Retries & timeouts

Set explicit connection and total request timeouts. Give the entire workflow a deadline so retries cannot exceed the user-facing latency budget.

Retry only transient outcomes

Use exponential backoff with randomized jitter, honor Retry-After, and cap attempts and elapsed time. Do not retry validation, authentication, or privacy errors unchanged.

Avoid retry amplification

Coordinate retries across workers and queues. A timeout does not prove that no upstream work occurred, so keep follow-up behavior idempotent where the public contract supports it.

Use one workflow deadline

Budget DNS, connection, response, backoff, and every attempt inside one user-visible deadline. Stop starting new attempts when the remaining time cannot accommodate them. Queue workers also need a maximum job age so stale work cannot accumulate indefinitely.

Preserve operation identity

Where an operation accepts Idempotency-Key, generate one opaque value for the intended operation and reuse it only for retries of that same request. Never reuse it with changed parameters. The API Reference defines where the header applies.

Test the policy

Exercise validation, authentication, rate-limit, upstream, slow-response, and connection-failure paths. Verify the total elapsed time, maximum attempt count, and logs rather than testing only the final response.