What does Go's goroutineleak profile report that the ordinary goroutine profile cannot?

## The judgment the ordinary profile leaves you `/debug/pprof/goroutine` is a complete census of goroutines and their parked call sites. It is the right instrument for a leak, but it does not identify one — it hands you a population and asks you to classify it. A goroutine parked for six hours on `chan receive` might be a leak, or it might be an idle worker waiting for work that has not arrived. Distinguishing them is inference: you take two snapshots and see which stack grows, you look at where the count concentrates, and you reason about whether the event that would wake this goroutine can still occur. Experienced engineers do this well and still get it wrong on unfamiliar code. ## What the leak profile does instead The `goroutineleak` profile answers a strictly narrower and much stronger question: **which goroutines can the runtime prove will never run again?** The idea borrows the garbage collector's central insight. The collector calls an object garbage when no live path can reach it. A blocked goroutine is in an analogous position: it is waiting on some synchronisation object — a channel, a lock — and it can only be resumed by another goroutine operating on that same object. If the runtime can establish that no goroutine capable of running can still reach that object, then no send, receive, close or unlock can ever arrive, and the waiting goroutine is *semantically* garbage even though it is technically still alive. It will occupy its stack and pin everything it references for as long as the process lives. That is a proof, not a heuristic. There is no duration threshold, no count comparison, and no snapshot diffing. Every entry in this profile is a goroutine that is definitely stuck, reported with the stack that shows where. ## What it cannot see The proof requires unreachability, and plenty of real leaks are perfectly reachable. Take the classic case in a streaming service: a writer goroutine blocked sending a frame to a subscriber whose connection has gone, where the subscriber's channel is still sitting in the server's map of active subscribers. The channel is reachable from live code. The runtime cannot rule out that some goroutine will one day receive from it, so it cannot prove anything, and the goroutine does not appear in the profile — even though you know, reading the code, that nothing will ever drain it. Fixing the leak here means removing the subscriber from the map, which is also what would make the goroutine provably leaked. The other blind spot is waits that are not synchronisation at all. A goroutine blocked in a socket read with no deadline, or in a blocking syscall, is waiting on the outside world. There is no in-process object whose reachability decides the outcome, so reachability analysis has nothing to say about it. So the two results are asymmetric, and that asymmetry is the whole point of the question. **A non-empty profile is proof of a leak. An empty profile is not proof of no leak.** Anyone who treats a clean `goroutineleak` result as a clean bill of health has drawn exactly the wrong conclusion. ## How to use it It is not a metric to scrape. Establishing unreachability is far more work than counting goroutines, so this profile costs meaningfully more than the ordinary one and is not something to pull every fifteen seconds alongside your other telemetry. The sensible posture is layered: - Keep the cheap goroutine census as your trend line — that is what tells you something is climbing. - When you suspect a leak, pull `goroutineleak` first. If it names something, you have skipped the entire inference step and can go straight to the code. - If it names nothing, fall back to the ordinary method: two snapshots minutes apart, diff them, read the growing stack's parked call site and its `created by` line. The reachable-channel leak above is the common shape, and this is how you catch it. ## The version caveat This is recent. The profile shipped in Go 1.27; Go 1.26 had it only behind an experiment flag, and earlier releases have nothing like it. That matters organisationally more than technically: if your leak-hunting runbook assumes the endpoint exists, it assumes a toolchain floor across every service that might page you, including ones another team builds. Write the runbook so the ordinary goroutine profile remains the path that always works, and treat the leak profile as the shortcut you take when the binary happens to be new enough.