Core · Fail, wait, try again, without making it worse.
Retries & backoff
APIs fail all the time: timeouts, 500s, 429s, a 30-second outage. Retrying fixes most of it, but retrying badly turns a small blip into a pile-up.
Try this
Run each experiment in the simulator above, then tick it off.
Key ideas
Back off exponentially
Wait 1s, 2s, 4s, 8s. Each failure doubles the wait, giving the API room to recover instead of hammering it.
Add jitter
If 500 tasks all retry at exactly 2 seconds, they collide again. A little randomness spreads them out.
Know what's retryable
Retry timeouts, 429s and 5xx errors. Don't retry 400, 401 or 404: the request itself is wrong and will fail forever.
Only retry safe steps
A retried step runs twice if the first attempt actually worked. Make it idempotent first.
In your Pabbly workflows
Failed tasks in Pabbly's task history can be re-run, and that is your manual dead-letter queue. For flaky APIs, check the response status, add a delay, and try again before giving up. Make sure the retried step is safe to run twice, and remember every retry is another task on the bill.
Check yourself
0/2Get every question right to mark this lab done. Wrong answers let you try again.
Q1. The API returns 401 Unauthorized. Should the workflow retry?
401 means the credentials are wrong or expired. Retrying sends the same bad credentials and burns tasks. Retry timeouts, 429 and 5xx instead.
Q2. Why add jitter to backoff?
Without jitter, every task that failed together retries together, and the recovering API gets hit by the same wave again.
Lab complete
Marked done on this device. On to the next one.
Watch next
Searches for “retry exponential backoff” on the channels worth your time.