Glossary · Reliability
Exponential backoff
Also called: retry with backoff, backoff and jitter
Exponential backoff is a retry strategy in which the wait before each new attempt grows exponentially (for example 1, 2, 4, 8 seconds), usually with random jitter, up to a maximum number of attempts or delay.
Most failures in automation are temporary: a timeout, a 503 during a deploy, a rate limit. Retrying immediately makes things worse; if a thousand clients all retry at once, the struggling service gets a thousand more requests. Backoff spaces retries out, and jitter (a random offset on each wait) stops clients from retrying in lockstep. AWS's Builders' Library article on timeouts, retries and backoff with jitter is the classic explanation.
A sensible default
| Attempt | Wait before it (base 1 s, doubling, capped) |
|---|---|
| 1st retry | ~1 s |
| 2nd retry | ~2 s |
| 3rd retry | ~4 s |
| then | stop and hand off |
Rules that prevent damage
- Only retry what can succeed. Timeouts, 429 and 5xx: yes. A 400 (bad request) or 401 (bad credentials) will fail identically every time.
- Only retry what's safe to repeat. A retried "create invoice" can create two, unless it carries an idempotency key or is an upsert.
- Cap it. Unbounded retries turn an outage into a backlog. After the last attempt, route the item to a dead-letter path where a person can see it.
In Fluxo Flow
Action nodes have Retries, a Retry Strategy (exponential, fixed or none), a Max Retry Delay and a Failure Behavior (stop, skip or continue) in their Advanced tab. When retries run out, an Error Handler node can notify someone, log the item or undo earlier changes, and owners and admins are notified when a scheduled or webhook run fails.
Read next
Related terms
- Rate limitA rate limit is a cap an API puts on how many requests a client may make in a time window; requests over the limit are refused, usually with HTTP status 429 Too Many Requests.
- Idempotency keyAn idempotency key is a unique value a client sends with a request so that, if the same request is retried, the server recognizes it and returns the original result instead of doing the work a second time.
- Dead-letter queueA dead-letter queue is a holding place for messages or items that couldn't be processed after all retries, kept aside with their error so a person can inspect, fix and replay them instead of losing them.
- HMAC signatureAn HMAC signature is a hash of a message computed with a secret key that only the sender and receiver know, sent alongside the message so the receiver can prove it came from the sender and wasn't altered.
- Dry runA dry run executes a workflow end to end with its side effects simulated, so you can see what every step would do without sending, writing or charging anything.