Rate Limiting coming to Jira Data Center 8.6

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-Limit is the maximum number of tokens a user can have.
  • X-RateLimiting-Remaining is the remaining number of tokens.
  • X-RateLimiting-Interval-Seconds is the time interval, in seconds. Tokens are replenished every time interval.
  • X-RateLimiting-FillRate is 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.

Thank you,
Grazyna Kaszkur
Product Manager for Jira Data Center

1 Like

From the other thread:

For the rate limiting feature - Is there a rest api where I could perhaps could make a request to in order to identify what my behavior should be (just do 1 request every 10 seconds or slow down to 1 request every 30 seconds due to the capability of the user)? I know I can use the headers - but that’s going to be useful afterwards

From the logs - how can I determine when rate limiting has hit? I’m trying to avoid me going “oh you’ve got 8.6 installed and are having issues - can you disable rate limiting?” (which I think nobody wants)

So, are all REST API calls affected, or only requests with specific characteristics (without special header, or something like that)?
How REST API calls triggered by user interaction in Jira are different from external REST API calls?

1 Like

Hi @a.belostotskiy, we will be relying on standard ways browsers decorate requests with request headers. This way we can tell which REST API calls come from the browser.

This is not to prevent from hacking the system, but rather to allow Rate Limiting to kick in for integrations that are under the customers’ control. And Rate Limiting can be used to, well, limit the rate at which these integrations call Jira APIs.

@danielwester , thank you for your questions.

You will not need to call any API. All requests, even those that do not end in HTTP code 429, but have been successfully processed will contain the response headers. What is your opinion on this? How would using a dedicated API be more convenient than information you can track with every request?

When Rate Limiting is hit, users are listed in the Rate Limiting UI, which lists users being limited, along with the time of last limited request. As to precise log statements allow me to check in with the team.

In my case I have an app that hits the search rest api in order to generate a report. Rather than dynamically adjusting my requests (and having to show the end user “you’re being limited by the the adminstrator” message. If I can hit a rest api to query the current configuration ahead of time (ie there’s no way I can generate the report right now - please wait 10mins or talk to your administrator) it would be great.

That said - having a log entry would help us with our support cases - telling people to look in the ui is good for confirmation and diagnosis but can be quite expensive/difficult for us to target in a support case.

So just to be clear. If I’m a p2 app that has loaded through jira and hits the /rest api - I’m not blocked by the rate limiting?

Hi @danielwester, I understand how logs will be helpful. I will return with the final shape of the logs once the team stops changing them :slight_smile:

About the dedicated API to retrieve the logging information - every request carries that information. If you want to test your limit ahead of time - make any request, or just the first request from the batch you’re planning to send, and reason from there. That said, dynamically tracking the remaining amount would allow your system to adapt to other sources of draining the limit - your process might not be the only one making requests on behalf of the same user.

And, by the description, it seems your P2 plugin is making requests from the browser to the backend - this kind of traffic should not be limited at all, so there should be nothing to worry about.


@gkaszkur my Server/DC App provides a REST API itself. Is there any way to implement the RateLimit behaviour for my app’s REST API Endpoints?
And please do not add RateLimits ever on your Java APIs. Make them paginable/streamable and implement caching on your side. But please do not do this. This will make an App developers live really really hard.
I would rather suggest you provide an API to also use the RateLimit thing inside an App to also secure it.


we would like to inform you that the EAP2 for Jira 8.6 is available for download and testing.

When it comes to Rate limiting functionality we have extended the information about users who have been rate limited in the Jira log file. More details on using the log file you will find here.
Moreover as mentioned before, we have added the 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.

If you have any feedback or questions, please let us know.

Thank you,
Grazyna Kaszkur
Product Manager for Jira Data Center

@clouless thank you for your questions. Your REST endpoints will be automatically protected and no actions are necessary from your end. Currently there is no way to opt-out of the REST API rate limiting behaviour.

When it comes to rate limiting Java APIs, we are aware of the impact it might cause on the app developers and the Atlassian Marketplace. Before taking any actions in this area in the future we will gather feedback first. Thus, thank you so much for your suggestions of the possible solutions.



Santa’s gone, Christmas is coming, and Rate limiting is already out the door with Jira DC 8.6. Just wanted to let you know that we’ve updated our docs with some more info on what requests are limited, how rate limiting works with other Atlassian products, and how it affects apps from Atlassian Marketplace.

You can find the docs here: https://confluence.atlassian.com/display/ADMINJIRASERVER/Improving+instance+stability+with+rate+limiting

Also, we’ve created a set of strategies on how to make your code (scripts, integrations, apps) work smoothly with rate limiting: https://confluence.atlassian.com/display/ADMINJIRASERVER/Adjusting+your+code+to+rate+limiting

I may repeat @danielwester question, but it is not clear to me. Is rate limiting affecting P2 apps? If my app calls rest API from frontend, e.g. using jQuery.ajax. Should I as a vendor of the app worry?

1 Like

no worries :slight_smile: . “JS-Frontend” calls use the existing session cookie for authentication and are not rate limited.
Only if you use an external client such as CURL that uses e.g. BasicAuth you will have limits.


It might be the case that we figured out a way to circumvent the rate limiting - or maybe we don’t fully understand how it’s supposed to work. The rate limiting docs say the rate limiting is applied to requests using Basic Auth, OAuth and JSESSIONID cookie:

[…] we’re targeting external HTTP requests with these authentication mechanisms:

  • Basic auth
  • OAuth
  • JSESSIONID cookie

However, when I use Jira 8.6.0 and enable rate limiting and select “limit requests” to 1 request per 1 minute per user, I can do the following:

  1. Send a request using Basic Authentication -> this is the request I’m allowed to do
  2. Retrieve the JSESSIONID from the response
  3. Use the JSESSIONID for further requests without sending Basic Authentication -> these requests are not rate limited at all, I can send as many requests as I like.

What is the expected behavior here? I would say you also want to limit these requests because the rate limiting should be applied per user, independently of the authentication mechanism. But with the current implementation you can circumvent the rate limiting. Or do we misunderstand anything?

Hi @shesse .
thank you for your feedback. The first version of Rate Limiting functionality was designed as a tool to protect the system from accidental overload from integrations willing to comply with its rules. Its goal was not to offer an impenetrable barrier against all traffic not originating from Jira UI. For the requests accidentally or intentionally crafted to resemble the ones generated by the UI, the heuristics of classifying traffic as applicable for rate limiting may result in false negatives.

Having stated that, we see a few possible reasons for the case you’ve described:

  1. the requests you’ve sent during your tests accidentally contained some characteristics which caused qualifying them as UI(for example, some REST clients like Postman sometimes add additional headers to their requests)
  2. the request targeted one of whitelisted internal rest endpoints without any practical use for integrations
  3. there’s some actual bug in rate limiting.

To have 100% certainty we would need to see more details about the requests, especially their headers and target endpoints. Would it be possible to share with us more details? Either in this thread or via email: jreczycki@atlassian.com Thank you.

For the record: after offline discussion with @shesse (Thank you again for your detailed case study) this case is now tracked under https://jira.atlassian.com/browse/JRASERVER-70560. If you will encounter any simillar behaviour, please leave us a comment there.

Could you please post here what the eventual retry-after header will/does look like? For example, in this thread we have X-RateLimiting-Limit, so would the new header look like X-RateLimiting-Retry-After? Or is it simply retry-after?