n8n Price: Why Execution Billing Changes the Bill

What n8n price actually charges for

n8n price is built around workflow executions, not completed tasks. Every time a workflow runs from its trigger to its final node, that’s one execution, whatever happens inside it — three steps or thirty. That single design choice is the reason a published price on n8n’s pricing page tells you almost nothing about what your bill will look like once real order volume, real webhooks and real retries hit the system.

If you run automation for a $3M–$30M ecommerce brand on Shopify Plus or a comparable subscription platform, you’ve almost certainly compared n8n against Zapier and found the numbers hard to line up. That’s not a pricing-page failure on your part. It’s because the two tools charge for fundamentally different units of work, and no calculator on either vendor’s site converts cleanly between them. The current figures — plan names, execution caps, per-task allowances — change often enough that quoting them here would be stale within a quarter; check n8n’s pricing page directly for what applies to you today.

Execution-based billing versus Zapier’s task model

Zapier counts a task as one action completed inside a Zap — a row added to a spreadsheet, an email sent, a record updated. A single Zap that runs a trigger and takes four actions typically counts as multiple tasks against your monthly allowance. n8n counts differently: one full run of a workflow, from trigger to last node, is one execution, regardless of how many nodes that workflow touches on the way through.

The practical effect shows up at the extremes. A workflow with a single trigger and fifteen internal steps — pull an order, check inventory across three warehouses, apply a discount rule, update a CRM record, post to Slack, log to a spreadsheet — costs the same one execution in n8n whether it has three steps or thirty. Under Zapier’s model, that same fifteen-step chain would likely be built as fifteen separate tasks, or split across multiple Zaps chained together, each consuming its own allowance.

Flip it around and the advantage reverses. A workflow that fires constantly but does very little each time — a webhook that checks stock levels every few minutes and only occasionally needs to act — burns through n8n’s execution count fast, because every check is its own execution whether or not it does anything. Under Zapier’s model, a trigger that runs and finds nothing to do often doesn’t consume a full task.

Comparing “n8n price” to “Zapier price” as two numbers on a spreadsheet misleads you before you’ve even started. The right comparison is your actual workflow shape — how many triggers, how often they fire, how many steps sit inside each run — mapped against each vendor’s current billing unit. Nobody sells that comparison as a table, because it’s specific to your store’s automation footprint, not a fact about either product.

What the published price doesn’t include

The number on a pricing page is the licence or subscription cost. It is not the cost of running automation as part of your operations. Four line items sit outside that number and rarely make it into the decision before someone signs up.

Execution volume at real scale. A workflow you tested with a handful of manual runs behaves nothing like the same workflow processing every order during a flash sale. If your checkout, fulfilment or customer-service automations trigger on every order, every abandoned cart, or every support ticket, your execution count during peak trading can be several multiples of your average month. Plan for peak, not average, when you estimate what tier you’ll actually need — and revisit that estimate after your first real sale event, not before it.

Credential and connection maintenance. Every workflow that touches Shopify, Klaviyo, a payment processor or a warehouse system holds a credential — an API key or OAuth token — that expires, gets revoked, or breaks silently when the connected service changes its authentication method. Someone has to notice when a workflow stops running because a token expired, and that someone is a recurring, unbudgeted line item, not a one-time setup cost.

Error handling that actually alerts a human. A workflow that fails silently is worse than one that never existed, because the team assumes it’s still working. Building retry logic, dead-letter handling and an alert that reaches a person — not just a log entry nobody reads — takes real engineering time on top of the workflow’s core logic, and that time doesn’t appear on any pricing page.

Version drift. n8n ships updates regularly, and node behaviour occasionally changes between versions — a field gets renamed, a default setting shifts, an integration’s API version bumps. Self-hosted instances that don’t stay current accumulate risk; instances that update aggressively risk breaking a workflow that depended on the old behaviour. Either way, someone owns that decision on an ongoing basis.

None of these four items are exotic. They’re the ordinary cost of running any piece of connected infrastructure. They’re absent from the price comparison because a pricing page describes licensing, and licensing is the smallest part of what it costs to keep automation reliable.

Self-hosting: the licence is free, the maintenance isn’t

n8n’s self-hosted option is one of its strongest selling points against Zapier, which has no comparable self-hosted tier. The licence cost for self-hosting is genuinely low or free depending on the edition you choose. That fact gets repeated often enough that it starts to sound like self-hosting is the free option. It isn’t — it’s the option where the cost moves from a subscription line to a labour line.

