Published by Tony Slavin
One of the easiest ways to turn a routine update into a larger outage is to treat every green checkmark as proof that the work is finished. This morning, a controlled WordPress update demonstrated why a phased rollout and a real public-path check matter.
What happened
We completed a deliberately limited update on one production site only. The usual health checks passed: the site loaded, the REST API responded, the database check was clean, and the updated plugin remained active.
Then we checked a live visitor-facing donation page. It returned a 404.
That single check changed the next decision. Instead of continuing through the remaining update list, we stopped the rollout, preserved the evidence, and held the rest of the sites for independent review.
The lesson: “site is up” is not enough
A homepage returning HTTP 200 only proves that the homepage returns HTTP 200. It does not prove that a site’s most important customer journey still works.
- For a donations site, test the public donation route.
- For a store, test a product and checkout path.
- For a booking site, test the booking flow.
- For a lead-generation site, test the form and confirmation path.
These are business-path checks, not just infrastructure checks. They are the difference between confirming that WordPress is running and confirming that the website is still doing its job.
Why the rollout stopped
Stopping was the correct result, not a failed result. A phased deployment limits the blast radius: one discovered issue remains one issue, rather than becoming the same issue repeated across multiple sites.
The practical rule we are carrying forward is simple: every update plan needs a short, site-specific list of public critical paths. Check them before the change, check them after the change, and stop at the first unexplained regression.
Healthy infrastructure is necessary. Verified customer outcomes are what make an update safe.
A checklist worth keeping
- Update one representative site first.
- Record a rollback point before changing anything.
- Verify core health: homepage, API, database, and error logs.
- Verify the site’s key visitor journey directly.
- Hold the wider rollout if any check fails.
- Document the evidence so the next reviewer starts from facts, not assumptions.
Automation makes careful operations faster. It should never make us less careful about the outcome people actually experience.
