How to write a simple incident postmortem report for your team

When something breaks in production, the instinct on many Australian engineering and operations teams is to patch it, ship the fix, breathe out, and move on. A quiet week later nobody remembers the chain of events that led to the outage, and the same mistake quietly reappears six months later. A simple incident postmortem report is the cheapest insurance you can buy against that cycle. It does not need to be a forty-page document or a courtroom-style investigation. A few pages written honestly within a week of the event are usually enough to capture the lessons that matter, and they will save your team real time when the next disruption lands at 3am Sydney time.

A postmortem is not a blame report. The whole point is to look at the system, the assumptions, the alerts, the handover between shifts, and the tooling that was or was not available, then write down what to change. Most Australian teams treat these documents as internal references rather than public case studies, and that is healthy. The trick is to make them short, structured, and actually read by the people who can act on them, instead of buried in a shared drive in Adelaide or Perth that nobody opens.

Pin down the scope before you write a single line

Start by agreeing on what the incident actually was. Was it a fourteen-minute outage of the customer portal, a corrupted batch job that mailed two hundred duplicate invoices, or a slow leak that exposed a misconfigured storage bucket to the public internet? Whatever it was, write a one-sentence definition in plain English and put it at the top of the document. If the team cannot agree on the definition in five minutes, the postmortem is probably trying to cover more than one incident, and you should split it.

Next, decide who needs to be in the room when you draft the report. For a moderate incident on a Melbourne-based product team, that usually means the on-call engineer, the team lead, a representative from the platform or SRE group, and someone from customer support who saw the tickets come in. Pull in legal or the privacy officer if there is any chance the incident touches the Notifiable Data Breaches scheme under the Privacy Act 1988, because the report may eventually feed into an OAIC assessment.

Finally, set a deadline. Most teams in Australian organisations find that a week is the sweet spot. Long enough for the adrenaline to settle, short enough that the logs are still useful. If you let it drag to six weeks, you will end up guessing at things that should have been obvious the morning after.

Reconstruct a timeline that anyone can read

The backbone of any incident postmortem is the timeline. You want it short, dated in local Australian time (AEST or AEDT depending on the state), and stripped of jargon. A bullet list works fine. Walk through what the monitoring system showed, what the on-call engineer saw, what they did, and what customers experienced.

Aim for entries at five-minute granularity during the active phase, then switch to coarser entries for the recovery and verification window. Keep each entry to one sentence: "10:15 AEDT – PagerDuty alert fires for checkout latency above 4 seconds." Not a paragraph, not a story, just the fact, the time, and the source.

A useful tip from teams operating across Brisbane, Sydney, and Perth is to standardise on a single timezone in the report, even if the responders were spread across states. Mixing WST and AEST in the same document is a reliable way to confuse everyone during the review meeting. If the incident crossed daylight saving boundaries, note it once at the top so nobody has to convert in their head while reading.

What a clean timeline entry contains

• A timestamp in 24-hour local time with the timezone abbreviation
• The system or human that observed or performed the action
• A single concrete fact rather than an interpretation or guess

Look for contributing causes, not a single root

The phrase "root cause" is one of the most damaging ideas in incident review. Real outages almost never have a single root. They have a chain of contributing causes: an untested deploy, a missing alert, a documentation gap, an assumption that turned out to be wrong, and a handover that lost context between the Friday shift in Canberra and the Monday shift back in Sydney.

A simple way to surface those causes is to ask "why" five times for each visible failure, and write down every answer that is not "because the engineer made a mistake." Most answers are about the system. That is what you can change. The person who clicked the button at 2am will probably never face the same combination again, so writing a paragraph about their judgement is mostly noise.

If your organisation follows the Australian Cyber Security Centre's Essential Eight or operates under APRA CPS 234, this is also the moment to check whether the incident reveals a maturity gap in those controls. A short note in the postmortem linking the cause back to the framework makes the follow-up actions much easier to defend at the next executive review.

Categories worth checking when you ask why

• Detection and alerting, including thresholds, routing, and silence rules
• Deployment and change management for the affected service
• Documentation, runbooks, and onboarding for new on-call staff
• Handover and shift coverage, especially across states and timezones

Capture what went well, not only what broke

Teams that only write about failure start to dread the postmortem meeting. Reserve a clear section in the document for things that worked. The on-call rota held. The runbook was actually useful for once. The status page went out within ten minutes. A customer in Hobart got a personal response from support before they even filed a ticket. These positives matter because they tell you which investments are paying off, and they remind the team that an incident is not a referendum on their competence.

This is also the section where you list the early signals that did not trigger a page. Often there is a metric, a log line, or a slow-rising queue that would have caught the problem an hour earlier if anyone had wired it into the alerting rules. Capture those quietly and without judgement. The team that owns the monitoring stack will thank you for it, and the next on-call rotation in your Sydney office will benefit.

Writing this section well also builds a habit of noticing what is working in your stack, much like a small retail team might open the https://e-pragati.org/gold-rate-today page each morning before the shop doors open in the CBD, a quick, trusted reference point that grounds the day.

Write actions that someone actually owns

A postmortem without actions is just storytelling. Every action item needs an owner, a due date, and a one-line description that does not require reading the rest of the document to understand. Avoid lines like "improve monitoring." Write "Add a P2 alert for checkout latency above 2 seconds for five consecutive minutes – owner: Priya, due 22 November."

Keep the action list short. Three to five items is plenty for a modest incident. If you find yourself writing fifteen actions, you are mixing tactical fixes with strategic changes. Split them. Tactical fixes go in the same document and close within the sprint. Strategic changes, such as rewriting the deploy pipeline or reworking the on-call rota across Melbourne and Adelaide, belong in a separate roadmap entry tracked over a quarter.

Track the actions in whatever system the team already uses. If your organisation has invested in course enrollment tracking through e-Pragati, the same workflow can host a small "incident follow-ups" module where each postmortem action is a card with an owner and a status. That keeps the postmortem document and the actual work in the same loop, instead of the report drifting off into a forgotten folder.

Share the report, then close the loop

Distribute the draft within a day or two of the deadline. Read it together in a thirty-minute meeting. The goal of that meeting is not to debate every word, it is to confirm the timeline, add anything missing, and adjust the actions. Capture the changes, publish the final version in whatever knowledge base the team already uses, and link it from the original incident ticket.

If the incident was severe enough to trigger reporting under the Security of Critical Infrastructure Act 2022 or to involve the ACSC, the report may need to feed into a wider governance process. In that case, keep a tight executive summary at the top of the document that a non-technical reader can absorb in three minutes: what happened, who was affected, what was done, and what is changing. The detail stays below.

Two weeks after publication, check which actions are actually closed. If they are not, that is itself worth writing down. Patterns of unclosed actions tell you something about workload, prioritisation, or trust in the process. A simple postmortem that gets read and acted on is worth more than a beautifully formatted document that nobody opens.

Pick a small template that suits your team, write it within a week of the incident, share the final version widely, and treat the action items as real work that lives on a visible board. Agree on a default owner for the next postmortem before you leave the review meeting, and schedule a thirty-minute check-in at the two-week mark to confirm the actions have landed. Your future self, on the next 3am page in Sydney or Perth, will quietly thank you for the habit.