How to run better incident reviews

An incident review is easy to make ceremonial.

A few screenshots, a short timeline, a vague action item, and everyone moves on. That is not enough if you want the system to get stronger.

I have spent energy trying to treat reliability as an operating system: dashboards, observability, ownership, incident follow-through, on-call, platform improvements. The important shift is not “we had a quieter month.” It is whether the next event has a default path, or whether it still requires a senior person to reconstruct the story.

What the review is for

A useful review answers three questions:

1. What happened?
2. Why was the system vulnerable to this sequence?
3. What will actually reduce chance or impact next time?

The third question is the one that usually dies. Teams produce a long list of safe-looking tasks. The operating system does not change.

Heroics are sometimes necessary. They should not become the model. If a problem keeps requiring exceptional individual effort, the missing piece is usually a system.

Look at conditions, not theater

Blame-resistant reviews focus on:

• missing safeguards
• weak observability
• confusing ownership
• dependency assumptions
• communication gaps during response

One common failure is spending the hour on the visible trigger and almost none on the conditions that made the trigger expensive. In integration and platform work, those conditions are often a one-off that should have been a primitive, a mapping nobody owned, or a dashboard that did not exist until someone already knew where to look.

I care about whether follow-through is inspectable. If the action lives in a doc nobody reopens, we held a meeting. We did not engineer reliability.

Keep the action list short on purpose

A long list of low-leverage tasks often means the team still does not understand the highest-value fix.

Prefer one or two changes that alter the default path:

• an owner for a surface that was implicitly “whoever last touched it”
• a check that would have made the failure obvious earlier
• a platform improvement that removes a class of recurrence
• a review or on-call change so the next response is not folklore

This is the same instinct as developer experience. Repeated operational tax should become infrastructure, not another heroic night.

Judgment is the other product

Good incident reviews improve not only reliability, but how the team thinks under pressure. They teach people to ask which layer failed: the task, the dependency graph, or a late decision.

That is what makes them worth doing. The document is a byproduct. The operating system is the point.