Jira Software Outage History

### Summary On April 13, 2026, between 05:49 and 06:29 UTC, customers experienced failures when attempting to log in, sign up, reset passwords, and complete multi-factor authentication flows across Atlassian cloud products. Approximately 90% of authentication requests failed during the peak impact window, affecting users in the US East and EU regions. The incident was mitigated within 40 minutes through manual intervention, and full service was restored by 06:29 UTC. ### **IMPACT** * **Duration**: ~40 minutes \(05:49–06:29 UTC, April 13, 2026\) * **Affected regions**: US East and EU \(authentication infrastructure serves EU traffic from US East, with traffic primarily from EU at this time of day\). * **Affected products**: All Atlassian cloud products requiring authentication, including Jira, Confluence, Jira Service Management, and Trello. * **Customer experience**: Users attempting to log in, sign up, reset passwords, or complete MFA flows received errors. Users already logged in with active sessions were unaffected. ### **ROOT CAUSE** This incident had several contributing factors that combined to produce a failure that the system could not recover from without manual intervention. **The primary cause** was a recently enabled change that caused our authentication infrastructure to retry requests to a downstream identity service when those requests were slow to respond. This retry behaviour was rolled out to 100% of traffic earlier the same day. Under normal conditions this would be benign, but it meant that any slowness in the downstream service was amplified. Since multiple upstream services were also independently retrying their own failed requests, the amplification compounded further into a retry storm. **The trigger** was a burst of legitimate user traffic. A pattern of many parallel link preview requests for a single user caused a concentrated load spike on a downstream identity service, pushing its response times above the retry threshold. On its own, this kind of spike had occurred many times before and always recovered. With the retry amplification now in effect, the spike instead created a runaway feedback loop: slow responses caused retries, retries increased load, increased load caused slower responses, preventing recovery. The incident was mitigated by manually scaling up the downstream identity service to provide sufficient capacity to absorb the amplified load. Once scaled, the service recovered immediately, bringing authentication error rates to zero within one minute. **REMEDIAL ACTIONS PLAN & NEXT STEPS** We are taking the following actions designed to prevent recurrence and improve our resilience: 1. **Immediate**: The retry-on-timeout change has been disabled. 2. **Load shedding and self-healing**: We are adding load shedding capabilities to our authentication services so that they can automatically shed excess load and self-recover during traffic spikes, without requiring action before automatic scaling starts. 3. **Reducing request fan-out**: We are reviewing patterns where a single user action can generate many parallel downstream requests, and will introduce methods where possible to reduce the amplification potential. We apologize to customers whose services were interrupted by this incident and we are taking immediate steps to improve the platform’s reliability. Thanks, Atlassian Customer Support

### Summary On April 8, 2026, between 04:46 UTC and 12:09 UTC, search functionality was unavailable or degraded across several Atlassian Cloud products, including Jira, Confluence, Jira Service Management, Rovo, Rovo Dev, Loom, Guard Standard, Customer Service Management and Atlassian Administration. A configuration change increased the resources reserved for a core system component that runs on nodes in our compute platform. On a subset of clusters configured for high‑density workloads, the increased reservations exceeded available node capacity interrupting search and related experiences for affected customers. The root cause was identified and a rollback was merged at 05:42 UTC with some systems seeing recovery by 07:33 UTC**.** Core search functionality was restored approximately by 08:55 UTC, and full downstream recovery completed by 12:09 UTC. ### **IMPACT** During the impact period, some customers experienced outages or degradation in search across Jira, Confluence, Jira Service Management, Rovo, Rovo Dev, Loom, Guard Standard, Customer Service Management and Atlassian Administration. Other experiences that rely on search such as quick find, navigation, AI assistants, dashboards, were also intermittently affected during this period. Impacted customers may have been unable to find pages or recordings and experienced degraded performance in finding issues; received empty or delayed search results; or experienced AI assistants and dashboards that could not retrieve relevant context. **Jira, Jira Service Management and Customer Service Management:** Search and experiences that depend on search like finding issues and agent responses in CSM remained available but with degraded performance in fallback mode. By 12:09 UTC, search indexes and search performance was fully restored from fallback to full capacity across all regions. **Guard Standard and Atlassian Administration:** Search functionality was unavailable for parts of the incident window. As a result, Domain Claims, usage tracking, and managed accounts were degraded for portions of the window. These services were restored to operational status by 07:33 UTC. Guard Premium was not impacted by this issue. **Confluence:** Search functionality was unavailable for parts of the incident window. Recovery began at 07:30 UTC as backend search clusters were restored. Full recovery, including search index replay, completed at 11:37 UTC. **Loom:** Search functionality and some experiences that rely on Confluence Search, such as sharing to spaces\) was unavailable for portions of the window and fully restored at 11:37 UTC. **Rovo and Rovo Dev:** Rovo agents remained responsive but experienced degraded functionality due to loss of search capabilities in underlying services. They were unable to reliably return context about work items or pages. Functionality was fully restored at 11:37 UTC. ### **ROOT CAUSE** Atlassian products rely on OpenSearch clusters to power their search capabilities including issue search, content search, and AI-powered search features. An infrastructure configuration change increased resource reservations \(CPU & Memory\) for a system component that runs across our compute platform. On a subset of clusters configured for high-density workloads, the increased reservations exceeded available node capacity. This caused search workloads to be evicted and, in some clusters, could not reschedule onto any available nodes impacting search functionality across affected products. The change was deployed across multiple production clusters in a short time frame, limiting the opportunity to detect the capacity conflict in a smaller subset of clusters before it reached the wider fleet. Automated scaling systems attempted to recover by provisioning additional capacity but in the worst‑affected clusters this led to runaway node scaling and exhaustion of available network resources, prolonging recovery time. ### **REMEDIAL ACTIONS PLAN & NEXT STEPS** We understand that service disruptions impact your productivity. In addition to our existing testing and preventative processes, Atlassian is prioritizing the following actions to help reduce the likelihood and impact of similar incidents in the future and to speed up recovery when issues occur: * **Enforce smaller deployment cohorts and larger soak for critical platform changes for these cluster types** Implement smaller deployment cohorts, mandatory soak periods between environments, and automated health gates so that changes are validated on a limited set of clusters before being promoted more broadly. * **Strengthen automated pre‑deploy validation for resource changes** Add validation checks to ensure resource changes for system components are compatible with node capacity and reserved headroom, preventing system workloads from crowding out customer workloads. * **Improve post‑deploy verification and alerting** Enhance monitoring and post‑deployment verification to detect patterns such as spikes in pending pods, runaway node scaling, and low pod‑IP headroom closely correlated with new configuration being rolled out. * **Align autoscaling behavior with capacity and safety limits** Align autoscaling capacity calculations with node reservations and introduce safeguards and circuit breakers to prevent runaway scaling and to enforce safe limits on node and pod IP counts. * **Enhance recovery automation** Improve automation and runbooks so we can safely disable autoscaling, remove empty nodes in bulk, and restore normal operations faster across multiple clusters in parallel. We apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform’s performance and availability and to reduce the risk and impact of similar issues in future. Thanks, Atlassian Customer Support

