Goroutine leaks in Go: detect, understand, fix

The program has been running for 3 days. Memory is climbing slowly, requests are starting to slow down, and at some point the process gets killed by the OOM. No panic, no visible error log, nothing in Sentry. Just a gradual degradation. Nine times out of ten: goroutine leak. What makes leaks hard to catch is that they don't make noise. A blocked goroutine consumes between 2 and 8 KB of stack depending on its state. Alone, it's nothing. At a few thousand, it's a problem. What a leak is A goroutine leak is a goroutine that was started and never terminates — because it's waiting for something that will never arrive, or because it's running in an infinite loop with no exit mechanism. The Go runtime does not collect blocked goroutines: they stay in memory until the process ends. Unlike classic memory leaks (unreleased objects), goroutine leaks often have a precise, reproducible cause. Once you know what to look for, they're quick to find. The 4 patterns that reliably leak 1. Channel send wi