In Jira Cloud we use rate limiting for REST API to protect our customers' sites (aka tenants) resources. Current implementation isn’t based on REST API consumer, it is based on concurrent requests made across all consumers of single tenant - consider tenant users, your App and other Apps accessing the infrastructure. Thus it is a challenge to provide meaningful, guaranteed information for consumer in response headers (e.g. Retry-After), such information could be seen only as a suggestion.
In case of implementing retries please be advised of using back-off mechanism to lower retry frequency on subsequent failed attempts and increase traffic gradually on a success. Concurrency based limiting is more visible for longer requests so the rule of thumb would be the longer request is the lower concurrency should be used.
We are actively working on per consumer rate limiting which should help us provide meaningful information in response headers. We expect it to be delivered in couple of quarters.
With regard to this issue we’ll fix it by not returning 500 and provide suggestion (as described above) when retry may happen.