What Is Heartbeat and Cron Monitoring?
Your job calls the monitor instead of the monitor calling your job. Missing check-ins become the alert.
Heartbeat monitoring, also called cron monitoring or passive monitoring, works by having your job send a signal to a monitoring service each time it runs. If the signal does not arrive within the expected window, the monitor raises an alert.
The direction is what distinguishes it. Uptime monitoring is outbound, meaning a monitor calls your infrastructure and reports what came back. Heartbeat monitoring is inbound, meaning your infrastructure calls the monitor.
Why direction changes what you can detect
An outbound check can only test things that have a reachable address. A nightly database backup has no endpoint. There is nothing for a monitor to call, so no outbound check can ever tell you whether it ran.
An inbound check has the opposite property. Because the alert is triggered by absence, it fires when the job fails, when the server it runs on dies, when the scheduler was never restarted after a reboot, and when the network between the two breaks. None of those require the job to be healthy enough to report.
| Uptime monitoring | Heartbeat monitoring | |
|---|---|---|
| Direction | Monitor calls your service | Your job calls the monitor |
| Answers | Is it responding right now? | Did it run when it should have? |
| Needs an endpoint | Yes | No |
| Detects a dead server | Yes | Yes |
| Detects a job that never started | No | Yes |
| Detects a job that ran and did nothing | No | Only with explicit reporting |
| Typical setup | Enter a URL | Add one HTTP call to the script |
How it is set up
The monitor issues a unique URL for each job. You add a call to that URL at the end of your script, usually a single curl command, and configure the interval the monitor should expect it within.
Because the whole integration is one HTTP request, it works anywhere that can make one: bash, any language, Kubernetes CronJobs, GitHub Actions, Heroku Scheduler, or a no-code automation with an HTTP step.
The asymmetry is what makes it worth doing. Adding the check is a single line; without it, a job scheduled every 24 hours can fail on Monday night and stay broken until somebody happens to go looking for output that was never produced.
Start and finish pings
Pinging only at the end tells you whether the job finished. Pinging at both the start and the end tells you considerably more, because the monitor can then measure duration and detect a run that began and never completed.
That distinction matters for jobs that hang rather than crash. A process stuck on a network call it will never finish never reaches the final ping, and with only an end ping it looks the same as a job that never started.
Explicit failure reporting
Waiting for silence means waiting out the full interval plus the grace period before anything alerts. A job that already knows it failed can say so immediately, either by reporting a non-zero exit code or by posting a failure status in the request body.
This turns a loud failure into a fast alert while leaving the absence detection in place for the failures that produce no output at all. Most heartbeat services support one mechanism or the other.
The gap it does not close
A ping proves the script reached the line containing the ping. It says nothing about whether the work was correct. A nightly sync that fetched zero rows because an upstream API returned an empty array will ping exactly like a successful run.
Closing that gap requires the job to assert something about its output, which means sending the row count or record total alongside the ping and alerting when it falls outside an expected range.
Related concepts
The underlying pattern is a dead man's switch, and tuning the alert window is covered in what is a grace period. For background on the scheduler itself, see what is a cron job.