What is a dead man's switch?
A nightly job that quietly stops running looks identical to a nightly job that has nothing to do. A dead man's switch is the only thing that tells the two apart.
Dead man's switch
heartbeat monitoring
A dead man's switch is a monitor that expects a periodic check-in from a scheduled job, then alerts if the check-in is late. It flips the usual alerting logic. Instead of watching for an error, it watches for silence.
The name comes from the railway lever a driver has to keep pressing. Let go, and the train brakes on its own. A software dead man's switch works the same way. Your job pings a monitoring endpoint at the end of every successful run. The monitor does nothing as long as pings keep arriving on schedule.
Miss the expected window, whatever it is, and the monitor assumes the job is gone rather than merely quiet. It alerts a person, because a scheduled job that stops checking in is a different problem than a scheduled job that throws an error.
Most monitoring can't see this failure at all
Error monitoring, uptime checks, and log alerts all share one assumption: something has to run and fail before there's anything to catch. A cron job that got deleted produces no error. Neither does a server that never came back up after a redeploy, or a scheduler process that crashed silently. There's nothing to throw, because nothing executed.
That's the gap a dead man's switch closes. It doesn't watch the job. It watches for the job's absence, which is the only signal available when the job itself has stopped existing in any observable way.
The failure mode this catches is common and expensive: a nightly billing sync, a report generator, or a data pipeline that quietly stopped weeks ago. Nobody notices until a downstream number looks wrong, and by then the gap has to be reconstructed by hand.
- 01The check-in interval has to allow for normal variance, or a slow run trips a false alarm every week.
- 02The ping fires on success, not on start, so a job that starts but hangs still counts as missing.
- 03Services like Cronitor, Healthchecks.io and Better Uptime offer this as a hosted endpoint; most teams don't need to build it themselves.
- ScheduleJob is expected to run on a fixed interval.
- RunJob executes and finishes normally.
- Check-inJob pings the monitor on success.
- WindowMonitor waits for the next expected ping.
- MissedNo ping arrives inside the window.
- AlertA person is told, not just a log.
Ordinary monitoring stops at 'Run'. A dead man's switch is built around the step after it, where a job that never restarted produces nothing to watch.
Common questions
01How is a dead man's switch different from uptime monitoring?
Uptime monitoring checks whether a service responds when asked. A dead man's switch checks whether a scheduled job checked in when it was supposed to, with no request needed to trigger it. A server can be fully up while the one cron job on it has silently stopped running.
02What should the check-in window be set to?
Slightly longer than the job's normal runtime plus its schedule interval, so a slow but successful run doesn't trip a false alert. A daily job that usually finishes in ten minutes might get a two-hour window; too tight and every alert becomes noise someone starts ignoring.
03Does every scheduled job need one?
Any job whose failure would go unnoticed until someone checks the output by hand is a candidate. A job that writes to a dashboard people look at daily has a natural backstop. A job that feeds a report nobody opens until month-end does not.
