Read the response and operation
HTTP 429 generally indicates that a client has exceeded a rate limit. HTTP 503 indicates that a service is temporarily unavailable. Both can include Retry-After, but provider behavior and limits vary. Record the response code, request ID and relevant rate-limit headers without logging tokens or personal data.
Before retrying, decide whether the operation is safe to repeat. A read is often easier to retry than a payment or order creation, but the API's actual contract controls the decision. A timeout can occur after a server completed the operation, leaving the client uncertain.
Bound the retry
Honor a valid Retry-After value when supported, allow for both seconds and HTTP-date forms, and apply a maximum wait and overall deadline. Otherwise use an appropriate exponential backoff with jitter. Limit attempts and concurrency so a temporary outage does not create a retry storm.
For write operations, use the provider's documented idempotency key or reconcile the operation status before retrying. An idempotency key only helps within the provider's documented scope and retention period.
Test failure paths
Simulate throttling, temporary unavailability, a lost response after a successful write and a dependency that stays down. Confirm the client reports a useful final failure and does not duplicate business effects. Track retries, exhausted attempts and customer-facing latency.
Review retry budgets after changing traffic or provider limits. Retrying every 4xx response or retrying indefinitely can make an incident worse.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.