Postmortem Workshop
A quality review for incident postmortems that checks whether the analysis is evidence-based, systemic and connected to corrective actions that can actually be verified.
Who this Lab is for
Designed for
- Incident reviewers and facilitators
- Engineering managers improving incident learning
- Service teams drafting a postmortem
Use it when
- Before publishing or closing a postmortem
- Training facilitators to avoid blame and weak actions
- Auditing incident-learning quality across teams
A complete run, step by step
Prepare the draft
Bring the current timeline, impact assessment, contributing factors, detection analysis and action list.
Check the evidence
Confirm timestamps, system evidence and the distinction between observed fact and inference.
Review contributing factors
Look beyond individual actions to conditions in design, tooling, process and organisational context.
Strengthen actions
Require owners, dates and verification criteria that demonstrate the risk has actually changed.
What you will need
Prepare the following information before starting. Use measured evidence where possible; defaults are examples and should not be treated as recommendations.
Evidence-backed timeline
Events use timestamps and distinguish fact from inference.
Choices: Yes — verified · Partially / undocumented · No
Systemic contributing factors
Analysis goes beyond a single human action.
Choices: Yes — verified · Partially / undocumented · No
Measured customer impact
Scope and duration are quantified.
Choices: Yes — verified · Partially / undocumented · No
Owned, testable corrective actions
Actions have owners, dates and verification criteria.
Choices: Yes — verified · Partially / undocumented · No
Detection and response gaps
The review explains why controls did not catch it sooner.
Choices: Yes — verified · Partially / undocumented · No
What the result tells you
Your report includes
- A postmortem-quality score
- Specific missing analysis or evidence
- Recommendations for stronger corrective actions
How it is determined
The review weights evidence, systemic analysis, measured impact, detection learning and action quality. Partial coverage receives some credit, but vague actions and unsupported timelines reduce the result.
The rubric assesses document completeness but cannot verify evidence quality, causal analysis or whether actions reduce risk.
Model assumptions
- • Responses reflect the current written postmortem.
- • Evidence and impact measurements are independently reviewable.
- • Corrective actions include owners and verification criteria.
Authoritative references
Deployment-triggered outage
Situation
A draft has a strong timeline and rollback analysis but describes impact only as 'some customers' and lists 'improve monitoring' without an owner.
Result
The workshop prioritises quantified customer impact and specific, owned detection improvements with acceptance criteria.
Use the result with engineering judgement
- It cannot determine whether the underlying evidence is accurate.
- A score should never be used to rank or blame individuals.
- Sensitive legal, people or security matters may require separate handling.
Questions before you begin
Should a postmortem name the person who made a change?
Record relevant actions factually, but focus analysis on why the system allowed one action to produce the outcome and how risk will be reduced.
What makes an action testable?
It has a named owner, target date and observable acceptance criteria that show the intended control or capability works.
When should the postmortem be reviewed again?
Track actions to completion and review whether they changed the relevant risk, especially after similar signals or incidents.
Postmortem Workshop is under review
This legacy judgement-based Lab has been retired. Existing saved reports remain available, but new execution is disabled.
Open deterministic utilities