What retries and error handlers actually cost on Zapier, Make and n8n

A 10% failure rate on a four-step workflow sounds like a rounding error. It is not. Every platform bills a failure differently, and the difference between “a failed step is free” and “a failed run is a billable unit” can change which tool a flaky workflow should live on.

This review is based on official documentation and pricing pages — we did not run these tools hands-on. Every number below is a worked example computed from documented billing rules, labelled computed, not measured. Where a rule could not be confirmed from the source pages, we say so instead of guessing.

The three billing models in one paragraph

Zapier bills tasks, and a task is any successful action (How is task usage measured in Zapier?). Make bills operations, where an operation is a single module run that processes or checks data (Make operations documentation). n8n bills executions, one per workflow run regardless of how many steps or how much data it contains (n8n pricing). Those three sentences are the whole argument. The rest is arithmetic.

E-E-A-T

Experience: This guide is written from the platforms’ own documentation rather than from running these three tools side by side. We did not benchmark them, and we say so wherever a number is computed rather than measured.

Expertise: The billing rules cited here come from each vendor’s own help and pricing pages, linked inline. We have not benchmarked the platforms against each other, and we make no measured cost-per-failure comparison.

Authoritativeness: Where documentation is ambiguous — Make’s treatment of failed and retried runs is the clearest case — we flag it as unverified and tell you exactly where to look rather than filling the gap with a plausible-sounding rule.

Trust: Every computed figure shows its arithmetic and carries a “computed, not measured” label. Plan prices and quotas move; we tell you when to re-check them.

The worked example

Assumptions (stated so you can change them):

A workflow with 4 action steps per run.
1,000 runs per month attempted.
10% of runs fail somewhere in the middle, so 100 failed runs and 900 successful runs.
A failed run has already completed 2 of the 4 steps successfully before the third step errors.
Retries are attempted once per failed run, and the retry re-runs the workflow from the start.

Zapier: tasks are only charged for success

Per the Zapier help page, only successful actions count as tasks; action steps that error or halt are not counted, and steps that never run because the Zap errored are not counted either (Zapier task usage).

First attempts:

900 successful runs × 4 successful steps = 3,600 tasks
100 failed runs × 2 successful steps before the error = 200 tasks
The erroring step itself: 0 tasks (errored action steps are not counted)

Subtotal: 3,600 + 200 = 3,800 tasks — computed, not measured.

Retries: Zapier’s docs note that when you replay an entire Zap run, previously successful steps re-run and each successful run counts as a task again (Zapier task usage). A retry that gets past the failing step therefore bills the two steps that already worked plus the two remaining steps:

100 retries × 2 already-successful steps re-run = 200 tasks
100 retries × 2 remaining steps that now complete = 200 tasks

Total for the retried scenario: 3,800 + 200 + 200 = 4,200 tasks — computed, not measured.

The visible line-item difference between “no retries” and “one successful retry” is 4,200 − 3,800 = 400 tasks, or roughly 11% more tasks than the first-attempt total — computed, not measured. Against a failure-free baseline of 3,600 tasks, the retried scenario costs 600 extra tasks (about 17% more): 200 for the first-attempt work on runs that failed, plus 400 for the replays. The failed step is free; the successful work that has to be redone is not.

n8n: one execution per run, and retries count too

n8n counts executions per workflow run, not per step (n8n pricing). Only production executions count toward the quota: trigger-, schedule- and polling-started runs. Manual runs, sub-workflow calls (only the parent counts) and error-workflow runs do not count (Understand executions).

First attempts: 1,000 runs = 1,000 executions.

Retries: the docs state that each retry of a failed execution from the UI is a new execution (View all executions). So 100 retries add 100 executions.

Total: 1,000 + 100 = 1,100 executions — computed, not measured.

Two caveats that change the operational picture:

A retry resumes from saved node state, and a failed node reprocesses all its items, including items it already handled (View all executions). That is a correctness and duplicate-processing risk — a charge to your downstream systems — before it is a charge to your plan.
The “Retry on Fail” node setting is documented as part of the same execution; treat this as a secondary, community-sourced claim rather than a hard billing guarantee, and confirm it against your own execution logs before you rely on it.

The structural difference: on Zapier, adding retries added 600 tasks to a 3,600-task baseline (≈16%, computed, not measured). On n8n, adding the same 100 retries added 100 executions to a 1,000-execution baseline (10%, computed, not measured). Both percentages are arithmetic on the stated assumptions, not a measured benchmark, and they are not directly comparable as a price comparison — the unit prices are different and only the n8n plan prices are quoted here.

Make: the part you must check yourself

Make’s Retry error handler pauses a failed bundle, stores the error, the mappings and the remaining flow as an incomplete execution, then retries automatically or manually; you can also finish incomplete runs manually or let Make finish them automatically (Retry error handler). Make also offers Skip, Retry, Resume, Commit and Rollback error handlers (Make error handlers).

What we could not verify from the pages we checked: whether a module run that errors consumes an operation and credit, and exactly how a retried or resumed run is billed. Both are unverified here. Do not treat any statement about them as fact, including ours.

How to check: open the scenario’s history, select a failed bundle, and look at the operation and credit counts shown for that bundle and for its retry. Make’s operations help page displays a checkmark count for operations and a coin count for credits consumed (Make operations). Compare a bundle that failed on step 3 against one that succeeded on step 3, and compare the retried bundle against its original. That gives you your own measured numbers, which beat any worked example.

Why the cost model matters more than the failure rate

The failure rate is the same on all three platforms for the same workflow. What differs is what a failure charges.

On Zapier, a failure is cheap at the moment it happens and expensive at the moment you fix it, because the fix means replaying steps that already succeeded (Zapier task usage). On n8n, a failure is charged as a run, and a manual retry is charged as another run (Understand executions). On Make, the cost of a failure is a question you answer in your own scenario history.

That reframes the decision. If your workflow is step-heavy and the downstream steps are cheap to re-run, Zapier’s per-success billing means failures cost you little until you start replaying. If your workflow is wide — many steps, expensive actions — a 10% failure rate on 1,000 runs means hundreds of tasks of redone work. If you want failures to be operationally free, n8n’s per-run model makes the retry cost a fixed, predictable increment rather than a multiple of your step count.

Practical guidance

Count the steps, not the runs. On Zapier and Make, the unit of cost is inside the workflow. A four-step workflow and a twelve-step workflow fail at different prices.
Model the replay, not just the error. Most of the Zapier retry cost in the example comes from re-running successful steps, not from the error itself.
Prefer in-flow retries where the platform supports them. n8n’s “Retry on Fail” setting is described as staying within the same execution (secondary, community-sourced — verify it). A UI retry is a new execution either way.
Use error workflows, and know their price. n8n error-workflow runs do not count toward the execution quota (Understand executions). Set one per workflow in Workflow Settings, starting with an Error Trigger; the data includes execution id, error message and last node executed (Handle errors gracefully).
Watch the polling and webhook edge cases. A webhook trigger counts one execution per inbound request that activates the trigger; malformed requests that fail before the workflow starts do not count. A polling trigger counts only when new data is found (Understand executions).
Re-check n8n pricing before you publish or commit. The figures we saw when writing this — Starter 2.5k saved executions at 20 EUR/month billed annually, Pro 25k at 50 EUR/month, Enterprise 50k, with automatic retries listed as included — are time-sensitive. Confirm them on the n8n pricing page before quoting them in a business case.

FAQ

Does a failed step cost anything on Zapier?

No. Zapier counts a task for each successful action, and action steps that error or halt are not counted, nor are steps that never ran because the Zap errored (Zapier task usage). The cost of a failure arrives later, when you replay the run and the previously successful steps bill again.

Is an n8n retry charged as a new execution?

Yes, when you retry a failed execution from the UI, the docs state each retry is a new execution (View all executions). The in-flow “Retry on Fail” node setting is described as part of the same execution, though treat that as a secondary claim to verify in your own logs.

How do I find out what a failed run costs me on Make?

Check your scenario history directly. We could not verify from the documentation whether an erroring module run consumes an operation and credit, or how a retried bundle is billed, so we are not going to guess. Compare the operation and credit counts on a failed bundle against a successful one, then compare the retry against the original.

CodeIntel Log — code quality, debugging, and software engineering benchmarks
ToolBrain — tool reviews, LLM comparisons, and AI workflow guides

Cross-links automatically generated from NoCode Insider.