36
heat values per polygon, per day
Acknowledgements
Built and maintained by CrisisReady, with support from the Harvard Data Science Initiative and the Harvard Salata Institute for Climate and Sustainability.
Send us a map. We return daily heat metrics, automatically, forever, built on the same reanalysis data as the IPCC and WMO, at the resolution your community actually needs.
Loading the forecast for all 992 IRIS blocks across Paris…
ERA5 reanalysis covers the globe at hourly resolution, fusing satellite, radiosonde, and station data with a climate model. Scientifically authoritative, but a 28 km grid, not a neighborhood.
Public health teams and city planners need heat exposure for their specific communities, not regional averages. Turning a raw climate grid into per-community metrics takes engineering most teams can't sustain.
For more on the fieldwork and cost math behind this decision, read What a heat risk assessment usually costs, and why we built an API instead.
Any set of polygons, anywhere on Earth. A standard GeoJSON file, the same format used by Google Maps, QGIS, and every modern GIS tool.
Projects start with 10 days of historical data. New days append automatically every morning. No further action required.
A scheduled process updates every active project each morning, blending near-real-time estimates with authoritative ERA5 data as it becomes available.
You don't need to know anything about AWS, databases, or reanalysis pipelines. You need a shape file and an API key.
A GeoJSON FeatureCollection, each feature a named polygon: city districts, census tracts, health zones, river catchments, anything with a boundary.
For every polygon, every day, drawn from the sources in the coverage matrix below.
curl -X POST https://api.heatrisk.io/v1/evaluate \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"project_id": "phoenix-cooling-centers",
"json_obj": { "type": "FeatureCollection", "features": [ ... ] }
}'{
"project_id": "phoenix-cooling-centers",
"status": "ready",
"date": "2026-06-17",
"polygon": "Maricopa County",
"metrics": {
"t2m_c": { "max": 43.3, "mean": 36.1 },
"heat_index_f": { "max": 102.5 },
"utci_c": { "max": 62.3, "category": "beyond_extreme" },
"wbgt_c": { "max": 31.3 }
},
"vulnerability": { "rwi": 0.60, "healthsites_per_10k": 1.2 }
}
Endpoint and shape shown here are illustrative; real credentials come with the real endpoint and the
actual request/response contract in docs/api.md.
UTCI (ISO 15743) and WBGT (ISO 7243) are the physiological and occupational-safety standards, comparable across a dry desert and a humid tropic alike.
WBGT crosses its own hard line at 32°C (suspend moderate/heavy outdoor work) and 35°C (all outdoor work must stop). These are the thresholds occupational-health agencies and emergency managers act on directly.
Standard measurement, 2m above ground.
"Feels like" temperature. Misleading in dry climates.
Radiation + wind + humidity + temp. Comparable across climates.
Occupational threshold. >35°C: stop outdoor work.
All seven projects are live in the API today — and were yesterday, and every morning before that: the five original demo projects plus New York City and Paris, added 2026-07-08.
Oaxaca Highlands and Andalusia both show the faint outline of their full state/region behind the colored sample: the Oaxaca Highlands' 50 municipios are a scattered set of specific farming communities in the Oaxaca state highlands (not Oaxaca de Juárez, the state capital), not one contiguous area, and Andalusia's 120 span Seville province plus neighboring slices of Huelva, Cádiz, and Córdoba — the gaps between them are real neighboring municipios that simply aren't part of this dataset, not missing data. The API works on any set of boundaries you send it, complete or not. New York City (188 neighborhood tabulation areas) and Paris (992 IRIS census blocks, INSEE's finest official geography, each roughly 2,000 residents) joined as demo projects on 2026-07-08: the finest-grained boundaries of any project here, and proof this works on a neighborhood census tract as readily as a county. New York City's most recent day was mild (32.4°C UTCI) rather than extreme, so it sits out of the chart below; Paris's wasn't, and joins it. (Both New York City's and Paris's projects are themselves private — neither org has opted into public access — but their aggregate numbers appear here the same as every other demo city; that's why the downscaling section below counts nine public projects, not these seven.) Each tile's own color scale is relative to that city — dark purple for its coolest polygon, yellow for its hottest — not a shared citywide-danger scale: real neighborhood-to-neighborhood texture from the correction, not how dangerous the day was (see the danger-level bars below for that; see how the correction works for why polygons in the same city differ at all).
Color always reflects each area's real UTCI danger level. Switch metrics and watch bar height move, while the color, the actual physiological risk, doesn't. That gap is the whole reason this API reports four metrics, not one.
Switch to Heat Index: Arizona falls out of first place. Switch to UTCI: it's back on top. Same place, same day: dry air hides what solar radiation is actually doing.
Switch to WBGT: Bangladesh jumps past Arizona and Andalusia. 35.2°C is the ISO threshold where all outdoor work must stop.
Every area here changes rank depending on which lens you use. That's the case for reporting all four, every time, instead of picking just one.
Every project, every day, three sources: hollow provisional cells become solid when ERA5 confirms them, usually within 6 days, and violet forecast cells become provisional as each day arrives — the pipeline's reconciliation, visible.
On June 22, the same day as this page's own Andalusia peak, 119 of 120 municipios hit Extreme-or- beyond UTCI, and, separately, 119 of 120 exceeded the WHO PM2.5 guideline. 118 municipios hit both thresholds on the same day. Écija itself: UTCI 56.2°C, PM2.5 at 18.4 µg/m³.
Share of the trailing 30 days' polygon-readings above the WHO 24-hour PM2.5 guideline (15 µg/m³) — refreshed daily.
Station-measured days shown solid, model days hollow: the same firmness vocabulary the ribbon above already taught, since CAMS-vs-OpenAQ is the same measured-vs-modeled axis as ERA5-vs-Open-Meteo. Five of six cities have at least one real monitor inside a project polygon, up to 11 stations in Maricopa County, and station data always overrides the model. Oaxaca's highlands have none; there, model output is labeled as exactly that.
ERA5-Land's raw grid runs ~9–28 km: one temperature for a canopy-heavy block and an impervious-heavy block a few streets apart. A statistical model, cross-validated per climate zone, corrects each polygon toward its own terrain, canopy, built fraction, surface-temperature structure, and population — and a real weather station, where one sits inside a polygon, overrides the model outright. Four tiers, strictly ordered: a lower one never overwrites a higher one.
Every view below is the same 591 census tracts on real stored days — first what the raw ~9 km reanalysis grid can say, then the corrected field the API actually serves, then the correction itself, the data tier behind every value, and the tract-level covariates the model reads. Hover any tract for its full record.
The raw reanalysis grid value, served whenever no validated correction applies for that zone, target, and band. Always disclosed as such, never silently upgraded.
The model's correction, applied only where its zone, target, and band pass held-out cross-validation. Daytime max passes in 19 of 19 climate zones tested; nighttime min in 15 of 19.
The model correction refined by a distance-weighted blend against real nearby weather stations. Boston & Cambridge is the one public project with this today.
A real station observation inside the polygon itself, overriding every modeled value. 3,977 METAR stations worldwide can ever contribute one.
The correction covers current and forecast data now, each validated on its own terms, not only history — though further out on the forecast, more of a zone's "pass" comes from a flat per-zone adjustment rather than genuine per-polygon differentiation, disclosed per cell on the model page, not folded into one number here. Full per-zone results, the station-coverage map, and the validation methodology are at the model performance page; a shorter reference version is in the docs.
Same relative color scale as the city tour above: each tile shows how its own polygons compare to each other, the real texture the correction adds within one city. Boston & Cambridge has its own full-depth figure above.
Mexico City is one of nine active projects with a public, correctable record. Three more, each telling a different part of the story, as of July 2026:
The only project today with a station-adjusted correction: 934 of 24,231 polygon-days are blended against nearby airport weather stations, on top of 22,319 model-corrected, 972 still on the raw grid, and 6 real in-polygon station readings.
Every one of its 6,244 recorded polygon-days carries a model correction; none are still on the raw grid.
15,453 of 15,596 polygon-days are model-corrected; 140 are still on the raw grid, mostly from before this project's covariates were complete; 3 carry a real in-polygon station reading.
Not every zone clears validation. A project in an excluded zone still returns a usable, disclosed grid value instead of a wrong correction (see the model performance page for the full per-zone picture and where each of the nine public projects stands today).
Every cell and date below is a real count against the live database: the data-completeness audit behind the city tour above, plus the named public source for each of the fourteen data families.
Every cell is a real count against the live database, not a claim. Solid is essentially every area covered. A tint drops off from there, and a hollow cell means only a few areas have the value at all. A faded cell hasn't been extracted here yet. The small dot marks a family where most areas are physically smaller than the satellite pixel the underlying dataset was built on, so the value is present but coarser than it looks.
Heat, baseline, and forecast columns start from ERA5-Land and Open-Meteo's ~9–28 km reanalysis grids. A statistical model corrects each polygon's grid temperature toward its own neighborhood, using terrain, canopy, built fraction, surface-temperature structure, and population, validated separately per climate zone; where a real airport weather station sits inside a polygon, its observed reading overrides the model. The corrected resolution runs roughly 100–300 m where the covariates are richest, coarser elsewhere (see how the correction is validated). Mexico City's row is the most instructive: population, age, and nightlights all show full coverage but a resolution-marginal dot, because 1,182 colonias are individually smaller than several of the source rasters they're drawn from: the data is real, the dot says exactly why it's coarser than it looks.
Every metric on this page traces back to a named, public dataset, not an internal estimate. Grouped by the same category colors used in the matrix above: heat measurement in ember, social/vulnerability indicators in atmos, environment in slate-green, air quality in haze.
A date range and a percentage are two different shapes of fact, so they get two segments per row instead of one misleading average: on the left, every individual Landsat overpass this city's persistent-heat composite draws on, spanning back years at a handful of dates a month. On the right, the daily heat pipeline's dense, unbroken recent window, with the trailing air-quality readings marked on top. The dashed break between them is real: "years" and "days" don't belong on one linear axis.
Ember ticks: one satellite scene date. Ember bar: daily ERA5/Open-Meteo coverage. Haze mark: the air-quality table's first-to-last date on record. Lagos's satellite record is visibly the sparsest of the eight, a real limit on cloud cover and overpass frequency this product hasn't smoothed over.
Back to 1946 — any June since then, per polygon, through the same code that ran this morning. That's the archive's real reach: not a trend claim (nine single hottest-days a decade apart is too little to call a slope), just proof of depth.
Each bar is that June's single hottest day, by heat index, pulled directly from the CDS archive and run through the same computation code the live API uses — not sampled from the daily pipeline, which only holds a rolling recent window. Heat index and 2m air temperature only: these are ERA5-native variables with an unbroken historical record back to 1940. UTCI/WBGT are not shown here because they depend on wind and solar fields sourced from a separate near-real-time archive that doesn't extend this far back. Computed once; historical values don't change.
64 districts, initialized in under 35 minutes. June 23 peak conditions, and "typical" is exactly what the ten-year baseline in the Mexico City deep dive below is built to test.
| District | UTCI °C | WBGT °C | Population |
|---|---|---|---|
| Loading live districts… | |||
Top 8 of 64 districts by UTCI · real ERA5 data
Risk depends on who is exposed and their adaptive capacity. Each indicator is extracted per polygon at project initialization.
82.7M people live in Bangladeshi districts facing both extreme heat stress and below-average wealth, as of July 4.
Each dot is one of Bangladesh's 64 districts — position is heat exposure (UTCI) vs. relative wealth, color is the site's severity tier, size is population. Wealth data (Meta RWI) covers ~93 low- and middle-income countries; for high-income geographies the API substitutes healthcare-access and land-cover indicators.
| District | UTCI °C | RWI | Facilities/10k | Population |
|---|---|---|---|---|
| Sunamganj | 53.5 | −0.21 | 0.10 | 2.9M |
| Sylhet | 52.6 | 0.00 | 0.30 | 4.0M |
| Natore | 52.5 | −0.07 | 0.35 | 2.0M |
| Netrakona | 52.5 | −0.19 | 0.24 | 2.6M |
| Thakurgaon | 52.1 | −0.28 | 0.12 | 1.6M |
| Maulvibazar | 52.0 | −0.08 | 0.18 | 2.2M |
| Mymensingh | 52.0 | −0.08 | 0.26 | 5.9M |
| Lalmonirhat | 51.9 | −0.19 | 0.09 | 1.5M |
Top 8 of 37 qualifying districts, ranked by UTCI · real ERA5 data
Population-weighted age structure per project, from the same WorldPop extraction that already populates every polygon's vulnerability record: no new pipeline work, just a comparison nobody had drawn yet. Residents 65 and older carry the sharpest heat-mortality risk of any age group; under-5s the second sharpest. The nearly 8× spread below reflects eight real demographic profiles sharing one API. Who is exposed and how hot their own neighborhood actually runs are now reported at the same resolution, so the two can be read together instead of a per-polygon vulnerability profile sitting on top of one shared grid-cell temperature.
La Paz County, Arizona: 31.8% elderly, the 4th-highest of the Phoenix project's 17 counties (behind Yavapai, Mohave, and Gila), and 1.15 health facilities per 10,000 residents, 5.9× fewer than Maricopa County's 6.78, while facing the same Beyond-Extreme UTCI severity (60.5°C) as the rest of the state. The heat here is no worse than anywhere else in Arizona; the county just has more people who are vulnerable to it and less capacity to respond. That's what this section's opening line ("risk depends on who is exposed and their adaptive capacity") looks like as three numbers from one polygon.
Lagos's demographic profile isn't the only place it stands apart. Seven of these eight projects show essentially zero mangrove cover in the underlying ESA WorldCover extraction: Lagos alone averages 2.2%, and one polygon, Amuwo Odofin, is 16.1% mangrove and 18.7% open water. Land cover, not just population, is part of what "adaptive capacity" means here: a coastal ecology none of the other seven projects have.
Mexico City runs at colonia resolution — 1,182 neighborhoods, each measured against its own ten-year baseline (2016–2025) of daily peaks for this time of year. This is the API's full output, nothing summarized away.
On June 28, 1,179 of Mexico City's 1,182 colonias ran warmer than usual for the date — each measured against its own ten-year baseline. 3 crossed the 95th percentile.
Warmer than usual. Today's peak topped roughly three of every four days this colonia has seen at this time of year since 2016 — but short of extreme.
The gauge reads from live data — on a normal day it says so. Baseline: 120 monthly reference distributions per colonia, 2016–2025 (WMO-standard decade), matched by day of year.
1,182 colonias make a solid choropleth unreadable at this scale; each one's heat values are corrected toward its own neighborhood rather than shared with the whole grid cell (see the specimen explorer below). Instead, three that each tell part of today's story, located within the city:
A median composite of clear-sky Landsat 8/9 thermal readings across this city's three most recent warm seasons (March–May 2024–2026), each colonia measured against the city's own average, skin temperature, not air temperature. Unlike the raw ERA5 grid, Landsat's ~100 m thermal band resolves individual colonias directly, so this is the first per-colonia map this API has been able to draw at all.
Search any of Mexico City's 1,182 colonias to see every field the API returns for it — 36 heat metrics, 16 ten-year baseline percentiles, 42 vulnerability indicators (including the Landsat persistent-heat composite above), and an Open-Meteo forecast outlook, from one API call.
Loading colonia detail…
These are the five original demo projects, live and not hypothetical: 272 polygons across 5 countries, updating today. New York City and Paris (on the live map above) joined most recently; their own use-case profiles are still in progress.
Data is already flowing. No pilot required to see it work.
Serverless AWS infrastructure: no servers to maintain, scales automatically, costs near-zero when idle.
EventBridge replays this whole flow automatically, every morning at 06:00 UTC, for every active project. ERA5 (~5-day lag) and Open-Meteo (same-day) fill in for each other so today's date is never empty; LandScan sizes the population behind every polygon.
Responds immediately with a project ID and estimated ready time.
LandScan extraction, 10-day ERA5 backfill, heat-metric computation.
06:00 UTC, every morning: confirms yesterday's ERA5 data and refreshes a 7-day forecast, no further action needed.
10-year climatology, computed once per project.
Plain-language risk summary, any time window.
Four functions: API requests, daily updates, WMO computation, async jobs.
Serverless. Scales to zero when idle.
GeoJSON and raster storage, pre-loaded once.
Fires the daily 06:00 UTC trigger.
Async jobs, automatic retries.
Keys and credentials, never hardcoded.
The pipeline keeps growing — some of what's below has already shipped.
PM2.5, PM10, NO₂, O₃, SO₂, and CO alongside heat exposure — live for every demo project, with real ground-station readings (OpenAQ) taking precedence over modeled CAMS values wherever a station exists inside a polygon, and a hierarchical spatial-consistency QC pass to catch sensor faults before they reach an ambient estimate.
Thermal-band satellite imagery, composited into a warm-season baseline per polygon, the first per-colonia surface-temperature map this API has been able to draw at all (the raw ERA5 grid never resolved colonias directly; Landsat's ~100 m thermal band does). In Mexico City this composite already surfaced a 26°C persistent surface-temperature range across colonias — real structural texture the raw ERA5 grid had no way to show at all.
A statistical model, cross-validated per climate zone, corrects each polygon's grid temperature toward its own neighborhood using terrain, canopy, built fraction, surface-temperature structure, and population; heat index, UTCI, and WBGT are re-derived from the corrected value. A real airport weather station inside a polygon overrides the model outright, with a distance-weighted blend against nearby stations between the two. Daytime-maximum correction passes validation in all 19 climate zones tested; nighttime-minimum passes in 15 of 19, serving the raw grid value in the four zones where it does not hold up. The correction now covers current and forecast data as well as history, each validated on its own terms, at a resolution of roughly 100–300 m where covariates are richest. Full per-zone results: the model performance page.
Beyond the existing experimental narrative summary, we're developing and validating a deeper AI interpretation layer that reasons over heat-specific context — physiological thresholds, occupational exposure standards, local vulnerability — rather than generic summarization. Being validated against real pilot data before it ships broadly.
Have a data source your work depends on? Tell us: new variables get evaluated against real pilot use cases, not added speculatively.
A GeoJSON map is all you need. The system initializes and updates every day without further action.
ERA5 is the global scientific standard for atmospheric reanalysis, the same data the world's leading climate agencies use.
Physical exposure alone doesn't predict risk. Vulnerability, the WMO baseline, and AI narrative turn metrics into decisions.
Contact us to request API credentials. We'll set up your account and walk through your first project.
Built and maintained by CrisisReady, with support from the Harvard Data Science Initiative and the Harvard Salata Institute for Climate and Sustainability.