What does n8n cloud pricing actually charge for?
n8n cloud pricing is built on the execution: one complete run of a workflow, from trigger to last node, counts as one execution no matter how many steps sit inside it. That is documented in n8n’s own pricing and docs, and it is the reason people arrive at the platform. A 12-step order workflow costs the same to run as a 2-step one.
The plan fee is the part of the bill that is easy to read. This article is about the rest of it, written for operators at $3M to $30M revenue on Shopify Plus or a paid subscription platform who are about to put real order, customer and support traffic through n8n.
The proprietary claim, stated plainly: the published price covers the platform, and for a brand at this size the platform is usually the smaller part of the total. Model tokens, runs you did not intend, and the hours someone spends building and watching the workflows are the line items that never appear on the pricing page.
If you are under the $3M floor, you are not who this is written for. A handful of workflows at low volume will not surface most of the costs this article covers (model tokens, retry and schedule executions, and build and monitoring labour), and a plain trial will tell you what you need.
Two sibling pieces cover neighbouring ground. n8n versus Zapier compares the platforms, and self-hosting n8n covers the no-plan-fee route. This one stays on the Cloud bill and what surrounds it.
Why execution pricing behaves differently from task pricing
Per-task tools charge for each action. Per-execution pricing charges for each run. The difference matters most for workflows with branching and loops, where a per-task tool multiplies the count and n8n does not.
The trade is that a single execution can do a lot of work, including work that is expensive elsewhere. An execution that loops over 200 line items and calls a language model for each one is still one execution on the n8n side. The cost moved. It did not vanish.
The first thing to internalise about n8n Cloud pricing is that the model makes the platform fee flat and pushes variable cost onto whatever the workflow calls.
What are the plan-level limits that matter more than the headline price?
The monthly execution allowance gets the attention. Other limits cause more incidents. Which ones exist, and at what values, is set by n8n’s current plan comparison, so this article names the categories and tells you what to check rather than quoting numbers.
Concurrency. How many executions can run at the same moment. A flash sale sends a burst of order webhooks. If the plan caps concurrent runs, the extra runs queue, and a workflow that tags fraud-risk orders may tag them after the fulfilment window has passed. Your monthly total can be well inside the allowance while this still bites.
Active workflows. Some plans limit how many workflows can be switched on at once. Brands hit this by building one workflow per store, per market or per integration, which is a sensible structure and a fast way to reach a cap.
Execution history retention. How long past runs stay inspectable. When a customer disputes something from six weeks ago, you want the run that touched their order. If history has rolled off, you are reconstructing from other systems.
Access controls. Role-based access, single sign-on and separate environments have been packaged on higher tiers in the past. Check which tier includes them. A brand with an agency, a contractor and two internal users needs to control who can edit a workflow that issues refunds.
Support level. Read what support is included, and on what response terms. If a workflow stops at 02:00 during a promotion, the answer to who you call is part of the price.
The practical step is a one-page sheet: one row per limit, one column for your peak value from the last busy period. Where your peak sits above or near a limit, that plan is the wrong plan, whatever the allowance says.
What is the first hidden cost: language-model tokens?
Any AI agent workflow calls a model, and the model provider bills separately. n8n does not include tokens in the plan. The provider bills the account whose API key sits in the credential, at that provider’s rates, which change.
For an agent that classifies support tickets, drafts replies or enriches product data, this is frequently the largest variable cost. It is also the one that scales in a way the n8n fee does not: the n8n count grows with the number of runs, while token spend grows with the length of each input and the number of model calls per run.
A workflow that summarises a ticket thread sends the whole thread each time. Long threads cost more. An agent that loops, calling the model, calling a tool, then calling the model again with the result, can make many model calls inside one execution.
There is no single benchmark to borrow here, and any figure you find is tied to a model, a prompt and a date. Work it out from your own data:
- Take a sample of real inputs, such as 50 recent tickets, and run them through the workflow in test.
- Read the token counts your provider reports for each call.
- Multiply by your monthly volume of that input, using your helpdesk’s real ticket count.
- Apply the provider’s current per-token rates, from their pricing page.
- Add a margin for prompt changes, because prompts only ever get longer.
Put it on its own line in the budget, separate from the n8n fee. Otherwise the fee looks like the whole cost and the token bill arrives as a surprise. For the design side of agents, the n8n AI agent guide explains where a model call belongs and where a plain rule is cheaper and safer.
How do schedules, webhooks and retries inflate the execution count?
The allowance is counted in executions, and several ordinary design choices create executions that do no useful work. Three deserve a check before you choose a plan.
Schedule triggers fire whether or not there is work
A workflow that runs on a timer counts each run. Here is an illustrative case, with numbers invented to show the arithmetic: a workflow set to run every 5 minutes to look for new subscription failures. That is 12 runs an hour, 288 a day, and 8,640 over a 30-day month. If the store only has failures on a fraction of those checks, most of those 8,640 executions found nothing.
Where the source system can push an event, use a webhook trigger, so the workflow runs when something happens. Where it cannot, lengthen the interval to match how quickly the business actually needs to react. A failed-payment check that runs hourly instead of every 5 minutes uses a twelfth of the executions, and the customer will not notice the difference.
Webhooks arrive more than once
Shopify and most platforms retry webhook delivery when they do not get a quick acknowledgement, and can deliver the same event twice. If each delivery starts an execution, you pay for both. Worse, if the workflow is not idempotent, it acts twice: two tags, two emails, two refunds.
Check the first node after the trigger. It should look up whether this event ID has been handled and stop if so. That stopped run still counts as an execution, but a cheap one that ends in a few milliseconds is far better than a second refund. Klaviyo failing to sync Shopify orders is a good example of how duplicate and missing events look downstream.
Retries multiply the bill during an outage
A retry setting on a node or a whole workflow re-runs on failure. Suppose a supplier’s API is down for an afternoon and each incoming run retries three times. The count for that workflow quadruples for the duration, and if the retries are on the workflow rather than the node, each retry can repeat work that had already succeeded.
Set retries on the specific node that calls the flaky service, use a wait between attempts, and cap the count. Then route the final failure to an error workflow that alerts a person. An error workflow is itself an execution, so an outage produces a second stream of runs. That is fine, but count it.
To see your real ratio, open the execution list after a week of production and group by workflow. Divide executions by the number of business events the workflow was meant to handle. A ratio near 1 is healthy. A ratio far above 1 tells you exactly which workflow to redesign.
What does building and running the workflows cost in people?
For a $3M to $30M brand the largest line in the total is often labour, and it is the line no pricing page can carry. Three kinds of work sit behind a working n8n deployment.
Build time. A first workflow that calls two APIs and writes to a third is quick to sketch. The version that survives production takes longer: pagination, rate limits, idempotency, field mapping for the awkward cases such as bundles, gift cards and partial refunds, and tests against real data. Estimate by counting the edge cases in your own catalogue and order types, not by counting nodes.
Credential and integration upkeep. Every connected app has a credential that can expire, be revoked when an employee leaves, or lose a permission when the vendor changes scopes. Somebody owns rotating them. If nobody does, workflows fail silently until a customer complains.
Monitoring. A workflow that fails without telling anyone is worse than one that never existed, because people trust it. Someone has to build the error workflow, decide who receives the alert, and read it. Treat this as recurring time on a calendar, and put a number on it using your own team’s hourly cost.
Change control. When a colleague edits a live workflow in the browser, the change is live at once. Brands with two or more editors need a process: a duplicate for testing, a named reviewer, and a record of what changed. Whether your plan includes separate environments affects how easy that is.
None of these have a published price, so the method is the answer: list the workflows, estimate hours for build, monthly upkeep and monitoring for each, and multiply by what an hour of that person costs you. Mark the estimate metric to confirm until a month of real logs replaces it. If the annual labour figure comes out several times the annual plan fee, that is normal, and it is the number to compare against an agency or an alternative.
How do you put together a total cost of ownership?
Combine the pieces into one sheet with these rows. The table shows what each line depends on and where its number comes from. Take from it that only the first row comes from n8n; every other row comes from your data or another vendor.
| Line item | Driven by | Where the number comes from |
|---|---|---|
| n8n Cloud plan fee | Executions, limits, tier features | n8n pricing page |
| Model tokens | Input length, calls per run, run volume | Model provider’s rates, your test sample |
| Extra executions | Schedules, duplicate webhooks, retries | Your own execution list after one week |
| Downstream app costs | API tiers on Shopify, helpdesk, ERP | Each vendor’s plan page |
| Build | Edge cases in your catalogue and orders | Your engineer’s estimate |
| Upkeep and monitoring | Credentials, alerting, change control | Recurring hours times hourly cost |
| Incident cost | What breaks when a workflow stops | Your own order and support volume |
The last row is the one teams skip. Estimate what a stopped workflow costs in an hour: orders not screened, tickets not routed, subscribers not notified. That figure sets how much redundancy and monitoring is worth paying for. A workflow that only tidies a spreadsheet does not need an on-call rota. One that screens orders for fraud does.
A worked example, with hypothetical numbers used only to show the sum. Say a brand runs one workflow on each of 3,000 monthly orders, with a 10% retry rate, plus a schedule trigger that runs every 15 minutes. The order runs come to 3,000 plus 300 retries, or 3,300. The schedule runs 4 an hour, 96 a day, 2,880 in a 30-day month. The total is 6,180 executions. Nearly half came from the timer, and the fix is a single settings change.
When does n8n Cloud stop being worth it?
There are four situations where the Cloud bill should prompt a rethink, and each has a different destination.
Execution volume driven by avoidable runs. If your execution audit shows most of your count is timers and duplicates, fix the workflows first. Moving platforms only carries the mess to a new invoice.
Data and network rules. If your security review will not permit customer data to pass through a third-party cloud, or if the system you need to reach sits behind a private network, self-hosting is the answer. It removes the plan fee and adds servers, backups, upgrades and an on-call person. The self-hosted guide covers that trade in detail.
Simple, low-volume needs. If you have a few linear automations and no in-house builder, a per-task tool can be cheaper in total because it takes less time to set up. Make versus Zapier shows how those pricing units differ.
Logic that has outgrown a workflow canvas. When a flow needs versioned code, tests and a review process, you are building software, and a canvas is an awkward place to do it. That is a legitimate reason to move some logic into code, while n8n keeps the glue.
n8n also does not belong in front of decisions where a wrong answer costs more than a human minute. Refunds issued without review, account bans, and anything running on data you know is unreliable should have a person approving the last step, whatever the platform.
For a wider view of what belongs in automation at all, ecommerce AI workflow automation and n8n use cases give the list of jobs that repay the effort.
Who is n8n Cloud not for?
n8n Cloud is not for a team with no one who can own a workflow after it is built. The pricing model rewards complex, multi-step automation, and complex automation needs an owner. If nobody on your side can read an error and tell whether it is a credential, a rate limit or a bad payload, you are buying a tool you cannot maintain, and the plan fee is the least of it.
n8n Cloud is also a poor fit for a team that wants a fixed monthly price for the whole outcome. Nothing in execution pricing gives you that, because the token bill and the labour vary with your volume and your ambition.
What should you do before choosing a plan?
Work out the all-in cost per workflow with your own numbers before you compare tiers. In order:
- List every workflow you intend to run and its trigger type.
- Pull monthly event counts from Shopify, your helpdesk and your subscription platform.
- Multiply by one plus your expected retry rate, then add schedule runs.
- Test a sample through any model calls and record the token counts.
- Read the current plan comparison for concurrency, active workflows, retention and access controls.
- Estimate build, upkeep and monitoring hours and price them.
- Put the sum next to the alternatives: a per-task tool, self-hosting, or having someone else run it.
Working out the all-in cost once takes an afternoon and prevents the two most common outcomes: a plan that is one tier too small, and a plan that is fine on paper with a token bill nobody budgeted.
Working out what n8n Cloud will cost, and whether the workflows are worth running at all, is an AI agents and automation problem more than a pricing problem: it comes down to which jobs deserve an agent, who owns it, and what it does when it fails. Pointerflow’s AI agents service is built for that scoping, so the all-in cost you work out is a number you can trust before you commit to a plan.
Sources
- No external figures are quoted. The article is written from n8n’s documented execution-based pricing model, which readers should confirm against n8n’s current pricing page and documentation, and from general engineering practice for costing workflow automation. Arithmetic examples are labelled illustrative.