Jira had two separate stretches of degraded performance on 24 September 2026, the first lasting 2 hours 56 minutes and the second 2 hours 2 minutes. Both were Atlassian-side faults affecting viewing content and creating or editing issues, not anything in your own setup.
Started
08:52 UTC
Duration
Lasted 2h 56m
Source
IsDown
Next time
Jira Software is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Viewing content, Create and edit
What happened?
The first incident started at 08:52 UTC and was filed as degraded performance accessing Jira and viewing issues. Atlassian's own resolution note is worth reading closely: it says the actual problem window ran from 07:28 to 08:08 UTC, nearly an hour before the status page update that announced it. That gap between fault and filing is common with status pages and is one reason relying on them alone leaves you behind. The incident was marked resolved at 11:46 UTC, 2 hours 56 minutes after the first public update went out. A second, separate incident began at 13:54 UTC, described as degraded performance viewing issues and boards, with issue creation also affected. Atlassian said this one hit Jira and JSM users in the US region specifically. It was mitigated by 14:58 UTC and marked resolved at 15:53 UTC, 2 hours 2 minutes after it started. Across both incidents Atlassian published six updates total and no post-mortem has been filed beyond the resolution notes quoted above. No user reports were logged in UptimeRobot's window for either incident. The components affected across the day were viewing content and create and edit, covering both read and write paths into Jira.
Learning
Both of today's incidents sat on Atlassian's side of the line: degraded performance inside Jira's own services for viewing issues, loading boards and creating tickets, the kind of fault that shows up as slow or failed responses no matter how healthy your integration code is. A check that only pings your own application servers or your webhook endpoints would have stayed green through both windows, because your infrastructure was fine the whole time. That's exactly why the first incident's own timeline shows a near-hour gap between when the fault actually started, 07:28 UTC by Atlassian's account, and when the public update appeared at 08:52 UTC. If you were only watching your own systems, you'd have had no signal at all until users started complaining or tickets stopped loading. This pattern, a vendor dependency degrading while your own stack reports healthy, is the normal shape of a third-party outage. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
