emitter.setMaxListeners()
Change the listener count at which an emitter starts warning about a possible memory leak.
emitter.setMaxListeners(n)- Added in Node.js v0.3.5
Parameters
| Parameter | Type | Description |
|---|---|---|
$n | <integer> | The maximum number of listeners for a single event before a warning is printed. Infinity or 0 means unlimited. |
Return value
<EventEmitter>A reference to the emitter, so calls can be chained.
Errors
Throws ERR_OUT_OF_RANGE if n is negative or not a number.
Every emitter warns once per event when an eleventh listener is added: MaxListenersExceededWarning: Possible EventEmitter memory leak detected. setMaxListeners(n) moves that threshold for one instance. EventEmitter.defaultMaxListeners moves it for every emitter in the process, including core's.
When to reach for it
Only when the count is genuinely bounded and genuinely above ten — a plugin host with fifteen registered plugins, a fan-out to a fixed list of workers. Set it to the number you actually expect plus a small margin, so the warning still fires if the count runs away later.
What trips people up
The warning is a symptom, not the disease. The overwhelming majority of these warnings come from a subscription inside a loop, a request handler or a reconnect path that never calls off(). Raising the limit removes the message and leaves the leak growing until the process runs out of memory. Before changing n, print listenerCount() and check whether it keeps climbing.
The warning goes to stderr, not to 'error', and it fires once per event name per emitter. Setting n to 0 or Infinity disables it entirely — reserve that for emitters whose subscriber list you fully control.
Example
When to use it
- Allow a plugin host to attach one 'shutdown' listener per registered plugin without warnings
- Raise the limit on a fan-out emitter that broadcasts to a fixed pool of workers
- Run node --trace-warnings after a MaxListenersExceededWarning to find the subscription site
Frequently asked questions
How do I fix MaxListenersExceededWarning: Possible EventEmitter memory leak detected?
Find the code adding listeners repeatedly and remove them with off() when their scope ends — the warning is nearly always a real leak, not a limit that is too low. Run node --trace-warnings to get a stack trace of the offending on() call. Only raise the limit with setMaxListeners() once you have confirmed the count is bounded.
What is the default max listeners in Node.js?
Ten per event, per emitter. It is exposed as EventEmitter.defaultMaxListeners and read per instance with emitter.getMaxListeners(). The threshold is a leak-detection heuristic only; nothing is blocked when it is exceeded.
How do I disable the listener limit entirely?
Call emitter.setMaxListeners(0) or setMaxListeners(Infinity) — both mean unlimited. Do this only for an emitter whose subscriber list you fully control, since it removes the only automatic warning you get about a growing leak.
More examples
Seeing the warning, then finding its source
The eleventh on() call triggers the warning, delivered on process 'warning' rather than through the emitter itself. The message names the event and the current limit but not the call site — --trace-warnings adds the stack, which is the fastest way to find the loop or handler doing the repeated subscribing.
const { EventEmitter } = require('node:events');
const bus = new EventEmitter();
process.on('warning', (w) => {
console.log(w.name);
console.log(w.message);
});
for (let i = 0; i < 11; i++) bus.on('data', () => {});
// MaxListenersExceededWarning
// Possible EventEmitter memory leak detected. 11 data listeners added to
// [EventEmitter]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
//
// Run with `node --trace-warnings app.js` to get a stack trace pointing at
// the exact on() call that crossed the threshold.Raising the limit only where it is justified
The limit is derived from the real subscriber count plus a margin, so a future bug that adds listeners in a loop still trips the warning. Setting EventEmitter.defaultMaxListeners instead would silence the check for every emitter in the process, including Node's own streams and sockets, and is worth avoiding.
const { EventEmitter } = require('node:events');
class PluginHost extends EventEmitter {
constructor(plugins) {
super();
// The count is known and fixed: raise deliberately, with headroom.
this.setMaxListeners(plugins.length + 5);
for (const plugin of plugins) {
this.on('shutdown', () => plugin.stop());
}
}
}
const host = new PluginHost([{ stop() {} }, { stop() {} }, { stop() {} }]);
console.log('limit:', host.getMaxListeners());
console.log('listeners:', host.listenerCount('shutdown'));
// Process-wide alternative, rarely a good idea:
// EventEmitter.defaultMaxListeners = 20;
Discussion