Record two times, not one ambiguous “updated” label

Show:

  • Data confirmed at 09:42 for the last successful read; and
  • Refresh failed at 10:07 for the latest attempt.

The second timestamp must not replace the first. “Updated at 10:07” would imply the rows themselves were updated. Keep the stale warning next to the queue title or action area, not only in a transient toast that disappears while old rows remain.

HTTP caching defines freshness and staleness for stored responses in RFC 9111, but it does not decide whether an operator may approve, assign, or delete a business record. That action policy belongs to the product and service owners.

Decide actions one consequence at a time

Reading an older row may be useful while assigning it could be unsafe. State the policy for each consequential action:

Action Example stale-data policy
Open details Permit, with freshness warning preserved
Copy record ID Permit
Assign owner Disable until refresh succeeds
Approve Require current version and authorization check
Refresh Permit; prevent duplicate attempts

The interface should explain why a disabled action is unavailable. A service must still recheck the record version and permission when an action runs; visual freshness is not an authorization mechanism.

Make failure and recovery noticeable without stealing focus

The W3C's status-message guidance requires messages about waiting, results, and errors to be programmatically determinable when they appear without a context change. Announce the refresh failure as a complete message. After a later success, announce that the queue is current again rather than making the warning disappear silently.

Acceptance checks

  • The last-successful data time remains visible after a failed refresh.
  • The failed-attempt time cannot be mistaken for the data time.
  • Rows have a persistent stale treatment until recovery.
  • Consequential actions follow a documented per-action policy.
  • Disabled controls have a visible reason and recovery condition.
  • Refresh failure and later recovery are exposed as complete status messages.
  • A successful refresh replaces rows and clears the warning together.

This pattern is a visible contract. It does not choose a cache lifetime or prove that any stale action is safe.