什么是 heartbeat / cron-job 监控？

反向监控——你的计划任务每次成功运行时 ping 我们的 URL。若我们在预期窗口没收到 ping 就报警。这解决了静默故障：挂掉的 cron job 不会报错，也不会被传统 uptime 监控捕捉到。

如何将 heartbeat URL 集成进我的 cron？

在 cron 命令末尾加上 curl -fsS <heartbeat_url>。如果前面的命令失败，curl 不会执行，heartbeat 就会被跳过。或者可以在开始和结束处分别 ping 两个路径，实现“开始”和“结束”信号分离。

应设置多长的 grace period（容忍期）？

约为任务平均执行时间的 2-3 倍。如果每日备份要 30 分钟，就设 90 分钟 grace——可以适度覆盖延迟，避免误报。对任务时长波动大的情况建议适当设置，并用仪表盘查找异常值。

可以监控每小时运行的 cron job 吗？

可以——只要设置合适的间隔（例如 60 分钟，grace 15 分钟）。监控会期望每 75 分钟至少收到一次 ping。如果你的任务更频繁（比如每 5 分钟），heartbeat URL 同样支持——只需匹配你的实际间隔设置。

heartbeat 监控能用于 AWS Lambda / serverless 吗？

可以。在 Lambda 函数最后加上对 heartbeat URL 的 HTTP 调用即可。监控对待它就和 cron heartbeat 一样——报警机制、容忍期设置完全一致。对那些 CloudWatch 无法发现执行静默失败的定时 Lambda 非常适用。

Cron监控 — 心跳与死亡监测

及时发现您的定时任务停止运行的瞬间。备份、队列任务、ETL作业、每小时同步等，全部静默监控。

计划任务的问题

cron 最可怕的特性之一是：当它出错时，没有任何提示。Web 应用仍然响应请求，主页看起来没问题，监控一切绿色，但某个地方的夜间备份其实已经两周没执行了。队列 worker 在上线后崩溃，积压的 job 越来越多。每小时同步由于权限问题悄悄丢失了数据行。你只有在下游某个环节最终崩溃时才发现——通常就是你最需要那项功能的时候。数据团队需要导出，支持部门要处理邮件队列，运维团队需要备份文件。到了这一步，已经太晚了。

标准的 uptime 监控检测不到这些问题，因为没什么可 ping。Cron 没有提供 HTTP endpoint、不开放端口、也不运行服务器。它执行、结束，再结束。如果停止工作——你没有任何迹象能够发现，除非主动去寻找。

反向方案：heartbeat 监控

Heartbeat 监控（也叫“死者开关”或“cron 监控”）采取了反向思路。不再是我们检测你的服务，而是你的服务主动向我们打卡。你只需给 cron 加一行——curl 我们生成的唯一 URL——而这个 URL 在每次 ping 时记录一个时间戳。我们检测这些 ping 的缺席。如果在预期时间间隔内（加上容忍范围）没接收到请求，就认为漏跑了一次，立即发送警报。

这种模型简单、可靠、且不依赖任何开发语言。只要能发 HTTP 请求，都能集成：Bash 用 curl，Python 用 requests，Node 用 fetch，PHP 用 curl_init，Windows 的 Task Scheduler 用 Invoke-WebRequest，GitHub Actions、Kubernetes CronJobs、Lambda 定时任务，等等。无需 SDK，无需 agent，无需安装守护进程。

如何配置

在 DiagnoSEO Uptime Monitoring 中点击“添加监控”，选择类型“Heartbeat / cron”。工具会生成带有 token 的唯一 URL，比如 https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9。设置预期间隔（job 多久执行一次，单位为分钟）和容忍范围（允许延迟多久前不会报警）。保存即可。

现在修改你的 cron，让它在每次成功运行后 ping 这个 URL。不同环境下有三种方式：

# Bash cron - 只在成功后 ping
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# 或当部分成功也可以接受时
0 3 * * * /usr/bin/backup.sh; curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Python
import requests
def main():
    do_the_work()
    requests.get('https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9', timeout=5)

# GitHub Actions
- name: Notify heartbeat
  if: success()
  run: curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9

