Glossary
Cron monitoring
Cron monitoring is checking that scheduled jobs actually ran, finished, and finished on time, usually by having each job ping a heartbeat URL.
Also called Cron job monitoring, Scheduled job monitoring, Batch job monitoring.
Cron monitoring is the practice of verifying that scheduled work actually happened. It exists because the failure mode of a scheduled job is silence: cron does not report to anyone, a job that never started produces no logs, and a host that rebooted takes its whole schedule with it. Nothing about the mechanism is designed to tell you when it stops.
The usual implementation is a heartbeat. The job sends a request to a unique URL when it finishes successfully; the monitor alerts if no request arrives within the expected window. That single mechanism catches all three interesting failures — the job that never ran, the job that crashed partway, and the host that went away — because they all produce the same silence.
In a crontab the ping is one more command on the end of the line: 0 2 * * * /opt/backup.sh && curl -fsS followed by the heartbeat URL. The && matters. curl runs only if the backup exited successfully, so a failed run stays silent and the monitor notices the silence. With the monitor expecting a ping every day and allowing an hour of grace, a night with no ping raises an alert a little after 3am, hours before anyone would go looking for last night's backup.
Two refinements are worth the effort on important jobs. Signal at the START as well as at the end and you can also detect a job that is still running long past its normal duration, which is a different problem from one that failed; on a tool that takes one signal per run, that takes a second heartbeat for the start. And make the success signal conditional on the work having actually been done — a backup script should send its heartbeat after checking that the file it wrote is a plausible size, not merely after the command returned zero.
| Failure | What cron shows | What the heartbeat monitor sees |
|---|---|---|
| Never started | Nothing: no run, no log | No ping by the deadline, so it alerts |
| Crashed partway | Perhaps a log line that nobody reads | No ping, because the job never reached the end |
| Host down or rebuilt | Nothing: the schedule went with the host | No ping, so it alerts |
| Ran but did no useful work | A clean exit | A ping, unless the job checks its own output first |
| Ran late | Nothing | A ping after the deadline, so it alerts and then recovers |
Questions
What is cron monitoring?
Checking that scheduled jobs ran and finished on time. Each job pings a unique URL when it succeeds, and the monitor alerts when a ping does not arrive within the expected interval plus a grace period.
How do I monitor a cron job?
Create a heartbeat monitor, copy its URL, and add a request to the end of the job so that it runs only on success, for example backup.sh && curl -fsS followed by the URL. Set the expected interval to the job's schedule, and add a grace period for its normal variation.
What grace period should a cron monitor use?
Longer than the job's worst normal run, plus a margin. A backup that usually takes twenty minutes and sometimes forty needs at least an hour. Too short and it pages on a slow night; too long and a failed run goes unnoticed for longer.
Why did my cron job not run?
The usual causes are a host that rebooted or was rebuilt without its crontab, a PATH or environment variable that cron does not set, a script that is not executable, and a schedule written for a different time zone. None of these produces an alert on its own, which is why the job needs to check in.
What is the difference between cron job monitoring and uptime monitoring?
Uptime monitoring reaches out to a service and asks whether it answers. Cron job monitoring waits for the job to reach out, and alerts on silence. A job on a private host that nothing can reach can only be monitored the second way.
In Uptimely
The Incoming Request monitor type covers this. Each monitor has its own /heartbeat/ URL, which accepts a GET or a POST, and an expected interval plus a grace period. If no request arrives in that window the monitor goes down and opens an incident, and the next request resolves it. There is one signal per run, with no separate start ping, so a job running far past its usual time looks the same as one that never finished. There is no separate cron product.
Uptimely gives each job its own heartbeat URL with an expected interval and a grace period, so a backup that silently stopped running raises an incident instead of a surprise.
Start monitoring free →Read next
Product feature
Related terms
Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.