This page contains one affiliate link, marked where it appears. It costs you nothing extra.
TL;DR
- Zapier and Make bill per item processed, not per workflow. Four actions looping over 20 rows is 80 billable units per run, not 4.
- n8n bills per execution. The same run counts once whether the workflow has 3 nodes or 30, and whether it processes 1 item or 200. This is the whole difference between the models.
- Zapier does not bill the trigger, failed actions, or most of its built-in tools (Formatter, Paths, Filter, Delay, Looping, Digest, Storage, Tables). Code by Zapier, AI by Zapier and calls to a sub-Zap do use tasks. It is easy to over-count.
- The fix is almost never a shorter workflow. It is filtering earlier, batching, or moving the fan-out heavy job to per-execution billing.
The bill came in higher than the plan you thought you were on, and none of the automations you built last month look big enough to explain it. The one you suspect is probably not the one spending the money.
Three actions processing 200 spreadsheet rows costs 600 tasks on Zapier’s published task definition. Thirty actions processing one form submission costs 30. The shorter workflow is 20 times more expensive, and nothing on the pricing page tells you that.
Call it the fan-out tax: the gap between what your automation looks like it should cost and what it actually costs, created entirely by how many items each run touches. It is invisible if you are counting steps, which is exactly what everyone does.
Neither figure is an estimate. Each vendor publishes its billing unit: Zapier counts one task per successful action, n8n prices on workflow executions “regardless of complexity”, and Make counts one operation per module run per bundle, which costs one credit for non-AI apps. Every number here is arithmetic on those definitions, first read on 23 August 2026 and re-checked against each vendor’s own page on 10 October 2026.
What the fan-out tax actually is
Fan-out is how many items a single run processes. A form submission is one item. A run that loops over 20 spreadsheet rows is 20 items.
On Zapier and Make, every action inside that loop is billed once per item. So four actions over 20 items is 80 billable units for a single run, not four. On n8n, the same run counts once regardless.
The tax is the difference between those two models, and it compounds with volume. It is why the billing unit matters more than any individual price on any pricing page.
Where each platform attaches its billing meter. The loop is the only step that multiplies, and n8n is the one platform whose meter sits outside it.
Why counting steps misleads you
The intuition almost everyone brings to automation pricing is that a bigger workflow costs more. It is a reasonable intuition and it is wrong on two of the three major platforms.
Here is the arithmetic, using the billing formulas each vendor publishes. R is runs per month, A is billable actions inside the loop, I is items per run, B is billable actions outside the loop:
| Platform | What one run costs | Why |
|---|---|---|
| Zapier | (B + A × I) | One task per successful action. The trigger is free, and so are most built-in tools. |
| n8n | 1 | One execution per run, whether the workflow has three nodes or thirty. |
| Make | (1 + B + A × I) | One operation per module run per bundle, one credit each for non-AI apps. The extra 1 is the trigger module, which Make does bill. |
Sources for each row: Zapier’s task usage article, n8n’s pricing page and Make’s operations article, all checked 10 October 2026.
Notice what is missing from the n8n row: A and I do not appear at all. Workflow length and item count are both irrelevant to the bill. n8n is measuring something else entirely, which is why its column barely moves while the other two climb.
Now the two workflows from the opening, on Zapier:
- The “big” workflow. 30 actions, 1 item per run: 30 tasks.
- The “small” workflow. 3 actions, 200 items per run: 600 tasks.
The three-step automation costs 20 times more than the thirty-step one. Both look identical on a pricing page, which advertises a task allowance and says nothing about what generates tasks.
What each platform actually bills
Over-counting your Zapier usage is its own kind of expensive, because it pushes you onto a higher plan than you need.
Zapier does not bill: the trigger step, failed actions, Filter and Paths steps, Tables and Forms steps, or the Formatter, Delay, Looping, Digest, Zapier Manager and Storage apps. A Zap that looks like eight steps may only have four billable actions. Not every built-in tool is free, though: Code by Zapier uses at least one task per run, AI by Zapier uses tasks by model tier, and the Call a Sub-Zap and Return From a Sub-Zap steps cost one task each, plus every action inside the sub-Zap. All of this is listed on Zapier’s task usage article, checked 10 October 2026.
n8n does not bill by node. Its pricing page prices every paid plan on monthly workflow executions “regardless of complexity”, with “unlimited steps” per execution, and lists the self-hosted Community Edition separately as a download from GitHub. Self-hosting moves the cost from the n8n invoice to your hosting bill, and the catch is worth stating plainly: running n8n on your own laptop only works while that laptop is on, which defeats the purpose for anything scheduled overnight. An always-on server is a monthly cost of its own, so price one before you count self-hosting as free.
Make bills the trigger. This is the one asymmetry people miss when moving from Zapier. Make’s operations article counts a trigger check as one operation, then one operation per bundle for every module after it: its own example of a trigger returning 10 form responses into three modules totals 31 operations. That is why the Make formula carries that extra + 1. One naming note worth getting right: credits and operations are not the same thing. Operations count what a scenario did; credits are what you pay. Make’s credits article says one operation equals one credit for non-AI apps, but some modules are tagged at 2 or 10 credits per operation, and AI modules can be billed on tokens, so a scenario heavy on AI steps burns credits faster than its operation count suggests.
Is metered billing just a scheme to make you dip into extra usage? The suspicion is reasonable and it is worth settling before you touch a plan selector. The meter itself is not the trick. Zapier declines to charge for the trigger, for failed actions and for most of its built-in tools, and all three vendors publish what they count. What none of them publish is how many units your own work generates, and that is the number an overage is made of. It is also the only number here that is yours to measure.
How to work out your own number
Comparing sticker prices across three pricing tabs feels like doing the research, and it cannot answer the question. The variable that decides your bill is not printed on any of those pages. It is your own item volume, and the direction it is heading. Pick an entry plan without knowing it and you meet the same ceiling a few months later, on a different vendor’s invoice.
You need four numbers, and the third one is the one that decides your bill:
- Runs per month. How many times the trigger fires.
- Billable actions outside the loop. Steps that happen once per run no matter how many items came in: a summary email, a final log entry.
- Items per run. The fan-out. This is the field that usually decides everything.
- Billable actions inside the loop. Steps that touch each item: create a record, send an email, update a row.
Then apply the formula for your platform from the table above. If you would rather not do the arithmetic by hand, our automation cost calculator does exactly this for all three platforms at once and tells you which plan tier the result lands in. It runs in your browser and needs no signup.
A worked example, at 500 runs a month with four billable actions and no fan-out at all:
| Platform | Counted as | Monthly usage |
|---|---|---|
| Zapier | trigger free, filter free, 4 actions billable | 4 × 500 = 2,000 tasks |
| n8n | the whole run counts once | 500 executions |
| Make | trigger module + 4 action modules | 5 × 500 = 2,500 credits |
Now raise items per run from 1 to 20 and the Zapier figure becomes 40,000 tasks while the n8n figure stays at 500. Nothing about the workflow changed except what it was pointed at.
How to cut the fan-out tax
Almost everyone starts by shortening the workflow. It is the least effective move available, because it attacks A when the problem is I.
Filter before the loop, not inside it. A filter that runs per item still costs you the actions that ran before it. Moving the filter upstream so fewer items enter the loop reduces I directly, and on Zapier the filter step itself is free.
Batch where the destination allows it. Many APIs accept an array. One action writing 20 rows is one billable action; twenty actions writing one row each is twenty. This single change is often the difference between two plan tiers.
Move the fan-out heavy job, not everything. You do not have to migrate your whole automation stack. If one workflow is generating most of your usage because it loops over large lists, that specific workflow is the candidate for per-execution billing. Leave the small, infrequent, trigger-once automations where they are.
Count what is actually billable before you upgrade. Given how much Zapier does not charge for, the honest first step is recounting. A workflow that looks like it needs a higher tier often does not.
If you recount and the number is still high, the fan-out is genuinely large and per-execution billing is the honest answer. Want to try that kind of builder before you move anything? Start on Make’s free plan. It is enough to learn whether the builder suits you before any money changes hands. Make’s free plan includes up to 1,000 credits per month, according to Make’s pricing page, read by the owner on 12 October 2026 (the page loads its figures with JavaScript, so we could not read it by script). (That is an affiliate link. It costs you nothing extra, and we use it because Make is the one of the three whose affiliate program we are actually in.)
Where this leaves you
None of these vendors are hiding this. All three document their billing unit plainly, and all three then publish a pricing page quoting the price of a thing you cannot yet count. That is the whole gap. Steps are visible, so people count steps. Items are invisible until the invoice arrives.
The practical version is one sentence: your bill scales with how many things you process, not with how long your workflow is. Find which of the four numbers above is the large one. The fix is usually obvious from there, and it rarely involves rebuilding anything.
For the wider picture of where each platform makes sense, how the three platforms price at volume works through the full comparison. If you are earlier than that and still deciding what to automate at all, the manual parts of client work worth handing to a machine is the better starting point.
What is the fan-out tax?
What counts as a task on Zapier?
What are the task limits in Zapier?
What is the difference between a Zap and a task?
Why does my n8n usage not change when I add steps?
Is a shorter workflow cheaper?
Are Make credits the same as Make operations?
