n8n retry logic vs Zapier is usually assumed to be a like-for-like comparison, two automation platforms offering roughly the same “try again if it fails” safety net. The two mechanics are not the same shape at all. n8n’s retry runs inline, inside the same execution, capped at 5 attempts and 5000 milliseconds between them, so it finishes or gives up within seconds. Zapier’s closest equivalent, Autoreplay, is a separate, opt-in feature that replays an already-failed step on an escalating schedule spanning roughly 10 hours 35 minutes. A team assuming Zapier behaves like n8n by default will find nothing retries at all unless that specific setting has been turned on.
n8n Retry Logic vs Zapier Starts With a Different Definition of “Retry”
Per n8n’s own documentation, retry is a per-node setting: “Use this option to retry the node after a failed attempt. In the HTTP Request node, go to Settings and enable Retry on Fail. Set Max Tries to the maximum number of times n8n should retry the node. Set Wait Between Tries (ms) to the desired delay in milliseconds between retries.” That retry happens inside the same workflow execution, before the run is considered finished.
Per Zapier’s own documentation on replay, the closest equivalent is a separate feature entirely: “If you enable autoreplay, Zapier will replay your Zap workflows automatically.” The same page’s own plan-availability chart for Autoreplay specifically marks the Free plan ineligible and Professional, Team, and Enterprise as available. Unlike n8n’s retry, Autoreplay only engages after a step has already failed and the run has already ended in error, and unlike n8n’s retry it is gated to a paid plan and has to be switched on deliberately rather than being available the moment a node’s own settings are opened.
What n8n’s Retry on Fail Actually Does
The shape of the mechanic matters more than the fact that it exists. Because n8n’s retry happens inside the same execution, the workflow does not move on to the next node until retry has either succeeded or genuinely exhausted its 5 attempts. That makes it well suited to a specific kind of failure: a flaky third-party API call that usually succeeds on a second or third attempt within a few seconds, where holding up the rest of the workflow for that short window is an acceptable cost. It is a poor fit for a failure that takes longer than seconds to resolve itself, since the entire retry budget is spent well before that kind of recovery would ever happen.
n8n’s own documentation describes the mechanic without stating the exact numeric caps, but n8n’s support team, closing a bug report about the field’s limits as working as expected, confirms them directly: “the maximum value for retries is 5, with 5000ms waiting time between each try in n8n.” Attempting to set Max Tries above 5 or Wait Between Tries above 5000 milliseconds simply reverts to those caps. In practical terms, a node with retry fully exhausted makes at most 5 attempts, with up to 4 waits of 5000 milliseconds each between them, so the whole sequence adds at most about 20 seconds of waiting on top of the attempts themselves before the workflow moves on or fails outright.
There is a documented interaction worth knowing before relying on this. Per an n8n maintainer’s own comment on a related report, “Retry on fail currently only works if you use the ‘stop workflow’ option,” referring to the separate On Error setting; the same maintainer noted this might change in a future release, so it is worth confirming this still holds on the current n8n version before relying on it. If On Error is set to either Continue option instead, the retry settings are not consulted at all, and the node simply proceeds past the failure on the first attempt.
What Zapier’s Autoreplay Actually Does
The reverse holds for Autoreplay: because it engages only after a run has already ended in error, it is well suited to a failure category n8n’s inline retry cannot meaningfully address, a downstream system that is genuinely down for minutes or hours rather than seconds, where a fast inline retry would just fail again immediately and a slower, spaced-out attempt schedule has a real chance of hitting a window when the dependency is back. The trade-off is that a record affected by a failed step sits in a failed state for potentially hours before the final scheduled attempt runs, which is a materially different experience for anyone watching that record depend on the Zap completing.
Zapier’s own documentation gives the full replay schedule, and it is not a compressed, seconds-long sequence the way n8n’s retry is: “First: 5 minutes after initial trigger event… Second: 30 minutes after last attempt… Third: 1 hour after last attempt… Fourth: 3 hours after last attempt… Fifth: 6 hours after last attempt.” The same page states plainly: “The final replay will occur about 10 hours, 35 minutes after the first error,” and confirms the attempt count matches n8n’s cap coincidentally: “Zapier will attempt to replay the step up to 5 times.”
Two further documented limits matter for anyone assuming Autoreplay behaves like a generic safety net. Zapier’s own documentation states plainly that “Filter and Paths steps are never replayed,” regardless of Autoreplay being enabled. And Autoreplay is entirely separate from Zapier’s default account-wide protection: per Zapier’s own documentation on why a Zap stops running, “Zapier will automatically turn off your Zap if it: Errors 95% of the time it runs. Has run more than 20 times in the past 7 days.” Both conditions have to be met together, not just the error rate alone, and the pause itself applies to every account regardless of plan or Autoreplay status. The ability to override it does not: choosing between the two named options, “Turn off if errors occur (recommended)” and “Keep running if errors occur,” is itself gated to Professional plans and higher, so a Free-plan Zap that trips the threshold has no way to opt out of the pause.
n8n Retry vs Zapier Autoreplay, Side by Side
| Property | n8n Retry on Fail | Zapier Autoreplay |
|---|---|---|
| Where it runs | Inline, inside the same execution | After the run has already ended in error |
| Maximum attempts | 5, hard-capped | 5, hard-scheduled |
| Total added wait time | Up to about 20 seconds, on top of the attempts themselves | About 10 hours 35 minutes |
| Plan availability | Any plan, per-node, on by default when enabled | Professional plan and higher, account-wide or per-Zap, off until deliberately enabled |
| Known exclusion | Ignored entirely if On Error is set to Continue | Filter and Paths steps are never replayed |
Where Teams Get This Wrong
None of these mismatches produce an error message pointing at the misunderstanding itself; a workflow or Zap that “should have retried and didn’t” just looks like a plain failure. The underlying cause in every case is the same: retry is treated as a single, portable concept that behaves the same way regardless of which platform it is configured on, when the two platforms actually ship genuinely different mechanisms under a similar-sounding name.
The first common mistake is assuming Zapier retries a failed step automatically the way n8n does, when Autoreplay has to be deliberately turned on and is gated to Professional plans and higher; on the Free plan, or with Autoreplay off, a failed step simply stays failed.
The second common mistake is expecting n8n’s retry to rescue a node whose On Error setting is one of the Continue options, when n8n’s own maintainers confirm retry is only consulted when On Error is set to Stop Workflow, so a node configured to continue past its own errors never gets a second attempt at all, regardless of how Retry on Fail itself is configured.
The third common mistake is treating Zapier’s 95%-error auto-pause and Autoreplay as the same feature, when they are separate mechanisms: the auto-pause is a default, account-wide circuit breaker for a Zap that is failing almost every time, while Autoreplay is an opt-in retry for individual failed steps regardless of the Zap’s overall error rate. A Zap can have Autoreplay working exactly as configured and still get auto-paused entirely if its overall error rate crosses the 95 percent threshold, since the two settings are evaluated independently of each other.
The fourth common mistake is assuming a Filter or Paths step in Zapier will eventually be retried by Autoreplay like any other step, when Zapier’s own documentation states these step types are never replayed under any circumstance, which means a Zap that depends on one of these step types recovering from a transient error has no automatic path back at all.
Related Reading
For the automation build side specifically, see n8n Consultancy. For the wider error-handling discipline this comparison sits alongside, see n8n vs Zapier for RevOps Automation. For the CRM foundation these workflows typically write back to, see HubSpot Consultancy.
Go deeper: Advanced n8n Error Handling Strategies · RevOps Consultancy · Measuring ROI in Workflow Automation for RevOps
Frequently Asked Questions
Does Zapier retry a failed step automatically like n8n does?
Not by default. Zapier’s own documentation shows Autoreplay is gated to Professional plans and higher and, even on those plans, has to be switched on rather than being automatic. n8n’s Retry on Fail, by contrast, is available on any plan and only needs enabling per node, with no separate account-wide toggle or paid plan required first.
How many times will n8n retry a failed node?
Up to 5 attempts, with a maximum wait of 5000 milliseconds between each one, per n8n’s own support team. Both figures are hard caps; setting either value higher simply reverts it to the maximum, so a fully-exhausted retry adds at most about 20 seconds of waiting on top of the attempts themselves.
How long does Zapier’s Autoreplay take to finish retrying a step?
About 10 hours and 35 minutes for all 5 scheduled attempts, per Zapier’s own documentation: 5 minutes after the initial trigger event, then 30 minutes, 1 hour, 3 hours, and 6 hours after each previous attempt. This is a fundamentally slower, after-the-fact process compared to n8n’s inline, seconds-long retry.
Does n8n’s retry setting work no matter how a node’s error handling is configured?
No. n8n’s own maintainers confirm retry only functions when the node’s On Error setting is Stop Workflow. If On Error is set to either Continue option instead, the Max Tries and Wait Between Tries settings are not consulted at all.