Incident Postmortem Template: From Evidence to Verified Actions

Know what a postmortem is—and what it is not

An incident report can record what responders did. Root-cause analysis can investigate a failure mechanism. A decision log can preserve why a choice was made. A postmortem connects all of those records to measured impact, response performance, uncertainty, corrective work and later verification.

Begin after stabilization, not during containment

During an active incident, the priority is safe detection, triage, containment, recovery and communication. The existing OpenMax guide to incident response automation covers that live-response job. A postmortem should not distract the incident commander with retrospective formatting while service restoration is still underway.

Open the postmortem when the incident policy's stability condition is met. Preserve the live incident log rather than editing it into hindsight. Record an evidence cutoff so late artifacts cannot silently change an approved conclusion.

Do not reduce the review to one root-cause sentence

“The deployment caused it” is usually too broad. A deployment may be the trigger; the direct mechanism might be a permissive default that enabled unbounded concurrency; validation, canary coverage and alert configuration may be contributing conditions. Each layer suggests a different control.

A single sentence also hides uncertainty. If production did not retain the effective configuration value, a mechanism supported by a diff, correlated metric and staging replay can remain PLAUSIBLE. That is more useful than promoting it to fact or deleting it because it is not yet certain.

Do not treat the meeting as the deliverable

The review meeting corrects the record and commits work. The durable deliverable is the approved document plus action evidence. A completed meeting with ownerless “improve monitoring” notes is not closure. Neither is a ticket marked done without the test named in the postmortem.

Google's public SRE guidance treats postmortems as written records with impact, mitigation, causes and follow-up work, while emphasizing review and system learning. Atlassian's public incident handbook similarly describes impact, mitigation, causes and follow-up actions. These are useful process references, not proof that one template fits every policy.

Freeze the evidence before the review meeting

Memory changes after a stressful event. Dashboards roll up old data, chat threads are edited, and a later theory can make ambiguous events look inevitable. An evidence register makes those changes visible.

Give every artifact a stable ID and limitation

For each log query, trace, alert, deployment event, ticket or decision entry, record:

1. a stable evidence ID;
2. its event time or covered interval and timezone;
3. the authoritative location and access class;
4. the collector or responsible system;
5. the narrow proposition it supports; and
6. what it cannot establish.

For example, a feature-flag audit entry supports that a path was disabled at a particular time. It does not prove that the queue drained or every subsequent result was correct. Those require separate artifacts.

Use links and redacted summaries instead of copying sensitive payloads

A widely readable postmortem does not need raw access tokens, request bodies, personal data or customer identifiers. Keep restricted evidence in the approved system and put a durable link, access class and minimally sufficient summary in the report. If reviewers cannot access the source, fix access through the normal authority path or provide an approved extract; do not paste secrets into the document.

Security, privacy, legal and customer-notification questions require the responsible specialists. NIST SP 800-61 Rev. 3, finalized in April 2025, connects incident response with broader cyber-risk management and improvement. A template is not a declaration of NIST conformity and cannot decide regulatory obligations.

Make the cutoff and addendum rule explicit

“Evidence current as of 2026-09-04T12:00:00Z” is testable. “Evidence collected after the incident” is not. State that material received after the cutoff goes into an addendum, names the claims it affects and triggers the appropriate re-review. Preserve the earlier state so readers can see why a conclusion changed.

Reconcile impact without changing the denominator

An impact sentence should name the unit, population rule, time window and outcome categories. “Hundreds of users were affected” cannot be inferred from hundreds of failed requests.

Pick one unit before calculating a rate

The unit might be requests, jobs, orders, accounts or people. Choose the unit your evidence can actually count. If retry behavior allows one person to create several requests, a request-level query cannot become a unique-user estimate without an identity-safe deduplication method and review.

PM081 uses render attempts. It makes no claim about users, workspaces, customers, revenue or contracts. Its population contains production attempts received between 09:07:11 and 10:18:00 UTC in one fictional region, excluding internal health-check retries.

Make categories mutually exclusive and exhaustive

