Most automation platforms promise “automatic retries” when a step fails. What they don’t advertise is how differently each tool defines failure, how many times they’ll retry, and what happens to your data when a step succeeds on the third attempt but your downstream logic assumed it failed.
If you’re running payment workflows, lead capture, or anything that touches money or customer data, retry behavior isn’t a nice-to-have detail—it’s the difference between a duplicate charge and a satisfied customer.
What triggers a retry in the first place
Zapier retries on HTTP 429 (rate limit), 502, 503, and 504 errors. It does not retry on 4xx errors like 400 (bad request) or 401 (unauthorized), because those indicate a configuration problem, not a transient failure.
Make (formerly Integromat) retries on the same 5xx errors but adds exponential backoff—first retry after one minute, second after two, third after four. You can configure this in scenario settings, but the default is three attempts.
n8n retries on any HTTP error by default unless you explicitly disable it per node. This sounds safer, but it means a misconfigured API call will burn through retry attempts instead of failing fast and alerting you.
The problem: if your automation sends a Slack notification on step failure, and the API call succeeds on retry two, you’ve already notified your team that something broke. Now you’re debugging a phantom issue.
When retries create duplicate actions
Here’s the worst-case scenario: your automation charges a customer via Stripe, then adds them to your CRM. The Stripe call succeeds, but the CRM times out. The platform retries the entire workflow, not just the failed step.
Result: two Stripe charges.
Zapier avoids this by replaying only the failed step and everything downstream. If step three fails, steps one and two don’t re-run. But if you’ve built a linear workflow without idempotency checks—like “charge card, then email receipt”—a retry on the email step won’t re-charge, but a retry on the charge step will re-email.
Make handles this better with “commit points.” You can flag a module as non-retriable, which tells the platform to skip it on replay. Stripe charges should always be flagged this way.
n8n requires you to handle this manually. If you want idempotency, you need to add a conditional node that checks whether the Stripe charge already exists before creating a new one. It’s more work upfront, but it’s also the only way to be certain.
What “max retries” actually means
Zapier’s documentation says tasks retry “up to three times,” but that’s three retries per step. If you have a five-step Zap and step four fails, Zapier will attempt step four three times, then mark the entire run as failed. Steps one through three don’t re-run.
Make’s retry count applies to the entire scenario run. If you set max retries to three, the platform will replay the whole scenario three times if any module fails. This is why commit points matter—you don’t want non-idempotent actions replaying.
n8n’s retry logic is per-execution, but you control the interval. Default is immediate retry, then 1 minute, then 5 minutes. You can stretch this to hours if you’re integrating with an API that has daily rate limits.
How to design for retries without breaking things
First, separate state changes from notifications. Charge the card in step one, write the result to your database in step two, send the receipt in step three. If step three fails and retries, you’re only re-sending an email—not re-charging.
Second, add idempotency keys to any financial or inventory action. Stripe’s API accepts an idempotency_key parameter; if you retry with the same key, Stripe returns the original charge instead of creating a new one. Most payment processors support this.
Third, log every retry. Zapier’s task history shows retry attempts, but Make and n8n require you to add explicit logging nodes. Write the execution ID, timestamp, and step name to a Google Sheet or database. When something breaks three days later, you’ll know whether it was a transient failure or a config issue.
Fourth, set retry limits based on your SLA, not the platform default. If your workflow processes orders, three retries over six minutes might be fine. If you’re syncing live event registrations, you want zero retries and an instant alert.
Finally, test failure states manually. Pause your CRM’s API access mid-automation and watch what happens. Does the platform retry? Does it log the failure? Does your fallback notification fire? If you don’t know, you’re guessing.
Want more breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools that run your business—and the edge cases their docs don’t mention.