Does pg_dump exit non-zero if the backup is corrupt or incomplete?

Yes. pg_dump exits with a non-zero status if it encounters a fatal error during the dump. However, some non-fatal warnings still exit 0, so verifying the output file is non-empty is an additional useful check.

How do I test that my backup script pings correctly?

Run the script manually and confirm the ping arrives at your monitor. Then introduce a deliberate failure (pass a wrong database name) and confirm no ping fires and the monitor would alert.

How to monitor pg_dump and mysqldump scheduled backups

pg_dump and mysqldump are one-shot command-line tools with no built-in scheduling, alerting, or monitoring. You schedule them yourself (usually with cron) and must check their exit status and error output explicitly. A non-zero exit from pg_dump or mysqldump means the backup failed or is incomplete — and cron by default discards that output. The reliable pattern is to check the exit code in your backup script and ping a heartbeat monitor only on a clean exit.

How do I know if pg_dump or mysqldump actually succeeded?

Both tools exit non-zero on failure. A script that ignores the exit code and pings on every run would report success even when the backup is empty or corrupt. Check the exit code explicitly:

backup.sh

#!/usr/bin/env bash
set -euo pipefail

BACKUP_FILE="/backups/mydb_$(date +%Y%m%d).sql.gz"

# pg_dump exits non-zero on failure; set -e aborts the script.
pg_dump -Fc -d "$DATABASE_URL" | gzip > "$BACKUP_FILE"

# Confirm the file is non-empty (a connection error can produce an empty file).
[ -s "$BACKUP_FILE" ] || { echo "backup file empty"; exit 1; }

# Only reached on full success — ping the monitor.
curl -fsS -m 10 --retry 3 "https://ping.cronshield.com/<your-check-id>"

For mysqldump, the pattern is the same — the tool exits non-zero and writes errors to stderr:

mysqldump --single-transaction --routines mydb | gzip > "$BACKUP_FILE" \
  && [ -s "$BACKUP_FILE" ] \
  && curl -fsS -m 10 --retry 3 "https://ping.cronshield.com/<your-check-id>"

How do I capture errors when the backup fails?

Redirect stderr to a log file so you have a record of what went wrong when the backup alert fires:

crontab -e

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

PING_URL is a placeholder for the endpoint you get when you create a monitor. The CronShield receiver ships in an upcoming release. Without the heartbeat, a cron that deletes old backups and fails silently produces no alert — and you discover the gap only when you need the backup.

What if the cron entry itself is missing or the machine is down?

A heartbeat monitor is the only thing that catches a backup that never ran — if no ping arrives in the expected window (daily, weekly), the alert fires regardless of what the backup server is doing. Set the grace period above the expected backup duration so a slow backup doesn't trigger a false alarm.

Add a missed-run alert to this job

The free tier gives you a heartbeat endpoint and an email alert when an expected ping doesn't arrive. Paid tiers add the log-aware diagnosis — the last log line and a likely cause in the alert. The heartbeat receiver ships in an upcoming release; see the plans to learn what each tier adds.

Start free View pricing

Frequently asked questions

Does pg_dump exit non-zero if the backup is corrupt or incomplete?: Yes. pg_dump exits with a non-zero status if it encounters a fatal error during the dump. However, some non-fatal warnings still exit 0, so verifying the output file is non-empty is an additional useful check.
How do I test that my backup script pings correctly?: Run the script manually and confirm the ping arrives at your monitor. Then introduce a deliberate failure (pass a wrong database name) and confirm no ping fires and the monitor would alert.