Heartbeat monitoring (dead man's switch)
Your scheduled job pings a URL when it finishes. If the ping never arrives, you get paged. Alerting on silence instead of errors.
See it
What it is
Normal monitoring alerts you when something bad happens. A heartbeat alerts you when nothing happens. Give each cron job, backup, or queue worker a unique check-in URL that it pings on success. The monitor knows the expected schedule plus a grace period, and if the ping is late it pages you. Healthchecks.io, Cronitor, Better Stack, and the heartbeat or watchdog features inside Datadog and Grafana all run the same trick.
This catches the failure mode nothing else catches: the job that never started. A crashed container, a crontab line someone deleted, a paused scheduler, an expired CI credential. None of those emit an error, so error-based alerting stays quiet forever while your backups silently stop. The stronger setup pings /start when the run begins and the base URL when it succeeds, so you also catch jobs that hang or suddenly run ten times longer than usual.
Gotchas: the monitor has to live outside the system it watches, otherwise the outage takes the watchdog with it. Set the grace period from real observed runtimes rather than optimism, or you will train yourself to ignore it. And only ping on genuine success: a shell script that curls the heartbeat on the next line regardless of exit code is a dead man's switch that never dies.
Ask AI for it
Add heartbeat monitoring (a dead man's switch) to the scheduled jobs in this project. For each cron job or worker, read a unique check-in URL from an env var: request <URL>/start at the beginning of the run, <URL> only on successful completion, and <URL>/fail from the catch block with the error message in the body. Use a 5 second timeout and never let a failed heartbeat request crash or block the job itself. Configure each monitor with the job's cron expression plus a grace period of roughly 1.5x the observed p95 runtime, and route alerts to the on-call channel. Include run duration and records processed in the check-in payload so slow-but-succeeding runs are still visible.