Reliability pattern
API retries: exponential backoff, jitter, caps, and stop conditions
Design an API retry policy that respects Retry-After, avoids synchronized retry storms, limits total latency, and separates safe from unsafe methods.
Backoff is one part of a retry policy. A production policy also needs eligible errors, idempotency rules, jitter, a per-attempt timeout, a delay cap, a total time budget, and a stop condition. Without jitter, a fleet can recover from one outage by creating the next one.
Treat the complete response as an evidence record: status, headers, provider code, request identifier, method, and raw body. The sequence below separates what the response proves from the checks still needed before a safe retry or code change.
Diagnostic procedure
Work from evidence to recovery.
- 01
Define eligible failures
Retry temporary transport failures, selected 5xx responses, and 429 only when the provider guidance and operation safety support it.
- 02
Randomize the delay
Use full, equal, or decorrelated jitter according to fleet behavior; avoid identical deterministic delays across workers.
- 03
Cap the incident
Set attempt count, maximum delay, cumulative wait, and a circuit-breaker or queue fallback.
delay = 2 ** attempt; retry every error forever
eligible(error) && withinBudget → max(Retry-After, jitteredBackoff) → capped attempts
Duplicate-side-effect riskPOST retries can repeat side effects. Add an idempotency key or a durable operation identifier before enabling automatic retries.
No account · no upload · no endpoint calledOpen the full retry planner and operating notes →
FAQ
Before you ship
Does APITC send this evidence to an API?
No. The matching and calculations in the linked workbench run in the active browser tab.
Should every retry response be retried?
No. Retry behavior depends on the method, idempotency protection, provider instructions, and whether the failure is temporary.
Protocol behavior checked against the AWS Architecture Blog — Exponential Backoff and Jitter. Recheck your pinned provider/API version before production deployment.