Reminder: Please ensure your Apps comply with Jira Cloud Burst API rate limit

[#1]

As part of Atlassian’s ongoing commitment to reliability, performance, and fair usage, burst API rate limits are now introduced for all Jira Cloud customers. These limits, first announced in the change-log in August 2025, are designed to prevent service disruptions caused by sudden spikes and sustained high load to API traffic. By proactively managing high-volume requests, we ensure a stable and seamless experience for all customers.

What does this mean for you?

• If your app or integration exceeds the allowed number of API requests in a short period, you will receive a “429: Too Many Requests” error.

• These limits are enforced on a per-tenant per-API basis.

• Rate limits are enforced using industry-standard token bucket algorithms, allowing for short bursts of activity but maintaining a sustainable average rate over time.

What action is required?

• Review and update any custom integrations or apps to ensure they compely with the new burst rate limits.

• For existing apps or integrations, implement exponential backoff and retry logic to handle rate limiting gracefully.

Why is this important?

• These limits are based on industry best practices and are essential for maintaining a reliable and high-performing Jira Cloud platform for all users and partners.

• Adhering to these limits helps prevent service disruptions and ensures a positive experience for all Atlassian customers.

Need help or more information?

• For detailed guidance and updates, please review our Atlassian developer changelog and Rate limiting.

We appreciate your cooperation in adopting these changes. Respecting burst limits is essential to maintaining a reliable and high-performing Jira Cloud for all customers.

[Josh]

Hi @Prashanth M .

I appreciate that your team is working on performance and stability. One thing I'm wondering about now is this part of the change:

• These limits are enforced on a per-tenant per-API basis.

As org admins, we had implemented separate service accounts with accompanying API tokens to isolate the impact of a specific integration that's behaving poorly.

• For example App 1 and App 2 are playing nicely with the Jira API endpoints, but App 3's API token gets rate limited because it's sending too many requests to those endpoints at the same time.

However, it appears that the account- and API token-based protections are no longer going to work that way. Adding insult to injury, we've also noticed that 429 errors are not captured in the Atlassian Admin audit log (we'll see Response 200 when the integrated app sees Response 429 - Too Many Requests).

Am I correct in understanding that now all our integrations will be (temporarily) at risk if one misbehaves? If so, are there any ways where org admins can see which app is resulting in rate limiting without needing to raise a Support ticket?

[Josh]

@Prashanth M our team found some additional information on this change that was not made clear in the original developer changelog post or this article:

https://developer.atlassian.com/cloud/jira/platform/rate-limiting/

Rate limits on API tokens

Effective November 22, 2025, Atlassian will implement rate limits on API tokens. This change aims to provide a consistent, reliable, and secure experience for all users. The rate limits will impact any applications, scripts, or integrations that utilize API tokens.

If you are currently using API tokens, it is essential to review the documentation on best practices for optimizing request costs. This will help you adapt to the new rate limits and maintain the efficiency of your integrations.

Neither this article nor the changelog entry contained an implementation date. There was no customer-facing communication prior to the implementation time (day before doesn't count), and this is a change that should have been clearly communicated to customers across multiple avenues given how impactful it can be.

Additionally, the lack of tooling / observability for organizational admins makes it borderline impossible for organizations with large Atlassian environments to pinpoint what app(s) are contributing to rate limiting or how much the threshold has been exceeded. We're completely in the dark at the moment.

I respectfully request that you rollback this change, provide more and clearer communication to customers, provide the tools necessary to address rate limiting issues, and then work to re-implement the change.