定时任务监控回答“任务有没有按时开始和完成”。它只负责接收心跳、判断漏跑、超时和失败并通知，不负责执行任务，也不替代队列和工作流平台。
| 工具 | 主要定位 | 适合场景 | 主要代价 |
|---|---|---|---|
| Cronitor | Cron 和后台任务监控 | 任务心跳、失败、超时和漏跑 | 不负责执行任务 |
| Healthchecks.io | Cron 心跳监控 | 开源核心、宽限期和通知 | 主要聚焦任务心跳，不是完整探活平台 |
| Better Stack | Uptime 与事件响应 | 同时需要任务心跳、值班和状态页 | 深度任务上下文和工作流能力需验证 |
| Checkly | 代码化合成检查 | 用 API / 浏览器检查顺带监控 Cron | 执行额度和脚本治理需要管理 |
Cronitor：任务心跳与执行窗口
Cronitor 通过任务开始、完成和失败心跳发现异常，也能发现任务根本没有运行。任务本身仍由 Cron、systemd、调度平台或 Worker 执行。
使用时要为任务定义合理的超时、执行窗口、负责人、通知渠道和恢复通知。
Healthchecks.io：简单可靠的心跳
Healthchecks.io 以心跳和宽限期为核心，适合脚本、备份、定时同步和个人服务。它的边界清晰：知道任务是否按时汇报，但不会替你保存完整执行上下文或调度任务。
怎么选
| 需求 | 优先考虑 |
|---|---|
| 发现 Cron 失败、超时和漏跑 | Cronitor |
| 需要简单的 Cron 心跳和开源核心 | Healthchecks.io |
| 已经把值班、状态页和 Uptime 放在 Better Stack | Better Stack |
| 需要把 API / 浏览器合成检查和 Cron 放在一起 | Checkly |
| 需要任务执行、重试、补跑和业务状态 | 选择任务调度或工作流平台，而不是监控工具 |
接入检查：任务必须有成功、失败、超时和漏跑四种状态；告警要包含任务名、执行时间、耗时、错误摘要和负责人；通知要有恢复和升级路径；执行器迁移时不应重做监控。
网站和 API 探活见网站与 API 可用性监控方案对比。