Are there rate limits for JIRA Cloud APIs?

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

4 Likes

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.

1 Like

@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.

1 Like

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)

Hi everyone,

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.

4 Likes

Hi @czawadka

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.

I mean an instance created via Sign up - Try Atlassian Cloud | Atlassian

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?

Thanks!

Thanks for your thoughts on Jira rate limits. A guide has now been published to help provide clarity: https://developer.atlassian.com/cloud/jira/platform/rate-limiting/

3 Likes

This is really good news!! Thank you! finally!!

1 Like

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.

I’ve also created ACJIRA-2255 since having rate limits will make it easier to develop against.

2 Likes

@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.

Any help here would be appreciated!

Thanks,

Danny