An almost 2-hour outage is fixed: what goes in the postmortem?

On a Monday afternoon, the order page of an online shop hangs for almost 2 hours after an update. The team fixes it by evening, and 2 weeks later a nearly identical bug strikes again. This is an illustrative scenario, not an incident at any real company.

What is missing is a postmortem: a written record made after the fault is handled, saying what happened, why, and what to do so it is less likely to repeat. This article draws on Google's books, documents from Atlassian and PagerDuty, and Richard Cook's paper How Complex Systems Fail, checked on October 26, 2026.

Key points

• A postmortem records the impact, the response, the causes and the work to prevent a repeat. Rolling back a bad release only restores service and does not explain why the fault happened.
• Set the threshold for writing one before an incident occurs. The pages read give no number of outage minutes large enough to require a report.
• Blameless means asking why the system allowed the mistake, not who made it.
• "5 whys" is useful if it does not force a single cause: Atlassian defends it and lets the chain grow into a tree of factors, while PagerDuty (citing Richard Cook) advises finding contributing factors rather than 1 root cause.
• The deciding part is the follow-up work: each item is specific, has 1 owner and 1 due date (Click Star's framework), and sits on the team's daily task board.

What a postmortem is and why not to skip it

A postmortem is a written record of an incident: the impact, what was done to handle it, the causes, and the work to stop a repeat. This follows Google's SRE book (copyright 2017) and matches Atlassian's handbook.

Fixed does not mean understood. According to Atlassian, rolling back a bad change restores service but does not tell you what broke and why. Google writes that without a formal process for learning, incidents can recur without end.

Click Star already has separate articles on website monitoring, on backup and recovery, and on project documentation. This one covers what comes after.

When to write one and how fast

Write the threshold down before an incident happens, so nobody argues about it when tired.

Google lists 5 common triggers: users see errors or slowness beyond some level, any data loss, on-call engineer intervention (such as a release rollback), resolution time above some level, and a monitoring failure. The chapter gives no number of days.

Atlassian writes postmortems for severity 1 and 2 incidents, while PagerDuty does so for every major incident (levels 2 and 1), including false alarms.

On timing, Atlassian (its Incident Postmortem page) suggests a review meeting within 24 to 48 hours of resolution and no later than 5 business days. PagerDuty sets 3 calendar days for level 1 and 5 business days for level 2 to finish the report and hold the meeting.

These are each company's own policies, not a common standard.

Click Star's reference framework, not taken from outside sources: a small team writes a report when it sees 1 of 4 signs. Customers report it before the team knows. Data is lost or wrong. A rollback or a restore from backup was needed. The fault lasted longer than a limit set in the company's own rules.

Blameless: how to do it and why it helps

Blameless means examining how the system allowed the mistake to happen, instead of asking who was wrong. According to Google, this kind of report assumes everyone had good intentions, and in a culture of finger pointing people hide problems for fear of punishment.

Illustrative example: an employee runs an update command at peak hours. The blaming report says "A was careless". The blameless report asks whether any rule forbids updates at peak hours, and whether any check blocked that command.

3 practices from the documents:

• Open the meeting by stating that it is blameless, and refer to people by role such as "the on-call engineer" instead of by name (Atlassian).
• Ask "what" and "how" questions instead of "who" and "why"; any "why" should aim at how the system was designed (PagerDuty).
• Build the timeline from before the incident and move forward, not backward from the fix, to avoid looking back with knowledge of the outcome (PagerDuty).

Blameless does not mean nobody is accountable. PagerDuty and Google both prefer a single owner for the report, and PagerDuty says this person is not the one who caused the incident.

Causes: "5 whys" and its limits

Ask "why" repeatedly until you reach something that can be changed, but do not assume there is only 1 root cause. Atlassian separates the proximate cause (what directly led to the incident) from the root cause (the place where a change would prevent the whole class of incident).

An illustrative example with the made-up incident from the start:

• Why did the order page hang? Because the update locked the orders table.
• Why did the update run at peak hours? Because there was no rule about deployment times.
• Why did it take almost 2 hours to restore? Because the alert only checked the home page, and a customer's call was the first sign.
• Why only the home page? Because nobody had listed the important pages.

The chain stops at 4 questions because it reached something fixable. The proximate cause is the update. What needs to change is the deployment-time rule and the list of pages to monitor.

The sources stress different things. Atlassian defends 5 whys, says the number 5 is just a name, and allows the chain to become a tree of factors. PagerDuty does not discuss 5 whys directly, but advises looking for contributing factors rather than 1 root cause, and cites Richard Cook, who argues that assigning 1 root cause is wrong in principle.

Cook's paper is about complex systems in general and mentions patient safety. Applying it to software is PagerDuty's interpretation.

A 1-page template for a small team

A 1-page report is enough if it has 6 parts. This is a Click Star reference framework, condensed from templates by Google, Atlassian and PagerDuty, and it is not their official template.

• Summary and impact: what failed, how long, how many customers or orders were affected, how many customers reported it (PagerDuty).
• Timeline: exact times with a time zone such as "14:12 Vietnam time", not "around 14:00" (Atlassian), with evidence for each point such as a graph or log (PagerDuty).
• Detection and response: who or what detected it, after how long, and what was done to restore service.
• Causes and contributing factors: the chain of "whys", separating the proximate cause from the deeper one.
• What worked, what did not, and where luck helped: these 3 questions appear in both Google and Atlassian.
• Follow-up work: each item has 1 owner, 1 due date and a link to the real task.

Writing follow-up work so it gets done

Click Star's framework: each item needs 3 things, a specific action, 1 owner and 1 due date. The sources name an owner and a priority, while the due date comes from the team's general policy. According to the SRE Workbook, to users a postmortem without follow-up action is the same as no postmortem (a remark by Google's Ben Treynor Sloss).

An article by John Lunney, Sue Lueder and Betsy Beyer in ;login: (USENIX, Spring 2017) proposes 3 criteria. Click Star opened the original PDF and checked them; PagerDuty and Atlassian also restate them.

• Actionable: a sentence that starts with a verb and produces a useful result.
• Specific: a narrow scope, clear about what is and is not included.
• Bounded: says when the item counts as finished.

Example from the original article and PagerDuty's documentation: "Investigate monitoring for this scenario" should become "Add alerting for all cases where this service returns more than 1% errors".

On deadlines, Atlassian sets 4 or 8 weeks for priority actions, depending on the service. PagerDuty gives its own policy as an example: high-priority items to stop a level 1 incident recurring within 15 days, items from a level 2 incident within 30 days.

PagerDuty also advises opening items in the task tool of the team that will do them, labeling them with severity and date, and opening only the items that truly must be done.

Sharing the report with the team and customers

Google advises sharing with the widest audience that can learn from it and reviewing every report, since an unreviewed postmortem might as well not exist. The SRE Workbook suggests considering customers too, to rebuild trust, while Atlassian notes that publishing publicly is not suitable in every case.

PagerDuty describes the customer version as a condensed, sanitized copy with 3 parts: a summary of 2 to 3 sentences, what happened, and what is being done. PagerDuty also advises avoiding the word "outage" unless the service was fully down.

How a small team in Vietnam can start

Click Star found no measurement for Vietnam on how often incidents occur or what disruption costs. The sources come from large companies with dedicated on-call staff, so do not copy them as they are.

Click Star's view. The greatest value lies in closing the work that follows the report, not in a polished document. For a small team, 1 page written within days of an incident is more useful than a long document written after 1 month, because details are still remembered.

With 5 whys, ask past the symptoms, aim the questions at the system rather than at people, and stop once you have factors that can be fixed. This is a judgment, not a measured result.

On interests: Click Star provides SEO-ready, fast website design and custom software, so it cares about stable operations.

A 4-week plan

Click Star reference framework, not taken from outside sources:

• Week 1: write the reporting threshold into internal rules, agree how to pick 1 owner, create a 1-page template.
• Week 2: try the template on the most recent incident, build the timeline from logs, hold a 30-minute blameless meeting.
• Week 3: write follow-up items using the 3 criteria, put them on the task board with severity and date labels, set due dates.
• Week 4: review overdue items, decide which not to do and record why, send a summary to the whole team.

How to tell whether the process works

Measure closure and recurrence, not the number of reports written. Click Star reference framework, since the sources give no standard level:

• The share of follow-up items closed on time.
• The number of incidents that repeat the same contributing factor.
• Time to detect and time to resolve, figures that Google uses to watch trends.

What is not known

• There is no measurement for Vietnam on how often website incidents occur, what disruption costs, or how widely postmortems are used.
• Google writes that this culture helps it see fewer incidents, but the book chapter gives no figures, and Click Star has seen no independent study measuring the reduction.
• John Allspaw's article on blameless reports (published on Etsy) is cited by Atlassian as a foundation. Click Star's tools could not open the Etsy page, so this article does not use its content.
• The pages read give no standard deadline for small teams, and no direct comparison of 5 whys with other methods.

Common mistakes

1. Skipping the report because "the cause is already known", even though others on the team do not know it.
2. Writing too late, when details are forgotten.
3. Writing "employee error" as the cause, instead of asking why the system allowed it.
4. Writing vague items such as "improve monitoring", with no owner and no due date.
5. Using the word "outage" in a customer letter when the service was only locally degraded.
6. Finishing the report and having nobody read or review it.