Memory leak in editor process (OOM kill) due to unbounded EventEmitter listeners in queue mode with 10+ active workflows

[Q2P-Sistema]

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:

• Memory Leak in n8n v1.99.1 Affecting Workflows with code node #16862 (memory leak with code node — different layer, same symptom)
• Workflow Editor leaks memory and freezes on large workflows (>100 nodes) #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

[n8n-assistant]

Hey @Q2P-Sistema,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-7640".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-7640

[ivov]

Hi @Q2P-Sistema

These listeners are transient and tiny warnings, not errors and not the cause of your OOMs.

To diagnose your setup, you can:

• Check in your DB if new or running executions are climbing up steadily → This would reveal job.finished() promises piling up and might correlate
• Enable N8N_METRICS and see if nodejs_heap_used_bytes is climbing or flat → This will tell you if it's retained JS objects or native memory
• Check if your workload is mostly high-frequency long-running jobs → This could mean your nodes are undersized
• Connect a debugger and take a heap snapshot (this by itself will increase memory usage, so account for it beforehand)

[Q2P-Sistema]

Hi @ivov, thanks for the response.

You're right — after deeper investigation, we found that the OOM was not caused by the EventEmitter warnings. The actual root causes were infrastructure misconfigurations in our Docker Swarm setup:

1. Redis --timeout 300 was killing idle client connections every 5 minutes, causing constant reconnection cycling in ioredis/BullMQ
2. PostgreSQL missing TCP keepalives — connections across the Swarm overlay were silently dropped, causing sporadic timeouts
3. Task Runner offer timeouts due to overlay network saturation during backup operations

After fixing these (Redis --timeout 0, Postgres tcp_keepalives_idle=60, and restarting stuck workflows), the environment has been stable.

Closing this as it's not an n8n code issue. Apologies for the noise, and thanks for the diagnostic pointers — they're useful for others who might face similar symptoms.