Answer: Atlassian publishes a Recovery Time Objective (RTO) of 6 hours and a Recovery Point Objective (RPO) of 1 hour for all Cloud products. These are objectives, not contractual guarantees. Atlassian’s only contractual commitment is the uptime SLA (99.90% Premium, 99.95% Enterprise). In the April 2022 outage, a subset of customers waited up to 14 days for full restoration, illustrating the gap between published RTO and worst-case reality.
If you operate Jira Cloud as core infrastructure, two numbers determine how badly an outage can hurt: the maximum acceptable downtime before business impact (RTO) and the maximum acceptable data loss measured in time (RPO). For Atlassian Cloud, both are published but they are framed as objectives, not financial guarantees, and the difference matters when you are planning continuity for a mission-critical engineering tool.
What Atlassian commits to (and what it doesn’t)
Atlassian publishes two distinct sets of numbers. The first is the uptime SLA: 99.90% for Cloud Premium and 99.95% for Cloud Enterprise. Free and Standard plans have no uptime SLA at all. Breaching the SLA triggers service credits (not refunds, not compensation for business impact) capped at 100% of the affected product’s invoice for that billing period.
The second set is the recovery objectives. Atlassian’s data management documentation states an RTO of 6 hours and RPO of 1 hour for all Cloud products. These objectives apply to scenarios that fall outside Atlassian’s normal high-availability architecture, primarily data corruption, deletion within Atlassian’s infrastructure, or events that require traditional backup-and-restore recovery.
Why the published RTO is not your worst case
On April 5, 2022, an internal Atlassian script intended to deactivate a deprecated app instead deleted 883 sites belonging to 775 customers. The first customers were restored three days later, on April 8, and the final restorations did not complete until April 18. For the most affected customers, that is a 14-day outage against a published 6-hour RTO.
Atlassian’s post-incident review is candid: while 99.6% of customers were unaffected and no customer lost more than five minutes of data, the company’s restoration tooling had not been designed for simultaneous multi-customer, multi-product recovery at scale. Recovery time, in practice, depended heavily on the failure mode.
What this means for your continuity plan
Three implications for engineering and platform leaders:
- Published RTOs are best-case assumptions. They describe the system Atlassian designed for, not every scenario you might encounter. Plan capacity around the worst-case scenarios in Atlassian’s own post-mortems.
- Atlassian’s commitments end at infrastructure availability. Atlassian operates using a shared responsibility model, meaning that they are responsible for the resilience of the platform and you are responsible for the disaster recovery and business continuity of your business operating on the platform. This is explicit in their documentation.
- Compensation does not equal business continuity. Service credits cover billing impact, not lost engineering velocity, missed release windows, or breached customer SLAs that depend on your Jira-based processes.
How to bridge the gap
If your business cannot tolerate a 14-day worst case, you need a recovery posture that exceeds what native Atlassian provides. The standard playbook borrows from the AWS Well-Architected disaster recovery framework: tiered postures like backup-and-restore, Pilot Light, Warm Standby, and multi-site active/active, chosen based on the cost of downtime versus the cost of the standby. For engineering tools where outage cost is high, a Pilot Light or Warm Standby model for Jira is increasingly considered table stakes.
The right question is no longer “what is Atlassian’s RTO?” It is “what is your business’s RTO, and what posture do you need on top of Atlassian to hit it?”
Sources
- Atlassian — Approach to resilience (RTO/RPO commitments) — https://www.atlassian.com/trust/security/data-management
- Atlassian — Service Level Agreement — https://www.atlassian.com/legal/sla
- Atlassian — Post-Incident Review on the April 2022 outage — https://www.atlassian.com/blog/atlassian-engineering/post-incident-review-april-2022-outage
- AWS Well-Architected — Disaster Recovery Strategies — https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html
Rewind">
