Useful status needs context. “Balance: £240” hides whether the value came from a live read, a cached snapshot or yesterday’s report. For a low-risk overview, that may be acceptable. Before a payment or eligibility decision, it may not be.
1. Record two times
Keep the timestamp supplied by the source, if it has one, and the time your application observed it. The first describes the underlying record as reported; the second tells the user when your system last checked. Preserve the time zone and handle clock skew. If a provider only offers a date or a provider’s sequence marker, do not invent a precise timestamp.
A page rendered at 10:30 can contain data last checked at 10:05. Saying “updated just now” because the page loaded just now confuses rendering time with data time.
“Last checked 10:05” is a statement about your system. “Current as of 10:05” is a stronger claim about the source and its coverage.
2. Freshness is relative to the decision
Choose how long information can be treated as recent enough for the task. That time limit depends on the use case, not on the visual design. A cached news list may remain useful for minutes. An available-balance check before a transfer may need a fresh provider response and a final authoritative check. The right threshold depends on source latency, volatility, user impact and the product’s obligations.
Make the policy explicit: how long a value is considered fresh, whether stale values remain visible, what actions require a new read, and how the UI behaves when refresh fails. “Fresh” should not imply that the source is complete or infallible.
3. Put time next to the status
| What is known | Example wording | What the wording avoids |
|---|---|---|
| Recent successful source read | “Balance last checked at 10:05.” | Claiming continuous live accuracy. |
| Value exceeds the window | “Showing the last checked balance from 10:05. Refresh before continuing.” | Silently presenting old data as current. |
| No timestamp supplied | “Provider value received; its update time wasn’t supplied.” | Inventing source recency. |
| Refresh failed | “We couldn’t update this value. Last successful check: 10:05.” | Replacing a known prior value with a false zero. |
4. A failed check is not an empty value
Distinguish “the source returned zero”, “the record does not exist”, “the provider is unavailable” and “the application has not checked yet”. These states have different meanings and should not collapse into a blank field or an all-clear badge.
Keep the last known value when it is useful, label it stale, and disable only the actions that truly require a fresh check. Preserve an accessible text label alongside colour or decorative status marks.
Try a status label
Select what the product observed. The example updates locally and does not fetch data.
5. Write a small freshness policy
- Name the source and the timestamp semantics it provides.
- Set a documented age threshold for each meaningful action.
- Show source time or last-check time in human-readable form.
- Define stale, unavailable, unknown and empty separately.
- Recheck at decision points where old data can cause harm.
- Measure source lag and communicate provider incidents.
A timestamp cannot make poor data reliable. It does let a person judge how much confidence to place in it and whether the next step should wait for a refresh.
Sources and review date
- Amazon EventBridge: monitoring best practices — operational monitoring and delivery metrics.
- IETF RFC 3339 — timestamp representation and offsets.
Reviewed 26 October 2026. Freshness limits are product-specific and should be validated with the actual source and user need.