@MaheshPopudesi, you’re doing bug fixes on a system that’s going to production in a little more than a month. This is the kind of issue that should be caught in beta, not after the announcement. Does this not suggest the rollout needs more time?
It’s been almost a week since the original post, and most of Scott’s questions remain unanswered. You also haven’t addressed the lack of rate limit headers in Forge frontend calls (ECO-899, FRGE-1923). How are Forge apps supposed to implement any kind of adaptive throttling without access to these headers?
Answering some of the confusion on how Tier 1 and Tier 2 Rate Limits work.
In Tier 1 (Global Pool), each app receives its own 65K points/hour quota, shared across all of that app’s tenants.
In Tier 2 (Per‑Tenant Pool), each app receives a separate quota per tenant, which varies based on that tenant’s product edition and user count.
We’ve designed the system to tolerate occasional overages above the points/hour allocations without immediately impacting your tenants. Only sustained overage over time will trigger hard rate limiting.
Moving from Tier 1 to Tier 2
If you expect your app’s traffic to grow, you don’t need to wait until you hit limits before talking to us. We have made it easy for Partners to request a tier review at any time by raising a support ticket Increase Marketplace App Limits.
We’ll work with you to assess whether Tier 2 is a better fit based on your app’s usage patterns and customers’ needs.
Points usage, visibility, and notifications
We will also make it easier to view point usage in the Developer Console. We plan to provide clearer insights into how many points your app is consuming, along with notifications as you approach key thresholds.
Impact on analytics and reporting use cases
Many apps focused on analytics and insights have been proactively evaluated and moved to Tier 2 where appropriate. If your app is analytics‑heavy or you believe it requires higher rate limits to support your customers, please contact us through the support ticket process to request higher rate limits.
API calls from Forge UI
Any request that invokes Jira or Confluence Product APIs will be counted toward the rate limits, including calls originating from the Forge UI.
Thank you for surfacing the header forwarding issues, the team is already looking at this.
Atlassian Connect to Forge Migration
We have done proactive mapping to assign both apps to the same tier. If we missed it, and you expect the Forge app traffic to grow, please let us know here. Increase Marketplace App Limits so that we can review it.
We are still reviewing some of the other questions in this thread and will circle back with responses.
you need to understand that we do not want to worry about this. Atlassian has chosen to be a platform provider with Forge and we are now literally the customers of your platform.
Imagine a platform provider like Vercel would implement this clumsy system. A manual process like this is just not acceptable.
I don’t understand why Tier 1 exists when we can simply request to be moved to Tier 2 when its obviously not a problem to do so?!
Atlassian already has a rate limiting system in place
Atlassian already has a policy in place
Atlassian can already identify policy violations on a per-app basis
95% of apps are unaffected by the new policy, partners can ask apps to be put in tier 2 and no action is currently required (?)
“A design that results in hour-long lockouts for apps would not be acceptable”
Can someone please tell me what problem Atlassian is solving?
The only thing I can imagine is that Atlassian is preparing for an increase in in-house developed Forge apps, as she is increasingly encouraging customers to get on the Forge bandwagon.
Assuming this is the case, may I suggest that Atlassian makes a distinction between Marketplace Partners and other developers? Put all apps from Marketplace Partners in Tier 2 by default, and apps by in-house developers in Tier 1 (with the ability to request higher quotas).
Given that we are paying Atlassian multiple times over, I would consider this to be fair.
While this works in my favor, I also want my customers to be happy on the Atlassian platform.
If I get rate limit x per enterprise instance, in-house developers on the same instance should get the same rate limit. Their needs are higher too. And they are paying multiple times too.
So the question has been raised many times here- why is there a global pool at all and why isn’t it a per tenant limit for all apps and get rid of the manual process
@MaheshPopudesi Could you please address the elephant in the room and explain the thinking behind the Tier 1 pool and the potential DoS issue?
And, what’s the timeline for the below? At the moment, we are all just guessing what our point numbers may look like.
Points usage, visibility, and notifications
We will also make it easier to view point usage in the Developer Console. We plan to provide clearer insights into how many points your app is consuming, along with notifications as you approach key thresholds.
We are looking for advice from Atlassian how to handle the rate limiting.
Our apps do not do batch requests or scheduled triggers.
We call the Atlassian APIs as a response to a customer viewing a page or clicking a button (our apps are mainly Confluence macros). That means we have no control over the rate of usage of our apps, or when users view a page with our macro. Obviously our macro could render “Confluence is overloaded, try viewing the page later” into a page, but I think this is not acceptable for users. On the other hand, our macros can’t wait with the rendering, because we have less than 10 seconds to return a response before Confluence displays “something went wrong” to the user.
We also see that our users put our macros e.g. into a page properties macro, and then view a page properties report macro, which in turn can trigger tens to hundreds of page renderings, triggering hundreds of API calls. The page properties report macro is a platform feature of Confluence. Also some users do e.g. a space PDF export for e.g. offline backup, which triggers rendering all pages, requiring our app to do many API calls in a short period of time. We can’t let our app “wait”, as otherwise the PDF export will just show an error message in the PDF.
So our question is: When we get a 429 response, what can/should we do?
First, thank you for acknowledging that the Tier 1 architecture will result in cross-tentant impact (even if eventually, instead of immediately).
Can you please elaborate on what “sustained overage over time” means? I understand that you probably want to keep specific thresholds a secret. But can you confirm whether sudden and legitimate usage from large customers over hours or days will be considered “sustained overage over time”?
Here’s a well-known diagram from the CWE that illustrates the problem with global pooling of resources without user or tenant-specific throttling:
Note: It doesn’t matter how many “yellow shirts” you arbitrarily accommodate before denying service. If everyone in line is a legitimate user (especially a paying user), then the solution is neither reasonable nor fair.
The point is that the overwhelming majority of commenters here acknowledge the need for rate-limiting and the fairness of a token-based system. But only Attlassian seems to understand the wisdom of the Tier 1 (Global Pool) portion of the solution.
A lot of ink has been spilled here about the tier 1/2 scenarios, but I have not yet seen any feedback from Atlassian on the time window, which is one of the other big problems (regardless of tier).
One hour is far too large to allow for recovery and it is not a reasonable duration of potential outage for any serious app.
In the event of a rate limit breach (meaning whatever it takes to set off your triggers), it is completely unacceptable to tell clients that the app now needs to remain offline for up to one hour before it can be used again.
Can the “accounting barrier" be reduced to 5 minutes with prorated rate limits? Or if really necessary, 10 or 15 minutes? Even better, can Atlassian aggressively throttle requests when apps pass 80% (or whatever) of the barrier, rather than refusing service entirely?
Imagine you have customers trying to use your timesheet app. Is it ever acceptable to say that, sorry, no one can log their time for the next hour, because the company admin ran a few space imports that exceeded the quota?
I could certainly sell the story to my customers that my app will be slow to respond to users for 15 minutes after such an event, but I cannot sell the story that my app will be offline for everyone for an hour. Apps are used by our customers to do work. Users cannot do their work if they cannot use the app. In the event of rate limiting, this system makes everyone unhappy.
This is a huge problem if an app is tier 1, but it still represents a significant problem even at tier 2 (especially given that is likely the largest customers who trigger rate limiting problems).
Here is another problem that no one is talking about: variation in points-per-edition with the caps.
If you have tier 2 apps, there is an effective points cutoff at 11,666 users ((500000-150000)/30 = 11,666) on an enterprise site, meaning your app’s tier 2 points-per-user budget starts to decline as soon as you reach 11,666 users.
If you have a Jira Cloud enterprise site with 100,000 users, your app has close to one-tenth the per-user budget of a 10,000 user site. (These 100,000 user customers are also the ones that we really want to keep, as vendors!)
The edition-based variation in points also seems unintuitive and a problem waiting to catch customers by surprise. Is Atlassian really putting different app rate limits in obvious customer-facing marketing when selling standard vs premium vs enterprise? Or is this (as I suspect) a hidden technical detail that no one finds out about until it is too late?
I can see customers downgrading from premium to standard, thereby losing half of their per-user points, with this edition downgrade (which was supposed to be an independent action) then causing certain apps to stop working.
And if standard-edition customers start hitting tier 2 rate limits, do we need to act as Atlassian salespeople and try to convince customers to upgrade to Premium just so they can use our apps?
All of these are just distractions from selling apps (and having happy customers). Having a uniform per-user value seems like it would solve a lot of these problems, as would having caps that are able to scale as Atlassian’s platform scales.
Also, about the Tier 1 global limit, there’s another concern:
We maintain a free marketplace app (400+ installs) that runs entirely in the UI with minimal platform impact. It’s low effort for us and quite useful for some people.
With the global limit, customer A may be unable to use the app because customers B and C exhausted the hour’s token pool. All three customers pay Atlassian for Jira; not for our app. The rate limit they’d experience stems from their combined use of Atlassian’s platform by way of our app, yet customer A would face service degradation through no fault of their own. Atlassian becomes the actor depriving customer A of service.
Without implementing additional monitoring (which we likely won’t), we’ll only discover this through bad reviews.
We use this app internally via the marketplace version. If heavy customer usage starts impacting our own work or we get a bad review, we won’t add rate-limiting handlers: we’ll simply remove the free app from the marketplace.
Getting locked out for an hour by exhausting all your points in the first few minutes is an extreme edge case; we haven’t seen this happen in real usage data for organic daily app workflows. In practice, organic usage patterns naturally spread requests across the hour, so we don’t expect apps to hit this scenario.
If your app reaches or exceeds the per-hour rate limit quotas, we will still let the app continue to operate without impacting your customer workflows. However, sustained overage over time will be rate-limited.
We have a diverse set of apps in our ecosystem, and we’ve designed the per-hour quotas to strike a balance in handling bulk operations while preserving plenty of headroom for normal organic day-to-day usage across these apps. And for apps currently in Tier 1, there’s meaningful room to grow; you can also proactively apply for Tier 2 whenever you’re ready.
Atlassian enforces several types of rate limits, including burst limits, platform-level limits, and product-specific API limits. Apps should assume that users may occasionally encounter these limits and design user experiences that handle rate limits gracefully.
Apps with organic usage typically show predictable traffic patterns, even as more customers are added and usage grows. That coupled with occasional overage forgiveness, should allow you to monitor an increase in usage early, and if your app is currently in Tier 1, please request a higher rate limit - Increase Marketplace App Rate limits
In practice Tier 1’s global pool has ample headroom for the vast majority of apps, including free ones, and we don’t expect typical organic usage to cause cross‑customer impact.
That said, for apps whose traffic profile suggests they’d benefit from per‑tenant limits, we’ve already moved hundreds of free apps to Tier 2. If you’d like us to review your app’s rate limits, please raise a ticket here for our team to review Increase Marketplace App Rate limits
Given that we are running in circles here, I think it is safe to say that this thread is dead.
I think we can conclude that:
Atlassian has no intention to answer the open questions
Atlassian has no intention to share her reasoning
Atlassian believes she knows traffic patterns better than Marketplace partners
Atlassian provided lip service to the lacklustre communications, but has no clear plan to address this moving forward
No change will be made to the rate limiting policies
Despite this thread resulting in the most Nice/Good/Great topic/reply badges earned on this platform in a 1-week period, all Atlassian Marketplace Partners are obviously completely wrong, Atlassian has it right, and we should all just shut up and be pretty.
I don’t mean any offense with this and I feel bad that you’re the messenger with this. But can we start seeing the data for this?
Please understand that for any vendor’s perspective (and potentially customers) you’re dealing with our reputation and support. This is why we want hard facts.
I am getting back to this issue after the holiday break. As an aside, there are now 28 days before this change goes live.
Issue 1: DC migrations and batch workflows
I previously posed questions about batch workflows. You say that “organic usage patterns naturally spread requests across the hour”. What about batch jobs that, by definition, do not?
For example, do the new limits count the API calls generated from DC-to-Cloud migrations? I previously posed this question but I do not recall seeing any answer.
You wrote that you don’t expect apps to hit this scenario, but…batch activities and DC-to-Cloud migrations do happen.
This amounts to a breaking change with very little notice: vendors have existing logic that performs many actions in batch, with appropriate logic to throttle the request rate upon reception of 429 responses, that is tested and working.
Instead of throttling requests like it used to, Atlassian is now seemingly shifting to a policy that accepts a large batch of requests but then starts blocking everything for an extended period of time (and now across both back end and front end), possibly also impacting other clients.
Dealing with this change definitely requires updating vendor logic, but we are still missing the header details to do this properly (see below).
Issue 2: Creating new attack vectors
For locking out all clients for an hour, you wrote “we haven’t seen this happen in real usage data”. From a “deliberate DoS” perspective, you would not have seen this behaviour because the attack vector does not currently exist. As soon as this change goes live, it creates a new attack vector that provides an easy method for malicious actors to knock apps offline.
Can Atlassian address how it would potentially deal with this? For example, is Atlassian making plans to allow vendors to request a priority escalation and promise an acceptable SLA (within an hour, ideally)? If this becomes just a “submit a general-purpose low-priority request to upgrade to tier 2” and it takes a week or more (as ECOHELP tickets are wont to do), that is not going to work.
Issue 3: Counting front-end API calls and lack of vendor visibility
This is the most concerning part to me. To my knowledge, Atlassian has never previously applied app-level rate limiting to front end API requests, but this is about to change in four weeks.
How are app vendors supposed to know how close they are to the proposed limits? Vendors can monitor their own back-end calls easily, but front end calls are a black hole for most vendors.
Sure, there is ECO-1208 proposed for Forge apps, but it sounds like the investigation is just starting this week. Even if it were somehow delivered today, this does not give vendors enough time to take any corrective actions before the new limits start.
Additionally, the existing dev console counts only API calls responses (not points), so it is still not particularly helpful for assessing if your app is close to or exceeding the limits.
On that topic, how are Connect apps supposed to get this visibility, other than waiting for the app to fail and customers to complain? ECO-1208 targets Forge apps, but the vast majority of apps with high usage are still Connect.
Connect is still supposed to be supported until Dec 2026, and I would hope that Atlassian will…keep supporting it until then.
Finally, by making points information available exclusively within the response headers (and nowhere else), particularly for RoA apps, Atlassian has created a situation such that end-user complaints become the primary feedback mechanism to the vendor about exceeding rate limits. How many customers does a vendor have to lose before they realize that there is a problem and they need to request an upgrade? Can there not be a better way?
I guess you could ask vendors to manually scan their developer console every day to count how many 429 errors occurred, but this seems like an unnecessary waste of time for thousands of people.
You wrote:
To summarize the entire problem: I am unaware of any way to design a user experience to “gracefully” handle 60 minutes of sustained 429 responses (or even 30 or 15 minutes).
As I have written before, the rollout seems rushed, particularly given the lack of vendor visibility into the points consumed.
What Would Help Vendors
Atlassian could easily assuage a large swath of vendor complaints by doing these three things:
Postponing the rollout until at least 45 days after the point at which Atlassian provides accurate and complete points-based API call metrics for all apps,
Providing response headers that document the approximate number of points used and remaining, since this is the only way that vendors (particularly those who are RoA) can try to approximate the earlier behaviour and not cause themselves to break, and
Reducing the “accounting boundary” from 60 minutes to 15 minutes, thereby reducing the duration of potential outages, whether they be triggered by malicious attacks, migrations, or increased user load. Outages that are just a few minutes are much more tolerable to users than those requiring “come back in an hour”.
Why is Atlassian getting such pushback (and why does this thread have 833 collective hearts)? It is because we, as vendors, do not want our apps to break and cause problems for our mutual customers. I hope you can understand why Atlassian’s proposed changes here have warranted such concern, because the potential downside for vendors is huge.
I agree with @scott.dudley’s post and the above concerns expressed by partners @MaheshPopudesi. Please postpone the implementation of the rate limiting system and run a proper rfc process. While I’m sure its intention is a more stable platform, the result of this will likely be a less stable platform which in the end results in unhappy customers, while the partners will have to answer to them. Breaking changes on this level require a close collaboration with partners to sort out issues and clarify real life concerns. You are in this instance our platform provider on which we depend to offer a stable service for our customers.
As it stands, this change currently violates all of Atlassian’s above company values.
Customers will get #@!%-ed.
There will not be balance, there will be 429s and broken apps.
Communications about this matter have not been open, and came far too late.
We partners don’t feel like this is playing like a team. Partners are certainly not part of the team. We don’t have the tools to properly monitor rate limits or the time to implement fixes, et cetera.
This change is currently not part of a continuous improvement, but a platform that will be open for both accidental and malicious degradation, which I am sure is not something Atlassian seeks.