从此每次成功执行都会 ping 我们，我们记录时间戳。如果在 间隔 + 容忍范围 分钟内没有检测到请求，就会开启故障事件，并通过所有已启用的通知渠道推送：邮箱、Telegram、Slack、Discord、短信。

如何选择间隔和容忍范围

间隔应严格等于 job 的计划频率。夜间 3:00 备份 — 间隔 1440 分钟（24 小时）。每小时同步 — 60。每 5 分钟轮询的 worker — 5。

容忍范围用于消化自然的抖动。Cron 不一定分毫不差地定时启动——会有排队、等待前一个任务完成、短暂错误后的重试回退。24 小时 job，1 小时容忍范围，可提供宽松缓冲，不会延误警报。5 分钟 worker 配 2 分钟容忍，能快速捕获真正停摆，而不会因短暂的 30 秒间断产生误报。大致建议：根据 job 抖动程度，容忍范围设置为间隔的 10-50%。

我们推荐的实践

只在成功后 ping。Bash 使用 &&，失败的任务不会 ping。我们会检测到缺失的 ping 并报警。
每轮循环后 ping 一次。长时间运行的 worker 建议在每个完成的 unit 里 ping，不是等到结尾。这样卡死的 worker 能在途中被及时发现。
一个 heartbeat 监控一个逻辑任务，而不是单一脚本。比如三个脚本拼成一个夜间流水线，只在链尾 ping 一次，可以给出是否“整个流程正常”这一清晰信号。
结合日志使用。Heartbeat 证明任务已启动，应用日志展示它做了什么。两者结合，监控更全面。

heartbeat 消失后会发生什么

当超过 deadline 时即开启故障事件。仪表盘将该监控标红并提示“已 X 分钟无 heartbeat”。通知会发送到所有启用的渠道。只要有新的 heartbeat 到来，监控会自动恢复正常，状态标记回“正常”，事件关闭，并（若开通了恢复通知）收到“已恢复”提醒。

这一切与其他监控一样——热力图、uptime 百分比、历史记录、标签、搜索、导出。对仪表盘来说，heartbeat 监控只是跟 HTTP、ping、端口、API 并列的又一行，可排序、可过滤。

操作清单

添加监控 → 选择 Heartbeat 类型 → 复制生成的 URL → 添加到 cron / worker / 调度器 → 设置间隔和容忍范围 → 保存 → 搞定。从现在起，只要计划任务停摆，你就能在数秒之内知晓——这可能是你为监控体系做的最关键的长期决策之一。

常见问题

什么是 heartbeat / cron-job 监控？
反向监控——你的计划任务每次成功运行时 ping 我们的 URL。若我们在预期窗口没收到 ping 就报警。这解决了静默故障：挂掉的 cron job 不会报错，也不会被传统 uptime 监控捕捉到。
如何将 heartbeat URL 集成进我的 cron？
在 cron 命令末尾加上 curl -fsS <heartbeat_url>。如果前面的命令失败，curl 不会执行，heartbeat 就会被跳过。或者可以在开始和结束处分别 ping 两个路径，实现“开始”和“结束”信号分离。
应设置多长的 grace period（容忍期）？
约为任务平均执行时间的 2-3 倍。如果每日备份要 30 分钟，就设 90 分钟 grace——可以适度覆盖延迟，避免误报。对任务时长波动大的情况建议适当设置，并用仪表盘查找异常值。
可以监控每小时运行的 cron job 吗？
可以——只要设置合适的间隔（例如 60 分钟，grace 15 分钟）。监控会期望每 75 分钟至少收到一次 ping。如果你的任务更频繁（比如每 5 分钟），heartbeat URL 同样支持——只需匹配你的实际间隔设置。
heartbeat 监控能用于 AWS Lambda / serverless 吗？
可以。在 Lambda 函数最后加上对 heartbeat URL 的 HTTP 调用即可。监控对待它就和 cron heartbeat 一样——报警机制、容忍期设置完全一致。对那些 CloudWatch 无法发现执行静默失败的定时 Lambda 非常适用。

Cron作业监控