Apply a documented precedence rule so each eligible row lands in exactly one outcome. PM081 assigns timeout first, then stale checksum, then expected checksum:

The reconciliation is 248 + 31 + 2,921 = 3,200. The impacted count is 248 + 31 = 279. The impact rate is 279 / 3,200 × 100 = 8.71875%, displayed as 8.72%. Keep the unrounded value or query output so a reviewer can reproduce the display.

Preserve exclusions and query versions

If a query changes from impact-v2 to impact-v3, record why. Do not overwrite the earlier export and then present the new number as if it were always known. List excluded records and the rule that excluded them. Have a data owner review category overlap, time boundaries and joins before approval.

Build an evidence-backed UTC timeline

A timeline is not a transcript dump. It contains the events needed to understand impact, detection, decisions, mitigation and recovery, with links to the evidence that fixes each time.

Distinguish event, observation, report and decision time

A timeout can occur at 09:07, a support report can arrive at 09:20, an alert can fire at 09:24 and the incident can be declared at 09:29. Those timestamps answer different questions. Treating the support receipt as the start would hide 12m52s of confirmed impact in PM081.

The core PM081 sequence is:

Define clocks instead of borrowing metric labels

From the table, first confirmed impact to automated alert is 16m49s. Declaration to mitigation action is 12m00s. First confirmed impact to sampled recovery confirmation is 1h10m49s.

Do not automatically call these MTTA or MTTR. Organizations disagree about start events, stop events, severity scope and pauses. Name the interval until an approved metric definition exists. This prevents a dashboard label from changing the historical meaning of the postmortem.

Use more than one recovery observation

An empty queue shows that work is no longer waiting. It does not show that returned previews are current. PM081 therefore records both queue clearance and a defined synthetic correctness fixture. Even together, those observations support sampled recovery rather than certainty about every result.

Analyze conditions without blame or false certainty

Blameless analysis assumes people acted with the information and systems available at the time, then asks which conditions made an unsafe outcome possible. It should improve candor without erasing responsibility.

Separate trigger, mechanism and contributing conditions

Use a claim table with one row per proposition:

• Trigger: the change or event that initiated the path to failure.
• Direct mechanism: the technical or operational process that produced the observable failure.
• Contributing condition: a safeguard, interface, workload, documentation or detection condition that increased likelihood or impact.
• Alternative: a competing explanation that should be retained until evidence confirms or disproves it.

In PM081, deployment of a configuration-schema change is CONFIRMED as a trigger. The theory that an omitted max_inflight became unlimited and exhausted a downstream pool is PLAUSIBLE, not confirmed. Validator acceptance of missing/non-positive values, missing burst coverage in the canary, and a delayed queue-age alert are confirmed contributing conditions. Database content corruption is disproved for this incident by the cited integrity scan, without claiming every possible database fault is impossible.

Record the reasonable context of decisions

Ask what the responder saw, which runbook version was available, what authority they held and what competing risk existed. “Why did the engineer wait?” invites hindsight. “Which signal was available at 09:12, and what action did the current runbook authorize?” produces evidence and a changeable system condition.

This does not prohibit documenting an error. It avoids stopping at the person's identity when validation, defaults, access, review or workload design can reduce recurrence.

Keep unknowns visible

PM081 cannot determine whether affected attempts occurred before the first retained trace. That row stays UNKNOWN. It is not deleted because it makes the story less tidy. The owner can define a retention or telemetry action if closing that gap is worth its cost and privacy implications.

Turn findings into actions that can be verified

An action should state the risk it addresses, the concrete change, a responsible owner, a due date and an observable verification contract. “Be more careful” and “improve monitoring” do not meet that standard.

Separate implementation from effectiveness

Use states such as OPEN, IN_PROGRESS, IMPLEMENTED, EFFECTIVENESS_VERIFIED and ACCEPTED_RISK. A runbook can be implemented when its version is published. It becomes effectiveness-verified only after the specified operator test succeeds and the evidence is reviewed.

