Burst API Rate Limits - one bad script can spoil it for everyone. And Atlassian profits!?

[#1]

At the recent San Francisco ACE last Thursday night, Atlassian's Dave Theodore and Ameya Phadnis presented "The Rate Limits of Atlassian Cloud".

The bad news - one person's stuff might break

One bit that was particularly interesting was around the new Burst API Rate Limit which is described thusly:

Burst API rate limiting in Jira Cloud controls how many requests a single tenant can send per second to a given REST API endpoint. This is a short term “spike” safeguard that is separate from the hourly, points based rate limit.

To put this in real terms - let's say one of your users has written a script to automatically sync all of their assigned tickets to a spreadsheet or something crazy like that. And let's say they share this script with all of their colleagues, and they start using it too.

So, this script probably calls the Get issue API endpoint. It's a pretty commonly used endpoint. Other users may have it in their scripts too. Many third-party Apps probably use that endpoint as well (more on this later).

Or maybe somebody has written bespoke integration between your company's internal tools and Jira. And it makes a LOT of calls. And a lot of people use it.

Welp.

If the people writing scripts are not aware of rate limits - they soon may be rudely introduced to them when their scripts break because they've overrun the limit for that one API endpoint.

Worse news - this breaks (or slows things down) for EVERYONE

That rate-limiting kicks in for ANY scripts or integrations that use that same endpoint, not just theirs. And any APPS! Now App Vendors probably have known about these rate limits for a while now, and know how do deal with them, but unfortunately I believe their access to that same API endpoint will still be rate-limited, so while the apps will work, they will be SLOWER.

Atlassian kindly offers some Best practices for handling rate limit responses: Things like checking for Retry/RateLimit headers, writing scripts with resiliency and automatic backoff, etc.

The good news - you might be able to see which stuff might break first or badly, and warn people

BUT HEY, you're a good Jira Admin. You're subscribed to the Jira Cloud Admins Group in the Community Forums. You can tell all your users about rate limits, but of course nobody is going to do anything until their stuff breaks.

But WAIT you can probably look in log files to see whose API tokens are making the most calls. You could head this off by finding those users and giving them a direct heads-up. Man, you could be ... PROACTIVE. NO WAY!

Well. I've got some:

Infuriating news

Atlassian also thinks providing access to API token usage in logs is a good idea too. They think it's such a great idea, they want to charge you an additional $4 per user (well, depending on how many users you've got, from $3-4) to upgrade to Atlassian Guard Premium.

Check it out below - it's an actual feature, but only if you PAY MORE.

This provides organization admins with visibility into activities like which managed users have created an API token or what organizational resources are being accessed by managed and external users via API tokens. 

That's right. Atlassian has imposed limits on your system, and then wants to charge you to help you avoid hitting those limits. Huh.

So then. I think it'd be super-cool if Atlassian made that kind of logging part of Atlas Guard Standard. Or hey, here's an idea, how about not charging for it AT ALL?

Things we customers can do:

• Write articles on Atlassian's Community Forums informing people about the issue.
• Futilely Naively Vote on:
  • JRACLOUD-74098 - Provide a REST API usage report
  • JRACLOUD-77836 - Give customers visibility on rate-limiting costs
  • JRACLOUD-74595 - Ability to monitor performance metrics
• Complain to your congressman Account Executive and Consumer Success Manager.
• Go to Team 26 and complain about it at the Jira booth.
• Make t-shirts for the tickets above and wear them at Team 26?

Infuriating Sidenote:

I went looking for some strategies on how to write scripts that handle rate-limiting, and found that (of course) on Data Center they have built out a dashboard and tons of controls that let you monitor and manage rate limits:
https://confluence.atlassian.com/adminjiraserver/improving-instance-stability-with-rate-limiting-983794911.html

Man, that's quite nice and based on that screenshot, the feature has been around since 2019!? So I guess if Atlassian ever wants to do things right on Cloud, they could uh, look at that for inspiration. (Alas, I fear that maybe the devs who worked on that feature may no longer be with the Company?)

And of course it'll probably be a Guard Premium feature. 😕😕

[Yvonne Sutter]

I 100% share your sentiment and am so glad I'm not the only one infuriated irritated by this. I got an email "Hey we're introducing API limits and hey you're bursting them occasionally, here we offer 0 info on which ones cause this, we won't even tell you if it's a problem due to your Jira Automations or a 3rd party app, but the go-live for the limits is a week from today. Cheers!"

???

