AI & Automation · Comparison

Zapier vs Make vs n8n: only one of the three retries a failure for you

Make retries three kinds of transient failure automatically, for almost eight hours, with nothing switched on. Zapier replays errored runs only if you pay for Professional. n8n retries nothing until you configure it, node by node. Here is what each one actually does when a run dies, and which one we would trust with a workflow that matters.

By Ishan Vats · Founder of IV Consulting · builds AI agents & automations for 150+ teams

Updated Aug 2026 11 min read Pillar: AI & Automation

Skip to the verdict → See the failure table

Autoreplay Incomplete executions Error workflows Retries

Step 3 just failed · 2026

TriggerOrder webhook fires

Step 3 · the CRM APITimes out. Nobody is told

ZapierReplays if you pay

MakeRetries 8 times, free

n8nNothing, by default

1 failure3 different silences

Quick answer

Of the three platforms, only Make retries a failed workflow automatically with nothing configured. It retries incomplete executions caused by rate limits, connection errors and module timeouts, 8 attempts over about 7 hours and 51 minutes. Zapier autoreplays errored runs on Professional, Team and Enterprise only, up to 5 attempts over about 10 hours and 35 minutes, and never autoreplays held runs. n8n retries nothing by default and does nothing on failure until you switch on Retry On Fail per node and attach an error workflow. Our verdict: Make has the best defaults, n8n has the highest ceiling, and Zapier has the most dangerous silence, because a Zap only turns itself off once 95 percent of its runs have errored in the last 7 days.

The failure nobody sees

Why does an automation break without anyone noticing?

Most automations break without anyone noticing because the platforms are built to keep running, not to raise an alarm. Automations do not usually fail loudly. They fail on a Tuesday afternoon, on one run out of two hundred, because an API was slow for eleven seconds. The workflow stops halfway. The lead never reaches the CRM. Nobody finds out until a client asks why they were never called back.

That is the failure mode that actually decides whether a small team keeps an automation running, and it is the one thing almost no Zapier vs Make vs n8n comparison covers. Every one of them compares app counts and pricing. Almost none of them tells you what the platform does at 3pm on the day a step returns a 503.

The three platforms answer that question very differently, and the differences are not marketing positions. They are documented behaviours you can read in each vendor's own help centre, and they change what you have to build on top. This post is that comparison: what happens automatically, what happens only if you paid for it, what happens only if you configured it, and what never happens at all.

The number that should worry you On Zapier, a Zap turns itself off automatically only if 95 percent of its runs error in the last 7 days. Read that the other way round. A Zap that fails 90 percent of the time will keep running, keep failing, and keep saying nothing, indefinitely. Silence is not evidence that your automations are healthy.

The comparison

What do Zapier, Make and n8n do when a step fails?

The short version: Make retries the most, for free, but throws the failed run away unless you flipped a setting that ships off. Zapier retries only on paid tiers, and only for one class of failure. n8n retries nothing until you build it, then retries better than either.

When a run fails	Zapier	Make	n8n
Automatic retry with zero setup	No. Autoreplay must be on, and only on paid tiers	Yes, for rate limit, connection and module timeout errors	No. Nothing retries until you enable it
Retry attempts	Up to 5	8 for system errors, 3 by default via the Break handler	Up to 5 per node, your choice
Retry window	About 10 hours 35 minutes from the first error	About 7 hours 51 minutes from the original run	Up to 5,000 ms between tries, so seconds, not hours
Which plans get it	Professional, Team, Enterprise. Not Free	All plans for system error retries	All, including self-hosted
Failures it will not retry	Held runs, ever	Anything outside the three system error types, unless handled	Anything you did not configure
Failed run stored for later	Yes, replayable for 60 days	Only if incomplete executions are enabled, and they are off by default	Only if you keep failed executions
Alerting a human	Email to the account owner	Notification on the scenario	Whatever your error workflow does, so anything
Auto disable on repeated failure	Only at 95 percent errors over 7 days	Scenario can be deactivated on repeated errors	Never, it keeps trying

