定时任务半夜挂了没人知道？给 cron 加一层可观测性

自动化最怕的不是失败，而是静默失败。一个每天凌晨 2 点跑的备份任务，如果连续一周都挂了，你发现的那天，才是要出大事的那天。这一篇讲怎么用最小的成本，给 cron 任务加一层"挂了会叫"的可观测性。

第一层：退出码不等于健康

很多人以为 command && echo ok 就算监控了。问题在于：命令成功退出但没产出结果，是 cron 世界最阴险的失败。比如脚本跑完了，但因为上游 API 变更，一条数据都没写进去——exit code 是 0，日志里也没有报错，只有结果数量是 0。

所以每一条任务都要给自己定义"业务级成功条件"：写库任务检查受影响行数，发布任务 GET 回读确认状态，备份任务核对产物文件大小和时间戳。把"成功"从 exit code 升级为业务断言，是 cron 可观测性的第一块基石。

第二层：心跳比告警更便宜

与其等任务失败再告警（任务本身没跑、机器宕机、cron 守护进程死了，都轮不到你的告警逻辑），不如反过来：让任务成功后上报一个心跳。用 dead man's switch（死人开关）的思路——健康监控服务每隔 N 小时没收到 ping，就说明任务没活着，主动发通知。GitHub Actions 有第三方托管方案，自托管的话一个小 HTTP 端点加一条 cron 扫描就够用。

心跳要点：任务结尾加一行 curl 或脚本调用；超时阈值设成"调度周期 × 2 + 缓冲"；上报内容带上任务名、日期、关键产出计数，排查时不用登机器就能定位。

第三层：留一份人类可读的运行档案

机器告警之外，每次运行往固定位置追加一行摘要：时间、任务、状态、耗时、产出数。文件比数据库更适合半夜排查——tail 一眼看穿最近七天的规律。哪天耗时突然翻倍、产出突然减半，趋势肉眼可见，往往比阈值告警更早发现问题。

上线前的自检清单

给新 cron 任务过一遍这四问：失败时谁会知道？会不会静默成功？重试会不会造成重复副作用（写库要先查重、发布要幂等）？日志能不能在 30 秒内定位到出错那一步？四问都有答案，任务才配得上"无人值守"四个字。

自动化的尊严不在于它平时跑得多顺，而在于它挂掉的那一刻，有人——或者至少有个进程——在替你着急。