Zephyr Scale: Too Many Requests error after adhering to Retry-After: 60

Adam Todd

Recently, all the post requests going to Zephyr Scale are returning a 429 Too Many Requests error. The Retry-After states 60, which interprets as 60 seconds. After putting in a 60 second pause when this error is triggered and retrying the post, the error still occurs. This issue wasn't happening prior to 5/27/26 with the same post requests at the same interval. The post is in reference to creating a test execution onto Zephyr Scale.

 

HTTP/1.1 429 Too Many Requests [Date: Wed, 27 May 2026 17:23:14 GMT, Content-Type: application/json, Content-Length: 81, Connection: keep-alive, Server: awselb/2.0, Retry-After: 60, Via: HTTP/1.1 m_proxy_prod_aws_us-east-1_1_1n, X-Amz-Cf-Pop: IAD55-P2, X-Amz-Cf-Id: gVutaZyFhexaGL8SX4IDUTMJXrX_Lq84grI9QfLNx897Aa5vr1q2-A==] org.apache.http.conn.BasicManagedEntity@712594f4

Germán Morales

Hi @Adam Todd, a few things stand out from the headers you shared.

The Server: awselb/2.0 and the CloudFront headers confirm this 429 is coming from Zephyr Scale's own infrastructure, not from the Jira Cloud rate limiter. These are separate systems with separate limits.

The fact that waiting 60 seconds (as Retry-After suggests) doesn't clear it usually means one of two things:

• The rate limit is based on a sliding window (e.g., X requests per hour), not a per-request cooldown. Waiting 60 seconds resets the short timer but you're still over the window quota. If your integration runs multiple test execution POSTs in a batch, you may be exhausting the hourly allowance before the first retry even fires.
• Something changed on Zephyr Scale's side today (5/27). If the same requests at the same interval worked yesterday and don't today, that points to either a rate limit policy change or a service-side issue, not your code.

Since Zephyr Scale is managed by SmartBear (not Atlassian directly), Atlassian Support won't have visibility into these 429s. You'll need to open a ticket through SmartBear's support channel for Zephyr Scale. Include the X-Amz-Cf-Id from a failing response, that's their trace ID for CloudFront.

In the meantime, check if you have parallel workers or CI pipelines hitting the same endpoint concurrently. The rate limit is typically per API token across all connections, not per individual request.