Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Getting Rate Limit For search API


I am getting ratelimit on hitting the endpoint `/rest/api/2/search`. In `x-ratelimit-limit ` header it's showing 600000. Not sure what this conveys. As we are not hitting 600000 requests. 

In our use-case we are hitting the `rest/api/2/search` endpoint with 2000 requests with a concurrency of 5. This process happens every 30mins

Need to know how many request can we make per minute or per hour or in concurrent?

1 answer

0 votes
Radek Dostál
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Mar 23, 2023

The beautiful part is that you don't need to know the limit, as long as you handle rate limit responses -

e.g. by setting a timeout for X seconds when you do hit rate limit, and then re-try the request; this is the most simple way to do it, albeit it's far from perfect since it can create "spikes" (ton of requests hit at once, then timeout, then hit Jira with another brick later). Personally, if I know I'm about to end up doing a lot of requests, I implement my own "rate limit" within the script to only send X amount of requests per second. That way, I do my best not to hit the rate limit cap at all, but if I do then I let it sleep for a few seconds before picking up again.

Concurrency of course complicates that quite a bit, but same principle.

If you're on Cloud there really doesn't seem to be a limit judging by and, but you should still consider not doing so many requests all at once since it very well could cause an outage by consuming too many resources for all of the users.

I'm not sure what it is that you're doing, but sending 2000 requests for a jql search does not sound like an optimal approach, more of a brute force one, especially if you intend on doing that every 30 minutes. This is far beyond too much to be considered a good approach.

I can tell you that if I saw someone doing this many requests on our on-premise data centers, I'd disable that account and send the owner a heart-warming letter asking them to fix their malfunctioning scripts (well they would be rate limited in the first place, but that letter still goes out).

If it's synchronous, 5 requests at once (waiting for response), that's probably going to be fine, but if you do all of that asynchronously then that's a problem for sure.

Imagine what would happen if there was another team doing the same thing, or if there were multiple - that would definitely be an issue, so your implementation, while it could work alone, is very inefficient and not scalable in grand scheme of things.

2000 / 30 => 66.6 requests per minute you need to do to finish before the next cycle. So say roughly 1.1 request/second; so yeah that can be throttled to avoid causing spikes, assuming, say, 5 requests per second, so each thread doing 1 req / 1 sec max you get to 5req/1s => 400 seconds => done in 6.6 minutes with plenty buffer in case of slow responses

Still, bad approach, it's kind of brute forcing something.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events