Bring a limit, that's fine and fair, but then offer a solution to keep track FOR FREE, that should be an absolute given. For the Jira Automations and other features we get a usage tab as well since they introduced limits, why not for this? (I hope I'm not giving them the wrong ideas now)

[Anne Saunders]

All I will say is that even in the predatory and miserable days of the 00's minutes-based cell phone plan, my cellular provider gave me granular detail about my usage, down to the numbers called and who called me, and the fractional minutes consumed. 

[Aaron Morris]

Now App Vendors probably have known about these rate limits for a while now, and know how do deal with them

Not quite. Yes, app vendors are painfully aware of Atlassian's new rate-limiting model. But no, nobody knows how to work with it effectively. In fact, the burst-limiting scheme talked about in this article is just the tip of the iceberg.

One of the most active threads in the history of the Atlassian Developer Community is about this exact topic: https://community.developer.atlassian.com/t/2026-point-based-rate-limits/97828

Just like one bad automation script can consume everyone's API quota, one aggressive app user can consume everyone's app usage. And there's very little vendors can do to guard against it. 😮

So yes, you may want to complain to your CSM...and print some t-shirts. 😆

Here's a ChatGPT summary of the above thread for anyone who doesn't have the 60+ minutes necessary to read it themselves:

Atlassian announced a new point-based API rate limit for Jira Cloud and Confluence Cloud apps. Under this model, API calls consume points, and apps are placed into quota tiers. The key issue raised in the thread is that the limits are not simply “per customer site.” In Tier 1, all installations of an app share one global hourly pool, so activity from one tenant could affect every other tenant using that app. In Tier 2, the blast radius is smaller, but the risk does not disappear: the quota is effectively tied to a single customer organization, which means one user doing a migration, bulk update, large export, or other bursty workflow could consume the app’s budget and disrupt the app for everyone else in that same organization until capacity recovers. 

Vendors in the thread said this could be especially problematic for enterprise use cases such as planning events, bulk operations, synchronization jobs, migrations, and compliance-related workflows. They also asked Atlassian for more clarity on how points are calculated, how burst traffic is handled, how admins and vendors can monitor consumption, and how quickly apps can be moved to higher-capacity tiers. Atlassian responded that the change is intended to manage rising API usage, that most apps are not expected to be affected, that some apps have already been proactively moved to Tier 2, and that partners can request higher limits through the Partner Portal with a grace period during review. Atlassian also said the hourly quota is meant as an accounting boundary and that the design is being pressure-tested to avoid hour-long lockouts, but many partners continued to ask for more detail and stronger assurances about customer-facing impact.

[Dusty Brossart]

Imagine being charged for a log file access to a software you purchased. That's where we're at folks. 

[s_gridnevskii]

Our company tries to be modern and started to use AI agents working with jira issues. Perhaps we will need to forget about them since every agent consumes many REST API calls. I understand Atlassian needs money since there is no oil in Australia and prices go high, but come on guys rest api call is very cheap in terms of CPU, in fact just to render issue view Jira uses hundreds of them, so it is not the point at all, just business.

And now we know why Atlassian closed on prem Jira. For the simple reason they cannot charge for every API call.

[Swapnil Jalamkar]

Hi  @Darryl Lee - I am Swapnil, Senior Product Manager for Jira API Traffic Observability. Thank you for your valuable feedback regarding the Burst API Rate Limits. Aligned with the core ask in JRACLOUD-74098 (REST API usage report), we are building a native, self-serve API traffic observability experience. This will enable admins to monitor rate-limited requests over time, identify exactly which apps, integrations, or API tokens contribute to throttled traffic, and see the specific endpoints impacted. We expect these insights to help you streamline the API traffic and avoid/remediate any accidental bursts, while ensuring platform stability for all users. This initiative is well underway, and we will share updates here on the Community forum and through other channels as soon as the first version is ready for release.

[Anne Saunders]

@Swapnil Jalamkar Is the plan for the observability tool to be available to teams on Standard Jira/Confluence plans, or will we have to update to Teamwork collection + Guard Premium or some other rate increase? 

[Josh]

@Darryl Lee preach!

I also have not been a big fan of this change. Admins used to be able to protect integrations from throttling by setting up API tokens to a dedicated user (service) account. If one integration started behaving badly, only it would be throttled. Now with the shared approach, those protections are no longer available to teams looking to protect instance performance.

If you want any background finger snappers at TEAM to voice these concerns, let me know. 😉

I wasn't aware of the Guard premium requirement and am glad that @Swapnil Jalamkar is working on improving observability.