Goroutine Leak

How a goroutine leak behaves

A goroutine leak is not a crash by itself, but a concurrency defect that leaves work units alive after they should have ended. The leaked goroutines may sit blocked on channels, waits, or context-related paths, so the application keeps paying for them even though they no longer contribute useful work.

Because goroutines are cheap to create, leaks often stay hidden during normal testing. The problem emerges when request volume rises, retry loops accumulate, or a long-running service slowly builds a backlog of stranded goroutines that are difficult to notice from one-off functional checks.

Why goroutine leaks hurt Go services

In a healthy Go program, goroutines should have a clear exit path tied to cancellation, completion, or timeout. When that path is incomplete, the leaked goroutine can keep references alive, retain locks, or continue waiting on events that will never arrive, which undermines efficiency across the whole process.

The impact is usually gradual rather than immediate. Throughput can fall, memory use can climb, and latency can worsen as scheduler pressure increases. In services that handle many concurrent requests, a small leak pattern can compound into a systemic capacity problem.

Leaks are especially dangerous when a goroutine waits on channels, network calls, or shared coordination primitives without a reliable way to stop. In those cases, the defect is not just wasted computation, it is a broken lifecycle for concurrency.

Common causes of leaked goroutines

The most common causes are incomplete cancellation handling, missing timeout paths, blocked channel sends or receives, and worker routines that never observe shutdown signals. Each of these creates a mismatch between the goroutine's lifetime and the task it was created to perform.

Leaks also appear when code starts background workers without defining ownership. If no component is responsible for stopping the worker, draining its inputs, or closing its outputs, the goroutine can outlive the request, job, or session that spawned it.

• Contexts are created but never canceled or are ignored inside child routines.
• Channel operations assume a reader or writer will always be present.
• Retry or polling loops do not exit when the parent request ends.
• Background tasks lack shutdown coordination during process termination.

How teams detect and limit goroutine leaks

Detection usually depends on watching goroutine counts, heap growth, latency, and stuck request patterns over time, then tracing those signals back to the code path that creates the leak. A single run is rarely enough; teams need trend visibility and a way to compare expected goroutine lifetimes with actual behaviour.

Once a leak is suspected, the usual fix is to make cancellation explicit, ensure every goroutine has a termination condition, and avoid channel patterns that can block forever. For distributed or service-heavy applications, the code review question is simple: what stops this goroutine, and who owns that stop condition?

For a broader operating model around runtime safety, access paths, and control discipline, it can help to anchor review work in The State of NHI & AI Agent Breach Report 2026, especially where long-lived processes and abandoned execution paths create persistence and exposure.

Related resources from NHI Mgmt Group

• Why do ServiceNow tickets leak secrets so often?
• Why do generative AI credentials increase the blast radius of a leak?
• Why do ServiceNow tickets and knowledge bases leak secrets so easily?
• How should teams stop LLMjacking when NHI secrets leak?