Five reasons your cron job failed silently (and how to catch each one)

Disclosure: I maintain Cronbell, a small heartbeat monitor. Everything below works with any heartbeat service, including self-hosted Healthchecks.io.

1. MAILTO is silent when nothing runs. It mails only when a job prints output and needs a working mail setup. If crond is stopped, the host is down or the crontab was replaced, you hear nothing.
2. ; instead of &&. backup.sh ; curl $PING pings even when the backup failed. Use backup.sh && curl $PING.
3. Output sent to /dev/null. The failure happened and you discarded the evidence.
4. DST and timezones. 30 2 * * * does not exist on the spring DST change in many zones and occurs twice in autumn. A fixed 24-hour interval drifts against it; a monitor that evaluates the cron expression in your IANA timezone does not.
5. Grace shorter than the runtime. A 40-minute backup with a 15-minute grace alerts every night until you learn to ignore it.

The fix is a heartbeat: the job requests a URL on success, and the service alerts when the request is late. Send /start first and /fail on error if you want runtime and explicit failures.

I collected tested, service-agnostic examples (crontab, systemd timers, Kubernetes CronJob with timeZone, restic, borg, a wrapper script that preserves exit codes) here: https://github.com/jinqo/cron-heartbeat-snippets

Which of these has actually bitten you, and how did you find out?