The problem: a nightly backup takes 20 minutes on a normal night and 70 on a busy one
Our example is a nightly backup. On a normal night it finishes in about 20 minutes. When the database is busy, or when the upload to storage slows down, it takes closer to 70. Both nights end with a good backup. Only one of them looks different from the outside, and only if you are watching the clock.
Set the expected interval too tight and you get an alert on every busy night, for a job that did its work. Set it too loose and a job that stopped running on Tuesday stays quiet until someone notices the backups have gone stale. The setting you choose decides which of those you get.
What a heartbeat monitor expects: a ping from the job on a schedule
A heartbeat monitor works the other way round from a website check. It does not go and look at your job. It waits for your job to report in. You give the job a unique URL, the job calls it when it finishes, and the monitor records the time. If the ping does not arrive within the interval you set, the monitor treats the job as missing and sends an alert.
So the monitor only knows what you tell it. It knows that a ping was expected by a certain time, and that one did not come. It does not know why. That is why the interval and the position of the ping matter so much. The basics of creating a heartbeat are in our heartbeat monitor post, so this one picks up from there.
How to choose the interval: match the job's schedule, not your worst night
The expected interval should follow how often the job is meant to run. A backup that runs once a day gets an interval of 24 hours. A job that runs every hour gets 60 minutes. The schedule is the thing to match.
It is tempting to add the worst-case runtime on top, so the 70-minute night is covered. For most jobs, resist that. The interval is about when the next ping should arrive, and run length only shifts that arrival. A backup that starts at 02:30 and takes 70 minutes pings at 03:40. A daily interval still covers that comfortably, because the next ping is due about 24 hours later.
Where the job has a short cycle, run length matters more. If a job runs every 30 minutes and sometimes takes 25, the margin is small, and the interval should reflect the schedule with room to spare. Check the heartbeat settings on the monitor for the exact fields it offers, and set only what they describe.
Why a late ping is not always a failed job, and what to check first
A missing ping tells you that the job did not report on time. It does not tell you the job failed. Common reasons for a late ping include a slow run, a job queued behind another, a server that restarted, or a ping that failed because the network was briefly unavailable.
Before you change the interval, check three things. Did the job start at the time you expected? Does the job log show that it finished, or does it stop partway? Did the ping itself run? If the log says the backup completed and the ping line is missing, the fault is in the script, not the schedule.
Only after that is it worth asking whether the interval is wrong. If the same job is late every night, the interval or the schedule needs to change. If it was late once, that is usually an event to note, not a setting to fix.
Ping at the end of the job, not the start, and why
Put the ping at the end of the job. A ping at the start tells you the job began. It says nothing about whether the backup finished, which is the thing you care about.
A start ping can also hide a job that hangs halfway. The monitor sees a recent ping, marks the job healthy, and carries on. A ping at the end only arrives when the job has reached the end. If it stops partway, the ping never comes, and the monitor alerts you.
This is also why the ping should run only on success. If your command chains the backup and the ping with &&, the ping runs only when the backup exits cleanly. That is what you want.
A worked example with a cron line and a curl ping at the end
Here is a nightly backup set to run at 02:30, with the ping added at the end. Replace the placeholder with the URL the monitor gives you for that job.
30 2 * * * /usr/local/bin/nightly-backup.sh && curl -fsS -m 10 --retry 3 YOUR_HEARTBEAT_URL > /dev/nullThe && means the ping only runs if the backup exits successfully. The -fsS flags keep curl quiet on success and show errors if it fails. -m 10 stops the ping from hanging for long. --retry 3 gives it a few tries if the network blips.
Set the monitor's expected interval to 24 hours. The backup starts at 02:30. On a normal night the ping arrives around 02:50. On a busy night it arrives around 03:40. Both are well inside the window. A night where the backup crashes leaves no ping, so the alert comes.
What to do when the alert arrives: check the job log, then the server, then rerun
When the alert arrives, work in this order. First, the job log. Find last night's run and see whether it finished, failed, or stopped. The log will usually answer the question quickly.
Second, the server. Check that it was up at the scheduled time and that the cron job actually started. A server that rebooted at 02:25 will not run the backup at 02:30 unless something brings the job back.
Third, rerun the job by hand. Once you know the cause, run the backup manually and watch it finish. Its ping should arrive, and the monitor should record the job as healthy again.
Keep a short note of what you found. If the same alert keeps coming, the notes will show the pattern faster than memory will. For a team, put the note where the next person on call will look. Alert emails go only to people in your organisation, so the message reaches the team that owns the job.
The free plan includes 10 monitors, enough to put a heartbeat on each scheduled job. Start free at https://app.aperioflow.co.uk/#/signup.