How to Monitor a Scheduled Backup With a Heartbeat

Cron backup heartbeat monitoring is one of those things nobody sets up until they need it. The nightly backup has run fine for years. Then someone migrates the server, the crontab doesn't come along, and backups quietly stop. Nobody finds out until the day they need to restore.

A heartbeat fixes exactly that: it makes the silence of a scheduled job impossible to miss. Here's how to set one up, what it catches, and, just as important, what it doesn't.

Why backups fail silently

A failed backup rarely shows an error anywhere a person will see it. The usual causes:

• The cron job disappeared. A migration, a reinstall, or a change of user left the crontab empty.
• The disk filled up. The backup starts and has nowhere to write.
• A credential changed. The database password or the storage access key no longer works.
• The script hangs. It waits on a response that never comes and never finishes.
• The server was off at the scheduled time.

In every case the result is the same: the job doesn't finish, and nobody's looking.

How a heartbeat works

A website monitor goes out and fetches your page. A heartbeat works the other way around: your job calls a unique URL when it finishes. If the call arrives on time, all good. If it doesn't, the monitor goes down and you get an alert.

What's being watched is the silence. Nothing gets installed on your server; one HTTP request is enough.

Step by step

1. Create a heartbeat monitor in MonitoraWeb. You get a URL with a secret token, like https://app.monitoraweb.com/hb/YOUR_TOKEN.
2. Set the interval. If the backup runs once a day, the interval is one day.
3. Set the grace period. That's the extra time you'll tolerate before raising an alarm. If the backup usually takes 20 minutes but sometimes an hour, a two-hour grace period avoids false alarms.
4. Add the call at the end of the job, so it only fires when the backup succeeded:

0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 https://app.monitoraweb.com/hb/YOUR_TOKEN

The && means curl only runs if the script exited cleanly. -m 10 keeps the ping itself from hanging.

5. To report failures immediately instead of waiting out the deadline, call the same URL with /fail appended when the script fails:

0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 https://app.monitoraweb.com/hb/YOUR_TOKEN || curl -fsS -m 10 https://app.monitoraweb.com/hb/YOUR_TOKEN/fail

6. Test it. Run the job by hand once and confirm the monitor receives the ping. If you can, force a failure and watch the alert arrive.

If you need help writing the schedule itself, the free cron expression generator builds it for you.

Make the script check its own work

A heartbeat only knows what your script tells it. If the script exits "successfully" with an empty file, the ping still goes out. So have the script verify the basics before calling the backup good:

• The file exists and isn't zero bytes.
• The database dump ends with the completion marker your dump tool writes.
• The upload to off-site storage returned success.

Only when all of that passes should the script exit with code 0 and let && send the ping.

What a heartbeat doesn't verify

To be clear: a heartbeat doesn't prove the backup is usable. We know the job finished and called in. We don't open the file, decompress it, or restore it. A corrupted, incomplete, or encrypted-with-a-lost-key backup can send its heartbeat just fine.

The only way to know a backup works is to restore it. Do that periodically in a separate environment and note how long it takes, because that's your real recovery time.

Other limits:

• If the server can't reach the internet, the ping won't arrive even though the backup ran.
• The alert tells you the signal didn't arrive, not why. The cause is on your server.
• We don't read the job's logs or measure how long it ran.

Alerts

When the interval plus grace period passes with no ping, the monitor goes down and alerts your list's channels: email, plus WhatsApp, Slack, Microsoft Teams, Discord, Telegram, or a signed webhook on paid plans. Everything a heartbeat does, and its limits, is on cron job monitoring.

Frequently asked questions

Does the heartbeat know whether my backup is valid?

No. It knows the job finished and called in. Confirming the backup can be restored is a separate task worth doing regularly.

What grace period should I use?

Enough to cover your slowest days. Look at how long the backup takes on its worst day and add some margin.

Do I need to install anything on the server?

No. curl, wget, or any way of making an HTTP request at the end of the job is enough.

What if the backup fails but the script doesn't notice?

The ping goes out anyway. That's why the script should check the file size or upload result before exiting successfully.

Can one monitor watch several backups?

It's better to use one monitor per job, so you know exactly which one stopped reporting.