A post went live. The permalink worked. The front page — the URL people
actually type — showed no sign of it for two hours.
Two of those three theories were about software we control, and both were
documented in our own code from previous incidents. A known bug is the most
seductive wrong answer there is: it explains the symptom, it comes with a
citation, and it stops you looking.
The cache flush reported success every single time, and it was
telling the truth — about the layer it owns. W3TC really
was empty. The request simply never reached it, because the host runs an nginx
proxy cache in front of WordPress with a two-hour TTL.
Nothing inside WordPress can see that layer, let alone clear it. But the
proxy accepts a purge:
curl -X PURGE https://example.com/ -> 204
The pipeline now runs flush WordPress → purge the proxy →
warm the front doors, in that order. Warming before purging just
re-cements what the proxy is already holding.
The one sentence
When a flush succeeds and the page is still wrong, you are flushing
the wrong cache.
A flush can only report on the layer it owns. The response headers are a
receipt from every layer that touched the request —
X-Proxy-Cache, Age, Via,
X-Cache, CF-Cache-Status. We theorised for two hours
about our own code; the answer was one curl -I away, in software we
did not know was there.
Read the headers first. They do not have a theory.