Go 1.27 adds a goroutine leak profiler for finding blocked goroutines in running programs
The profile reports goroutines stuck on channels or sync primitives that can never be released, and can be used in production.
The Go team has described a new goroutine leak profiler that ships with Go 1.27. A goroutine is considered leaked when it is blocked and the conditions needed to unblock it can never be met, which slowly increases memory and garbage collector work.
The profile is exposed as the goroutineleak type in runtime/pprof. Services that already register net/http/pprof get it automatically at the /debug/pprof/goroutineleak endpoint, with no further setup.
The mechanism works by tracing which goroutines can still reach the concurrency primitives that block others. It is limited to goroutines permanently blocked on channels or sync package types such as Mutex, RWMutex, WaitGroup and Cond. The team says this still covers a large share of real leaks and produces few false positives.
Goroutines waiting on file or network I/O, system calls or custom spin locks are never reported as leaked. The post also notes that detection can be slower than a regular garbage collection in some cases, while memory overhead is small.
Developers running Go services can enable the endpoint once on Go 1.27 and compare profiles over time. The authors suggest combining it with test-time tools such as goleak and the synctest package rather than relying on one approach.
Sources
- Goroutine Leak Profilesofficial
Verified Oct 24, 2026 (official source). goprofilingconcurrencyrelease