Heartbeat monitoring watches for a regular signal from a job or service and alerts you when that signal is late or missing. Instead of your monitor reaching out to check something, the thing being watched reaches in to say "I ran." When the expected heartbeat does not arrive on time, the monitor raises an alarm. It is the only reliable way to catch a background job that fails silently, because a job that never runs cannot send an error.
Most monitoring is active: a checker somewhere loads your website or calls your API on a schedule and reports what it saw. That works for anything with a public address you can poke. It does nothing for the work that has no address, the scheduled jobs, cron tasks, backups, queue workers and data syncs that run on their own and finish without anyone watching. Heartbeat monitoring exists for exactly that blind spot.
What is heartbeat monitoring?
Heartbeat monitoring, sometimes called dead man's switch monitoring, works by expecting a signal on a schedule. You give the monitor a rule, "I will hear from this backup job every day by 2:15am", and the job sends a small HTTP request, the heartbeat or ping, each time it finishes successfully. As long as the pings keep arriving on time, the monitor stays quiet. The moment one is late past a grace period, it alerts you.
The logic is deliberately inverted. A normal check fails when it sees something wrong. A heartbeat check fails when it sees nothing at all. That difference is the whole point, because the worst job failures are the ones that produce no error, no log line, and no output. The job simply did not run, and silence is not something an active check can detect.
How does heartbeat monitoring work?
In practice it is three small pieces working together. Get them right and a job that quietly dies at 3am wakes you instead of surprising you a week later.
- A unique ping URL. The monitor gives you a URL for each job. Your job sends a request to it on success, usually one line added to the end of the script or a curl call after the command.
- An expected schedule. You tell the monitor how often to expect the ping, matching the job's own schedule, plus a grace period for a run that starts late or takes longer than usual.
- An alert when the ping is late. If the deadline plus grace passes with no ping, the monitor fires your alert over SMS, email, Slack or webhook, the same way an uptime alert would.
Better setups let the job ping twice: once when it starts and once when it finishes. That way the monitor knows the difference between a job that never started and a job that started but hung or crashed halfway, which points you at very different problems.
Heartbeat monitoring vs uptime monitoring
They are two halves of one coverage map. Uptime monitoring watches the things with an address; heartbeat monitoring watches the things without one. Neither replaces the other.
| Aspect | Uptime monitoring | Heartbeat monitoring |
|---|---|---|
| Direction | Monitor calls your service | Your job calls the monitor |
| Fails when | It sees an error or timeout | It sees no signal at all |
| Best for | Websites, APIs, servers, ports | Cron jobs, backups, queue workers, syncs |
| Catches | Outages, slow responses, bad content | Jobs that never ran or died silently |
A team that only runs uptime checks has a clean dashboard and no idea that its nightly backup stopped completing three weeks ago. A team that only runs heartbeats knows its jobs finish but not that its checkout is down. You want both, pointed at the right things, which is why most teams pair heartbeats with ordinary website uptime monitoring on the public-facing side.
alertping
Heartbeat checks for the jobs that fail without an error
AlertPing gives every scheduled job a ping URL and alerts you the moment a heartbeat is late, with SMS on every plan and 30-second uptime checks. One tool for the jobs with an address and the ones without.
What should you use heartbeat monitoring for?
Anything that runs on a schedule and matters when it stops. The common cases share a trait: nobody is watching them run, so a failure is invisible until something downstream breaks.
- Backups. The classic. A backup that silently stopped running is only discovered the day you need to restore, which is the worst possible day to learn it.
- Data pipelines and syncs. A nightly import that fails leaves stale data behind a perfectly healthy-looking app. Pairing a heartbeat with proper checks on data freshness and volume catches both the job that never ran and the run that produced garbage.
- Billing and invoicing runs. A scheduled charge job that skips a night is money not collected, and often nobody notices until reconciliation.
- Queue and worker processes. A worker that crashes and does not restart stops processing quietly. A heartbeat on each cycle catches the stall.
- Certificate and token renewals. A renewal cron that fails leaves you with an expired certificate days later, at which point it is an outage, not a warning. This is the case where a heartbeat and SSL expiry monitoring cover each other: one catches the failed renewal, the other catches the clock running out.
What makes heartbeat monitoring reliable?
The value is entirely in catching the silent case, so the setup has to be trustworthy in a few specific ways or it produces noise instead of signal.
- Ping only on success. If the job pings before it does its work, you learn it started, not that it worked. Send the heartbeat at the very end, after the job has done the thing that matters.
- Set a realistic grace period. Too tight and a normally slow run pages you for nothing. Too loose and a genuinely dead job goes unnoticed for hours. Match it to how late a healthy run can be.
- Alert off your own infrastructure. If the monitor that expects the heartbeat runs on the same server as the jobs, a server outage takes both down and no alarm goes out. The expectation has to live somewhere independent.
- Route to a channel people see. A missed backup at 3am is not urgent enough to page, but an email nobody reads for a week defeats the purpose. Slack or a low-priority SMS usually fits.
Is heartbeat monitoring the same as a dead man's switch?
Effectively, yes. A dead man's switch is any mechanism that triggers when an expected signal stops, and heartbeat monitoring is that idea applied to jobs and services. The name captures the logic well: the alarm is armed by silence, not by an error. We went deeper on the concept in what a dead man's switch is in monitoring, and on the practical setup in how to monitor a cron job. If you want the pattern set up rather than explained, that is what dead man's switch monitoring gives you.
The takeaway is small but easy to miss: your quietest failures are your most dangerous ones, because nothing announces them. Active checks cover the loud failures. Heartbeat monitoring covers the silent ones, and most teams do not add it until a backup they trusted turns out to have stopped weeks ago.