How to Monitor Database Backups (So You’re Never Caught Out)

Backups are the ultimate silent-failure risk: nobody checks them until they need them, and that is the worst time to learn they have not run in weeks. Monitoring backups is less about the backup tool and more about confirming the job ran, finished, and produced a sane result.

What to actually monitor

• Did the backup job run at all? (the most common failure)
• Did it complete successfully, with a non-zero exit on error?
• How long did it take? A sudden change in duration is a red flag.
• Optionally, is the output a plausible size, not a 0-byte file?

Add a heartbeat to your backup job

A pg_dump example that signals start, success and failure — and only counts as success if the dump is non-empty:

#!/bin/bash
UUID=<your-uuid>
BASE=https://api.cronguard.dev/v1/ping/$UUID
curl -fsS $BASE/start

if pg_dump mydb | gzip > /backups/mydb.sql.gz && [ -s /backups/mydb.sql.gz ]; then
  curl -fsS $BASE
else
  curl -fsS $BASE/fail
fi

Don’t forget off-site copies

Monitor each stage independently — the local dump, the upload to object storage, and any periodic restore test. Each gets its own monitor so you know exactly which step broke.

Get alerted before you need the backup

Point those pings at CronGuard and set the schedule. If a backup misses its window, runs short, or fails, you get an instant alert across multiple channels — and a history of execution times. Free to start, set up in a minute.