The problem: a cron job that stops running makes no noise, so nobody notices
A cron job runs on a schedule with no one watching it. It backs up a database at two in the morning, sends invoices on the first of the month, or clears out old files every hour. When it works, nothing happens that anyone sees. When it stops, nothing happens either. There is no error on a screen and no message in an inbox. The gap only shows up when someone needs the file that was never made.
This is how small teams usually find out. A client asks for last week's data. A disk fills up and the backup folder has not changed since March. Nobody was told, because the job was never set up to say anything.
What a heartbeat monitor is: your job pings a URL when it finishes, and you get an alert if the ping does not arrive
A heartbeat monitor reverses the usual check. Instead of checking your server from outside, it waits for your job to report in. Your job makes a web request to a unique URL when it finishes successfully. The monitor records the time of each ping. If a ping does not arrive within the window you set, it raises an alert.
The job does not need to send anything meaningful. The ping is the signal. The monitor only needs to know that the job ran and reached the end.
It is worth being clear about what this covers. A heartbeat tells you that the job got to the final step and called the URL. It does not check that the output is correct. A backup file can exist and still be unreadable. A heartbeat is one layer of your checks, not the whole plan.
Worked example: a nightly database backup that pings when it completes
Say you run a small web app with a Postgres database. A script runs at 02:00 every night. It dumps the database to a file, copies that file to storage, and then finishes. The last line of the script is a request to your heartbeat URL.
Once that line is in place, each successful run sends a ping. The monitor sees a ping at about 02:05, then another the next night, and so on. If the server is rebooted, the disk fills up, or the cron entry is removed during a tidy-up, the script stops before that final line. No ping arrives. The monitor notices the silence and alerts you the next morning, rather than a client noticing weeks later.
Put the ping at the very end, after the copy has finished. That way a ping means the whole job completed, not just that it started.
How to set the expected interval and a sensible grace period
Two settings control when an alert fires: the expected interval and the grace period.
The expected interval is how often the job should run. For a nightly backup, that is 24 hours. For a job that runs every hour, it is 60 minutes.
The grace period is the extra time you allow before deciding the job has missed its run. Jobs vary. A backup might take eight minutes on a quiet night and 25 minutes when the database is larger. If the grace period is too short, you will get false alarms, and people start ignoring them. A sensible starting point is at least 15 minutes for anything that runs in the small hours, or 10 to 20 per cent of the interval for shorter jobs. After the first week, adjust it to match how long the job really takes.
Keep the interval matched to the schedule. Do not set it to how quickly you want to hear about a problem. A nightly job with a one-hour interval will alert you every night.
What to do when the alert arrives: check the schedule, the logs and the last successful run
An alert means the ping did not arrive in its window. It does not tell you why. Work through three checks in order.
First, check the schedule. Is the cron entry still there? Did the server's time zone change, or did someone edit the crontab? Run crontab -l and confirm the line is present and the time is what you expect.
Second, check the logs. Look at the output from the last run. Did the script fail partway through? Did it hit a permissions error, run out of disk space, or fail to reach storage? The log usually shows where it stopped.
Third, check the last successful run. Compare the time of the last ping in the monitor with your backup folder. If the last ping was two days ago but the backup file is from yesterday, the job may be running and failing at the final step. If both are old, the job has stopped altogether.
Then fix the cause, run the job by hand, and confirm the ping arrives. Do not simply silence the alert.
Add a heartbeat to your backup job so a missed backup is the first thing you hear about
Backup jobs are where heartbeats earn their place. A backup that fails silently looks the same as one that works, until you try to restore. A ping turns a silent failure into an alert on the day it happens.
Keep the ping on its own line at the end of the script, so it runs only after the earlier steps have finished. In a shell script with set -e, a command that fails stops the script before the ping is reached. Test it by making one step fail on purpose and checking that no ping arrives.
A heartbeat is not a substitute for testing restores. A ping proves the job finished. It does not prove that the file can be read back. Restore a copy to a spare machine on a regular schedule, and treat that as a separate task with its own reminder.
How to set one up in AperioFlow, using the free plan with 10 monitors
In AperioFlow, create a heartbeat monitor and give it a name that says what the job does, such as "Nightly Postgres backup". Set the expected interval and grace period as described above. The monitor gives you a unique URL. Copy it into your script or cron job.
Run the job once by hand to confirm that the ping arrives and the monitor shows a recent check-in. Then leave it to run on schedule.
Alert emails go only to people in your organisation, so add the people who should hear about a missed backup. The free plan includes 10 monitors. For most solo developers and small client setups, that covers the nightly jobs, backups and key sites that matter most.
Short checklist: which jobs on a small team deserve a heartbeat
Give a job a heartbeat if:
- it runs unattended, on a schedule, with no one watching it
- a missed run would cause a visible problem for a client or customer within a day or two
- it is the only copy of something, or it is the step that makes a copy
- it sends something out, such as invoices, reminders or reports
- it cleans up or rotates files, so a failure fills a disk slowly
Jobs you run by hand do not need one. Neither do tasks where a missed run costs nothing and nobody would ever notice.
If you have a backup or cron job that nobody is watching, start free at https://app.aperioflow.co.uk/#/signup and add a heartbeat monitor to your next cron job. The free plan includes 10 monitors.