nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Prashanth M_ljvqh9

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.

Comments

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.

Suyash Kumar Tiwari

Hi @Josh , Thank you for raising these concerns and for explaining the impact this change has on your integrations.

My name is Suyash and I am a Principal Product Manager at Atlassian responsible for API & Extensibility for Jira. I will work with you to ensure this initiative lands well and all your concerns are addressed.

Below, I’ll walk through each of the key points you’ve raised.

Concern around not having API token based rate limiting.
I understand your concern, especially given how you’ve been using separate service accounts and API tokens to isolate integrations. To ensure platform stability for all customers, we need to enforce per‑API limits at the tenant level rather than per token. If we allowed each token to independently hit the full burst limit, the cumulative load from multiple integrations could impact overall performance.

This does mean that, in your example, App 1, App 2, and App 3 share the same burst budget on those endpoints, so a misbehaving integration can temporarily affect others if it consumes a large portion of that budget.

Here’s what we recommend:
1. Ensure integrations (like App 3 in your example) implement robust retry logic with exponential backoff when they encounter rate limits. This is the most effective way to minimise impact on other integrations while staying within the shared limits.
2. If you'd like a detailed report on what is currently triggering your limits, please reach out to our support team and we can provide a breakdown of your usage data for further tuning.
We also recognise the importance of self‑serve monitoring and visibility so that admins can understand which apps or integrations are driving rate‑limit events without needing to open a support ticket. This is a prioritised item on our roadmap, and we’ll share updates as soon as we have a firm release date.
Response 200 when the right response should be 429 - Too Many Requests

Thanks for calling this out.

In your specific case, from our internal checks we can see that Burst Rate Limiting is not currently applied to your account, which means the behaviour you’re seeing is likely due to a separate issue rather than the new burst limits themselves.

Because this depends on your exact tenant and integration setup, we’d like to investigate it as a dedicated case. Please reach out to our support team so that we can pull detailed logs, confirm exactly where the 429 is being generated, and work with you on a fix or workaround.
Around communicating this change

We appreciate your feedback regarding the communication of these changes. To clarify, burst details were added to the Rate Limiting documentation as instructions, and the notification box highlighting these updates has been active since November 2024. Additionally, the specific details were tracked in this Changelog entry. That said, we hear your concerns about the clarity of the implementation timeline and will take this back to the team to improve our future rollout communications.

Josh

Hi @Suyash Kumar Tiwari .

Thank you for the thoughtful and detailed response.

It's great to hear that the self‑serve monitoring and visibility functionality is prioritized on your roadmap. Are there any JAC tickets open for this that I could vote / comment on and watch?

Suyash Kumar Tiwari

Hey @Josh - There is no JAC ticket on the self-serve monitoring. We understand that this is a core customer requirement and appreciate the need behind it. We we will share more details around timeline and delivery on Community & Public Roadmap.

Jason Selby

I have just recieved comms stating

Based on recent traffic analysis, your instance has been identified as a site whose API usage occasionally exceeds the public rate limits. Once enforcement is enabled for your tenant, API traffic exceeding these limits will start receiving HTTP 429 Too Many Requests RateLimit‑Reason: jira‑burst‑based responses.

Where can I find out what is exceeding the publics rate limits so I can put some measures in?

Swapnil Jalamkar_zfqhbf

Hi @Jason Selby - I am Swapnil, Senior Product Manager for Jira API traffic observability. We are currently building a self-serve monitoring dashboard for admins to easily identify which apps or integrations are driving rate limit events, so they accordingly streamline the traffic. We'll share an update once we have a targeted release date for this feature.

Charlie Misonne

Thanks for this article.

We got an email about a Jira site hitting the API limits. The email does not contain any information to help us identify the Jira site it is about (we have 8).

Luckily Atlassian support was able to help me out to pinpoint the site AND exact endpoint.

I encourage fellow community members to vote for these feature requests:

JRACLOUD-74098 - Provide a REST API usage report
JRACLOUD-74595 - Ability to monitor performance metrics
JRACLOUD-77836 - Give customers visibility on rate-limiting costs

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud