The archive · Work & Ways of Doing · Operational decision · 2019–2025
Atlassian's blameless postmortem turns a $100K outage into an automated fix
When a config typo took Atlassian down for 45 minutes, the company ran a blameless postmortem — no firing, no shame, and an automated check so it can't recur.
Atlassian
What it had to solve
Atlassian requires a written postmortem for every severity-1 and severity-2 incident. Its standing rule is 'always blameless': people are assumed to have done their best with the information they had, so the review chases process and system fixes instead of a scapegoat.
How it works
Blameless postmortems are Atlassian's answer to the question of how a team learns from failure without wrecking itself. The company requires a postmortem for every severity-1 or severity-2 incident, and opens the meeting by reminding everyone that postmortems are blameless: every person is assumed to have acted with good intentions based on what they knew at the time.
The rule has a concrete proof. An engineer once made a syntax mistake in a config file for critical equipment, and the entire company went down for 45 minutes — 'hundreds of thousands of dollars' by Atlassian's own estimate. Instead of punishing the engineer, the team treated the human error as a system design problem, traced it with Five Whys, and landed on a fix that no discipline could produce: an automated 'will it start' check on the config before loading, and eventually the removal of human interaction with the configuration altogether.
The practice is institutionalized, not anecdotal. Atlassian's public Incident Management Handbook spells out the meeting agenda, the Jira workflow for tracking corrective actions, approved priority actions with 4- or 8-week service-level objectives, and public postmortem blogs to spread lessons. Its stated goal is cultural: remove the fear of being shamed or fired so incidents get reported and root causes get found.
Why it lands
- Blame-free reviews surface information that fear would bury — the only raw material that prevents future incidents.
- A permanent system fix beats punishment: the config typo now can't happen instead of 'must not happen again'.
- Requiring postmortems for severity 1-2 incidents makes learning routine rather than heroic.
- Tracking every corrective action in Jira with SLOs turns lessons into committed work, not meeting notes.
What it did
The engineer stayed and still contributes at Atlassian, and the outage — quantified at 'hundreds of thousands of dollars' — is now prevented by a quick technical check. Atlassian published the whole practice in its Incident Management Handbook, complete with templates, approvers and SLO-tracked priority actions, and credits Google and Etsy as its inspiration.
What you can take
If an incident review can end someone's career, people will hide information; if it reliably ends in a system fix, they'll bring you the truth you need to prevent the next one.
Since then
Atlassian keeps publishing and updating its incident management guidance, including templates and a free handbook, and the blameless model has become a standard practice across the software industry — with Atlassian's pages among the most-cited how-to guides. Inside the company, postmortems remain mandatory for top-severity incidents, and engineering managers review reports on unresolved root causes so that an incident is only closed when its class of failure is actually fixed.
Sources
spotted an error? The archive wants to know.
Your turn
You just read one. Describe the brief you are staring at, and see who has been given the same problem.
Free account · 3 free questions · no card