Live, Cached, and Stale Data

Three clocks, not one

A live map can show three different times: when a source observed an event, when SkyWatch received it, and when the browser last refreshed. These clocks answer different questions. Observation time describes the underlying report; receipt time describes transport delay; browser refresh time only proves when the screen asked for data.

A recent browser refresh does not make an old observation current. SkyWatch therefore evaluates source timestamps and cache age separately from the time displayed by the device. When a provider omits a reliable timestamp, the interface should describe the record as estimated or of unknown age instead of inventing precision.

What cached data is for

Caching protects continuity when a provider is slow, rate-limited, or temporarily unreachable. It can preserve the last known aircraft position, alert event, weather tile, or environmental reading while a new request is in progress. This is useful context, but it is not a new observation.

A healthy cache has a documented time budget. High-frequency aircraft positions age quickly, while a seismic catalogue or orbital element set may remain useful for longer. SkyWatch applies layer-specific expectations because one universal stale threshold would make either fast feeds too permissive or slow products unnecessarily unavailable.

Stale, empty, and unavailable are different

An empty result can mean there are no matching records, but it can also mean that a provider returned an error, a query was rejected, or a cache was never populated. Those conditions should not collapse into the same zero. SkyWatch keeps genuine empty state separate from transport and source failure wherever the upstream contract allows it.

Stale means that a previously valid record is older than the layer's current-use threshold. Unavailable means the application cannot establish a usable answer. A stale marker may remain visible as subdued context; an unavailable layer should explain that it cannot currently support a conclusion.

Emergency information uses stricter rules

Public warnings are requested network-first because an old warning must not silently replace the present state. A short replay window can keep a brief alert visible long enough for browsers to observe it, while a formal release or all-clear closes the event immediately.

Recent alerts can remain on the map for context after their strongest display period. Their reduced opacity is intentional: it shows where activity was reported without implying that the warning is still active. Official instructions and timestamps always take priority over visual emphasis.

A five-step freshness check

First identify the source. Second read the observation time. Third inspect cache age or freshness status. Fourth compare the expected update interval for that layer. Fifth look for an independent corroborating source before drawing an operational conclusion.

If any step is missing, reduce the confidence of the conclusion rather than filling the gap with an assumption. A blank or delayed map is information about coverage, not evidence that the monitored world is quiet.