Monitor pg_dump (PostgreSQL dump)

1. Create a check

Create a check in Mortemain matching your dump's schedule (for example daily at 02:00) and a grace window that covers how long a dump normally takes plus some slack. Copy its ping URL:

https://ping.mortemain.com/your-check-uuid

2. Wrap pg_dump in a script

Don't ping straight from cron, wrap pg_dump in a small script so you control exactly when success and failure are reported. Fail on any non-zero exit code from the pipeline, and only ping on success:

#!/usr/bin/env bash
set -euo pipefail
URL=https://ping.mortemain.com/your-check-uuid
OUT=/backups/mydb-$(date +%F).sql.gz

pg_dump -Fc -Z6 -h localhost -U postgres mydb | gzip > "$OUT"

# tell Mortemain the dump finished OK
curl -fsS -m 10 --retry 3 "$URL"

Point cron at the wrapper, not at pg_dump directly:

# daily dump at 02:00
0 2 * * *  /usr/local/bin/pg-dump-backup.sh

3. Alert on failure immediately

A dump can fail loudly (disk full, connection refused, bad credentials) long before the grace window lapses. Add a trap so any error pings /fail and puts the check down straight away, instead of you waiting hours to find out:

#!/usr/bin/env bash
set -euo pipefail
URL=https://ping.mortemain.com/your-check-uuid
OUT=/backups/mydb-$(date +%F).sql.gz

# on any error below, tell Mortemain the dump failed
trap 'curl -fsS -m 10 "$URL/fail"' ERR

pg_dump -Fc -Z6 -h localhost -U postgres mydb | gzip > "$OUT"
curl -fsS -m 10 "$URL"          # success

set -euo pipefail matters here: without it, a failing pg_dump piped into gzip can still exit 0 and the trap never fires.

4. Measure how long the dump took (optional)

Ping /start right before pg_dump begins, and Mortemain tracks each run's duration. A database that quietly grew until the dump takes 5× longer than usual shows up as a warning, not as a 3 a.m. surprise during a restore:

curl -fsS -m 10 "$URL/start"
pg_dump -Fc -Z6 -h localhost -U postgres mydb | gzip > "$OUT"
curl -fsS -m 10 "$URL"

Prefer everything in one place? A psql or maintenance script calling out to multiple databases can follow the same shape, see the general shell & cron guide for chaining, retries and one-liners.

Test it

Run the script by hand once. The check should flip to up within a second or two, and its duration should show a realistic dump time. Then break it on purpose (wrong credentials, unreachable host) and confirm the /fail alert lands immediately, before quietly restoring the correct credentials. That's the whole safety net: a backup that stops running or starts failing can no longer hide.