Running n8n yourself means you’re responsible for the server it runs on: provisioning it, patching the operating system, backing up its database, and scaling it if execution volume grows past what a single instance handles comfortably. You’re responsible for upgrading n8n itself, which means testing that your existing workflows still behave the same way after each update — because a workflow that silently changes behaviour after an upgrade is a worse failure mode than one that’s simply down. You’re responsible for uptime: if the server hosting your self-hosted instance goes down at 2 a.m. during a flash sale, nobody’s on-call rotation catches that unless you built one.

For a team of one or two people handling marketing operations alongside everything else, this labour cost is usually the deciding factor against self-hosting, whatever the licence savings look like on paper. For a team that already runs infrastructure — an engineer who owns deployment pipelines, monitoring and on-call as part of their normal job — the marginal cost of adding one more self-hosted service is much lower, and the licence savings become real.

The question worth asking before choosing self-hosting isn’t “can we afford the server.” It’s “who owns this when it breaks at 11 p.m. on a Saturday, and is that a job we’re willing to give them.” If there’s no clear answer, the cloud-hosted option’s higher subscription price is usually buying you an on-call team you don’t have to build yourself.

What a workflow at scale actually costs

Here’s an illustrative example, not a quote of anyone’s real bill. Say a $10M ecommerce brand runs four automations: order sync from Shopify to a fulfilment system, an abandoned-cart flow that checks cart status every fifteen minutes, a customer-service ticket router, and a weekly inventory reconciliation. The order sync and ticket router each fire once per relevant event — a few hundred executions a day between them at typical volume. The abandoned-cart check, because it polls on a schedule rather than firing only when needed, generates an execution every fifteen minutes whether or not there’s a cart to check — that’s 96 executions a day from that one workflow alone, most of which find nothing to do.

That’s the pattern that catches teams out: a workflow triggered by a schedule rather than by an actual event inflates execution count regardless of how much real work happens. The fix isn’t to abandon scheduled checks — sometimes polling is the only option an integration supports — but to know which of your workflows are event-triggered (cheap, proportional to real activity) and which are schedule-triggered (a fixed execution cost regardless of activity), and to price the schedule-triggered ones against their actual value before assuming they’re worth running every fifteen minutes rather than hourly.

When n8n stops being worth it

n8n’s pricing model earns its keep when your workflows are complex — many steps chained together — and event-triggered, so execution count tracks real order and customer activity rather than a fixed polling schedule. It stops being the obvious choice in a few specific situations.

It stops being worth it when most of your automations are simple, single-action tasks — sync this field, send this email — because that’s exactly the shape Zapier’s task model was built to price efficiently, and n8n’s execution counting doesn’t reward simplicity the same way. It stops being worth it when your team has no engineer who can own workflow logic and error handling as an ongoing responsibility, because the tool’s flexibility becomes a liability the moment nobody’s watching what it does when an upstream API changes. And it stops being worth it — for the self-hosted option specifically — the moment “who fixes this at 2 a.m.” doesn’t have a named answer.

That list doesn’t make n8n the wrong choice for a $3M–$30M operator. It makes it a tool whose real cost only shows up once you map your own workflow shapes against its billing unit, not against the number on its pricing page.

Who n8n’s pricing model doesn’t fit

n8n isn’t the right fit for a team that wants to sign up and never think about infrastructure again — that’s what a fully managed, opinionated platform is for, and n8n’s flexibility is the opposite trade. It isn’t the right fit for a brand under the $3M revenue floor with no dedicated operations capacity; the maintenance burden described here scales down slower than the workflow complexity does, so a small brand often pays more in owner or generalist time than the licence would ever cost. And it isn’t the right fit for automations where a wrong result costs more than a human minute to fix — refund decisions, anything touching payment reversal, anything where an unattended retry loop could double-charge a customer. Those belong behind a human checkpoint regardless of which automation tool runs the rest of the workflow.

Getting the pricing model right is really a question of where automation sits in your operating stack, not just what the monthly bill says. That’s an AI agents and automation design decision — which workflows are event-triggered versus scheduled, who owns error handling, what runs self-hosted versus managed — and it’s covered in more depth on Pointerflow’s AI agents service page.