2026 point-based rate limits

General
22

You cannot build an enterprise platform while disabling the ecosystem that makes it enterprise-ready.

This decision fundamentally undermines Atlassian’s enterprise business model.

I fully agree with, and stand alongside, all the Marketplace Partners here. This rate-limit change, combined with the EOL of Connect, the EOL of Data Center, and Atlassian’s stated ambition to grow the enterprise business, is deeply counterproductive.

It creates a significant new attack surface across Atlassian tenants, through apps and first-party extensibility, and materially puts the Marketplace and ecosystem at risk.

Let’s be clear about the economics:

  • The Atlassian Marketplace generates $2B+ annually in gross app sales

  • There is an additional $1B+ in adjacent services revenue

  • For customers with 10,000+ users, enterprises spend more than $4 on apps for every $1 spent on Atlassian core products

Apps do not compete with Atlassian, they complete the platform. This is what differentiates Atlassian from competitors like Notion, Linear, or ServiceNow. Those platforms may offer comparable core products, but they lack a sufficiently powerful API or a mature enterprise ecosystem, which is why they fail to scale at the enterprise level.

The reality is simple: Enterprise customers require apps to make Atlassian viable at scale.

The Atlassian enterprise business was built by Marketplace and Solutions Partners through the years of Atlassian’s famous “no sales” PLG period. Partners solve edge cases Atlassian cannot and should not absorb into the core product. There is a clear force multiplier at work: for every Atlassian engineer, there are hundreds of Marketplace developers listening to customers, taking risks, and shipping faster. Limiting the API effectively limits Atlassian’s roadmap larger roadmap and ability to quickly service customers. The roadmap is not limited to what the internal product teams built but is inclusive of the innovations to the API which allow us to dream and build new capabilities and ship along side Atlassian..

This is not a criticism of Atlassian Product or Engineering. Atlassian built an exceptional core platform with extensibility as a first-class principle: through P2, Connect, and now Forge.

That extensibility is foundational to Atlassian’s success and kneecapping the API undermines that foundation.

Restrictive rate limits constrain app functionality, increase instability, and introduce compliance risk, potentially impacting SOC 2 and other enterprise frameworks. These limits are not merely a cost increase; they effectively eliminate the ability to build meaningful, enterprise-grade apps.

If enterprise-grade apps cannot exist, the Atlassian enterprise business does not exist.\

Atlassian should be careful not to repeat the mistakes of competitors. One of the most common enterprise objections to Notion is its inability to scale due to API and infrastructure constraints. This change risks putting Atlassian on a regression path to undoing all the amounts of investment prior engineering teams have worked on to scale the cloud business from the 2,000 user limit it started with.

This is not theoretical. It is existential: for the Marketplace, partners, and Atlassian’s enterprise growth strategy.

23

Hi,

This global cross tenant throttling really baffles me.

We are moving to ROA with our apps where possible. Once an app is ROA, there is basically no cross tenant communication possible, and we can’t even keep global app state.

How can a vendor even implement the point based rate limit and coordinate across tenants with ROA?

Just getting headers is not sufficient, because we must schedule our app requests across tenants, yet we can’t communicate across tenants.

24

@ChrisHemphill1 - I previously expressed concerns about ensuring the stability of the Atlassian Cloud ecosystem as we (Atlassian + partners/vendors) continue to support customers in highly regulated industries such as pharma, medtech, etc. My concerns were partially alleviated when Atlassian (slightly) softened the Forge migration timeline, but now this change announcement is far worse than anything I ever would have imagined. :scream:

The proposed Tier 1 “Global Pool” model raises an extreme concern for customers using Jira/Confluence in environments regulated by the US FDA, EU EMA, etc. If a single tenant of an app can exhaust a shared hourly quota and cause degraded or unavailable functionality for all other tenants (potentially for up to 60 minutes!!!), that introduces a form of cross-tenant coupling that those customers simply cannot accept.

In practical terms, this means:

  • Unpredictable outages in compliance-related activities: Customers might not be able to run tests, complete risk assessments, apply electronic signatures, or generate reports because another company consumed the hourly quota?!? Those are all common use cases that regulated customers rely on Marketplace apps for.

  • Unreliable controls in validated workflows: Nearly every regulated customer uses third-party extensions to configure Conditions and Validators in their Jira workflows. These extensions are used to enforce regulatory rules. What will happen if a customer initiates a bulk transition after the app’s hourly quota is consumed? Will the regulatory rules not be enforced?

  • No good mitigations: When any of the above scenarios happen, the customer will be required to initiate a Corrective Action / Preventive Action (CAPA) investigation. What is the corrective action here? What is the preventive action? What can customers do except to abandon the platform? (Which none of us want.) Customers have no recourse to make their environment stable.

