Skip to content

Build1 publisher3 min readPublished

A stale cache put 95 views in YouTube's Atom feed for a video the page counted at 118

YouTube's public feed answers a view-count query with a stale number, a valid 200 and an unremarkable byte count, so a program that reads it once takes the wrong answer for the real one.

The Engineer · Build desk

Illustration accompanying A stale cache put 95 views in YouTube's Atom feed for a video the page counted at 118

What happened

  • At 05:15 UTC on 18 September 2026, YouTube's public Atom feed reported 95 views for a video whose own page reported 118 at that same moment, and the response came back a valid 200.
  • Twelve reads of the same feed document over forty-five seconds with an identical User-Agent returned two different counts for that video, at identical byte size and the same status code.
  • Three minutes earlier, thirty reads spaced four seconds apart were rejected in nineteen milliseconds, returning Google's generic 404 page with no HTTP 429 and no quota message anywhere.
  • The video page exposes the count as an integer in a field named originalViewCount, separate from the rendered "118 views" label whose formatting depends on the served language.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • constraint Guards built on status codes, byte counts or retries are blind to this failure, so correctness has to come from comparing several reads.
  • exposure Anyone charting their own channel from this feed has been recording numbers up to about a fifth low, with a 200 in the log and nothing to raise an alert on.
  • cost The remedy doubles the requests per measurement and adds a second document to parse, which is most of what made a keyless six-kilobyte endpoint attractive in the first place.
  • capability Because a view total never falls, a program can settle the disagreement from the reads it already has, taking the highest of several as the freshest.

The series sat at 22 views across three reads spanning 2h04, then at 71 across five reads spanning 2h46, then at 95 [10]. It was recorded by Obole, which publishes as an AI running on a two-core ARM server with no GPU and says it prints the raw numbers, including the ones that make it look bad [22]. That is a step function. Between the first plateau and the second, 49 views arrived in one step [4]. Those plateaus are cache lifetimes, according to Obole, and the comparison with the video page is what established it [10].

With a cumulative counter there is nothing to average. A view total does not go down, so when two reads of the same instant disagree, the lower one is a stale cache [13]. A guard that took the mean of the two would have written 106.5 views [2], a figure no cache ever served.

The guard Obole already had retried while the feed came back empty, and it had a real case to handle from the day before: 1,609 bytes, HTTP 200, a complete channel header, zero entry elements [7]. "An empty response is not a measurement of zero, and retrying was the right fix for that case," Obole wrote [8]. A response that arrives with a different number sails straight past that loop [9]. The entry's updated timestamp, the one field a reader would check for staleness, read 2026-09-17T18:42:39 while the same document served a counter from nine hours later [11].

The endpoint also fails the ordinary way, and the loss rate climbed over two hours from 2 reads out of 6, to 4 out of 6, to 30 out of 30 [15]. An ordinary YouTube page answered HTTP 200 in 465 ms from the same machine at the same moment, so the address was still reachable and one endpoint had stopped answering [19]. Obole calls rate limiting plausible and unestablished [16], having itself issued about thirty requests in two minutes [17]: "I am writing it down because it is the hypothesis that accuses me" [18].

The published fix is four rules: read two independent sources, take several reads of each, keep the maximum of everything that answered, and refuse to write a value lower than the last [21]. The last two rules hold only for counters that cannot fall [6]. Point them at a quantity that can go down and the maximum rule pins the series to the highest stale value it ever saw [6].

This is one channel, one machine, one morning, and the number YouTube treats as authoritative sits in Studio behind a session [6]. So the 23-view gap [1] is a floor on the divergence for that video at that instant; how far the feed runs off in general is still open. On the second video the feed reported 6 where the page reported 12 [3].

What to watch

  • Whether the endpoint's alternation between 200-with-no-content, 404 and 500 settles, or the media:statistics tag stops appearing in the feed at all.
  • Whether originalViewCount keeps that name in the video page payload, since a rename breaks the second source the whole fix depends on.
  • A reference series out of YouTube Studio would turn the 23-view gap from a floor into a calibration of how far the feed lags.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories