The backup job fails quietly. Make the silence loud.
Email and Slack on every plan.
Database uptime is the wrong proxy for backup health. Postgres can be up for 90 days while pg_dump has been permission-denied since a role change. You find out at restore time.
A backup check that means something
- Run the dump.
- Confirm the file exists and is larger than a minimum size.
- Only then ping the heartbeat URL.
- Optionally ping /start before the dump so a hung dump shows as running, not as "never started".
What to name the check
"prod-pg-dump @ db-1", not "backup". When three dumps exist, you need to know which host went quiet.
Off-site copies
If you rsync the dump elsewhere, that is a second job. Give it its own check. A local dump that never left the box is a different incident from a dump that never ran.
Restore tests
Heartbeats cannot prove the backup restores. Put a restore drill on a calendar. The heartbeat only proves the job that creates the file still runs.
FAQ
Should I ping from the database host or the backup worker?
Ping from the process that actually wrote the file. If a central worker pulls from several DBs, one check per database.
What about managed backup services?
If the vendor has no webhook, you can still ping from a small script that lists the latest snapshot age and pings only when it is fresh.