Aglet

Triage a report that may be showing stale cached data

A report can look wrong because its displayed result was prepared earlier than the source data, because the report period is misunderstood, or because the source itself is delayed. Triage should establish when the result was produced, what data boundary it covers, and which comparison exposes the concern.

Establish what is happening

  1. Capture freshness context

    Record the report name, displayed refresh or as-of text, selected period, visible filters, and the time the discrepancy was observed. Preserve the disputed value and a nearby value expected to change, so the investigation has a concrete comparison.

  2. Separate time boundaries

    Write down source event time, ingestion or update boundary, query execution time, and display time when each is available. Do not collapse these into one timestamp. A result can be current for its source boundary while still omitting later events.

  3. Classify the first question

    Classify the case as cache freshness, source lag, period semantics, or unknown. State what evidence would distinguish those possibilities, and route only the unresolved boundary to the next queue instead of prescribing a refresh without proof.

What to carry forward

Triage is complete when the disputed result has a recorded data boundary and observation time, with the leading explanation tied to evidence. Keep the case open as unknown when timestamps are absent; missing freshness context is itself a report usability finding.

Technical background: Metabase documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow