Post-Incident Review: Blameless and Useful

Incident Response & Ticketing Workflows

Chapter 9 · Post-Incident Review: Blameless and Useful

Chapter 5 called this the timeline's own eventual destination. This chapter closes the loop: how to turn a good timeline and a resolved incident into a review that actually prevents the next one — and why "blameless" is a practical mechanism for getting a review worth trusting, not a soft or performative gesture.

Why "Blameless" Isn't About Being Soft

Blameless doesn't mean nobody is ever accountable, or that mistakes don't matter. It means the review focuses on systemic and process causes — what made this mistake possible or easy to make — rather than individual blame. This is a practical, outcome-driven choice, not a purely feel-good one.

The Real Mechanism: Psychological Safety Produces Better Data

If an engineer who made a mistake fears personal blame for it, they're incentivized to omit or soften that detail in the review — which means the review's own account of what happened is now wrong, and any fix aimed at a wrong account of events is aimed at the wrong thing. Blamelessness isn't charity toward the individual; it's what makes the review's own data trustworthy enough to actually act on.

Proximate Trigger vs. Root Cause

The proximate trigger is the immediate, final action that set the incident off. The root cause is the systemic condition that made that trigger possible, or its consequences severe. A genuinely good review keeps asking "why" past the first, obvious answer — a lightweight version of the "5 whys" technique:

Question	Answer
Why did checkout fail?	A query ran forever
Why did the query run forever?	It scanned the whole table
Why did it scan the whole table?	No index existed on the filtered column
Why wasn't there an index?	The schema-review process for new queries doesn't currently check for this

That last answer — a missing schema-review check — is the actual root cause worth fixing. "Add the missing index" fixes today's incident; it does nothing for the next query that reaches production the exact same way.

A Real Review Structure

Section	Source
Timeline	Built directly from Chapter 5's own live timeline — the review's primary source material
Root cause	Found via the 5-whys style questioning above — not just the proximate trigger
Impact	Concretely quantified — duration, users affected, tied to the severity classification from Chapter 3
What went well	Genuinely worth naming, not just filler — what actually worked should be reinforced, not only what failed
What went poorly	Honest, specific, systemic — not individual blame
Action items	Specific, owned, dated — covered in full below

Action Items With Owners and Dates, Not Aspirations

A review ending in "we should improve our monitoring" produces nothing — nobody is specifically responsible, and there's no deadline creating any urgency. Every real action item needs a specific owner (one named person, not "the team") and a specific due date. If neither can genuinely be assigned, it's more honest to leave the item out than to include it performatively.

Action items can become their own ignored backlog

A review that produces action items nobody ever follows up on is barely better than no review at all. Some mechanism — even a lightweight one, like a monthly check-in on open items — needs to actually confirm whether they got done, or the review's own real work quietly evaporates.

Working Example: The Full Mini-Postmortem

Built directly from Chapters 5 and 8's own running checkout incident:

TIMELINE — condensed from the live incident log (14:02–15:22 UTC); full log linked.

ROOT CAUSE — A schema change added an unindexed query path to order_items.
Proximate trigger: the query ran a full table scan under peak load, exhausting
the connection pool. Root cause: no schema-review step currently checks new
queries for missing indexes before they reach production.

IMPACT — SEV1, checkout unavailable for ~35% of attempts, 13:45–15:20 UTC (95 min).

WHAT WENT WELL — pg_stat_activity identified the stuck query within 25 minutes;
stakeholder updates sent on a consistent 30-minute cadence throughout.

WHAT WENT POORLY — the missing index reached production with no review
step designed to catch it.

ACTION ITEMS
  1. Add a missing-index check to the schema-review checklist — Owner: J. Lee — Due: 2026-08-16
  2. Add an automated alert when connection pool utilization exceeds 80% — Owner: M. Patel — Due: 2026-08-23

Hands-On Exercises

Exercise 1

Explain why this chapter argues blamelessness is a practical mechanism for better data, not just a kinder way to run a review.

📄 View solution

Exercise 2

Using this chapter's own 5-whys example, explain why "add the missing index" is the wrong action item to stop at, and what the real root cause turned out to be.

📄 View solution

Exercise 3

Explain why "we should improve our monitoring" fails as an action item, and what this chapter says a real one needs instead.

📄 View solution

Chapter 9 Quick Reference

Blameless = focused on systemic causes, not individuals — a practical way to get honest, trustworthy data, not a soft gesture
Fear of blame causes people to hide details — which makes the review's own account of events wrong
Proximate trigger vs. root cause — keep asking "why" past the first obvious answer (a lightweight 5-whys)
A review's structure: timeline (from Ch5), root cause, impact, what went well, what went poorly, action items
Action items need a specific owner and a specific date — vague aspirations produce nothing
Action items need a follow-up mechanism too, or they quietly become an ignored backlog
Next chapter: Capstone: Running One Incident Start to Finish