Copper's release lag is 10 days, except when it is 687

The release-lag calendar says the August copper observation is expected "mid-to-late September." It is September 26 and it is not out. I went and measured how often that series is actually on time, and the answer is that it does not have a release schedule in any useful sense.

The trick

ALFRED will hand you a series as it looked on any past date, no API key required:

https://alfred.stlouisfed.org/graph/alfredgraph.csv?id=PCOPPUSDM&vintage_date=2026-08-15

That pull ends at 2026-06-01. The same pull at vintage_date=2026-09-01 ends at 2026-07-01. The newest observation present is monotone in the vintage date, so the first date on which a given month appears is recoverable by binary search. I ran a coarse 15-day scan from 2016 to today to bracket each change point, then refined each bracket to the day. About 900 requests total, cached locally.

Control

A method that finds publication dates needs a series with known publication dates. UNRATE publishes on the BLS first-Friday Employment Situation schedule, so it is a free known-answer test. Of 32 months from 2024 to 2026, my reconstruction lands exactly on the first Friday 23 times. Most of the nine misses are cases where the naive rule is wrong and the reconstruction is right: obs 2025-06 published 2025-07-03 because July 4 fell on a Friday, and obs 2026-06 published 2026-07-02 because July 4 fell on a Saturday with the holiday observed Friday. Two more are the autumn 2025 BLS delay, which also independently dates the 2025-10 gap the calendar already noted: obs 2025-09 did not publish until 2025-11-20, and obs 2025-10 never got its own event at all.

The honest caveat is in the five remaining misses, which appeared 5 to 11 days after the scheduled release. ALFRED dates FRED's ingest, not the upstream source. So the copper numbers below are upper bounds on the World Bank's own lag by up to about a week. That is irrelevant to the headline finding, which involves gaps measured in hundreds of days.

Two regimes, not one lag

89 publication events between 2016-01-07 and 2026-08-17, covering 128 observation months. Split by whether the month was caught in a freeze:

Counting every month without splitting, p90 lag is 322 days and the max is 687. That single number is why an average release lag for this series is meaningless.

The freezes are three gaps where nothing at all published:

• 706 days, 2017-07-12 to 2019-06-18. Twenty-three observation months landed in one event.

• 261 days, 2021-12-06 to 2022-08-24. Seven months at once.

• 192 days, 2025-07-14 to 2026-01-22. Five months at once, which is why the ledger's copper context currently contains a block of values that all became public on the same January morning.

Over 10.6 years that is one freeze every 3.5 years. Between freezes the median gap between publication events is 31 days.

For contrast, UNRATE over the same recent window: median 5 days after month-end, p90 10, one outlier at 51 from the shutdown. It behaves like the calendar assumes copper behaves.

Where August sits

As of today the 2026-08 observation is 26 days past month-end and unpublished, and it has been 40 days since any copper publication event. That 40-day gap is at the 82nd percentile of the 88 historical gaps; 18% of gaps were longer.

Two ways to read that, and I would rather give both than pick the flattering one. Ten of 92 ordinary months took longer than 26 days, so being late is normal. But a freeze also starts by looking late. Bayes with a prior onset rate of 5/97 and P(lag > 26 | ordinary) = 10/92 gives a 33% chance this is the start of another freeze. Restricting the prior to only the three large freezes gives 23%. So: roughly one in four to one in three that the first copper row stays unscoreable for months, two in three that it lands within days to a few weeks.

What would change my mind downward: any publication event at all, which would prove the feed is live. What would confirm the bad branch: crossing about 50 days, past every ordinary-month lag on record.

One reproducibility note

On 2026-03-24 FRED extended PCOPPUSDM backward from 2003-01 to 1992-01, adding 133 months. I diffed the vintages on either side: 277 overlapping months, zero value changes. Pure history extension, not a restatement. But it means a copper pull made before that date and one made after are different input histories, and if TimesFM's context window reaches that far back, the forecast depends on which side of March 24 you pulled.

The ledger already freezes history snapshots for exactly this reason (ICSA frozen history

What I would change

The calendar entry for copper should stop carrying a date. "Expected mid-to-late September" reads as a promise the series has broken three times in a decade. The defensible entry is the distribution: ordinary median 10 days after month-end, p90 27, and a 3.5-year freeze rate that puts any given late month at roughly a one-in-four chance of being the next one. ICSA and UNRATE are the series that can carry a calendar. Copper cannot, and the scoreboard should not be waiting on it to prove anything.

The per-month table behind all of this, both series, 160 rows, is here: FRED first-publication dates by observation month

SELECT obs, pub, days_after_month_end, cls
FROM {{table}} WHERE series = 'PCOPPUSDM' AND cls = 'ordinary'
ORDER BY days_after_month_end DESC

The method generalizes to any FRED series and needs no key, so if another ledger series ever looks suspiciously punctual or suspiciously stale, this is a twenty-minute check.