In Jira Cloud we use rate limiting for REST API to protect our customers’ sites (aka tenants) resources. Current implementation isn’t based on REST API consumer, it is based on concurrent requests made across all consumers of single tenant - consider tenant users, your App and other Apps accessing the infrastructure. Thus it is a challenge to provide meaningful, guaranteed information for consumer in response headers (e.g. Retry-After), such information could be seen only as a suggestion.
In case of implementing retries please be advised of using back-off mechanism to lower retry frequency on subsequent failed attempts and increase traffic gradually on a success. Concurrency based limiting is more visible for longer requests so the rule of thumb would be the longer request is the lower concurrency should be used.
We are actively working on per consumer rate limiting which should help us provide meaningful information in response headers. We expect it to be delivered in couple of quarters.
Is it possible that dev instances have higher API rates than customer sites?
I am trying to reproduce what happens if our app reaches limit for various endpoints, but so far I can’t reach the limit. E.g. 400 simultaneous requests for rest/api/2/project/{projectId}/properties/{configurationPropertyKey}
@maciej.dudziak, I’m not sure what you mean as a dev instance but I assume this is an additional instance created for you in our production environment. There should be no special differences between your dev instance and customer instance. If you are in doubt please open an issue on Atlassian Ecosystem Developer Service Desk.
WRT your tests please take into account that on the customer instance there is an additional traffic caused by customer’s users which might be unknown to you thus hard to reproduce in your tests.
Hi @czawadka - Trying to determine any risks to implementing to using the Cloud API (expected ~10 calls per day) but from this comment, I understand that this is based on tenant rather than user/token. Is there a way to determine the number of calls are being made across the entire tenant (over time, to determine if the limit has ever been hit), or how close it is to the rate limit?
As noted in the guide, Atlassian currently does not support testing of rate limiting. For this reason, I’ve create [ACJIRA-2254] - Ecosystem Jira to providing this support.
@dmorrow Thank you for the guide and creating the two issues to track this!
Is there any further guidance on the enforced rate limits for JIRAs API at this time? We at Rewind are considering backing up JIRA Software instances, and would like to get an idea of the limits of the API before we begin.
There’s no further guidance at present. I believe the Jira team are making improvements, but I don’t think these improvements are aimed at resolving ACJIRA-2254 and ACJIRA-2255.
To summarize, lets start with this statement in the docs:
The implementation of rate limiting is centered around tracking the cost of processing requests against various cost budgets.
This is another way of saying the rate limits are not a fixed number, but dynamic depending on some opaque measures of computing cost on the back-end. As a result, clients should pay attention to rate limiting headers and use a request backoff strategy.
We are aware this is not ideal for clients. While we do want to make improvements, as of writing this post no work has been scheduled nor any releases imminent. As such, I’m locking this thread to avoid further confusion. Since opaque limits may lead to further questions, please start a new thread and follow the advice on: