Finding a Memory Leak in Node or Go Before It Takes Down a Pod

Memory usage that climbs and then plateaus, or climbs and drops back down after a garbage collection cycle, is often just normal allocation behavior, not a leak. A real leak is memory that keeps climbing indefinitely, cycle after cycle, without ever coming back down, because something is holding a reference that should have been released. Plot memory usage over several hours before concluding you have a leak at all; a chart that looks alarming over ten minutes sometimes looks completely normal over three hours once garbage collection has had time to run.

Node's built-in inspector can capture a heap snapshot you can load into Chrome DevTools, and the useful technique isn't looking at one snapshot, it's taking two, separated by enough time for the suspected leak to grow noticeably, and using the comparison view to see which object types grew between them. Look specifically for objects you'd expect to be temporary, like event listeners, closures, or cache entries, showing up with a growing count instead of staying flat. A common Node-specific cause is an event listener added on every request without ever being removed, which silently accumulates until the process runs out of memory.

Go's pprof tooling can capture a heap profile showing exactly which call sites are responsible for currently live allocations, which is more directly actionable than Node's snapshot comparison since it points at the allocating code path immediately. The profile to focus on is in-use memory, not total allocations, since a function that allocates a lot but releases it all is not your leak; a function whose allocations show up in the in-use profile and keep growing across successive captures is. A common Go-specific cause is a goroutine that never exits, holding references to data that should have been garbage collected once its work was done.

Regardless of runtime, a few patterns account for most real leaks:

• An unbounded in-memory cache with no eviction policy, growing forever as new keys get added.
• A subscription, listener, or timer that gets created per-request but never cleaned up when the request completes.
• A closure that captures a large object by reference and outlives the scope it was created for.
• A goroutine or async task that's supposed to exit but gets stuck waiting on something that never happens.

Checking your own code against this list before profiling can sometimes save you the profiling step entirely.

Once the profile points at a specific allocation site, confirm the fix actually worked the same way you confirmed the problem: capture a new baseline, apply the fix, run under the same load for the same duration, and compare. A leak fix that isn't verified this way risks becoming a leak fix that only partially worked, or one that fixed a symptom while the actual root cause, an unbounded cache instead of the specific key you noticed growing, keeps running quietly in the background.

Say a Node service caches API responses keyed by a combination of user ID and query parameters, and traffic grows steadily over a week until the pod starts restarting daily. Two heap snapshots taken a few hours apart show one object type growing steadily: the cache's internal map. The cache was built with no maximum size and no time-based expiry, so every unique combination of user and query parameters it had ever seen stayed in memory forever. The fix wasn't a code review catching a typo, it was adding a maximum entry count with least-recently-used eviction, confirmed afterward by watching the same map's growth flatten out under the same production traffic instead of climbing indefinitely.