Finding a Memory Leak: A Heap Snapshot Walkthrough

The pattern is usually visible on a memory graph before anyone reads a single line of code: a steady upward climb that never plateaus, unlike normal memory usage which grows during a busy period and then falls back down once that work completes. If your graph shows a return to baseline after load drops, that's probably healthy garbage collection doing its job, not a leak.

If it doesn't return to baseline, and instead climbs a bit further after each busy period before falling back only partway, that's the signature of an actual leak: something is being retained across garbage collection cycles that shouldn't be, and the retained amount compounds over time until the process runs out of memory or an orchestrator's restart policy kicks in first.

Before diving into heap snapshots, rule out a few things that look like leaks but aren't. A cache with no eviction policy will grow until it plateaus at the size of everything that's ever been cached, which can look exactly like a leak on a short observation window but is actually bounded, just at a size nobody planned for. Check whether the growth curve is flattening slowly over a longer window before assuming it's unbounded.

Also confirm you're looking at the right memory metric. Total process memory includes the operating system's own caching behavior around freed memory that hasn't been returned to the OS yet, which can look like growth even when your application's actual live heap is stable. Compare application-level heap metrics specifically, not just total process resident memory, before concluding there's a real leak.

Take two heap snapshots separated by a meaningful gap, ideally spanning at least one full busy-then-idle cycle, so any object that should have been collected has had the chance to be. Compare the two snapshots specifically for objects whose count grew between them without a corresponding drop, rather than just looking at total heap size, which tells you something grew but not what.

Sort the comparison by the delta in object count or retained size, not by total count, since the object type responsible for a leak is often not the most numerous type overall, just the one that kept growing while everything else stayed flat. Once you've found the growing object type, trace its retainers, what's holding a reference to it, which is usually where the actual bug lives: an event listener that's never removed, an entry added to a map keyed by something like a request ID that's never cleaned up, a closure capturing more than it needs to.

The equivalent process in Go uses pprof's heap profile, captured at two points in time the same way as the Node.js snapshots above, separated by enough of a gap to distinguish real growth from normal allocation churn. Compare the two profiles for the allocation sites and types whose retained memory grew between captures, rather than relying on a single snapshot, which only shows a moment in time and can't distinguish something that's growing from something that's simply large.

Go's garbage collector handles a lot of allocation patterns cleanly on its own, so a real leak here is more often something explicitly held alive: a slice or map that only grows, a goroutine that never exits and keeps its own local variables reachable indefinitely, a channel that's never drained. Trace the growing allocation back to the code path that creates it the same way you would in Node.js, since the diagnostic logic is the same even though the tooling looks different.

Once you've identified what's growing, the actual cause usually falls into a small set of patterns:

• An event listener or callback registered once per request or per connection and never removed, so the count grows with traffic instead of staying bounded.
• A cache, map, or dictionary with no eviction policy or size limit, growing unbounded as new keys are added and old ones are never removed.
• A goroutine or async task that never completes, keeping everything it references reachable for as long as it's alive, which in a genuine leak is forever.
• A closure or callback capturing a larger scope than it actually needs, keeping objects alive indirectly through a reference the code doesn't obviously need to hold.

Fix the root cause, not the symptom. A scheduled restart masks a leak instead of fixing it, and the underlying bug keeps consuming memory and dropping in-flight work on every restart until someone actually traces it back to the retaining reference.