Monitoring cron jobs: how to notice when jobs die silently.
Updated July 11, 2026 · 6 min read
A failed web server gets noticed quickly. A failed backup gets noticed when you need it, which is the most expensive possible moment. Cron jobs fail silently: no error on the website, no alert, just silence. The heartbeat pattern makes that silence audible.
Contents
Why cron jobs die silently
The typical causes are unspectacular: a full disk, expired credentials, a deleted or commented-out crontab line, a server migration that left the job behind, or a script that has been exiting with an error since the last update.
Classic website monitoring sees none of this, because the website itself is fine. You need monitoring that fires when something does NOT happen.
The heartbeat pattern
A heartbeat monitor reverses the direction: your job reports in after every successful run with a short HTTP request to a unique ping URL. The monitoring service expects that report on a defined schedule, for example daily with some tolerance (grace period). If it stays out, you get alerted.
The charm of it: it does not matter WHY the job did not run. Crontab gone, server off, script broken, the missing ping catches every cause with a single mechanism.
Set up in one line
Append a curl call to the ping URL at the end of your cron job. Important: chain it with && so the ping only fires on SUCCESS:
0 3 * * * /usr/local/bin/backup.sh && curl -fsS --retry 3 https://uptime.clesk.space/ping/YOUR-TOKEN >/dev/nullThe common pitfalls
These details are where heartbeat setups fail in practice:
- ; instead of &&: with a semicolon the job pings even on failure, and monitoring reports a false "all good". Always use &&.
- Grace period too tight: a backup that occasionally takes 20 minutes longer is not an outage. Choose the grace period well above normal variation.
- Time zones: cron runs in the server time zone, monitoring usually thinks in UTC. Configure the expected schedule accordingly.
- Swallowed curl errors: -fsS makes curl fail loudly on HTTP errors and stay quiet on success; --retry 3 bridges short network blips.
- "Job runs but does nothing": the heartbeat only confirms THAT the job completed. Whether the backup is usable is a separate check, e.g. a size check or restore test inside the script, before the ping.
Which jobs deserve a heartbeat
Rule of thumb: everything whose silent failure costs you money or data.
- Backups (database and files), the classic
- Imports/exports and integration syncs (inventory, feeds, newsletter lists)
- Invoice and report runs
- Certificate renewal jobs (certbot renew)
- Queue workers and cleanup jobs nobody ever looks at
Frequently asked questions
What if my job takes a varying amount of time?
That is what the grace period is for: if you expect the ping daily, allow e.g. 6 hours of tolerance. The alert only fires once schedule plus tolerance are exceeded.
Does this work with systemd timers or Windows Task Scheduler?
Yes. All that matters is that an HTTP request hits the ping URL after a successful run, which works from any scheduler, any language and any CI system.
How many heartbeat monitors do I need?
One per job you would miss. With Clesk Uptime, heartbeats are included in Pro and set up in two minutes: name, expected schedule, grace period, done, and you get your ping URL.
Your backup deserves a watchdog.
Create a heartbeat monitor, append the curl line, sleep well. Included in Pro.
Monitor for free