Understand concurrency
Too many concurrent executions can cause performance degradation and unresponsiveness. To prevent this and improve instance stability, n8n sets concurrency limits for production executions in regular mode.
Any executions beyond the limits queue for later processing. These executions remain in the queue until concurrency capacity frees up, and are then processed in FIFO order.
Concurrency limits
n8n limits the number of concurrent executions for Cloud instances according to their plan. Refer to Pricing for details.
You can view the number of active executions and your plan's concurrency limit at the top of a project's or workflow's executions tab.
Details
Some other details about concurrency to keep in mind:
Concurrency control applies only to production executions: those started from a webhook or trigger node. It doesn't apply to any other kinds, such as manual executions, sub-workflow executions, or error executions.
Test evaluations don't count towards production concurrency limits. They use a separate per-plan limit for how many test cases can run in parallel within a single test run: self-hosted Community and n8n Cloud Pro run 1 (sequential), self-hosted Business runs 3, and Enterprise (both n8n Cloud and self-hosted) runs 5. You can adjust the value for a given run from the Run Test popover. Refer to Metric-based evaluations for details.
You can't retry queued executions. Cancelling or deleting a queued execution also removes it from the queue.
On instance startup, n8n resumes queued executions up to the concurrency limit and re-enqueues the rest.
Comparison to queue mode
Concurrency in queue mode is a separate mechanism from concurrency in regular mode. In queue mode, the concurrency settings determine how many jobs each worker can run in parallel. In regular mode, concurrency limits apply to the entire instance.
Related resources
Last updated
Was this helpful?