When choosing between n8n, Zapier, and Make, the deciding factor is often not available integrations or UI polish. It is the billing unit: the specific unit that is metered when a workflow runs. Two workflows can look equally complex on a diagram, yet cost very differently depending on whether pricing counts executions, tasks, or operations.
This matters most for long, node-heavy pipelines. A typical content automation setup can contain many processing steps, conditional branches, and multiple API calls. In those cases, execution-based billing can keep costs predictable, while per-step billing can grow linearly with the workflow’s internal structure.
Billing unit: the hidden variable behind “similar” workflows
Each platform uses a different metric for cost estimation:
- n8n typically bills per execution. A single workflow run counts as one execution regardless of how many nodes it includes.
- Zapier typically bills per task. Each action or step that runs is metered as its own unit.
- Make typically bills per operation. Each module run is counted, often expressed as credits.
Most comparison pages focus on features, but the vendor framing is explicit: an agent with many internal steps may be “one run” in execution-based pricing, while the same agent may map to dozens or hundreds of billed tasks in per-step pricing.
A self-hosted n8n pipeline with 209 nodes
A concrete scenario involves a self-hosted n8n instance running a content pipeline for a small publication. The system uses:
- 10 production workflows
- around 209 nodes across the automation stack
- a single cloud box to host the full orchestration layer
The most frequent question about that setup is not “why n8n,” but whether a hosted per-task tool would have been easier. Ease of setup can be real, but the billing unit determines whether “easier” becomes “expensive” at scale.
Why long workflows punish per-task billing
In a node-based workflow, each node can represent a unit of work such as fetching data, calling an LLM, parsing output, validating conditions, or writing results back to a database. With per-task billing, every metered step adds to the bill. With execution-based billing, all those internal steps collapse into a single billed run.
Three example workflows illustrate the difference when internal structure is mapped 1:1 to a per-task billing model:
| Workflow | Nodes | n8n cost per run (execution-based) | Per-task cost per run (node-to-task mapping) |
|---|---|---|---|
| SF-2 script generator | 27 | 1 execution | ~27 tasks |
| SF-4 render | 28 | 1 execution | ~28 tasks |
| SF-5 publisher | 33 | 1 execution | ~33 tasks |
SF-2, for example, includes a sequence such as: webhook intake, Postgres fetch, prompt assembly in a code step, an HTTP call to an LLM, parsing, guard conditions using conditional “If” nodes, a write-back, and a final response. Twenty-seven nodes can still execute in seconds, yet per-task pricing can treat each node-equivalent step as a separate billable unit.
How to model costs when workflows have many steps
To make cost comparisons actionable, a model should focus on how many workflow runs occur and how many internal steps execute per run. A few key points improve accuracy:
- Nodes are not always tasks: some nodes may be non-executing or behave like configuration. The strict node count can be an overestimate for per-task meters.
- Loops and splits multiply: branching, iterating over items, or repeatedly processing segments can increase billed steps faster than node count suggests.
- Conditional paths matter: workflows that sometimes skip steps can reduce billed tasks relative to a worst-case mapping.
- Tier boundaries and monthly resets: subscription tiers can change what is included vs metered later. Cost modeling should apply the same billing period and tier rules used by the provider.
Practical takeaway: execution-based billing favors complex pipelines
For automation that is intentionally broken into many small steps, execution-based billing can significantly reduce the sensitivity of cost to workflow structure. In contrast, per-task or per-operation pricing tends to scale with internal workflow complexity because each internal step that runs becomes a billable unit.
For teams operating pipelines with dozens of nodes per workflow and frequent runs, the billing unit becomes the primary variable in cost forecasting. Feature sets may determine whether a platform can build the workflow at all, but the billing unit determines whether the platform can do it affordably over time.
Quick rule of thumb: If a workflow is designed as a readable chain of many steps, execution-based pricing usually stays stable per run, while per-step pricing often grows roughly with the number of steps that actually execute.
Leave a Reply