n8n Concurrency Limit: How to Set It (2026 Guide)
Oct 26, 202614 min read
The n8n concurrency limit is the maximum number of production executions running at the same moment, a ceiling that matters to anyone who has also worked with tools like Activepieces. Self-hosted, you set it with N8N_CONCURRENCY_PRODUCTION_LIMIT; on n8n Cloud, your plan fixes it.
Anything over the limit waits in a queue instead of failing. Every figure you need comes from n8n's documentation and pricing page, not from this article.
Read the four facts below as the whole definition, because the limit is narrower than most forum threads assume.
n8n concurrency limit defined: the direct answer
- It counts production executions running at once, not executions per hour or per day.
- It's set by an environment variable when you self-host, and by your plan on Cloud.
- Executions over the limit queue and run as slots free up.
- Manual runs from the editor are excluded.
Other automation tools, Activepieces among them, have their own run caps, so don't carry this definition across to them.
What counts toward the limit
Click Execute workflow in the editor and that run doesn't use a slot; only production executions count, meaning runs started by a trigger such as a webhook, a schedule or an app event.
Nothing is dropped and nothing errors when extra executions arrive; they queue. The cost is latency: a webhook caller waiting on a response sees the delay, and a backlog of slow workflows can hold everything behind them.
If your logs show executions in a waiting state while the instance looks idle, suspect this queue before you suspect a bug.
I'm not quoting the default here; it's documented on n8n's environment variables page. Setting the variable to -1 turns the limit off. That doesn't add capacity. You have only removed the gate, so the database and workers now take the load directly.
This takes minutes, not a project: automate it in Activepieces free.
Where n8n applies concurrency limits
Look for a concurrency limit in exactly three places. Those are nowhere in regular mode unless you set one, on each worker in queue mode, and on your plan in n8n Cloud; manual executions are excluded from all three.
That's why removing a cap never makes the system faster by itself; it only moves the queue to whatever sits behind it.
| Where | Who sets it | Default or figure | What it governs | Manual runs |
|---|---|---|---|---|
| Regular mode | You, via environment variable | -1 (unlimited) | Production executions in the single process | Not counted |
| Queue-mode workers | You, per worker | --concurrency 10 |
Jobs each worker pulls from Redis at once | Not counted |
| n8n Cloud | n8n, by plan | Starter 5, Pro up to 50 | Simultaneous production executions on the account | Not counted |
| Activepieces | — | — | — | — |
As the table shows, only one of these three is a number n8n picks for you. The other two are numbers you chose, which is how people end up with a limit that looks generous and a box that falls over.
Self-hosted regular mode
With the default at -1, nothing is capped and every webhook hit starts an execution in the same process. You get no protection from the setting; the ceiling is whatever one Node process and your database can survive.
In the n8n scalability benchmark, a single large instance topped out at 16.2 requests per second, so past that rate you're trading latency or failed requests for nothing.
Self-hosted queue mode workers
Unless you override it, each worker takes --concurrency 10. Ten workers at the default is a hundred simultaneous jobs, so the real ceiling is workers multiplied by the flag, not the flag.
On a small setup the same benchmark measured queue mode at 72 requests per second, and 162 on a large one, so you'll need larger infrastructure to achieve higher throughput.
That's roughly ten times the single-instance figure on a large setup, and it means scaling out buys more than raising the flag on one machine.
n8n Cloud plan ceilings
You don't choose the number on Cloud. Starter allows 5 concurrent executions and Pro goes up to 50. Starter costs 20 € per month, so a burst of six webhooks has the sixth waiting.
For 30 € more, Pro at 50 € per month gives ten times the headroom. Business is 667 € per month, a jump you only justify once the Pro ceiling is what you actually hit.
Change the n8n concurrency limit step by step
On a self-hosted instance this is about fifteen minutes and four changes: the production limit variable, a restart, the worker flag, and a test that proves the limit holds.
Start with the production limit variable. Put it in the environment: block of the n8n service in docker-compose, or export it in the shell that launches n8n.
- Set
N8N_CONCURRENCY_PRODUCTION_LIMIT=5. Five is a deliberately low test value, so the queue is easy to see. Raise it once the test passes. - Restart with
docker compose up -dso the container is recreated. A plainrestartcan keep the old environment. - Read the startup logs with
docker compose logs n8n. They should report the limit you set. If they show nothing or the old value, the variable never reached the container, and everything after this is meaningless.
Stage 2: set concurrency on each queue-mode worker
Raise the limit on the main instance and the workers get no faster. Each worker takes its own flag: start it with n8n worker --concurrency=5, or set it in the worker service's command: in docker-compose.
Restart every worker, because a single forgotten one keeps its old value and quietly becomes your real ceiling.
Stage 3: prove it with 20 parallel webhook calls
Build a workflow with a Webhook trigger followed by a Wait node set to a minute or so.
Activate it so the calls count as production executions, then fire 20 requests at the production URL at the same time, for example with a shell loop that backgrounds each curl.
Open the executions list. Some runs should show Running, up to your limit, and the rest should show Queued. If all 20 show Running, the limit isn't applied. If none ever leave Queued, the workers aren't picking up jobs.
On Cloud, stage 4 is where you check the plan ceiling instead. There is no variable to set. The ceiling comes with your plan, so run the same 20-call test and read the result as a plan limit.
If runs queue earlier than you expected, the fix is a plan change, not a setting.
You can follow the rest of this with the builder open. Start free, no card.
Why higher concurrency limits fail
When something behind the limit, the database, the worker count or the plan, was never sized to match, the higher number fails. That's why the number you typed in is rarely the number you get.
Database and memory limits on n8n concurrency
When the limit goes up and the database doesn't, Postgres answers FATAL: sorry, too many clients already. Concurrency set to 50 on SQLite means 50 executions fighting over a single-writer file, so you see lock errors and slower runs, not throughput.
Per-worker times worker count
Because each worker keeps its own pool of database connections, and the pool defaults to 10, adding workers multiplies the demand, which Postgres counts against max_connections, 100 by default according to pgpedia.
Two workers ask for 20 connections, which leaves plenty of room. Five ask for 50, half the budget gone before anything else connects.
Ten ask for 100, which is the entire default allowance, and the main instance, your BI tool and any admin session have nowhere to sit. Twelve ask for 120, so the database refuses connections the moment the workers warm up.
{{chart}}
Past that line, either raise max_connections (and the memory to back it), put a connection pooler in front, or run fewer workers with higher per-worker concurrency. Scaling out is not free.
Confusing concurrency with monthly execution quota
Two different numbers get mixed up here. Concurrency is how many production executions run at once. The monthly execution quota on Cloud is how many you may run in total.
Even a plan that allows plenty of simultaneous runs can still stop you on the 30th, and a generous quota still queues you if the concurrency ceiling is low.
If runs stall while the month is young, look at concurrency. If they stop late in the month, look at the quota.
When another tool's concurrency control fits the job
When the quota is fine and the thing choking is a downstream API or database, a limiter outside n8n fits better than raising n8n's own setting. The limit you need belongs where the pressure lands.
Only one of these options limits parallel runs of a workflow; the others limit what a workflow does to someone else. The table shows what each option actually caps and where you set it.
| Option | What it caps | Where configured | When to use it |
|---|---|---|---|
| Activepieces per-workflow limit | Parallel runs of one workflow | Workflow settings in that tool | You are already on it and want a per-workflow cap |
| Upstream rate limiting | Requests per window to one service | The service, or a gateway in front of it | The target keeps answering 429 Too Many Requests |
| Batching | Items handled per call or per run | Inside the workflow | One run fans out into thousands of calls |
| A queue service | Consumer throughput, with bursts buffered | The queue's consumer settings | Spikes arrive faster than anything downstream can drain |
Read the "what it caps" column before you pick. Matching the cap to the failure is the whole job.
Non-product options: batching and upstream queues
Usually the error is 429 Too Many Requests from someone else's API. A higher n8n limit makes it worse because more runs hit that API at once. Fix it at the source of the pressure.
Split large item lists into batches with a pause between them, so one execution stops opening a thousand connections. Where the target supports it, put a rate limiter or gateway in front of it so every caller is throttled, not only n8n.
If bursts are the real shape of your traffic, put a queue service between the sender and n8n. Webhooks land in the queue, and a consumer drains it at a rate you choose.
That's a design decision, not a setting, and it keeps working when you change plans or add workers.
How other platforms handle concurrency limits
Activepieces documents a concurrency limit per workflow, which is a cap on parallel runs of that one flow. Its core is MIT-licensed, and the repository's LICENSE file places the enterprise directories under packages/ee/ on a separate commercial licence.
The repository on GitHub has 25,226 stars and 744 integrations under packages/pieces/community, and the current docs cover plan availability, so teams can accelerate development with hundreds of pre-built integrations and proven community support.
As a comparison point, the Activepieces setting shows what a per-workflow cap looks like; it is not a fix for n8n. It doesn't touch your n8n database, workers or plan ceiling, and those are what the next section turns to.
What Activepieces does about this
The failure this article describes is a cap that someone raised without looking at what sits behind it. Activepieces handles the part of that problem it can reach.
Its concurrency limit is set per workflow, so you cap parallel runs of the one flow that is hammering a downstream API and leave every other workflow alone.
n8n's limit is a single instance-wide value, which is why one noisy workflow ends up crowding out the rest.
That is a narrower claim than "this fixes concurrency". A per-workflow cap doesn't size your database, and it doesn't tell you how many connections your workers will demand. It does mean the number you type in matches the thing you are protecting.
If the failure is 429 Too Many Requests from one service, you limit the workflow that calls that service. Check the Activepieces docs for which plans include the setting before you plan around it.
You can also check what you are depending on. The core is MIT-licensed, and the repository's LICENSE file puts the enterprise directories under packages/ee/ on a separate commercial licence, so the boundary between free and paid code is a file you can read.
The repository on GitHub shows 25,226 stars and 744 integrations under packages/pieces/community, so teams can avoid custom integration development for supported platforms. Those figures show how much of the integration surface is open and inspectable.
They don't show how it will behave under your load, so run the same 20-parallel-call test from earlier against any workflow you move, and read the result before you trust the cap.
Frequently asked questions
Does the n8n concurrency limit apply to manual executions? No. The limit caps production executions, the ones started by triggers and webhooks on active workflows.
Manual runs from the editor sit outside it, so a test click still fires while production runs wait. That's also why a workflow can look fine while you build it and stall once it goes live.
Can I set a different concurrency limit per workflow in n8n?
Not as a native setting. The limit is instance-wide, one value shared by every workflow. If one noisy workflow starves the rest, the fix lives in your design: split it onto its own instance or worker pool, batch its work, or throttle at the trigger.
Raise the global number and the noisy workflow only gets more room to crowd out the others.
Why are my n8n executions stuck in Queued?
Because every concurrency slot is taken, or because nothing is picking jobs up. Check the first cause by looking for long-running executions holding slots, such as a workflow waiting on a slow API.
Check the second by confirming workers are running and connected to the same Redis and database as the main instance.
When a worker has crashed or points at the wrong Redis, it looks identical from the editor: jobs pile up and nothing moves.
Does n8n Community Edition have a concurrency limit?
It depends on the mode. In regular mode you can set a production concurrency limit through configuration.
In queue mode, concurrency is set per worker, so your real ceiling is the per-worker value multiplied by the number of workers, bounded by what your database and Redis can handle.
On Cloud, the plan sets its own ceiling, and that one isn't yours to change.
How do I check the current limit on my instance?
Read the configuration the process actually started with, not the one you remember writing.
On a self-hosted instance, inspect the environment variables on the main container and on each worker, since they can differ. Then compare against the startup logs, which report the concurrency value in use.
On cloud, the limit comes from your plan, so check the plan details in your account rather than hunting for a variable.
Related reading
References
Build it
Set this up in minutes.
No code required. Connect your accounts, and Activepieces runs it from there.
Start free Talk to sales
