Polymarket Weather Resolution Checker (METAR / NOAA) avatar

Polymarket Weather Resolution Checker (METAR / NOAA)

Pricing

from $2.00 / 1,000 bracket resolution checks

Go to Apify Store
Polymarket Weather Resolution Checker (METAR / NOAA)

Polymarket Weather Resolution Checker (METAR / NOAA)

Check how a Polymarket daily-temperature market will resolve before it does. Per bracket: the running high/low at the rules' station from METAR, YES/NO locked or final, market price, confidence and a plain-English reason. Pay per bracket. METAR proxy, not the official reading.

Pricing

from $2.00 / 1,000 bracket resolution checks

Rating

0.0

(0)

Developer

Jack Sheward

Jack Sheward

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

20 hours ago

Last modified

Share

Check how a Polymarket daily-temperature market will resolve before it does.

Give it a Polymarket "Highest / Lowest temperature in

  • the running high or low so far (in the market's unit and whole degrees), with report count and last report time;
  • whether the bracket is already decided: YES_LOCKED, NO_LOCKED, UNDECIDED, and FINAL_YES / FINAL_NO once the local day is over;
  • the current market price and implied probability, a confidence grade, and a one-sentence plain-English reason.

No login, no API key, no browser. It uses Polymarket's public market-data API and aviationweather.gov. The default run (three cities, daily high) takes a few seconds.

This is a proxy, not the official reading. Polymarket resolves on a named weather-station page, not on METAR. The observed value here is derived from the same station's METAR/SPECI reports and can differ from the official one by about a degree (rounding, a missing or late report, a non-METAR reading). Every row says so, and the confidence grade accounts for it. See How accurate is it?

How Polymarket's temperature markets resolve

Read from the live rules text of all 229 open events on 2026-09-30 (each row repeats what its own market says):

  • The winning bracket is the one containing the day's highest (or lowest) temperature reading at one named station, in whole degrees (°F for US cities, °C elsewhere), for the station-local calendar day.
  • Source. For 48 of 51 cities the rules name NOAA's weather.gov/wrh/timeseries?site=<ICAO> page (the "Temp" column; the hourly data for US °F cities). Weather Underground (the station's history / daily observations table) is the documented fallback if NOAA has no data by 11:59 PM ET the next day, and the primary source for Taipei and Jinan. Hong Kong resolves on the Hong Kong Observatory's "Absolute Daily Max/Min" to 0.1 °C.
  • The market resolves once the first data point for the next date is published (or by 11:59 PM ET the day after). With no data at all it resolves to the lowest bracket. Later revisions are not considered.
  • Brackets are 2 °F wide for US cities (66-67°F, plus 65°F or below / 84°F or higher) and 1 °C wide elsewhere (20°C, plus 15°C or below / 26°C or higher).

Weather Underground is in this actor's title because the rules name it as the fallback source (and as the primary one for Taipei and Jinan); for most cities the page that decides is NOAA's.

resolution_source, resolution_source_url and fallback_source on every row come from the market's rules text, and station_icao is cross-checked against this actor's own station table. If they disagree you get a free station_mismatch notice, the rules' station is used, and the rows are graded low.

What you get

One dataset. record_type is the first field.

record_typeOne row perBilled
resolution_checkbracket market with real METAR evidenceresolution-check
noticeexplanation: bad input, not a weather market, no market for that date, unsupported city, no observations, station mismatch...free

Key resolution_check fields

FieldExampleNotes
event_slug, market_slug, market_url, question, bracket_labelhighest-temperature-in-nyc-on-september-29-2026, 70-71°Fbracket_low / bracket_high are the inclusive whole-degree bounds (null = open end)
city, event_date, metric, unitNYC, 2026-09-29, high, Fevent_date is the station-local date
station_icao, station_name, station_checkKLGA, LaGuardia Airport Station, matchstation parsed from the rules; match / mismatch / unlisted vs this actor's table
resolution_source, resolution_source_url, fallback_sourceNOAA, https://www.weather.gov/wrh/timeseries?site=klga, Wundergroundstraight from the rules text
observed_value, observed_value_c, extreme_reports, observed_at_utc70, 21.1, 4, 2026-09-29T16:51:00Zrunning max (high markets) or min (low markets) so far, in the market's whole-degree unit; how many reports show that value; when it was first reached
obs_count, first_obs_utc, last_obs_utc, max_obs_gap_minutes25, ..., 60.0METAR + SPECI reports inside the station-local day; longest hole between reports
day_complete, timezonetrue, America/New_Yorkthe local day is over and a next-day report is in the feed (or 2 h have passed)
bracket_statusFINAL_YESsee below
confidence, confidence_reasonsmedium, ["within_1_degree_of_bracket_edge"]see below
market_status, polymarket_result, proxy_matches_polymarketresolved, yes, truefor already-resolved markets: Polymarket's actual result and whether our verdict agrees
yes_price, no_price, implied_probability, best_bid, best_ask, last_trade_price, price_flag, price_as_of0.66, 0.34, 0.66, ...Gamma outcomePrices (cached up to ~5 min). On thin books the displayed price can be a midpoint, so price_flag says ok / wide_spread / no_bid / no_book / resolved
explanationsee belowone sentence, always carries the proxy caveat

