Postmortems

A postmortem is the written record of an incident after it is over. It captures what happened, why it happened, what the impact was, and what your team changes so it does not happen again. In Firefight every closed incident can have exactly one postmortem, and it lives alongside the incident’s timeline, actions, and follow-ups.

You can let AI write the first draft from the incident record, or start from a blank page and write it yourself. Either way the document stays editable by your team until you mark it completed. See Generating with AI for the drafting flow and Editing & revisions for the editor.

The nine sections

A generated postmortem is structured into nine sections, in this order:

Section	What it covers
Summary	The problem, impact, causes, and steps to resolve at a glance
Introduction	Context for readers who were not in the room
Timeline	Every recorded event, from declaration to resolution, in order
Deeper dive	A detailed narrative of how the incident unfolded
Impact	Who and what was affected, and for how long
Resolution	How the incident was brought to an end
Key contributing factors	The conditions that allowed the incident to happen
What went well	Response practices worth keeping
Action items	Concrete follow-ups that prevent a repeat

Every heading is always present on a generated document. The Timeline is never empty, and any section the AI had nothing for carries a short note asking you to add what you know. See Generating with AI.

The sections are a starting structure, not a cage. The document is free-form rich text, so you can expand, trim, or reorganize sections as your team sees fit.

Statuses

A postmortem moves through four statuses. The current status is always visible as a badge on the postmortem page and on the incident page card.

Status	Meaning
Draft	The document is being written and edited
In progress	Someone is actively working on it, set over the API or MCP
In review	The document is being reviewed by the team
Completed	The postmortem is finished

A freshly generated or blank postmortem starts in Draft. While AI generation runs, the page shows a placeholder until the draft arrives, and the status stays Draft throughout. When the write-up is done, use the menu in the top-right of the postmortem page to mark it as Completed. If something needs another pass, the same menu reopens it as a Draft.

Over the API and MCP

Everything above can be done without opening the dashboard. GET, POST and PATCH on /api/v1/incidents/:id/postmortem read the write-up, open it, and change its body or status, and MCP has get_postmortem, start_postmortem, update_postmortem and set_postmortem_status for the same four things.

Sending a new body replaces the whole document rather than appending to it, so read the current one first if you mean to add a section. Reading gives you a version, and sending a body means sending that version back, so a write built on a document somebody has since changed is refused rather than replacing their work. Every version is kept either way. See Using the API and the MCP server.

Where postmortems live

Each incident page in the web dashboard has a postmortem card. While the incident is still open, the card reminds you that a postmortem becomes available once the incident is resolved. After the incident is closed, the card offers Generate draft and Start blank. Once a postmortem exists, the card shows its status and links to the full-page editor. In Slack, the resolution message offers Write the postmortem as well.

From the postmortem page you can also export the document as PDF or as Markdown through the menu in the top-right corner.

Tip

Write the postmortem while memories are fresh. Generating a draft right after closing the incident gives reviewers something concrete to react to, which is much faster than starting from nothing a week later.