Some readers still see the old version of a corrected story

One layer is holding the old copy, and 10 minutes of evidence will tell you which. Fetch the article's record from the content API and note its last-modified instant. Fetch the page URL with a unique query string appended. Fetch the plain URL, and read the Age and cache-status headers on the response. Then have somebody on a different network do the same. The layer whose answer disagrees with the API record is the one that never received the purge, and everything after that is a specific fix rather than a guess.

Do not flush the cache first. A full flush usually makes the symptom disappear, destroys the evidence that would have identified the layer, and guarantees the same incident recurs — at a worse moment, because the stories this happens to are the ones people are reading.

Prove which layer is holding it

1. Read the source of truth. Fetch the story from the content API or preview endpoint and record its version or last-modified instant. If the API is wrong, this is not a caching problem at all and the investigation ends here.
2. Bypass every cache with a unique query string. Request the URL with an unused parameter appended. Most edges treat that as a distinct object, so a correct response proves the origin and the build are fine and something downstream is holding a copy.
3. Request the plain URL and read the headers. Age tells you how long the edge has held this object. The cache-status header — each CDN emits its own, and some now also emit the standardised one — tells you hit or miss. An Age far larger than your intended time-to-live is the whole answer.
4. Repeat from a second network. A mobile connection, a colleague in another city, or an external checker. Different points of presence hold independent copies, and a purge that reached one region and not another looks exactly like a random subset of readers being wrong.
5. Go around the edge. Request the origin directly with the host header set. A stale response here means a build artefact or an origin-side cache, not the CDN.
6. Check the app and the browser separately. Reload the page with the cache disabled in developer tools. If the desktop browser is the only stale surface, it is a local cache or a service worker, and no CDN purge in the world will clear it.

The five layers, and what each looks like from the desk

The third and fifth rows are the ones that produce the most confusing reports, because both make the problem look like it affects a random subset of readers. They do not: they affect a specific population you cannot see from the newsroom — one network, or one app version.

Ranked causes, most common first

1. The purge never fired, because the event class did not match. This is the most common cause by a wide margin. The webhook subscribes to a publish event; a correction to a live story emits an update event, and nothing is listening. Check the event log for the story's save instant before anything else.
2. The purge fired against the wrong key set. The story moved section, gained or lost a tag, or was removed from a curation slot, and only the post-edit keys were purged — so the old section index and the old tag page still hold it. Purging both the pre-edit and post-edit key sets is the fix, and what belongs in each is covered in surrogate keys and purging one story rather than the site.
3. The purge fired and something dropped it. A queue with no retry, a rate limit, an expired credential, or a call that timed out and was never retried. This is invisible unless purges are acknowledged and failures alert.
4. A static build was never regenerated. The page is rendered at deploy time or revalidated on a schedule, and the schedule is not the newsroom's. The symptom is distinctive: even the cache-busted request is stale.
5. An intermediate cache with its own time-to-live. A reverse proxy in front of the origin, a partner's cache, an aggregator, or a corporate network. Nothing you purge reaches it, so the only control is the freshness headers you sent when the object was first served.
6. A service worker serving cache-first. The app or progressive web shell has its own store and its own expiry policy, entirely outside the CDN. It clears on a version bump, which means a release.

Two adjacent symptoms are worth ruling out early because they look identical from the desk and have different causes. If the story went live at the wrong time rather than showing the wrong content, the problem is the scheduler — see scheduled stories that go live late or twice. If the page is fresh but its structured markup still describes the old version, that is a rendering path that did not re-run, and the labelling consequences are set out in markup that separates reporting, opinion and sponsored content.

Fix in this order, while the story is live

• Reach the reader first. Purge the article's own key, verify by re-fetching from 2 networks, and only then work outward to the section index, the front page and the feeds.
• Purge by key, not by URL, and never by flushing everything. A full flush sends every reader to the origin cold, and on a big story that turns a correction into an availability incident.
• Record what you purged and when. The instant a correction became visible to readers is a different fact from the instant an editor pressed save, and it is the one that matters if a complaint follows — which is why it belongs in a fact-check record that survives a complaint.
• Leave the diagnosis in writing before the adrenaline fades. Which layer, which evidence, which fix. Most publishers discover this class of bug 3 or 4 times before anybody writes it down.

A correction is not published when an editor saves it. It is published when the last cache in the path stops serving the old sentence.

The permanent fix: a publish event that is verified, not assumed

1. Emit one event for every content change, of any class — publish, update, unpublish, retitle, re-tag — and let subscribers decide what they care about. Event-class mismatches disappear when there is one class.
2. Carry the full key set in the event, both pre-edit and post-edit, computed by whatever knows the story's relationships rather than assembled by hand at the purge site.
3. Acknowledge and retry. A purge is a distributed operation that fails sometimes; treat it like any other unreliable call, with a dead-letter path that raises an alert rather than a log line nobody reads.
4. Verify by re-fetching. After the purge, fetch the article from 2 points of presence and compare a version marker in the response against the record. A verification that runs on every publish is a few lines of code and it converts an invisible failure into an alert.
5. Publish a version marker in the HTML — a meta tag or comment carrying the story's last-modified instant. It costs nothing and makes every future instance of this bug a one-minute diagnosis instead of a 40-minute one.
6. Bump the app's cache version on release, and set a short maximum age for article shells, so the mobile surface has a bounded worst case rather than an open-ended one.

The verification step is the one worth arguing for, because it is what turns purging from a hope into a system. It is small, unglamorous, plumbing-shaped work — the sort of thing we build as internal tools and ops systems, where the value is entirely in the failure it makes visible. If the same investigation keeps ending at the build layer rather than the edge, the question underneath it is architectural, and it is the one asked in why search traffic fell after the replatform, where stale rendering and crawl behaviour turn out to share a cause.

The rest of this silo sits under CMS and publishing platform engineering, and the platform work we do for newsrooms is described in our media and publishing practice.

• caching
• corrections
• CDN
• incident response