Database Backup Monitoring

Database backup monitoring for silent failures.

PingCron alerts you when your scheduled backup job stops checking in, so failed backups don't go unnoticed for days.

5 monitors free · No credit card · Live in under 60 seconds

A backup that silently stops running is not a backup.

Backup scripts fail for predictable reasons — disk space ran out on the destination volume, the database password was rotated and the script wasn't updated, a deploy changed environment variables cron doesn't have access to, network blipped during the upload, S3 credentials expired, file permissions changed after a server update.

Cron may run the command. That doesn't mean your backup completed. The script could exit with an error one second in, and cron will happily run it again tomorrow with the same result. Day after day, no backup, no warning.

You usually find out during an incident — when you go to restore and there's nothing to restore from. By then, the most recent good backup is weeks old.

Common silent backup failures:

  • pg_dump fails because the destination disk is full but the script keeps "running"
  • S3 sync exits cleanly with 0 bytes transferred after expired IAM credentials
  • Backup directory permissions changed after a server update — silent permission denied
  • Database password rotated, script connects with old creds, fails immediately
  • Cron daemon stopped after a server reboot — the job never ran at all

Setup

Add one line to your backup cron job.

Put the PingCron check-in after the backup command. If the backup command fails and the curl never runs, PingCron alerts you after the grace period.

Before

0 2 * * * /scripts/backup.sh

After

0 2 * * * /scripts/backup.sh && curl -fsS https://api.pingcron.io/ping/abc123

The && operator ensures the ping only fires if the backup script exits with status 0. If pg_dump fails, if the disk is full, if S3 credentials expire — the curl never runs, and PingCron alerts you after the grace period.

Real-world examples

PostgreSQL nightly dump → S3

0 2 * * * pg_dump $DB | gzip | aws s3 cp - s3://backups/db-$(date +\%F).sql.gz && curl -fsS https://api.pingcron.io/ping/abc123

MySQL daily backup

30 3 * * * mysqldump --all-databases | gzip > /backups/mysql-$(date +\%F).sql.gz && curl -fsS https://api.pingcron.io/ping/abc123

MongoDB dump + offsite sync

0 4 * * * mongodump --out /backups/mongo && rclone sync /backups/mongo remote:mongo-backups && curl -fsS https://api.pingcron.io/ping/abc123

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

Four steps. About a minute total.

01

Create a backup monitor

Name the backup job you want to protect. PingCron generates a unique ping URL.

02

Choose the expected interval

Daily for nightly backups, hourly for incremental snapshots, weekly for offsite syncs. Add a grace period to cover slow runs.

03

Add the ping URL after your backup command

Use && so the ping only fires when the backup actually succeeded. Works with pg_dump, mysqldump, mongodump, rclone, restic, or any other backup tool.

04

Get alerted when the backup misses its check-in

Email, Slack, Discord, or webhook. Configure multiple channels per monitor.

Alerts where you'll actually see them.

Configure as many channels as you want per monitor.

Email

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

Add one curl command to your backup script's cron job. After the backup completes successfully, the script pings a unique PingCron URL. If a ping doesn't arrive on schedule, PingCron alerts you via email, Slack, Discord, or webhook.
PingCron expects a check-in at a regular interval. If the backup ran successfully, your script pings the URL. If the backup script crashed, exited early, or wasn't run at all, PingCron doesn't receive the ping. After the grace period passes, the monitor goes down and you're alerted.
That's exactly when you want to know. Use the && operator in cron — it ensures the ping only fires if the backup script exits with status 0. If the backup fails, the curl never runs, and PingCron alerts you after the grace period. For instant alerts, ping /fail in your error handler.
Yes. Set the schedule to '1d' and add a grace period long enough to cover the longest expected runtime. If your nightly backup typically takes 30 minutes but sometimes takes an hour, set the grace period to 75 minutes — PingCron only alerts after the schedule plus grace period elapse without a check-in.
Yes. PingCron is database-agnostic — you wrap your existing pg_dump, mysqldump, or any other backup command with the ping URL. Works the same for MongoDB, SQLite, Redis snapshots, S3 sync jobs, or any other backup workflow.
Yes. Add a Slack incoming webhook URL in your notification settings. When a backup monitor goes down or recovers, PingCron posts to the configured channel. Slack alerts are included on every plan, including the free tier.
Yes. The free plan includes 5 monitors, email/Slack/Discord alerts, and 7 days of history. No credit card required. Upgrade to Pro at $9.99/month for 50 monitors, custom webhooks, and 30-day history.

Related monitoring guides

Know your backup job ran before you need it.

Add one line to your script. Get alerted the moment a backup misses its check-in.

Start monitoring free

5 monitors free · No credit card · Live in under 60 seconds