Retry 429, 5xx and Timeout Failures in n8n Without Creating New Problems

Classify before retrying

429 usually signals rate limiting. 5xx may be transient server failure. Network timeouts can be ambiguous: the remote system may have completed the request even when your workflow never received the response. By contrast, many 4xx responses indicate a request that will continue failing until its input or authorization changes.

Use bounded backoff

Retry a finite number of times, increasing the delay between attempts. If a service supplies a retry-after signal, respect it. A tight retry loop can turn a temporary outage into a larger incident.

Protect mutations

For create, send, charge, or update operations, use a provider idempotency key or a durable processed-event key whenever available. A timeout after a successful remote write is the classic path to accidental duplicates.

Keep terminal failures visible

After the final permitted retry, route the execution into an observable failure path: capture the workflow, failed node, execution reference, event key, response status and a privacy-safe error summary. Do not silently swallow the failure.

Test the retry boundary

• Force a 429 and verify the delay is applied.
• Force a transient 500 and verify recovery within the retry limit.
• Force repeated failure and verify the workflow stops retrying.
• Simulate a timeout after a remote write and verify idempotency prevents a duplicate.
• Verify alerts and logs contain enough evidence to recover manually.