This content originally appeared on HackerNoon and was authored by oleksii_schastlyvyi
\ Here's something almost no weather app tells you: the timestamp on a radar frame is not the age of the data you're looking at. It's the age of the composite – the moment when hundreds of individual station scans were assembled into a single image. The pixel over your exact location might be 3 minutes old. The pixel 40 kilometers away might be 28 minutes old. Both sit under the same label.
This isn't a bug. It's how composite radar works. And for years, the industry has been perfectly happy not explaining it. At Rain Viewer, we recently decided to stop being part of that silence.
What's actually inside a radar frame
A composite radar map is assembled from 1,200+ ground stations, each scanning on its own schedule. Roughly half update every 5 minutes – mostly stations in dense, well-funded networks. The rest update every 10–15 minutes, or sporadically. Some go offline briefly and return.
The pipeline takes these asynchronous feeds, reprojects them to a common grid, resolves conflicts where coverage overlaps, and stamps a single frame time on the output. That frame time is when the mosaic finished rendering – not when any particular station scanned.
We just weren't telling users.
What "LIVE" actually means
The LIVE badge in weather apps – including ours – signals that the app is fetching the latest available composite as fast as possible. It's a statement about polling behavior, not data age. In LIVE mode, you're seeing the most recent frame the radar network has produced. That frame might still be 8–15 minutes old, because that's the pipeline latency: station scan, upload, processing, composite assembly, CDN delivery, app render.
The badge isn't dishonest in a narrow technical sense. But it creates a strong user expectation – immediacy – that the underlying data frequently can't meet. And because no weather app shows per-location freshness, users have no way to calibrate that expectation. When data is stale and reality doesn't match, the mental model they reach for is "the app is wrong" – not "the data covering my street is 25 minutes old."
We saw this pattern clearly in Rain Viewer support tickets. The complaint was almost always the same: radar showed rain, no rain came, or the opposite. In a meaningful portion of those cases, the user was in a region with sparse coverage. The data was old. They had no way to know.
Why we sat on this for two years
Surfacing freshness indicators is straightforward technically – we had the pixel-level data. The hesitation was competitive optics. A yellow "slightly delayed" label over your location, while a competitor shows a clean green LIVE badge over the same data, feels like losing. There's a rational case for hiding the delay: users don't know what they don't know, the competitor looks more confident, and "we show you problems others hide" is a hard message to land in a 3-second first impression.
We eventually decided this reasoning was wrong, for a simple reason: users were already noticing. They just had no framework to interpret what they noticed. Showing a 22-minute-old scan as LIVE doesn't prevent confusion – it just removes the context that would let users reason correctly about it.
How we designed the tiers
The system we shipped in Rain Viewer has four states. Fresh (green): under 10 minutes. Slight lag (yellow): 10–20 minutes. Significant lag (red): 20–60 minutes. No coverage (grey): over 60 minutes old, or no radar data – satellite imagery is used instead.
The 10-minute green threshold took some deliberation. Given station cadences, composite assembly, and mobile delivery latency, the freshest pixel a user realistically receives is already 2–8 minutes old under normal conditions. A 5-minute threshold would push most users into yellow by default – that's noise, not signal. Ten minutes is honest about the pipeline without crying wolf.
One specific rule worth noting: relative timestamps ("22 minutes ago") only apply to the current frame. When users scrub back through historical radar, we show an absolute timestamp – Scan: 13:52, 28 Mar. "22 minutes ago" applied to data from yesterday is not just useless, it's actively misleading.
The general pattern
Every data product has a version of this problem – a gap between what the timestamp implies and what the data actually reflects. The industry default is to smooth over that gap, show confident numbers, and let users draw their own conclusions. It's a locally rational decision that creates a globally bad equilibrium: users trust the data more than they should, get burned, and blame the product instead of the pipeline.
Radar data has irreducible latency. Showing that latency honestly is a worse first impression and a better long-term product. We think that trade-off is obvious. We're surprised it took this long to make it.
This content originally appeared on HackerNoon and was authored by oleksii_schastlyvyi
oleksii_schastlyvyi | Sciencx (2026-05-22T04:07:33+00:00) The Timestamp on Your Weather Radar Doesn’t Mean What You Think. Retrieved from https://www.scien.cx/2026/05/22/the-timestamp-on-your-weather-radar-doesnt-mean-what-you-think/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.