Retrospective vs. postmortem: is there a difference?
In practice, the terms describe the same activity: a post-incident review. “Postmortem” is the older, more common term; “retrospective” has gained ground because it avoids the morbid framing and emphasizes learning over autopsy. Some teams draw a soft distinction—using postmortem for the written document and retrospective for the meeting and process around it—but there is no industry-standard difference. Pick one term, define it, and use it consistently.How to run an incident retrospective
1. Schedule it quickly
Hold the retrospective within a few business days of resolution—ideally within a week. Memory decays fast, and the details that matter most (what people saw, what they believed, why they acted) are the first to go. Invite the responders who were actually involved, not just their managers.2. Build the timeline
Reconstruct what happened in order: when the issue started, when it was detected, key decisions, mitigation attempts, and resolution. Pull from your incident channel, monitoring alerts, deploy logs, and the incident timeline. A shared, factual timeline grounds the whole discussion—disagreements about “what happened” should be settled here, before anyone discusses “why.”3. Identify contributing factors
Resist the urge to find the root cause. Real incidents almost always have several contributing factors: a latent bug, a gap in monitoring, an ambiguous runbook, a risky deploy window. Ask “what made this possible?” and “what made this worse?” for each phase—detection, diagnosis, and mitigation. Slow detection and slow mitigation are findings just as much as the triggering defect.4. Write a blameless narrative
Document the incident from the responders’ point of view: what they knew, what they saw, and why their actions made sense at the time. Avoid counterfactuals (“they should have checked the dashboard”) and name systems, not people, as points of failure. If the narrative reads like an indictment of a person, rewrite it.5. Assign action items
Turn findings into concrete follow-ups: fix the bug, add the missing alert, update the runbook, add a guardrail to the deploy pipeline. Every action item needs a single owner and a due date—a list of good intentions without owners is where retrospectives go to die. Prioritize ruthlessly; three completed action items beat fifteen abandoned ones.6. Share the learnings
Publish the retrospective where the whole engineering organization can read it, and announce it—in a team meeting, a newsletter, or a dedicated channel. Other teams likely share the same failure modes. An unread retrospective only teaches the people who were already there.What to include in the document
A solid retrospective document covers:- Summary — a few sentences: what broke, the impact, and the fix
- Impact — duration, affected services, customer-facing effects, and any SLA/SLO implications
- Timeline — timestamped sequence from first signal to resolution, including detection and escalation times
- Contributing factors — the conditions that made the incident possible and prolonged it
- What went well — effective responses worth reinforcing (fast detection, a good runbook, a clean handoff)
- What could be improved — gaps in tooling, process, or knowledge
- Action items — each with an owner, a due date, and a priority
Common mistakes
- Skipping retrospectives for “small” incidents. Near-misses are cheap lessons. You don’t need the full process for every blip, but a lightweight review beats none.
- Blame in disguise. “Human error” as a root cause, or timelines written as accusations. If a person “caused” the incident, the system that let one mistake cause an outage is the real finding.
- Root-cause tunnel vision. Stopping at the first plausible cause and missing the detection and response gaps around it.
- Action items with no follow-through. Unowned, undated items quietly expire. Review open items regularly.
- Waiting weeks to run it. Stale memories produce vague timelines and generic conclusions.
- Writing it and telling no one. The document is a means; the learning is the point.