Control Concurrency (Cloud Limits: Starter 5 / Pro 20 Parallel)

In n8n Cloud, each plan limits how many workflow executions can run simultaneously: the Starter plan allows 5 parallel executions, the Pro plan 20, and the Enterprise tier is, according to the n8n pricing overview at 200 or more parallel executions. If the limit is exceeded, n8n automatically queues additional executions and processes them on a FIFO basis as soon as capacity becomes available again. For companies that regularly process larger volumes of data, for example bulk imports, bulk mailings, or working through long lists via webhook triggers, this limit is a factor that should be known before building a workflow, otherwise executions can pile up unnoticed in the queue. As of: July 2026.

How the concurrency limit works in n8n Cloud

According to the n8n documentation on Cloud concurrency the limit applies exclusively to production executions, meaning those started by a webhook or a trigger node. Manual test runs, sub-workflows, and error workflows do not count toward it and continue to run independently of the limit. If the number of simultaneous production executions exceeds the plan value, further runs are not rejected but wait in a queue. Important in practice: waiting executions cannot be retried, and anyone who cancels a waiting execution removes it completely from the queue. After an instance restart, n8n resumes the waiting runs up to the capacity limit and re-queues the rest. The current utilization level can be seen directly in the executions tab of a project or workflow.

Impact on bulk processing

For example, anyone who triggers 500 records individually as separate executions via a webhook automatically gets a queue in the Starter plan after the first 5 simultaneous runs, even if n8n itself does not show an error message. This delays overall processing but does not cause data loss, as long as no one cancels the waiting executions. It becomes more critical with time-critical processes, for example when an external system expects a quick response and the queue unpredictably extends the response time. During instance restarts too (for example due to maintenance windows), the queue can briefly build up further before it is worked through.

Workarounds via batching

Instead of triggering many individual production executions in parallel, the load can be managed within a single workflow. Common approaches in practice:

• Use Split in Batches: Records are processed in groups within a single workflow run, instead of starting a separate production execution for each record. This significantly reduces the number of simultaneous executions.
• Plan wait times: A Wait node between batches relieves downstream systems (for example APIs with their own rate limits) in addition to n8n's internal queue.
• Use sub-workflows: Since sub-workflow executions, according to the documentation, do not count toward the concurrency limit, processing logic can partly be structured so that fewer production top-level executions occur simultaneously.
• Throttle trigger frequency: For bulk uploads, it is worth timing the triggering process (for example a cron job or an upstream import) so that it keeps the number of simultaneous webhook calls below the plan limit from the outset.

Honestly, none of these tricks replace a higher plan tier if significantly more real parallelism is permanently needed. Batching shifts the load in time, but it does not create additional capacity.

Self-hosted: full control over the limit

Anyone who operates n8n themselves has more flexibility: according to the n8n documentation on concurrency control the limit is disabled by default in self-hosting and can be set specifically via the environment variable N8N_CONCURRENCY_PRODUCTION_LIMIT, including in queue mode. This means more control over your own infrastructure, but also more personal responsibility: without a deliberately set limit, an instance can become overloaded during a sudden spike in load. This is exactly where sound planning comes in, for example when deciding whether a cloud plan or your own infrastructure fits a company's actual data volume and control requirements. NordFlux supports exactly this assessment as part of its n8n consulting.

Frequently asked questions about concurrency control in n8n

What happens to executions that exceed the limit?

They are not discarded, but automatically placed in a queue and processed in the order they arrived (FIFO) as soon as capacity becomes available again.

Does the limit also apply to manual test runs?

No. According to the documentation, the concurrency limit in n8n Cloud only affects production executions via webhook or trigger node. Manual executions, sub-workflows, and error workflows are excluded.

Can I simply restart a waiting execution?

No, waiting executions cannot be retried. Anyone who cancels them removes them completely from the queue, and they then need to be triggered again.

Is upgrading to the Pro plan worthwhile because of the concurrency limit?

That depends on the actual processing volume. Anyone who regularly needs significantly more than 5 simultaneous production executions will experience queue delays more often on the Starter plan. Batching can cushion this, but for permanently high volume it does not replace a higher plan tier.