How Should a Dashboard Signal Stale Data?
From the earlier reference collection. Read the current software blog.
A useful freshness signal defines when data becomes delayed, gives the last successful update, and explains what readers can still rely on.
Set thresholds before an incident
“Updated recently” is not a reliable rule. Decide how often a feed is expected to arrive, then define a grace period that accounts for ordinary variation. A feed expected every five minutes might be considered delayed after fifteen minutes, while a daily file may need a different threshold. The threshold should reflect the source’s normal cadence and the consequences of using old values.
Apply the rule to each source or metric, rather than letting a page-wide timestamp hide a lagging component. If a dashboard combines a live sensor stream with a daily summary, those parts have different freshness expectations.
Show both status and time
A color or warning icon can attract attention, but it should not carry the explanation by itself. Pair a plain label such as “Delayed” with the last successful update time and the expected cadence. For example: “Delayed: latest successful reading received at 10:15 a.m.; readings usually arrive every five minutes.” This tells a reader how old the information is and why the warning appears.
Use an absolute time as well as a relative one where space allows. “Updated 23 minutes ago” is quick to scan, while “10:15 a.m. Pacific” remains meaningful in a screenshot or saved report. Include the date when the display could span midnight, and make the time zone clear.
Keep last known values distinct
When a feed pauses, the last value may still be useful, but it is no longer current. Keep it visible only with an unmistakable timestamp and stale status. Avoid carrying the old value forward as if it were a fresh observation. A chart can show the last point and a gap after it; a table can include a separate “reading time” column.
If a cached page is being served, distinguish cache age from source-update time. The source may have published a new file that the dashboard has not yet retrieved. Stating which step is delayed helps maintainers and readers understand the problem.
Make the warning actionable
A freshness warning should say which feed or area is affected and, if known, what the dashboard is doing: retrying, showing the last received data, or omitting values. Do not claim that an upstream provider is down unless that has been confirmed; describe the observed failure, such as “No new file received since 10:15 a.m.”
After recovery, clear the stale label only when a successful update has actually arrived. A simple, consistently applied policy turns freshness from decoration into information readers can use.