Incident Postmortem Template for Learning and Follow-up

Run a review that preserves evidence and accountability

Wait until the incident is stable enough for learning, then review the system and decision context with the people who hold the evidence. Keep facts, analysis, actions, and follow-up linked but separately owned.

1. Set the trigger, owner, audience, and boundary

   Use declared criteria to decide which incidents need a postmortem. Assign a facilitator or document owner, name the intended audience and confidentiality, link the incident record, and state what the review will not decide. Keep emergency work and time-bound notification duties ahead of the learning meeting.

   Sources: [postmortem-pack], [google-sre-culture], [gitlab-incident-review]

2. Start from impact, records, and one ordered timeline

   Summarize measured impact with explicit confidence, then build one UTC timeline from the incident record and sanitized evidence references. Preserve the lead-up, detection, response, stabilization, communication, and review-relevant decisions without rewriting uncertain observations into facts.

   Sources: [postmortem-pack], [google-sre-example], [nist-800-61r3], [pagerduty-template]

3. Review system conditions without assigning blame

   Assume people acted from the information and incentives available at the time. Examine causal, contributing, and protective factors across software, process, communication, tooling, ownership, and environment. Link formal causal claims to the separate RCA when one exists rather than treating one proximate error as the entire explanation.

   Sources: [postmortem-pack], [google-sre-culture], [atlassian-postmortems], [aws-post-incident]

4. Capture learning wider than cause alone

   Record what went well, what needs improvement, surprises, and lessons. Include decision context and unresolved or dissenting views so the final document does not imply more agreement than the review achieved. Remove or restrict end-user-identifying and operationally sensitive material before wider sharing.

   Sources: [postmortem-pack], [google-sre-culture], [pagerduty-template], [gitlab-incident-review]

5. Turn accepted findings into verifiable actions

   Give every corrective, preventive, detection, or process action a stable ID, source-factor references, role owner, due date, observable verification criteria, and follow-up date. Keep implementation and effectiveness as separate states; a merged change or completed task does not prove that risk was reduced.

   Sources: [postmortem-pack], [atlassian-postmortems], [gitlab-incident-review], [aws-post-incident]

6. Review the record and close follow-up honestly

   Complete a review of the findings and proposed actions, publish only to the appropriate audience, and revisit the evidence on the scheduled follow-up date. Mark an action verified, ineffective, or superseded from observed evidence. Leave the record open when effectiveness is unknown.

   Sources: [postmortem-pack], [google-sre-culture], [nist-800-61r3], [atlassian-postmortems]

The incident postmortem boundary

Use this owner for post-stabilization learning, review decisions, and accountable follow-through. Reference adjacent records by stable ID rather than absorbing their authority.

Three incident postmortem patterns

The record shape stays stable while the incident changes. Each pattern keeps facts, causal analysis, actions, and approval with their accountable owners.

Decide whether the postmortem is ready to publish

Structural validity makes missing ownership and contradictions visible. It cannot replace facilitator judgment, specialist review, or observed action outcomes.

1. The incident is still active, urgent protection is incomplete, or a time-bound notification decision is open.

   Choose: Keep the postmortem in draft and return authority to the response, safety, security, privacy, legal, or regulator-notification owner.

   Tradeoff: The learning document waits, but it does not distract from active protection or become an accidental command channel.

2. The timeline, impact, or factor statements have no evidence reference or contradict the incident record.

   Choose: Preserve the disagreement, repair the reference, and keep unsupported claims out of the accepted findings.

   Tradeoff: The review may publish later or with unresolved items, but confidence is not manufactured from consensus alone.

3. A causal statement relies on one human error, one proximate event, or an untested assumption.

   Choose: Return it to hypothesis or contributing-factor status and investigate the system, process, tooling, communication, and decision context.

   Tradeoff: The explanation becomes less simple, but the record is less likely to assign blame or fund an ineffective action.

4. An action has no source factor, role owner, due date, verification criteria, or follow-up date.

   Choose: Keep the action unaccepted until its ownership and evidence contract are explicit.

   Tradeoff: Fewer actions leave the meeting, but each accepted item can be tracked and challenged.

