Nobody schedules an incident. It arrives inside a task that looked routine: update the plugins on the client sites. Here is how that ordinary task becomes a bad afternoon — and, at each step, where a governed workflow would have bent the curve.
This is an illustration, not a specific customer. It's the shape of a failure every agency recognizes.
09:14 — The update that "succeeded"
You batch-update plugins across a handful of client sites. Every update reports success. The plugin's own settings page loads. You move on.
What you can't see from the dashboard: one of those plugins shipped a minor version that changed a hook the client's custom template relied on. The homepage now throws a fatal error. The admin still works. The front end is down.
Where it bends: a health check wired to the update would have loaded the front end right after applying the change and flagged the failure at 09:14 — not left it for a visitor to find.
11:40 — The client finds it before you do
Two and a half hours later, the client emails: "Is the site down?" Now you're context-switching out of other work, into a live outage, with a client watching. The clock on the incident didn't start when you noticed — it started at 09:14.
Where it bends: the failure should surface to you, on one board, the moment it happens — not to the client, hours later.
11:55 — The rollback that isn't there
You know which plugin. Now you need the previous version — the exact build, plus whatever data it wrote — and you need it while the site is down. If your only safety net is "there's a nightly backup somewhere," you're now restoring a whole site to undo one plugin, and losing anything that happened since midnight.
Where it bends: a snapshot taken before the update gives you a precise previous state for that plugin — so the undo is targeted and fast, not a full-site restore.
The governed version of the same morning
Run the same update through a governed, reversible workflow and the timeline collapses:
- Snapshot first. Each plugin is captured before it changes, so there's a real state to return to.
- Health-checked batches. Updates run in batches behind a health check.
- Automatic rollback. If a site fails the check after a plugin update, the safe batch path restores the previous plugin version automatically — the break is reverted in minutes by the system, not whenever a client happens to notice.
- Approved and audited. The action is logged — who or what asked, who approved, what ran — so a junior or an AI agent can do the work without it being an unlogged gamble on production.
Two honest caveats, because the details matter:
- Automatic health-check rollback covers the plugin batch path. Theme and core updates still run governed — approval-gated and audited — but without that automatic revert, so keep a recent backup for those.
- Even with auto-rollback, there's a window between applying an update and the health check catching a break. Governance shrinks that window to minutes; it doesn't promise a visitor never sees it.
The point isn't "update less"
Delaying updates just swaps a downtime risk for a security one. The way out is to make each update checked, reversible, and logged — so the routine task stays routine, and the bad afternoon never starts.
Aura's SiteAgent plugin is what brings this governed workflow to your sites. The plugin is free and open source, and connecting your first site — to see its health, versions, and the updates waiting — takes a minute. The governed update-and-rollback flow itself runs on a paid plan; see pricing, or check the numbers on the care-plan margin calculator.