Profiling a Memory Leak in Node or Go Before It Pages You

Plot memory usage over a long enough window, hours to days, not minutes. A real leak shows steady growth that never comes back down between garbage collection cycles.

A high but stable memory footprint, even one that looks alarming on a dashboard, isn't a leak, it's your actual working set, and profiling for a leak that isn't there wastes time better spent elsewhere. Confirm the trend before opening a profiler.

Take two heap snapshots, minutes or hours apart under normal load, and compare them in a heap profiling tool, looking specifically at what grew between the two.

The most common Node-specific leak pattern is a closure or event listener that holds a reference to something it shouldn't, most often an event emitter that accumulates listeners because code adds one on every request instead of once at startup, or a cache with no eviction policy that grows unbounded because nothing ever calls delete on it.

Go's garbage collector handles most heap leak patterns reasonably well, so a genuinely growing memory footprint in a Go service is more often a goroutine leak: a goroutine started to handle something, blocked forever on a channel nobody's ever going to write to or a context that never gets canceled, holding onto whatever memory it captured in its closure indefinitely.

A goroutine profile, not just a heap profile, is where this pattern shows up: a goroutine count that climbs steadily and never comes back down between requests is a strong signal, even before you look at heap size at all.

• Does memory usage actually plateau over a multi-hour or multi-day window under normal traffic, not just look better for the first several minutes after a deploy?
• For Node, did the fix address the specific reference that was being held, event listener, cache entry, closure, not just a general clean-up-more-often change that masks the symptom?
• For Go, does goroutine count also plateau, not just heap size, since a goroutine leak with small per-goroutine memory can take a long time to show up as a heap problem even while it's a real leak?
• Has the fix been validated under the same load pattern that originally triggered the leak, not just under light testing traffic?

Say a Node service's memory climbs steadily over several days with no traffic pattern that explains it, and a heap snapshot comparison shows a steadily growing array retained by a single module-level variable. Tracing that variable back through the code shows a request handler pushing an item into it on every call and never removing anything, effectively an unbounded in-memory log nobody intended to keep forever.

The fix is almost always smaller than the investigation: cap the array's size, add a time-based eviction, or move the data to somewhere with an actual expiry, like a cache with a TTL. The time cost here is almost entirely in confirming the trend and narrowing down the reference, not in writing the eventual fix.

A hard memory limit that restarts a process before it exhausts the host's memory entirely is good operational hygiene regardless of whether you have an active leak, since it turns a slow leak into a periodic, low-impact restart instead of a full host-level outage. It is not a substitute for actually finding and fixing the leak: a service restarting every few hours to work around unbounded growth is burning latency and dropped requests on every restart, and that cost compounds even if no single restart looks alarming on its own.