Every n8n Cloud limit, by plan

n8n prices its Cloud plans by workflow executions per month. An execution is a single run of an entire workflow, however many steps it has, so a 50-node workflow costs the same as a 2-node one. As of November 2026, Starter includes 2,500 executions a month and Pro includes 10,000, both billed annually. Business (40,000) is self-hosted only, and Enterprise is custom. Steps, active workflows and users are unlimited on every plan.

The limits that actually stop workflows are concurrency, execution duration and memory. Starter runs 5 production executions at once, Pro 20 or 50 depending on tier, and Enterprise 200 or more. Executions over the limit queue in first-in, first-out order. The maximum execution duration is 5 minutes on Starter and 40 minutes on Pro and Enterprise. Each Cloud instance has a fixed amount of RAM, from 640 MiB on Starter to 4,096 MiB on Enterprise. A workflow that loads too much data can crash the instance.

Self-hosted n8n has no plan-based execution quota on the pricing page. By default there is no concurrency limit and no execution timeout, so the limits are the server's resources and any you configure. Values come from n8n.io/pricing and docs.n8n.io, verified November 12, 2026. Prices and limits change; check the pricing page.

Prices below are the annual-billing rates shown on n8n's pricing page in euros. All plans count executions the same way, by whole workflow runs, regardless of complexity or data volume. The pricing table lists overage fees as "Capped" for Starter and Pro. For Business and Enterprise, n8n says workflows continue running and overage charges may apply if you don't move to the next usage tier. The 14-day free trial has Pro features with a 1,000-execution limit and Starter-level compute.

Concurrency limits apply only to production executions, meaning those started by a webhook or trigger node. Manual runs, sub-workflow executions and error workflows don't count. Excess executions wait in a first-in, first-out queue. Queued executions can't be retried, and cancelling one removes it from the queue. You can see current active executions and your plan's limit at the top of a workflow's or project's Executions tab. The per-workflow Timeout setting can't exceed your plan's maximum on Cloud.

Each Cloud plan gets a fixed amount of RAM. n8n itself uses about 180 MiB of it, and working in the editor while heavy executions run uses more. If a workflow needs more memory than the instance has, the instance can crash and become temporarily inaccessible. n8n also prunes saved execution logs automatically, by count or by age, whichever limit comes first. If the database fills, it removes execution data but keeps the execution records.

Self-hosted n8n has no plan quota on executions in the pricing page's Community column. The practical limits are the ones you set or the ones your hardware imposes. By default, regular mode doesn't limit concurrent production executions and workflows have no timeout. n8n also doesn't restrict how much data a node fetches, so memory is the usual ceiling. These environment variables are the documented controls.

Concurrency limit: production executions over the limit don't fail. They sit in the queue and appear in the Executions list as queued until capacity frees up. Community threads describe them showing as "Starting soon / Queued."

Execution duration: a run that exceeds the plan's maximum or the workflow's Timeout setting is cancelled. In the main process the timeout is soft and takes effect after the current node finishes.

Memory: n8n may report Execution stopped at this node (n8n may have run out of memory while executing it). If the instance becomes unavailable you may see Problem running workflow, Connection Lost or 503 Service Temporarily Unavailable, and self-hosted logs show Allocation failed - JavaScript heap out of memory. n8n Cloud restarts the instance automatically.

Saved executions: old logs are pruned, but workflows keep running. n8n says reaching that limit "does not stop your workflows from running."

Process data in batches. n8n's own guidance is to split work into smaller chunks (for example 200 rows per execution instead of 10,000) and to move heavy per-batch work into a sub-workflow that returns only a small result.

Avoid memory-heavy patterns. Use fewer Code nodes where a built-in node will do, avoid manual executions on large datasets, and don't save successful production executions you don't need.

Smooth bursts. Concurrency limits queue work rather than dropping it. Rate-limit upstream webhooks or batch events so the queue doesn't build up behind slow runs.

Upgrade the plan for more concurrency, longer runs and more RAM, or self-host and size the server yourself, setting your own concurrency and timeout values.