Backups

Backup monitoring — know when a backup didn't run

Monitor any backup job with a one-line ping — get alerted when a database dump, restic or borg run, or S3 sync misses its schedule, fails, or hangs.

Start free Read the docs

The problem

Backups are the classic silent failure. The cron job runs, the dump fails — disk full, expired credentials, a network blip — and nothing tells you. You find out weeks later, mid-incident, when the restore you desperately need turns out to be empty or missing entirely.

How SteadyCron solves it

  1. 1 Create a heartbeat check matching your backup schedule (e.g. daily at 02:00) and set a grace period that absorbs normal variance.
  2. 2 At the end of your backup script, ping SteadyCron on success — and explicitly on failure if the dump command errors.
  3. 3 If the success ping doesn't arrive within the grace period, SteadyCron alerts you via email, Slack, Discord, Telegram, or webhook. 
#!/usr/bin/env bash
TOKEN=<your-ping-token>
if pg_dump "$DATABASE_URL" | zstd | age -r "$KEY" > /backups/db.sql.zst.age; then
  curl -fsS https://ping.steadycron.com/$TOKEN
else
  curl -fsS https://ping.steadycron.com/$TOKEN/fail
fi
app.steadycron.com/jobs

Jobs

New job
Search jobs…
All HTTP Heartbeat
Status Group: env
env:prod 5 jobs 1 failing
weekly-digest-email HTTP 0 9 * * 1 in 2 days 3 days ago
nightly-db-backup Heartbeat 0 2 * * * in 19 h 5 h ago
stripe-reconciliation HTTP 0 */4 * * * in 38 min 3 h ago
cache-warmup HTTP */15 * * * * in 11 min now
search-index-sync Heartbeat */30 * * * * in 6 min 24 min ago
env:dev 3 jobs
seed-test-data HTTP 0 4 * * * in 14 h 10 h ago
preview-env-cleanup Heartbeat 0 */6 * * * in 2 h 4 h ago
trial-expiry-sweep HTTP 0 6 * * * — yesterday

Every job's status, schedule, and last run — at a glance.

Why a heartbeat, not just an exit code

Your script’s exit code only matters if something is watching it — and on a lone VM, nothing is. A heartbeat moves the “did it run?” question off the box that might itself be down. If the server reboots, the disk fills, or cron is misconfigured, the ping simply never arrives, and SteadyCron tells you.

Works with any backup tool

Backup monitoring doesn’t care what produces the backup — only that it finished. The same one-line ping works for:

  • Database dumps — pg_dump, mysqldump, mongodump, SQL Server maintenance plans
  • File and system backups — restic, borg, duplicity, rsync, tar rotations
  • Cloud syncs — rclone or aws s3 sync to object storage
  • Windows — Task Scheduler jobs can ping with a single curl.exe or PowerShell Invoke-RestMethod line

If it can make an HTTP request, it can be monitored. No agent, no SDK.

Catch backups that hang, too

Send a /start ping at the top of the script. If a backup begins but never sends its /success or /fail — because it hung on a lock or ran out of memory — SteadyCron flags the run as stuck, not just late.

Catch backups that quietly degrade

A backup that “succeeds” in two seconds is usually a backup of nothing. SteadyCron’s anomaly triggers watch each job against its own baseline: a run that finishes far faster or slower than its median, or a payload that suddenly shrinks, can raise an alert even though the exit code said everything was fine.

Your backup metadata stays in the EU

Ping timestamps, job names, and alert history are stored on Hetzner infrastructure in Germany — no US sub-processors in the execution path, and a GDPR DPA is available. The backup data itself never touches SteadyCron; only the ping does.

Related documentation

Stop finding out the hard way

Start on the free tier — no credit card required.

Start free