On Tuesday, August 4, a number of the client websites we manage experienced intermittent slowness and occasional timeouts, beginning around 7:00 AM CDT and recurring on and off through the day. The cause was a bug in a third-party caching plugin’s telemetry feature, which made a blocking server-side request to an external analytics endpoint that had become unreliable.
Everything is stable as of this writing. Here’s what happened, why it took us most of a day to pin down, and what we’re changing.
What happened
WP Rocket, the page-caching plugin we run across much of our managed WordPress websites, includes an optional analytics feature (“Rocket Analytics”) that reports usage data back to the vendor. That report is sent server-side, during page generation, as a synchronous HTTP request with a 30-second timeout.
On August 4, the endpoint receiving those reports began failing intermittently, returning errors after anywhere from 4 to 16 seconds. Because the request was synchronous, WordPress waited for it to fail before finishing the page. Any page build that wasn’t served from cache inherited that delay.
The symptoms varied by platform. Sites on hosting with a fixed pool of PHP workers exhausted that pool and returned gateway timeouts; sites elsewhere simply got very slow, and a small number became unreachable for longer stretches.
Timeline (all times CDT)
- ~7:00 AM: First alerts. Slowness and timeouts across sites on multiple hosts.
- Morning: Initial investigation focuses on hosting platforms, CDN configuration, and our own management tooling. Symptoms come and go without a clear trigger.
- Midday: Fleet-wide management tooling is taken offline as a precaution to rule it out. Symptoms continue.
- Afternoon: Recurrence. Analysis of monitoring data shows failures clustered within the same few seconds across sites on unrelated hosts, which rules out any single host or network path.
- Evening: Root cause identified: a blocking outbound request from the caching plugin’s telemetry feature. Our symptoms matched a bug report filed publicly the previous day by another host, wp-media/wp-rocket#8669, which documented the same failure with measurements. WP Rocket was disabled across all managed websites temporarily to resolve.
- Following morning: Patched version deployed and telemetry disabled fleet-wide. Sites stable.
Why this was hard to find
Three things worked against us.
Page caching hid it. Visitors receiving a cached page saw no problem at all. The delay only appeared on a cache miss — a purge, a logged-in session, a crawler walking uncached URLs, or an uptime check that bypasses cache. A site could serve a cached homepage in under 100 milliseconds while every uncached request behind it took sixteen seconds.
The failure was outbound, not inbound. We spent the morning looking at inbound paths: hosts, CDN, firewall rules, our own management server. None of it explained why sites on entirely separate infrastructure, some behind a CDN and some not, failed within the same second. A shared outbound dependency was the only thing that could produce that pattern, and it wasn’t where we were looking.
The upstream failure was itself intermittent. The endpoint recovered between episodes, so sites recovered too, which made it look like unrelated incidents on unrelated servers rather than one cause.
What we’ve done
- Deployed the patched plugin release across the fleet.
- Disabled the telemetry feature regardless of the patch. A non-essential analytics call should never sit on the path that renders a page for a visitor. We’re not re-enabling it.
- Verified response times across affected sites are back to normal baselines.
A note on the vendor
This was a real bug with a real fix, the report was handled publicly, and a patch followed quickly. We’re keeping WP Rocket. What we’re not keeping is optional vendor telemetry running inside the request path of client websites.
If your site was affected and you’d like the specifics for your own records, get in touch and we’ll walk you through it.