Jira Service Management Status

Jira and JSM customers using Microsoft OAuth for automatic creation of Jira tickets from email were unable to read email. This is now fixed and functional for all new incoming email processing. The impacted customers during the incident period need to re-authorise the Microsoft mail server to restore and below are the instructions. To re-authorise an incoming Microsoft mail server: Login in Jira as Admin Select  > System Select Mail > Incoming Mail. Select Edit incoming mail server. Select re-authorise . Enter your Microsoft credentials to continue using your Microsoft mail server.

On June 10 2026, between 08:10 and 09:08 UTC, users experienced degraded performance and inability to load the Assets page, which is impacting the ability to create, update, and delete assets. We have implemented a fix and services have been restored to normal operation for all affected customers.

We are now confident that any of the tasks that were impacted by this incident and were delayed should now be operating as expected. We apologize for any inconvenience that this issue may have caused.

The issue has now been resolved, and the service is operating normally for all affected customers.

On June 08 2026, between 01:30 and 02:40 UTC, users experienced degraded performance with Jira Software front-end experiences affecting view board, navigation, and backlog across multiple regions. We have implemented a fix and services have been restored to normal operation. We continue to monitor the situation closely.

On June 2, 2026, some Jira and Jira Service Management users in the US-East region may have experienced performance degradation of automation rule executions. The issue has now been resolved, and the service is operating normally for all affected customers. Previously delayed automation rules are expected to be completed within 12 hours.

**SUMMARY** On June 01, 2026, between 06:54 and 08:28 UTC, Atlassian customers using Jira, Jira Service Management, and Jira Work Management were unable to view issues, boards, and backlogs, and experienced errors when performing transitions, adding comments, and navigating the product. The event was triggered by caching infrastructure autoscaling failure. The issue only impacted customers hosted in Europe. The incident was detected within 8 minutes by our automated monitoring system and mitigated by progressively scaling the caching clusters manually. The total time to resolution was 1 hour and 34 minutes due to the progressive recovery. **IMPACT** The incident caused service disruption for customers hosted in the Europe region who were unable to access core experiences across Jira Software, Jira Service Management, and Jira Work Management. **ROOT CAUSE** The root cause of the incident was a capacity constraint on our caching infrastructure in one availability zone of our EU Central cloud region. As morning traffic increased, our caching clusters attempted to scale out automatically. However, the cloud infrastructure was unable to provision additional nodes in that availability zone due to insufficient underlying capacity. Our caching infrastructure is designed to scale across multiple availability zones to ensure balanced and resilient capacity. On this occasion, a capacity constraint in one availability zone prevented the scaling operation from completing as expected. With the caching layer unable to grow to meet demand, the clusters began to experience network and/or CPU saturation and could not handle all incoming requests within the expected timeout window. Since a single user request to Jira typically involves multiple cache calls, timeouts compound rapidly. As more threads became blocked waiting on timed-out or slow cache operations, the application nodes reached its busy thread limit and began shedding load. While additional application nodes were added, these also experienced the same thread limit saturation due to the saturation of the cache layer resulting in widespread 503 service unavailable errors for customers. **REMEDIAL ACTIONS PLAN & NEXT STEPS** We know that outages impact your productivity. In addition to existing safeguards and monitoring, Atlassian is prioritizing the following actions to help prevent similar incidents in future: - **Increased minimum caching cluster size**: We have increased the minimum number of nodes in all affected caching clusters in the EU Central region. This ensures sufficient capacity headroom to handle peak traffic without relying on autoscaling, reducing the risk of a similar failure occurring. - **Change autoscaling behaviour**: We are working on improvements to our autoscaling behaviour to fall back to other availability zones when capacity is unavailable in a single zone. We apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform’s performance and availability. Thanks, Atlassian Customer Support

