How to run WordPress on Linux, properly.

ObservedBursts of 503 errors, about 1,850 a week, clustered at the minutes the cluster scaled up.

CauseThe load balancer health check watched a helper process that was ready in six seconds, while PHP behind it needed thirty-five. New pods took traffic before they could serve it, and the autoscaler flapped between two and four replicas.

Evidence & resolutionLoad balancer log: 903 of the last 1,000 errors were backend connections closed at scale-up. Fixed by probing the real PHP path and raising the replica floor.

ObservedLogins failing with 403 after a routine CDN configuration change.

CauseA security token was being served from a cached JSON response, so every visitor received the same expired token.

Evidence & resolutionA diff of the CDN behavior and the headers its cache key kept.

ObservedEvent listings up to 11.6 hours stale while the CDN purge count reached about 270 a day.

CauseA nightly sync re-saved about 150 events and each save fired its own purge, which overran the 30-second gateway timeout before the last ones ran.

Evidence & resolutionCDN invalidation history: 1,282 purges in five days. Fixed by skipping sync saves and issuing one wildcard purge.

ObservedContent changes silently stopped reaching visitors.

CauseTwo plugins bundled different versions of the same cloud authentication library, and the cache purge call failed on an undefined method.

Evidence & resolutionOne line in the PHP error log. Fixed by namespacing the vendored library in our plugin and upgrading the fleet.

ObservedEvery image URL on a site changed to the current month on the first of the month.

CauseThe bucket had been switched to uniform access, so the per-file permission write failed, the file's metadata never saved, and the path was regenerated with today's date on every request.

Evidence & resolutionA plugin issue thread that reached 37 comments before the cause was isolated, and the bucket's access setting. Uniform access becomes permanent after 90 days.

ObservedAn image service pod killed for memory once a day.

CauseThe CDN honored a 60-second cache lifetime instead of the application's four hours, so the origin re-optimized 3,160 images an hour for 303 distinct variants.

Evidence & resolutionCDN hit ratio alongside the container memory graph. Fixed with an origin-honoring cache policy and a memory arena cap.

ObservedImages failing for 65 percent of visitors over thirty days, with a p95 response time of 30 seconds.

CauseAn upstream image optimizer bug: one aborted request on a cold cache key wedged that key for every later visitor, and a year of cached HTML kept asking for an image width the site no longer generated.

Evidence & resolutionThirty days of CDN standard logs, 2,032 unique clients, status 000 for viewer disconnects. Nothing in application monitoring showed it.

ObservedScheduled tasks stopped and a newsletter queue froze.

CauseA redirect rule at the edge sent the cron ping to the homepage, so it never reached PHP.

Evidence & resolutionEdge logs showing 301 responses for the cron path. Fixed with a bypass header for internal callers.

ObservedA page fix deployed, invalidated and confirmed fresh, yet the page kept rendering wrong.

CauseThe front end fetches each page a second time with a query flag for its layout data, and that variant is a separate cache object the invalidation never touched.

Evidence & resolutionThe exact request the application makes, not the one a human makes in a browser. Invalidate with wildcards.

ObservedA homepage redirect loop for some visitors while every monitor stayed green.

CauseThe CDN cache key ignored query strings but forwarded them to the origin. A crawler hit a junk legacy URL, WordPress answered with a canonical 301, and the CDN stored that redirect under the bare homepage key for a day.

Evidence & resolutionEdge logs: about 8 percent of homepage visitors at the affected edges, two of them looping 378 and 150 times. Fixed by forwarding only whitelisted parameters, then purging everything, because a fixed policy does not evict what is already poisoned.

ObservedEdits and releases invisible to visitors for up to a day.

CauseHTML cached for 24 hours, and the save hooks purged only the edited permalink. The homepage, menus, sitemaps and the pages affected by a deploy were never purged; the release flushed the object cache and nothing else.

Evidence & resolutionA purge coverage map built from the save hooks against the edge lifetimes. Fixed with purges in the release and a short HTML lifetime.

ObservedFatal errors on a form page after a PHP upgrade, 120 occurrences in a week.

CauseAn abandoned add-on used a function removed in PHP 8.

Evidence & resolutionApplication monitoring grouped by error. Fixed with a small shim while the add-on was replaced.

ObservedHundreds of PHP errors in monitoring with no user reports.

CauseScanners were fetching core bootstrap and sample configuration files directly, and the files answered.

Evidence & resolutionError groups by request path. Closed with a web server rule that returns 404 for those files.

ObservedMore than 27,000 requests fleet-wide to one REST endpoint in a day, and a web shell written to a cache directory on one site.

CauseA core vulnerability before the patch was available, plus a web server that would execute any PHP file wherever it was written.

Evidence & resolutionEdge logs. The shell returned 404 only because the container filesystem is ephemeral. Fixed with a firewall rule and a web server deny for PHP under uploads and cache.

ObservedOut-of-memory kills and 502s in traffic spikes despite per-site PHP tuning.

CauseThe init script edited the PHP-FPM pool file as the wrong user, the error was swallowed, and every site silently ran the default of 15 workers.

Evidence & resolutionReading the live pool config inside the container, not the repository: 22 deployments affected. Fixed by mounting the config read-only and asserting it at boot.

ObservedA fresh install that never came up.

CauseMySQL takes about 100 seconds to initialize on burst-starved nodes, and the liveness probe killed it at 60 to 90 seconds, every time.

Evidence & resolutionPod events: exit 137 at the same age on every attempt. Fixed with a five-minute startup probe.

ObservedLogin page returning 502 on production only.

CauseThe production web server had 64k FastCGI buffers while staging had 256k, and chunked responses without a content length also made the CDN skip compression.

Evidence & resolutionA configuration diff between the two environments. Fixed in infrastructure code for both, which is where the drift started.

ObservedProduction canonical URLs pointing at a development hostname.

CauseA development environment had been pointed at the shared database and WordPress wrote its own hostname into rows.

Evidence & resolutionA database query for the development hostname: 57 rows, 54 bad sitemap entries. Fixed from a backup with a flush and a purge.

ObservedA site that appeared to flip between two renderings for a week, with the object cache suspected.

CauseOur own observer was wrong: one screenshot suite alternated between staging and production against a single baseline. A controlled cache flush rebuilt cleanly and ruled out poisoning.

Evidence & resolutionFour days lost before the suite was split. Verify the instrument before the system.