The Fan-Out Tax (Why a 3-Step Zap Can Cost 20x a 30-Step One)

This page contains one affiliate link, marked where it appears. It costs you nothing extra.

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 counts one execution per workflow run, and Make counts one credit per module action. Every number here is arithmetic on those three definitions, read on 23 August 2026.

Key Takeaways

• 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, its built-in tools (Formatter, Paths, Filter, Delay, Looping, Digest, Storage, Tables), or failed actions. 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.

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:

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, or any of its built-in tools. That list is longer than it looks: Formatter, Paths, Filter, Delay, Looping, Sub-Zap, Digest, Zapier Manager, Storage, Tables and Forms. A Zap that looks like eight steps may only have four billable actions.

n8n does not bill by node. The Community edition has no execution limit at all. The real cost is hosting, and the catch is worth stating plainly. Running n8n on your own machine only works while that machine is on, which defeats the purpose for anything scheduled overnight. A small always-on VPS is roughly five dollars a month.

Make bills the trigger. This is the one asymmetry people miss when moving from Zapier. Make charges one credit per module action including the trigger module, which is why the Make formula carries that extra + 1. Routers and error handlers are free, and filters live on connections rather than being modules, so they do not count. One naming note worth knowing: Make’s pricing page now uses the word credits, while older writing about the platform still uses operations. They are the same unit.

How to work out your own number

You need four numbers, and the third one is the one that decides your bill:

1. Runs per month. How many times the trigger fires.
2. 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.
3. Items per run. The fan-out. This is the field that usually decides everything.
4. 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:

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 gives you 1,000 credits a month, enough to learn whether the builder suits you before any money changes hands. (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.