Articles

Node.js Memory Leaks: Detect with Heap Dumps (2026)

April 18, 2026 6 min read

Node.js memory leaks are insidious because they don’t usually crash your application immediately, but instead, they gradually consume all available memory, leading to slow performance and eventual instability. The core issue is that your application is holding onto references to objects that are no longer needed, preventing the garbage collector from reclaiming their memory.

The most effective way to diagnose this is by taking and analyzing heap dumps. A heap dump is a snapshot of all the objects that are currently in your Node.js process’s memory at a specific point in time. By comparing heap dumps taken at different intervals, you can identify which objects are growing in number and what’s keeping them alive.

Here’s how to capture a heap dump using node --inspect and Chrome DevTools:

First, start your Node.js application with the --inspect flag:

node --inspect your_app.js

This will output a URL like ws://127.0.0.1:9229/..... Open this URL in Google Chrome. It will take you to the Chrome DevTools. Navigate to the "Memory" tab.

In the Memory tab, select "Heap snapshot" and click "Take snapshot." Do this once when your application is in a known "good" state (e.g., just started, idle). Then, perform the actions that you suspect are causing the memory leak (e.g., repeatedly making API calls, processing data). After the suspected leak has had time to manifest, take another heap snapshot. Repeat this process a few times if necessary to see a clear trend.

To analyze the leaks, compare two snapshots. Select the second snapshot and, in the "Objects" view, choose "Comparison." This will show you the difference in object counts and sizes between the two snapshots. Look for object types that have significantly increased in "Delta" (the difference in count) and "Retained Size" (the amount of memory that would be freed if this object were garbage collected).

Let’s say you notice a large increase in the count of MyCustomObject instances. Clicking on MyCustomObject in the comparison view will show you the "Retaining paths." This is the crucial part: it tells you what is holding a reference to these leaked objects, preventing them from being garbage collected. You’ll see a chain of objects, starting from the root (like the global object or a timer) down to your MyCustomObject.

Common culprits for retaining references include:

  • Global Variables: Objects assigned to global variables will persist for the lifetime of the application. If you’re accidentally assigning to a global variable without realizing it, or if a global variable is intended to cache data but isn’t managed properly, it can lead to leaks.

    • Diagnosis: In the heap snapshot comparison, look for objects retained by (root) or window (in browser-like environments, less common in pure Node.js but possible with certain libraries).
    • Fix: Ensure you’re using let or const appropriately and avoid assigning to global scope unless absolutely intended. If it’s a cache, implement a size limit or an eviction strategy.
    • Why it works: By removing the global reference, you allow the garbage collector to see that the object is no longer reachable.

  • Closures: Functions that "close over" variables from their outer scope can retain those variables even after the outer function has returned. If these enclosed variables are large objects or collections that are no longer needed, they form a leak.

    • Diagnosis: Examine the retaining paths. You might see a function reference pointing to an object. Inspect the function’s scope to see what it’s capturing.
    • Fix: Be mindful of what variables your closures are capturing. If possible, pass only the necessary data into the closure, or nullify references within the closure when they are no longer needed.
    • Why it works: Closures hold onto their lexical environment. By ensuring the environment doesn’t hold onto unnecessary large objects, you break the leak.

  • Event Listeners: If you add event listeners (e.g., to EventEmitter instances, streams, or DOM elements in a browser context) and don’t remove them when they are no longer needed, they will keep the listener callback and the object it’s attached to alive.

    • Diagnosis: Look for references to EventEmitter instances or similar objects in the retaining path, often pointing to listener functions.
    • Fix: Always remove event listeners when the associated component or object is destroyed or no longer active. Use emitter.removeListener(eventName, listenerFunction) or emitter.removeAllListeners(eventName).
    • Why it works: Removing the listener explicitly tells the emitter that it no longer needs to hold a reference to the callback function and the associated context.

  • Timers (setInterval/setTimeout): If a setInterval or setTimeout callback holds a reference to an object, and the interval/timeout is never cleared, that object will remain in memory indefinitely.

    • Diagnosis: Retaining paths might show setTimeout or setInterval functions holding references to your leaked objects.
    • Fix: Always store the ID returned by setInterval and setTimeout and call clearInterval(id) or clearTimeout(id) when the timer is no longer required.
    • Why it works: Clearing the timer explicitly removes the scheduled execution and, crucially, the reference it holds to its callback and its captured environment.

  • Caches without Limits: Implementing an in-memory cache is common, but if it grows indefinitely without any eviction policy (like LRU - Least Recently Used, or a simple size limit), it will eventually consume all available memory.

    • Diagnosis: The retaining path will likely lead from a global cache object (e.g., a Map or an array) to your leaked objects.
    • Fix: Implement a maximum size for your cache and an eviction strategy. Libraries like lru-cache can help.
    • Why it works: By actively removing older or less-used items, the cache ensures that its memory footprint remains bounded.

  • Circular References (Less Common in Modern GC): While modern garbage collectors are good at handling circular references, in some complex scenarios or with specific native modules, they might still cause issues. A circular reference is when Object A references Object B, and Object B references Object A, creating a loop.

    • Diagnosis: This is harder to spot directly and often manifests as the previous issues. If you suspect this, investigate the retaining paths carefully for mutual references.
    • Fix: Break the circular reference manually when an object is no longer needed by setting one of the references to null.
    • Why it works: Breaking the cycle makes at least one of the objects in the cycle unreachable, allowing the GC to collect them.

After applying a fix, restart your Node.js application and repeat the heap dump analysis process to confirm that the memory growth has stopped.

The next error you’ll likely encounter if you haven’t addressed all memory issues is an out of memory error, often with a specific code like ERR_STRING_TOO_LONG if a string buffer allocation fails due to extreme memory pressure.

Want structured learning?

Take the full Nodejs course →