OpenAI 429 vs 503 Errors: Retry Without Skewing Your Data

429 and 503 answer different questions

The September 2, 2026 API changelog says rapidly growing traffic may receive HTTP 429 with slow_down. A temporary model overload may receive HTTP 503 with server_is_overloaded. OpenAI says either response may include Retry-After and recommends honoring it; without the header, clients should use exponential backoff.

Build the retry policy in this order

1. Parse the HTTP status, structured error code, request ID, and Retry-After.
2. If the response is not in an approved transient class, stop and route it to the appropriate failure handler.
3. If Retry-After is valid, wait for that duration unless it exceeds the job’s total time budget.
4. Otherwise calculate exponential backoff with randomized jitter.
5. Cap the attempt count, per-wait delay, and total elapsed time.
6. For write-like or externally visible tools, use an idempotency strategy before retrying.

if retry_after_is_valid:
    delay = retry_after
else:
    delay = min(max_delay, base_delay * 2 ** attempt) + jitter

if attempts_exhausted or elapsed + delay > job_budget:
    stop_or_defer()
else:
    retry_after(delay)

This pseudocode is a design pattern, not an official SDK sample. Use your runtime’s current OpenAI SDK and header parser.

Jitter prevents clients from retrying together

Pure exponential backoff can synchronize a fleet: many workers fail together, calculate the same delay, and return together. Random jitter spreads the retries. Use a documented strategy such as full jitter or equal jitter and test it with a fake clock.

Do not sleep inside a request thread if the architecture can reschedule work. A durable queue can preserve the task, earliest retry time, attempt count, and idempotency key without tying up capacity. Interactive requests should have a short user-facing budget; long research batches can defer instead of making the user wait through repeated attempts.

Log a decision ledger, not just an error count

Download the OpenAI API retry decision ledger (CSV). Its rows are marked EXAMPLE-REMOVE and contain no production results. Redact credentials, prompts, personal data, and raw output before sharing a real ledger.

Capture event time, endpoint, model, status, error code, retry header, attempt, chosen delay, decision, outcome, and latency. Store the request ID in a restricted operational log. The key derived metrics are not merely “errors per hour”:

• first-attempt success rate;
• recovered-after-retry rate by status and code;
• requests abandoned by attempt cap or elapsed-time cap;
• added latency among successful requests;
• duplicate side effects prevented or detected;
• measurement rows lost, deferred, or completed.

Protect AI visibility measurements from retry bias

A visibility study can become biased when failed prompts disappear from the denominator. If one model or query class overloads more often, analyzing only successful answers can make it look more reliable or more visible than it was.

Pre-register the query set and keep every scheduled row. Mark outcomes as completed, recovered, deferred, permanently failed, or excluded with reason. Report the completion rate next to citation and recommendation rates. Our AI visibility and referral test uses the same denominator discipline.

For cost governance, the OpenAI API cost-by-key ledger can be joined on a hashed job ID. Do not assume a failed or retried request was free; use billing telemetry where available and otherwise mark the cost unknown.

Alert on impact and classification

Use separate time series for 429 slow_down, 503 server_is_overloaded, other 429 codes, and other 5xx errors. Alert on sustained user impact, depleted retry budgets, queue age, or completion-rate loss—not on one transient response.

A sudden 429 slow_down increase after a client deployment points first to traffic shaping and concurrency. A 503 overload increase isolated to one model suggests a different investigation. These are operational hypotheses, not proof; the request logs and OpenAI status information provide the evidence.

Never create an infinite retry loop. It converts a brief constraint into added load, higher latency, and a misleading success metric.

Review the policy after traffic-shaping, concurrency, queue, SDK, or model-routing changes because each can alter the retry pattern without any change to the underlying content workload.

Source, method, and update note

Primary source: OpenAI’s API changelog, September 2 entry, checked September 3, 2026.

Method: SearchEngineAnswer translated the documented status and error-code distinction into a retry and monitoring workflow. We did not run a load test and report no incident rate or recovery-rate benchmark.

Recheck trigger: Update if OpenAI changes the error codes, retry guidance, response headers, status semantics, or SDK behavior.