PM081's A04 adds feature-disable, backlog and correctness checks to the rollback runbook. It is IMPLEMENTED at the cutoff, but the independent game day has not occurred. The record refuses to call it effective.

Write the verification contract before closure

“Add a load test” is a task. “Replay a 1,000-job staging burst with a 40-worker ceiling; verify the queue drains, active workers never exceed 40, and the defined fixtures return no stale result” is a verification contract. It names the workload, thresholds and observations.

The threshold remains an illustrative design choice for PM081, not a recommendation for every system. A real service owner must set capacity and correctness criteria from its architecture and risk tolerance.

Track accepted risk as a decision, not a missing ticket

Some actions cost more than the risk justifies. If the authorized owner accepts that risk, record the rationale, scope, review date and authority. Link the decision to a decision log when the tradeoff deserves its own durable history. Silent abandonment is not accepted risk.

Complete worked example: PM081

The downloadable packet is deliberately complete enough to audit. It includes nine evidence records, seven roles, seven causal claims, five corrective actions, a 60-minute review agenda and a follow-up ledger. It also leaves approvals and later observations incomplete where no evidence exists.

What happened in the fictional service

Northstar Preview deployed v4.18.0 at 09:02:14 UTC. Queue age and connection-pool use began rising at 09:06:50. The first retained timeout appeared at 09:07:11. Support received a symptom report before the automated alert. Responders declared a fictional SEV-2, disabled the new path, watched the backlog clear and ran a defined synthetic fixture.

The example does not infer that the deployment alone caused the incident. Its current mechanism remains plausible pending an independent service-lead review.

What the response evidence can and cannot prove

The feature-flag entry proves the mitigation action occurred, not that recovery was complete. The zero-queue metric proves the backlog cleared, not that content was current. The synthetic fixture supplies a correctness sample, not a census. The impact export supplies attempt-level counts, not unique people.

This repeated “supports / does not establish” pattern is intentional. It prevents a source artifact from carrying more certainty than it contains.

Why the packet is not presented as success evidence

At the cutoff, three reviews are pending: service-lead review of the mechanism, data-lead review of the impact query, and a security/disclosure screen. No corrective action is EFFECTIVENESS_VERIFIED. The document remains IN_REVIEW.

Download the complete PM081 packet and try to reproduce the impact arithmetic and each clock before using the empty worksheet. A useful template should make disagreement inspectable, not merely make the report attractive.

Run the review meeting and approval path

The facilitator should circulate the draft and access instructions before the meeting. Participants should correct evidence and commitments, not read a long document for the first time on the call.

Use a sequence that protects the denominator and evidence

A practical 60-minute PM081 review reserves 5 minutes for scope and blameless rules, 10 for impact reconciliation, 12 for timeline corrections, 15 for causal claims and alternatives, 12 for action commitments, and 6 for readback and approval conditions.

The allocation is illustrative. A complex security incident may need several specialist sessions. A small operational event may be resolved asynchronously if policy permits and disagreement is low.

Invite roles that can correct the record

Include the incident commander, service owner, data owner for impact calculations, observability owner, relevant action owners and an impartial facilitator. Add security, privacy, legal, communications or vendor specialists when the incident scope requires them. Attendance does not automatically grant approval authority; record who may sign which conclusion.

End with a readback, not an optimistic summary

Read back changed claims, remaining unknowns, accepted actions, owners, dates, verification criteria, redactions and approval conditions. If a specialist review is missing, keep the document IN_REVIEW. Publish an addendum when late evidence changes a conclusion rather than silently replacing history.

Test OpenMax on a bounded drafting task

OpenMax's public DevOps use-case documentation describes using supplied incident materials to structure reports, flag missing fields and track follow-up actions. That vendor description supports a narrow drafting trial. This page did not test the product, integrations, retrieval permissions, output accuracy or published performance figures.

Start with a known-answer packet

Provide the fictional PM081 packet and ask for a draft containing:

