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

Every garbage-collected or manually managed runtime has a normal memory sawtooth, usage rises as work happens and drops when it's reclaimed. A leak looks different: the baseline itself creeps upward over hours or days, so each sawtooth peak and trough sits a little higher than the last one.

Confirming that pattern before profiling anything saves time. Watch resident memory over a period long enough to see several cycles, not a single deploy's worth of data, since a short window can't tell a leak from a normal warm-up as caches fill.

Take a heap snapshot under realistic load, let the service run for a while doing real work, then take a second one. Comparing the two in Chrome DevTools shows what grew between them, retained size and object counts per constructor, which points you at the specific type of object that's accumulating instead of leaving you to guess.

Look especially at counts that grow roughly in proportion to requests served, an array or map that gains one entry per request and never removes any is one of the most common patterns, and it's usually invisible until the snapshot comparison puts a number on it.

Go's runtime/pprof package exposes a heap profile you can capture and compare the same way, two profiles taken minutes apart under load, diffed to show what's still allocated in the second that shouldn't have accumulated since the first.

Goroutine leaks are a related but distinct problem worth checking alongside the heap profile: a goroutine blocked forever waiting on a channel nobody writes to or closes never gets collected, and it holds onto whatever it captured in its closure for as long as it exists. A steadily growing goroutine count in your metrics is often the earlier warning sign, showing up before the memory graph makes the leak obvious.

A handful of patterns account for most leaks in services that run for days or weeks at a time. Event listeners registered on a long-lived object and never removed accumulate one per subscription. Closures that capture a large object by reference keep that object alive far longer than intended. Unbounded in-memory caches or maps that grow with usage and never evict. Timers or intervals started and never cleared when the thing they were tracking goes away.

None of these are exotic bugs, which is exactly why they're common: each one is a small, easy-to-miss omission, a removeListener call that isn't there, a cache with no eviction policy, that only becomes visible once the process has been running long enough for it to matter.

A graph that looks flatter after a change is a good sign, not proof. Reproduce the original load pattern, run it for a sustained period, and watch the memory growth rate specifically, not just the absolute level at one point in time, comparing before and after under the same conditions.

If the growth rate hasn't measurably dropped, the fix addressed a symptom rather than the actual leak, or there's a second leak still running underneath the one that got fixed. Confirming under load before calling it done is what turns a plausible fix into a verified one.

A reliable way to confirm a fix:

1. Reproduce the original load pattern that exposed the leak instead of judging the change during a quiet period.
2. Run it for a sustained period, long enough to show several memory cycles rather than a single deploy's worth of data.
3. Watch the growth rate of resident memory, not just the absolute level at one point in time.
4. Compare the before and after growth rates under identical conditions, and treat an unchanged rate as a sign the fix addressed a symptom.