The Milan METAR Outage That Exposed the Flaw in Polymarket's New Weather Settlement Rule
On the morning of August 31, 2026, the public weather feed for Milan Malpensa Airport went dark. To anyone looking at NOAA or standard data APIs, the last recorded temperature was 25°C, followed by silence. But the airport hadn't stopped observing the weather. Its internal broadcast system was still perfectly functional, telling landing aircraft that the temperature was actually 31°C.
For traders betting on Polymarket's weather brackets, that six-degree gap is a disaster. And it all comes down to a single, flawed rule about what happens when data goes missing.
What Happened at LIMC
Milan Malpensa Airport, ICAO code LIMC, was publishing METAR reports normally during the morning of August 31. The last report before the interruption was timestamped 07:20 UTC and showed a temperature of 25 degrees Celsius. Clear skies. Light winds. Normal conditions.
Then the public METAR stream stopped.
The expected reports at 07:50, 08:20, and 08:50 UTC did not appear. Anyone querying NOAA, the Aviation Weather Center, or a standard METAR API would have seen the same thing. The most recent LIMC temperature was 25 degrees Celsius, and then nothing. The silence looked, from the outside, like a data absence.
But the airport had not stopped observing the weather.
During the entire outage window, LIMC's digital ATIS continued operating normally. A captured arrival ATIS message at 13:20 UTC showed a temperature of 31 degrees Celsius and a dew point of 16. The airport's own broadcast system was telling aircraft exactly what the temperature was. The sensors were functioning. The observation system was functioning. Pilots flying into Malpensa that afternoon had current meteorological information.
The temperature during the METAR silence was not 25 degrees. It was 31 degrees. Six degrees warmer than the stale figure sitting in every public database.
The Architecture That Creates the Gap
Understanding why this happened requires understanding how aviation weather data actually moves from an airport to a prediction market.
Airport sensors measure conditions continuously. Those measurements feed into two separate downstream systems simultaneously. One feeds ATIS, the digital broadcast that aircraft use directly. The other feeds the METAR generation process, which formats the observation into a standardized message and passes it into a chain of regional aggregation systems, then into international OPMET distribution, then to downstream providers like NOAA, then to public APIs, and eventually to whatever data source a prediction market uses for settlement.
ATIS is a short chain. Sensor to broadcast. Two steps.
METAR is a long chain. Sensor to formatter to regional aggregator to OPMET distribution to international relay to downstream provider to public API. Each link can fail independently of every other link.
On August 31, something in that chain failed for LIMC and for several other northern Italian airports simultaneously, including Milan Linate, Bergamo, and Turin. The METAR stream went dark. ATIS kept working. TAF kept updating. Other Italian stations remained available. The underlying weather observation was functioning throughout.
From the perspective of a Polymarket settlement database, the result was no new METAR. From the perspective of the airport, ATIS controllers, and the aircraft landing there all afternoon, the weather was being observed and reported continuously. Those are two completely different situations. Polymarket's rule treats them identically.
The Six Failure Modes That Look the Same
This is the technical core of the problem.
When a public METAR feed shows no new data, that silence can be produced by at least six different underlying causes. An observation genuinely never made. An observation made but the METAR generation process failed locally. A METAR generated correctly but failing to enter the regional aggregation system. A bulletin entering aggregation but lost during routing. International OPMET distribution receiving the message but failing to relay it. A downstream provider not receiving the relay.
Every one of these failure modes produces the same output from the perspective of a downstream query: no data.
Operationally and meteorologically, they are completely different. The first means the weather was genuinely not observed. The last five mean the weather was observed, the observation existed in some form, and the data was lost somewhere in a chain that has nothing to do with whether the temperature at the airport was 25 degrees or 31 degrees.
Polymarket's rule does not distinguish between these cases. It cannot. The rule operates on the output of a data source, not on the underlying observation. If the data source shows nothing by 11:59 PM ET, the market resolves to the lowest bracket, regardless of which of the six failure modes caused the silence.
What the Milan Test Actually Revealed
The August 31 incident was a stress test that Polymarket did not run intentionally but received for free.
Consider the scenario the Milan architecture exposed. A Polymarket weather market is open on the temperature at LIMC. The airport's sensors are working. The ATIS is broadcasting 31 degrees. Aircraft are landing with accurate meteorological data. But the METAR chain has failed somewhere between the regional aggregator and the downstream provider.
By 11:59 PM ET, if the chain has not recovered, the market resolves to the lowest bracket. Not because the temperature was low. Not because the observation failed. Because a segment of the international aviation messaging infrastructure had a bad day.
Traders who correctly predicted that temperatures at Malpensa would be in the high bracket lose. Not because their prediction was wrong. Because the settlement source failed to receive an observation that existed.
That is not a weather market. That is a weather market combined with a proxy bet on the uptime of the OPMET distribution chain. The two markets are priced very differently. Polymarket is selling one and delivering the other.
Why the Deadline Does Not Solve the Problem
The 11:59 PM ET rule addresses a real problem. Markets have to resolve. Indefinite delay is not a workable settlement mechanism. The rule establishes that if the designated data source has not delivered by a specific deadline, something deterministic happens.
But it solves the timing problem while leaving the underlying problem untouched.
The underlying problem is that Polymarket has not defined what no data means. The rule assumes that the presence or absence of data in a specific feed is a reliable proxy for whether an observation occurred at the airport. The Milan incident demonstrated that this assumption can fail. Significantly. By six degrees over the most critical hours of the trading day.
A robust settlement mechanism for weather markets needs to answer three distinct questions that the current rule leaves open.
The first is what the authority hierarchy for observations should be. If METAR is unavailable, does ATIS data constitute a valid observation? Does TAF? Does a manual aviation weather report from the airport itself? Is there a hierarchy of sources, or is METAR the only source that counts regardless of what other evidence exists?
The second is how delayed reports and historical backfills should be treated. METAR records can arrive hours late and still be entered into archives. If the 13:20 LIMC observation from August 31 was eventually backfilled into the historical record after the 11:59 deadline, does it affect settlement? The current rule implies no. But the observation was real.
The third is what happens when contemporaneous evidence contradicts the data source. If ATIS was broadcasting 31 degrees during the METAR outage, and that ATIS record is preserved, what weight does it carry in settlement? The current rule gives it none, because the rule operates only on the designated data source.
None of these questions have answers in the current rule framework.
The Broader Problem With Single-Source Settlement
The Milan incident is a specific case of a general problem with prediction markets that resolve against a single data source.
Any single data source has a failure mode. Traditional financial markets understand this and build redundancy into settlement mechanisms. When a primary price source fails, there are fallback sources, dispute mechanisms, and committee-based resolution processes for edge cases. The systems are designed around the recognition that no single source can be treated as perfectly reliable.
Polymarket's weather markets are resolving against feeds that sit at the end of a multi-hop data chain, where any hop can fail independently, and where failures at some hops produce silences that are indistinguishable from genuine observation gaps. Adding a deadline rule ensures settlement happens. It does not ensure that settlement reflects weather.
For markets where the brackets are narrow and the stakes are meaningful, a six-degree error caused by a METAR chain failure is not a rounding issue. It is the difference between a correct resolution and an incorrect one.
What a Sound Rule Would Require
The fix is not simple. That is worth acknowledging directly.
Building a weather settlement mechanism that correctly handles METAR chain failures requires understanding how OPMET works at a level of detail that is not intuitive for a prediction market engineering team. METAR distribution is an international system with multiple potential failure points, different recovery behaviors, and data products that are technically distinct but cover the same underlying observations.
A rule that says METAR from NOAA or we resolve low is operationally simple. It is also operationally wrong in the cases the Milan incident exposed.
A rule that correctly handles the Milan scenario would need to specify alternative data sources in priority order, define the conditions under which each alternative becomes authoritative, establish a process for evaluating backfilled historical data against the settlement deadline, and provide a mechanism for handling cases where contemporaneous non-METAR evidence contradicts the METAR record.
This is not an impossible rule to write. Aviation meteorologists write rules like this for operational purposes regularly. But it requires subject matter expertise that goes substantially beyond knowing that METAR exists.
The Hard Implication
There is a version of this story where the Milan incident is a minor edge case that affects a handful of markets and is noted in the technical changelog. That version treats METAR chain failures as rare events unlikely to affect markets frequently enough to matter.
The problem is that the Milan outage on August 31 also hit Milan Linate, Bergamo, and Turin simultaneously. Multiple airports. Multiple markets. A single regional failure in the OPMET distribution chain produced identical no data conditions across all of them.
Regional failures are not rare in the OPMET system. International aviation weather distribution is a complex network maintained by organizations across multiple countries with different infrastructure standards and maintenance schedules. The chain fails. Not constantly. But often enough that any weather market that runs for a full year across international airports will encounter this failure mode more than once.
Every time it happens, the question is the same: did the temperature exceed the bracket, or did the METAR chain fail? Polymarket's current rule answers a different question: did the designated data source deliver by 11:59 PM ET?
Those two questions have the same answer most of the time. Milan proved they do not always.
The traders who rely on the rule to reflect the weather that actually occurred at the airport are assuming that the METAR chain is reliable enough that the distinction does not matter. That assumption held until August 31. It did not hold on August 31.
Before the next regional OPMET failure, Polymarket needs a rule that can tell the difference.
Rate this piece — one tap, no signup
Editor-in-Chief
Ezekiel Njuguna is the Editor-in-Chief of Predictions Market Fans, where he helps make probabilistic thinking clear and practical for readers. With a strong focus on quantitative research and market mechanics, he leads the site’s technical guides, including a detailed breakdown of Kalshi Combos. His writing connects economic theory with real-world trading strategy, including practical discussions of how yield-bearing tools can support active bankroll management.
The Weekly Signal
Every Friday — the week's sharpest prediction market analysis, forecasting insights, and data-driven commentary. No noise.
Disclaimer: This content is for informational and educational purposes only. It does not constitute financial advice, investment recommendations, or trading guidance. Prediction market participation involves risk of loss. Always conduct your own research before making any financial decisions.
