Most teams can forecast their n8n bill to within one tier before they build anything, because the billing unit is unusually easy to count. n8n Cloud meters workflow executions — not steps, not data volume, not users — and n8n's own documentation confirms that plans differ by usage limits and computing power rather than by what the workflows are allowed to do. If you know how many times a month a thing happens in your business, you know roughly what you will pay. The hard part is knowing which things count, and designing so that one business event doesn't quietly become six executions.
What the listed tiers actually give you
As publicly listed on n8n's pricing page, the cloud tiers run: Starter at €20/month billed annually with 2,500 workflow executions, Pro at €50/month billed annually with 10,000 executions, and Business at €667/month billed annually with 40,000 executions and unlimited steps. Monthly billing is dearer, at roughly €24 and €60 for Starter and Pro respectively.
Two things to be clear about before you put those numbers in a budget. They are euro-denominated, so the AUD figure you actually pay depends on the exchange rate on the day, your card's conversion margin and whatever GST treatment applies to your billing region. And they are list prices observed in October 2026 — check the live checkout before you commit, because plan structures change and older comparison articles describing n8n as self-host-only or as billing by workflow count are now simply wrong.
The shape worth noticing is the gap between Pro and Business. Ten thousand executions to forty thousand is a four-fold capacity increase for roughly thirteen times the price. Nobody buys Business for the executions.
Counting the billing event, not the business process
The mistake in most forecasts is counting processes instead of triggers. A single "new order" automation is one workflow, but it fires once per order. At 2,500 orders a month it consumes the entire Starter allowance on its own, with nothing left for anything else.
Build the forecast from triggers. For each automation you intend to run, write down what fires it and how often that thing happens in a normal month:
| Trigger type | What drives the count | Example |
|---|---|---|
| Webhook | One per inbound event | Shopify order, Stripe payment, form submission |
| App trigger | One per matched record | New Xero invoice, new HubSpot deal stage change |
| Schedule | One per scheduled run, regardless of records processed | Every 15 minutes = ~2,900/month |
| Polling node | One per poll that finds new data; empty polls do not count | Driven by real event volume, not poll frequency |
| Manual / test | Does not count toward quota | Editor runs while building and debugging |
That table is where most sizing exercises go wrong. A schedule trigger set to every five minutes runs around 8,700 times a month and consumes an execution each time, whether or not there was anything to do — more than three times the Starter allowance spent on nothing. Meanwhile a nightly batch that processes four hundred records in a single run is one execution. The relationship between business volume and execution volume is set entirely by design, not by how busy you are.
Then add the categories people leave out:
- Retries. A workflow that fails and retries on a transient API error consumes capacity each time it runs. An integration that is flaky two per cent of the time is a two per cent surcharge on that workflow's allowance.
- Error-handling workflows. If you have configured an error workflow to catch failures and post to Slack or create a ticket, that is a separate workflow running separately.
- Test and development runs. n8n's execution documentation, as at October 2026, states that manual executions from the editor while building or testing do not count toward the execution quota. Development is effectively free; what is not free is testing by firing the production webhook or letting the schedule run, which meters normally.
- Sub-workflows. n8n's documentation states that sub-workflow executions do not count toward the monthly execution quota — only the top-level parent execution counts. That makes decomposition cheap: breaking a monolith into a parent and three children does not triple your consumption.
Add it up, then add 40 per cent. Volumes grow, new workflows get added by whoever is enthusiastic, and the month you run a campaign is not the month you forecast on.
Workflow design changes the bill more than volume does
Because n8n charges per execution with unlimited steps on the listed plans, the economics reward consolidation in a way that per-task and per-operation tools do not. Three lessons follow.
Batch where latency allows. A schedule that runs hourly and processes all pending records is 720 executions a month. The same work as an event-triggered workflow at 5,000 events a month is 5,000 executions. If the business can tolerate an hour's delay, batching is a 7x reduction in consumption for identical output.
Consolidate related triggers. If an order fires three separate top-level workflows — create invoice, notify warehouse, update CRM — that is three executions per order. One parent workflow with branching logic, or one parent calling three sub-workflows, is one. The trade-off is blast radius: a single run that does three things fails all three when it fails, so this is a judgement about how independently those steps need to fail and be replayed.
Do not schedule what can push. The saving here is narrower than it looks. A built-in polling node only bills when it finds new data, so swapping it for a webhook mostly buys you latency rather than quota. The expensive pattern is the hand-rolled one: a schedule trigger plus an HTTP request node that checks for changes every few minutes and almost always finds none. That bills every single run. Where the upstream system supports webhooks, replacing that pattern is usually the single largest saving available.
This is the part where designing the execution model before the workflows get built pays for itself several times over. The difference between a naive and a considered design on the same business volume is routinely the difference between Starter and Pro, or Pro and an uncomfortable conversation about Business.
Concurrency is a separate constraint to quota
Having executions left in the month does not mean a workflow will run immediately. n8n documents concurrency limits that vary by plan — the number of production executions that can run at the same time. For steady trickle-feed workloads this never surfaces. For bursty ones — a batch of inbound webhooks when an upstream system catches up, or a morning spike of form submissions — executions queue.
Queueing is usually fine. What is not fine is a workflow that was written assuming immediate execution and now runs eleven minutes later, or retry logic that fires while the original is still queued and produces duplicate invoices. Size for your peak minute, not your monthly average, and make workflows idempotent so that a replay is safe.
Why Business gets bought
Nobody pays €667/month for 40,000 executions. They pay it for what n8n's documentation describes as the governance capabilities on the paid tiers: SSO, separate environments, projects, scaling and support. That is the real upgrade trigger, and it usually arrives in a predictable way. A prototype works. It becomes load-bearing. Someone asks who can edit it, how a change is tested before it touches production, what happens when the person who built it leaves, and whether there is an audit trail.
Forecast that moment rather than being surprised by it. If an automation will touch money, customer data or a regulated process within twelve months, the governance tier is a line item in the business case from the start — not a shock in month seven.
Self-hosting moves the cost, not the discipline
The free Community Edition can be self-hosted indefinitely, and independent hosting documentation describes running it without a vendor subscription — you pay for the server instead. That is genuinely attractive at high volume, and it is the right answer for organisations that need data to stay on infrastructure they control.
Be careful with the assumption that self-hosting means unmetered. n8n's execution documentation states that paid plans carry an execution-limit quota whether they are Cloud or self-hosted, so the licensed self-hosted tiers are sized the same way the cloud ones are. Only the free Community Edition takes the meter off the table.
What moves rather than disappears is the operating burden: hosting, backups, monitoring, version upgrades, security patching, incident response and someone who can be reached when a queue stalls at 2am. For a low-stakes internal workflow, a small server is cheap. For revenue-critical automation, the reliability requirement dominates the licence price, and you have replaced a €50 subscription with a responsibility.
The model bill sits on top
If your workflows call an LLM, the execution allowance is only one of two meters. Model usage is billed separately on input and output tokens, and prompt size is the variable people underestimate — an agent that attaches a long document to every call costs far more than its per-call rate suggests. Retries and tool calls multiply it. If you need regional processing for data-residency reasons, OpenAI's pricing documentation notes a 10 per cent uplift on those endpoints. Worth knowing too: hosting the automation platform in Australia does not mean an external model provider receives the data in Australia. Verify that connector by connector.
The first move
Pull one month of real trigger counts from the systems you intend to automate — order volume, form submissions, invoices created, records changed — and write them next to the trigger type each workflow would use. Multiply schedules out by frequency. That single sheet tells you which tier you are in before anyone writes a node.
If you would rather see the number than build the sheet, our automation ROI calculator will take your trigger volumes and give you a sized tier, a design that keeps you inside it, and a straight answer on whether the workflow is worth automating at your volume — including the cases where it isn't.