Post-mortem report PM-2026-09, booking outage, Slotharbour
Post mortem report template with a timeline, five whys and owned actions
A post mortem report has to explain what happened, what it cost, why the system allowed it, and what will stop it happening again, without blaming the person who made the change. This four page blameless review of a 107 minute booking outage gives the impact in four figures, a timed timeline, five whys down to a root cause, and six actions with owners and dates.
The document, page by page
Every page as it renders and as it prints, with nothing summarised. Read the wording before you reuse it.
Section by section
What each section is for, so you can keep the ones you need and drop the rest.
- Reference block and blameless note
- Incident number, date, review meeting, author and status, and how the review treats people.
- 1 and 2. Summary and impact
- The change and the connection arithmetic, then four impact figures and availability against target.
- 3. Timeline
- Ten timed events from approval to resolution, with detection and diagnosis times.
- 4. Five whys and root cause
- Five numbered whys down to two separated settings and no total check.
- 5. What went well and what did not
- Three of each, side by side.
- 6 and 7. Actions and customer communication
- Six actions with owners and dates, then status page updates and the venue email.
How to adapt this document
First, for a non technical failure, such as a missed delivery run or a payroll error, keep the same skeleton and swap the system terms for process steps; the timeline and five whys work just as well. Second, for a smaller incident, merge the summary and impact into one paragraph and drop the communication section, but never drop the actions table. Third, if your organisation has service level targets, always state the availability for the period against the target, because that number tells leadership how much the incident cost in terms they already track.
What makes this document work
The arithmetic of the failure is on page one
The summary states the sum that broke the system: 48 workers at 20 connections each tried to hold 960 against a limit of 500. Anyone reading it understands the failure without knowing the code, and the deploy check in action 2 tests exactly that product.
The timeline shows where the time went
Ten timed rows show the alert firing at 18:02 into an email inbox, the page at 18:19, a restart at 18:46 that treated the symptom, and the link to the deploy at 19:12. The note under it turns that into 15 minutes to detect and 53 to diagnose.
The whys stop at a condition, not a person
The third why lands on two configuration files that live apart and a review that showed only one. The root cause is that no check stops the total passing the limit, which is fixable. A why that ends at a name fixes nothing.
Questions people ask
What does blameless mean in a post mortem?
It means the review assumes people acted reasonably with the information they had, and looks for the conditions that let a normal action cause harm. People are named by role, not singled out. Blame makes people hide mistakes, which hides the next outage's cause. Blameless does not mean nobody is accountable for the actions that follow.
When should a post mortem be written?
For every incident above an agreed severity, and for near misses that could have been serious. Hold the review within a few working days, while memories and logs are fresh; here the outage was on a Tuesday, the meeting on Friday and the report published the following Monday. Waiting weeks loses detail and momentum.
Is five whys always five?
No. Five is a rule of thumb that pushes past the first, obvious answer. Stop when you reach a condition the organisation can change, which may take three whys or seven. Watch for branches too: the missed alert here is a separate chain that lengthened the outage, so it gets its own action.
Who should attend the post mortem meeting?
The people who responded, the owner of the system that failed, someone from customer support, and a facilitator who was not deeply involved. Fourteen people attended this one. The meeting checks the timeline, agrees the root cause and the actions; the written report records what was agreed, with owners and dates.
Should a post mortem be shared with customers?
Many software companies publish a shorter public version: what happened, the impact, the cause in plain terms and what is changing. Keep internal details such as system names and staff roles out of it. Customers mostly want to know it will not happen again and whether they are owed a credit, as the venue email here explains.
How do you make sure the actions get done?
Give each one a single owner and a date, track them where engineering work is already tracked, and review open actions at a regular meeting until closed. Rank them: here action 1 was done the next day, while action 4 removes the whole class of failure but takes weeks, so actions 2 and 3 cover the gap.
Build your own in about a minute
The button below opens the generator with this use case already described. Change the wording to match your own, generate, then edit anything you like.
Make one like thisOther document examples
Test report template with cases by area, a pass rate chart and open defects
A test report has to tell the people who decide on a release what was tested, what passed, what is still broken and whether the agreed exit criteria are met. This four page report for a payroll module release counts 378 cases by area, charts the pass rate, lists every open defect with a decision, and ends with sign off from QA and the product owner.
Progress report template with done, next, blocked and budget burn
A progress report has to tell the person paying, in two minutes, whether the work is on track, what happened, what happens next and what they need to decide. This two page weekly report for a website rebuild at week 6 of 12 does that with a status strip, done and next tables, one blocker with a deadline, budget against time and five dates.
Sustainability report template with targets, progress charts and data
A sustainability report has to show readers which targets a business set, how far it has come against each, where it is behind, and what it will do next, with the data to back it. This nine page report for a furniture maker tracks eight targets, charts progress, covers timber and suppliers, repair and take back, climate, people and community, and ends with owned priorities.
Want the steps in the builder? Read Create a document with AI, then Document builder components. For everything this generator can do, see the document maker.
Written and checked by the OneCraft team. Last checked .