Postmortem AI: Write a Report You Can Trace to Evidence

You can use AI to draft a postmortem by giving it approved incident evidence, asking for a source-backed timeline, and reviewing every conclusion with the people involved. Let it organize the record and expose gaps; people decide what happened, what contributed, and which changes to make.

The useful output is a report that supports better future decisions. Tools like fenbs keep the resulting lessons, remediation tasks, and human decisions available to the next assistant, rather than leaving them buried in the drafting chat.

How do you draft a postmortem with AI?

1. Choose a human review owner and define the incident boundary: the affected service or process, the period under review, and the intended readers.
2. Collect permitted evidence in a source list. Label logs, alerts, deployment records, incident notes, and participant accounts so each has a stable reference.
3. Ask AI for a timeline with a source beside every event. Require it to mark contradictions and missing information instead of filling them in.
4. Draft impact, contributing conditions, response, recovery, and proposed follow-ups. Keep confirmed facts separate from explanations that still need investigation.
5. Review with participants, record the human conclusions, and turn accepted follow-ups into tasks with an owner and a completion check.

Run this process after immediate recovery work is under control. A report can record that an investigation remains open; it does not need a tidy explanation before the evidence supports one. Keep the original evidence available while you revise the narrative.

Which evidence should you give the assistant?

Start with a small, labeled collection that covers the important events. For a hypothetical checkout outage, that might include the first failed transaction alert, a release record, the incident channel summary, a rollback record, and a recovery chart. Explain what each source measures and what it cannot prove.

Remove secrets and unnecessary personal information before using an approved AI service. Keep restricted evidence in its authorized system and provide an appropriate reference or permitted summary. A long log pasted without context can make a precise-looking report harder to verify.

Ask participants what they knew at the time, including misleading signals and actions that seemed reasonable. Google's postmortem guidance↗ (opens in a new tab) describes a blameless approach focused on contributing causes rather than indicting individuals. AI should help make those conditions visible, not turn a person into the explanation.

How do you check the timeline instead of trusting it?

Require a consistent time zone and retain the original timestamp beside each normalized time. Distinguish when something happened from when someone reported it. A support message at 10:08 does not establish that the failure began at 10:08.

Have someone open the references and check the sequence. Ask the assistant to list conflicting timestamps, unsupported durations, and events whose order remains uncertain. Atlassian's postmortem guidance↗ (opens in a new tab) emphasizes specific timestamps and links to incident evidence. Do not let a smooth paragraph hide a discrepancy you still need to resolve.

How do you separate causes from plausible guesses?

Give the draft separate labels for observations, supported explanations, and open questions. "Errors increased after the release" is an observation. "The release caused every error" needs additional evidence. Ask what would weaken each proposed explanation, as well as what supports it.

Look beyond the triggering event. Consider detection, recovery access, confusing documentation, missing tests, and dependencies that increased the impact. A rollback restoring service may support a connection without explaining the mechanism. Keep that mechanism open until someone checks it.

Preserve what worked, too. If a clear escalation path helped recovery, say so and identify the evidence. Once people agree on the findings, Decisions and rules in fenbs can distinguish an approved change from an assistant's suggestion for the next session.

What makes a follow-up actionable?

A useful follow-up states the condition to change, who owns the work, and how the team will know it helped. "Improve monitoring" is difficult to finish. "Add an alert for checkout failures and demonstrate it with a controlled test" has an observable result.

Separate immediate repairs from prevention and further investigation. Give an unresolved theory an investigation task rather than quietly promoting it to fact. Use the principles in writing a task for an AI assistant to define the evidence and review expected before completion.

What needs human review before sharing?

Ask participants to check their part of the timeline, the service owner to review the explanation, and the relevant communications owner to review the audience and wording. Check impact figures against their source and name any missing coverage. Do not imply that no data was affected unless the investigation establishes that conclusion.

Review source access as well as the report itself. An internal link can expose sensitive details to a reader who should only receive a summary. Keep public communication as a separately approved document; writing a blog with AI addresses publication, while this workflow stays focused on incident learning.

A repeatable review gate is part of using AI at work, not a sign that the drafting failed. Keep the final human-approved report distinguishable from draft revisions, and leave open questions plainly visible.

How to do this with fenbs

1. Create a free account and add a project for the incident or the service improvement work. One person can start free, with no credit card.
2. Add the review and remediation tasks. Put the goal in each task and the investigation or implementation steps in its plan; link to permitted evidence in its authorized location.
3. Record what people decided in Decisions and rules. Save reusable findings as Lessons learned, including what future work should do differently.
4. Connect a supported assistant from Integrations. Ask it to read the project context before working, then save task progress, checks, and the next review needed before stopping.

fenbs does not monitor incidents, collect logs, or determine the cause of an outage. Keep those jobs in your incident and observability tools. Its role is the durable work record: the lessons, decisions, tasks, and next step that make the postmortem useful after the report is written. Explore more practical workflows in AI at work.