Dear app developers,
As we announced at Summit this year, we’re planning to ship Rate limiting for Jira Data Center in Jira 8.6.
Rate limiting allows Jira to self-protect against automated integrations or scripts that send requests to Jira in huge bursts, affecting stability and performance. It keeps Jira stable by giving admins control over how many requests automations and users can make, and how often they can make them. You can read more about how it works here.
How Rate limiting can impact you?
At first, we’re planning to limit only REST APIs. We’re not limiting JAVA APIs or requests coming from the interaction with the UI.
Rate limiting is using the token bucket algorithm, in which users are given a certain number of tokens that can be exchanged for requests. After making a request, you’ll see information about your tokens and limits in the HTTP response headers:
X-RateLimiting-Limitis the maximum number of tokens a user can have.
X-RateLimiting-Remainingis the remaining number of tokens.
X-RateLimiting-Interval-Secondsis the time interval, in seconds. Tokens are replenished every time interval.
X-RateLimiting-FillRateis the number of tokens replenished every time interval.
The above will let the integrations reason about and adapt to the rate limiting settings.
How will I know that I was rate limited?
The server will return an HTTP error code 429 (too many requests) in the response. In the next EAP for Jira 8.6, we’re planning to add
retry-after in the HTTP response headers. The
retry-after header will specify the number of seconds you need to wait before you can make new requests.
Testing Rate limiting
We wanted to give you more details about Rate limiting, so you can test it with your apps. The first version of this feature is available to test in the EAP 1 for Jira 8.6.
If you have any feedback or questions, please leave a comment under this post.
Product Manager for Jira Data Center