bracket_status

StatusMeaning
NO_LOCKEDThe bracket can no longer win. HIGH market: the max so far is already above the bracket's top (a daily high cannot fall). LOW market: the min so far is already below the bracket's bottom (a daily low cannot rise).
YES_LOCKEDAn open-ended bracket that can no longer lose: a high already inside "X or higher", or a low already inside "X or below".
UNDECIDEDCould still go either way before the station-local day ends.
FINAL_YES / FINAL_NOThe station-local day is complete: the bracket does / does not contain the observed extreme.

A bracket in the middle (say 70-71°F with a high of 70 so far) stays UNDECIDED until the day is complete: the high could still rise out of it.

confidence

The grade says how safely the verdict survives a proxy error of about a degree.

GradeWhen
highdecided (locked or final), clean data, and 3+ whole degrees from the bracket's nearest edge
medium2 degrees from an edge; or within 1 degree of an edge on a completed day with a corroborated extreme (the winning 1-2 degree bracket is always within 1 degree of its own edge, so a correct FINAL_YES is never better than medium); or the verdict would flip if the single most extreme report were missing; or the next-day report has not been seen yet
lowUNDECIDED (day incomplete); within 1 degree of an edge while the day is still running; within 1 degree and the extreme rests on a single report; a gap of more than 150 minutes between reports; fewer than 4 reports on a finished day; stale reports (no report for 3 h on a running day); or a station mismatch

confidence_reasons lists every trigger, e.g. ["day_incomplete_bracket_undecided", "within_2_degrees_of_bracket_edge"].

Example output (real rows)

A finished, already-resolved day (NYC high, 2026-09-29). Polymarket's winner was 70-71°F; our verdict matches:

{
"record_type": "resolution_check",
"event_slug": "highest-temperature-in-nyc-on-september-29-2026",
"market_slug": "highest-temperature-in-nyc-on-september-29-2026-70-71f",
"bracket_label": "70-71°F", "bracket_low": 70, "bracket_high": 71,
"city": "NYC", "event_date": "2026-09-29", "metric": "high", "unit": "F",
"station_icao": "KLGA", "station_name": "LaGuardia Airport Station", "station_check": "match",
"resolution_source": "NOAA", "resolution_source_url": "https://www.weather.gov/wrh/timeseries?site=klga",
"fallback_source": "Wunderground",
"observed_value": 70, "observed_value_c": 21.1, "extreme_reports": 4, "observed_at_utc": "2026-09-29T16:51:00Z",
"obs_count": 25, "first_obs_utc": "2026-09-29T04:51:00Z", "last_obs_utc": "2026-09-30T03:51:00Z",
"max_obs_gap_minutes": 60.0, "timezone": "America/New_York", "day_complete": true,
"bracket_status": "FINAL_YES", "confidence": "medium", "confidence_reasons": ["within_1_degree_of_bracket_edge"],
"market_status": "resolved", "polymarket_result": "yes", "proxy_matches_polymarket": true,
"yes_price": 1.0, "no_price": 0.0, "implied_probability": 1.0, "price_flag": "resolved",
"explanation": "The station-local day is complete and the observed high at KLGA was 70°F, inside the \"70-71°F\" bracket, so it resolves YES on the METAR proxy - within 1 degree of the bracket edge, so the official reading could land on the other side; Polymarket has resolved this bracket YES (METAR proxy, the official source can differ by about 1 degree).",
"observation_source": "aviationweather.gov METAR/SPECI", "checked_at": "2026-10-01T02:36:10Z"
}

A day still running (London high, 2026-10-01, 03:35 local, 7 reports so far, highest 19 °C):

bracket_labelbracket_statusconfidenceyes_priceexplanation (shortened)
16°C or belowNO_LOCKEDhigh0.0005NO is locked in: the high so far is 19°C, already above the bracket's top, and a daily high cannot fall
18°CNO_LOCKEDlow0.0005...already above the bracket (top 18°C)... within 1 degree of the bracket edge
19°CUNDECIDEDlow0.0265Undecided: the high so far is 19°C, inside the bracket, the day is still running, so it could still rise out of it
21°CUNDECIDEDlow0.66Undecided: the high so far is 19°C, outside the bracket, so it could still rise into it

