Blameless post-incident reviews, the lightweight version

Ask an IT team whether post-incident reviews are valuable and everyone nods. Ask when they last did one and the room gets interesting.

The pattern is almost universal. After the big outage, everyone agrees there should be a review. Scheduling takes a week. By then the fix is in, three new fires are burning, and the review either never happens or produces a document that gets filed and changes nothing. Six months later the same class of incident happens again, and the déjà vu in the incident channel is palpable.

The problem isn't commitment. It's that most PIR formats were designed for organisations with dedicated problem managers, and they're too heavy for a team where the reviewer is also the person fixing tomorrow's outage. Heavy processes don't degrade gracefully under load. They just stop.

So here's a format that survives real calendars: 45 minutes, five questions, one owner per action.

Before the meeting: build the timeline, not opinions

The only preparation that matters is a factual timeline: first alert, detection, key decisions, communications, resolution, verification. Timestamps from the ticket, the chat, the monitoring. No interpretation yet, just what happened when.

This used to take someone an hour of channel archaeology, which is exactly why it didn't happen. It's now a task AI does well: feed the incident channel export and the ticket log to an assistant and ask for a neutral timeline with timestamps and open questions. Ten minutes, including the human pass to correct what it misread. With the timeline in hand before the meeting, the meeting itself can be short, because nobody spends the first half hour reconstructing reality from memory.

The five questions

Run the meeting on these, in order, and park everything else.

What happened? Walk the timeline once, correct it, agree on it. Five minutes if the prep was done.

Where did we get lucky? The most underrated question in incident review. "The senior engineer happened to be online" and "it happened at 14:00, not at month-end close" are not comfort, they're warnings. Luck is unpaid technical debt, and this question surfaces it without accusing anyone.

What made detection or response slower than it should have been? Note the phrasing: not "who was slow." Missing monitoring, unclear ownership, a runbook that didn't exist, an escalation path that went through one specific phone. Systems, not people.

What do we change? Concrete, small, owned. Three actions maximum. Ten actions is the same as none; the discipline of choosing three forces the team to pick what actually matters.

How would we know it worked? For each action, what becomes observable? "Alert fires within five minutes for this failure mode" is verifiable. "Improve monitoring" is a hope with a verb.

Blameless, in practice

Everyone endorses blamelessness in the abstract. In the room it lives or dies on the language of the questions. "Why did you restart the node?" produces defensiveness. "What information did we have when the restart decision was made?" produces the actual answer, which is usually that the decision was reasonable given what was visible at the time, and the fix is making more visible next time.

One rule keeps this honest: if the review concludes a person should simply have been more careful, the review isn't finished. Careful is not a control. Tired, busy, well-meaning people make the same mistake again; checklists, alerts, and defaults don't get tired.

The part everyone skips: closing the loop

The actions from the last review are agenda item zero of the next one, and their completion rate is the one metric worth tracking about your PIR process itself. Teams with review action completion above roughly 80 percent see repeat incidents fall visibly within a couple of quarters. Teams below 30 percent are performing a ritual, and stopping the ritual would at least be honest.

We keep a one-page PIR completion checklist in the Opstimio library, alongside the major-incident checklist it pairs with, mostly because the failure mode of reviews is rarely the meeting. It's the follow-through, and follow-through improves the moment it's visible on a page someone owns.

Forty-five minutes, five questions, three owned actions, verified next time. Small enough to actually happen after every significant incident, which beats the perfect process that happens after none.