2026 point-based rate limits

@MaheshPopudesi – Thank you for confirming that Isolated Cloud is intended to be excluded. The rate-limiting guide only suggests that Government Cloud might be excluded, and the Quick Reference Guide has no reference to either. It would be helpful to add those clarifications as part of the other requested documentation updates the community has identified.

Regarding regulated environments, I hope it is clear now that my concerns are that regulated customers are particularly sensitive to platform instability, because platform instability introduces a new category of risk most customers don’t need to be concerned with: regulatory compliance risk. So much so that many will not hesitate to abandon the platform if they perceive it to have become unstable. Especially if they are only evaluating Atlassian Cloud as they plan to decommission Data Center.

I’m sure the Atlassian Team is still working to compile thoughtful responses to the great multitude of concerns expressed in this thread regarding the validity, timing, and stability of the pending change to rate limiting. I look forward to Atlassian’s responses.

1 Like

Thanks @MaheshPopudesi. What seems to cause the most anxiety/confusion is around the tier system and how one qualifies or gets moved into Tier 2. Clarifying that would go a long way.

For what it’s worth, I mistakenly assumed that “Free” referred to free marketplace apps, not Atlassian apps.

Hi Everyone,

We’ve heard your feedback, particularly around timing and clarity, and we appreciate how direct the community has been. While these changes have been the focus of a lot of internal discussion and care, we recognize that aspects of our initial communication, especially around how tiers and enforcement will work and the associated timelines, weren’t as clear or as early as they needed to be. That created uncertainty, and we take responsibility for that.

The goal of the new rate-limiting model is to protect reliability and fairness across all tenants and apps, not to limit or degrade the experience of partner apps in our ecosystem. For the vast majority of partners, enforcement in February should be a non-event. Based on what we see in the data today, existing usage patterns, including known peaks, are already supported, so we don’t expect that you need to change anything.If that ever isn’t the case, we’ll let you know, work closely with you to navigate, and guide you through a straightforward process to request an upgrade where it’s needed.

Over the past year, we’ve carefully reviewed traffic data across apps and used that to inform the tier thresholds for both the Global Pool and the Per-Tenant Pool. Those thresholds are based on how apps actually behave in production, not on theoretical models. In cases where usage from a single customer could impact other customers of the same app, we’ll proactively partner with those developers on per‑tenant quotas or other mitigations to maintain a fair and reliable experience for everyone.

We’ve identified a small number of apps whose current usage patterns would be better served by different limits. We’re working with those developers to adjust their configuration so they remain comfortably within bounds. If we see similar patterns in your app in the future, we’ll contact you with clear options and sufficient notice. This won’t be a surprise change.

Here’s what we’re doing to ensure this change lands predictably and safely:

  • Improving visibility, including tier labeling for your apps in the Developer Console in the next 24 hours and observability signals

  • Continuing to engage directly where deeper discussion is helpful

  • Communicating proactively if we do make changes that could affect you so you have time to prepare

Thanks for your patience and for continuing to be candid with us—we deeply value this community, and your feedback will help us get this right.

7 Likes

Thanks Alan. You message notes that the “vast majority of partners” effectively need not worry. That’s great. But what if I’m one of the affected partners? We have dedicated 50% of our engineering capacity to Forge, I do not want to dedicate more to dealing with API limits. As was said in the !MPACt sessions, I want to focus instead on innovation and building new ideas. I am sure this anxiety is shared amongst other marketplace partners, and is likely adding fuel to this fire.

Further, we all know Forge is not where it is wanted. Please can you reassure me that not only will the tier labelling be put in the Developer Console, but that it will be accurate.

For instance, the 0% revenue share of RoA coming early is great. But due to bugs, we didn’t get it until well after 1 October. It was backdated, all is OK in the end. What if there are similar challenges here? Automatic enforcement gives no second chances, customers will be affected. Please make sure it works properly, and only affects the partners you want to target.

Edit to add: You say that “We’re working with those developers [to make changes].” Does this mean if we haven’t been contacted, we are OK? And you can confirm that there will be no impact come 2 Feb?

5 Likes

@AlanBraun – Thank you for the additional context and for acknowledging the gaps in the initial communication. It’s reassuring to hear that enforcement in February is expected to be a non-event for the vast majority of partners.

That said, my concern is less about February itself and more about what happens on any ordinary day after enforcement begins.

Specifically: what will happen when an app exceeds Tier 1 limits?

I understand Atlassian’s commitment to working closely with partners, but there’s an important gap between identifying an issue and resolving it. During that window, what should partners and customers expect?

  • Will the app experience 30+ minute outages?

  • What’s the order-of-magnitude time-to-resolution? Minutes, hours, days, or weeks?

  • What does “proactively partnering” look like in real time for customers already in production?

To make this concrete, here’s a hypothetical scenario.

New Enterprise usage on a Tier 1 app

Imagine a Jira Cloud reporting app (let’s call it “Super Awesome Business Reports”). It’s relatively new, has a modest SMB customer base, and is operating comfortably within Tier 1.

An Enterprise customer (let’s call them ”Acme Enterprise, Inc.”) begins a Jira Data Center → Cloud migration. Acme needs a new reporting app, because their custom home-grown reports won’t migrate to Cloud. They find Super Awesome Business Reports in the Marketplace and install it in an Enterprise sandbox.

Now they want to evaluate whether the app will meet their needs, so they run a large exploratory report, perhaps across 1+ million issues.

