Cron monitoring, for the job that stops without saying so
A scheduled job that fails loudly is the easy case. The one that costs you is the job that simply stops being scheduled, because it raises nothing at all, and nothing that asks a server a question can see it.
The test is inverted, and that is the whole idea
Every other check on this site works the same way: we ask your site a question and read the answer. That model has one blind spot, and it is total. A job that does not run does not answer badly, it does not answer at all, and an absence of traffic looks exactly like a quiet night.
So the direction is reversed. Your script calls us when it finishes, and we watch for the call that does not come. The failure mode becomes something we can observe, because silence is now an event rather than the default.
The line at the end of your script
curl -fsS https://your-instance/beat.php?k=YOUR_KEY > /dev/nullAt the end, after the work. A script that crashes halfway never reaches this line, which is precisely what you want: the signal means the job finished, not that it started.
Late is not the same as gone
A backup that finishes twelve minutes late on a busy night is not broken, and alerting on it is how you teach someone to ignore alerts. Each monitor therefore carries two numbers rather than one: how often the signal is expected, and how much lateness is tolerated before anything is said.
| Setting | Default | Why that value |
|---|---|---|
| Expected interval | You set it | It is the schedule of the job itself, so nobody but you can guess it. |
| Tolerance | 5 minutes | Long enough to absorb a slow night, short enough that a job which skipped entirely is heard about the same morning. |
| Minimum tolerance | 30 seconds | A floor, not a preference: below it, ordinary clock drift between two machines becomes an outage. |
Both defaults are read from src/Heartbeat.php, counted on 3 August 2026. The alert text and the remedy live in src/Diagnose.php.
Where the others land on this
This is the one capability where the market is genuinely well served, and pretending otherwise would be the easiest thing on this page to disprove. UptimeRobot, Uptime Kuma and Site24x7 all offer it, and Uptime Kuma's push monitors are as good as ours.
What differs is what surrounds it. A heartbeat here is one monitor among the others on the same site, so a silent backup and a broken stylesheet arrive in the same queue, ranked together, with the same one-click actions. If you only need heartbeats, several free tools will do it, and the honest answer is to use one.
Questions people ask about scheduled jobs
Why can a monitoring tool not just check whether the job ran?
Because there is nothing to check. A cron job that does not run produces no request, no log line and no status code: it produces nothing at all, which is indistinguishable from a quiet night. Every check built on asking a server a question fails here, because the failure is the absence of an event rather than a bad answer to one.
What exactly do I add to my script?
One line at the end, after the work is done: a call to a URL that carries the monitor's own key. If the script exits early, crashes, or is never started, the line is never reached and the signal never arrives. That is the whole mechanism, and it is why the call belongs at the end and not at the beginning.
What happens if the job runs late rather than not at all?
Each monitor carries an expected interval and a tolerance, five minutes by default and never less than thirty seconds. A nightly backup that finishes twelve minutes late on a busy night stays silent; one that has not reported by the end of its tolerance raises the alert. The tolerance exists because a job that is occasionally slow is not a job that is broken, and alerting on it teaches people to ignore the alert.
Does this need a package, an agent or an outbound allowance?
It needs whatever your script already has to make one HTTP request, which on a shared host is curl or wget. There is no agent to install, no library to require, and nothing to keep updated: the call is a plain GET, and if your host blocks outbound HTTP the job could not have reached anything else either.
What does the alert tell me that a missing backup file would not?
When. A missing file tells you the backup is absent now; the signal tells you which run was the first to go missing, which is usually the same night something else changed on the server. The alert also names the job rather than the symptom, because the point of watching a scheduled task is to hear about it before the day you need what it produces.
Start with the site, the jobs follow
A heartbeat is one monitor on a site you are already watching. Point the free checker at an address first and see what a status code was covering for.