Answer the questions an incident review should cover. The generator turns them into a clean Markdown postmortem with a timeline and an action-item table you can paste into your wiki.
Runs entirely in your browser — nothing you enter here is sent to a server.
A postmortem is the written review of an incident: what happened, what it cost, why, and what will change. "Blameless" means it assumes everyone involved acted reasonably with the information they had, and looks for the conditions that made the failure possible — a missing check, a confusing default, an alert that came too late — instead of a person to hold responsible.
That is not politeness for its own sake. People who expect to be blamed leave out the details that matter most, and the next incident repeats the last. A review that is safe to be honest in is the only kind that produces accurate information.
Two or three sentences a manager can read, then numbers: how many users, how long, how much. Avoid adjectives; give figures.
Timestamps from logs and chat, not from memory. Include detection and each decision — the gaps between entries show where time was lost.
Keep asking why until you reach something you can change. "Human error" is where the analysis starts, not where it ends.
Each with one owner and a date. Three that get done are worth more than fifteen that sit in a backlog.
Write the draft within a few days, while people still remember, and hold a short meeting to correct it. Say "the deploy was not load tested" rather than "Sam did not load test the deploy" — the system allowed an untested deploy, and that is the part you can fix. Then publish the document where the whole engineering team can find it, and track the action items like any other work.
A summary, the impact in numbers, a timestamped timeline, the root cause and contributing factors, what went well and badly, and action items with owners and due dates.
For every incident above an agreed severity, and for any near miss the team can learn from. Write it within a week, before details fade.
Describe actions and system conditions rather than individuals' failings, assume good intent, and ask how the process allowed the mistake. Names appear as owners of follow-up work, not as causes.
As short as it can be while still letting someone who was not there understand what happened. One to two pages is typical; a long timeline can go in an appendix.
Upzilla checks your sites, servers and APIs around the clock and alerts you the moment something breaks. 10 monitors free, no card required.