I'm not able to get retry-after header on getting 429

[Lalit Kumar]

As mentioned above picture, I should get these headers in response when I receive 429, but I'm not getting these headers.

Here are the status code and response headers that I'm getting:

429
{
server: 'AtlassianProxy/1.15.8.1',
vary: 'Accept-Encoding',
'content-type': 'text/html;charset=ISO-8859-1',
'strict-transport-security': 'max-age=315360000; includeSubDomains; preload',
date: 'Tue, 06 Apr 2021 12:03:12 GMT',
'atl-traceid': 'caa2c0619953d843',
'x-xss-protection': '1; mode=block',
'x-envoy-upstream-service-time': '15',
'x-content-type-options': 'nosniff',
connection: 'close',
'expect-ct': 'report-uri="https://web-security-reports.services.atlassian.com/expect-ct-report/global-proxy", enforce, max-age=86400',
'content-length': '1922'
}

[Andy Heinzer]

Hi @Lalit Kumar 

Sorry to hear about this problem.  However I believe that the documentation you are referring to here is for our Jira Server/Data Center editions as seen in https://confluence.atlassian.com/adminjiraserver/improving-instance-stability-with-rate-limiting-983794911.html

However this Community posts makes it appear that you might be using Jira Cloud instead. For Jira Cloud, we have documented the rate limit behavior a little differently over in https://developer.atlassian.com/cloud/jira/platform/rate-limiting/ in that page the exact wording is

Retry-After headers

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 indicates the date time when you can retry the request. 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.

As such, not all the same headers are included in the Cloud REST response and not all 429 responses will include a retry-after in the response Cloud. 

The rate limiting in Cloud is continuously evolving based on numerous factors.  Hence you are not as likely to get this specific header in Cloud as you might get back from a Server/Data Center edition.  Instead our Cloud rate limiting documentation suggests applying a jitter to the delay and using an exponential backoff strategy if you are creating an app to make such REST API calls.

I hope this helps.

Andy