Currently in JIRA API there is a rule is to serve 50 concurrent requests, if 51 requests are received, it will drop with a HTTP 429 status.

It would be nice if this level could be raised, or another workaround provided.

Update:
When the REST API is being rate-limited, it now provides headers with information that allows implementing a back-off logic. In addition, the number of requests each endpoint can receive before being rate limited is dynamic., From Rate limiting:

429 responses may be accompanied by Retry-After and X-RateLimit-Reset headers.

Retry-After indicates how many seconds the app must wait before reissuing the request. If you reissue the request before the retry period expires, the request will fail and return the same or longer Retry-After period.

X-RateLimit-Reset This header provides the timestamp (in ISO 8601 format) when the rate limit will reset, calculated as the request timestamp plus the Retry-After period. It's provided in the format: yyyy-MM-ddTHH:mmZ.

Some transient 5XX errors are accompanied by a Retry-After header. For example, a 503 response may be returned when a resource limit has been reached. While these are not rate limit responses, they can be handled with similar logic as outlined below.

Other header responses include:

• X-RateLimit-Limit: This header specifies the maximum number of requests that a user can make within a specific time window.

• X-RateLimit-Remaining: This header shows the number of requests remaining in the current rate limit window before the limit is reached.

• RateLimit-Reason: This header indicates the reason the request was declined. Possible values:

• • jira-cost-based, which refers to counter and cost based limits being breached

• • jira-quota-based, which refers to API rate limits being breached

• X-RateLimit-NearLimit: When true, indicates that less than 20% of any budget remains. This is a boolean value added to a successful response.

Request backoff

Apps should treat 429 responses as a signal to alleviate pressure on an endpoint. Apps should retry the request only after a delay. Best practice to double the delay after each successive 429 response from a given endpoint. Backoff delays only need to exponentially increase to a maximum value at which point the retries can continue with the fixed maximum delay. You should also apply jitter to the delays to avoid the thundering herd problem.

The following articles provide useful insights and techniques related to retry and backoff processing:

• Exponential backoff article in Wikipedia
• Error retries and exponential backoff in AWS.