Atlassian 2022: The Maintenance Script That Deleted Hundreds of Cloud Sites
Atlassian's 2022 cleanup script deleted hundreds of customer cloud sites after site IDs were mistaken for app IDs, exposing the difficulty of large-scale tenant restoration.
A cleanup script received site identifiers instead of app identifiers
On April 5, 2022, Atlassian intended to remove a legacy application from customer sites after integrating its functionality into Jira Service Management. The deletion process accepted both application identifiers and entire site identifiers. A communication gap caused the script to receive site IDs, and the API provided no warning that the scope had changed from deleting an app to deleting a whole cloud site.[1] The result was deletion of 883 sites representing 775 customers. This was not a cyberattack; it was an authorized maintenance workflow operating on the wrong object class.
The interface made two radically different operations look alike
When an API can delete either a component or an entire tenant using identifiers of the same shape, input validation becomes a safety control. Destructive scope should be explicit, typed and difficult to confuse.
The outage lasted days because restoration at that scale had never been automated
Atlassian could recover individual sites, but it had not built a fast process for restoring hundreds of multi-product sites into an otherwise live shared cloud. The company’s post-incident review says some customers remained affected for up to fourteen days.[2] The backups existed and data loss was limited, yet recovery time became the dominant failure. Each site connected Jira, Confluence, identities, media, third-party apps and other services that had to be reconstructed consistently. The incident therefore separated backup durability from disaster-recovery throughput in a way customers could feel directly.
Recovery time is a product characteristic
A backup that needs two weeks to restore at incident scale may protect data while still failing the service’s availability promise. Recovery capacity has to match plausible blast radius.
A first successful production run created misleading confidence
Atlassian reported that an initial run against thirty sites succeeded because those records contained the correct app identifiers. A later batch contained whole-site IDs and deleted the sites sequentially.[3] This pattern is dangerous in automation: an early canary can validate the script while failing to validate the data that drives the script. Safe staged rollout must therefore test both code and input semantics. A canary batch should be sampled from the same generation process as the later batch, and the system should independently verify that each target belongs to the expected resource type.
Canaries must test the thing that can actually vary
If the executable is constant but the identifier list changes, then the list is part of the release. Review and validation need to cover the data, not just the script.
The deletion also removed information needed to contact affected customers
The same site deletion removed customer identifiers and administrator contact data used by support and routing systems. Atlassian later acknowledged that this blocked some customers from filing normal support tickets and made proactive communication harder.[4] This is a subtle resilience lesson: disaster recovery must protect the control information needed to manage the disaster. Contact directories, tenant identifiers, runbooks and recovery credentials should not depend entirely on the production objects they are meant to recover.
Recovery metadata needs an independent home
A provider should be able to identify affected tenants and reach approved contacts even if the tenant’s primary record has vanished. Support infrastructure is part of the disaster-recovery system.
The postmortem converted the failure into concrete platform changes
Atlassian committed to universal soft deletes, stronger safeguards around destructive actions, improved large-scale restoration automation and a new communications playbook.[5] Soft deletion changes the economics of mistakes: an erroneous delete becomes a reversible state transition rather than immediate physical destruction. That pattern is widely applicable. Destructive operations can enter a quarantine period, require secondary approval and trigger monitoring before irreversible cleanup occurs. The important point is to move safety from operator memory into the platform.
Shared cloud architecture made selective restoration technically difficult
Atlassian could not simply roll the entire platform back to an earlier snapshot because unaffected customers continued using the service. Recovery required extracting and restoring only the deleted tenants from multi-tenant data stores while preserving newer writes for everybody else. This is one of the hardest forms of cloud recovery. A provider needs point-in-time data plus tenant-aware reconstruction tools. Backups designed only for whole-database disaster recovery are insufficient when the likely failure is a selective logical deletion inside a healthy shared system.
The outage shows why destructive APIs need asymmetry
Create and delete should not be equally easy. Creation errors consume resources; deletion errors destroy evidence and customer state. APIs can encode this asymmetry with separate endpoints, stronger authorization, typed identifiers, dry-run modes, quotas, delayed execution and independent approval for bulk actions. Atlassian’s incident occurred because a normal maintenance process had enough authority to erase whole sites quickly. Reliability improves when the fastest path through the system is not also the most destructive one.
Why the Atlassian 2022 outage belongs in software-failure history
Atlassian’s April 2022 outage belongs in software history because it combined three modern cloud risks in one event: ambiguous destructive automation, multi-tenant recovery complexity and dependence on production metadata for customer communication. Backups prevented catastrophic data loss, yet hundreds of customers still waited days for their sites to be reconstructed. The incident demonstrates that disaster recovery is not finished when data is safely stored. Providers must be able to restore the right tenant, into a live shared environment, at the scale of the largest plausible logical deletion—and they must preserve enough independent metadata to coordinate that recovery while it happens.
Works Cited
- 01
- 02Atlassian — April 2022 Outage Update atlassian.com
- 03Atlassian — August Update on PIR Progress atlassian.com
- 04Atlassian — November Update on PIR Progress atlassian.com
- 05Atlassian Community — April 2022 Outage PIR Announcement community.atlassian.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.