Listen to this article
In April 2022, an internal Atlassian maintenance script permanently deleted 883 sites belonging to 775 customers. Not corrupted. Not disabled. Deleted, along with the customer contact data Atlassian needed to tell those customers what had happened. The company's own post-incident review, published three weeks later, remains one of the most transparent outage writeups any vendor has produced - and one of the most instructive. The deletion took 23 minutes. Getting everyone back took up to 14 days.
The deletion bar is drawn at the minimum visible height. At true scale it would not render at all - which is the point.
Two small failures, one permanent outcome
Atlassian's PIR names two compounding root causes, and neither is exotic. First, a communication gap: the team requesting the maintenance run handed over the IDs of entire cloud sites when they meant to hand over the IDs of a single app on those sites. Second, a script problem: the deletion script supported both a "mark for deletion" mode, which is recoverable, and a "permanently delete" mode, which is not - and it offered no warning signal to confirm which type of deletion was about to run. Wrong inputs, met a dangerous default, met an execution path with no independent check. The script did exactly what it was told.
The deletion took 23 minutes. The first public status update took an hour and a half. Full recovery took two weeks.
The communication gap extended into the response. The first Statuspage update went out 1.5 hours after the deletion, but the first broad acknowledgment on social channels took over 17 hours - in part because the contact data for the affected customers had been deleted along with their sites. The blast radius of an unvalidated change included the ability to talk about the unvalidated change.
What recovery actually cost
The restoration effort is where the asymmetry becomes vivid. Atlassian mobilized hundreds of engineers, including more than 450 support engineers running validation checks around the clock. The first restoration method took roughly 48 hours per batch of sites and recovered 112 sites. Mid-incident, the team rebuilt the process into a second method that cut restoration to roughly 12 hours per site and handled the remaining 771. Maximum data loss for restored customers was five minutes - a genuinely good backup story. But backups restore data; they do not restore the two weeks.
Both figures are Atlassian's own. Method 1 restored sites in batches; the rebuilt method restored individual sites in parallel.
Three years later: build-your-own agents, for everyone
Fast forward to April 9, 2025. At Team '25, Atlassian announced that Rovo, its AI teammate, is now included for all Jira, Confluence, and Jira Service Management Premium and Enterprise customers at no extra cost. By Atlassian's own numbers, nearly 2,000 Rovo Agents were already integrated into customer workflows at announcement, Atlassian AI has over 1 million monthly active users, Rovo connects to 50-plus Atlassian and third-party tools, and Rovo Studio lets anyone build agents with or without code.
Hold those two stories side by side. In 2022, one human-written script with unvalidated inputs and a dangerous default deleted 775 customers in 23 minutes. In 2025, the same workflows host thousands of agents that anyone can build, connected to everything. The 2022 script was reviewed by professional engineers and still carried a "permanently delete" mode with no confirmation. What defaults are sitting inside agents built last Tuesday by someone with no code review at all?
The AuthorityGate take
This is not an anti-Atlassian argument. Their PIR is admirably candid, their backup discipline held data loss to five minutes, and Rovo is a legitimately impressive platform. The argument is about arithmetic: change velocity is multiplying and validation is not. When the number of things that can execute a destructive change goes from "our scripts" to "thousands of agents anyone can build," the safeguards cannot stay where they were in 2022.
The 2022 failure chain - wrong inputs, dangerous default, no independent confirmation - is exactly what change validation exists to break. Every change, whether it comes from a human, a pipeline, or an agent, should pass gates that verify the inputs, score the blast radius, and route anything irreversible to a named human before it executes. That is the augmented model: the script or the agent proposes, the gates verify, a person owns the "permanently delete" decision. Atlassian needed 23 minutes of missing validation to lose two weeks. An agent fleet does not get slower.
Atlassian's postmortem ends, as good postmortems do, with process fixes. But the deepest lesson in it is not about one script. It is that the gap between "execute" and "verify before execute" is measured in minutes on the way down and weeks on the way back - and that gap is about to be walked by a lot more than scripts.
Sources
Go deeper
Every agent action, validated before it takes effect
AuthorityGate's newsletter breaks down real AI incidents and the governance failures behind them. Our configurable 8-gate validation model is how organizations keep a named human accountable for what their AI actually does.