Retry logic handles temporary failures by trying again instead of failing on the first error. A short network glitch, a busy server or a rate limit often clears up within seconds, so a second attempt succeeds.
A good policy sets a limited number of attempts, waits between them, and increases the wait each time, a pattern called exponential backoff, often with a little random variation so many clients do not retry at the same instant. It retries only errors that might be temporary, such as timeouts and server busy responses, and does not retry permanent ones like invalid input or authentication failures.
Retries are only safe if repeating the action is harmless, so the operation needs to be idempotency-safe; otherwise a retry after a timeout that actually worked can create a duplicate. When attempts run out, pass the failure to error handling so someone is alerted. Retries appear in webhook delivery, API clients and workflow automation tools like n8n.
Related: Workflow, Race Condition.