Disrupted Opsgenie/JSM availability
### Summary On September 14, 2026, between 15:30 and 17:10 UTC, Atlassian customers using Opsgenie, Jira Service Management, and Compass experienced delays in receiving alert notifications and intermittent failures when using Ops features. The issue was triggered by long-running transactions in a core service, which led to thread pool exhaustion and caused subsequent requests to become unresponsive. The long-running transactions were caused by a configuration change released between September 9, 2026 and September 11, 2026 UTC. The team actively monitored the impact of the change on the system until early September 14, 2026 UTC, and observed no anomalies. However, increasing traffic during US working hours on September 14, 2026, caused these unexpectedly long-running transactions. The incident was detected within one minute by our automated monitoring systems, and full service stabilization occurred after isolating and rolling back the change on September 14, 2026 at 17:10 UTC. ### IMP
The latest update from Opsgenie.
State
Resolved
Started
48 d ago
2026-09-14 16:46 UTC
Lasted
57 min
until 2026-09-14 17:43 UTC
Worst impact
Major outage
Timeline
5 updatesInvestigating
30 min 53%
Identified
11 min 19%
Monitoring
16 min 28%
Updates
Times in UTCAs posted by Opsgenie
### Summary On September 14, 2026, between 15:30 and 17:10 UTC, Atlassian customers using Opsgenie, Jira Service Management, and Compass experienced delays in receiving alert notifications and intermittent failures when using Ops features. The issue was triggered by long-running transactions in a core service, which led to thread pool exhaustion and caused subsequent requests to become unresponsive. The long-running transactions were caused by a configuration change released between September 9, 2026 and September 11, 2026 UTC. The team actively monitored the impact of the change on the system until early September 14, 2026 UTC, and observed no anomalies. However, increasing traffic during US working hours on September 14, 2026, caused these unexpectedly long-running transactions. The incident was detected within one minute by our automated monitoring systems, and full service stabilization occurred after isolating and rolling back the change on September 14, 2026 at 17:10 UTC. ### IMP
On September 14, 2026, Opsgenie and Jira Service Management experienced a disruption, and impacted users saw delayed alerts notification and inability to view the alerts in the user interface. The issue has now been resolved, and the service is operating normally for all affected customers.
The issue has now been resolved, and services are operating normally for all affected customers. We will continue to monitor closely to confirm stability.
We have identified the likely cause of the issue, and our teams are diligently working on a mitigation. We will continue to share additional updates here as more information is available.
We are actively investigating reports of a service disruption affecting Opsgenie and Jira Service Management. We will share updates here as more information is available.
Affected components
2Opsgenie in the last 90 days
Full historyIncidents in 90 days
2
Days with an incident
9
Median duration
3 days
This incident
99% shorter than the median
Other Opsgenie incidents
All incidentsFollow Opsgenie
Your coding agent knows when Opsgenie is down, and tells you when a failure is theirs, not yours. You can also get Opsgenie incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "opsgenie" and tell me if Opsgenie has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.cc/feed.xml?providers=opsgenie/feed subscribe https://outages.cc/feed.xml?providers=opsgenieFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane