Your Service Restarts Itself Every Night. That's Not Normal

Memory that climbs and then plateaus at a higher baseline after a garbage collection cycle is normal behavior, not a leak, since most runtimes intentionally hold onto some reclaimed memory rather than returning it to the OS immediately. A real leak looks like memory that climbs steadily over hours or days without ever plateauing, even during periods of comparable, steady traffic. Graph heap usage over at least a full day, ideally several, before concluding you have a leak at all, since chasing a false positive wastes real profiling time on a problem that isn't there.

Take two heap snapshots using the built-in inspector, one shortly after startup and one after the service has been running long enough to show the climbing pattern, then compare object counts between them in a tool that supports snapshot diffing. The object type whose count grew the most between snapshots is almost always your leak's source. The most common Node culprits are event listeners added but never removed, closures captured in a cache that has no eviction policy, and promises held in an array that's appended to but never cleared.

Go's built-in pprof tooling gives you both heap profiling and goroutine profiling, and it's worth checking both, since a "memory leak" in Go is often actually a goroutine leak, background goroutines started but never terminated, each holding onto its own stack and any captured variables. Capture a heap profile and a goroutine count at two points in time the same way you would with Node's snapshots, and look specifically for a channel that's written to but never read from, which is the single most common way a Go goroutine ends up blocked forever instead of exiting cleanly.

• Unbounded caches: a cache with no size limit or expiry policy grows forever under real traffic, even though it looked fine in every test with a handful of requests.
• Event listeners or subscriptions never cleaned up: especially common in long-lived connection handlers where a cleanup path exists but isn't reliably called on every exit path, including error paths.
• Closures capturing more than intended: a closure that captures an entire outer scope, including large objects the function never actually uses, keeps that whole scope alive for as long as the closure itself is referenced.
• Goroutines or async tasks blocked forever: waiting on a channel, queue, or promise that will never resolve, holding their entire stack and captured state indefinitely.

The most reliable way to catch a leak before it reaches production is a load test that runs long enough, well past the point where transient allocation noise settles, with heap usage graphed throughout rather than sampled once at the end. A leak that only shows up after several hours of sustained traffic will never surface in a five-minute smoke test, no matter how thorough the test's request coverage otherwise is. Make this a gate before a release that touches connection handling, caching, or background task code specifically, since that's where leaks concentrate.

A common mistake is running the long load test against a staging environment with a tiny dataset, so caches never grow enough to reveal an unbounded entry count. For example, a cache keyed by user ID looks flat when a handful of test users cycle through it, then climbs all week in production. The fix is to make test traffic resemble production key diversity: replay anonymized request patterns, or generate many distinct users, tenants, and identifiers. Graph heap usage and, in Go, goroutine count together, and fail the release gate if either keeps rising after warm-up. That catches the leak that only diversity exposes.