1. all nine evidence IDs with their limitations;
2. the exact 3,200-attempt reconciliation and 8.72% rounded rate;
3. separate event, report, alert, decision and recovery times;
4. C01–C07 without promoting PLAUSIBLE or UNKNOWN claims;
5. A01–A05 with current states and verification contracts; and
6. an explicit list of pending approvals.

Compare the output with the source packet. Reject any draft that invents a customer, converts attempts into users, calls A04 effective, drops uncertainty, or treats a vendor statement as independent evidence.

Keep human authority at the evidence and approval gates

Only authorized people should select or expose source material. Data and service owners review quantitative and technical claims. Security/privacy/legal reviewers control sensitive handling. The postmortem approver controls publication state. An AI-generated draft does not acquire any of those authorities.

Before using live records, ask OpenMax or the relevant administrator to verify current connectors, retention, permissions and data-handling terms for the intended environment. The public example is not a substitute for that verification.

Prefer a simpler method when complexity is low

A stable document template and work tracker may be enough for a small team with infrequent incidents and a short evidence set. Do not introduce an AI drafting layer when source authorization is unresolved, when reviewers cannot inspect citations, or when the organization has not defined incident ownership. The smallest credible next step is one redacted known-answer exercise, not autonomous production ingestion.

Avoid failure modes that polished reports can hide

The denominator drifts between drafts

One section counts requests while another counts users, or the time window changes without updating the rate. Fix this with a versioned population rule, mutually exclusive categories and an explicit reconciliation equation.

The timeline becomes a memory consensus

Participants agree on an approximate sequence but the report loses the alert, log and decision links. Keep evidence IDs beside the timestamps and label inferred times.

“Root cause” absorbs every condition

A broad root-cause paragraph makes it impossible to map controls. Separate trigger, mechanism, contributing conditions, alternatives and unknowns; attach a state to each.

Blamelessness becomes ownerlessness

The report avoids personal blame but also avoids action owners. Keep the analysis system-focused while assigning clear responsibility for implementation, verification and approval.

Completion is mistaken for effectiveness

A ticket closes when code merges or a runbook is written. Preserve a separate effectiveness state and require the pre-agreed observation before using it.

Sensitive evidence is copied for convenience

Raw tokens, customer content or personal data move into a broadly shared document. Use stable restricted links, approved extracts and specialist redaction review.

Frequently asked questions

When should an incident require a postmortem?

Use pre-defined policy triggers such as severity, customer or data impact, unusual recovery work, repeated failure, compliance obligations or high learning value. Do not decide only after seeing whether the incident story is comfortable to publish. Have the appropriate owner approve exceptions.

How soon should the review happen?

Preserve evidence immediately after stabilization and schedule review while context remains available, but allow enough time to build a defensible impact query and causal analysis. The right window depends on severity, evidence retention and specialist availability; this guide does not prescribe a universal number of days.

Is a blameless postmortem the same as no accountability?

No. Blameless analysis avoids reducing system failure to personal fault. Accountability remains visible through evidence ownership, claim review, action owners, due dates, approval and effectiveness checks.

Can AI determine the root cause?

AI can help organize supplied evidence and expose missing fields, but a plausible narrative is not causal proof. Service owners must review mechanisms, data owners must validate impact, and qualified specialists must assess security, privacy, legal or regulatory implications.

When is a corrective action complete?

Use at least two states: implemented and effectiveness verified. Define the test, threshold, evidence and reviewer before closure. If the test fails, reopen or replace the action without rewriting its original intent.

Sources and related OpenMax workflows

Primary and official sources consulted on 2026-09-05:

• Google SRE Book: Postmortem Culture
• Google SRE Workbook: Postmortem Culture
• NIST SP 800-61 Rev. 3: Incident Response Recommendations
• Atlassian Incident Management Handbook: Postmortems
• OpenMax DevOps use-case documentation

Continue with incident response automation for the live-response workflow, or use the decision log template when a durable risk or prioritization decision needs its own record. Product capabilities and security-sensitive guidance should be rechecked against current official documentation and internal policy before publication.