The problem isn’t caching — it’s the model schedule itself
Spend enough time with weather APIs and you notice it: the forecast at 14:30 UTC looks suspiciously similar to what came back at 11:00 UTC. The instinct is to blame caching — yours or the provider’s. Sometimes that’s right. But there’s a more fundamental reason forecasts go stale that has nothing to do with cache TTLs, and it’s worth understanding if freshness actually matters to your application.
NWP (Numerical Weather Prediction) models run on fixed cycles. Between the time a cycle’s data collection ends and the time model output actually becomes available for consumption, a meaningful gap passes. That gap is where applications quietly serve outdated forecasts without knowing it.
How the cycle timings actually work
GFS runs four times per day, initialized at 00, 06, 12, and 18 UTC. Initialization time is not the same as availability time. NOAA’s GFS takes roughly 3.5–5 hours after initialization to finish computing and stage the GRIB2 files. The 12Z run — initialized with observations valid at noon UTC — doesn’t have usable output ready until roughly 15:30–17:00 UTC depending on the forecast hour you’re pulling.
NAM runs the same four-times-daily schedule but is faster out the door — typically 2–3 hours post-initialization — covering a smaller domain at 12km resolution for CONUS, with nest domains down to 3km. HRRR is the rapid-refresh outlier: it runs every hour, with roughly 1.5–2 hours of latency between initialization and availability, and its 3km grid is what makes it actually useful for convective-scale events. If you need to know whether a thunderstorm cell will affect a specific venue in the next three hours, HRRR is the model that matters — and it updates fast enough to make that call meaningful.
ECMWF runs twice daily (00Z and 12Z), with around 5–6 hours before output is broadly accessible through licensed feeds. Higher resolution, slower out the door, worth waiting for on medium-range (3–10 day) windows.
The dead zone
Here’s where it gets operationally relevant. Call it the dead zone: the period after a new model cycle has initialized but before its output is actually available. During that window, any weather API is necessarily serving output from the previous run. For GFS, that window can stretch past 4 hours. A call at 15:00 UTC might return 06Z GFS output — data initialized 9 hours ago, covering observations from 9 hours before that initialization.
That’s a 9-hour-old analysis dressed up as a current forecast. For a 7-day outlook, it doesn’t matter much. For a 2-hour precipitation window in a convective environment, it matters a lot.
Our GRIB2 ingestion pipeline — processing HRRR, NAM, GFS, and ECMWF output continuously — has to make a decision at every run: switch to new model data as soon as it’s available, or wait for a fuller set of forecast hours before flipping. We lean toward switching as soon as a usable subset lands rather than waiting for complete output. The trade-off is that early-available forecast hours (roughly hours 1–24) are fresher than the model’s extended hours, which take longer to compute and stage. Both approaches have costs — stale-by-design or incomplete-by-design. You should know which one your API provider is making.
What this means if you’re building something latency-sensitive
A few concrete patterns worth applying:
Check the obs_time field, not just the request timestamp
Most weather API responses include a model initialization timestamp somewhere in the payload. For our API, current.last_updated_epoch tells you when the underlying data was last refreshed. That field is more honest than your own request timestamp. If the two values are more than 90 minutes apart and you’re consuming HRRR-backed data, something’s off — either on our side or in how you’re caching responses yourself.
Tier your update logic by forecast horizon
A 6-day forecast doesn’t need refreshing every 10 minutes. HRRR updates hourly and covers 0–48 hours. GFS extends to 384 hours but runs only four times daily. Polling both at the same frequency wastes quota and adds nothing for the extended range. A sensible pattern: aggressive refresh (every 30–60 minutes) for hours 0–6, moderate refresh (every 2–3 hours) for hours 6–48, once per model cycle (every 6 hours) for anything beyond that.
For convective-scale applications, HRRR is the only model that matters — but it has geographic limits
HRRR covers CONUS only. If your application operates in Europe, Southeast Asia, or anywhere outside CONUS, you’re on GFS or regional equivalents like ECMWF HRES. The practical consequence is that hourly convective-scale updates become 6-hourly synoptic-scale updates, and your application’s behavior should reflect that. Presenting a 3-hour precipitation forecast derived from 6-hourly model input as precise is misleading to users even when the numbers look plausible.
The model blend problem
Most providers blend model output rather than serving a single model’s raw output. That’s correct behavior — no single model is dominant across all forecast hours and all conditions. But blending obscures which model cycle is driving a given forecast hour, which makes staleness harder to reason about.
We blend: HRRR where available and recent enough, NAM for mid-range CONUS, GFS for extended range and non-CONUS. The honest limitation is that there’s no field in our API response identifying “this specific hour came from HRRR run 14Z.” That level of provenance isn’t surfaced. A previous post covered what you can reverse-engineer from response fields — though from the angle of data interpretation rather than model scheduling.
If your use case genuinely requires knowing the source model run, the only clean path is pulling GRIB2 files from NOAA’s NOMADS server directly and doing your own extraction. That’s a non-trivial ingestion problem: the files are large, grid coordinates require proper interpolation, and you’ll need to handle production latency yourself. Most developers correctly conclude that consuming a polished API and accepting the provenance opacity is the right trade-off. Just don’t mistake that trade-off for a guarantee of real-time freshness.
The number worth remembering
In the worst case — calling the API just after a new GFS cycle has initialized but before its output has landed — you’re looking at data from a cycle initialized 10+ hours ago. For most use cases, that’s fine. For real-time operational decisions — sports event planning, construction site safety calls, logistics dispatch — the model age at call time is worth checking explicitly, not assumed away.
Pull last_updated_epoch, compare it against the current Unix timestamp, and build that delta into whatever threshold logic drives your application. The question isn’t whether you got a fresh API response. It’s how old the model run behind that response actually is.