Finding a Memory Leak Before It Finds Your Pager

Run the service with `--inspect` enabled, or trigger a heap snapshot programmatically, at two points in time separated by enough load to make a real leak visible against normal noise, an hour or more under typical traffic. Load both snapshots into a comparison view and sort by the objects that grew the most between the two, not by total size alone, since a large but stable cache looks different from a collection that's growing unbounded. The comparison view, not either snapshot in isolation, is what actually points at the leak.

A closure that captures a reference to something large and outlives its useful purpose, an event listener registered but never removed, an entry added to a Map or WeakMap-that-should-have-been-a-WeakMap, are the most common real-world Node.js leak patterns. An event emitter that accumulates listeners across repeated calls to a function that re-subscribes without ever unsubscribing is a particularly common one in long-running services, and it often only becomes visible after enough repetitions that a normal test suite, which runs each path only a handful of times, never catches it.

Go's built-in `pprof` heap profile shows memory allocation by call site, which points you toward which function is allocating memory that isn't getting freed. A goroutine leak, one that's started but never returns because it's blocked on a channel nobody ever sends to or closes, shows up differently, as a steadily growing goroutine count in the goroutine profile rather than in heap allocations directly, though it often drags memory up alongside it since each leaked goroutine holds its own stack and any captured references. Check both profiles; they point at different, equally common failure patterns.

A heap snapshot or profile taken after an out-of-memory kill is nothing, because the process and its memory state are already gone. Set up automatic capture triggered by a memory threshold crossing, well before your actual limit, so a snapshot exists from a moment when the leak was visible but the process was still alive and responsive enough to produce a clean profile. This single piece of automation is the difference between diagnosing a leak in an afternoon and reconstructing one from vague symptoms after it's already caused several restarts.

To set up automatic capture, work through these steps:

1. Pick a memory threshold well below your actual limit, so the capture fires while the process is still alive and responsive.
2. Trigger a heap snapshot or profile automatically when memory crosses that threshold, instead of waiting for an out-of-memory kill.
3. Test the capture in staging first, since taking a snapshot pauses the process briefly and adds some overhead.
4. Compare the captured snapshot against an earlier one to see which objects grew the most between the two.

Some memory growth is normal and expected, a cache filling up to its intended size, a connection pool warming up, garbage collection running less aggressively under light load and reclaiming memory later than you'd expect. Compare RSS growth against a period of genuinely idle traffic; a service that grows under load and then plateaus, even at a higher baseline than before, is probably fine, while one that keeps climbing during idle periods with no new work coming in is the pattern that actually indicates a leak worth chasing.

Once you have a suspected culprit from a snapshot diff or a pprof allocation profile, write a small, repeatable script that exercises just that code path in a loop and watch memory under a profiler while it runs. This turns a vague, multi-day production symptom into a fast, local feedback loop you can iterate against, which is a much better position than trying to confirm a fix by deploying to production and watching a dashboard for another few days to see if the trend finally flattens out.

Some leaks only show up under production-scale traffic or a specific, hard-to-replicate data shape, a particular customer's usage pattern, a rare combination of concurrent requests. For these, lean harder on the automated snapshot-on-threshold capture from production itself, and consider running the suspect service temporarily with more verbose allocation tracking enabled on a single instance pulled from the load balancer rotation, trading a bit of that instance's performance for the diagnostic detail you can't get any other way.