What Is a Dead Man's Switch in Monitoring? Alerting on Absence
A dead man's switch in monitoring is an alert that fires when an expected signal stops arriving, rather than when something reports a problem. It borrows its name from the mechanical control that stops a train when the operator releases the handle, and it exists for the same reason: to make silence dangerous instead of comfortable.
This article covers what the pattern actually protects against, why absence is the hardest failure for conventional monitoring to notice, where the design belongs in a monitoring setup, and the sizing decisions that separate a switch you trust from one you mute. It also covers the uncomfortable question the pattern raises, which is what watches the watcher.
Why absence is the failure nobody catches
Most monitoring is built around events. Something breaks, something emits an error, a threshold is crossed, an alert fires. That model works because failure usually announces itself. A server returns a 500, a disk fills, a latency graph spikes, and the system that noticed sends a message.
The failure mode this misses is the one where nothing announces anything. A cron job removed during a deploy generates no error, because nothing ran and nothing failed. An alerting integration whose credentials expired generates no error visible to you, because the integration is failing to send rather than failing to work. A monitoring agent that stopped reporting looks identical to a system with nothing to report. In every case the signal that would have told you is precisely the signal that stopped, which is why the absence has to be the alert.
The pattern also names something people usually notice only in hindsight. Teams routinely treat a quiet dashboard as good news. A dashboard with no alerts and a dashboard whose alerting pipeline is broken look exactly the same from the outside, and the second one stays comfortable right up until the outage that nobody was told about. A dead man's switch is how you distinguish the two without waiting for the outage to do it for you.
How the pattern works in practice
The mechanism is a timer that something has to keep resetting. Your system sends a signal on a schedule, usually an HTTP request to a unique URL. Each arrival resets the clock. If the clock reaches the configured limit without a reset, the monitor alerts. Nothing in the setup requires your system to know anything is wrong, which is the entire point, since a system that knew would have alerted already.
That description is also a description of a heartbeat monitor, and the two overlap heavily. The useful distinction is intent rather than implementation. A heartbeat monitor usually watches one job and answers whether that job ran. A dead man's switch is the same technique aimed at the monitoring chain itself, answering whether the thing that would tell you about problems is still capable of telling you. Same mechanism, different subject.
The most valuable place to apply it is the last link before a human. Configure a low-severity alert that fires on a fixed schedule, once a day or once a week, and route it through the same path a real alert would take: same integration, same channel, same on-call rotation. If that scheduled alert stops arriving, the pipeline is broken, and you learn it on a Tuesday afternoon rather than during an incident. Teams that run this find broken integrations far more often than they expect, usually after a credential rotation, a channel rename, or a permissions change nobody connected to alerting.
Choosing the window, and choosing the severity
Two settings decide whether the switch is useful. The first is the window, meaning how long silence is allowed before it counts. Set it too tight and normal variation trips it, because networks retry, schedulers drift, and jobs occasionally run long. Set it too loose and the switch cannot tell you anything urgent, because a full day of silence has already passed by the time it speaks. A defensible starting point is the expected interval plus the longest normal delay you have actually observed, plus a margin, revisited once you have real data.
The second is severity, and this is where most implementations go wrong. A dead man's switch on a nightly report and a dead man's switch on your alerting pipeline are not the same emergency, even though the mechanism is identical. The first can wait for morning. The second means you are currently blind, and every other alert in the system is unreliable until it is fixed. Routing both to the same channel at the same priority teaches people to treat the channel as background noise, which defeats a pattern whose whole value is that someone notices.
What watches the watcher
The obvious objection to a dead man's switch is that it moves the problem rather than solving it. If your monitoring can fail silently, so can the thing monitoring your monitoring. That objection is correct, and the honest response is that the pattern reduces shared failure rather than eliminating it.
The reduction comes from independence. A switch that runs on the same host, through the same network path, using the same credentials as the system it watches shares every failure mode with that system, and it will go quiet at exactly the moment you needed it. A switch hosted by an external service, reached over the public internet, using separate credentials, fails independently of your infrastructure in almost every scenario that matters. It is not immune. It is uncorrelated, which is the achievable version of the same goal.
The same logic argues against running the switch through infrastructure you own at all. If your monitoring, your alerting, and your dead man's switch all live in one cloud account, one region, or one provider, a single account or region failure takes all three. Distributing that risk is why external monitoring exists, and it is the same argument for keeping a status page on separate infrastructure from the product it reports on.
Common mistakes in dead man's switch monitoring
Running the switch inside the system it watches. A check that shares a host, a network path, or a set of credentials with its subject shares its failures too. Put the timer somewhere that can survive the outage it is meant to report.
Giving every switch the same severity. A silent nightly report and a silent alerting pipeline are different emergencies. Flatten them into one channel and the channel becomes noise, which is the failure the pattern was supposed to prevent.
Setting a window nobody validated. Windows chosen from intuition rather than observed timing either fire constantly or fire far too late. Measure the normal interval first, then set the window against real numbers.
Writing an alert with no context. An absence produces no error to attach. If the message does not name what went quiet and when it was last seen, the responder starts from nothing at the worst possible moment.
Never testing it. A switch that has never fired is a switch you have never verified. Stop the signal deliberately, confirm the alert arrives through the full path to a human, and repeat after any change to the alerting chain.
FAQ
What is a dead man's switch in monitoring?
It is an alert configured to fire when an expected signal stops arriving. Instead of reacting to a reported problem, it treats silence as the problem, which is how it catches failures that produce no error message anywhere.
Is a dead man's switch the same as a heartbeat monitor?
The mechanism is the same, and the terms are often used interchangeably. In practice a heartbeat usually watches whether a specific job completed, while a dead man's switch is the same technique aimed at the monitoring or alerting chain itself.
What should a dead man's switch watch?
The highest-value target is the alerting path, checked with a scheduled low-severity alert that travels the same route a real one would. After that, any scheduled work whose absence would go unnoticed, such as backups, exports, and data refreshes.
How long should the silence window be?
Long enough to absorb normal variation and short enough to be actionable. Start with the expected interval plus the longest delay you have actually observed plus a margin, then tighten it once a few weeks of real timing data exist.
Closing thought
The pattern is worth the odd name because it names something monitoring setups genuinely miss. Systems built entirely around reported failures are blind to the failures that report nothing, and the most consequential version of that blindness is an alerting pipeline that has quietly stopped working. A dead man's switch does not make your systems more reliable. It makes your knowledge of them more reliable, which is a different and often more valuable thing.
If you want the outside-in half of that picture handled by infrastructure that fails independently of your own, Odown runs checks from seventeen locations on every plan and delivers alerts through Slack, Discord, Telegram, Opsgenie, PagerDuty, email, and webhooks. Point a scheduled test alert through the same path your real alerts take, confirm it lands, and you will know your alerting works before you need it to.
