What a dead man's switch is (and when your app needs one)

Most monitoring watches for something bad happening — a request that errors, a page that goes down. A dead man's switch does the opposite. It watches for something good not happening, and raises the alarm when the expected signal goes quiet.

It's the right tool for a whole class of failures that ordinary uptime checks miss entirely — and once you see the shape of it, you notice how many of your background jobs need one.

Where the name comes from

The term comes from the train driver's pedal that had to be held down to keep the train moving. Let go — because the driver was incapacitated — and the train brakes automatically. The safe state is triggered by the absence of a signal, not its presence.

In software, the switch is a timer you keep resetting. Your job checks in on every successful run; each check-in pushes the deadline forward. If a check-in ever fails to arrive before the deadline, the switch fires and alerts you.

Why absence is the signal that matters

A normal monitor asks "is this endpoint responding?" That works for a website, because a website is supposed to answer at all times. It doesn't work for a nightly backup, a weekly digest email, or an hourly sync — there's no endpoint to poll, and the failure you care about is silence, not an error.

When you want one

Reach for a dead man's switch any time the failure mode is a job that silently stops rather than one that loudly breaks:

Scheduled backups, cron jobs, queue workers, data syncs, batch imports, recurring emails, certificate renewals, cleanup tasks — anything that's supposed to happen on a rhythm and would otherwise fail without a sound. If nobody would notice for hours or days that it stopped, it needs one.

How to wire one up

The mechanism is simple: give the job a URL to ping at the end of a successful run, and set an expected interval. The monitor resets its timer on each ping. Miss the window — the job crashed, hung, got disabled, or the whole box went down — and you get alerted that the check-in never came.

That's exactly the heartbeat pattern we lay out, with the practical setup, in how to know if your cron job actually ran. It's the same fix behind a GitHub Action that gets disabled and a Supabase pg_cron job that quietly stops — a dead man's switch is what turns any of those silences into an email.