Engineering Postmortem Template (Blameless, Actionable)

Why postmortems turn into blame sessions

Postmortems fail in a specific way: the room starts assigning cause before the room has a shared timeline. Someone says "the deploy caused this" before the deployment time is confirmed. Someone else says "the alert didn't fire" without knowing whether the alert was configured for that scenario. The conversation becomes a debate about causation before anyone has established what actually happened, in what order.

The fix is structural: build the incident timeline together at the start of the postmortem, before anyone names a root cause. Once the whole room has looked at the sequence of events — what changed when, who saw what at which time — cause is far easier to discuss and far less likely to collapse into blame. This is the ordering mistake most templates make: they put root cause before the timeline because root cause is what the template is for. But the timeline is what makes root cause honest.

The agenda (copy-paste this)

Duration: 60 minutes for a straightforward incident; 90 minutes for complex multi-system failures
Format: Facilitated; all responders and the on-call engineer present; prepare async with a pre-read doc

Section 1 — Incident summary (5 min)

Dates and duration of the incident
Severity classification and affected systems
Who detected it and how (customer report, alert, engineer, monitoring)
This section is factual only; no analysis yet

Section 2 — Timeline (20 min)

Build the timeline collaboratively on screen — not a pre-written doc
Sequence: what changed, what was observed, who acted, what was decided
Every timestamp should be sourced (log line, PagerDuty, Slack message)
When the timeline is complete, ask: does everyone agree this is what happened? Resolve disagreements before moving on

Section 3 — Impact summary (5 min)

Customer impact: who was affected, for how long, in what way
Business impact: revenue, SLA, reputational
Internal impact: on-call hours, team disruption
Keep this factual; it anchors the "how bad was it" question without editorializing

Section 4 — Root cause and contributing factors (20 min)

Root cause: the most proximate change or condition that made the incident possible
Contributing factors: the conditions that made it worse, harder to detect, or slower to resolve
Most useful postmortems identify 3-5 contributing factors alongside the root cause; fixing only the root cause often misses the systemic conditions
Ask for each factor: did any individual or team make a decision that seemed reasonable given the information available? If yes, the factor is systemic, not personal

Section 5 — What went well (5 min)

What detection or response worked better than expected?
What existing process or tool limited the blast radius?
These are practices worth formalizing — if the runbook saved 20 minutes, note that so the runbook gets maintained

Section 6 — Action items (15 min)

Each action item addresses a root cause or contributing factor — not a general improvement
One owner per item; a delivery date that reflects urgency
Categorize: detect sooner / recover faster / prevent recurrence
Limit to actions the team can realistically complete before the next incident, not a comprehensive reliability roadmap

What makes postmortem templates fail

Root-cause-first ordering is the main structural problem — already covered above. The second is treating "action items" as a single category. Detection improvements, recovery improvements, and prevention improvements require different owners and different timelines. Mixing them produces a list that spans six months and three teams, which means accountability diffuses and none of them ship.

The third failure mode is skipping "what went well" because it feels like inappropriate optimism after an incident. It's not — it's the only systematic way to identify and formalize practices that worked under pressure. If the monitoring that caught the issue wasn't on anyone's roadmap to build, learning that it mattered is worth documenting. Otherwise it gets deprioritized after the incident fades and you're blind the next time.

The compounding cost of incidents where contributing factors go unaddressed, and runbooks that worked go un-maintained, accumulates fast. The meeting tax covers how recurring meeting overhead and incident review debt interact.

Why postmortem capture is uniquely difficult

Postmortem discussions generate dense, unstructured content fast: timeline reconstruction, competing interpretations, multi-person action item assignments, technical detail that won't make sense in a transcript without context. A postmortem recap written from memory or edited audio is nearly always incomplete, and incomplete postmortem records are useless for pattern recognition across incidents.

Pavleur captures the full postmortem discussion and generates the report automatically — timeline as reconstructed, contributing factors as named, action items with owners and categories as stated in the meeting. If someone shared their screen to show a log extract, a monitoring graph, or the alert configuration that failed to fire, that visual is part of the report. Audio-only tools miss this entirely; a postmortem record without the graphs is a record without the evidence. Anyone on the team — including engineers who join after the incident — can read the full, visual-context-included record without asking someone to reconstruct it. For a direct comparison with other tools on this: Pavleur vs. alternatives.

On postmortem cadence

Run the postmortem within 48 hours of incident resolution while details are fresh. The longer you wait, the more timeline reconstruction depends on memory rather than logs, and memory is unreliable under stress. For high-severity incidents, 24 hours is better. For minor incidents, async postmortems — a shared doc with structured prompts, reviewed synchronously — can be more efficient than a full meeting. The meeting format is most valuable when the incident was ambiguous or high-stakes enough that shared interpretation matters.