Fast answer: what n8n concurrency settings control
An n8n concurrency setting limits how many production executions — runs started by a webhook or trigger node — are allowed to run at the same moment, not how many run per day. On n8n Cloud, your plan sets this limit, shown in the Executions tab. On self-hosted n8n, N8N_CONCURRENCY_PRODUCTION_LIMIT controls it, defaulting to -1, meaning concurrency control is off. Executions beyond the limit queue and run first-in-first-out. A low limit reduces simultaneous load on downstream systems, but it does not create a per-workflow lock, deduplicate events, or guarantee idempotent side effects.
Documentation verified 6 August 2026
Running slots, queued work, and completed work
Think of n8n’s production concurrency limit as a fixed number of running slots. When a webhook or trigger node starts a new production execution, n8n places it into a running slot if one is free. If every slot is occupied, the execution goes into a queue instead of starting immediately.
Queued executions wait until a running slot frees up, then n8n starts them in the order they arrived — first in, first out. That FIFO behavior is the ordering n8n documents. n8n does not publish a guaranteed wait time for queued work, because the wait depends entirely on how quickly the executions ahead of it finish.
Once an execution finishes — successfully or with an error — its slot becomes available again, and n8n pulls the next queued execution into it. If your n8n instance restarts while executions are queued, n8n resumes queued executions up to the concurrency limit on startup and re-queues the rest.
Two operational details matter for queued executions: you cannot retry a queued execution directly, and cancelling or deleting one removes it from the queue entirely rather than pausing it. To see how many executions are running versus queued, check the top of a project’s or workflow’s Executions tab, which shows the active count alongside your configured limit.
Which executions count toward the limit — and which don’t
Concurrency control in n8n applies to one category of execution only: production executions started by a webhook or trigger node. Several other execution types run outside this limit entirely, regardless of how many are active:
- Manual executions — runs you start from the editor while building or testing a workflow.
- Sub-workflow executions started with the Execute Sub-workflow node.
- Error workflow executions — runs of a workflow configured to handle another workflow’s failure.
Evaluation test runs, used to compare workflow behavior against a metric during AI-focused development, also sit outside the production concurrency limit. They draw from a separate per-plan limit — sequential for Community and Pro, three in parallel for Business, and five for Enterprise — which self-hosted instances can override with N8N_CONCURRENCY_EVALUATION_LIMIT, or adjust per test run from the Run Test popover.
This separation matters when diagnosing a queuing problem: if manual test runs feel slow, the production concurrency limit is very unlikely to be the cause.
n8n Cloud versus self-hosted configuration
The two deployment types set the same kind of limit through different controls.
| Aspect | n8n Cloud | Self-hosted n8n |
|---|---|---|
| Who sets the limit | n8n, based on your plan | You, via an environment variable |
| Where to view it | Top of a project’s or workflow’s Executions tab | Application logs; a future n8n version is documented to add UI visibility |
| Queue mode | Available on Cloud Enterprise by contacting n8n; concurrency there governs jobs per worker, not the whole instance | Optional; enabled with Redis and one or more worker processes |
| Changing the limit | Requires a plan change | Set N8N_CONCURRENCY_PRODUCTION_LIMIT and restart, following your own hosting provider’s restart procedure |
On n8n Cloud, concurrency in regular mode applies instance-wide. Cloud’s queue mode, an Enterprise-only option, is a distinct mechanism where the concurrency setting governs how many jobs each worker runs in parallel rather than the whole instance. Self-hosted n8n follows the same regular-mode-versus-queue-mode split, with one environment variable spanning both.
N8N_CONCURRENCY_PRODUCTION_LIMIT, exactly as n8n documents it
On self-hosted n8n, N8N_CONCURRENCY_PRODUCTION_LIMIT is the single setting that governs production concurrency in both regular mode and queue mode. Its documented default is -1, and in regular mode a value of -1 disables concurrency control — n8n places no cap on how many production executions run simultaneously. Setting it to a positive integer, for example 20, enables the limit, and n8n begins queuing anything beyond that number.
In queue mode, the same variable takes precedence over the worker-level --concurrency flag whenever it is set to a value other than -1. If N8N_CONCURRENCY_PRODUCTION_LIMIT is left at -1, queue-mode workers fall back to the --concurrency flag or its own default. That is worth checking before assuming queue mode automatically respects a number you set elsewhere.
Keep N8N_CONCURRENCY_PRODUCTION_LIMIT separate from other execution settings that use different sentinel values. EXECUTIONS_TIMEOUT, for instance, also defaults to -1, but it governs how long a single workflow may run before n8n cancels it — not how many run at once. Separately, EXECUTIONS_DATA_PRUNE_MAX_COUNT uses 0 to mean “no limit” for stored execution history, a different sentinel on a completely different setting. Treat each variable’s default on its own documented terms rather than assuming -1 and 0 behave the same way across settings.
Applying a new value requires restarting the n8n process, following whatever restart procedure your own hosting setup already uses — this article does not prescribe a specific deployment command, since that depends on how you run n8n. Evaluation runs draw from a separate limit, N8N_CONCURRENCY_EVALUATION_LIMIT, which by default follows your license tier: one at a time on Community and Pro, three in parallel on Business, and five on Enterprise.
Reading the symptoms: a cause/decision matrix
Concurrency-related symptoms are easy to misread. This matrix separates what each one can indicate from what it does not, by itself, prove.
| Symptom | What it can indicate | What it does not prove |
|---|---|---|
| Executions sitting in the queue | The production concurrency limit is reached for the instance, or worker in queue mode | That the limit is set incorrectly — queuing under load is the mechanism working as documented |
| Queue draining slowly | Running executions are taking longer than expected, or the limit is conservative relative to incoming volume | A concurrency bug — n8n does not publish a guaranteed drain rate |
| Downstream API returning rate-limit errors | Too many simultaneous calls are reaching that API | That n8n’s concurrency limit is the wrong value; it may need to reflect the API’s own rate limit, not n8n’s capacity |
| A business effect appearing twice | A retry, duplicate webhook delivery, or workflow logic issue upstream of concurrency | That concurrency control failed — it limits executions running at once, it does not deduplicate events or requests |
| High CPU, memory, or database connection pressure | The current limit is letting more simultaneous work through than the instance’s resources support | That raising the limit will fix it — the underlying resource ceiling still needs headroom |
A safe sequence for tuning the limit
Change one variable at a time, and confirm each step before moving to the next.
- Measure the baseline. Record current CPU, memory, database connection count, queued-execution count, and any downstream API error rate before changing anything.
- Identify the actual bottleneck. Confirm whether queuing comes from instance resource limits, a slow downstream service, or simply high incoming volume relative to a conservative limit.
- Choose one conservative change. Adjust
N8N_CONCURRENCY_PRODUCTION_LIMIT, or request a Cloud plan change, by a modest increment rather than removing the limit outright. - Observe under real load. Watch the same metrics from step one over a representative period, not just a single quiet hour.
- Roll back if needed. If resource pressure, error rates, or downstream failures increase, revert to the previous value and reassess before trying again.
Never raise a limit blindly. n8n ties concurrency control directly to protecting instance stability — CPU, memory, database connections, worker capacity, API rate limits, and downstream system capacity all need headroom before you increase how much can run at once.
What n8n concurrency settings don’t solve
Concurrency control is instance-wide capacity management, not a per-workflow mutex or a business-key lock — that follows from the setting’s documented scope, which applies to production executions across the whole instance, or per worker in queue mode, not to a single workflow’s exclusivity. Reading it as “my workflow can never overlap itself” is an inference; a limit of one at the instance level is the closest approximation, not a documented guarantee.
Four gaps are worth naming directly:
- Per-workflow exclusivity. A concurrency limit of one serializes eligible production executions across the instance — including other workflows competing for the same slot — not just repeat runs of a single workflow. For a design that keeps one specific workflow from overlapping itself, see stopping overlapping n8n workflow executions.
- Event deduplication. Concurrency limits how many executions run at once; it does not recognize that two incoming requests represent the same underlying event.
- API idempotency. A retried outbound call can still repeat a mutation on a downstream system even when n8n is serializing executions. See Remove Duplicates versus idempotency in n8n for the distinction.
- Business reconciliation. If a duplicate side effect already happened, concurrency settings offer no mechanism to detect or reverse it afterward.
Workflow timeout (EXECUTIONS_TIMEOUT and the per-workflow Timeout After setting) is a separate control again — it cancels a single execution after too much time elapses, and has nothing to do with how many executions run simultaneously. Execution-data retention, how long finished execution records are kept, is a third, unrelated setting. For the general mechanics of duplicate webhook triggers, see why an n8n webhook can fire twice.
Verification checklist after a configuration change
- Confirm the new
N8N_CONCURRENCY_PRODUCTION_LIMITvalue, or Cloud plan limit, is what you intended, from the Executions tab or your deployment’s environment configuration. - Watch the queued-execution count over a representative traffic period to confirm it drains rather than growing unbounded.
- Check downstream API error and rate-limit responses for a change, up or down.
- Monitor CPU, memory, and database connection usage against your baseline.
- Confirm no new duplicate business effects have appeared — and if they have, treat that as a separate problem from concurrency, not evidence the limit is wrong.
Rollback and safety note
Frequently asked questions
Does a lower concurrency limit mean fewer total executions per day?
No. It limits how many run at the same moment, not the total count over a day. A low limit with fast-finishing executions can still process a high daily volume; it just processes them a few at a time.
Does n8n show which executions are currently queued?
You can view active execution and limit counts at the top of the Executions tab, and self-hosted logs record executions entering and leaving the queue. n8n’s documentation notes that a future version will add queue visibility directly in the UI.
Can I retry a queued execution?
No. Documented behavior states you cannot retry a queued execution; cancelling or deleting it removes it from the queue instead.
Does raising N8N_CONCURRENCY_PRODUCTION_LIMIT automatically give my instance more capacity?
No. The setting controls how many executions are allowed to run at once — it does not add CPU, memory, database connections, or worker processes. Raising it without headroom in those resources can worsen instability rather than fix it.
Is a concurrency limit of one the same as a per-workflow lock?
Not by documentation. A limit of one serializes eligible production executions at the instance level, which can approximate exclusivity for a single busy workflow, but it also applies to every other workflow’s production executions competing for that same slot.
Sources and change log
- n8n Docs: Understand concurrency (Cloud)
- n8n Docs: Control concurrency (self-hosted)
- n8n Docs: Executions environment variables
- n8n Docs: Enable queue mode
- n8n Docs: Configure workflow settings
- n8n Docs: All executions
Change log: Initial publication, 6 August 2026.