### Summary On May 14, 2026, between 04:30 and 05:26 UTC, Atlassian customers experienced widespread service disruption across multiple Atlassian Cloud products. The issue was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products. The incident was detected within a minute by automated monitoring systems and mitigated in 56 minutes. ### **IMPACT** During the incident, customers attempting to access Atlassian Cloud products in the us-east region experienced authentication and permission failures and were unable to access services. Customers also experienced errors when accessing the support portal until Atlassian fell back to an alternate support method. This was caused by a core identity service in the us-east region becoming unavailable. Affected products included Atlassian Administration, Atlassian Analytics, Bitbucket, Compass, Confluence, Jira, Jira Product Discovery, Jira Service Management and Trello. Some users outside us-east may have been affected in certain scenarios. ### **ROOT CAUSE** The incident was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products. ### **REMEDIAL ACTIONS PLAN & NEXT STEPS** We know that outages impact your productivity. Atlassian is prioritizing the following actions to help prevent similar incidents in future: * **Refine deployment orchestration safeguards** * Harden our deployment platform to prevent similar race conditions or resulting capacity loss during a rollback operation. * Streamline mitigation steps when a service becomes unavailable in a region. * **Reduce cross-region impact** * Improve regional isolation and fallback handling so an issue affecting a single region is less likely to impact customers or product functionality in other regions. We recognise how critical reliable access to Atlassian products is for our customers' productivity, and we apologize to customers who were impacted by this incident. Thanks, Atlassian

This incident has been resolved. During the incident window, some customers using Atlassian Assist experienced excessive notifications as our team replayed delayed events caused by this prior incident: https://jira-service-management.status.atlassian.com/incidents/v307yb60q5g7 Our engineering team identified and addressed the issue. All services have fully recovered, and notification delivery is operating normally. No data loss occurred as a result of this incident. We apologize for the disruption and any confusion caused by the excessive notifications.

### Summary ### On May 12, 2026 between 19:01 and 20:46 UTC, a subset of Atlassian customers may have experienced delays in background operations and automation processes. Some background operations, such as notifications or search indexing, were delayed until May 14, 2026 19:25 UTC due to increased cross-region traffic. The issue stemmed from a latent bug in the event processing pipeline. Automated monitoring detected the incident within 16 minutes, and it was mitigated through manual rollback within 1 hour and 45 minutes. Recovery of cross-region event delivery from the affected timeframe took 48 hours due to infrastructure scale constraints. ### IMPACT ### During the incident, customers may have experienced delays in background operations like automation, search indexing, notifications, and permission synchronization. The event processing pipeline distributes events between Atlassian services to support these background operations. - On May 12, 2026, at 19:01 UTC, the deployment of a routing configuration increased event volume across cross-region services. At 20:46 UTC, rolling back routing configurations resolved the issue. - Processing the accumulated cross-region message backlog finished by May 14, 2026, at 19:25 UTC. **Automation & Jira Service Management** Some Atlassian customers experienced event-triggered rules delayed or executed multiple times during the recovery window. **Confluence** Some Atlassian customers experienced delays in search indexing and possible duplicate notifications and automation rule executions during the recovery window. ### ROOT CAUSE ### The issue arose from the deployment of a routing configuration change to the event processing platform, exposing a latent bug in legacy configurations. This change distributed higher volume of events to cross-region services. Cross-region services validated and discarded extra events but needed greater scale to handle the increased influx. The mitigation involved rolling back the configuration change in the event platform. Recovery involved scaling cross-region services to handle higher inbound traffic. ### REMEDIAL ACTIONS PLAN & NEXT STEPS ### We know that performance degradations impact your productivity. While we have a number of testing and preventative processes in place, this specific issue wasn’t identified because the change was related to a very specific kind of legacy case that was not picked up by our automated continuous deployment suites and manual test scripts. We are prioritizing the following improvements to help prevent similar incidents in future: - Enhance runtime metrics across critical-path configurations to predict change impact before deployment. - Enhance failover capabilities to create and replace infrastructure components to respond faster to increased processing demands. We apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform’s performance and availability. Thanks, Atlassian Customer Support

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance was completed in 47 minutes and backed up events were processed by 03:00 UTC.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.