Proof your backups ran — every job, every server

Backups are the retainer work nobody thinks about until something goes wrong.

Your agency runs nightly backups across 40 client sites. The backup tool runs silently in the background. When everything works, nobody notices. When a backup silently fails for three weeks and then the client’s database corrupts — everyone notices.

The Backups channel captures backup events — completions, failures, restore verifications, storage alerts — and surfaces them in the client’s operational timeline. A failed backup isn’t buried in a tool’s notification email. It appears in the timeline alongside deploys, form submissions, and monitoring signals.

The receipts

The channel view for any site reads like an audit: completed runs, failed runs, the success rate, and the jobs under watch. Below it, Backup Health draws one band per run, stacked by frequency, across the last month for every job — so a database job running every two hours and a nightly files job each show their own rhythm, and a gap in the bands is visible from across the room. Completed, failed, expired, and no-run states each carry their own color; hover any band and you get the run’s time and its restore-by date — when that backup ages out of retention and stops being a safety net.

That expiry visibility is the quiet win. “We have backups” is only true until the retention window closes. The channel shows what’s restorable today, what’s aging out, and which jobs haven’t produced a run at all — before the emergency that requires them, not during it.

And when you’re about to do something risky — a migration, a major update, a Friday deploy — you don’t switch tools: request a backup directly from the channel and get a fresh restore point on record before you touch production.

What the Backups channel captures

Backup lifecycle: Backup scheduled, backup started, backup completed, backup failed. Each event includes metadata — backup type (database, files, full), size, duration, storage destination.

Restore events: Restore initiated, restore verified. When your team tests a restore as part of a disaster recovery drill, the verification event appears in the timeline.

Storage signals: Storage threshold warnings, retention policy cleanups, destination availability checks. When a backup destination approaches capacity limits, the signal appears before backups start failing.

The invisible safety net

Backup health is one of the most underreported aspects of maintenance retainers. The monthly report says “backups running.” But is that true? Did the backup on March 14th actually succeed? Is the retention policy keeping 30 days of history? Is the storage destination accessible?

Without the Backups channel, answering those questions means logging into the backup tool, checking per-site status, and trusting that the tool’s own alerting works. With the Backups channel, backup events are part of the client timeline — visible, auditable, and reportable.

Integrations that feed this channel

• SnapShooter: Backup completion events, restore verifications, storage signals
• Custom backup solutions: Send events from UpdraftPlus, BlogVault, custom scripts, or any backup tool through the Burrow API

How agencies use the Backups channel

Backup health monitoring: Failed backups appear in the client timeline. Scout flags patterns — three consecutive failures, storage threshold approaching, retention gaps.

Retainer reporting: Monthly digests include: “30 nightly backups completed successfully. Average backup size: 2.1GB. Retention: 30 days.” The work that nobody thinks about becomes visible.

Compliance and audit: The backup event trail is an audit log. When a client asks “do we have backups from March 7th?” the timeline has the answer.

Maintenance reporting | Site monitoring use case | Agency operations | CMS version tracking