The Model Run Timestamp Is Not the Data Timestamp
The timestamp on a weather API response tells you when the forecast is valid, not when the underlying model finished running or when the data was ingested into the API you’re calling. Those three things can be hours apart — and almost no API documentation says this clearly.
It matters most when your app makes decisions based on how fresh the forecast is. Most apps do, implicitly, even when they don’t say so.
How Model Runs Actually Work
GFS runs four times a day at 00Z, 06Z, 12Z, and 18Z. But “runs at 00Z” means the model’s initialization cutoff is 00Z — GRIB2 output files don’t start appearing on NOAA’s NOMADS servers until roughly 00Z+3h30m to 00Z+5h for the full global run, depending on which forecast hours you’re pulling. The early hours (f000 through f048) come out faster; the long-range files (f240 and beyond) trickle in much later.
HRRR is a different situation. It runs hourly, initializes quickly (analysis fields start posting around 45 minutes after the top of the hour), and covers only CONUS at 3km resolution — which is exactly why it’s valuable for sub-6-hour convective forecasts. But “runs hourly” doesn’t mean “available every hour on the hour.” There’s still a latency window, and missing it means you’re serving the previous run’s output, which is now nearly two hours stale.
NAM runs four times daily like GFS, but with a shorter forecast horizon and a nested grid structure that makes partial-availability timing messier to track.
Our GRIB2 ingestion pipeline handles all three, and the operational reality is that you build polling and retry logic specifically around knowing these windows, because NOAA’s delivery isn’t perfectly punctual. Delays of 20–40 minutes past the expected availability window aren’t rare. You either account for that in your pipeline or you silently serve stale data.
What This Means for API Responses
When you call a forecast endpoint and get back hourly data, what model run is actually powering it? That’s almost never surfaced directly in the response. It depends on:
- Which models the API provider ingests (not all ingest HRRR)
- When the last successful ingest completed for your requested region
- Whether the provider blends multiple model outputs or picks one per location
If you’re calling at 14:30 UTC and the API is backed by GFS, the most recently available run is probably 06Z — not 12Z, which won’t finish propagating until around 17:00–17:30 UTC at the earliest. Your “current” forecast is built on initialization data that’s 8+ hours old. For a 3-day forecast, that’s mostly fine. For nowcasting or anything tracking a fast-moving convective system, 8-hour-old GFS is a real problem.
HRRR changes that calculus significantly for CONUS locations. A valid HRRR run from 13Z, available around 13:50Z, is far more useful for a 14:30Z query than 06Z GFS. The question is whether the API you’re calling is actually pulling from HRRR at that cadence, or only for certain parameters.
The Blending Problem
Most production forecast APIs don’t serve a single model output — they blend. HRRR for short-range in CONUS, GFS or ECMWF for medium-range, maybe NAM for mesoscale detail in the 0–48h window. Blending improves skill scores on average, but it makes data provenance opaque. The temperature forecast for hour 2 might be HRRR-derived; the hour-72 temperature is almost certainly GFS or ECMWF. The crossover point is rarely documented, and the lag characteristics of each source are different.
Freshness isn’t a single number for a blended response — it varies by forecast hour within the same API call. That’s worth knowing before you build anything that makes strong assumptions about how current the data is.
What You Can Actually Do About It
Don’t cache blindly on wall-clock time
A flat 15-minute TTL sounds reasonable but it’s disconnected from how model data actually moves. The forecast for the next 6 hours isn’t going to meaningfully change between your 14:30 and 14:45 calls unless a new HRRR run just landed. The forecast for 3 days out isn’t going to change until the next GFS run. Cache by forecast horizon instead: refresh aggressively near the top of each hour for short-range (0–6h) when HRRR output is becoming available, and use a 3–4 hour TTL for anything beyond 48h.
Check the obs_time or last_updated field if it’s exposed
Some APIs surface when the underlying model run was valid. If that field is available, use it to decide whether to re-fetch. If you queried at 13:55 and last_updated shows 13:00, you’re likely on the current HRRR run. If last_updated shows 10:00, something’s off — either the ingest pipeline is delayed or you’re getting cached output from several runs ago.
For time-sensitive applications, query with explicit time parameters
If your application is making a decision about conditions in the next 90 minutes, pass the target datetime explicitly rather than relying on a “current forecast” inference. At minimum it forces you to think about what you’re actually asking for, and it gives the API a cleaner lookup path.
Know your latency tolerance before picking a model tier
If you’re building something for agriculture or energy scheduling 5–10 days out, ECMWF-backed data matters and HRRR freshness is mostly irrelevant. If you’re building a construction site safety tool that needs to flag high-wind conditions in the next 3 hours, you need HRRR or equivalent, and you need to confirm the API you’re calling actually serves it at hourly resolution. Those are genuinely different products. It’s worth asking explicitly rather than assuming “forecast API” covers both use cases.
The Honest Caveat
No weather API — ours included — surfaces full model run provenance per forecast hour in a standard response. That information exists internally (we track which run each forecast hour came from in our pipeline), but I’m not aware of any API that exposes it in a structured way today. So some of what I’ve described above requires reasoning from indirect signals: last_updated timestamps, known model run schedules, and your own understanding of which models cover your region.
ECMWF publishes its own data availability timelines. NOAA publishes HRRR and GFS run schedules at nominal resolution on NOMADS. If you’re building anything sensitive to forecast freshness, those pages are worth bookmarking and cross-referencing against what your API is actually returning.
The next time a forecast looks suspiciously stale during a fast-moving weather event, the first question isn’t whether the API is broken — it’s whether you’re looking at the right model run for your time horizon at all.