I can find some articles about other products (API request limits | Bitbucket Cloud | Atlassian Support) but not for JIRA Cloud.
Update - I suppose I’m looking for an update to https://community.atlassian.com/t5/Answers-Developer-Questions/Atlassian-connect-rate-of-requests-limit/qaq-p/479325
Update - I see that the ACT_AS_USER method has a published rate limit - but I’m looking for the answer for making calls as the add-on user OAuth 2.0 - JWT bearer token authorization grant type
There are no rate limits on requests to JIRA Cloud REST API resources right now, although we do actively monitor for situations where requests are detrimental to JIRA performance.
It is highly likely that we will introduce some kind of rate limiting for JIRA in the future.
Hi Dave, we’d like to be good REST API citizens and rate limit our requests to JIRA instances.
Can you give us any hints towards a sensible rate limit we should use until Atlassian implement one? Or how many concurrent requests our add-on should be making to any given Jira instance?
Hi Jon,
Thanks for future thinking! It is always better to have some rate limiting on client side than having none.
Rate limits on Atlassian side haven’t been implemented yet so it is unproven what values should play well. However our feeling is it would be safe to have 5 simultaneous request from web browser and 10 from backend.
Our infrastructure might handle higher load but from time to time we might be unable to process all requests. Please be prepared for receiving errors.
Are there any rate limits on the cloud-dev environments?
Hi @john.hill,
Currently cloud-dev environments are identical to regular customer sites except for the user limit.
Dave
Are Jira Cloud REST APIs still not rate limited? I see in my logs that I get some HTTP 429 responses for some customers calling GET /rest/api/2/project/{projectIdOrKey}/properties/{propertyKey}.
Or is this part of the errors we should be prepared for that @czawadka mentioned?
Yes, I’m seeing those 429 responses on GET requests in relation to project properties. I’d like to understand that limits that apply now.
@dmeyer or anyone else from Atlassian do you have an update on this? I see more and more 429 errors in my logs and it’s kind of important to know how to deal with these.
Hi all!
There is already a rate limiting mechanism in place to protect customers instances, to keep then usable. The mechanism is used for all endpoints including REST APIs. Our Jira SREs try to tune them to not harm our customers. There might be some situations when SREs need to change standard thresholds which results with visible or increased number of 429 responses.
We are still working on finding the best mechanism/thresholds so we are not able to provide any rules which would be valid for a longer period of time.
In cases of seeing 429 responses I would recommend postponing and replying requests at lower rate if possible.
If you already return 429 responses then I suggest that also a Retry-After header is included indicating how long to wait before making a new request. See 429 Too Many Requests - HTTP | MDN
Some other applications that eazyBI uses as a data source already provide this header and we respect that and wait the specified number of seconds.
Raimonds
If there are rate limits, please document them. We need to know how to handle our traffic BEFORE it hits the limits. If it hits the limits then our add-on will become unusable and will result in a bad user experience.
@czawadka Totally agree with @raimonds.simanovskis point, getting a hint from the server on when it is okay to retry is very important for clients. Otherwise, implementing any kind of retry mechanism is more like a guessing game.
(I didn’t check if there is already such a header, but it’s kind of difficult to replicate 429 errors. This needs documentation)
I checked in our logs that when we sometimes receive the error 429 then we currently do not receive the Retry-After header from Jira Cloud sites.
Is it a rate limit per addon or is it just for the whole instance? It’s important to know because we are asked by customers if we are overloading their instances.
They also ask for improved performance which means increasing the rate of requests. If one addon bombards Jira with requests all others are suffering. Clients think that our addon is slow in such case.
@czawadka, @daniel2 is totally right. Even if you cannot share limits right now, please at least tell us if the limits are for the whole add-on or if every instance of our add-on has its own limits ?
So we need to know if one of our add-on’s customers overwhelms the limits, will that affect the rest of the users of our add-on ?
Thank you
As of now, by default rate limiting is per tenant per endpoint and it doesn’t matter if it is Jira UI, app, integration or custom script using an endpoint. Additionally to that Jira SREs have mechanisms which may reduce load in case of anomalies but this is a manual process and is not triggered automatically.
In other words, by default we do not rate limit individual apps.
Dear @czawadka, if our add-on is making requests towards an endpoint, isn’t it considered a tenant?
Then it will be rate limited, based on your comments.
Can you please clarify ?
Thank you!
@k.tsourapas I should have been more clear with the meaning of “tenant” which is defined as a single customer site.
According to your question if the app hits endpoints too frequently it might get 429 responses. Though this is not for limiting the single app but to protect the customer site.
Dear @czawadka,
Does the Atlassian team plan to provide documentations about Rate Limit ?
Or do we have any ways to get retry-after or X-Ratelimit-Remaining header like hipchat? (ref: hipchat-rest-api-rate-limit)