Go 1.26 Goroutine Leak Detection: A Practical Guide

Short answer: Build with GOEXPERIMENT=goroutineleakprofile, hit /debug/pprof/goroutineleak?debug=2, and look for the (leaked) tag in the stack trace. Go's garbage collector already knows a goroutine can never wake up (blocked on an unreachable channel, mutex, or condition variable) and Go 1.26 is the first release that exposes that fact as a profile instead of making you guess.

Your Go service is fine. Then it isn't. Memory creeps up over a few days, nothing crashes, no error logs, and eventually a pod gets OOMKilled and restarts. You bump the memory limit and move on. Three weeks later it happens again.

That's usually a goroutine leak, and Go has historically been terrible at telling you about it. There's no panic. No warning. No -race flag for it. You can leak a million goroutines and the runtime will happily let you, because from Go's point of view, a goroutine blocked forever isn't an error. It's just waiting.

Each leaked goroutine costs at least 2KB of stack space plus whatever it's holding in its closure: an open database connection, a large slice, a reference to a struct that should have been garbage collected an hour ago. One leaked goroutine is noise. A steady trickle of a few per request, running for days inside a Kubernetes pod with a fixed memory limit, is exactly the kind of slow-burn failure that's miserable to diagnose after the fact, because by the time you notice, the evidence is buried under thousands of other goroutines that are behaving completely normally.

If you've dealt with this before, you've probably reached for Uber's goleak library in your tests, or pulled a manual goroutine dump off /debug/pprof/goroutine. Both are useful, and neither solves the real problem.

goleak snapshots the goroutines running before and after a test and fails if new ones are still alive when the test ends. It's a solid first line of defense, but it only catches leaks that happen during a test run, on a code path your test actually exercises. It has nothing to say about a service that's been running in production for six days under real traffic patterns your test suite never simulated.

The other classic move is pulling a raw goroutine dump from /debug/pprof/goroutine?debug=2 and eyeballing it. That endpoint has existed since Go 1.x and it gives you a list of every goroutine that exists right now, leaked or not. A healthy service under load might have hundreds of legitimately busy goroutines. Manually scanning stack traces trying to guess which ones are stuck forever versus which ones are just slow is exactly the kind of task humans are bad at and computers are good at, which is the gap Go 1.26 closes.

Go 1.26 shipped an experimental profile type called goroutineleak in the runtime/pprof package. It's not a timer and it's not a heuristic. It reuses the garbage collector's own reachability analysis: if a goroutine is blocked on a channel, mutex, or condition variable, and that object is unreachable from anything that could ever unblock it, the runtime knows for a fact that goroutine can never wake up. That's a proven leak, not a guess based on how long something has been blocked.

This matters because it's the same class of insight -race gives you for data races: not "this looks suspicious," but "this is mathematically true given the current object graph." That's what makes it safe to trust in a report instead of treating it as another noisy signal to filter.

Enable it at build time with the GOEXPERIMENT environment variable:

Once enabled, the profile shows up as a normal pprof endpoint at /debug/pprof/goroutineleak, the same family as the existing heap, goroutine, and allocs profiles you're probably already using. You can also pull it programmatically:

Here's a function that fans out work across goroutines and collects results on an unbuffered channel, a pattern that shows up constantly in real codebases (batch processing, parallel API calls, worker pools):

If the caller only reads the first result and moves on, every other goroutine is stuck forever on out <- f(), because nobody is ever going to read from out again and the channel is unbuffered. Nothing crashes. Nothing logs. Each one just sits there permanently, holding onto whatever memory it captured in its closure, whether that's a large response body, an open file handle, or a database row set.

This exact shape (fan-out over an unbuffered channel, early return from the caller) is one of the most common leak patterns in real Go services, because it's invisible in code review. The function looks correct. It even works correctly for the happy path where the caller reads every value. It only leaks when the caller doesn't, and that's often a behavior introduced months later by a different engineer touching the calling code, not the Gather function itself.

Run the program above under the profiler and pull the profile with debug=2 for full stack traces (debug=1 gives you a condensed summary count per unique stack, useful for a quick glance; debug=2 gives you the full trace per goroutine, which is what you want when you're actually hunting a leak):

That (leaked) tag is the whole point. A normal goroutine profile would show [chan send] for a goroutine that's momentarily blocked waiting for someone to read, which is completely normal and happens constantly in healthy code. The goroutineleak profile only lists a goroutine with (leaked) when the reachability analysis has proven the channel it's blocked on can never be read from again. That distinction, provably stuck versus temporarily busy, is what turns this from noise into an actionable report you can hand to whoever owns that code.

A single leaked goroutine doesn't matter. A slow, steady leak that adds a few more every request cycle absolutely does, and in Kubernetes it shows up as a pod that runs fine for hours then gets OOMKilled on a schedule that roughly tracks your traffic pattern. If you've spent time troubleshooting CrashLoopBackOff and OOMKilled pods before, this is the same failure mode with a specific, provable root cause instead of "memory usage is high, we don't know why."

Never expose /debug/pprof/* publicly. Wire it behind an internal-only Service so only cluster-internal traffic (or a port-forward) can reach it:

With that in place, pull the profile before and after a load test, or on a quiet night versus a busy one, and diff the leaked-goroutine count between the two:

A leaked-goroutine count that only ever goes up, never down, even after traffic drops, is your signal. Cross-reference that timeline against kubectl describe pod and the OOMKilled reason under Last State, and you've gone from "memory keeps climbing, no idea why" to a stack trace pointing at the exact line that's holding onto memory. If you want to work backward from the crash instead, PodTriage walks through the exact kubectl commands to confirm an OOMKilled pod is a leak rather than an undersized limit before you ever open a profiler. If this service is part of a larger microservices setup, pulling that timeline alongside your existing distributed tracing and observability tooling makes it much faster to confirm the leak lines up with a specific upstream call pattern rather than general load.

This isn't a silver bullet, and it's worth being precise about why. If a blocked goroutine is still reachable through a global variable, a package-level cache, or another goroutine that's technically still runnable (even if that other goroutine is itself never going to do anything useful), the reachability analysis won't flag it as leaked, because from the garbage collector's strict point of view, something could theoretically still reach in and unblock it.

It also only reports goroutines blocked on channels, mutexes, and condition variables. A goroutine stuck in an infinite for loop that's still actively running (burning CPU instead of being blocked) isn't a candidate for this profile at all; that's a different problem you'd catch with a CPU profile instead. goleak in your test suite and this profile in production complement each other rather than one replacing the other.

Pick one service that's been mysteriously eating memory. Build it with the flag on, deploy it to staging behind the internal-only Service shown above, and add a scheduled job (a CronJob, or even a five-minute cron on your own machine hitting the port-forward) that curls the goroutineleak endpoint and writes the output somewhere you can diff over time. Run that for a week before you touch production.

The Go team has indicated Go 1.27 is expected to make this default-on, with no build flag required. Getting familiar with reading the output now, on a service you already suspect has a problem, costs you nothing later and means you'll already know what a real leak looks like the first time it shows up unprompted in a routine profile pull.

Go 1.26 also shipped testing/synctest improvements for deterministic concurrency testing, which pairs well with this: synctest lets you fast-forward fake time and control goroutine scheduling inside a test, so you can write a test that deliberately triggers the exact blocking condition the leak profiler is designed to catch, rather than waiting for it to happen under real production load. If you're moving containers off Docker Compose onto Podman Quadlet and systemd as part of a broader infrastructure cleanup, that's also a good moment to standardize on exposing pprof endpoints consistently across every service, rather than adding them one at a time only after something breaks.