网站白天还能打开，晚上有人发消息说访问失败，才发现服务已经停了几个小时。容器设置了自动重启，也不能保证域名、HTTPS、数据库和页面都正常。Uptime Kuma 可以定时检查入口，把异常送到通知渠道，再保留一段可查询的状态记录。
部署位置要先想清楚。如果监控和被监控的网站都放在同一台 VPS 上，机器断电或网络中断时，它们会一起停止。这里建议用另一台 VPS 监控正式网站，最好让故障范围也有区别；仅仅多建一个容器，无法覆盖宿主机宕机。一个个人站点可以先做好 HTTP 检查和通知，再逐步增加细节。
部署前先确认 VPS 的磁盘、内存和公网访问条件，也可以查看雨云云服务器；注册时填写优惠码 KuZhuJi。
先决定监控哪一个入口
读者访问的是域名，所以第一项监控通常应该是公开 HTTPS 地址。只检查源站 IP，可能漏掉 DNS、证书和代理故障；只检查代理缓存页，也可能漏掉源站应用已经停止。可以建立两项检查，但名称必须区分，例如“公开首页”和“源站应用健康检查”。
没有独立健康接口时，先用首页做 HTTPS 检查，再增加一个关键词判断。网站错误页也可能返回 200，用正文中一个稳定且有意义的短语作为条件，能识别一部分“能响应但页面不对”的情况。关键词不要选用户名、每日日期或随机数字，否则内容正常变化也会触发告警。
监控节点看到的是它自己的网络路径，不代表所有地区用户的访问体验。海外监控检查国内网站时，跨境链路的短暂异常也会反映在记录里。先观察一段时间再调整重试和间隔，不要把每次单个请求失败都当成站点整体故障，也不要把可用率百分比当速度测试结果。
在专门目录中启动 2.x 镜像
项目当前 Docker 安装入口使用 louislam/uptime-kuma:2。本例不为已有 1.x 实例安排直接升级；旧实例需要阅读正式迁移说明，先备份并验证兼容性。新安装的服务器已经具备 Docker Engine 和 Compose 插件，当前账号可以运行 Docker，域名 status.example.com 解析到监控 VPS。
mkdir -p /opt/uptime-kuma/data
cd /opt/uptime-kuma
docker version
docker compose version
保存以下内容为 compose.yaml，应用数据全部放在 data。本例只做 HTTP、TCP 等网络检查，不需要挂载宿主机 Docker socket。为了一个网站的可用性告警，不必给监控服务管理整台机器的权限。
services:
uptime-kuma:
image: louislam/uptime-kuma:2
restart: unless-stopped
ports:
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/data
environment:
TZ: Asia/Shanghai
2 会跟随该主版本的镜像发布移动。首次部署通过检查以后，记录镜像摘要，固定到验证过的摘要或正式版本标签。后续升级先看发布说明，再安排维护窗口，避免一次自动更新让通知渠道和数据迁移同时出现问题。
docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=80 uptime-kuma
curl -I http://127.0.0.1:3001/
出现权限错误时检查挂载目录和运行用户；容器虽然启动但进程不断退出时，读取日志里最早的错误。不要急着删掉 data 重新安装，那里既有账号，也有通知配置和监控历史。先留一份副本，再做诊断。
管理员入口先保持私人
初始化可以通过 SSH 转发进行，在自己的电脑执行下列命令并打开本机 13001 端口。替换用户与服务器地址，创建管理员账号后再公开域名入口。
ssh -N -L 13001:127.0.0.1:3001 user@monitor.example.com
Caddy 运行在宿主机，站点段使用下面的上游地址。保存后先校验配置，再重载服务；入站 80、443 和 DNS 需要正确。Caddy 能处理 WebSocket，后续使用控制台时也要确认连接没有被中间代理截断。
status.example.com {
reverse_proxy 127.0.0.1:3001
}
如果把代理放进另一个容器，改用共享 Docker 网络上的服务名。域名入口打开后，用未登录窗口核对管理界面需要认证。公共状态页可以按需建立，但不要把内部接口地址、私有机器名称、通知接收人的联系方式都放到公开页面上。
给管理员设置独立密码，并在当前界面中配置二次验证和恢复资料。监控控制台里可能保存 Webhook、邮件或机器人令牌，它们能把消息发到你的渠道，不能把控制台当普通展示页面随意开放。
准备独立实例时，可在雨云选择适合的云服务器配置，优惠码 KuZhuJi。配置按实际任务选择，数据库和附件另做备份。
第一项检查要能证明它真的工作
添加 HTTPS 监控，填写网站真实入口。可以先用一分钟左右的间隔观察，不要为了追求即时发现把所有站点都改成极高频率；检查会访问被监控服务，也可能撞上限流。请求超时设置需要符合实际响应情况，过短会放大偶发慢请求，过长则延迟发现。
状态码和关键词检查可以分别设置。带登录的网站不要把长期管理员 Cookie 填进去检查首页，尽量提供不暴露内部信息的健康接口。确实要认证时，使用专门的低权限账号，记录到期和轮换方式，否则账号失效也会被误看成应用故障。
创建完监控后，确认状态从等待变成正常，并查看一次响应记录。随后添加一个专门的测试监控，指向自己控制的不存在路径，配置期待正常状态码，使其产生失败。把这一项绑定通知渠道，用它验证真实告警，再删除或停用测试项，避免为了验证告警去停止正式网站。
有些站点会将所有不存在的路径重定向到首页，测试地址不一定失败。验证时先检查 HTTP 返回行为；需要稳定的异常，可以用专门的测试服务或一个由自己管理的错误响应地址，不要猜测第三方网站的某个地址永远不存在。
通知需要测两次
通知设置中的测试按钮可以证明消息渠道基本可用，但还要确认监控项真的绑定了渠道。先发送测试消息，再用失败监控触发一次状态变化，最后让测试监控恢复，确认恢复消息也到达。收到第一条消息以后，核对标题是否能识别哪个域名出了问题。
同一项监控短时间来回变更，会产生很多通知。用重试和重试间隔过滤短暂抖动，比直接关闭通知更合理；真正持续失败还应尽早提醒。配置调整以后记录原因，后续遇到长时间漏报，可以知道是检查没有运行，还是重试规则把告警推迟了。
如果用邮件，测试收件箱、垃圾邮件和发件账号额度；如果用 Webhook，检查接收方认证和响应。如果消息渠道依赖被监控的同一台 VPS，那台机器故障时通知仍可能断掉，应选择故障范围更独立的渠道。主要渠道失效时，可以再设一个备用接收方式。
需要增加服务器时，可以打开雨云选购页面，填写优惠码 KuZhuJi；迁移前保留数据与原有部署配置。
一次告警后怎样判断故障位置
公开入口失败，先从自己的网络和另一条路径访问。仅监控节点失败，可能是路径、限流或节点本身的问题；多个地方都失败，再检查 DNS、证书和源站。保留发生时间，和网站日志、代理日志对应，避免只靠用户截图判断故障持续了多久。
若本机应用健康检查正常、公开域名失败，优先查代理、DNS和 HTTPS。应用检查也失败，再查容器状态、数据库连接和资源使用。TCP 端口可达只能说明连接可以建立，不代表应用返回的业务内容正确，不要因此直接宣布网站已经恢复。
证书到期相关提醒也需要结合实际终止 TLS 的位置。如果域名前面还有其他代理，监控看到的证书可能属于代理入口；源站证书的到期要单独处理。公开页面正常不代表下一次回源还能成功，特别是使用严格回源校验时。
迁移监控时别制造重复告警
备份前确认最近的通知已经处理，安排一个短维护窗口，停止容器后打包完整数据目录和 Compose。历史数据会逐渐增长，先看磁盘空间，再决定保留周期，不要等数据库写入失败才清理。
cd /opt/uptime-kuma
mkdir -p /opt/backups
docker compose stop uptime-kuma
tar -czf "/opt/backups/uptime-kuma-$(date +%F-%H%M).tgz" compose.yaml data
docker compose start uptime-kuma
复制备份到另一处存储。恢复测试要使用隔离环境，先阻止它向正式通知渠道发消息，避免两套实例重复监控、重复告警。检查账号、监控项目、历史和通知配置是否齐全，再确定迁移顺序。正式切换时，一边启用、一边停用，保留清楚的交接时间。
上线后每隔一段时间重复一次测试告警，检查接收渠道仍可用。有人改了机器人权限、邮件密码或 Webhook 地址，监控页面可能仍然一片绿色，但最需要的那条消息已经发不出来。把这个检查安排进维护日程，比再增加几个没人看的指标更实在。