Retry Strategy for Automation Failures

An API returns 503. A webhook times out. A service you depend on is briefly unreachable. If the automation stops at the first failure, that work sits unfinished until someone notices. A retry strategy is the rule for whether to try again, how long to wait, and when to stop.

Fallbacks, and bad input, are a separate design. This is only the next attempt.

Why a first failure is not the end of the work

A 99.9% uptime target still leaves room for downtime. A 365-day year has 8,760 hours. One tenth of one percent of that is 8.76 hours, about 8.8 hours. That is arithmetic on the target, not a claim that a vendor you use will be down for an afternoon.

Your workflow automation will meet some of those windows, plus ordinary timeouts. Retries help when the fault is brief. They hurt when they are unbounded, or applied to an error that will never clear.

Which retry strategy fits the failure

Four patterns cover almost every automation you will meet. The waits below are an illustration of the shape, not a setting copied from a product.

Strategy	What it does	When it fits
Immediate	Tries again with no pause	One extra try, already classed as transient and safe to repeat
Fixed interval	Same wait every time	A known short gap, and low volume
Exponential backoff	Wait grows, then hits a cap	Timeouts, 429s, and 503s
Backoff with jitter	The same growth, plus a random offset	More than one client calling the same service

An immediate retry belongs only as a single extra try. AWS treats no backoff, no jitter, and no maximum as the pattern to avoid. A fixed interval is simple, and weak when many workflows fail together and return on the same clock.

Exponential backoff grows the wait. An illustrative sequence is 1 second, then 2, then 4, then 8, with a cap so the gap does not become hours by accident. AWS recommends this, plus a maximum number of attempts, so a backlog of retries does not keep a recovering service busy. Jitter adds a random offset so clients do not retry in a herd. Less predictable timing is the feature.

Classify the error before you retry

Not every failure deserves another attempt. A timeout, a 429 (too many requests), a 503, or a dropped connection often clears. A 401, a 403, or a 400 on a bad payload will not.

Retrying every error is an anti-pattern in the AWS Well-Architected guidance, as is trusting a built-in retry you have not tested. Split “try again later” from “stop and tell a person”.

Reading a record is usually safe to repeat. Creating a charge, sending an email, or inserting an invoice is not, unless the step has been made safe to repeat. A retry of a charge that is not idempotent can double-charge. That is a property of the operation, not a story about a particular business. Fix that before you add retries.

Why infinite retries are dangerous

A cap is part of the strategy. Make’s documented default for its Retry handler is three attempts, 15 minutes apart, and both can be changed. Zapier’s autoreplay stops at five. Those are product defaults, not a law.

Then stop, and keep the item. A dead-letter queue holds work automatic retries could not finish. Amazon SQS moves a message there once the receive count exceeds maxReceiveCount.

On a standard queue the original enqueue time does not reset on that move, so the dead-letter queue needs a longer retention period than the source, or the message can expire unread. Keeping the item is the aim. It is not a promise that nothing is ever lost.

Unbounded retries hold connections a healthy request needed, and can keep a service overloaded after the fault has started to clear. They also multiply. Marc Brooker at Amazon illustrates a five-deep stack with three tries at each layer: load on the bottom service can rise 243 times. That figure is 3⁵ under those assumptions, not a measurement of your stack. Retry in one place. A missing field will not succeed on the twentieth try.

When you stop, log the error, the attempt, and the payload a person needs. Alert when the cap is hit, not on every retry. How to do that without crying wolf is in monitoring automated workflows. When retrying is the wrong tool, see automation error handling.

What Zapier, Make, and n8n actually do

Zapier can autoreplay an errored step up to five times: five minutes, then 30 minutes, one hour, three hours, and six hours. It will attempt the replay. It does not promise success.

From Zap history, steps that already succeeded are not run again. Replaying the whole run from the editor does run them, which can repeat an email or a row. Filters and Paths are not replayed from history.

Make stores a failed bundle as an incomplete execution when you add a Retry error handler. Automatic completion defaults to three further attempts, 15 minutes apart. If incomplete executions are on, connection errors, rate-limit errors, and module timeouts are already retried on an exponential schedule, at most three in parallel from the same scenario. When attempts are used up, the run stays unresolved for a person.

In n8n, open the node, then Settings, and enable Retry On Fail. Wait Between Tries is a fixed pause in milliseconds, not a growing backoff. That suits a short blip, not an outage. For the alert, set an error workflow in the workflow’s settings. It must start with an Error Trigger.

In custom code, classify the status, cap the attempts, wait longer each time, and add jitter if several callers might retry together. A circuit breaker, which pauses calls once failures cross a threshold, complements that cap. It does not replace it.

Before you switch retries on

For each step, write down whether the error is transient, whether it is safe to run twice, how many attempts you will allow, and who is told when the cap is hit.

AI systems work at Fernside is scoped workflow automation and integrations, measured in weeks, not a switch you turn on the same week. After a system is live, managed systems can watch failed runs and dead-letter queues. That does not replace the person who owns the process.

If a failed step currently just stops, book a discovery call and bring that workflow. We can look at where another attempt would help, and where it would repeat a charge, an email, or an invoice.