Pushbuild

Why self-hosted n8n slows down on sub-workflow fan-out

A common pattern is a parent workflow that loops over hundreds of items and calls a sub-workflow for each one. On a single self-hosted instance this can make the whole editor and every other workflow slow. n8n documents the settings that control how much runs at once.

At a glance

  1. Check how the parent calls the sub-workflowThe Execute Sub-workflow node has two modes: Run once with all items, which passes every item into one sub-workflow execution, and Run once for each item, which starts one execution per item.
  2. Know what concurrency control does not coverIn regular mode, n8n does not limit how many production executions run at once by default.
  3. Move to queue mode when one instance is not enoughQueue mode hands executions to separate worker processes.

Check how the parent calls the sub-workflow

  • The Execute Sub-workflow node has two modes: Run once with all items, which passes every item into one sub-workflow execution, and Run once for each item, which starts one execution per item.
  • If the sub-workflow can handle a list, Run once with all items starts far fewer executions.
  • The node's Wait for Sub-Workflow Completion option decides whether the parent waits for each sub-workflow to finish or moves on without waiting.

Know what concurrency control does not cover

  • In regular mode, n8n does not limit how many production executions run at once by default. n8n's docs say too many at once can thrash the event loop and make the instance unresponsive.
  • Setting a production concurrency limit (an environment variable described in n8n's self-hosting docs) queues production executions over the limit and runs them in FIFO order.
  • That limit applies only to executions started by a webhook or trigger. Sub-workflow executions are not counted, so it will not throttle a fan-out on its own. Batch the items in the parent instead.

Move to queue mode when one instance is not enough

  • Queue mode hands executions to separate worker processes. Each worker's --concurrency flag sets how many jobs it runs in parallel, and it defaults to 10.
  • n8n recommends a worker concurrency of 5 or higher. Low values across many workers can exhaust the database connection pool.

Updated 2026-11-02. General guidance, not advice for your situation; we scope each project in writing before any work starts.

Questions people ask first

Does the production concurrency limit slow down sub-workflows?

No. n8n's docs say it applies only to executions started by a webhook or trigger node, not to sub-workflow, manual or error executions.

Can I retry an execution that is waiting in the queue?

No. Queued executions can't be retried, and cancelling or deleting one removes it from the queue.

Tell us what you need built.

Tell us the process and the tools involved, or call. We reply with questions or a written scope.

hello@pushbuild.com

(617) 299-8887