Skip to content
Optimal Lab

AI Automation · interactive

Retries and error handling

An automated workflow calls an API and gets an error. Some errors go away if you wait, some need you to slow down, and some will never succeed. The retry policy should depend on which.

Attempts, 0 to 12 s

503503200
  • attempt 1 at 0 s503
  • attempt 2 at 0.8 s503
  • attempt 3 at 3.4 s200

Outcome: succeeded

Waits grow (about 1 s, then 2 s…) with random jitter so clients don't retry in sync. Succeeded at 3.4 s.

The API returns

Retry policy

Step 2 of 4

  1. 1

    Sort the error first

    Timeouts, 502/503/504 and dropped connections are usually temporary. 400, 401, 403 and 404 aren't.

    Only retry what can succeed later.

  2. 2

    Back off exponentially, with jitter

    Wait 1 s, 2 s, 4 s… plus some randomness, and stop after a few tries.

    delay = base × 2^attempt × random(0.5, 1.5)

  3. 3

    Respect Retry-After

    A 429 tells you how long to wait. Waiting less just earns more 429s.

    Retry-After: 10

  4. 4

    Fail loudly, safely

    After the last try, park the item in a dead-letter queue and alert a person. Make steps idempotent so a retry never charges twice.

    Retries + idempotency go together.

In production

Tools and technologies

Workflow tools have retries built in; the policy is yours to set.

Not tied to one language — use these names when you search docs or design a system.