Read this table correctly None of these numbers is a quality score. They describe defaults, and defaults only matter until you change them. The reason they matter anyway is that most small teams never do change them, so the default behaviour is the behaviour they actually get. If you are still choosing between the three on features and price, that comparison lives in n8n vs Make vs Zapier AI agents, and the billing shape is broken down in execution based vs task based automation pricing.

Platform one

Does Zapier retry a failed Zap automatically?

Zapier retries a failed Zap automatically only if you turned autoreplay on, and only if you are paying for it. Zapier's autoreplay is available on the Professional, Team and Enterprise plans, and is not available on Free. With it enabled, Zapier automatically replays any Zap run with an errored status, either account wide or per Zap.

The retry schedule is a backoff. Zapier attempts to replay the step up to 5 times, waiting 5 minutes, then 30 minutes, then 1 hour, then 3 hours, then 6 hours between attempts. The final replay happens about 10 hours and 35 minutes after the first error. That is a generous window, and it covers the most common real cause of failure, which is a third party API having a bad afternoon.

The catch is which failures qualify

Autoreplay only touches errored runs. It will not replay a run that was safely halted, and it will not replay a held run. Held is not a rare edge case: Zapier holds runs when an app connection has disconnected, when you hit your task limit, or when flood protection kicks in. Those are exactly the failures a small team hits, and they are the ones autoreplay leaves sitting there. You replay them by hand, in Zap history, within 60 days of the original trigger event.

So the honest summary is that Zapier's safety net is real, paid for, and has a hole in the middle of it shaped like your most likely outage.

And the Zap stays on almost no matter what

Zapier will turn a Zap off automatically, but the threshold is high: 95 percent of its runs erroring in the last 7 days. Team accounts get 24 hours of warning by email before that happens and Enterprise accounts get 72 hours. Below that threshold, a Zap that is failing most of the time simply keeps going. If you want to know that a workflow is degrading, you have to look, because the platform will not raise its voice until the workflow is effectively dead.

What this means in practice If you are on Zapier Free or Starter, your automation has no automatic retry at all. Every transient failure is a permanent one until a human notices. That is the single strongest argument for Professional that Zapier's own pricing page does not make.

Platform two

How does Make handle a failed scenario run?

Make handles a failed scenario run better out of the box than either Zapier or n8n, and it is not close. For three specific system errors, RateLimitError, ConnectionError and ModuleTimeoutError, Make retries the incomplete execution automatically with no user action required at all. Not a setting. Not a plan tier. It just happens.

The schedule is an exponential backoff across 8 attempts, starting 1 minute after the original scenario run and ending 3 hours after the previous attempt, with the final try landing about 7 hours and 51 minutes after the original run. Those three error types cover most of what actually breaks in production: an API rate limiting you, a connection dropping, a module timing out.

The setting that ships off

Here is the part that costs teams data. Incomplete executions are disabled by default. You have to enable Store incomplete executions in the scenario settings before Make will keep the failed run, its error message, its mappings and the remaining flow. Without it, a failure that falls outside the auto retried error types is gone. There is nothing to inspect and nothing to resume.

There is also a ceiling. The maximum number of incomplete executions across every scenario in every team in your organisation depends on your usage allowance, and you get an error once you exceed it. So the queue is a buffer you are expected to clear, not a permanent archive.

The Break handler, for everything else

For errors outside the automatic three, Make gives you the Break error handler. Attach it to a module and configure how many times to reattempt and how long to wait between attempts. The defaults are 3 retry attempts with a 15 minute delay, and it is a fixed interval rather than an exponential backoff. Break retries only run automatically if you enable automatic scenario run completion in the handler settings, and it wants incomplete executions turned on to work properly.

Two switches, five minutes If you run anything important on Make, open the scenario settings today and turn on Store incomplete executions. Then add a Break handler to any module that talks to an external API. That is the entire hardening job on Make, and almost nobody does it.

Platform three

What does n8n do when a node fails?

When a node fails in n8n, nothing happens by default. The workflow stops at the failing node and that is the end of it. n8n ships with no automatic retry, no automatic replay and no automatic alert. Every bit of resilience on n8n is something you build.

Which is either the worst answer here or the best one, depending on whether anyone on your team will actually build it.

Retry On Fail is per node, and it is small

Open any node, go to Settings, switch on Retry On Fail and you get two fields: Max Tries and Wait Between Tries (ms). Both are capped. n8n confirmed in its own issue tracker, on version 2.0.3, that Max Tries reverts to 5 if you try to set it higher and the wait reverts to 5,000 ms if you try to exceed that, and closed the report as working as expected.

That cap matters more than it looks. Five tries at five seconds apart is a 25 second window. It will absorb a slow API. It will not absorb a provider that is down for ten minutes, which is precisely the outage Make's 7 hour 51 minute backoff and Zapier's 10 hour 35 minute replay window are designed for. On n8n, long outages are handled by re-running the execution, not by the node.

The Retry On Fail trap

Each node also has an On Error setting with three options: Stop Workflow, which is the default, Continue using the regular output, and Continue using the error output. If you enable Retry On Fail and set On Error to either Continue option, the node reports an error even when a retry succeeded. It was filed against n8n 1.57.0 in September 2024 and closed as not planned, so treat it as designed behaviour rather than a bug that will be fixed. If you want retries and a graceful fallback path in the same node, test that combination before you trust it.

Error workflows are the actual feature

The thing that makes n8n the strongest of the three, once configured, is the error workflow. Build a separate workflow starting with the Error Trigger node, then select it under the failing workflow's settings. When that workflow errors, the error workflow runs and receives the execution ID, the execution URL, the error message, the stack trace, the last node executed and the workflow details.

That is a full incident payload, and you can do anything with it. Post to a Slack channel with a link straight to the failed execution. Open a ClickUp task. Write a row to a Notion database. Page someone. Neither Zapier nor Make gives you that level of control over what happens at the moment of failure, and it is the difference between finding out in six seconds and finding out in six days.

One gotcha before you celebrate You cannot test an error workflow by running the workflow manually. n8n's docs are explicit: the Error Trigger only runs when an automatic workflow errors. Build it, activate the parent workflow, then break something on purpose to confirm the alert actually arrives. An untested error workflow is not an alert, it is an assumption.

If you are building on n8n and have not set an error workflow yet, that is the first thing to do after your first automation goes live. Our walkthrough on building your first AI agent workflow with n8n covers the build; this is the part that keeps it alive afterwards.

The verdict

Our verdict: Make out of the box, n8n once someone owns it

Comparison posts usually end in "it depends." Here is the version with an opinion, based on how these builds actually go wrong after handover rather than on how the feature lists read.

If nobody will maintain it, use Make. Make is the only one of the three that protects an unattended workflow with zero configuration, and rate limits, dropped connections and timeouts are the overwhelming majority of what breaks. Eight retries over nearly eight hours, free, on every plan, is a genuinely good default. Turn on incomplete executions on day one and you have a resilient automation that an ops person can own.

If the workflow is load bearing and someone technical owns it, use n8n. The default is the worst of the three and the ceiling is the highest by a distance. An error workflow that posts the execution URL into the channel where your team already works turns a silent failure into a two minute fix. Nothing on Zapier or Make matches it. The cost is that you have to build it, and a team that will not build it should not choose n8n for reliability.

Zapier is fine, if you are on Professional and you know what held means. Autoreplay is a real safety net and the backoff is the longest of the three. But it is paywalled, it ignores held runs, and the 95 percent auto disable threshold means the platform will never tell you a workflow is quietly degrading. On Zapier, monitoring is your job, not the platform's.