For many companies, the risk alone may be enough to disqualify Atlassian Cloud as a viable platform and move somewhere else.

To be clear, I don’t believe this is coming from a lack of care or intent on Atlassian’s part. I understand the need to protect shared infrastructure and to evolve rate limiting in a way that reflects real system cost. But the Global Pool approach, as described, appears fundamentally incompatible with the expectations of regulated customers.

Given all the concerns raised so far related to cybersecurity, regulatory compliance, technical feasibility, and general fairness to customers, I strongly encourage Atlassian to abandon the Global Pool strategy. API quotas are necessary, but they can’t be global.

Thank you for listening, and I sincerely hope this thread becomes a dialogue with Atlassian, instead of just a long rant from us.

25

And one more thing: What about Isolated Cloud customers? I didn’t notice any description of how they will be handled. Will they consume points from the same global pool as everyone else?If so, they won’t be isolated anymore. Not functionally, anyway.

26

Correct it would be per app because we (the vendors) would be bearing the pool. However, if you are a significantly sized tenant relying on an app that is also used by other top teams (so if you are using an app with a high install count), you’re likely to experience outages of the app. Even if your team is only hammering our app at maybe 200 requests in an hour, if that app is used by 500 other well sized teams with higher request rates, say on a busy Tuesday, everyone with that app will experience downtime of the app. In some cases maybe it’s not critical and you can ask your team to sit it out for an hour, which is what the other admins are doing, so an hour later, y’all hammer and it shuts down again. OR it is mission critical like analytics, charts and diagrams, content classification systems, time tracking apps, etc. Well, those apps would be unable to document your changes or report. You’d be flying blind.

All Atlassian Admins for any team over 100 users should be equally concerned.

27

..and what about Government Cloud which actually is a different App ID? “Sorry NSA, you can’t use Jira for an hour, your app exceeded the limit, hopefully there’s no national security issues in the next hour.”

28

:100: percent agreed. The more technical folks in our community have clearly indicated this change – as currently understood by all of us in the ecosystem – could put many apps into Tier 1 and at worst immediately open a vector for trivial malicious DoS’ing of Marketplace Apps, and at best opens an avenue for frequent enterprise customer outages. As a vendor COO I can state it is difficult for us to plan ahead with Atlassian’s Marketplace (what the heck is happening to my baby?!?) in the future. It’s already been draining to file seemingly endless bugs and/or consistency feature requests across Forge and the platform app APIs, but this sort of change is also now rather threatening to our very business, all delivered without dialog, and without proper change notice. Why? It is dispiriting to deal with at best, and coming on the heels of the recent !IMpact session seems disingenuous.

I believe Content Retention Manager could well be in the same boat, as we constantly monitor state and lifecycle of MILLIONS of objects in larger instances. I concede that it is possible this change is rushed and ill-considered, needing more work in design and more shared goals with the platform team and the platform apps teams; or perhaps we are currently misunderstanding things and the effects we believe will happen won’t; but either way I strongly encourage and beg you quickly caucus internally and do some further risk analysis on both the technical and business aspects, @ChrisHemphill1, @AlanBraun and @asridhara.

Best regards, -nick wade
Co-founder & COO, Opus Guard (an Atlassian Ventures company)
ex-Atlassian and former Global Head of Ecosystem and Marketplace

29

From the doc for Jira rate limit: https://developer.atlassian.com/cloud/jira/platform/rate-limiting/#rate-limit-quotas-by-tiers

All quotas are measured in points per hour and reset at the top of each UTC hour.

This is going to cause a platform-wide outage on the first day of this proposal rolls out and hurt the platform it’s supposed to protect.

From the Jira Platform’s perspective, for example, a fixed UTC-hour rate-limit reset creates a global “starting gun.” At the top of every hour, all apps and all tenants simultaneously regain quota. With tens of thousands of apps installed across hundreds of thousands (or more) Jira sites, even very modest behavior - say a handful of API calls per tenant when quota becomes available - turns into an instant, synchronized surge. What would normally be spread across an hour collapses into a few seconds of traffic.

