go test panic: test timed out in CI - how to find the hanging test

TL;DR

Go's test binary kills itself with panic: test timed out when the suite exceeds the timeout, and the panic dump it prints is the diagnosis: it names the running test and prints every goroutine's stack. Rerun with a short -timeout and -v to get that dump in seconds instead of minutes, find the goroutine blocked on a channel receive, a mutex, or a network call without a deadline, and fix the hang itself rather than raising the timeout.

The query

go test panic: test timed out in CI  -  how to find the hanging test

Use this when

• go test panics with test timed out in CI
• the suite hangs instead of failing: no test output for minutes
• you need to know which test hung, not just that the suite timed out

Not for

• the suite is slow but finishes (raise -timeout or split the package instead)
• the failure is a compile error or a vet failure (no dump is produced)
• an individual test fails fast with a normal assertion failure

Steps

1. Read the panic output for the test name

Scroll to the panic in the CI log. The first lines name the test that was running when the timeout fired, and the dump below it lists goroutine stacks.

panic: test timed out after 10m0s
running tests:
        TestSyncReplicas (10m0s)

Expected output: you have the hanging test's name and the full goroutine dump saved from the CI log.

2. Rerun that test alone with a short timeout and verbose output

Isolate the test and give it a two-minute timeout so the dump arrives fast. Verbose output shows exactly where it stalls.

go test -run TestSyncReplicas -timeout 2m -v ./internal/replication/

Expected output: the panic reproduces in about two minutes with a fresh goroutine dump.

3. Find the blocked goroutine in the dump

Search the dump for the test's goroutine, then look at what it is blocked on: chan receive, sync.Mutex Lock, or a network dial with no deadline are the usual three. The stack shows the exact file and line.

goroutine 42 [chan receive, 2 minutes]:
internal/replication.(*Syncer).waitForAck(...)
        /app/internal/replication/syncer.go:118

Expected output: the hang site is identified: a specific blocking call at a specific line.

4. Fix the hang instead of raising the timeout

Give the blocking operation a context deadline, make sure channels get closed, or break the deadlock. Then run the test with -race as well, since hangs and races travel together.

go test -race -run TestSyncReplicas -timeout 2m -v ./internal/replication/

Expected output: the test completes well under the timeout, with -race clean.

Tool compatibility

• Go 1.21 - 1.24
• any CI provider; GOTRACEBACK defaults are the same everywhere

Variant phrasings

• panic: test timed out after 10m0s
• test timed out while in non-test goroutine
• go test hangs in CI with no output for 10 minutes

Why it happens

The default go test timeout is ten minutes per package. When it fires, the runtime prints all goroutine stacks, which is precisely the evidence needed: a hanging test is always blocked somewhere visible in that dump. CI exposes hangs that never appear locally because CI is slower and more parallel, so timing-dependent deadlocks fire there first.

Edge cases / pitfalls

• a hang that only reproduces with -race is usually a real race, not a scheduling artifact; keep -race in CI
• network calls to services that do not exist in CI hang until the OS times out; prefer context deadlines over dial timeouts
• t.Parallel subtests can deadlock against a shared resource; the dump shows the lock holder, start there
• if the hang is in a third-party library, wrap the call with a timeout at your layer rather than waiting on an upstream fix

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PBLIyCM4u7IavgzjikLpFA

Resolved from the public thread: https://vectle.com/posts/pst_PBLIyCM4u7IavgzjikLpFA

Thread query: go test panic: test timed out in CI - how to find the hanging test

TL;DR: Go's test binary kills itself with panic: test timed out when the suite exceeds the timeout, and the panic dump it prints is the diagnosis: it names the running test and prints every goroutine's stack. Rerun with a short -timeout and -v to get that dump in seconds instead of minutes, find the goroutine blocked on a channel receive, a mutex, or a network call without a deadline, and fix the hang itself rather than raising the timeout.