An incident timeline is useful when it separates what happened from what people later inferred. During a postmortem, teams often remember detection, a mitigation, and recovery—but overlook the customer impact that began earlier or the handoff that delayed diagnosis. A shared timeline makes those gaps discussable without turning the meeting into a search for someone to blame.
Make each time meaningful. Record the timezone, the source of the timestamp and the confidence of the entry. Keep “not yet known” visible instead of filling a gap with an estimate. A useful timeline separates detection, confirmation, mitigation, recovery and follow-up; it does not claim that the first alert was the first customer impact.
A visual collaboration board can arrange event records, open questions, and follow-up actions together. Google's SRE postmortem guidance emphasizes a detailed timeline, system-level learning, and measurable actions. The example below is fictional; use your incident logs as the authority for a real review.
Collect evidence before ordering it
Gather alerts, deployment records, support reports, incident-channel messages, and the service's own measurements. Record the time zone and distinguish when an event occurred from when the team learned about it. If two sources disagree, keep both timestamps until the discrepancy is resolved. Do not fill a quiet period with a confident story that the logs do not support.
Limit the first pass to the service and period affected. For an illustrative booking service, the question might be: “Why did some customers receive an error after confirming a new booking slot, and how was the service restored?” That scope is narrower than every issue seen on the platform that day.
An illustrative booking incident
| Time (UTC) | Recorded event | What still needs confirmation |
|---|---|---|
| 09:02 | A booking-service change is deployed | Which components were included? |
| 09:08 | The first failed confirmation appears in logs | Was this the first customer impact? |
| 09:16 | An alert reaches the on-call engineer | Why did detection lag the first visible failure? |
| 09:28 | The team disables the new confirmation path | Did every request use the fallback? |
| 09:41 | Error rate returns to the prior range | Are delayed confirmations still pending? |
These times illustrate how to structure a review; they are not measured Boardmix or customer data. The timeline says what is observed. It does not prove that the deployment alone caused the errors. The team should connect cause and effect only after comparing logs, code, configuration, and the fallback behavior.
Separate impact from contributing conditions
Below the event row, add tracks for user impact, signals, decisions, and unresolved questions. The 09:08 log entry may indicate earlier impact than the 09:16 alert. A gap like that suggests a detection question. The fallback may have restored the visible error rate while leaving some bookings in an uncertain state. Put that possibility on the board as a question until checked.
Use neutral wording. “The alert threshold did not fire until 09:16” is inspectable; “the on-call engineer was slow” ignores what information was available. Google SRE's discussion of blameless postmortems focuses on system design and actions with verifiable end states.
Build the timeline in Boardmix
Create a horizontal time axis in Boardmix. Put each sourced event above it and the corresponding customer effect below it. Link to the authoritative incident record rather than pasting private logs onto a public board. Add a separate area for hypotheses and evidence needed to test them; do not color a hypothesis as if it were a confirmed event.
For each accepted follow-up, write an owner and a testable end state. “Improve monitoring” is vague; “alert on confirmation failures before they exceed the agreed threshold for the agreed window” can be implemented and checked after the team sets the actual threshold. The board organizes the review, while monitoring and incident systems remain the sources of operational truth.
