The update-roulette teardown
Every update is a bet
on a live client site
“Update all” is one click. The consequences aren't. Here's a plain look at what actually breaks when you update plugins, themes, and core on production — and how to take the gamble out without stopping updating.
What actually goes wrong
None of these are exotic. They're the ordinary ways a routine update turns into an afternoon — and they compound with every extra site under management.
A plugin update ships a breaking change
A minor version bump quietly changes a hook, a shortcode, or a database schema. The plugin's own page loads fine; the client's custom template that depended on the old behaviour doesn't.
Two plugins that were fine together stop being fine
Update A alone is safe. Update B alone is safe. Updated together — or against a PHP version one of them didn't test — they fatal. The combinatorics are why testing every site by hand doesn't scale.
The white screen you find out about from the client
A fatal error takes the front end down. Without a health check wired to the update, nobody knows until the site is already offline and the client is already emailing.
The rollback that isn't there
You can update in one click. Undoing it means finding the previous version, the previous data, and the previous state — usually while the site is down. Most maintenance workflows have no real undo.
Why testing every site by hand doesn't scale
One site, you can babysit. The problem is the multiplication:
- Every site has a different plugin set, theme, and PHP version — so “tested” on one proves nothing about the next.
- The risky updates arrive on the vendor's schedule, not yours — often several in a week.
- The failure is frequently invisible from the dashboard: the update “succeeded”, but the front end is broken.
- The cost isn't the fix — it's the context-switch, the client email, and the trust you spend each time.
So most agencies pick one of two bad options: update blindly and firefight, or delay updates and carry the security risk. Governed updates — checked, logged, and automatically reversible on the plugin batch path — are the third option.
Taking the gamble out
You don't de-risk updates by updating less. You de-risk them by making every update checked and logged, and plugin updates automatically reversible. That's what Aura's SiteAgent does on each connected site.
Health-checked, auto-rolling-back plugin updates
Run plugin updates in batches behind a health check. If a site fails the check after an update, the safe batch path restores the previous plugin version automatically — so a break is reverted in minutes by the system, instead of sitting there until a client happens to notice.
Snapshot before you touch it
Every plugin is zip-snapshotted before it changes, so there's a real previous state to return to — not a hope that the last backup was recent and complete.
Approval + audit, so the risky move is a decision
Mutating actions are approval-gated and recorded — who or what asked, who approved, what ran. An agent or a junior can do the work without the update being an unlogged gamble on production.
The whole fleet in one place
See versions, health, and available updates across every client site at once, so you're triaging from one board instead of logging into wp-admin after wp-admin.
Automatic health-check rollback covers the safe pluginbatch-update path. Theme, core, and direct single updates still run governed — approval-gated and audited — but without that automatic rollback, so treat the site token as a sensitive credential. Aura is honest about where each guardrail does and doesn't apply.
Stop betting the client site
Connect your first site free with the open-source SiteAgent plugin and see its health, versions, and the updates waiting. No card required; paid plans unlock the whole fleet and governed updates when you're ready.