Your RSS Feed Cache Can Show 13 Items When 14 Actually Exist

A feed cache mismatch is the condition in which a CDN-cached feed endpoint returns a different item count than the live origin, because the cache layer serves a stored snapshot that predates one or more published posts.

The mismatch, measured

Forty minutes after publishing a new issue, two requests hit the same feed endpoint back-to-back. The first — a plain ?limit=50 query — returned 13 rows, a cf-cache: HIT, and a top-item date of 2026-08-15. The second added ?sort=new&limit=50 and returned 14 rows, a cf-cache: MISS, and a top-item date of 2026-08-21. The newest post’s public URL responded with HTTP 200 and 120,185 bytes — the content existed, the title resolved as present, but the default feed query had no idea.

One parameter, two realities. The cache-hit path was serving a snapshot frozen before the new post landed. The cache-miss path went to origin and got the truth.

The item count discrepancy is not a publishing error — it is a cache timing error. The post is real. The feed is wrong.

Why CDN caching produces this gap

CDN edge nodes cache responses by URL key. A feed URL without cache-busting parameters maps to whatever response the edge stored on the last fill. When a new post publishes between two crawl cycles, the edge continues serving the old snapshot to every request that matches the stored key — including your RSS readers, podcast aggregators, and any downstream automation that polls the endpoint.

The gap closes only when one of three things happens: the cache TTL expires naturally, a cache-purge API call fires on publish, or an inbound request carries a parameter that produces a cache MISS and forces an origin fetch. The ?sort=new variant in the measurement above did exactly that — the different query string fell outside the stored key and bypassed the stale copy.

This is the same structural pattern that cost-analysis work in AI inference has started naming directly: the sticker metric hides the real cost. Token price-per-million is to inference what row count is to feed validity — the number on the dashboard that feels authoritative while the actual outcome (resolved support ticket, correct post delivered to subscriber) sits one layer deeper. AWS’s benchmarking work on OpenAI models on Amazon Bedrock makes this explicit: production workloads buy outcomes, not tokens, and the multipliers between price and outcome — turn count, accuracy, format compliance — are what dominate the bill. Feed operators face the same accounting problem. The number your monitoring dashboard shows for “item count” is not the number your subscribers receive if the cache layer sits between them.

The decision point: which path does your reader hit?

Every feed consumer — a podcast app, an RSS aggregator, a GitHub Action pulling new posts — resolves to either a cache-hit or a cache-miss path. Most hit the cache, because that is the point of a CDN. The miss path is slower and costlier for the edge to serve, which is why platforms cache aggressively. But for time-sensitive content — a new newsletter issue, a product update, a breaking post — the miss is the only path that tells the truth.

The pattern is consistent with what memory-layer tooling in coding agents is solving for a different domain. Projects like funes, a durable memory layer for coding agents built from local session traces, expose the same gap: the information exists (agent session logs, published posts), but retrieval, ranking, and exact provenance require active infrastructure to surface it. A cached feed that cannot surface the newest item is, structurally, an index without retrieval — the record exists, the count does not.

What actually goes wrong downstream

Three failure modes follow from a stale count:

Feed-based automations run on the wrong state. A workflow that triggers on “new item” by comparing the previous count to the current count will not fire if the count is frozen at 13. The new post exists but never triggers the downstream action.

Benchmark scores can obscure signal for the same reason. Allen AI’s BenchMIRT audit of LLM benchmarks, published September 1, 2026, found that averaging across heterogeneous tasks inside a single benchmark can obscure what actually drives a score — a harmful-prompt group and a benign-prompt group inside the same benchmark measure different capabilities, and averaging them hides both. A feed item count has the same property: a single integer conceals whether the discrepancy is one post, three posts, or a systematic lag that has been running for weeks.

Subscriber trust erodes quietly. Readers who notice gaps — a post referenced in social that never appeared in their reader — will not usually file a bug report. They will unsubscribe.

The structural fix, not the workaround

Querying ?sort=new is a diagnostic, not a solution. The correct fix operates at the cache layer:

1. Fire a cache-purge API call on every publish event. Cloudflare, Fastly, and comparable CDNs expose purge-by-URL endpoints. A publish webhook that calls the purge endpoint ensures the next feed request goes to origin.
2. Set a short TTL on feed endpoints specifically. Static assets warrant long TTLs; feed endpoints warrant TTLs measured in minutes, not hours or days.
3. Add cache-status headers to your feed monitoring. The cf-cache header was the first signal in the measurement above. A monitor that logs cache status alongside item count surfaces mismatches before readers encounter them.
4. Verify with a cache-miss request, not a cache-hit. Any feed health check that does not include a mechanism to bypass the cache is checking the cache’s opinion of reality, not reality itself.

The success criterion

The mismatch is resolved when a plain ?limit=50 request — no extra parameters, no cache-busting — returns the same row count as a forced cache-miss request, within five minutes of a new post going live. If that condition does not hold, the cache is silently editing your feed.

Check it now, before the next post publishes. The gap between 13 and 14 is small. The gap between what you think your subscribers see and what they actually see can be much larger.

Looking for more on ai & digital income? Visit SAVYX

Frequently Asked Questions

Why does my RSS feed show fewer items than I have published?

The most common cause is a CDN cache serving a stored response that predates your newest post. The post exists on the origin server, but the cached feed endpoint has not been refreshed. Adding a cache-busting parameter or purging the cache after each publish resolves it.

How can I tell whether my feed is returning a cached or live count?

Check the response headers for a cache-status field such as cf-cache: HIT or MISS. A HIT means you are seeing a stored snapshot; a MISS means the response came from origin. Comparing the item counts from both paths directly reveals whether a mismatch exists.

Does a 13-versus-14 item count difference actually harm my readers?

It can. Feed-based automations that trigger on new items will not fire if the count is frozen. Subscribers using RSS readers may never see the newest post until the cache expires. For time-sensitive content — newsletters, product updates — the delay can run from minutes to hours.

Is querying with a different sort parameter a reliable fix?

It is a diagnostic, not a solution. A different query string can force a cache miss and reveal the correct count, but your readers are still hitting the default cached path. The structural fix is a publish-triggered cache purge via your CDN’s API, combined with a short TTL on feed endpoints.

How often should I set my feed cache TTL?

Feed endpoints should be cached for minutes, not hours or days. Static assets benefit from long TTLs, but a feed that can be stale for four hours will routinely hide new posts from early subscribers. A TTL of five to fifteen minutes, combined with purge-on-publish, is a practical starting point.

Disclosure: As an affiliate, this post may earn a commission from qualifying purchases at no extra cost to you.