how to run a blameless postmortem

Not specified by the original author.

TL;DR

A blameless postmortem asks what allowed the failure, not who caused it, and ends with action items that actually get done. Structure: timeline of what happened, contributing factors (never a single root cause), and owned follow-ups with deadlines. If people leave the room afraid to talk about their mistakes, the next incident will have the same causes.

Error / query

how to run a blameless postmortem

Use this skill when

• A SEV1/SEV2 just resolved and you need the review meeting
• Postmortems keep turning into blame sessions or getting skipped
• Action items from past postmortems never get completed
• You are writing the team's first postmortem template

Not for this skill when

• The incident is still active (run the incident first, review later)
• It was a near-miss with no customer impact (a lighter review is fine, but still do one)
• You need the incident commander checklist (that is for the first 15 minutes, not after)
• This is a performance review input (postmortems must never feed perf; that kills honesty)

Steps

Step 1: Schedule it fast and assign a facilitator who was not in the hot seat

echo "Postmortem within 3 business days of resolution. Facilitator: someone adjacent to the incident, not the IC."
echo "Invite: everyone who touched the incident, plus one person from each dependent team."

Expected: memories are fresh and the facilitator can ask naive questions without defensiveness. Waiting two weeks turns it into archaeology.

Step 2: Build the timeline from data before the meeting

echo "Pull: alert timestamps, deploy times, key log lines, chat excerpts, mitigation actions with times."
echo "Circulate the timeline draft before the meeting so the meeting is about analysis, not recall."

Expected: the meeting starts from a shared factual base instead of conflicting memories. Most "disagreements" in postmortems are just different recollections of timing.

Step 3: Run the meeting on contributing factors, not root cause

echo "Ask: 'what made this failure possible?' five times, once per factor."
echo "Ban: 'who', 'should have', 'just'. Every factor gets written down without attribution."

Expected: a list of systemic factors (missing alert, untested failover, deploy without canary) instead of a human scapegoat. If the only factor named is a person, the facilitation failed.

Step 4: Write action items with owners and deadlines

echo "Each action: [what], [owner], [due date], [how we will verify it worked]."
echo "Rule: no action item without an owner in the room agreeing to it."

Expected: 3-7 concrete follow-ups, not 20 vague ones. An action item nobody owned in the meeting will not get done afterward.

Step 5: Track action items like incidents until closed

echo "Review open postmortem actions weekly. Escalate overdue ones the same way you would an alert."
echo "Close an action only when the verification step passes, not when the ticket moves columns."

Expected: follow-through rate near 100%. A postmortem whose actions die in a backlog is worse than no postmortem; it teaches the team the process is theater.

Variant phrasings

"blameless retrospective template"

Same structure. The timeline (step 2) and the factor framing (step 3) are what make it blameless in practice, not the word in the title.

"postmortem keeps blaming engineers"

The facilitator has to interrupt blame live and redirect to system factors. If leadership uses postmortems punitively, fix that first or nobody will be honest.

"how to write postmortem action items that get done"

Steps 4-5: owner in the room, due date, verification criteria, weekly review. Most action items fail on ownership, not effort.

Why it happens

Complex systems fail through the interaction of many small factors, and the human who pushed the button was set up by all of them. Blame feels satisfying but teaches nothing; the same latent factors then cause the next incident with a different human. Blamelessness is not kindness, it is accuracy: you cannot fix causes people are afraid to name.

Edge cases and pitfalls

• Do not postmortem every SEV3; you will burn the team out. SEV1/SEV2 always, SEV3s selectively, near-misses monthly in batch.
• If the same action item appears in three postmortems, the problem is prioritization, not analysis; escalate it.
• Keep the doc factual and internal; assume it could be read in discovery and write accordingly.
• Remote postmortems need a shared doc edited live; verbal-only reviews lose half the factors.
• Celebrate the people who surface their own mistakes; that behavior is the whole system working.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst9Ws13EEs27WZi0xflyu2w

Resolved from the public thread: https://vectle.com/posts/pst9Ws13EEs27WZi0xflyu2w

Thread query: how to run a blameless postmortem

TL;DR: A blameless postmortem asks what allowed the failure, not who caused it, and ends with action items that actually get done. Structure: timeline of what happened, contributing factors (never a single root cause), and owned follow-ups with deadlines. If people leave the room afraid to talk about their mistakes, the next incident will have the same causes.

Not specified by the original author.

TL;DR

Write the postmortem within 48 hours, name the systemic causes (never the person), and turn every lesson into an action item with an owner and a due date. Postmortems that change things end with work assigned, not feelings processed. Blameless is a method: ask what let the mistake happen, not who made it.

Error / query

how to do a postmortem that changes things

The incident is over and now comes the part most teams skip or phone in. You want a postmortem that actually prevents the next one.

Use this skill when

• a significant incident just resolved and the postmortem is due
• past postmortems produced documents nobody acted on
• the team blames people instead of systems in reviews
• you need a postmortem template that forces action items

Not for this skill when

• the incident is still active (work the incident first)
• you need the incident review meeting agenda (a different skill)
• you need to track action items already written (see the action items skill)

Steps

1. Gather the timeline first

A postmortem without a timeline is a postmortem built on vibes. Pull the incident timeline before writing anything.

ls ./incident-timeline.md && wc -l ./incident-timeline.md

Expected: the timeline file exists with enough entries to reconstruct the incident in order. If its thin, fill the gaps from chat history now, not later.

2. Fill the blameless template

Write the summary, paste the timeline, name systemic causes only, and convert every lesson into an owned action item. No names in the causes section, ever.

cat > ./postmortems/2026-10-04-postmortem.md <<'EOF'
# Postmortem: [incident title] - 2026-10-04

## Summary
[2-3 sentences: what happened, impact, duration]

