I hope the Atlassian team recognizes that the point accrual for the get permissions API is broken and fixes it ASAP. If an app can only check permissions 30 times in an hour (and less for larger customers with more users) that is a full blocker. Especially when the Atlassian security profile requires permissions to be re-checked for any backend processing.
Chris
More disturbing behavior observed. See below logs and inline comments
# Normal response with expected behavior
2026-03-26 16:24:52.503 DEBUG org.apache.http.headers - http-outgoing-65 << Beta-Ratelimit-Policy: "tenant-app-quota";q=100100;w=3600
2026-03-26 16:24:52.503 DEBUG org.apache.http.headers - http-outgoing-65 << Beta-Ratelimit: "tenant-app-quota";r=17842;t=2107
2026-03-26 16:24:52.503 DEBUG org.apache.http.headers - http-outgoing-65 << X-Beta-Ratelimit-Reason: jira-quota-tenant-based
2026-03-26 16:24:52.503 DEBUG org.apache.http.headers - http-outgoing-65 << X-Beta-Ratelimit-Nearlimit: true
2026-03-26 16:24:52.503 DEBUG org.apache.http.headers - http-outgoing-65 << X-Ratelimit-Limit: 350
2026-03-26 16:24:52.503 DEBUG org.apache.http.headers - http-outgoing-65 << X-Ratelimit-Remaining: 349
# Quota now reached (r=0)
# issue #1 no more Ratelimit-Policy header received to know total quota and window attributes
# issue #2 the t in Ratelimit is completely off it should be 20XX instead of 27XX
2026-03-26 16:25:28.490 DEBUG org.apache.http.headers - http-outgoing-66 << Beta-Ratelimit: "tenant-app-quota";r=0;t=2788
2026-03-26 16:25:28.490 DEBUG org.apache.http.headers - http-outgoing-66 << X-Beta-Ratelimit-Reason: jira-quota-tenant-based
2026-03-26 16:25:28.490 DEBUG org.apache.http.headers - http-outgoing-66 << X-Beta-Ratelimit-Reset: 2026-03-26T16:00Z
2026-03-26 16:25:28.490 DEBUG org.apache.http.headers - http-outgoing-66 << X-Ratelimit-Limit: 400
2026-03-26 16:25:28.490 DEBUG org.apache.http.headers - http-outgoing-66 << X-Ratelimit-Remaining: 399
#Quota still reached, t still bogus
2026-03-26 16:25:29.914 DEBUG org.apache.http.headers - http-outgoing-67 << Beta-Ratelimit: "tenant-app-quota";r=0;t=2352
2026-03-26 16:25:29.914 DEBUG org.apache.http.headers - http-outgoing-67 << X-Beta-Ratelimit-Reason: jira-quota-tenant-based
2026-03-26 16:25:29.914 DEBUG org.apache.http.headers - http-outgoing-67 << X-Beta-Ratelimit-Reset: 2026-03-26T16:00Z
2026-03-26 16:25:29.914 DEBUG org.apache.http.headers - http-outgoing-67 << X-Ratelimit-Limit: 200
2026-03-26 16:25:29.914 DEBUG org.apache.http.headers - http-outgoing-67 << X-Ratelimit-Remaining: 199
#Quota still reached, t still bogus
2026-03-26 16:25:30.149 DEBUG org.apache.http.headers - http-outgoing-68 << Beta-Ratelimit: "tenant-app-quota";r=0;t=2521
2026-03-26 16:25:30.149 DEBUG org.apache.http.headers - http-outgoing-68 << X-Beta-Ratelimit-Reason: jira-quota-tenant-based
2026-03-26 16:25:30.149 DEBUG org.apache.http.headers - http-outgoing-68 << X-Beta-Ratelimit-Reset: 2026-03-26T16:00Z
2026-03-26 16:25:30.149 DEBUG org.apache.http.headers - http-outgoing-68 << X-Ratelimit-Limit: 350
2026-03-26 16:25:30.149 DEBUG org.apache.http.headers - http-outgoing-68 << X-Ratelimit-Remaining: 349
#Another quota usage, reporting the right t (32*60 = 1920 + 47)
2026-03-26 16:27:12.396 DEBUG org.apache.http.headers - http-outgoing-69 << Beta-Ratelimit-Policy: "global-app-quota";q=65000;w=3600
2026-03-26 16:27:12.396 DEBUG org.apache.http.headers - http-outgoing-69 << Beta-Ratelimit: "global-app-quota";t=1967
2026-03-26 16:27:12.396 DEBUG org.apache.http.headers - http-outgoing-69 << X-Ratelimit-Limit: 350
2026-03-26 16:27:12.396 DEBUG org.apache.http.headers - http-outgoing-69 << X-Ratelimit-Remaining: 349
#Quota reached used again, eventually t is a bit closer to the right value but still off
2026-03-26 16:52:50.620 DEBUG org.apache.http.headers - http-outgoing-72 << Beta-Ratelimit: "tenant-app-quota";r=0;t=510
2026-03-26 16:52:50.620 DEBUG org.apache.http.headers - http-outgoing-72 << X-Beta-Ratelimit-Reason: jira-quota-tenant-based
2026-03-26 16:52:50.620 DEBUG org.apache.http.headers - http-outgoing-72 << X-Beta-Ratelimit-Reset: 2026-03-26T16:00Z
2026-03-26 16:52:50.620 DEBUG org.apache.http.headers - http-outgoing-72 << X-Ratelimit-Limit: 400
I’m going to focus on these two issues observed when the quota is reached
# issue #1 no more Ratelimit-Policy header received to know total quota and window attributes
# issue #2 the t in Ratelimit is completely off it should be 20XX instead of 27XX
I could see #1 being an expected behavior just not documented, however the #2 must clearly be a bug
Hi everyone,
I was trying to implement backoff strategy for Forge SQL 429 rate limit errors but I could not find any Retry-After header in the response:
function SQL Error Details: [“{"message": "Limits for the current installation have been exceeded","name": "ForgeSQLError","responseDetails": {"status": 429,"statusText": "Too Many Requests","traceId": null},"code": "RATE_LIMIT_EXCEEDED","context": {}}”]
In Atlassian documentation, it is mentionned that Retry-After headers are going to be returned with responses which would be rate limited at enforcement. Since I do not see them in the Forge SQL response - does that mean that Retry-After header is implemented only on the standard REST API endpoints? If that is the case - how are we suppose to handle rate limits using Retry-After in Async API?
We are starting to see undocumented rate limit reasons in our log, which is quite unfortunate, since we cannot possibly observe our log files for undocumented, new rate-limits each day. Could you please update the documentation to include all possible rate-limits that are now in effect? We were promised this would have no effect on most apps, but now they start popping up left and right without any changes to our usage patterns.
jira-max-concurrent-threads-across-all-instances-per-tenant-per-user
Hi @BurakAKTEPE
We confirmed that Forge front-end traffic is exempted. Could you please re-run the same test when you get a chance? We want to make sure that it is resolved for you as well. If you are still seeing the same behavior, please open an ECOHELP ticket, and we will debug this with you.
I just saw that one of the Jira API returned jira-cost-based as the rate limit reason. Just one example of undocumented reason.
Also I get some inconsistant structure of the response:
"rawHeaders":{
"Beta-RateLimit":"\"global-app-quota\";r=0;t=3141",
"Beta-Retry-After":"3141",
"X-RateLimit-Limit":"600000",
"X-RateLimit-Remaining":"0",
"X-RateLimit-Reset":"2026-04-09T13:15Z",
"RateLimit-Reason":"jira-cost-based",
"Retry-After":"89",
},
Problems:
Atlassian: “new global pool limit for rate limiting”
Also Atlassian:
This incident has been going on for more than 14 hours as of writing: Atlassian Developer Status - Some Forge apps experiencing increased Jira API rate limiting errors (429)
In an ideal world, I would love to see a post-incident analysis.
I checked our logs and noticed that 429s with FAILURE_CLIENT_RATE_LIMITED first appeared for us around 2026-04-15.
I hope this can be resolved as quickly as possible, and I would also like to see a post-incident report to provide some more clarity.
I can imagine the investigating team meticulously tracing the root cause with the logical assumption that all rate limit polices are per-tenant, only to hilariously discover the global pool model.
This is the quality of recent engineering decisions on rate limits:
What is going on?
@MaheshPopudesi any post-incident report on that: Atlassian Developer Status - Some Forge apps experiencing increased Jira API rate limiting errors (429)
Over 33 hours to resolution. What happened?
Hi everyone — following this thread closely as a Marketplace partner building in this space.
To those asking about visibility into live points consumption: we’ve been working on exactly this problem. Our app QuotaWatch (available on the Marketplace) monitors Jira REST API quota consumption in real time and surfaces threshold alerts before a 429 breach — the specific scenario many of you have described here.
It reads the Beta-RateLimit and X-RateLimit-* response headers directly, so it works with the existing shadow header infrastructure Atlassian is already sending. No additional API permissions required.
Happy to answer questions about how it handles the per-tenant breakdown use case if that’s useful to anyone in this thread. We’re also actively watching this discussion to understand what else admins and developers need as enforcement beds in.
Hi @MeghnaPatankar – Congrats on publishing a new app.
One thing to double-check: The Tier 1 Global Pool is scoped per app, not per site. The docs define global-app-quota (Tier 1) as:
A quota applied to your app globally across all tenants
So the rate-limit headers report an app’s own consumption pooled across every site (tenant) it’s installed on, not the customer’s combined usage across all the other apps on their site.
My app is seemingly still not enrolled as I’m still seeing the Beta prefix in the headers
2026-07-22 08:33:13.189 Beta-Ratelimit-Policy: “tenant-app-quota”;q=480000;w=3600
2026-07-22 08:33:13.189 Beta-Ratelimit: “tenant-app-quota”;t=1606
Has there been any communication about the status of this Feature rollout? Is it expected to take so long for the feature to be activated globally?