多数自托管可用性监控工具的比较，起点都放在仪表盘上。这往往并非最有判断力的起点。界面是否顺手当然重要，却不足以决定工具和你真正要抓住的故障类型是否贴合。更高价值的问题其实更简单，也就是：健康证明究竟从哪里来。

有一类系统，健康信号应当来自外部观察者的持续探测，反复去打 URL、TCP 端口、DNS 记录，或者容器边界。还有一类系统，健康信号更适合来自一份小而明确、可以被审阅的配置文件，把每个端点的通过条件和失败条件写清楚。再往下一类，健康信号只能来自任务自己按时回报，因为外部根本没有一个足够有意义的东西可供轮询。顺着这个角度去看，Uptime Kuma、Gatus 和 Healthchecks 就不再像三件可互换的替代品，而更像三种不同的监控形状。[1][3][5]

这一层差别，从当前发布节奏里也能看出来。以 2026-05-07T08:05:19Z UTC 为准，Uptime Kuma 最近的稳定版是 2.3.0、2.3.1 与 2.3.2，发布时间集中在 2026-05-01 到 2026-05-03。[2] Gatus 最近的稳定版是 v5.35.0，发布于 2026-02-20。[4] Healthchecks 则在 2026-04-28 发布了 v4.2。[7] 这些日期并不能直接证明谁更强，却足以说明三者在 2026 年都仍是活跃的操作性选择，而并非已经失修的边角工具。

图像说明：题图采用一张真实网络机柜照片，画面里有路由器、交换机与交错的跳线。它适合这篇文章，因为可用性监控的核心工作，就是把杂乱的物理与逻辑连接状态，提前转换成可读的信号，让故障在用户工单出现以前就被看见。[8]

1. Uptime Kuma 是以面板为中心的主动探测工具

Uptime Kuma 最容易成立的场景，是你希望把许多不同类型的主动检查放进一个自托管界面里，并且让值班的人一眼就能看到答案。项目自己的 README 把它描述为一个容易上手的自托管监控工具，并列出了很长一串监控类型，包括 HTTP(S)、TCP、关键字与 JSON 查询检查、WebSocket、Ping、DNS 记录、Push、Steam 游戏服务器，以及 Docker 容器。[1] 同一份说明里还强调了多套状态页、状态页域名映射，以及覆盖很广的通知渠道，并不只是邮件一种。[1]

这组信息说明它真正优化的是什么。Uptime Kuma 不只是一个探测器，它还在试图成为一个操作员日常会进入的房间：主动健康检查、告警分发，以及公开或半公开的状态沟通，都可以在这里并排出现。若你运行的是一组内部服务、一个规模不大的 SaaS 栈、一片 homelab，或者一个轻量平台，希望用一处可视化界面把这些东西管起来，这种形状就很有吸引力。[1]

因此，它最强的适配面，是那些“它现在到底是并非可用”会被反复追问的环境，而且答案可以从外部观察中得出。HTTP 可达性、TLS 证书到期、关键字是否出现、容器状态、端点延迟，这些都很自然地落在 Uptime Kuma 的工作边界里。[1] Push monitor 虽然把它往任务回报那一侧稍微拉近了一点，整套产品的重心依旧来自主动观测。[1]

它的边界也同样清楚。只有当团队真的会使用那个实时界面、真的会把状态页当成产品的一部分时，Uptime Kuma 的价值才最完整。若团队更希望把监控逻辑写成可审阅配置、拆进版本库、再用许多小片段组合起来，Kuma 的强项就会退到第二位。它最突出的便利，在于操作上的即时性，而不在于配置表达的克制。

2. Gatus 是把端点健康写成配置的评估器

Gatus 的出发点完全不同。它的 README 把项目写成一个面向开发者的健康仪表盘，可以用 HTTP、ICMP、TCP、DNS 等协议监控服务，再通过条件表达式去评估结果，判断状态码、响应时间、正文内容、证书等是否满足要求。[3] 这表面上像一组功能条目，真正重要的是它的结构中心，也就是端点定义和条件本身。

示例配置与参数表把这件事写得很清楚。端点以 YAML 声明，每个端点带有自己的轮询间隔，也带有自己的通过或失败条件。[3] Gatus 还提供告警、维护窗口、远程实例聚合、并发度、存储配置，以及多份配置文件合并规则，让多个 YAML 文件最终拼成一张统一的操作图。[3] 也就是说，Gatus 更像一个附带仪表盘的监控策略仓库。

因此，当团队希望健康逻辑可审阅、可迁移、可文本化时，Gatus 会特别顺手。后端团队可以把“健康”写成一组断言，而并非只在网页表单里点出一个绿色对勾。平台团队则可以把端点定义放进版本控制，用环境变量注入差异，把配置按服务或团队拆分，必要时再把多个实例聚合进一块总览面板里。[3] 对已经习惯 pull request 与部署包的工程组织来说，这种形状更自然。

