Backups

Your backup didn't run last night. Would anyone know?

Backups don't fail loudly — they fail silently, by not running. Here's how to put a watchdog on every backup job you're responsible for, in about two minutes each.

Here's a true story with the names filed off. A small Windows server ran a backup job faithfully for years — every week, a fresh archive appeared on the FTP server. Then the site was migrated to a new machine. The old job, of course, didn't come along. Nobody noticed, because a backup that stops running produces no error. No crash, no email, no red light. Just an ever-widening gap between "the last backup we have" and "the day we'll need it."

The failure mode nobody monitors

Everyone plans for the backup that fails: the job runs, something breaks, an error lands in a log. But the log is on the server, nobody reads it, and the far more dangerous case is the backup that doesn't run at all: the scheduled task got disabled during maintenance, credentials expired, the machine was rebuilt, cron lost the entry, the disk it staged to filled up. Every one of these is silent. If you manage servers for clients — agency, MSP, freelancer — multiply that by every client machine you're on the hook for.

There's a third failure mode, sneakier still: the backup that "succeeds" at 40 MB when it's normally 10 GB, because a path changed or a database went missing from the dump. Success exit code, useless archive.

The fix: a dead-man's-switch

The pattern is old and it works: instead of hoping errors reach you, make silence itself the alarm. The backup job pings a URL after every run — success or fail. A monitor on the other end knows the schedule ("weekly, plus a few hours of grace") and alerts you when:

  • a run reports failure — you hear about it immediately, with the error message;
  • no run reports at all inside the expected window — the disabled-task / dead-cron / decommissioned-server case that log files can never catch.

MonitorSpider's backup monitor is exactly this. You create the monitor, set the expected interval (say, weekly + 6h grace), and it gives you a private ping URL. Reporting success or failure from any tool on any OS is one line of shell:

your-backup.sh \
  && curl -fsS "$PING_URL&status=success" \
  || curl -fsS "$PING_URL&status=fail"

On Windows, the same thing is a tiny PowerShell call — we publish a ready-made Send-BackupPing.ps1 you can bolt onto any existing tool: a Cobian post-backup event, a Veeam post-job script, a wbadmin wrapper, anything that can run a command when it finishes.

Catching the shrinking backup

The ping can optionally carry bytes and duration_s. MonitorSpider stores them and graphs backup size over time — so the 10 GB → 40 MB "success" is visible at a glance on the monitor's page, right next to its uptime history. Your client's status page can show the backup's health alongside the site's.

No backup yet? Take one of ours

If a server has no backup at all, the watchdog alone won't save you — so we publish free, auditable, single-file backup scripts with the ping already built in:

They're plain scripts you can read top to bottom before running on a client's server — no agent, no installer, nothing phoning home except the ping URL you configure.

Set it up once per job

  1. In MonitorSpider, add a monitor of type Backup (push) — one per backup job is the right granularity.
  2. Set the expected interval and grace to match its schedule.
  3. Copy the ping URL into your backup script (or our kit's config).
  4. Run the job once and watch the monitor go green.

From then on, a failed backup pages you with its error message, and a backup that silently stops running pages you the moment its window expires. Alerts go to your whole team by email — and to Slack, Telegram or a webhook on Premium.

Put a watchdog on the backup you're most worried about — your free plan includes one backup monitor. Start free, no credit card.
Keep reading