Skip to content
Latchkey

Go "panic: test timed out" - Fix Test Timeouts in CI

go test enforces a per-binary timeout (10 minutes by default) and panics if a test run exceeds it, dumping all goroutine stacks. The dump shows whether a test deadlocked, blocked forever, or was just genuinely slow.

What this error means

A test run aborts with panic: test timed out after 10m0s followed by a full goroutine stack dump. The job exceeds the timeout and fails. It can be a hard hang (deterministic) or an occasional slow run near the limit (intermittent).

go test output
panic: test timed out after 10m0s
running tests:
	TestWorkerDrain (10m0s)

goroutine 34 [chan receive]:
github.com/yourorg/app.(*Worker).Drain(...)
	worker.go:88 +0x...

Common causes

A deadlock or blocked goroutine

A test waits on a channel send/receive, a mutex, or a WaitGroup that never completes, so it blocks until the timeout fires. The stack dump shows the goroutine parked on the blocking operation.

A genuinely slow test near the limit

Integration tests, large fixtures, or a slow external dependency can push a run past the default timeout, especially on a loaded CI runner.

A missing context deadline

A call with no timeout (network, subprocess) hangs indefinitely when the dependency is slow or unreachable in CI.

How to fix it

Find the blocked goroutine in the dump

  1. Read the running tests: line - it names which test hung.
  2. Find that test’s goroutine in the dump; its top frame shows where it is blocked (chan receive, sync.Mutex, etc.).
  3. Fix the deadlock - close the channel, signal the WaitGroup, or add a context timeout.

Raise the timeout for legitimately slow suites

If the test is correct but slow, give it more time explicitly.

Terminal
go test -timeout 20m ./...

Bound the operation under test

worker_test.go
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
result, err := svc.Call(ctx)

How to prevent it

  • Give every blocking call a context deadline so it can never hang forever.
  • Set an explicit -timeout matching your suite’s real runtime.
  • Run -race to surface the synchronization bugs that cause deadlocks.

Frequently asked questions

What causes ""panic: test timed out""?
A test waits on a channel send/receive, a mutex, or a WaitGroup that never completes, so it blocks until the timeout fires. The stack dump shows the goroutine parked on the blocking operation.
How do I fix "panic: test timed out"?
Find the blocked goroutine in the dump
Can Latchkey fix this automatically?
Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.

Related guides

References

Latchkey auto-heals failures like this one - detected, fixed, and retried without you. Start free → 30-day trial · No credit card