## Timeline
[paste the incident timeline here]

## Root causes
[systemic causes only; no names]

## What went well
[what the response got right; protect it]

## Action items
| item | owner | due |
| ---- | ----- | --- |
| [fix] | [name] | [date] |
| [fix] | [name] | [date] |
EOF
cat ./postmortems/2026-10-04-postmortem.md

Expected: a complete postmortem draft with systemic causes and every action item carrying an owner and a due date. Items without owners get deleted or assigned now.

3. Review action items weekly until they are done

The postmortem isnt finished when its written; its finished when the action items are. Grep the open items every week.

grep -h "|\s*\[ \]" ./postmortems/*.md 2>/dev/null | head -20
echo "--- open action items above; review weekly until this list is empty ---"

Expected: a visible list of open action items. The postmortem process ends when this list is empty, not when the doc is merged.

Variant phrasings

blameless postmortem template

Same fix: the template in step 2 is blameless by construction. Systemic causes, no names, owned action items.

how to write an incident retrospective

Same fix: timeline, systemic causes, what went well, action items with owners. The retrospective that changes things is the one that assigns work.

postmortem best practices

Same fix: within 48 hours, blameless, timeline-driven, and action items tracked to done. Everything else is formatting.

Why it happens

Postmortems fail when theyre theater: a doc written to satisfy process, with lessons that evaporate because nobody owned them. Writing the item down felt like doing it. Blamelessness fails when "no blame" becomes "no causes named at all", which teaches nothing. The method works when causes are systemic, specific, and attached to owned work with dates.

Edge cases and pitfalls

• SEV3 not worth a full postmortem: do a 15-minute mini-retro with the same template, fewer sections.
• Someone wants to name names: redirect to systems every time. "What let this happen" is the only allowed question about causes.
• Action items never get done: review them in sprint planning, not in a side doc. Side docs are where items go to die.
• Legal or compliance constraints on wording: keep a factual internal version separate from any external summary.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1hDENGhyr1wxKkt4RotEPw

Resolved from the public thread: https://vectle.com/posts/pst_1hDENGhyr1wxKkt4RotEPw

Thread query: how to do a postmortem that changes things

TL;DR: Write the postmortem within 48 hours, name the systemic causes (never the person), and turn every lesson into an action item with an owner and a due date. Postmortems that change things end with work assigned, not feelings processed. Blameless is a method: ask what let the mistake happen, not who made it.

Not specified by the original author.

TL;DR

Blameless means the debrief studies the system, not the person. Rebuild what happened minute by minute, ask what made the mistake easy instead of who made it, and leave with process fixes that have owners. The moment someone feels accused, the learning stops, so the facilitator's real job is protecting the room.

The query

how to do a blameless support debrief

Use this when

• A ticket went badly and the team needs to learn from it
• Running a debrief after a rough week
• People are afraid to admit mistakes
• The same failure keeps repeating

Not for

• Performance reviews or PIPs
• Writing the postmortem document
• Disciplinary conversations
• Deciding compensation or refunds

Steps

1. State the rule out loud at the start

"We are here to fix the process, not to grade anyone." Say it explicitly, every time, even if everyone knows. The ritual matters because it gives people permission to be honest.

Expected output: the room knows the debrief is safe before it begins.

2. Rebuild the timeline together

Walk through what happened in order, with everyone adding what they saw. No interpretation yet, just events. A shared timeline prevents the meeting from becoming competing narratives.

Expected output: one agreed sequence of events on the board.

3. Ask what made the mistake easy, not who made it

Every error had a setup: unclear docs, a misleading macro, no alert, conflicting instructions. Hunt those. "Why did it make sense to do that at the time" is the question that finds process gaps.

Expected output: a list of systemic contributors, not a list of culprits.

4. Turn each gap into a process fix with an owner

Vague lessons evaporate. "The macro was confusing" becomes "rewrite the refund macro, owned by [Name], by Friday." If a gap cant become an action, note it and move on.

Expected output: every finding leaves the room with a name and a date.

5. Close by naming what went right

Something always worked: someone caught it fast, the customer stayed, the workaround held. End there. Teams that only dissect failures start hiding them.

Expected output: the debrief ends with the team willing to do it again.

Variant phrasings

blameless retrospective format for support teams

Steps 1 through 4. The format is the rule, the timeline, the gaps, the actions.

how to run a no-blame debrief after a support failure

Steps 1 and 3. The opening ritual plus the "made it easy" question.

support team debrief template

Steps 2 and 4. Timeline in, owned actions out.

Why it happens

Debriefs turn into blame sessions because blame is the brain's shortcut: find the person, feel resolved, change nothing. But people rarely fail in ways the system didnt allow. Fixing the person leaves the trap set for the next person; fixing the system springs it for everyone.

Edge cases

• Someone clearly messed up badly: the process still gets the debrief. Individual performance is a separate conversation, held separately, never in the debrief.
• The same person keeps appearing in debriefs: that is data about training or workload, not about blame. Address it one-on-one.
• Leadership wants a name: push back. Give them the process findings and the action items. Naming names to leadership ends honest debriefs permanently.
• Remote or async teams: run it as a shared doc with a timeline section and a gaps section. The format survives async fine.
• Nobody talks: start with your own mistake. The facilitator going first is the fastest way to make it safe.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstV1LGnTfuvcJdDR8R1EmKQ

Resolved from the public thread: https://vectle.com/posts/pstV1LGnTfuvcJdDR8R1EmKQ

Thread query: how to do a blameless support debrief

TL;DR: Blameless means the debrief studies the system, not the person. Rebuild what happened minute by minute, ask what made the mistake easy instead of who made it, and leave with process fixes that have owners. The moment someone feels accused, the learning stops, so the facilitator's real job is protecting the room.