An n8n automation project costs three things, and only one of them appears on a pricing page. The build is measured in working days. Monthly consumption is calculated from execution counts and calls to artificial intelligence models. Maintenance shows up nowhere before month three. Yet maintenance is what decides whether the project is still profitable a year later.
This article lays out the costing method Tandem applies on its automation projects, with vendor pricing checked in October 2026. If your question is about the licence itself, our article on n8n free versus paid covers the cloud tiers and the real cost of self-hosting. If you are new to the tool, start with the complete n8n guide.
The three cost lines of an n8n project
A serious automation quote always separates three things. The first is the build, meaning scoping, construction and testing. You pay for it once. The second is operations, covering the n8n subscription, model calls and third-party APIs. You pay for it monthly and it moves with volume. The third is maintenance, covering error recovery, connectors that change and evolving business rules.
Merging these three lines produces two opposite mistakes. Some companies budget only the build and discover the usage bill in the second quarter. Others compare twenty-euro subscriptions and conclude that automation is free. Both are wrong by the same factor, because the dominant line is neither of those.
What does it cost to build an n8n automation?
Building the workflow is rarely the long part. On our projects it accounts for roughly a quarter of the effort. Scoping and getting access together weigh about as much, and those two are what blow up timelines. Wiring a node takes minutes. A service account, an API token and an IT sign-off take days.
This is not only our observation. On the official n8n forum, an August 2026 thread asked integrators where the time actually goes when you run five clients or more. One of them names access as the real bottleneck. Technical setup takes hours, the credential loop takes days. That wait stays invisible in every plan.
What n8n counts as an execution
The n8n quota is not counted in steps or nodes. The vendor documentation sets out three rules that change the estimate entirely. A webhook bills one execution per inbound request, even when the body is empty. When one workflow calls another, only the parent execution counts towards the quota. And only production executions are counted, so manual test runs stay free.
The practical consequence is simple. A conversational agent that checks context, finds a slot and then books an appointment fires three inbound requests. A thousand conversations therefore consume three thousand executions, not a thousand. The first costing reflex is to pull the real execution count over a week of production and divide it by the number of requests handled. That ratio beats any theoretical estimate.
The sub-workflow rule opens a lever in the other direction. Splitting a large workflow into modules called by a parent costs nothing extra in quota. Conversely, merging two agent tools into a single round trip halves consumption on that step.
What does it cost to run an n8n workflow per month?
Take a case you can actually price. A workflow handling 10,000 requests a month fits the n8n Pro plan. It is billed at 50 euros a month on annual commitment according to the vendor's public pricing in October 2026. On the model side, Anthropic's documentation prices the handling of 10,000 support tickets with a small model at roughly thirty euros. The order of magnitude is the same with other providers for a model in that class.
Tooling for a workflow at that volume therefore stays under a hundred euros a month, excluding business APIs. That is good news, and it is also the trap. A costing exercise that stops there announces a budget that is wrong by an order of magnitude, because it leaves supervision out of the calculation.
| What pushes the bill up | Why | The lever |
|---|---|---|
| The number of tool calls per request | Every inbound request counts as one execution | Merge two tools into a single round trip |
| The model you pick | A large model costs several times a small one on the same volume | Keep the large model for the steps that genuinely reason |
| The context resent on every call | Input tokens are paid on every execution | Turn on prompt caching, a cache read costs a tenth of the price |
| Calls that fail and get retried | A retry burns quota and tokens without producing a result | An explicit error branch rather than a blind retry |
| Requests abandoned halfway | A call hung up after twenty seconds has already consumed its share | Measure their share before committing to a per-unit price |
Maintenance, the line nobody puts in the quote
A workflow is not a frozen deliverable. Vendor APIs change, business rules evolve, and edge cases always arrive after go-live. The more decisions a workflow delegates to a model, the heavier this load becomes, because probabilistic behaviour has to be verified rather than read.
I devoted a whole video to this question, and it is the warning I end on. Rushing to an autonomous agent when simple automation would do means putting your finger in a maintenance gearbox. Change one word in the prompt and the whole chain behaves differently. A deterministic automation gets fixed by reading a log. An agent gets re-evaluated against a set of cases.
The second danger of maintenance is its silence. In the same n8n forum thread, one integrator describes an exchange queue that grew for months without anyone noticing. Every execution came back green, and the receiving system simply never acknowledged anything. Since then he puts a two-sided counter on every client, what was sent against what was accepted.
- An error branch on every workflow, notifying a named human rather than a generic mailbox.
- A daily heartbeat, so a workflow that has stopped running reports itself.
- A periodic reconciliation, between what the workflow produced and what the receiving system actually recorded.
- A per-workflow list of credentials, written on day one, otherwise offboarding a provider turns into archaeology.
Build or buy, the calculation that settles it
Before costing a development, check that an existing product does not already cover the need. I went through this choice in a LinkedIn post on build versus buy in July 2025, and the maths has not moved. A bought solution deploys in days, with predictable cost and continuous updates. An internal build takes at least three months and a dedicated team for a mere prototype, with a fully loaded cost in the tens of thousands of euros a month.
The sorting rule fits in one sentence. Buy when your process looks like everyone else's, in support, recruitment or marketing. Build when it is your differentiator. n8n often sits in the middle, because it lets you assemble bought building blocks without writing a full application.
Between the two, a well-scoped n8n automation remains the cheapest way to cover the ninety per cent of standard cases in a process. That is the logic Tandem applies on its autopilot automation engagements, and the reason we keep n8n rather than custom development on most projects.
How to cost an n8n project before you start
The method has three steps, and I detailed it in my newsletter on companies seeing no return on their AI investment. The first step analyses the team involved, its headcount, the fully loaded cost of an employee and the unit cost of an operation. The second measures flows, volumes, average durations and friction points. The third compares estimated annual gains against the build cost plus the usage cost.
That third addition is the one companies forget. Models carry a per-call price, and that price belongs in the calculation from day one. A project that pays for itself on paper while ignoring monthly consumption often turns out neutral once the full bill is on the table.
On a first project, the safest route is to start with two or three simple cases that pay off quickly, and keep one more ambitious track in parallel. That is exactly what a use-case audit produces, a list ranked by impact and feasibility rather than a hunch.
Who funds an automation project in France?
Part of the budget can be financed. Bpifrance's digital transformation loan targets companies with 2 to 49 employees created more than three years ago. The France Num factsheet puts it at 5,000 to 75,000 euros, over three to five years, with no personal guarantee. The first repayment falls nine to twelve months after release of the funds.
The important point for an n8n project is the list of eligible expenses. It covers software purchases, but also consulting and technical assistance, plus training and change management. In other words, the human part of the project is inside the scope, and that is the part that weighs the most.
So what budget should you plan for an n8n project?
Plan a three-line budget and refuse any quote that shows only one. The build is counted in days, around 40 per cent of which go into scoping and getting access. Operations stay modest at small and mid-sized business volumes, a few tens of euros a month for the licence and about as much for the models. Maintenance is provisioned in monthly hours, and that is the line that decides the final result.
The real trade-off sits on the level of automation you pick, well ahead of the tool itself. An autonomous agent costs more to supervise over time than a deterministic workflow doing the same job. If you are hesitating between the two, our comparison of n8n against Make and Zapier and our tutorial on building an AI agent with n8n give you both ends of the spectrum. And if you want a figure for your own case, Tandem works as an n8n agency on scoping as well as production.
One last budget warning. An instance left on an old version eventually costs a full migration in one go, whereas regular upgrades spread the load. Our guide to migrating to n8n 2.0 shows what that debt looks like in practice.
