适用范围与前提
本文配套 站点可用性探测，用于自托管 Uptime Kuma 的探测对象、通知和状态页验收。开始前登记探测点所在网络、目标清单、通知测试接收人和数据目录；本文未在你的目标环境执行，验证状态为待验证。
Uptime Kuma 从部署实例所在网络发起检测。一次 HTTP 成功只说明该探测规则被满足，不能证明全部业务链路或全部用户入口可用。容器处于运行状态也不等于应用可服务。需要主机指标、日志或复杂告警路由时，应另外使用 Prometheus、Grafana 和 Alertmanager。
先固定探测点与对象清单
为每个监控项写清：探测点位置、目标地址、期望状态码或关键词、间隔、超时、重试，以及失败后谁在多长时间内做什么。容器内的 localhost 指向容器自身，目标必须写成探测实例实际可达的地址。
优先选择业务自己的健康检查接口，而不是只探测首页或登录页。公开状态页只放入适合对外展示的名称和服务，不要放内部主机名、管理地址或令牌。
部署后核对实例与数据目录
2.x 的 Docker 数据默认挂载到 /app/data。官方不支持把该目录放到 NFS 等网络文件系统。首次启动后应能在绑定地址打开安装向导并创建管理员；生产入口不要把 3001 直接暴露到公网。
docker compose ps
docker compose logs --tail=100 uptime-kuma上述命令只读取当前 Compose 项目状态和最近日志，不修改监控配置。正式部署应记录经过验证的镜像版本或摘要，而不是长期跟随浮动的 :2 标签。
验收探测规则而不是“页面能打开”
HTTP(S) 监控至少核对状态码、超时和证书；仅状态码不够时再加关键词或 JSON 查询。Push 监控把心跳令牌当作秘密保管，轮换后更新所有调用方。Docker 容器监控需要把宿主机 docker.sock 挂进容器，这会把 Docker 控制权交给该实例，公网暴露时不要启用。
经授权后只在测试对象上制造一次失败与恢复，记录：状态变化时间、通知送达时间、恢复通知是否出现。不要用生产核心服务做故障注入。
通知渠道、维护窗口与降噪
通知可使用 SMTP、Telegram、Slack、Discord，以及钉钉、飞书、企业微信、Server 酱等渠道；完整列表以当前版本界面为准。先在测试接收端验证，再绑定正式值班通道。维护窗口应写明范围、负责人和结束时间，避免计划内发布被当成故障。
重复通知、探测点自身网络抖动和证书临期要分开处理。通用分级方法可参考 Prometheus 告警分级与降噪实践，该文不表示 Uptime Kuma 使用 Alertmanager。
反向代理、状态页与指标出口
对外访问使用独立域名或子域名，反向代理必须转发 WebSocket 的 Upgrade 与 Connection。官方不支持把完整管理界面放在 /uptimekuma 这类子路径。若实例只通过代理访问，在设置中开启 Trust Proxy，以便日志记录真实客户端地址。
/metrics 使用首个管理员账号的 HTTP Basic Auth，供已有 Prometheus 抓取；开启后限制来源，不要把该接口公开到未授权网络。
备份、升级与回退
2.x 已移除 JSON 备份/恢复，支持的做法是停止实例后复制完整 data 目录；若改用 MariaDB 等外部库，须把该库一并纳入备份。升级前记录镜像版本和挂载路径，在隔离目录验证备份可启动。
docker compose pull
docker compose up -d --force-recreate同一主版本可按官方说明重建容器并保留数据卷。v1 升 v2 会迁移心跳数据，耗时随历史记录增长，期间不要中断进程；失败后用升级前备份和对应旧版本在隔离目录恢复，不要让旧程序直接读取已迁移数据。
出现通知未送达、状态页泄露内部信息、WebSocket 无法登录或探测点只能看到自身网络时，停止扩大监控范围，先恢复已知可用的入口和备份。