Uptime monitoring answers “is my site up?” Heartbeat monitoring answers a harder question: “did my backup actually run last night?”

The difference matters because the worst failures are silent. A crashed web server throws errors somewhere. A cron job that stopped running throws nothing — no error, no log line, no alert. The machine rebooted three weeks ago, cron never came back, and you find out when you need the backup that doesn’t exist.

Heartbeat monitoring (also called a dead man’s switch) inverts the usual model. Instead of a monitor checking your service, your job checks in with the monitor. Every successful run sends a ping. If the pings stop arriving within the expected window, that’s the alert.

#The basic pattern

Your job pings a URL after it succeeds:

# crontab: run the backup, then check in — but only if it worked
0 3 * * * /home/me/backup.sh && curl -fsS https://your-monitor/ping/backup

The && is the whole trick: the ping fires only on success. The monitor knows the backup runs daily; if 24 hours (plus some grace) pass without a ping, it notifies you.

That’s the entire concept. The subtleties are where implementations differ.

#The pitfalls

Grace windows. A backup that usually takes 10 minutes will someday take 90. If your window is exactly 24 hours, that day produces a false alarm — and false alarms at 3am are how people learn to ignore monitoring. Set the window to the interval plus real slack.

Pinging before the work. A ping at the start of the job tells you cron fired, not that the job worked. Ping after, gated on success. (Some tools support start-and-finish pings so you also catch jobs that hang.)

Multiple sources, one name. If two servers ping the same heartbeat, one can die and the other keeps the heartbeat green. Either give each source its own name, or make sure your tool tracks them separately.

The monitor watching itself. The heartbeat service must not run on the infrastructure it’s watching. If the alert channel lives on the box that died, silence looks exactly like health. This is the one place self-hosting works against you.

#Tools

healthchecks.io is the established service in this category — ping URLs per check, period + grace configuration, a generous free tier, and it’s open source if you want to self-host (with the caveat above). It delivers alerts to email out of the box; getting them to your phone means wiring an integration on top.

Cronitor and Dead Man’s Snitch are the commercial takes on the same idea.

#Where trigger.fyi fits

trigger.fyi is a push notification service for developers — one curl call, notification on your phone. Heartbeats are coming as a first-class primitive with the same shape as the rest of the API:

fyi.heartbeat("db-backup", { every: "24h" });

One line inside the job. The server keeps a timer per heartbeat name; any ping resets it; if the window passes in silence, your phone gets the notification — the same pipe that already delivers your cron alerts and deploy notifications.

Heartbeats aren’t live yet — we’re building the delivery layer to be boringly reliable first, because a false “your backup missed its check-in” costs more trust than the feature earns. You can see everything else working today with a single curl.

Related: Cron job notifications · Send from curl · Monitoring without dashboards · What is trigger.fyi