Incident Timeline

An incident timeline reconstructs the sequence of events before, during and after one specific failure, so a team can see what it knows, what it is interpreting and where the gaps are. Each participant usually holds a piece of the story. Support saw the first tickets, engineering knows what shipped, marketing knows when a campaign started, and analytics knows when a metric moved. The timeline puts those pieces on one axis.

The order of events constrains which explanations are possible. It does not establish which one is true: an event that happened first is a candidate cause, not a demonstrated one.

Worked example: incomplete product setup

This scenario, its events and its findings are illustrative, not results from a real incident or study. It continues the example from the root cause analysis guide: fewer new accounts are finishing the company-details step of setup.

When	Event	Source	Marked as
Sun	A mobile acquisition campaign starts	Campaign calendar	Evidence
Mon 09:10	A release replaces the company-details form component	Deploy log	Evidence
Mon 14:30	First ticket: “Continue gives me an error” from a phone	Support ticket	Evidence
Mon–Wed	Daily setup completion for new accounts falls	Analytics dashboard	Evidence, but the chart is daily, so the exact start is unknown
~Tue?	“A browser update went out around then”	Recalled by one participant	Interpretation, date unconfirmed (gap)
Thu	Support has tagged nine tickets as setup errors	Support queue	Evidence
—	“The release broke autofill”	Team discussion	Interpretation, moved to the hypotheses row

The timeline does not say what caused the drop, but it narrows the fishbone hypotheses:

• Measurement: A missing completion event alone does not account for customers reporting an error. The hypothesis is weakened, not eliminated: the same release could also have changed the event.
• System: The release comes before the first error ticket. That makes the new form component a strong candidate, but its position on the axis is not evidence that it caused the failure.
• Context: The campaign started a day earlier. A shift toward mobile visitors could lower the overall completion rate without any defect, so this stays open until completion is compared within comparable cohorts.
• Interface: The release notes describe a new form component, not changed instructions or button placement. Unclear instructions might still affect some customers, but they do not explain why the change happened this week.

The team also leaves two gaps open: the date of the browser update and the hour completion started to fall. Next, it compares affected and unaffected situations with Is / Is Not and tries to reproduce the failure, as the root cause analysis guide describes.

Incident timeline vs. journey map and service blueprint

All three put events in order, but they answer different questions:

Exercise	What it maps	Question it answers
Journey Mapping	A typical or intended customer experience	What do customers usually go through, and how do they feel along the way?
Service Blueprint	The front and backstage of a typical or ideal service	Which people, processes and systems support each step?
Incident Timeline	One specific failure, as it actually happened	What happened, in what order, and how do we know?

A journey map or service blueprint can show where a failure is likely to happen. An incident timeline reconstructs one occasion when it did. Use a blueprint to locate the step and the systems involved, then a timeline to establish what changed around that step and when. The process map guide covers which mapping exercise fits which question.

Limitations

Order is not cause. Several things usually change in the same period, and the first change before a symptom is not necessarily the one that produced it. Treat each earlier event as a candidate to test.

The timeline is only as complete as the records. Events that nobody logged, such as a third-party change or a browser update, can be missing entirely. Absence from the timeline is not evidence that something did not happen.

Memory fills gaps convincingly. Recalled times and sequences are useful leads, but they drift toward the story the group already believes. Keep them marked as interpretation until a record confirms them.

It covers one incident. A timeline of one failure does not show how often the failure happens or whether other customers fail for different reasons. Use Pareto analysis on recorded problems to see how common each category is.

Google’s postmortem guidance treats a written timeline as part of a blameless review focused on contributing causes and preventive action. The same approach applies here: the goal is a better-supported explanation, not a record of who made a mistake.