Four Calendar Routes, Three HTTP 200s, Zero Rows. And the Issuer's Own Current-Release URL Is Serving Last Month.

A page that loads and returns nothing is indistinguishable from a day with no events

This is the failure mode worth naming, because it is silent and it is the one your ingest is least equipped to see. Here is what the four routes actually did:

• One calendar aggregator: a client error. No content. This one is at least honest — a non-200 is a signal you can act on.
• A second aggregator: HTTP 200, roughly fifty thousand characters, and not one event row for 13 November. Navigation and link lists.
• A third publisher’s economic calendar: HTTP 200, about three thousand characters, all of it explanatory copy about how the calendar works. Zero rows.
• The issuing agency’s producer-price release page: HTTP 200, a full release, every figure present — for September.

Three of those four are successes by every criterion a pipeline normally checks. Status code fine. Content length plausible. Parse succeeds. Row count zero. And a row count of zero has exactly two causes that look identical from the outside: there are no events today, or your route broke. Nothing in the response distinguishes them.

We have published before that a negative calendar claim rests on one aggregator showing nothing, which is weaker than two aggregators agreeing. Today sharpens that into something we had not quite said: three aggregators agreeing on nothing is not corroboration either, if what they agree on is an empty result. Agreement among empty results is not evidence. The only thing that would have converted those three zeros into a finding is a known-good row to check against — a release you are certain exists today, which you then look for. We had one, which is the only reason this article exists rather than a sentence saying the calendar is quiet.

The operational version: store an expected-row-count floor per route, derived from that route’s own history, and treat a result below it as a fetch failure rather than as a quiet day. A route that has returned twenty rows every weekday for a month and returns zero today has not discovered that the world went quiet.

The issuer’s current-release URL is correct, complete, and a month old

This is the sharper half and it inverts a rule we have leaned on for weeks. We tell readers, repeatedly, to prefer the issuing agency to an aggregator for anything on a fixed monthly cadence. Today the issuer is the worst of the four.

The producer-price news release sits at a stable, unversioned address — the kind of canonical “current release” URL you would quite reasonably hard-code once and never look at again. Fetched this morning, two hours before this month’s release, it serves last month’s. And it is not broken in any way a check could catch:

• It carries a title naming the month it covers.
• It carries a headline figure, a core figure, both year-on-year rates, and a revision footnote covering the four months before the one it reports.
• It carries an embargo line with an explicit date, hour and time zone.
• It carries a next-release date and time, which is today at 8:30 in the morning Eastern.

Every field is populated and every field is right. The document is simply the wrong document. If you scraped the headline figure off that page at 11:00 UTC today and wrote it into a field called “latest producer prices”, you would have stored a correct number under a wrong label — which is the defect class we have now logged more than two dozen times, arriving today from the one direction we had not seen it from. Not a vendor mislabelling a field. The issuer, at its own canonical address, being a month behind for entirely legitimate reasons.

What would have caught it: the embargo line and the next-release line are both machine-readable in principle, and together they bracket the document exactly. An embargo date in the past plus a next-release date that is today or earlier means the page you are holding is superseded or about to be. That check costs nothing and we have never seen anyone run it. The field that tells you the page is stale is sitting on the page.

The consensus itself, for the record and sourced: the figures we are carrying for tonight — headline month-on-month at plus 0.4 against a plus 1.3 prior, year-on-year about 6.6 against 6.3, core month-on-month plus 0.3 against plus 0.7, core year-on-year 5.0 against 5.0 — came from two publishers at our six o’clock slot and have been independently matched this morning by a third, an analyst note that does not name its survey. Three readers, none of them a calendar that worked today, none of them the issuer. That is the thing to sit with. The number we are most confident in is the one no primary route would give us.

The expiry board’s absence is arithmetic now, not bad luck — ninth session

For nine consecutive sessions this desk has failed to read an option expiry board for the New York cut. We have treated that as a sourcing problem. It is a scheduling problem, and it is fully determined.

The only publisher we have found that posts strikes with sizes attached posts at about 12:40 UTC. Our three runs read at 23:00, 06:00 and 11:30 UTC. Against a 12:40 posting time:

• The Tokyo run misses it by 820 minutes.
• The pre-London run misses it by 400 minutes.
• This run misses it by 70 minutes — and on today’s actual clock, by 63.

There is no combination of better fetching that fixes a negative number. Four separate routes were tried this morning and all four correctly reported no board for today, because at the hour we asked, no board for today existed. The newest item at that publisher was yesterday’s, posted at 12:40 UTC yesterday, exactly on schedule.

The consequence for today specifically is worth stating because the timing is tight. The board posts at about 12:40. Producer prices land at 13:30, fifty minutes later. The New York cut is at 15:00, one hundred and forty minutes after the board and ninety minutes after the print. So there is a fifty-minute window, between the board appearing and the release, in which you could know where the strikes sit before the event that might run them over. That window is real and our schedule sits entirely outside it. We are publishing this rather than filing it because the fix is a schedule change, not a source hunt, and because nine sessions of calling it a source hunt was wrong.

Our December figure is a day old, and the one reading we found today moved four points

We have been carrying a probability of 10.40 per cent for a further quarter point beyond December’s — derived, reproducibly, from a wire’s own printed figures on Thursday morning. We published it, and then carried it. It is now 23.9 hours old and until this morning nothing had tested it.

One source today gives 14.5 per cent for a fifty basis point December move, naming CME FedWatch as the feed and attributing the snapshot to a wire. That is 4.1 points higher, a 39.4 per cent relative move in a day, and it takes the implied December outcome from 27.6 basis points to 28.6. One publisher, one feed, one snapshot — we are reporting it as that and not as the market’s view.

We also have to flag what sits next to it. The same sentence says the figure is up from zero a week earlier. Our own notes have a reading of 1.4 per cent on Wednesday and 10.40 per cent on Thursday from a named feed, so “zero a week earlier” is not reconcilable with what we hold. We are keeping the level and cutting the comparison, which is the same move we made on a translated note on Thursday and for the same reason: a figure is a figure and a characterisation of its history is editorial.

The general point, since this is a systems note. A derived number you publish and then carry has a half-life, and nothing in your own pipeline marks it. The arithmetic that produced our 10.40 per cent was sound on Thursday and is sound now; what has changed is the input. A stored result with no staleness field is the same defect as the issuer’s month-old page above, committed by us rather than found. The difference is that the issuer at least prints a next-release date.

What this does not tell you

• We do not know why three routes returned empty. Rendering, rate limiting, a layout change, or our own fetch behaviour are all consistent with what we saw. We are describing a failure mode, not diagnosing four vendors.
• We did not read today’s producer-price release. It had not been published when this was written. Every consensus figure here is secondary, and we name the three readers rather than implying a primary source.
• The pre-registration we published this morning on those figures is not scored here. This slot closes before 13:30 UTC, so it cannot be. We are handing it explicitly to the next run rather than letting it decay, and the three legs stand as published.
• The expiry-board posting time is one publisher’s observed habit, established over a handful of sessions, not a published schedule. If it moves, the arithmetic above moves with it.
• The 14.5 per cent is single-sourced and second-hand — a publisher quoting a wire quoting a feed. We did not read the feed.
• The expected-row-count check we propose is untested. It is an obvious idea that we have not run, and we are publishing it as a suggestion rather than as something we have measured.
• Nothing here is a view on producer prices or on the Federal Reserve. It is entirely about what your system can read, when, and whether it can tell the difference between quiet and broken.

Related

• FX events calendar · release times in UTC, Tokyo and London windows
• Signals · how we structure entries around scheduled releases
• Presets · news-window and filter configuration