Cron Monitoring in 2026: Dead Man's Switch Patterns for Scheduled Jobs
The worst outage I've ever shipped wasn't a crash. It was a backup job that quietly stopped running for eleven days. Nothing errored. Nothing paged anyone. The cron line was still in the crontab, the server was up, the disk wasn't full — the job just… didn't fire, because an upstream change had made the script exit 0 before doing any work. We found out when we went to restore. The backups were the restore.
This is the thing about scheduled jobs that regular monitoring misses: your alerting is built to catch things that happen, and a cron failure is a thing that doesn't happen. An HTTP endpoint that 500s trips a check. A cron job that never runs trips nothing — there's no request, no log line, no error to catch. You need a monitor that gets suspicious about silence.
That pattern has a name: the dead man's switch. The job is supposed to check in on a schedule; if the check-in doesn't arrive on time, that absence is the alert. Full disclosure up front: I built one of these tools (CronCanary), so I'll be explicit about where it wins and where the others are the better call.
How a dead man's switch actually works
You take a job like this:
0 3 * * * /usr/local/bin/backup.shand you make it ping a URL on success:
0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://ping.example/abc123The monitor knows the job should check in every 24 hours (plus a grace window). If 3am passes and no ping lands by, say, 3:30, it alerts you. Two failure modes are now covered for the price of one line: the script broke (it never reached the curl), and the script never ran at all (cron daemon died, container got rescheduled, someone commented out the line "just for a sec" three months ago). The && matters — it means the ping only fires if backup.sh actually succeeded.
The more robust version also signals start and failure explicitly, so you can tell "still running, slow" apart from "died halfway":
curl -fsS https://ping.example/abc123/start
/usr/local/bin/backup.sh && curl -fsS https://ping.example/abc123 || curl -fsS https://ping.example/abc123/failEvery tool below implements this same core idea. They differ in where they're hosted, how much they cost, and how much they pile on top.
The honest summary
Healthchecks.io if you want open source you can self-host, or a generous free tier you don't have to think about. The reference implementation of the pattern.
Cronitor if your cron monitoring is one tab of a bigger uptime/APM story and you want it all in one dashboard.
Dead Man's Snitch if you want the most focused, no-frills version of exactly this one idea, with a great name.
CronCanary (ours) if you want dead-man's-switch monitoring that's dead simple to wire up, priced for indie/small-team budgets, and not bundled into a platform you didn't ask for.
Where Healthchecks.io wins
It's open source, and that's not a footnote. If you have a compliance reason to keep monitoring in-house, or you simply don't want a third party in the path of knowing whether your jobs run, you can docker run the whole thing. The hosted free tier is also genuinely usable for a personal server's worth of jobs — this is the tool I recommend to people who ask "what's the no-commitment option?"
The check semantics are mature. Start/success/fail signals, configurable grace periods, cron-expression schedules (not just "every N minutes"), and integrations into basically every notification channel that exists. Years of edge cases are already handled.
Where it stops: self-hosting means you now operate the thing that watches your other things — and a monitor that's down during your outage is worse than no monitor, because it lulls you. On the hosted side, scaling past the free tier into many jobs and team features is where you start comparing price sheets.
Where Cronitor wins
Cron monitoring inside a fuller observability product. Cronitor does heartbeat/cron checks and uptime checks and has a metrics/APM side. If you'd rather have one vendor and one dashboard for "is the website up" and "did the nightly job run," consolidating there has real operational value — fewer tabs, one on-call integration to configure.
Good ergonomics around environments and teams. Grouping checks, per-environment config, and team alerting are first-class, which matters once you're past a handful of jobs.
Where it stops: if all you need is "tell me when my three cron jobs stop checking in," you're buying a platform to use one feature of it. That's the right trade for some teams and overkill for others.
Where Dead Man's Snitch wins
It does one thing and refuses to do more. A "snitch" is a URL; your job pings it; if the ping doesn't arrive on schedule, you get told. That's the entire product, and the focus is the feature. The name alone has probably sold more subscriptions than any feature comparison, and honestly it earns it — it's the canonical "I just want the dead man's switch" answer.
Frictionless setup. Create a snitch, copy the URL, paste it after your command. You're monitored in under a minute, which is the whole point of a tool you reach for when you finally got burned by a silent failure.
Where it stops: the simplicity cuts both ways — if you later want richer schedule semantics or it to be part of a broader monitoring picture, you'll be adding more tools around it.
Where CronCanary wins (and where it doesn't)
I built CronCanary after the eleven-days-of-no-backups incident, and after watching the same gap bite a swarm of automation I run that lives entirely on cron — loops that fire on a schedule and recover themselves, where "the loop silently stopped" is the failure I lose sleep over. I wanted the Dead Man's Snitch ergonomics (one URL, paste after your command, done) without either self-hosting a monitor or paying platform pricing for one feature.
Setup is a single ping URL, same as the others. Create a check, get a URL, append && curl -fsS <url> to your cron line. Start and fail endpoints are there when you want to distinguish "running long" from "died." No agent to install, nothing on your box to keep alive.
Priced for the indie/small-team reality. The whole reason this category exists is people getting burned on jobs that matter — backups, billing runs, data syncs — and those people are very often solo devs and tiny teams, not enterprises. CronCanary is built to be the affordable "yes, just monitor my jobs" option rather than the entry tier of a pricier suite.
Where it doesn't win: if you need an in-house, audited, self-hosted monitor, run Healthchecks.io — that's its home turf and I won't pretend otherwise. If you want cron checks and uptime and APM under one roof, Cronitor is the consolidation play. CronCanary is deliberately the focused, affordable dead-man's-switch — that's the job it's for.
The decision tree
"I want open source / self-hosted, or a no-commitment free tier." → Healthchecks.io.
"I want cron monitoring as part of a full uptime + APM platform." → Cronitor.
"I want the most focused, iconic version of just this one idea." → Dead Man's Snitch.
"I want simple, affordable dead-man's-switch monitoring without a platform attached." → CronCanary.
The thing nobody tells you about cron monitoring
The hard part isn't picking a tool — they all implement the same pattern competently. The hard part is the discipline of deciding, for each scheduled job, what "didn't run" should cost you, and setting the grace window to match. A nightly backup that's six hours late is fine; a billing run that's six hours late might mean customers got double-charged or not charged at all. Too tight a window and you'll train yourself to ignore the alerts; too loose and you've recreated the eleven-day silence with extra steps.
So before you wire up any of these: list your scheduled jobs, and next to each one write the honest answer to "how long can this be silently dead before it's a real problem?" That number is your grace period, and it's the actual product. The ping URL is just plumbing — which is exactly why the right tool is whichever one makes the plumbing disappear so you can think about the number instead.