Sometimes yes. A delayed weather observation or a historical chart can still be useful. A checkout quote or an available balance is different: an old value may cause a real loss. The design problem is not simply whether to cache. It is how to represent age, uncertainty, and the actions that remain safe.

Keep the last good snapshot, but keep its history too

I store a successful fetch as an immutable snapshot. A failed fetch records an error separately; it never rewrites the snapshot's timestamp.

Three times are worth separating:

• source_updated_at: when the provider says its data changed, if it supplies this value.
• fetched_at: when our system successfully retrieved and validated the response.
• published_at: when our system made this snapshot visible to readers.

These can differ by minutes or hours. Calling fetched_at "the data's timestamp" would imply more than we know when the provider gives no update time. I leave source_updated_at null in that case.

The snapshot also needs a source identifier, schema version, and a hash of the validated payload. The hash makes it easier to tell a successful fetch of unchanged data from a genuinely new observation.

Turn age into an explicit state

A small pure function can classify the last good fetch. The thresholds below are examples, not universal defaults:

type Freshness = "fresh" | "stale" | "unavailable";

function freshness(
  nowMs: number,
  fetchedAtMs: number | null,
  freshForMs: number,
  usableForMs: number
): Freshness {
  if (fetchedAtMs === null) return "unavailable";
  if (usableForMs < freshForMs) throw new Error("invalid policy");

  const age = Math.max(0, nowMs - fetchedAtMs);
  if (age <= freshForMs) return "fresh";
  if (age <= usableForMs) return "stale";
  return "unavailable";
}

The policy belongs to the use case. A reference page might tolerate two hours of stale data. A transaction flow might allow zero seconds: once the live quote expires, the action is disabled until a fresh value arrives.

Expose the state in the API response instead of asking each client to reconstruct it:

{
  "value": 42.7,
  "source_updated_at": null,
  "fetched_at": "2026-10-30T08:15:00Z",
  "freshness": "stale"
}

The browser can then show the value with a clear "Last fetched" label and a stale notice. If the value is too old, show the last timestamp but withhold the number where it could be mistaken for current data.

Handle a failed refresh without lying

On refresh, validate the entire response before committing a new snapshot. A 200 OK containing an HTML error page is a failure, not an update. So are malformed numbers and missing required fields. For multi-source views, do not give the whole page one green "updated" badge when only one source refreshed.

I also avoid setting fetched_at to the time of a failed attempt. That small mistake makes yesterday's value look fresh every time a retry fails.

The operational side is simple: use bounded retries with jitter, record the last error separately, and alert when the age of the last good snapshot crosses the policy threshold. An error-rate alarm alone can miss a feed that quietly stopped changing.

Test the boundary, not just the happy path

Advance a fake clock across the fresh/stale and stale/unavailable boundaries. Send an older provider timestamp after a newer one. Return a valid HTTP status with invalid JSON. Simulate a partial update and a client whose clock is wrong. Then check that the visible label and allowed actions still match the server's state.

The useful promise is modest: the system may not always have current data, but it should always be honest about what it has.