Bad input comes back as free rows, for example {"record_type": "notice", "notice_code": "not_weather_market", "message": "\"ballon-dor-winner-2026\" is a Polymarket event (\"Ballon d'Or Winner 2026\") but not a daily highest/lowest temperature market, so there is no weather resolution to check. Nothing was charged."}.

How the check works

  1. Fetch the event from Polymarket (Gamma API): its rules text, brackets and current prices.
  2. Parse the station (ICAO) and unit from the rules; cross-check the station against the built-in table of the 51 current cities (49 return evidence rows; Hong Kong and Jinan return a free notice, see Input).
  3. Take the station-local calendar day (midnight to midnight local clock time, DST-aware) and fetch the station's METAR and SPECI reports for it from aviationweather.gov (history for about 30 days).
  4. Running extreme = max (high markets) or min (low markets) of the day's reports. US stations: the METAR T-group tenths of °C converted to °F and rounded half-up to a whole °F (floor(°C × 1.8 + 32 + 0.5), the value NOAA shows). Other stations: the reported whole °C.
  5. Status per bracket (table above), confidence grade, explanation.

Reports outside the local day are ignored (a 23:51 report of the evening before and the 00:00 report of the next day are both excluded). Nothing is ever estimated: with no reports there is no evidence row, only a free notice.

How accurate is it?

