Incident Postmortem Builder

An outage is expensive, and the best thing a team can get from one is learning. A postmortem is the written review that captures what happened, why, and what will change. A good one is specific, honest and blameless: it examines the system and the process, so that people share what they know. This builder gives the review a standard shape and does the small calculations.

The details to enter

Name the incident, the severity (such as SEV-2), the date and the author. Enter the start and end time in 24-hour HH:MM form. Write a summary of two or three sentences, the impact on users and the business, and the root cause. Add how it was detected, what went well and what went wrong, one point per line. The timeline and action items have their own formats, described next.

The duration and timeline

The tool converts both times to minutes since midnight and subtracts. A start of 14:05 and an end of 15:40 is 95 minutes, printed as “1 h 35 min”. If the end time is earlier than the start, the incident is assumed to have crossed midnight and 24 hours is added. The tool does not convert time zones, so use one zone for all times. Timeline rows are typed as time | event, and the document sorts them by time even if you enter them out of order. Rows with times that are not in HH:MM form are placed at the start.

Root cause and actions

A useful root cause names the conditions that allowed the failure, not just the trigger: the migration ran in peak hours with no test on production-sized data. Action items should each be a concrete change with an owner and a date, typed as action | owner | due, for example “Add a pre-deploy check for long table locks | Karan Mehta | 2026-11-20”. They are printed in a table, with dates written in full. Vague actions such as “be more careful” are not actions.

A worked example

The sample is “Checkout errors after a database migration”, severity SEV-2, on 4 November 2026 between 14:05 and 15:40, authored by Karan Mehta. A schema migration added a column with a default value to the orders table, locked it, and checkout requests failed for 95 minutes. About 1,800 checkout attempts failed, and an estimated 410 orders were delayed rather than lost. The timeline has five rows, from “Migration started” at 14:05 to “Checkout error rate back to normal” at 15:40. The cause was that the migration ran during peak hours without testing how long it would lock the table. An error-rate alert fired four minutes after the start. Three actions follow: a pre-deploy check for long table locks, due 20 November 2026, a rollback decision rule for migrations, due 27 November 2026, and running migrations outside peak hours, due 13 November 2026.

Making it useful

Write the timeline from logs and chat history, not from memory. Include what people knew at each point, since decisions look obvious only afterwards. Share the document with every team that could be affected, and review the actions at a regular meeting until they are done. Track how often similar incidents recur.

Limits

The tool formats the review and computes the duration. It cannot diagnose the incident, validate the root cause or assign actions. Time calculations use the times you type with no time zone handling. The template is a common structure, and some organisations have their own required forms. Nothing you type is uploaded or saved.

Related tools

• Bug Report Builder records the defect that may have caused the incident.
• SOP Builder turns a lesson, such as a rollback rule, into a written procedure.
• SLA Generator sets the availability targets that an incident is measured against.
• RACI Matrix Builder clarifies who owns each action and each decision during an incident.