This spike is uniquely dangerous because it is perfectly aligned in time and globally repeatable. Jira’s APIs are not single lightweight operations: each request fans out into authentication, permission checks, rate-limit accounting, and downstream services like search and indexing. A sudden jump from “normal” traffic to hundreds of thousands or millions of requests per second can overwhelm thread pools and queues before autoscaling has time to react, causing latency spikes and partial failures even though every caller is technically within its allowed quota.

Once latency or throttling appears, the problem compounds. Clients that were waiting for the reset often retry immediately, amplifying the surge and creating a feedback loop at every hour boundary. From the platform’s view, the core issue is structural: a fixed UTC reset converts distributed, well-behaved client traffic into synchronized global load.

30

Hey everyone, while we wait for a bit more of a formal response from the product team on this I wanted to let you all know we very much ensured we considered Marketplace Program Partners in this policy. I know many of your concerns have been captured in our thought process already and we will continue to monitor and discuss those that we might not have caught. I will be watching this one closely and also feel free to slack me if you want to have a direct conversation. Thank you for all the feedback already.

31

Hi all, thanks for the detailed and thoughtful questions.

We will first address some common themes and then return to other individual questions in this thread.

We understand the question about why this doesn’t follow a longer changeover period. Over the past year, we’ve seen a significant increase in overall API usage, which drives important business outcomes. We have also observed an increase in policy violations that can affect the experience of all other apps in our ecosystem. Throughout last year, we have been adjusting our rate limits policy, and we have made a few announcements regarding the plan to introduce rate limits, as well as started selectively enforcing rate limits on some apps.

  • Along with introducing the point-based rate limits, our goal is to support a smooth transition for all apps and minimize impact. Based on our traffic analysis for the past year, ~95% of the apps never cross boundaries of the Global Pool; of those that did, we proactively moved qualifying apps to Tier 2. We don’t expect the vast majority of apps to experience any impact from this change.

  • We have been sending Shadow headers, to apps to notify them if they exceed the new rate limits. The updated quota-based rate-limited headers will clearly indicate which limits (Global or Per-Tenant) are being reached. Additionally, enforcement will be phased in gradually across different app cohorts starting. This approach enables us to closely monitor the rollout and minimize any potential impact.

Other themes in the questions.

Hourly accounting and burst behavior

The hourly quota is intended as an accounting boundary, not as a guarantee that an app will be unavailable for a full hour if a spike occurs.

  • The model will forgive occasional hourly spikes for the app; however, when the app consistently crosses the Global Pool thresholds, please explore optimizing API usage patterns. Additionally, please apply for the Tier 2 quota. We recognize that apps can experience short, high-intensity bursts, so that short-lived spikes don’t translate into prolonged service disruptions for all other tenants.

A design that results in hour-long lockouts for apps would not be acceptable, and this is one of the key scenarios we’re pressure-testing during this period before enforcement.

  • We are already sending shadow headers to inform you about whether your app is hitting rate limits. The developer console change, which lists app tiers, will go live next week.

Tier 2 escalation path

We have proactively reviewed and moved qualifying apps that require higher quotas than the Global Pool to Tier 2.

  • If your app consistently generates high traffic or you expect your usage patterns to increase and potentially exceed the threshold in the near future, we encourage you to contact us to review your app for Tier 2 quotas, which can help prevent any potential disruptions. The current escalation path for requesting additional capacity is via a support ticket in the Partner Portal. Increase Marketplace App Limits.
  • During an active review, the app will receive a grace period so that the app’s customers are not affected.

Our goal with this rollout is to ensure minimal impact on apps, with thresholds derived from existing traffic, and no immediate functional changes should be required for most apps. The only expected developer action is to observe the new rate-limit headers and ensure standard retry/backoff handling is done.

Thanks for flagging this - “ Each request must stay within the maximum…” In the current model, requests are evaluated only against the hourly quota. There is no independently configurable or enforced per-request cap that developers need to account for. We’ll update the documentation to remove or rephrase this wording to avoid confusion.

Thank you all for sharing your feedback and concerns regarding the upcoming point-based rate limits. We want to assure you that we are actively listening and taking your comments seriously. Our team is carefully reviewing your responses to ensure that we thoroughly address your questions and concerns.

