Uptime monitoring answers "is my site reachable?" — and it is genuinely useful. But a whole class of failures produces no downtime at all: the nightly backup that never ran, the invoice batch that did not fire, the data sync that silently stopped on the 4th of the month. Nothing is down; something just quietly stopped happening. This article covers the standard fix — heartbeat monitoring — and compares the main options in 2026, from Healthchecks.io, which popularized the model, to self-hosted clones and all-in-one platforms that now include it.
The Dead Man's Switch, Explained
The idea is simple and clever: instead of watching for something to fail, you require it to report in.
- You register a heartbeat URL for the job.
- Your cron entry ends with
&& curl -fsS https://your-monitor/hb/abc123 > /dev/null. - If the check-in does not arrive within the expected schedule, you get alerted.
The inversion matters: you are not detecting an error, you are detecting absence. That is the only reliable way to catch a job that never started, a script that crashed before reaching the network, or a scheduler that died silently. Backup jobs are the canonical case — discovering at restore time that backups stopped six weeks ago is a rite of passage nobody needs twice.
The Options in 2026
Healthchecks.io is the best-known hosted implementation. It is focused, fairly priced, open source (self-hostable), and does exactly one thing. If heartbeat monitoring is all you need, it is a reasonable default, and the self-hosted variant keeps data in-house.
Self-hosted clones (healthchecks, and various cron-watch scripts) give you the same model on your own server — with the usual trade-off that you now monitor the monitor.
All-in-one platforms have been absorbing the feature. Tools like Cronitor specialize in it; broader platforms have added heartbeat checks alongside uptime and alerting. Wakeless (a self-healing monitoring service for indie developers) takes it a step further in one specific dimension: when a monitored system around the cron job breaks — the process is dead, the disk is full, the service crashed — it can remediate automatically, not just notify. If your nightly job fails because the database is down, a pure heartbeat service tells you; a self-healing platform can bring the database back and the next run succeeds.
Choosing Between Them
| Dimension | Healthchecks.io / self-hosted | All-in-one (e.g. Wakeless) |
|---|---|---|
| Heartbeat / dead man's switch | ✓ (core feature) | ✓ |
| Uptime, SSL, port checks | ✗ (not its job) | ✓ |
| Auto-remediation of root cause | ✗ (notify only) | ✓ (whitelisted actions) |
| Multi-region uptime | ✗ | ✓ |
| Self-host available | ✓ | ✗ |
| Cost | Free–low | Free tier; paid from ~$13/mo |
| Best fit | "I only need heartbeats" | "I want one pane for checks + fixes" |
The honest recommendation: if your monitoring needs start and end at "tell me when a cron job skips", a dedicated heartbeat service is the simplest, cheapest answer — there is no shame in a single-purpose tool. If you are accumulating three tools (uptime checker, heartbeat service, an SSH alias for manual fixes) and paying for each, an integrated self-healing platform consolidates the stack; the free tiers make it easy to verify on your own jobs before paying anything.
Start With the Two Jobs That Matter Most
Whichever you pick, wire heartbeats into your backup and any billing/invoicing job first. Those two failures compound silently for weeks. Everything else can follow incrementally — a heartbeat is one curl appended to a cron line.
Originally published on the Wakeless blog — self-healing server monitoring for indie developers.
Top comments (0)