What happens next?

  • For the prospective Enterprise customer: Does the app function reliably during this evaluation, or is it likely to hit Tier 1 limits during a perfectly reasonable “trial” use case?

  • For existing paying customers: Are they insulated from this spike, or do they experience outages because of activity in Acme’s enterprise sandbox?

  • For the vendor: Is there a realistic path to winning the Enterprise customer? Or is their best-case scenario simply not losing existing customers during the outage(s)?

From the outside, it’s not clear how Tier 1 handles this kind of legitimate-but-sudden usage without creating cross-tenant impact.

Another scenario: Connect → Forge migration under the new limits

Now consider the same app, but as an established Connect app migrating to Forge. The vendor is already dealing with:

  • Re-implementing reports using different APIs

  • Managing customer expectations where feature parity isn’t yet perfect

Under the new model, they also need to accurately predict their future API point consumption before deploying to production and hope they qualify for Tier 2 in advance.

If that estimate is wrong (or if Tier 2 is declined), the result isn’t just throttling. It’s production instability for existing customers in validated or business-critical environments.

I trust Atlassian has thought through scenarios like these, but I haven’t yet seen them clearly addressed in the “95% non-event” framing. For partners and customers, especially customers in enterprise and regulated contexts, these edge cases are exactly where confidence is won or lost.

It would be extremely helpful to understand:

  • How sudden, legitimate spikes from a single tenant are handled in Tier 1

  • What protections exist for other tenants during that period

  • What the expected time-to-resolution looks like once an issue is detected

Greater transparency here would go a long way toward helping partners and customers assess risk and plan responsibly.

Thank you for continuing to engage on this.

9 Likes

Can we get a non-corporate explanation as to why the equation isn’t simply:

tenant-scoped app hourly rate limit = total users per tenant * [X] API requests

No tiers. Fully automated. Scales in a fair, predictable and manageable way for all parties. Provide that user total within the context object.

I don’t understand why Atlassian would simultaneously be reducing support headcount while creating yet another unnecessary support queue for every single app to go from Tier 1 to Tier 2.

If you’re worried about apps accidentally or intentionally maxing out that rate limit, you surface that data to the org admin who will contact the app developers. Simple self-policing model.

4 Likes

Hi everyone, thanks for your questions and discussion here.

We’re working on a consolidated response to address the remaining questions raised in this thread and will follow up with more details early next week.

While this is coming, we have reviewed current and projected traffic patterns across apps as part of our planning, and we don’t expect you to invest any cycles in this over the holidays.

Appreciate the continued engagement.

2 Likes

It’s now 48 hours later. Also note you’re applying this change to both Forge and Connect apps. Those have very different available metrics in the dev console.

Docs: “When the quota is reached, all further requests are denied until the next reset.”

3 Likes

We have started rolling out the labels in phases across all apps, and you should have full visibility by early next week.

I do see the Tier listings on our apps in the developer console, and I already see the issues with it. Apps that get migrated to Forge get their Tier status reset. We have some apps that are in migrations currently, and while they show Tier 2 on Connect listings, they now show Tier 1 on Forge listings. The Forge migration that we had for a while is Tier 2.

Also, it seems that frontend calls do get rate-limited (some of our apps on Tier 2 only have frontend calls), but the Forge does not expose rate-limiting headers at all.

1 Like

Hi @MaheshPopudesi

For apps that are not listed in the Developer Console (for example, pure Connect apps that are not Connect on Forge and which are not Cloud Fortified), in which location will Atlassian make the tier information visible?

Thanks,
Scott

1 Like

Hi @scott.dudley. We have a few pure connect apps and there is a new Rate Limit Tier field showing for those apps in the Dev Console.

1 Like

Hi @MaheshPopudesi one of our apps has been classed into a Tier 1 global pool.

The app gets hit hard with bulk transitions from large customers. We were getting a lot of 429’s so had to apply significant request smoothing based on the old rate limit headers. As soon as the rate limit bucket changes from 300 per minute to 60,000 per hour that smoothing routine will not longer work.

Who do we talk to to get the tier reassessed?

Thank you
Chris

1 Like

I heard that Connect apps may only show up in the developer console if they are Cloud Fortified. Personally, my Connect apps do not appear in the console at all.

However, @RaimisJ figured out that even if the apps do not appear, you can hack the URL to include your Connect plugin key and access the tier information like this: https://developer.atlassian.com/console/myapps/connect/{app.key}/overview

Atlassian still presumably needs to correct this omission from the console so that people do not need to use this workaround.

2 Likes

Our apps have been put in tier 1. Many of our jobs are scheduled and if many daily scheduled jobs execute in the same hour then we are sure to hit the 65k limit. If we implement the retry and backoff strategy then we are bound to increase the Function usage and incur charges, which was changed recently causing huge spikes. Our customers rely on these daily jobs running reliably. It’s not acceptable for them to start seeing failures just because Atlassian suddenly decided API usage has to be “fair.” There’s got to be a better way to manage this.

The line of “vast majority of apps will not be impacted” just does not hold water. May be there are many apps that are deployed that are just personal/learning apps. Does this include apps built by customers? Does this include old apps that are not in use and not updated in years? Vast majority of apps may just not have any users.

Hi Atlassian, could you clarify what is meant by the “Custom Rate Limit Tier” and what limitations apply to it?

1 Like

Thank you for flagging this. We are working to ensure that any apps that migrated to Forge have the same Tier assignment as their Connect apps. We will reconcile these shortly.

1 Like

Hi Chris,

We can absolutely review your app’s tier and quota.

Please submit a ticket using the Marketplace Support Increase Marketplace App API rate limit here so our team can review this.

Thanks, Girish. Please submit a ticket using the Marketplace Support Increase Marketplace App API rate limit for your apps, so our team can review your apps.

And thus begins the new unnecessary support queue.

10 question form.

3 Likes