Live

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 updates
16:4617:0017:1417:2917:43
Major outageUpdate postedTimes in UTC

Investigating

30 min 53%

Identified

11 min 19%

Monitoring

16 min 28%

Updates

Times in UTC

As posted by Opsgenie

Postmortem2026-09-18 17:02 UTC

### 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

Resolved2026-09-14 17:43 UTC

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.

Monitoring2026-09-14 17:27 UTC

The issue has now been resolved, and services are operating normally for all affected customers. We will continue to monitor closely to confirm stability.

Identified2026-09-14 17:16 UTC

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.

Investigating2026-09-14 16:46 UTC

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

2
Web ApplicationMobile Application

Opsgenie in the last 90 days

Full history
90 days agoToday

Incidents in 90 days

2

Days with an incident

9

Median duration

3 days

This incident

99% shorter than the median

How long each incident lasted, on the day it started. The outlined bar is this incident.

7 days
median 3 days
90 days agoToday

Other Opsgenie incidents

All incidents

Follow 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.

Prompt
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.

RSS
https://outages.cc/feed.xml?providers=opsgenie
Slack
/feed subscribe https://outages.cc/feed.xml?providers=opsgenie

FAQ

Go from tracking outages to fixing production issues with Polylane.

Try Polylane