Database Backup Monitoring
Backup monitoring for missed runs and failed transfers.
Monitor recurring database backup jobs with a success check-in after the dump and required upload finish. Get alerted when a check-in is missed, then investigate the job and destination. Five monitors are free.
5 monitors free · No credit card · Verify your first check-in
Check the backup job, the stored copy, and the restore separately.
A green scheduler entry only shows that a command ran. A backup can still be incomplete, missing from the recovery destination, or impossible to decrypt. Decide which steps must succeed before your script reports success.
PingCron watches the check-ins your job sends. It does not inspect archives or restore databases. Use missed-run monitoring alongside destination checks and isolated restore drills so each check answers a specific recovery question.
Investigate a missing backup check-in in this order:
- Check whether the scheduler started the expected job, using its configured timezone.
- Read the dump and upload exit codes; inspect storage capacity and access errors.
- Confirm that the expected new archive reached the recovery destination.
- If the work succeeded, check heartbeat delivery and the monitor’s interval and grace.
Setup
Send success after the backup reaches its destination
Define the dump, transfer, and verification steps your recovery process requires. Only report success when all required steps complete.
Before
0 2 * * * /scripts/backup-and-upload.sh
After
0 2 * * * /scripts/backup-and-upload.sh && curl --max-time 10 -fsS YOUR_MONITOR_SUCCESS_URL
Use the monitor’s actual success URL. The script exits on a failed dump or upload, so the cron success heartbeat is skipped. A received heartbeat proves only that the script reported success; separately verify archive integrity, retention, encryption-key recovery, and restoration into an isolated database.
Real-world examples
Inside backup-and-upload.sh (illustrative paths)
#!/bin/sh
# Configure PostgreSQL connection settings securely in the environment.
# Supply a unique ARCHIVE path and your own upload command.
set -eu
: "${ARCHIVE:?Set a unique backup file path}"
pg_dump --format=custom --file="$ARCHIVE"
/usr/local/bin/upload-backup "$ARCHIVE"
# Exit zero only when every required backup step succeeded.Backup jobs to monitor.
Any scheduled backup that needs to keep running.
PostgreSQL backups
Nightly pg_dump or pg_basebackup jobs.
MySQL backups
Daily mysqldump or Percona xtrabackup runs.
MongoDB backups
mongodump exports to disk or cloud.
SQLite backups
Sqlite3 .backup or file copies.
S3 upload jobs
Sync local backups to S3 or other object storage.
Offsite backup syncs
rclone, rsync, restic to remote destinations.
Daily snapshots
LVM snapshots, ZFS snapshots, EBS snapshots.
Client backup scripts
Per-tenant or per-customer backup workflows.
How it works
Review the backup, install monitoring, and verify completion.
Review the expectation
Match the deployed schedule and timezone, then choose grace for legitimate runtime and delay.
Create and install the monitor
Keep its actual heartbeat URL private and send success only after the required work finishes.
Verify the setup
Confirm the first successful heartbeat and receipt of an alert-destination test.
Alerts where you'll actually see them.
Save alert destinations for the owning account. Email, Slack, and Discord are included on every plan; custom webhooks require Pro or above.
HTML alerts with monitor details and direct links.
Slack
Post to any Slack channel via incoming webhook.
Discord
Native Discord webhook integration.
Custom webhooks
POST alerts to any endpoint with full payload.
FAQ
From configuration to a verified first run
Define what a completed backup means before adding its heartbeat. If recovery depends on an offsite copy, send success after both the dump and upload succeed. A local file or a successful HTTP receipt alone cannot establish recoverability.
Check the backup crontab →- Preserve the exit status of each dump, compression, and upload command. Avoid pipelines that hide an earlier failure.
- Choose grace to cover normal backup duration and expected scheduler delays. Keep separate monitors for independently scheduled backups.
- Run restore drills into an isolated destination and verify the restored data. Keep decryption keys recoverable separately from encrypted backups.
Before relying on alerts
- Review the monitor’s schedule, timezone, and grace period against the deployed job.
- Save your alert destination in Settings, send a labeled test, and confirm that you received it.
- Run the actual workload through its scheduler and confirm its first successful heartbeat in PingCron. Copying the URL does not install monitoring.
A successful receipt records what the job reported; it does not prove the output is correct. Detection and delivery timing depend on the schedule, grace period, and alert provider.
Start with the backup your team would restore first
Free covers five monitors with email, Slack, and Discord alerts. Compare plans when you need more jobs, longer history, custom webhooks, or shared team access. A larger plan does not replace a restore drill.
Verify one backup job before adding the rest.
Start free, confirm its first successful check-in and alert destination, then add the jobs your recovery process depends on.
Start monitoring free5 monitors free · No credit card · Verify your first check-in