Our goal with these changes is to create a fair, reliable, and scalable platform for everyone in the ecosystem. We recognize that updates to rate limits can raise important questions, and we are committed to working closely with our partners to ensure a smooth transition. You can expect thoughtful, timely responses from us as we continue this conversation together.

Link to the Quick Reference Guide: New points-based API rate limiting and tiered quotas for Jira & Confluence Cloud

32

Probably because the v2 Confluence API turned single requests into many multiple requests to fetch the same data.

Still trivial to DDoS the entire Marketplace.

33

As long as the quota is enforced, it’s not just an “accounting boundary” - it’s rate limiting. As I explained earlier in this thread, Atlassian’s own system will bear the consequences of this design choice, not just third-party apps.

34

Still trivial to DDoS the entire Marketplace.

And therefore the entire Atlassian platform. If a few critical apps go down, it renders Atlassian effectively down with workflows impacted, but it won’t show up on a status page report.

35

If this were true, we’d see an RFC with a period for comments as well as engagement from top marketplace partners and developers. We’re all a bit concerned that this dropped a week before Christmas and goes live without enough time for any of us to plan, provide feedback, or even give you sufficient time to hear us out.

Do you have any open forums planned with the top Marketplace Partners? (I’m not one of them, grab someone like @danielwester)

We can’t emphasize enough just how damaging this will be to not just Marketplace Apps but all of Atlassian.

Most end users don’t know the difference between a Marketplace app and Atlassian’s core product. This is by design. Additionally, many apps are mission critical at more than 65% of teams (I know these stats intimately). An app with thousands of installs that runs through a-sync jobs can easily hit the T2 global rate limits. They are simply insufficient. When our apps go down, it means Atlassian is down. End user workflows will be blocked, the outage won’t appear in Status Page unless you plan on extending every app’s API usage there. You’ll likely be slow to respond to customers complaining because you just won’t see it unless you turn on alerts for every app.

We accept the need for limits, but this method will be very damaging to apps and Atlassian.

We are asking for an extension of time and a true RFC/Forum for us to work on this with you.

36

For folks with access - session recording of Atlassian swooning MP & solution partners during Dec’25 !impact forum.

37

Thanks for your insights @Darin-L - couldn’t agree more. Atlassian only needs one shot to finish off MP, enterprise and then herself: Shoot down MP Apps and the domino pieces (not pizzas) start falling.

38

I’m going to assume that “announcing a massive change to how REST API works with a 52 day notice during holiday season through a change log entry, without prior consulting of partners” falls in the bucket of “might not have caught”.

It is completely Atlassian prerogative to nuke marketplace apps, and potentially nuke her own platform as a result of thundering herd, but at least have the decency to communicate properly about it.

Noblesse Oblige

39

“Expecting” is not enough. Changes of this magnitude should only happen with hard data backing them up - shared with partners, not kept internal.

Having a global pool for apps of any size is insane. The same quotas exist for apps with a few users and apps with thousands of users.

Given the lack of information provided to partners, I have to turn to good old math to calculate the impact, and it is ugly: 65,000 points/hour comes to ~1,000 points per minute. For a 1,000-user app (that’s a small one), this means fetching a single issue per minute per user. In what world does this work in real life?

One enterprise customer running a bulk operation exhausts the entire global pool. Result: every other customer locked out for up to an hour.

40

Based on our traffic analysis for the past year, ~95% of the apps never cross boundaries of the Global Pool; of those that did, we proactively moved qualifying apps to Tier 2. We don’t expect the vast majority of apps to experience any impact from this change.

Since the data exists I suggest you could notify the marketplace partners that will be impacted by these changes, for a better clarity.

We also suggest to implement some monitoring and notification like the cloud fortified ones so that developers can adjust and fix this kind of issues.

In connect apps we can still do this kind of monitoring but with forge it’s hard to monitor since we don’t have the logs.

+1 It would have helped if this was an RFC from the beginning.

41

What I find so puzzling about this proposal is that it allows an app with only one installation (potentially on a free-tier site) to hammer the API all day, whilst preventing successful apps with hundreds or thousands of customers on sites with tens of thousands of paying users from doing the most basic work.

The proposal essentially penalises successful apps, even though Atlassian are making millions of Dollars from the sites that the apps are installed on.

As others have said, a lot of customers would not be using the Atlassian tools if it wasn’t for the Marketplace apps that complete the solution for them.

It seems like a pretty risky strategy to me.