No. Atlassian Jira Service Management is up right now.
Every monitored Atlassian Jira Service Management system is operational as of October 11, 2026. PulsAPI did not find an outage in its latest check of the official status feed.
Operational·Checked just now·Live · 60s while moving
Know the moment Atlassian Jira Service Management breaks
Atlassian Jira Service Management is healthy right now. We keep checking (every 60 seconds once it starts moving) and email you the moment that changes.
Free, no password, no card. Unsubscribe in one click.
How we know: the official Atlassian Jira Service Management status page, PulsAPI's own check (every 60 seconds while one is moving, every 5 to 20 minutes while it is stable), and outage reports from engineers. How PulsAPI monitoring works
Atlassian Jira Service Management Component Status
The main Atlassian Jira Service Management systems on this page. All 11 are operational right now.
11operational
Assets
Operational
Assist
Operational
Authentication and User Management
Operational
8 more components tracked
Their status is in the bar above. Free accounts see every component by name.
Also tracking Automation for Jira, Jira Service Management Email Requests, Jira Service Management Web, Opsgenie Alert Flow, Opsgenie Incident Flow, Purchasing & Licensing, Service Portal, Signup.
Component statuses may change independently during partial outages.
Recent Atlassian Jira Service Management Outages & Incidents
Incident history from the official Atlassian Jira Service Management status page, including resolution updates.
Job processing and scheduling is degraded affecting multiple Atlassian productsResolved Oct 1, 2026 · 4h 55mResolved
### Summary
On October 1, 2026, between 01:00 and 07:25 UTC, degraded job processing and scheduling impacted Atlassian products including Bitbucket Cloud, Confluence, Forge apps, Jira, and Jira Service Management in all commercial cloud regions. This caused delayed or missed background tasks, such as email-to-ticket processing and scheduled pipelines; interactive product use was not affected. The event was triggered when an unexpected volume of scheduled tasks became due simultaneously, overwhelming our shared job scheduling platform. Automated monitoring detected the incident within three minutes. Recovery began around 03:45 UTC as engineering scaled capacity and the platform worked through the backlog, with full resolution reached in 6 hours and 25 minutes.
### IMPACT
Most scheduled tasks stopped running at 01:00 UTC and resumed from about 03:45 UTC. Most delayed work had caught up by about 06:00 UTC, and the remaining delays had cleared by 07:25 UTC. Across affected products:
- Recurring scheduled tasks skipped or delayed runs due during the incident; skipped runs were not automatically re-run, and tasks resumed at their next scheduled time.
- Most one-time scheduled tasks ran late; a small number may not have run.
- Automation rules, including scheduled rules, ran normally, except as noted below.
Bitbucket Cloud
Scheduled pipelines due between 01:00 and about 03:50 UTC did not run. If a scheduled pipeline did not run during the incident, you can wait for the next scheduled execution or trigger it manually. Other pipeline runs were not affected.
Confluence
Some calendar event reminders due between 01:00 and about 03:45 UTC were not sent.
Forge apps
Scheduled triggers stopped at 01:00 UTC and resumed from about 04:00 UTC; missed invocations were not replayed.
Goals
Start of the month email reminders to update goals could be delayed.
Jira and Jira Service Management
Incoming emails stayed in their mailboxes and were processed automatically after recovery. Scheduled notifications, such as filter subscriptions, were delayed. In some service projects, automation rules and notifications triggered by SLAs or time in status ran late. SLA timer data remained intact.
Atlassian Support
Until 07:25 UTC, issues with our support tools may have slowed some of our responses.
Based on our investigation to date, we have not identified any loss of work items, pages, repositories, or incoming emails.
### ROOT CAUSE
Our shared job scheduling platform operates at high scale under normal conditions. One of the platform consumers scheduled an abnormally high volume of tasks to be executed at the same time on October 1st at 01:00 UTC. This order-of-magnitude surge exceeded our architectural and scaling limits, creating a processing backlog across dependent services. Engineering manually increased capacity to handle the abnormal load, enabling the service to process the backlog and return to normal operations.
### REMEDIAL ACTIONS PLAN & NEXT STEPS
We know that delayed and missed work affects your productivity. We are prioritizing these actions to help reduce the likelihood and impact of similar incidents:
- **Enhance workload isolation:** Implement fair scheduling guardrails so volume surges from a single source do not starve or delay tasks across other products.
- **Strengthen surge controls:** Add operational capabilities to quickly throttle or pause scheduled workloads from specific sources during unexpected traffic spikes.
- **Improve system scaling and recovery:** Enhance platform capacity and optimize scaling processes to handle extreme demand spikes and recover more rapidly.
We apologize to customers whose services were impacted during this incident.
Thanks,
Atlassian
---
[2026-10-01T07:51:30.397Z] (resolved) On 01st Oct 2026, between 01:00 UTC and 07:25 UTC, users may have seen missing job execution, including delayed email-to-ticket processing and schedules that do not run as expected. We have now implemented a fix and and services have been restored to normal operation for affected customers. The impact to support tickets with missing SLA component and delayed notifications have also confirmed recovery.
Note: For Bitbucket customers, if there was any scheduled pipelines that did not run during the incident window, you may wait for the next scheduled execution or trigger them manually.
---
[2026-10-01T07:01:47.734Z] (identified) Our teams continue to work on recovery until the incident is fully resolved. We will provide further updates if we have significant progress to share.
There is also an impact to the new support tickets created in terms of missing SLA component, notifications which may be affecting the response times and backlog management of some tickets.
---
[2026-10-01T05:00:54.985Z] (identified) Our teams continue to work on recovery until the incident is fully resolved. We will provide further updates if we have significant progress to share.
Along with impact to scheduled and asynchronous work across several products, we also identified SLA component in Jira Service Management is not appearing as expected.
---
[2026-10-01T04:03:57.506Z] (identified) Our teams have taken corrective steps to mitigate the issue and are observing some improvements. We continue to monitor the situation and will take necessary actions until the incident is fully recovered.
---
[2026-10-01T03:47:44.654Z] (identified) Our teams have identified the root cause of this incident and is now actively working on mitigating the issue. We will provide further updates within an hour or sooner if we have any significant progress to share.
---
[2026-10-01T02:55:55.862Z] (investigating) Job processing and job scheduling is degraded, which is affecting scheduled and asynchronous work across several products, including Jira, Confluence and Bitbucket Cloud.
Affected users may see delayed or missing job execution, including delayed email-to-ticket processing and schedules that do not run as expected.
On September 24th 2026, some Jira and JSM users in the US region may have experienced a performance degradation impacting Jira issue creation, issue viewing, and board loading. The issue has now been resolved, and the service is operating normally for all affected customers.
---
[2026-09-24T14:58:28.180Z] (monitoring) Mitigations have been deployed and we are seeing positive signs of recovery across Jira. Issues viewing work items, loading boards, and creating tickets are subsiding.
We are continuing to monitor system health to ensure full stability and will share our next update within 60 minutes.
---
[2026-09-24T13:54:20.515Z] (investigating) We continue to investigate the issue impacting Jira issue creation, issue viewing, and board loading.
Our teams remain engaged on identifying a resolution. We will provide the next update in 1 hour, or sooner if there is material progress.
### 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.
### IMPACT
The incident primarily affected Ops features across Opsgenie, Jira Service Management, and Compass for customers hosted in the US region. During the incident, the end-to-end flow for alert creation and notification delivery experienced an average delay of 22 minutes. No alerts or notification payloads were dropped during the incident; all queued events were successfully processed and delivered as services recovered. Additionally, related Ops API endpoints and Web UI flows experienced elevated latency and intermittent errors. The disruption began at 15:30 UTC and was resolved by 17:10 UTC (total duration: 1 hour and 40 minutes).
Engineering teams were alerted immediately via backup disaster-alerting pipelines and began mitigation without delay. However, the disruption affected internal notification and coordination flows between cross-functional teams (including Customer Support and Incident Communications), which resulted in delays in publishing external Statuspage updates.
### ROOT CAUSE
The incident was triggered when a newly released configuration change made redundant downstream service calls on every page load, causing a traffic spike. The configuration change, released between September 9, 2026, and September 11, 2026, was actively monitored for impact until early September 14, 2026. However, a traffic spike during US working hours caused unexpected issues. The downstream service began rate-limiting requests, and an aggressive retry strategy without sufficient backoff held worker threads open, leading to pool exhaustion and timeouts on incoming critical traffic.
### REMEDIAL ACTIONS PLAN & NEXT STEPS
The incident was mitigated by disabling the feature flag that triggered the inter-service rate limiting.
We understand reliable access to Atlassian products is critical for your teams. We are prioritizing the following actions to prevent recurrence:
- **Improve Service-to-Service Resilience**
- Review and adjust rate-limiting configurations between internal services.
- Optimize retry strategies to prevent long-running transactions and keep the impact isolated to problematic point.
- **Improve Architectural Isolation**
- Refine the architecture of this core service to have more isolation between different transactions so that degradations in one transaction type do not impact unrelated critical flows.
- **Improve Proactive Alerting**
- Add early-warning alerts for thread pool saturation and elevated inter-service rate-limit responses before they impact end users.
- Implement backup alerting processes for customer support and incident communication paths
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
---
[2026-09-14T17:43:30.670Z] (resolved) 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.
---
[2026-09-14T17:27:32.434Z] (monitoring) The issue has now been resolved, and services are operating normally for all affected customers. We will continue to monitor closely to confirm stability.
---
[2026-09-14T17:16:20.108Z] (identified) 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.
---
[2026-09-14T16:46:06.429Z] (investigating) 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.
Atlassian Jira Service Management Uptime History
Daily uptime recorded by PulsAPI over the last 90 days, with the days that carried a Atlassian Jira Service Management incident marked. Each day is measured from our own checks, so the record continues even when the vendor publishes nothing.
Uptime history91 days observed
Jul 1399.93% average · 11 days with incidentsOct 11
Live Atlassian Jira Service Management Outage Reports
Problems reported by engineers using Atlassian Jira Service Management. Reports often appear 10 to 20 minutes before the official status page moves, and stay on this page for 90 days.
Reports, last 24 hours0 total
24h agoNothing reportednow
No Atlassian Jira Service Management problems reported yet.
Something wrong with Atlassian Jira Service Management on your end?
Reports are anonymous, take about ten seconds, and help the next engineer who checks.
About Atlassian Jira Service Management
Jira Service Management (formerly Jira Service Desk) is Atlassian's ITSM platform used by 45,000+ teams for IT help desks, incident management, and change management. JSM outages prevent IT teams from logging and routing support tickets. Track Jira Service Management status and outages here.
Over the past 30 days, PulsAPI has measured Atlassian Jira Service Management uptime at 99.95%. Response times, incident history, and SLA tracking for Atlassian Jira Service Management are available on the PulsAPI dashboard.
Atlassian Jira Service Management Status FAQ
Is Atlassian Jira Service Management down right now?
The verdict at the top of this page comes from the latest poll of the official Atlassian Jira Service Management status feed and refreshes automatically, so you are not looking at a stale cached answer. PulsAPI re-checks a vendor every 60 seconds whenever it is not fully operational, or has changed status in the last 30 minutes, so an incident is always on the fastest cadence. Vendors that are stable and rarely watched are re-checked every 5 to 20 minutes instead.
What should I do if Atlassian Jira Service Management is not working?
Check the component list on this page first to see if your failure matches a known outage. If it does, you can report the issue for other engineers, follow the incident timeline for vendor updates, and run any fallback your app supports until Atlassian Jira Service Management recovers.
How do I check Atlassian Jira Service Management uptime history?
PulsAPI tracks Atlassian Jira Service Management uptime over 30, 60, and 90-day rolling windows. The current 30-day uptime is 99.95%. The 90-day uptime strip on this page is public: no account needed. A free account adds alerts whenever Atlassian Jira Service Management changes state, plus 15 days of incident detail; Pro extends that to 90 days and Business to 13 months.
How fast does PulsAPI detect Atlassian Jira Service Management outages?
PulsAPI reads the official Atlassian Jira Service Management status page. PulsAPI re-checks a vendor every 60 seconds whenever it is not fully operational, or has changed status in the last 30 minutes, so an incident is always on the fastest cadence. Vendors that are stable and rarely watched are re-checked every 5 to 20 minutes instead. Alerts reach Slack, Discord, Microsoft Teams, PagerDuty, or email within seconds of detection.
Does PulsAPI track individual Atlassian Jira Service Management components?
Yes. PulsAPI monitors 11 individual Atlassian Jira Service Management components, so you can see which service or region is affected instead of a generic "service degraded" banner.
Can I get alerts when Atlassian Jira Service Management goes down?
Yes. Create a free account and subscribe to Atlassian Jira Service Management: the free plan covers three services with unlimited email alerts and no monthly notification cap. Paid plans lift the monitor limit entirely (Pro and above do not meter how many vendors you watch) and route the same alerts into Slack, Discord, Microsoft Teams, PagerDuty and webhooks.
How do I report an issue with Atlassian Jira Service Management to the community?
Click "Report an issue" at the top of this page, pick the issue type and severity, and optionally add your region and a short note. Reports are anonymous and help other engineers spot Atlassian Jira Service Management problems early. Official status pages often lag real incidents by 10 to 20 minutes.
Is there a free way to monitor Atlassian Jira Service Management?
Yes. The free plan covers 3 monitored services with unlimited email alerts, permanently, so Atlassian Jira Service Management plus two more costs nothing. Every new account also opens with a 30-day Business trial (unlimited monitors, Slack alerts, SLA reporting) with no credit card.
Track Atlassian Jira Service Management with the rest of your stack
2463+ vendors in one dashboard, and an email the moment any of them changes state. Three free, and no monitor limit at all from $29/mo, unlike the alternatives, which keep charging by the monitor.