Last checked: 5 minutes ago
Get notified about any outages, downtime or incidents for Jira Service Management and 1800+ other cloud vendors. Monitor 10 companies, for free.
Outage and incident data over the last 30 days for Jira Service Management.
Join OutLogger to be notified when any of your vendors or the components you use experience an outage. It's completely free and takes less than 2 minutes!
Sign Up NowOutlogger tracks the status of these components for Xero:
| Component | Status |
|---|---|
| Assist | Active |
| Authentication and User Management | Active |
| Automation for Jira | Active |
| Jira Service Management Email Requests | Active |
| Jira Service Management Web | Active |
| Opsgenie Alert Flow | Active |
| Opsgenie Alert Flow | Active |
| Opsgenie Incident Flow | Active |
| Opsgenie Incident Flow | Active |
| Purchasing & Licensing | Active |
| Service Portal | Active |
| Signup | Active |
View the latest incidents for Jira Service Management and check for official updates:
Description: ### Summary From `12/Aug/24 10:39 UTC` to `13/Aug/24 14:38 UTC` some customers experienced degraded performance on Issue View in Jira. This was caused by a data processing compatibility problem between a cache, the underlying database, and the new deployment. Due to a slow increase in failure rate and a small initial surface area of impact, the problem didn’t immediately trigger our continuous error monitoring and alerting. Once we identified the issue it was resolving itself through self-healing mechanisms in the infrastructure. However, in a few outlier cases, we had to intervene with tenant specific cache recalculations. All but 6 tenants were fully remediated by `12/Aug/24 21:30 UTC`. The issue occurred on the read layer of our architecture so while customer experience was degraded, there was no data loss. ### **IMPACT** About 1% of instances in were impacted over the lifetime of the incident. Users on those impacted instances would have experienced degradation when loading Issue View in a specific scenario. This was when a Multi Select Custom Field is enabled on an Issue and where that Custom Field also had a Default Value set. ### **ROOT CAUSE** We introduced a change in our code which caused processing of Custom Fields in specific configurations to fail. This prevented Issue View from loading issues for projects with the above specific configuration applied. This problem occurred because of different representations of the data in the database, in the code base, and in the cache in the production environment. These multiple representations caused an exception when translating the data from one representation to the next. ### **REMEDIAL ACTIONS PLAN & NEXT STEPS** The problem largely self healed as the cache expired and was refreshed with compatible data; however, we chose to force cache re-computation for affected tenants in order to expedite this process. We chose not to roll back the deployment at that point as that would have created the reverse compatibility issue with the already healed tenants. Instead, we focussed on forward fixing with a hotfix and accelerating remediation for still affected tenants. For a small very number of tenants, forced re-computation did not immediately rectify and we had to roll forward a code hotfix to remediate. We are prioritizing the following improvement actions to avoid repeating this type of incident: * The already deployed hot fix to stop this particular problem recurring. * A series of tests for this class of issue in our read layer. * A review of monitoring to detect these fine grained problems before they cause more customer impact. We apologize for any disruption this issue may have caused and are taking steps to help ensure it does not occur again. Thanks, Atlassian Customer Support
Status: Postmortem
Impact: Minor | Started At: Aug. 12, 2024, 3:51 p.m.
Description: ### Summary From August 9, 2024, 14:49 UTC until August 10, 2024, 00:55 UTC, Atlassian customers using Jira and Jira Service Management products could not use JSM Assets objects in their workflows. The event was triggered by an out-of-cycle deployment of our services. There were no functional changes included in the service, however, the deployment impacted multiple customers across Europe, North America, and Asia Pacific. The incident was detected within 82 minutes by Staff \(Customer reports\) and mitigated by restarting the JSM Assets service, which put Atlassian systems into a known good state. The total time to resolution was about 4 hours for most customers, with one having a 10h prolongued outage. ### **IMPACT** The overall impact was between August 9, 2024, 14:49 UTC and August 10, 2024, 00:55 UTC on Jira and Jira Service Management products\_. The Incident caused service disruption to\_ Europe, North America, and Asia Pacific customers only where they failed to leverage JSM Assets objects in their workflow. Jira users faced disruption when looking to: * View Assets objects associated with issues after loading their issues, lists of issues, or boards in browser * View Gadget results which relied on AQL in their JQL * Interact with JQL\+AQL via API * Transition issues which required Assets object validation Jira Service Management users faced disruption when looking to: * Create issues in JSM Customer Portal * View Assets objects on Requests in JSM Customer Portal * Fill JSM Form relying on Assets * Configure Asset fields and JSM Forms with Assets * Refresh queues based on AQL ### **ROOT CAUSE** The issue was caused by a race condition in refreshing authorization tokens. As a result, the products above could not retrieve access tokens and resource identifiers to support customer features, and the users received HTTP 500 errors. More specifically, our out-of-cycle deployment triggered an authorization token refresh for a downstream service serving customer traffic at the time. As our service was processing traffic, it sought to update authorization tokens, and in some cases, the tokens partially persisted within the customer context. Subsequent calls for the affected customer failed due to a mismatch of authorization tokens. ### **REMEDIAL ACTIONS PLAN & NEXT STEPS** We know that outages impact your productivity. While we have several testing and preventative processes in place, this specific issue wasn’t identified because the change was related to a particular kind of legacy case that was not picked up by our automated continuous deployment suites and manual test scripts. We are prioritizing the following improvement actions to avoid repeating this type of incident: * Removing the need to cache authorization tokens during service runtime. Furthermore, we deploy our changes progressively \(by cloud region\) to avoid broad impact. In this case, our detection instrumentation could have worked better. To minimize the impact of breaking changes to our environments, we will implement additional preventative measures such as: * Alerting on high amount of error rates over short spans of time. We apologize to customers whose services were impacted by this incident and are taking immediate steps to improve the platform’s performance and availability. Thanks, Atlassian Customer Support
Status: Postmortem
Impact: Major | Started At: Aug. 9, 2024, 4:35 p.m.
Description: ### Summary From August 9, 2024, 14:49 UTC until August 10, 2024, 00:55 UTC, Atlassian customers using Jira and Jira Service Management products could not use JSM Assets objects in their workflows. The event was triggered by an out-of-cycle deployment of our services. There were no functional changes included in the service, however, the deployment impacted multiple customers across Europe, North America, and Asia Pacific. The incident was detected within 82 minutes by Staff \(Customer reports\) and mitigated by restarting the JSM Assets service, which put Atlassian systems into a known good state. The total time to resolution was about 4 hours for most customers, with one having a 10h prolongued outage. ### **IMPACT** The overall impact was between August 9, 2024, 14:49 UTC and August 10, 2024, 00:55 UTC on Jira and Jira Service Management products_. The Incident caused service disruption to_ Europe, North America, and Asia Pacific customers only where they failed to leverage JSM Assets objects in their workflow. Jira users faced disruption when looking to: * View Assets objects associated with issues after loading their issues, lists of issues, or boards in browser * View Gadget results which relied on AQL in their JQL * Interact with JQL\+AQL via API * Transition issues which required Assets object validation Jira Service Management users faced disruption when looking to: * Create issues in JSM Customer Portal * View Assets objects on Requests in JSM Customer Portal * Fill JSM Form relying on Assets * Configure Asset fields and JSM Forms with Assets * Refresh queues based on AQL ### **ROOT CAUSE** The issue was caused by a race condition in refreshing authorization tokens. As a result, the products above could not retrieve access tokens and resource identifiers to support customer features, and the users received HTTP 500 errors. More specifically, our out-of-cycle deployment triggered an authorization token refresh for a downstream service serving customer traffic at the time. As our service was processing traffic, it sought to update authorization tokens, and in some cases, the tokens partially persisted within the customer context. Subsequent calls for the affected customer failed due to a mismatch of authorization tokens. ### **REMEDIAL ACTIONS PLAN & NEXT STEPS** We know that outages impact your productivity. While we have several testing and preventative processes in place, this specific issue wasn’t identified because the change was related to a particular kind of legacy case that was not picked up by our automated continuous deployment suites and manual test scripts. We are prioritizing the following improvement actions to avoid repeating this type of incident: * Removing the need to cache authorization tokens during service runtime. Furthermore, we deploy our changes progressively \(by cloud region\) to avoid broad impact. In this case, our detection instrumentation could have worked better. To minimize the impact of breaking changes to our environments, we will implement additional preventative measures such as: * Alerting on high amount of error rates over short spans of time. We apologize to customers whose services were impacted by this incident and are taking immediate steps to improve the platform’s performance and availability. Thanks, Atlassian Customer Support
Status: Postmortem
Impact: Major | Started At: Aug. 8, 2024, 10:17 a.m.
Description: We have resolved the underlying issue and prevented it from affecting any more customers in the future. We have confirmed that only a small subset of customers were affected, and we’re dedicated to reaching out to each one of the affected customers.
Status: Resolved
Impact: Minor | Started At: July 30, 2024, 2:27 p.m.
Description: Between 28 July 2024, 23:00 UTC, and 29 July 2024, 10:22 UTC, some customers experienced performance degradation issues for Jira and JSM. The root cause was a problem with the propagation of configuration in our system during the migration of one of the database instances hosting your Jira cloud site. This caused the Jira application not to correctly balance load against database nodes within the database cluster, leading to CPU saturation of the database. We have deployed a fix to mitigate the issue and have verified that the services have recovered. The conditions that cause the bug have been addressed and we're actively working on a permanent fix. The issue has been resolved and the service is operating normally.
Status: Resolved
Impact: None | Started At: July 29, 2024, 8:27 a.m.
Join OutLogger to be notified when any of your vendors or the components you use experience an outage or down time. Join for free - no credit card required.
