Skip to main content

Alert on Failed Backup Jobs

If a backup fails and nobody knows, you do not have backups. Your alerting can be simple as long as it is reliable and tests the same path the backup job uses.

Quick Summary
  • Make backup scripts fail loudly (non-zero exit code).
  • Capture stdout/stderr to a log.
  • Alert on failure: cron mail, systemd OnFailure, or webhook.

Make failures visible​

Backup scripts should:

  • use set -euo pipefail
  • verify artifacts (zstd -t, gzip -t)
  • exit non-zero on any failure
backup-script-shell-safety.sh
set -euo pipefail
umask 077

Cron + email (small environments)​

Cron can email output if configured.

cron-alert-example.txt
MAILTO=ops@example.com

15 2 * * * /usr/local/bin/wp-backup-run

Webhook pings (healthchecks-style)​

If you use a ping-based monitoring service, call it on success and on failure.

healthcheck-ping-wrapper.sh
#!/usr/bin/env bash
set -euo pipefail

PING_OK="https://hc.example/ping/uuid"
PING_FAIL="https://hc.example/ping/uuid/fail"

if /usr/local/bin/wp-backup-run; then
  curl -fsS "$PING_OK" >/dev/null
else
  curl -fsS "$PING_FAIL" >/dev/null || true
  exit 1
fi
warning

Treat webhook URLs as secrets if they grant access or can be abused. Store them in a root-readable config file.

systemd timers + OnFailure (robust)​

systemd can run a backup service and trigger an alert service on failure.

/etc/systemd/system/wp-backup.service
[Unit]
Description=WordPress backup
OnFailure=wp-backup-alert.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/wp-backup-run
/etc/systemd/system/wp-backup-alert.service
[Unit]
Description=Alert on backup failure

[Service]
Type=oneshot
ExecStart=/usr/bin/logger -t wp-backup "backup job failed"

Next steps​

  • Email logs: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/email-backup-logs.mdx.