Measured on resolved markets: the bracket our FINAL_YES names versus the bracket Polymarket actually resolved YES.

  • The actor itself, resolved days 2026-09-29 and 2026-09-30, every city with a market, high and low: 188 of 188 events matched (49 cities; all 2,068 bracket rows agree with Polymarket's result, proxy_matches_polymarket = true).
  • Backtest, 2026-09-08 to 09-30, 2,197 resolved events at 49 stations (same logic, replayed offline): 2,185 matched (99.45%). That is 483 of 484 for °F stations and 1,702 of 1,713 for °C stations, and 2,095 of 2,099 (99.8%) if the one bad day (2026-09-20) is left out. The station-local clock day (DST-aware) beat the NWS-style local-standard-time day (2,185 vs 2,134 matches), and counting SPECI reports beat routine METARs only (2,185 vs 2,178).
  • The 12 misses, all investigated. None was rounding, a wrong station or the day boundary. 8 fell on 2026-09-20, when 5 Asian daily highs and 3 European / Middle-East daily lows differed from every report we had for roughly 03:20-07:00 UTC (the official page appears to have been missing those reports). 3 were Manila (RPLL) lows where one evening or SPECI report that we count was not in the official data. 1 was San Francisco on 2026-09-21, where the official low sat below every METAR/SPECI (a non-METAR reading). 7 of the 12 had an extreme resting on a single report.
  • The grade is calibrated against that backtest (accuracy of our FINAL_YES verdict, by the grade the row gets):
FINAL_YES gradedEventsMatched Polymarket
high7100%
medium1,61399.7%
low57798.8%

So: right about 99.5% of the time on completed days, and the grade separates the verdicts that are more likely to flip. It is not a guarantee, and it is not the official value. The 44 of 188 verdicts graded low in the live check above were all correct too; low means "less safe", not "wrong".

Known limitations

  • Proxy, not source. The official page can lack reports METAR has (late or dropped reports, as on 2026-09-20) and can contain a reading METAR does not (one San Francisco low in the backtest). Either moves the extreme by a degree or more, which is what the grade and extreme_reports are for.
  • Hong Kong (Hong Kong Observatory daily extract, 0.1 °C) and Jinan (no METAR feed) return free notices.
  • History is about 30 days (the aviationweather.gov archive). Older days return a free notice that names the bracket Polymarket resolved.
  • Prices are Polymarket's displayed prices (up to about 5 minutes old, midpoints on thin books).
  • At most 40 events per run; new Polymarket cities need a table update.

Input

Every field is optional, but an empty input returns a free note (nothing is run).

FieldTypeDefaultWhat it does
marketslist of strings[]Polymarket event or bracket URLs or slugs (up to 50). Event = all brackets, bracket = just that one.
citieslist of strings[] (form prefill: NYC, Chicago, London)City names as Polymarket titles them, aliases (New York, LA, SF, CDMX), the station (KLGA) or "Chicago low".
datestringtodayStation-local date for cities: today, yesterday, tomorrow, -2d, +1d, 2026-09-29, September 29. Past days that have resolved work for ~30 days.
metrichigh | low | bothhighWhich market for cities.

At most 40 events are checked per run. Both markets and cities are used when both are filled.

{ "cities": ["NYC", "Chicago", "London"], "date": "today", "metric": "high" }
{ "markets": ["https://polymarket.com/event/highest-temperature-in-nyc-on-september-30-2026"] }
{ "cities": ["Tokyo", "Paris"], "date": "yesterday", "metric": "both" }

Supported cities: NYC, Chicago, Denver, Dallas, Atlanta, Miami, Austin, Houston, Seattle, Los Angeles, San Francisco, Toronto, Mexico City, Panama City, Sao Paulo, Buenos Aires, London, Paris, Amsterdam, Munich, Milan, Madrid, Warsaw, Helsinki, Moscow, Ankara, Istanbul, Tel Aviv, Jeddah, Karachi, Lucknow, Cape Town, Singapore, Kuala Lumpur, Manila, Beijing, Shanghai, Qingdao, Jinan, Zhengzhou, Wuhan, Chengdu, Chongqing, Guangzhou, Shenzhen, Taipei, Seoul (Incheon), Busan, Tokyo, Wellington. Hong Kong is recognised but returns a free notice (it resolves on the Hong Kong Observatory's 0.1 °C reading, which is not a METAR value). Jinan has no METAR feed on aviationweather.gov, so it returns a free notice too. New Polymarket cities need a table update (they come back as a free notice).

Pricing

Pay per event. You only pay for rows you actually receive.

EventPriceWhen
actor-start$0.005once per run, only when at least one bracket check is delivered
resolution-check$0.002per bracket row backed by METAR evidence
notice rowsfreebad input, non-weather markets, no market for the date, unsupported city, no observations

A run that returns only notices costs nothing, not even the start fee. If your maximum cost per run cannot cover the start plus one check, nothing is charged and you get a notice. When the budget runs out mid-run, the rows that fit are delivered and a free charge_limit notice says how many were not.

Typical bills: one city-day-metric event (11 brackets) is about $0.027; the default run (three cities, daily high, 33 brackets) is about $0.071. To spend less, check single brackets (a bracket URL is one row) or fewer cities.

FAQ

Does Polymarket resolve on Wunderground? Mostly not, according to the rules text read on 2026-09-30. The rules of 48 of 51 cities name NOAA's weather.gov timeseries page, with Weather Underground as a fallback (and as the primary source for Taipei and Jinan). The actor tells you per market which one applies. METAR is the common ground: both pages are built from the station's METAR/SPECI reports.

Why is every correct FINAL_YES only medium? Because the winning bracket is only 1-2 whole degrees wide, so a one-degree difference between our METAR value and the official page would move the answer. medium means "clean data, corroborated extreme"; the 99.7% hit rate of medium verdicts in the backtest above is the empirical side of that.

Which day does it use? The station-local calendar day on the station's clock, including daylight saving (what the market rules say: "for all times on this day"). Kalshi's NWS climate day (local standard time) is a different convention, covered by the Kalshi checker below.

What if the market already resolved? You still get rows (billed like any other): our verdict next to polymarket_result, and proxy_matches_polymarket per bracket. That is also how you can audit the proxy yourself.

What if the day is too old or hasn't started? More than ~30 days back, or a day that has not started, comes back as a free notice (the former names the bracket Polymarket resolved). It never invents a value.

Is the price a probability? It is Polymarket's displayed price (outcomePrices), cached for up to about 5 minutes. On empty or one-sided books it can be a midpoint, which price_flag marks.

Is this official or investment advice? No. This is an unofficial tool, not affiliated with or endorsed by Polymarket, NOAA, Weather Underground or the Hong Kong Observatory. It reads Polymarket's public market-data API (no scraping of polymarket.com, no wallet data, no trading) and aviationweather.gov (US public domain). You are responsible for complying with Polymarket's Terms of Use. Nothing here is investment advice.

For AI agents (Apify MCP server)

  • Inputs are forgiving: lists or newline-separated strings, URLs or slugs, city aliases, "Chicago low", dates like yesterday. Bad entries become free notice rows, never a failed run.
  • Rows are flat and self-describing: bracket_status and confidence answer "is it decided, and how sure", and explanation is a ready-to-quote sentence.
  • Useful questions: "Which NYC high brackets are already dead?" (bracket_status = NO_LOCKED), "Has the Tokyo high already locked a YES?" (YES_LOCKED / FINAL_YES), "Did the proxy agree with Polymarket yesterday?" (date: yesterday, proxy_matches_polymarket).