Create a Dump of the V8 Heap in Node.js

Take a dump of the V8 heap, inspect it, and learn how to record snapshots with DevTools. Have you ever watched your Node.js app slowly eat up memory until the whole thing crashes? You restart it, and everything looks fine — until it happens again. You add logs, you stare at the code, but nothing jumps out at you.

That is the frustrating reality of a memory leak. And the best tool to hunt one down is a V8 heap dump in Node.js.

In this guide, you’ll learn exactly how to create a dump of the V8 heap, what the output looks like, and how to load and inspect it using Chrome DevTools — step by step, with real screenshots.

What is a V8 heap dump?

Node.js runs on the V8 JavaScript engine. V8 manages all the memory your app uses through something called the heap — every object, closure, array, and variable lives there at runtime.

A heap dump is a snapshot of that memory at a specific moment. It captures every single object currently alive in memory, how large it is, and what’s holding onto it.

Think of it like pausing a movie and taking a photo of every actor on screen, plus who they’re standing next to. That picture tells you a lot about what’s going on — and more importantly, what shouldn’t be there.

Create a Dump of the V8 Heap in Node.js

Why it matters: memory leaks are invisible without it

A memory leak in Node.js doesn’t crash your app immediately. It’s slow. Gradual. Your server handles 100 requests fine, then 1,000, then at 10,000 you start getting timeouts and then OOM (out-of-memory) kills.

Without a heap dump, you’re guessing. With one, you can see:

• Which object types are consuming the most memory
• How many instances of each type exist
• What is holding them in memory and preventing garbage collection.

Step 1: Create a Node.js app with the heapdump package

First, create a project folder called heapdump-demo and add an app.js file. Install the dependencies:

npm init -y
npm install express heapdump

Here’s a simple app.js that triggers a heap dump on every request (for demo purposes):

const express = require('express');
const heapdump = require('heapdump');

const app = express();

app.get('/', (req, res) => {
  res.send(`<h2>Take a look at the network tab in devtools</h2>//`);
});

app.get('/heapdump', (req, res) => {
  heapdump.writeSnapshot((err, filename) => {
    if (err) return res.status(500).send(err);
    res.send(`Heap dump written to: ${filename}`);
  });
});

app.listen(8080, () => {
  console.log('Server running on port 8080');
});

Run it with:

node app.js

Then visit http://localhost:8080/heapdump in your browser to trigger the snapshot.

Step 2: The .heapsnapshot file appears in your project

After triggering the dump, check your project folder. You’ll see a new file appear — something like heapdump-280936526.45328.heapsnapshot.

Here’s what that looks like in VS Code:

This file is plain JSON under the hood. It contains a dense structure of nodes and edges representing every object in V8 memory at the time the snapshot was taken.

Step 3: What’s inside the .heapsnapshot file?

If you open it in your editor, it looks like a wall of numbers. That’s intentional — it’s a machine-optimised format, not meant to be read directly.

Each row represents a node in the heap: its type, name, ID, self size, edge count, and trace node ID. The fields are defined in the meta.node_fields section at the top of the file.

You should never try to read this manually. That’s what Chrome DevTools is for.

Step 4: Load the snapshot in Chrome DevTools

Open Chrome and navigate to your app at http://localhost:8080. Open DevTools (F12 or right-click → Inspect), and click the Memory tab.

You’ll see three profiling options:

• Heap snapshot
• Allocation instrumentation on timeline
• Allocation sampling

Select Heap snapshot, and at the bottom of the panel you’ll see a Load button highlighted in red. Click it and select your .heapsnapshot file.

Once loaded, the snapshot appears in the left sidebar under Heap Snapshots, showing the filename and its size (in this case, 7.1 MB). Chrome DevTools with the loaded heapdump snapshot visible in the left panel at 7.1 MB]

Step 5: Reading the Summary view

Click on the loaded snapshot and you’ll land in the Summary view — the most useful place to start.

Here’s what the columns mean:

• Constructor — the type of object (closure, array, string, compiled code, etc.)
• Distance — how many steps from the GC root to this object
• Shallow size — memory used by the object itself
• Retained size — memory that would be freed if this object were garbage collected (includes everything it holds)

The retained size is the most important column for hunting leaks. If something has a massive retained size and shouldn’t be there, that’s your suspect.

In this snapshot you can see (compiled code) ×5028 and (closure) ×3613 — large numbers that are worth investigating in a real app.

Step 6: Switch to the Containment view

The Containment view shows you the GC roots — the objects that V8 is using as anchors. Anything reachable from a GC root cannot be garbage collected. Here you can see the top-level global object, GC roots, and internal Node.js handles like TTYWRAP, SIGNALWRAP, and DNSCHANNEL. These are expected. If you see your own application objects listed here unexpectedly — that's a leak.

Step 7: Check the Statistics view

Switch the dropdown from Summary to Statistics for a high-level breakdown of how memory is split across categories.

This view breaks down the total heap (7,073 KB in this case) into:

• Code — 1,099 KB
• Strings — 1,983 KB
• JS Arrays — 164 KB
• Typed Arrays — 18 KB
• System objects — 1,179 KB

If strings are suspiciously large, you might have a log buffer or string cache growing unchecked. If JS arrays are enormous, look for event listener arrays or unbounded caches.

Common mistakes to avoid

Here are the pitfalls developers run into most often:

Taking only one snapshot. A single snapshot shows what’s in memory, but not what’s growing. Always take two — one before your suspect action and one after — then use the Comparison view to see what changed.

Confusing shallow and retained size. A small shallow size can still have a massive retained size if it holds references to large structures. Always sort by retained size when hunting leaks.

Taking snapshots under heavy load. In-flight request objects will show up and pollute your results. Take snapshots in low-traffic windows or in staging.

Not naming snapshot files. If you generate multiple snapshots, give them meaningful names so you can compare them easily:

heapdump.writeSnapshot(`./snapshots/before-load-${Date.now()}.heapsnapshot`);

Quick tips for better heap analysis

• Use the Comparison view (not Summary) when comparing two snapshots side by side
• Sort by retained size descending to find the biggest memory hogs first
• Search for your own class names in the Class filter box to quickly find application-specific objects
• If you see IncomingMessage or ServerResponse objects with unexpectedly high counts, you may have dangling request handlers
• Use process.on('SIGUSR2', ...) to trigger snapshots in production without restarting the server

Conclusion

A memory leak in Node.js doesn’t announce itself. It creeps up quietly, request by request, until your server is on its knees. The V8 heap dump is your best weapon against it.

You don’t need fancy tools or expensive APM software. A free npm package, Chrome DevTools, and the steps above are enough to pinpoint the exact object causing the problem.

The developers who ship stable, long-running Node.js services aren’t luckier than everyone else — they just know how to look at what’s in memory. Take your first heap dump today. You might be surprised at what you find lurking in there. Found this useful? Share it with your team, or drop a comment with the leak you tracked down, ’d love to hear about it.

Thanks for Reading!

If you found this useful: Clap for the article, it helps others discover it Follow me for more practical guides on analytics, web development, and real-world engineering solutions Leave a comment if you’d like a deep dive into any specific Matomo feature

I regularly share hands-on content about: AI, / Information technology, / Web, / Analytics, / NodeJS / Nest.js / React / Next.js, / System design, / real project learnings.