Updated 25 October 2026 · By the Upcertain team
Where the name comes from
A train driver's dead man's switch stops the train unless the driver keeps pressing it. Nothing has to go wrong in a visible way: the absence of the signal is the alarm. Software borrowed the idea for work that has no address to check, such as cron jobs, backups, queue consumers and data imports.
Why ordinary uptime checks miss these failures
An HTTP check can tell you a website answers. It cannot tell you that last night's backup ran, because a job that never started produces no error, no log line and nothing to request. The failure is silence, and silence is exactly what a dead man's switch watches for.
- A server is rebuilt and the crontab is not copied over.
- A worker crashes and the process manager gives up restarting it.
- A script starts failing on a full disk or an expired credential, so it exits before doing its work.
- A platform's scheduled function is paused after a billing change or a deploy.
How it works
- You create a monitor with an expected period: how often the job should run.
- The job calls the monitor's unique URL when it finishes successfully.
- If no call arrives within the period plus a grace time, the monitor opens an incident and alerts you.
- The next successful call resolves it.
In Upcertain this is a heartbeat monitor, with periods from 30 seconds to 30 days and a grace time of up to a day. Setup snippets for cron, Node.js, Python, PHP and GitHub Actions are in the heartbeat guide.
Choosing the period and grace
| Job | Period | Grace | Why |
|---|---|---|---|
| Queue worker reporting every minute | 1 min | 1 to 2 min | A worker loop is steady; alert quickly |
| Sync every 15 minutes, runs 1 to 5 minutes | 15 min | about 6 min | Covers the longest normal run |
| Hourly GitHub Actions workflow | 1 h | 15 to 30 min | Scheduled workflows can start late |
| Nightly backup, 20 to 50 minutes | 24 h | about 1 h | Long and variable run time |
| Monthly invoice run | 30 d | 1 d | Rare job; a day's slack is fine |
Grace should cover the longest normal delay before the job starts plus its longest normal run time. Too little, and a slow night pages someone; too much, and you hear late. Start generous, look at a week of real arrivals and tighten it.
Report success, not just existence
Call the URL at the end of the job, and only when it succeeds. In a shell that is job.sh && curl .... A heartbeat sent at the start proves the job began, not that the backup was written. If you also want to know about failures immediately rather than at the deadline, have the job call your error tracker on failure; the heartbeat covers the case where nothing runs at all.
Other uses
- Network reachability from inside. A machine on a private network that pings out every minute tells you it is up and online, even though nothing can reach it from outside.
- End-to-end pipelines. The last step of a data pipeline reports in, so a failure anywhere upstream shows up as a missing heartbeat.
- Third-party schedulers. Jobs run by a platform you do not control can still report to you.