If you’ve ever pulled a current-conditions response and a same-hour forecast response for the same location and compared temp_c between them, you’ve probably noticed they don’t always agree. Sometimes the delta is under half a degree. Sometimes it’s three or four degrees and you start wondering which one is wrong.
Neither is necessarily wrong. They’re measuring different things, computed from different sources, and the mismatch is structural — not a bug you can file a support ticket about.
What Each Value Actually Represents
current.temp_c in a realtime response is observation-based. It’s pulled from a METAR station (or the closest acceptable one after our station-selection scoring runs), and it reflects actual reported conditions — typically updated every 30 to 60 minutes depending on the station type. What you’re getting is a recent physical measurement, decoded from a METAR string, possibly corrected for elevation difference between the station and the requested coordinate using a standard lapse rate (~6.5°C per 1,000 meters of gain).
hour.temp_c from the forecast endpoint is different in kind. It’s a model output — interpolated from GFS or HRRR grid cells covering the area, blended and post-processed into a point estimate. The model was initialized some hours before your request, the output decoded from GRIB2, and by the time you’re asking for 14:00 local time, that temperature was baked in during the most recent model run — possibly 6 to 12 hours earlier.
So when you compare them at the same nominal hour, you’re comparing a raw observation against a model prediction finalized hours ago. The divergence isn’t random. It has specific causes.
The Main Reasons They Diverge
1. Model Initialization Lag
GFS runs four times a day: 00Z, 06Z, 12Z, 18Z. HRRR runs hourly but only out to 18 or 48 hours depending on the cycle. The forecast value you’re receiving was generated from the most recently ingested model run — but ingestion, processing, and serving adds latency. In our pipeline we decode GRIB2 output, write point-based estimates for tens of thousands of locations, and cache the result. A forecast for 14:00 local might have been generated from a 06Z GFS run ingested mid-morning. That’s a real gap.
If conditions deviated from model expectations in the intervening hours — a convective system moved in, a sea breeze arrived earlier than forecast — the observation sees it and the forecast doesn’t. This is especially visible in locations with strong local effects.
2. Station Representativeness
Current conditions use the best-available METAR station for the requested point, not the grid cell the model used. Those are rarely the same physical location. If the nearest station sits at a different elevation or on the opposite side of a ridge, the corrected observation and the model estimate are inherently measuring slightly different physical situations. The lapse-rate correction helps, but it’s a standard atmospheric average, not a terrain-specific measurement. On calm nights with strong inversions, actual valley temperatures can diverge sharply from what any lapse rate predicts — the observation will catch it; the model usually won’t.
3. Observation Timing vs. Hour Alignment
METARs are not issued precisely on the hour. A routine METAR typically comes out at 50 or 55 minutes past, so a request at 14:30 may be returning an observation recorded at 13:53. The forecast for hour 14 is a model estimate centered on that hour. If temperature is changing fast — a frontal passage, rapid heating after cloud clearance — a 37-minute offset in the observation is not trivial.
Detecting the Gap in Your Application
The first thing worth building is a simple delta monitor. Pull both current.temp_c and the matching hourly forecast value for the same timestamp and log the difference. Be deliberate about which forecast hour you compare against — use the hour whose time_epoch is closest to current.last_updated_epoch, not the current clock hour.
// Pseudocode — adapt to your language
const obsEpoch = response.current.last_updated_epoch;
const closestHour = response.forecast.forecastday[0].hour
.reduce((prev, curr) =>
Math.abs(curr.time_epoch - obsEpoch) < Math.abs(prev.time_epoch - obsEpoch)
? curr : prev
);
const delta = Math.abs(response.current.temp_c - closestHour.temp_c);
if (delta > 2.5) {
// Flag this response — observation and forecast disagree materially
log.warn(`Temp delta ${delta}°C at ${response.location.name}`);
}A delta above roughly 2.5°C is worth surfacing to your logging layer. Above 4–5°C you’ve almost certainly hit one of the structural causes above — either the model didn’t see what actually happened, or the station isn’t representative of the requested location.
What to Show Users When There’s a Mismatch
Default to current.temp_c for the “right now” display — it’s observation-based and fresher than any model output. Using forecast values as a stand-in for “current” is the source of most user-facing confusion about this mismatch.
Where it gets harder is near-future hours — two or three hours out. You only have model output for those. If the current observation is already 3°C warmer than the model predicted for now, expect the next couple of forecast hours to also run cool relative to what actually materializes. A simple observation-based bias correction helps: take the current delta and fade it out over the next few hours rather than trusting the raw model output unchanged.
// Rough bias correction over next N hours
const biasDelta = currentObsTemp - currentHourForecastTemp;
const fadeHours = 3;
correctedForecasts = upcomingHours.map((h, idx) => ({
...h,
temp_c_corrected: h.temp_c + biasDelta * Math.max(0, (fadeHours - idx) / fadeHours)
}));This is not a rigorous NWP bias correction — that would require ensemble spread data we don’t expose. But a linear fade from the observed offset toward zero over a few hours beats serving raw model output when you already know it’s wrong for the current hour.
When the Delta Is Actually Telling You Something
A large mismatch can be a useful signal in itself. If current.temp_c is significantly colder than the forecast for this hour and pressure is falling, that’s consistent with a cold front arriving ahead of schedule. If it’s warmer, the model may be underestimating daytime heating — common in summer over urban areas where the GFS 13km grid doesn’t resolve local heat island effects. HRRR at 3km handles this better, but it only covers CONUS and only out to 48 hours on extended runs.
For locations outside HRRR coverage — most of Europe, Asia, anywhere GFS is carrying the near-term hourly load — grid resolution alone means some local effects are simply absent from the model. The observation will see them. Build around that rather than assuming the two values will converge.
One Hard Caveat
None of this substitutes for genuine forecast verification at scale. For that you’d want historical API responses stored with timestamps, matched against later observations, and tracked across model runs. A single real-time comparison is a snapshot; systematic bias needs systematic measurement. We’re exploring historical data licensing partly for this reason — longitudinal analysis is genuinely hard to do from a real-time API alone.
If you’re already logging API responses, start collecting last_updated_epoch alongside the temperature delta. A week of data will show you which locations in your user base are chronically mismatched. In our experience those are almost always locations where the METAR station is a poor representative for the requested coordinate — which is a station-selection problem, not a model problem, and it’s solvable from a different direction entirely.