网站和 API 可用性监控回答“服务现在能不能访问、用户能不能完成关键流程”。本文比较 HTTP、Ping、TCP、DNS、证书和浏览器合成检查，不比较 Cron 心跳和应用异常堆栈。
| 工具 | 主要定位 | 适合场景 | 主要代价 |
|---|---|---|---|
| UptimeRobot | 托管探活 | HTTP、Ping、端口、关键词和证书检查 | 复杂业务流程和深度 APM 较弱 |
| Uptime Kuma | 自托管探活与状态页 | 希望自己部署并控制数据 | 自己负责升级、备份和通知 |
| Checkly | 代码化合成监控 | API、浏览器流程和多区域检查 | 脚本、执行额度和告警治理 |
| Better Stack | Uptime、告警和事件响应 | 探活、值班、Status Page 和 Incident Management | 深度 APM 与复杂日志分析要外接 |
| Pingdom | 网站性能与可用性监控 | 网站、真实用户与性能基线 | 价格和高级能力需核对 |
UptimeRobot 与 Uptime Kuma
UptimeRobot 适合快速建立 HTTP、Ping、端口、关键词和证书探活；Uptime Kuma 适合自托管、内网服务和状态页。两者都应配置恢复通知、维护窗口和多渠道告警。
Checkly：API 与浏览器流程
Checkly 适合把 API 检查和浏览器流程作为代码运行，验证“页面能打开”之外的真实用户路径。脚本要避免依赖脆弱的选择器，并对检查频率、区域、凭据和敏感数据做治理。
Better Stack 与 Pingdom：托管闭环
Better Stack 把 Uptime、日志、告警、Status Page 和 Incident Management 放在一起，适合希望快速建立发现、通知、值班和对外沟通闭环的团队。Pingdom 更适合把网站性能和可用性基线纳入同一托管服务。
怎么选
| 需求 | 优先考虑 |
|---|---|
| 快速监控网站、API、端口和证书 | UptimeRobot |
| 自托管探活和状态页 | Uptime Kuma |
| API / 浏览器多步骤合成监控 | Checkly |
| 探活、值班、事件响应和 Status Page 一体化 | Better Stack |
| 网站性能与可用性基线 | Pingdom |
HTTP 探活应区分 DNS、连接、TLS、认证、服务端错误和业务响应错误；关键接口最好检查响应字段，而不是只判断 HTTP 200。定时任务心跳见定时任务监控方案对比。