The opinion we will defend The cheapest platform per execution is not the cheapest platform per recovered failure. A workflow that runs 2,000 times a month and silently drops 1 percent of runs is losing 20 real things: leads, invoices, handoffs. Whatever that costs you, it dwarfs the difference between the three pricing plans people spend weeks comparing. Choose on what happens when it breaks, and treat the price comparison as a tiebreaker.

Where we stand on this We build automations for client teams and hand them over, which means we do not get to be around when they break. That changes what you optimise for. An automation that needs a specialist to notice it has stopped is not finished, no matter how well it runs on the day of handover. Every build we ship has a failure path that reaches a human who is not us, and on n8n that is an error workflow, on Make it is incomplete executions plus a Break handler, and on Zapier it is autoreplay plus somebody's calendar reminder to check Zap history. That last one is the weakest of the three, and it is the honest reason we reach for Zapier last on anything that matters.

Before you pick, run your own numbers Reliability only matters in proportion to what the workflow is worth. Put your real run volumes and the hours the process eats into the AI agent ROI calculator and you will see, in one number, how much a 1 percent silent failure rate is actually costing you. That number decides how much hardening is worth doing far better than any feature table can.

The fix

What should you switch on this week?

Whichever platform you are on, the hardening job is about thirty minutes. Here is the list, per platform, in the order we do it.

On Zapier

Enable autoreplay account wide if you are on Professional or above. Then open Zap history, filter to held runs, and find out how many are sitting there right now. Autoreplay will never touch them. Put a recurring 15 minute check in someone's calendar, because the platform will not tell you until 95 percent of runs are failing.

On Make

Turn on Store incomplete executions in the settings of every scenario you care about. Add a Break error handler to any module that calls an external API, and enable automatic scenario run completion on it so the retries actually fire. Then check the incomplete executions tab weekly, because it has a cap tied to your usage allowance.

On n8n

Build one error workflow starting with the Error Trigger node that posts the error message and the execution URL to Slack, then attach it to every production workflow. Add Retry On Fail to nodes that call external APIs, 3 tries at 2,000 ms is a sensible baseline. Then break something deliberately to prove the alert arrives, because you cannot test it manually.

On all three: make the failure land where people already look

The single highest return change is not a retry setting. It is making sure a failure produces a message in the channel your team reads every day, with a link that opens the failed run. Retries buy you time. An alert is what turns a silent failure into a fixed one. That plumbing is exactly what the Automation stage exists to install, and if you would rather see the failure path designed properly from the start, that is the conversation to have.

If reliability is the reason you are considering a move off Zapier, sequence it properly rather than rebuilding everything at once. We walk through it in the Zapier to n8n migration guide.

FAQ

Questions owners ask about automation failures

Does Zapier automatically retry a failed Zap?

Only with autoreplay enabled, and autoreplay is available on the Professional, Team and Enterprise plans, not on Free. When it is on, Zapier replays runs with an errored status up to 5 times, waiting 5 minutes, 30 minutes, 1 hour, 3 hours and then 6 hours between attempts, so the final replay lands about 10 hours and 35 minutes after the first error. Autoreplay never replays held runs, which are the ones paused by a disconnected app, a task limit or flood protection. Those you replay manually in Zap history, within 60 days of the original trigger event.

Does Make retry a failed scenario automatically?

Yes, for three system error types and with no configuration required: RateLimitError, ConnectionError and ModuleTimeoutError. Make retries the incomplete execution 8 times on an exponential backoff, starting 1 minute after the original run and finishing about 7 hours and 51 minutes after it. For any other error you attach the Break error handler, which defaults to 3 retry attempts at a fixed 15 minute interval and needs automatic scenario run completion enabled to retry on its own.

Why does Make lose my failed runs?