### Summary On March 18, 2026, between 10:06 and 13:47 UTC, customers experienced delays in Automation rules executing when triggered by Jira events such as Work Item creation, Work Item updates, and comments. Automation rules using other trigger types, including scheduled triggers, manual triggers, and incoming webhooks, continued to operate normally. The incident was caused by an internal configuration change that inadvertently disabled the event delivery pathway used to notify the automation platform of changes in Jira. The incident was identified through customer support tickets and verified through our monitoring; engineering teams were engaged for resolution. Once the root cause was identified, the configuration was corrected and normal automation processing resumed. Following restoration, the delayed events began flowing to the automation platform for processing. This backlog took approximately 14 hours to fully clear. During this recovery window, some automation rules ran on Work Items whose data had changed due to user actions, customer mitigation, or other causes. Since rule execution usually follows triggering events closely, many customer rules assume immediate execution on the Work Item. The delay allowed other changes —such as updates or customer actions to mitigate the incident's impact — to occur, causing unintended consequences when the rule executed later. ### **IMPACT** During the impact window, Jira Cloud customers were unable to rely on timely execution of event‑triggered automation rules. Rules that depended on Jira Work Item events - including Work Item created, Work Item updated, comment added, sprint changes, and version changes - ran with significant delays. This affected automated workflows responsible for Work Item routing, notifications, field updates, and other rule‑driven actions throughout the outage. Automation rules that used scheduled, manual, or incoming webhook triggers remained unaffected. Following mitigation, a recovery period of approximately 14 hours was required to process the backlog of delayed events. During this window, processing delays peaked at approximately 12 hours from event occurrence to rule completion. In some cases, rules executing against Work Item data several hours after the rule trigger occurred, caused problems due to the rules being built with the expectation in mind that little time would pass between trigger and execution. This resulted in Work Items ending up in an unintended state; especially as some customers undertook manual intervention given the situation. ### **ROOT CAUSE** The incident was caused by a configuration change to an internal feature flag used to control event delivery to the automation platform. A code change had been prepared to remove a feature flag from the event delivery system. However, this code change had not yet been deployed to production. When the feature flag was subsequently retired through our feature flag management system, the retirement process relied on usage telemetry that incorrectly indicated the flag was no longer active. This inadvertently created a blind spot where the flag appeared unused when it was in fact being actively evaluated. When the flag was retired, the event delivery system interpreted its absence as an instruction to stop delivering Jira events to the automation platform, causing all event-triggered automation rules to stop firing. ### **REMEDIAL ACTIONS PLAN & NEXT STEPS** We understand that outages impact your productivity. In addition to our existing testing and preventative processes, Atlassian is prioritising the following actions to help reduce the likelihood and impact of similar incidents in the future: * **Strengthen feature flag lifecycle safety controls** * Address the telemetry gap by removing feature flagged code from the hot path of our event processing framework where it was being surpressed, ensuring we have good telemetry on feature flag use across our systems. This will prevent inadvertent archival of feature flags in future. * Refine feature flag retirement processes so that flags cannot be retired without verifying actual production usage, independent of standard telemetry signals. * **Improve event delivery monitoring and alerting** * Refine monitoring to detect drops in automation event delivery rates within minutes, and add automated alerting on automation execution volume anomalies to enable faster detection of disruptions. * **Improve our ability to clear delayed events faster and deliver controls for customers to decide alternative workflows for events based on delay.** * Refine replay infrastructure to recover faster from the pent up backlog that can be created due to delays. * Provide workflow components that allow users to decide what to do for varying delays between the triggering event and when the rule gets executed to reduce the risk of unintended changes during recovery. We recognise the importance of Jira Automation to our customers' workflows and are committed to ongoing improvements to the reliability and resilience of our platform. We sincerely apologize for the disruption this incident caused, and we will continue to invest in measures that support a stable and dependable service. Thanks, Atlassian Customer Support