5. A change shipped, but the verification window has not passed or the expected result was not observed.

   Choose: Record implementation without marking the action verified; keep follow-up open or mark it ineffective when evidence contradicts the intended result.

   Tradeoff: Closure takes longer, but activity is not mislabeled as demonstrated risk reduction.

What an incident postmortem cannot prove

A disciplined record supports organizational learning. Its conclusions still depend on available evidence, memory, observability, facilitation, access, participation, analysis quality, and the time allowed for follow-up.

• A blameless approach improves the review frame but does not guarantee psychological safety, complete participation, unbiased analysis, or fair organizational decisions.
• A detailed timeline can expose gaps and decision context, but chronology alone does not prove causation.
• One accepted cause model can omit interacting technical, organizational, vendor, environmental, or human factors.
• A published action list does not authorize implementation, allocate capacity, approve a release, or prove effectiveness.
• Redacted references and access labels do not independently prove privacy, confidentiality, chain of custody, retention compliance, or legal privilege.
• A quiet follow-up window is bounded evidence, not proof that the incident cannot recur.
• This template is not a response plan, incident report, root-cause certification, public status update, regulator report, audit record, legal opinion, or project postmortem.
• This ordinary informational article does not grant AI signup credits. The linked product page follows its own current eligibility rules.

Sources and verification record

The same-release artifact supports the fictional record and validator claims. Current primary and first-party operational sources support the review principles and field model without certifying this pack or making local conventions universal.

1. [postmortem-pack] Playcode:Incident postmortem fictional example

   Checked August 1, 2026. Supports: The locally reviewed fictional record, field graph, validator behavior, tests, and reproducible archive. Public availability remains unverified until deployment.

2. [google-sre-culture] Google SRE:Postmortem Culture: Learning from Failure

   Checked August 1, 2026. Supports: Google SRE guidance on written incident learning, blameless review, trigger criteria, formal review, action quality, stakeholder sharing, and protecting identifying information. It documents one operating model, not a universal standard.

3. [google-sre-example] Google SRE:Example Postmortem

   Checked August 1, 2026. Supports: A fictional teaching example with status, summary, impact, trigger, resolution, detection, UTC timeline, factors, lessons, and owned action items. Its local field choices are not mandatory.

4. [nist-800-61r3] National Institute of Standards and Technology:NIST SP 800-61 Rev. 3

   Checked August 1, 2026. Supports: The April 2025 publication’s guidance on event sequence, systemic causes, investigation records, data integrity, sensitive-record safeguards, follow-up reports, lessons-learned meetings, and prioritized improvements. It is cybersecurity guidance, not a generic postmortem schema.

5. [pagerduty-template] PagerDuty Incident Response Documentation:Postmortem Template

   Checked August 1, 2026. Supports: PagerDuty’s own operational fields for ownership, meeting date, overview, contributing factors, resolution, quantified impact, responders, UTC timeline, evidence links, learning, and trackable actions. Timing and tool conventions remain local.

6. [atlassian-postmortems] Atlassian Incident Management Handbook:Incident postmortems

   Checked August 1, 2026. Supports: Atlassian’s first-party practice for ownership, chronological timelines, blameless language, contributing causes, specific follow-ups, and separate review of findings and actions. Its workflow and service targets are company choices.

7. [gitlab-incident-review] GitLab Handbook:Incident Review

   Checked August 1, 2026. Supports: GitLab’s public operating practice for blameless sequence and decision context, a named DRI, redaction, incident-record inputs, causal and action narrative, and linked follow-up. Its roles, tools, and timing are local.

8. [aws-post-incident] Amazon Web Services Well-Architected Framework:Perform post-incident analysis

   Checked August 1, 2026. Supports: AWS guidance on blame-free analysis beyond immediate human error, clear ownership, impact and supporting evidence, lessons, corrective actions, near misses, and feeding patterns into operating controls. It is not a legal or forensic standard.

Incident postmortem template questions