Because incomplete executions are disabled by default. Until you enable Store incomplete executions in the scenario settings, Make does not keep the failed run, its error message, its mappings or the remaining flow, so there is nothing to inspect or resume afterwards. Enable it on every scenario that matters. Note there is also a cap on how many incomplete executions your whole organisation can hold, based on your usage allowance, so treat the queue as something to clear rather than an archive.

Does n8n retry failed nodes by default?

No. n8n does nothing on failure until you configure it. You enable Retry On Fail in an individual node's Settings tab, which gives you Max Tries and Wait Between Tries in milliseconds. Both are capped: n8n confirmed on version 2.0.3 that Max Tries reverts to 5 and the wait reverts to 5,000 ms if you set them higher, and closed that report as working as expected. So node level retry on n8n covers a slow API, not a provider outage lasting minutes.

What is an n8n error workflow and why does it matter?

An error workflow is a separate workflow that starts with the Error Trigger node and runs whenever a linked workflow fails. You attach it by selecting it in the failing workflow's settings. It receives the execution ID, the execution URL, the error message, the stack trace, the last node executed and the workflow details, so you can post a complete incident alert into Slack, ClickUp or Notion. It is the strongest failure feature on any of the three platforms. One catch: it does not run during manual executions, so activate the workflow and break it deliberately to test the alert.

Will my automation platform tell me when a workflow is failing?

Not reliably. Zapier emails the account owner and turns a Zap off automatically only once 95 percent of its runs have errored in the last 7 days, with 24 hours of warning on Team plans and 72 hours on Enterprise, so a workflow failing most of the time can run for weeks without being disabled. Make surfaces errors on the scenario. n8n tells you nothing at all unless you built an error workflow. On every platform, assume monitoring is your job and route failures into a channel your team already reads daily.

Which platform is most reliable for a small business?

Make, if nobody is going to maintain the automation, because it is the only one that retries transient failures automatically on every plan with nothing configured. n8n, if someone technical owns it, because an error workflow gives you a real alert with a link to the failed execution and nothing on the other two platforms matches that. Zapier sits between the two: autoreplay is a genuine safety net with the longest retry window, but it is paywalled to Professional and above and it ignores held runs entirely.

Can IV Consulting make my automations fail safely?

Yes. IV Consulting builds automations across Zapier, Make and n8n and installs the failure path with them: retries, stored failed runs, and an alert that reaches a human who is not us. That is standard in every build we hand over, because an automation nobody notices has stopped is not finished. If you want to size the opportunity yourself first, start with the AI agent ROI calculator.

Before you pick, run your own numbers A platform's retry behaviour only matters in proportion to what the workflow carries. Put your real run volume and the hours the process eats into the AI agent ROI calculator and you will see what a small silent failure rate is actually costing you, which is the number that should decide how much hardening is worth doing.

Who wrote this

Ishan Vats

Founder, IV Consulting · AI & automation consultant

I build production AI agents and automations across Zapier, Make and n8n, and I hand them over, which means the failure path has to work without me. 150+ ops transformations over 10+ years. Want to know what your own workflows are worth protecting?

Run the AI agent ROI calculator →

Keep reading

Related guides and work

Comparison

n8n vs Make vs Zapier AI agents

The same three platforms on features, agent depth and billing model, with our pick for each situation.

Read the comparison →

Guide

Zapier to n8n migration guide

If reliability is why you are moving, here is the order to rebuild in without breaking what works.

Read the guide →

Work with us

The Automation stage, built for you

Your tools connected, the busywork gone, and a failure path that reaches a human who is not us.

See the offer →

Would you know if your automations stopped?

Book a free 30-minute strategy call. We will look at what you run today across Zapier, Make and n8n, tell you where a failure would go unnoticed, and show you the smallest change that turns a silent failure into an alert. If you do not need us yet, we will say so.

Book a Free Strategy Call →

Free 30-minute call. Honest take, even if that means "you do not need us yet."