by /
Platform note (August 2026): This July 2026 incident report preserves the provider facts that were true during the audit. Its vendor-placement recommendations are superseded: BlitzMetrics is moving away from provider-specific hosting. Current company-site hosting follows a recorded functional baseline on a supported architecture; a small number of legacy client sites may remain on the outgoing provider during migration. See the existing-client company-site hosting add-on.
On July 18, three of our WordPress sites threw fatal errors within two minutes of each other. All three were on WP Engine. Same stack trace, same plugin, same cause.
The obvious conclusion is that WP Engine broke them. That conclusion is wrong, and getting it wrong would have cost us the next six months.
Here is what the fleet actually looks like when you check all 115 sites instead of the three that were on fire.
The number that reframed the whole problem
At the time of the July 2026 audit, we ran personal-brand sites on our BlitzAdmin AWS fleet and a handful of client sites on WP Engine. Every audited WordPress site ran Rank Math for SEO. Rank Math Pro is an add-on that requires Rank Math Free installed alongside it, and the two had to stay in version lockstep or the site would fatal.
| Platform | Sites | Running current plugin version | Fatal crashes |
|---|---|---|---|
| Our own AWS fleet | 103 | 13% | 0 |
| WP Engine | 8 | 67% | 3 |
The platform with all the crashes is five times better maintained than the platform with none.
That is not a paradox. It is the entire lesson.
Managed hosting does not cause plugin drift. It detonates it.
WP Engine auto-updates the free plugin. That is what you pay a managed host to do. When it pushed Rank Math Free forward on July 17, the sites whose Pro add-on was still sitting at an old version — because Pro only auto-updates when the site is connected to a paid license — suddenly had a new Free running against a stale Pro. Pro called a class that no longer existed. White screen, instantly, on all three.
Our own platform auto-updates nothing. So on our 103 sites, Free and Pro are both frozen wherever they landed on install day. They do not crash. They also do not improve. Eighty-seven percent of them are running plugin versions that are months old, and one of them has been carrying a Pro build from a release cycle so far back that the moment anything updates it, it will fatal exactly like the three that did.
The crash is not the disease. The crash is the smoke alarm.
We had effectively disconnected the smoke alarm on 103 sites and then congratulated ourselves that they were not on fire. The 13% number is what that actually costs: outdated SEO plugins, missing schema features we pay for, security patches never applied, and a fleet-wide fatal queued up behind whatever finally triggers an update.
The failure nobody was looking for: one site, two platforms
While auditing this, we found the real outage — and it was neither platform’s fault.
Two sites were returning HTTP 500 on every path, including the login page. Both had healthy WordPress installs. We confirmed it: the install responded 200 and the admin login loaded fine.
The problem was that each domain’s DNS pointed at our AWS fleet IP, while the actual WordPress install lived on WP Engine. The domain was aimed at a server that did not have the site on it.
These sites had been migrated between platforms at some point, and the DNS and the install ended up on opposite sides. Nothing monitors for that. Uptime checks see a 500 and report “site down,” which sends someone hunting for a plugin conflict that does not exist. We wasted a cycle last month doing exactly that — a plugin was blamed publicly and the call had to be retracted a day later.
A split-platform site fails in a way that looks like every other failure and responds to none of the usual fixes.
The rule
One site, one platform. And whoever owns the platform owns the update discipline.
Those two halves are inseparable. Picking the right platform buys you nothing if nobody owns what the platform does not do for you.
Current placement policy
| Site type | Architecture | Why |
|---|---|---|
| Personal-brand site | Supported publishing architecture | Choose against the recorded publishing scope, traffic, dependencies, and operating ownership. The public company-site hosting add-on is not a stand-alone personal-brand offer. |
| Existing-client company or local-service site | Supported production architecture | Preserve the recorded lead path, search controls, measurement, publishing workflow, integrations, and recovery method in the functional baseline. |
| Anything split across platforms | One documented system of record | Domain routing, deployment, updates, recovery, licenses, and ownership must point to the same supported implementation. |
What the July 2026 platforms obligated us to do
On WP Engine at the time: the host updated free plugins. Our job was making sure every paid add-on was license-connected so it updated in step. An unconnected paid plugin on that managed host was a scheduled crash—the host could move one half and not the other.
On our own fleet at the time: nothing updated itself. Our job was the whole job: a connected license, a scheduled update pass, and a weekly check that read version numbers rather than merely checking whether the homepage loaded. A site could be nine months out of date and still return a perfect 200.
Why “it isn’t crashing” is not a status report
The check we had been running looked only for sites that were down. During that July 2026 audit it found three, every week, all on the then-managed provider—because those were the only sites receiving automated component updates.
An availability check on a platform that never updates measures nothing. Everything looks fine right up until the day something changes, and then it all goes at once, which is precisely what happened on July 18 to the sites where things do change.
The check has to read versions. Ours now does, and the first time it did, it found that the version probe itself had been broken for three consecutive weeks — it was requesting a file that the paid plugin does not ship, getting a 404 every time, and reporting “no problems found.” Three clean reports in a row, all of them meaningless.
A monitoring system that cannot fail loudly is not a monitoring system. If your check has never returned bad news, verify that it can.
The checklist
- Every site is on exactly one platform. Confirm DNS resolves to the same infrastructure the install actually lives on. Do this for every site, not just the ones that look broken.
- Place personal-brand sites on a supported publishing architecture. Match the simpler scope, traffic, dependencies, and operating ownership; the company-site hosting add-on is not a stand-alone personal-brand offer.
- Place company and local-service sites on a supported production architecture. Choose against the accepted functional baseline, complexity, traffic, integrations, recovery path, and operating ownership—not a vendor name.
- Every paid plugin is license-connected on install day. Not later. Connection is what turns on auto-update, and auto-update is what prevents drift. Our own agency license covers 750 sites and we run about 200 — connecting every one of them costs nothing.
- Build it into provisioning, not into a runbook. A site we built this month was born with the exact broken version pair, because the provisioning template still ships it. Fixing sites one at a time loses to a template that keeps making them.
- The weekly check reads version numbers. Not HTTP status. And confirm the check is capable of reporting a failure.
What this is really about
We spent weeks treating a crash as the problem. The crash was the only reliable signal we had, and it was coming from the one platform doing its job.
The sites that never crashed were in worse shape than the sites that did. They were just quiet about it.
Choose a supported architecture that fits the recorded functional baseline. Keep domain routing, deployment, updates, licenses, recovery, and ownership in one documented system. Then operate the controls the architecture does not supply automatically.
Related reading: The System — how our components fit together, and login-free publishing with application passwords, which is how we read plugin versions across the fleet without a human logging into 200 dashboards.
Dennis Yu
Dennis Yu is the CEO of Local Service Spotlight, a platform that amplifies the reputations of contractors and local service businesses using the Content Factory process. He is a former search engine engineer who has spent a billion dollars on Google and Facebook ads for Nike, Quiznos, Ashley Furniture, Red Bull, State Farm, and other brands.
Dennis has achieved 25% of his goal of creating a million digital marketing jobs by partnering with universities, professional organizations, and agencies. Through Local Service Spotlight, he teaches the Dollar a Day strategy and Content Factory training to help local service businesses enhance their existing local reputation and make the phone ring.
Dennis coaches young adult agency owners serving plumbers, AC technicians, landscapers, roofers, electricians, and believes there should be a standard in measuring local marketing efforts, much like doctors and plumbers must be certified. He has appeared on 353 podcasts with 619 credited episodes — see the full list of his podcast appearances.