对应的代价也写在文档里。Gatus 对轮询间隔和慢检查的说明很直接：若检查本身耗时很长，它会影响工具接近理想轮询节奏的能力，因此复杂检查更适合拉长间隔，告警关键路径则适合保留较短周期。[3] 这句话暴露了它的性格。Gatus 并不假装所有东西都应当每几秒探一次、且没有成本。它要求使用者对检查预算和检查语义都保持清醒。

所以，选择 Gatus 最好的理由，应当落在“我们希望端点健康像配置工程一样被书写和审阅”，而并非“我们还缺一个面板”。

3. Healthchecks 是要求任务按时回报的心跳工具

Healthchecks 所在的类别又是另一种。它的文档起点落在 check、ping URL、schedule 和 grace time 上，URL 与端口只属于另一类主动探测语言。[5] 每一个定时任务或周期性进程都会获得一个独有的 ping URL，被监控的系统向这个 URL 发送 start、success 或 failure 信号。[5] 一旦预期时间过去，检查会先进入 late；再过了 grace window，才会进入 down。[5] 如果一个任务发出了 start 却始终没有送来 success，Healthchecks 也可以在 grace time 用尽后把它视为失败。[5]

这使得 Healthchecks 对 cron 作业、定时任务、批处理流水线、备份脚本、导入器、报表生成器，以及后台 worker 这一类工作特别合适，因为它们往往从外部根本没有一个足够可靠的探测面。一个数据库备份脚本所在的机器返回 HTTP 200，并不意味着备份真的在跑。一个队列 worker 端口是通的，也不意味着它完成了应该完成的批次。Healthchecks 之所以成立，正在于它要求任务自己证明：我确实按时出现过。[5]

文档把这种操作形状写得很完整。Projects 与 teams 让检查和集成可以按项目分组，同时保留独立的 API key 与访问边界。[5] 自托管配置文档又把产品的另一面交代得很清楚：数据库默认可以落在 SQLite、PostgreSQL 或 MySQL 上，邮件与验证行为可以单独配置，ping 请求体还可以选择写入兼容 S3 的对象存储，避免全部塞进主数据库。[6] 这说明它的形态已经越过孤零零的 webhook 端点，是一个带有自己状态模型的调度监控应用。[5][6]

边界也同样明确。若你的主要需求是连续地主动探测公开网站、证书或网络服务，Healthchecks 通常并非最该先上的那一件。它当然可以和这些工具并存，却没有打算去赢得同一个类别。它的中心，自始至终都是那些必须按时回报的工作负载。

4. 一个更实用的选择图

优先选择 Uptime Kuma，通常出现在这些场景里：

优先选择 Gatus，通常出现在这些场景里：

优先选择 Healthchecks，通常出现在这些场景里：

一个常见而且合理的部署方式，并非“三选一”。Kuma 与 Gatus 都覆盖主动观测，只是操作文化不同；Healthchecks 则覆盖另一类“这个任务必须回报自己已经跑过”的系统。因此，不少团队最后会把一种主动探测工具与 Healthchecks 配在一起，而并非逼某一个产品去假装同时扮演两种模型。

5. 最容易犯的错

最常见的错误，是因为三者都能发通知、都能在某个界面上显示红绿状态，就把它们看成可以互相替代的同类产品。这样会把三种不同的真实性模型压平到一张购物清单里。

Uptime Kuma 的办法，是让外部观察者持续去看。[1] Gatus 的办法，是让一份可审阅的配置文件定义何谓健康。[3] Healthchecks 的办法，是让工作负载自己回报它确实按时出现。[5] 这一层一旦摆稳，选型反而会变得简单。最好的工具，通常就是它的信号模型和你系统里的故障进入方式相互贴合的那一个。

来源

  1. Uptime Kuma GitHub README：监控类型、push monitor、通知范围、状态页、域名映射与 Docker 安装形状。
  2. louislam/uptime-kuma 的 GitHub API 发布流：最新稳定标签与发布时间，包括 2.3.0-2.3.2。
  3. Gatus GitHub README：端点条件、轮询间隔、告警、存储、远程实例、配置合并与部署方式。
  4. TwiN/gatus 的 GitHub API 发布流：最新稳定标签与发布时间，包括 v5.35.0。
  5. Healthchecks 文档：ping URL、调度、grace time、late/down 状态、集成、项目与团队边界。
  6. Healthchecks 自托管配置文档：数据库默认项、邮件设置，以及将 ping 请求体写入兼容 S3 对象存储的可选方案。
  7. healthchecks/healthchecks 的 GitHub API 发布流：最新稳定标签与发布时间，包括 v4.2。
  8. 本文题图所用网络机柜照片的 Wikimedia Commons 文件页。