Bug Description

When running n8n in queue mode with more than 10 active workflows, the editor process registers unbounded EventEmitter listeners on the Bull Queue object (one global:completed and one global:failed listener per active workflow).

Since Node.js has a default limit of 10 listeners per EventEmitter, this immediately triggers MaxListenersExceededWarning on boot — before any execution runs — and causes a progressive memory leak that eventually kills the editor process with OOM (exit code 137).

The warning appears during the workflow activation loop on startup, confirming this is a structural issue in how listeners are registered, not a runtime behavior problem.

To Reproduce

1. Deploy n8n in queue mode (EXECUTIONS_MODE=queue) with Redis and PostgreSQL
2. Activate more than 10 workflows (cron or webhook triggers)
3. Check editor logs on boot — MaxListenersExceededWarning appears immediately
4. Monitor memory usage over time — it grows progressively
5. After a few hours the editor process is killed by the kernel (exit 137)
6. The entire queue freezes: running jobs become zombies, new jobs stay queued as "Starting soon" indefinitely

Expected behavior

The editor process should call queue.setMaxListeners() proportionally to the number of active workflows, or remove listeners when they are no longer needed. Memory usage should remain stable regardless of the number of active workflows.

Log on every boot (appears before any execution runs, during activation loop):

Initializing n8n process n8n ready on ::, port 5678 Version: 2.14.2 Building workflow dependency index... Start Active Workflows: Activated workflow "Workflow 1" (ID: xxx) Activated workflow "Workflow 2" (ID: xxx) ... Activated workflow "Workflow 11" (ID: xxx) (node:7) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 global:completed listeners added to [Queue]. MaxListeners is 10. (node:7) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 global:failed listeners added to [Queue]. MaxListeners is 10. Activated workflow "Workflow 12" (ID: xxx) ... Activated workflow "Workflow 53" (ID: xxx) Finished building workflow dependency index. Processed 53 draft workflows. Editor is now accessible via: https://[redacted]

---

Docker Swarm service history confirming OOM kill:

NAME DESIRED STATE CURRENT STATE ERROR n8n_editor.1 (current) Running Running 3h ago n8n_editor.1 (previous) Shutdown Failed 3h ago "task: non-zero exit (137)"

---

Docker stats — editor memory at rest after fresh boot:

CONTAINER CPU % MEM USAGE / LIMIT MEM % n8n_editor 0.03% 320.9MiB / 2GiB 15.6%

---

Editor stack (relevant excerpt):

services: n8n_editor: image: docker.n8n.io/n8nio/n8n:2.14.2 environment: - EXECUTIONS_MODE=queue - EXECUTIONS_TIMEOUT=3600 - EXECUTIONS_TIMEOUT_MAX=7200 - OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true - QUEUE_BULL_REDIS_HOST=[redacted] - DB_TYPE=postgresdb - DB_POSTGRESDB_HOST=[redacted] deploy: resources: limits: cpus: "1" memory: 2048M

---

Impact when editor crashes:

• UI freezes completely (WebSocket connection lost)
• Running jobs become zombies in PostgreSQL (status = running indefinitely)
• Queue stops — new jobs stay as "Starting soon"
• EXECUTIONS_TIMEOUT not honored because editor process is dead
• Recovery requires: Redis FLUSHDB + worker restart + editor restart

---

Workarounds applied (do not fix the leak):

• Increased editor memory limit to 2GB (delays crash)
• Scheduled daily forced restart of editor container at 5am (resets listeners)

---

Related issues:

• #16862 (memory leak with code node — different layer, same symptom)
• #20124 (browser-side memory leak on large workflows — client-side equivalent)

Operating System

Debian Linux (Docker Swarm on Ubuntu host)

Node.js Version

As shipped in docker.n8n.io/n8nio/n8n:2.14.2

To Reproduce

1. Deploy n8n in queue mode (EXECUTIONS_MODE=queue) with Redis and PostgreSQL
2. Activate more than 10 workflows with cron or webhook triggers
3. Check editor container logs on boot — MaxListenersExceededWarning appears immediately, before any execution runs
4. Monitor editor container memory over time — grows progressively
5. After a few hours the editor process is killed by the kernel (OOM, exit code 137)
6. UI freezes, running jobs become zombies in PostgreSQL, queue stops processing

Expected behavior

The editor process should call queue.setMaxListeners() proportionally to the number of active workflows, or properly remove listeners when workflows are deactivated. Memory usage should remain stable regardless of how many workflows are active.

Debug Info

Debug info

core

• n8nVersion: 2.14.2
• platform: docker (self-hosted)
• nodeJsVersion: 24.13.1
• nodeEnv: production
• database: postgres
• executionMode: scaling (single-main)
• concurrency: -1
• license: enterprise (production)
• consumerId: cf8a5c7f-808b-420c-86e7-8bddc99a1258

storage

• success: all
• error: all
• progress: true
• manual: true
• binaryMode: memory

pruning

• enabled: true
• maxAge: 120 hours
• maxCount: 10000 executions

client

• userAgent: mozilla/5.0 (x11; linux x86_64) applewebkit/537.36 (khtml, like gecko) chrome/146.0.0.0 safari/537.36
• isTouchDevice: false

Generated at: 2026-04-08T12:45:51.255Z

Operating System

Debian Linux (Docker Swarm)

n8n Version

2.14.2

Node.js Version

24.13.1

Database

PostgreSQL

Execution mode

queue

Hosting

self hosted