Go 1.27 adds a goroutine leak profile for finding blocked goroutines in running programs

The new pprof profile reports goroutines that can never be unblocked, with few false positives, and can be used in production.

The Go team has described the goroutine leak profile that arrives in Go 1.27. It reports goroutines that are blocked in a way that can never be resolved, such as a sender on an unbuffered channel whose receiver has already returned.

The profile is exposed as the goroutineleak type in runtime/pprof and, for services that already import net/http/pprof, at the /debug/pprof/goroutineleak endpoint. The post walks through a worker example where an early error return strands the remaining senders, and shows that giving the channel a buffer removes the leak.

Detection builds on the garbage collector: a goroutine counts as live if it is unblocked or blocked on something a live goroutine can reach. The approach covers goroutines blocked on channels and sync primitives such as Mutex, WaitGroup and Cond, but not those waiting on file or network IO.

The authors say memory overhead is small, though detection can be slower than a normal collection in unusual cases, so they suggest profiling periodically, for example every few hours. It works best alongside goleak and synctest in tests.

Sources

• Goroutine Leak Profilesofficial

Verified Oct 27, 2026 (official source). goprofilingconcurrencyruntime