What needs to be finished first
A chronological timeline of the incident with timestamps for all relevant events, such as alerts, actions, and recoveries, has been created and is available in the tool.
A documented incident flow with named roles, such as Incident Commander, Communications, and Operations, is available so participants and decisions can be traced.
What needs to be ready before start
Postmortem template with header, timeline, impact, root cause, contributing factors, action items, and lessons; shared document; log excerpts and graphs from the incident day; chat transcript from the incident channel; list of participants.
Facilitator without direct incident involvement; Incident Commander from the incident; all operators with active actions in the timeline; one scribe for the record; optional neutral observer from another team for outside perspective.
Incident ID, duration, impact in numbers (users, revenue, SLO breach); timeline draft 24 h before the session; known workarounds; hypotheses already discussed in chat; date and owner of the session.
60-90 min workshop, plus 2 h asynchronous preparation by the facilitator
Schedule the session no later than 5 working days after resolution. Pre-fill the template header and timeline skeleton. State the rule: language stays focused on system behavior, no names in cause statements. Recording is optional, but agreement is set beforehand.
The one question this method answers
Which system conditions and decision points made the incident possible, and which concrete measures prevent recurrence?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Timeline walkthrough | 20 min | The facilitator reads the timeline aloud, participants fill gaps, correct timestamps, and mark decision points. No discussion of causes yet, only the factual basis. | If the team drifts into discussion in phase 1, the facilitator stops it and moves the point to phase 3. The timeline is the basis, not the verdict. |
2Phase 2: Capture impact | 10 min | Record user impact, business impact, and SLO breaches in numbers. Minimum: duration of the disruption, number of affected users, and estimated revenue or reputation effect. | Numbers need a source. If they are estimates, mark them as estimates. Impact drives the priority of action items. |
3Phase 3: Contributing factors | 30 min | Collect contributing factors by category: technology, process, organization, information. For each factor: what did the system do or not do, and what would have changed the outcome. Keep the language neutral. | The facilitator interrupts personification and rewrites it. Instead of 'X forgot', use 'the process had no control point'. |
4Phase 4: Action items | 20 min | For each contributing factor, define 0-2 measures with owner, due date, and priority. Make action items small executable tickets, not programs. Separate detection measures clearly from cause measures. | If all action items are 'better docs' or 'more training', the analysis is too shallow. At least one technical measure is needed per relevant factor. |
5Phase 5: Lessons and sign-off | 10 min | Formulate three lessons learned that other teams could benefit from. Clarify the publication format and the audience. Sign off by the Incident Commander and facilitator. | Lessons belong in the cross-team learning channel, not only in the local wiki folder. If lessons stay local, the multiplier effect is lost. |
What comes out at the end
Postmortem document in the engineering wiki with a header containing incident ID, date, severity, and duration; a timeline with timestamps; impact numbers; contributing factors by category; action items with owner and due date; lessons learned; and a sign-off block.
One document per incident with the incident ID in the title. Status field: draft, review, signed-off, follow-up-done. Keep action item status current in the document header. Add later findings as a dated appendix, not by overwriting.
Template for learning, contributing factors, and follow-up actions after an incident.
What happened, and what impact did it have?
Link or excerpt from the timeline.
| Action | Owner | Date | Expected impact |
|---|
Review date and status.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Severity: SEV-2. Duration: 35 min (09:12-09:47 UTC). Impact: 8.2% of checkout requests with HTTP 500, estimated 1,240 affected users, EUR 14,200 revenue loss according to Finance estimate.
Recognize symptoms and steer against them
Contributing factors contain names or roles, and the team starts defending itself instead of analyzing.
The facilitator immediately rewrites every sentence with a name into system behavior. Whoever defends the factor is brought back to the system question.
Times and actions are reconstructed during the session, while chat logs or pager data are not used.
Start the session only with a prepared timeline. If it is incomplete, move the session and assign the participants to gather the chat export.
The list contains measures like 'monitor better' or 'update docs' without a name and due date.
Add name and date in the session for every action item. Without an owner it is not an action item, it is a wish. Delete it or reformulate it.
The document stays in draft status, action items are not tracked, and the same incident class repeats.
Set the sign-off session no later than 10 working days after the incident. Put action items into the backlog with a postmortem label. Review all open postmortem items quarterly.
Even tiny glitches get the full postmortem treatment and the team ends up in a postmortem marathon.
Define severity criteria clearly, for example SEV1 to SEV3. Only SEV1 and SEV2 get a workshop; handle SEV3 as a short written lightweight postmortem.
Managers or customers are reading along, and the document becomes defensive and imprecise.
Keep the postmortem internal and derive a separate stakeholder summary from it. Separate the learning document from the communication artifact.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.