To monitor a cron job, you invert the direction of the check: instead of a monitoring service polling the job, the job pings the monitoring service every time it finishes successfully. This is called heartbeat monitoring, or a dead man's switch. You give the monitor an expected period and a grace period; if the ping does not arrive in that window, you get paged. It is one line of curl at the end of the job, and it is the only technique that catches a cron job which never ran at all.
Why cron jobs fail silently
A web server is easy to monitor because it answers. A cron job answers nothing. It runs at 3am on a box nobody is watching, and when it stops running it produces exactly the same amount of noise as when it succeeds: none. Hence the backup story every company has. The dump job started failing in March, nobody found out until the restore in July, and those four months of history looked identical to four clean ones.
The three approaches people reach for first share one defect:
-
MAILTO in the crontab. Cron emails you the job's output. In practice
the mail is swallowed by a misconfigured local MTA, lands in a folder nobody opens, or
is so noisy that everyone filters it. Worse, MAILTO only reports output from a job that
ran. If the cron daemon is dead, the box is off, or someone's
crontab -rwiped the file, there is no output, so there is no mail. Silence looks identical to success. - Checking exit codes in a wrapper script. Better, because you react to failure rather than to text. But the wrapper only helps if the wrapper runs. Kill the machine, the container or the cron daemon, and your careful error handling never executes. Silence again.
- Logging to a file. A log is a record, not an alarm. It works only if a human reads it, on a schedule, forever. Nobody does this.
The line worth remembering: with cron, the absence of a failure signal is not evidence of success. Only a positive success signal proves the job ran. Every approach above hunts for failure. Heartbeat monitoring watches for missing proof of success instead, which covers every way a job can die without saying a word.
How heartbeat monitoring works
The mechanics take about two minutes, in any language, on any host:
- Create a heartbeat monitor with an expected period (every 24 hours, hourly, a cron expression) and a grace period (how late is still acceptable).
- The monitor hands you a unique ping URL.
- Your job requests that URL as its last action, and only if everything before it succeeded.
- If no ping arrives within the period plus the grace, the monitor alerts you.
The ping is an outbound HTTPS request, so the job can sit behind a firewall or on a private subnet and still be monitored. And because the monitor lives somewhere else entirely, it keeps watching when your infrastructure does not. On a server you provision and deploy to yourself, the cron daemon is one more service that can quietly stop, and a monitor running on the same box would stop with it. That is the dead man's switch monitoring principle: the alarm fires because the system stopped reporting, not because it managed to report a problem.
The one-line version: a crontab that pings on success
crontab -e ▸ nightly backup, 3am
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://hb.alertping.com/p/YOUR-MONITOR-KEY > /dev/nullThat is a complete cron monitoring setup. The curl flags each stop a specific bad behavior:
-ftreats an HTTP error (a 500 from the monitoring service) as a failed command, instead of succeeding with an error page as the body.-ssilences the progress meter, which otherwise generates a pointless cron email every night.-Sputs real errors back on stderr, so an undeliverable ping still surfaces. Use-sand-Stogether, always.-m 10caps the request at 10 seconds, so a hung connection cannot leave a cron process alive until the next run collides with it.--retry 3retries transient network errors. A dropped packet should not page you at 3am.> /dev/null(or-o /dev/null) discards the response body. Same reason as-s: no output, no cron mail.
The mistake everyone makes: && versus ;
The && in that line is the entire point of it. In a POSIX shell,
a && b runs b only if a exited 0, so the
ping happens only when the backup actually worked.
Write ; instead and the shell runs the ping unconditionally: the backup can
explode, exit 1, corrupt its output, and the heartbeat still lands on time. That is
monitoring which reports green while the job burns, worse than no monitoring, because it
buys you confidence you have not earned. Same trap in a pipeline:
backup.sh | tee log.txt returns tee's exit status, not the
backup's, unless you set pipefail. Check the character. It is the most common
cron monitoring bug, and it is silent by construction.
A wrapper that signals start, success and failure
The one-liner catches a job that did not run. It does not catch a job that started and then hung (what a database dump does when it blocks on a lock), and it does not measure duration. Send three signals instead of one: a start ping, a success ping, and a failure ping carrying the output.
/usr/local/bin/run-backup.sh
#!/usr/bin/env bash
set -uo pipefail
PING="https://hb.alertping.com/p/YOUR-MONITOR-KEY"
# 1. Signal the start. This starts the duration clock and lets the
# monitor alert on a job that begins but never finishes.
curl -fsS -m 10 --retry 3 -o /dev/null "$PING/start"
# 2. Do the real work. Capture output so a failure can carry it.
OUTPUT=$(/usr/local/bin/backup.sh 2>&1)
CODE=$?
# 3. Report the outcome, and only the truthful one.
if [ "$CODE" -eq 0 ]; then
curl -fsS -m 10 --retry 3 -o /dev/null "$PING"
else
printf '%s' "$OUTPUT" \
| curl -fsS -m 10 --retry 3 -o /dev/null --data-binary @- "$PING/fail"
fi
exit "$CODE"
set -e is deliberately absent: with it, the script would exit the moment
backup.sh failed and never send the failure ping, which is precisely the ping
you care about. The monitor now knows three things it could not know before: that the job
started, that it finished, and how long it took.
Laravel: the scheduler already has hooks for this
If your jobs run through the Laravel scheduler rather than raw crontab, you do not need
a wrapper. The scheduler exposes ping hooks on every task, in
routes/console.php on Laravel 11 and up, or app/Console/Kernel.php
on older versions:
routes/console.php
$schedule->command('backup:run')
->dailyAt('03:00')
->pingOnSuccess('https://hb.alertping.com/p/YOUR-MONITOR-KEY')
->pingOnFailure('https://hb.alertping.com/p/YOUR-MONITOR-KEY/fail');
// Long job? Bracket it to capture run duration:
$schedule->command('reports:build')
->hourly()
->pingBefore('https://hb.alertping.com/p/OTHER-KEY/start')
->pingOnSuccess('https://hb.alertping.com/p/OTHER-KEY');
pingOnSuccess() fires only on a zero exit code: the &&
semantics from earlier, enforced by the framework. Its sibling thenPing()
fires regardless of outcome, so treat it the way you treat ;. These
hooks need Guzzle. One catch: the scheduler cannot monitor itself, because every hook
depends on the single schedule:run cron entry firing. Put a heartbeat on an
everyFiveMinutes() task and you are also monitoring the scheduler, and
therefore cron, and therefore the box.
Kubernetes CronJobs: identical principle
A Kubernetes CronJob gives you retries and pod logs, and still no alarm when
the controller is wedged or the image pull fails. Same fix, at the end of the container
command:
k8s ▸ cronjob.yaml
spec:
schedule: "0 3 * * *"
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: backup
image: registry.example.com/backup:1.4
command: ["/bin/sh", "-c"]
args:
- /usr/local/bin/backup.sh &&
curl -fsS -m 10 --retry 3 -o /dev/null
https://hb.alertping.com/p/YOUR-MONITOR-KEYalertping
Give every scheduled job a heartbeat
Create a monitor, paste one curl line, pick a grace period. The first night the backup skips, your phone knows. SMS, Slack, email and webhooks are included on every plan.
Choosing the period and the grace period
This is where teams either get quiet, trustworthy alerts or train themselves to ignore the pager. The period is when you expect the ping. The grace is how much lateness is normal. Set the grace from the worst run you have actually seen, not the average one. A nightly backup that usually takes 12 minutes will, on the night someone bulk-imported a million rows, take 40. A 15-minute grace pages you at 3:15am for a healthy job that finished at 3:40. Do that twice and the team mutes the channel.
| Job | Period | Grace | Why |
|---|---|---|---|
| Nightly backup (12 min typical) | 1 day | 30 to 60 min | Absorbs the heavy night, still tells you before breakfast. |
| Hourly sync | 1 hour | 10 to 15 min | About a quarter of the period: room for jitter and a retry, but you never miss two runs. |
| Every-5-minute queue worker | 5 min | 5 to 10 min | Never page on one skipped tick. One to two periods catches a real stall in about 10 minutes. |
| Weekly report (Mondays) | 7 days | 2 to 6 hours | Nobody reads it before standup, so hours of grace cost nothing and remove every false page. |
Rule of thumb: grace should exceed your worst observed run time, and for short-period jobs it should be at least one full period. If you keep shrinking the grace to catch failures faster, the real problem is a job whose run time is drifting.
Monitor the work, not just the exit code
A heartbeat proves the process ran and exited 0. It does not prove it did anything useful. This is the failure mode that survives naive cron monitoring:
- The zero-row success. The sync job's API credentials expired. It fetched an empty list, wrote zero rows, exited 0, and pinged cleanly for three weeks while dashboards rendered stale numbers. Green board, dead pipeline.
- The empty backup.
pg_dumpexited 0 but the disk filled, so the file is 4KB. The heartbeat cannot tell. - The creeping duration. A job that took 4 minutes in January takes 55 now. It has not failed yet. It will, the first time two copies overlap on the same table.
Make the job assert on its own output before it pings. Have the script fail itself when the
result is nonsense, and let && do the rest:
assert ▸ a backup smaller than 10MB is not a backup
pg_dump mydb | gzip > /backups/db.sql.gz
SIZE=$(stat -c %s /backups/db.sql.gz)
if [ "$SIZE" -lt 10000000 ]; then
echo "dump is only $SIZE bytes, refusing to report success" >&2
exit 1
fiNow the heartbeat means something specific: not "a process exited 0" but "a backup of plausible size exists". Duration is the other half. The start and success pings bracket the run, so a job whose median run time doubles over a month warns you weeks before the outage. Pair the heartbeats with a server monitoring tool watching disk and memory on the same box, and the cause is usually right there in the graph.
How do I know if a cron job ran?
Have the job tell you. Add a curl to a unique heartbeat URL at the end of the crontab
line, after &&, so it fires only on exit code 0. If the ping arrives,
the job ran and succeeded. If it does not arrive in the expected window, you are alerted.
Grepping syslog only proves cron tried to start it.
How do I monitor a cron job?
Use heartbeat monitoring. Create a monitor with an expected period and a grace period,
get its unique ping URL, and append && curl -fsS -m 10 --retry 3
https://hb.alertping.com/p/YOUR-KEY to the job so it pings only on success. When a
ping is missed, the service alerts you by SMS, Slack, email or webhook. No agent, and it
works behind a firewall.
What is a dead man's switch in monitoring?
A dead man's switch is a monitor that alerts when a signal stops arriving, rather than when an error is reported. The name comes from train controls, where releasing the lever stops the train. Applied to cron: your job checks in on every successful run, and silence triggers the alarm. It catches failures that can never announce themselves.
Why do cron jobs fail silently?
Because cron has no concept of an expected outcome. It fires a command and forgets it. Failures land in mail nobody reads or logs nobody opens, and a job that never runs (dead daemon, wiped crontab, powered-off box, PATH change) produces no output at all. Silence and success look identical from outside, so nothing surfaces until someone needs the result.
Where this fits
Uptime checks tell you the front door is open. Heartbeats tell you the work behind it is still happening. Most teams build the first, skip the second, and find the gap on restore day. AlertPing's cron job monitoring is the heartbeat side: a unique ping URL per job, a schedule and grace period you set, and the same downtime alerts and escalation chains as every other check, on every plan from $19 a month. It sits alongside the checks in how to monitor website uptime, because a backup that stopped running six weeks ago is an outage too. You just have not had it yet.