Izveidot kontuCreate account
‹ All playbooks
Write a blameless post-incident review

ops.incident-postmortem·version 1.0.0·draft

Write a blameless post-incident review

The incident has a written, blameless review with a timeline, root cause, and owned follow-up actions tracked to closure.

KasparsOperations Leadruns itProfile ›
Whenon an event — an incident is marked closed in the incident log
Who actsthe agent prepares only
Time60–90 min active for the agent, 15 min for the owner
Countryany country
Sign in to run thisThis playbook opens inside Brain Club. Sign in to read and run it.

When to use

An incident was just closed — outage, data mistake, missed deadline, angry-customer event — and the cause is not yet understood or its fix is not yet tracked. Not while the incident is still open — use agents.incident-response first; a review of an unresolved incident is fiction. Not for a single customer complaint with no operational cause — use ops.customer-complaint. Not for a security incident with possible legal consequences — use tech.security-audit and involve the owner before anything is written.

Before you start

  • The incident is closed and its record has a start time, detection time, and close time.
  • Raw material is collected within 48 h of closure: chat threads, alerts, deploys, screenshots. Logs age badly.
  • A facilitator is named (the agent drafts; a person facilitates the review meeting if one is held).
  • Everyone involved knows the rule up front: the review assumes everyone acted reasonably with the

What a run requires1

  • Approval · S5 · ownerthe run stops until a named person records the decision

Any step can wait until a date and reopens by itself; every closed step leaves evidence (a note, a link, a number).

The trail8 steps

  1. Assemble the raw timelineagent

    Walk the material chronologically: first symptom, first alert, first human action, each fix attempt, the actual fix, the close. Record times in one timezone (Europe/Riga).

    Done when a draft timeline exists with a source (log line, message, deploy id) next to every entry.

  2. Quantify the impactagent

    Write down: duration from detection to fix, who or what was affected, what customers experienced, what it cost or could have cost, what customers were told and when.

    Done when the impact section has numbers or an explicit "no customer impact" with the reason.

  3. Find the root cause — ask why until it stops being a personagent

    Trace the chain: the trigger, why the trigger was possible, why detection took as long as it did, why the fix took as long as it did. Stop at a system, process, or missing-check cause, never at "X made a mistake".

    Done when the root cause is a sentence about a system or process, and the contributing factors are listed separately. ⛔ If the draft says a person "forgot" or "didn't check", it is not done — find the check or guardrail that was missing instead.

  4. Draft the reviewagent

    Use the template: summary, impact, timeline, root cause, what went well, what went badly, lessons, proposed actions. Keep it under two pages.

    Done when the draft is in the documents module, linked to the incident record, and readable by someone who was not there.

  5. Review and accept the documentownerneeds approval · owner

    Approval · S5 · owner — the run stops until a named person records the decision

    The owner reads the draft, corrects facts, and accepts it or sends it back once with specific changes.

    Done when the owner has said "accepted" in writing, or returned it with changes that the agent then applies and resubmits. ⛔ Do not soften the root cause to protect anyone — if the owner wants it softened, record the owner's wording but keep the factual chain in an appendix.

  6. Turn lessons into owned actionsagent

    Each lesson becomes a task with an owner and a due date (typically 14–30 days). Create them in the tasks module with bc tasks add, and link them to the incident record. If an action is big enough to be a goal, create it with bc goals add instead.

    Done when every proposed action is a task or goal with a named owner and a date — or is explicitly rejected by the owner with a reason.

  7. File and circulateagent

    File the accepted document in the documents module under postmortems, and send the owner a three-line summary: what happened, root cause, actions and owners. If customers were affected, note whether management.crisis-communication output needs updating.

    Done when the document is filed, the summary is sent, and the tasks appear in the owners' task lists.

  8. Track actions to closureagent

    Check the linked tasks weekly until all are closed. Escalate any action past its due date to the owner once.

    Done when every action is closed or the owner has accepted a written reason why it will not be.

Checks — how we know it worked

  • Read the root-cause sentence aloud: it names no person and no team as the cause.
  • Every timeline entry has a time and a source.
  • Every lesson has a corresponding task or an explicit rejection.
  • The document is findable by someone searching the documents module for the incident id.
  • 90 days later: no repeat incident with the same root cause (check at the next quarterly review).

If it goes wrong

SymptomResponse
The draft blames a personRewrite S3: ask what check, alert, or guardrail would have caught it; the person becomes a contributing factor only if they had information nobody else had.
Timeline times disagree between sourcesPrefer machine records (logs, alerts, deploys) over memory; mark remembered times as approximate.
The owner will not accept the documentAsk for specific factual corrections only; if the disagreement is about conclusions, record both positions in the document.
Actions pile up unclosedAt three overdue actions, raise it in management.weekly-owner-review rather than chasing privately.
Same root cause recursThe previous review's actions were wrong or unfinished — reopen that document, do not start from scratch.

What each step leaves behind

  1. S1a draft timeline exists with a source (log line, message, deploy id) next to every entry.
  2. S2the impact section has numbers or an explicit "no customer impact" with the reason.
  3. S3the root cause is a sentence about a system or process, and the contributing factors are listed separately. ⛔ If the draft says a person "forgot" or "didn't check", it is not done — find the check or guardrail that was missing instead.
  4. S4the draft is in the documents module, linked to the incident record, and readable by someone who was not there.
  5. S5the owner has said "accepted" in writing, or returned it with changes that the agent then applies and resubmits. ⛔ Do not soften the root cause to protect anyone — if the owner wants it softened, record the owner's wording but keep the factual chain in an appendix.
  6. S6every proposed action is a task or goal with a named owner and a date — or is explicitly rejected by the owner with a reason.
  7. S7the document is filed, the summary is sent, and the tasks appear in the owners' task lists.
  8. S8every action is closed or the owner has accepted a written reason why it will not be.

Evidence to keep

The incident id · the accepted document and its version · the raw timeline with sources · the owner's acceptance (who, when) · the task ids for every action · the closure status of each action at 30 and 90 days.

How this playbook improves

After every 5 reviews ask: how many days from close to accepted document, and what caused the delay? What share of actions closed by their due date? Did any incident repeat a root cause from a previous review — if so, its actions failed and the S6 format needs changing. A new version changes the step behind the worst measure and says so in its change note.