Go Tests OOM-Killed - Fix "signal: killed" Test Runs in CI
By Kaveh Alemi·Latchkey
A test run exhausted memory and was killed. A leak across cases, an unbounded fixture, a heavy benchmark, or too much parallelism can push the test process past the runner’s RAM and trigger an OOM kill.
What this error means
A package test ends with fatal error: runtime: out of memory, or the step dies with signal: killed and no test failure. It often correlates with a specific package, parallelism level, or a fuzz/benchmark run.
go test output
fatal error: runtime: out of memory
# or, OOM-killed by the OS with no Go stack:
go test github.com/org/app/ingest: signal: killed FAIL
Common causes
A leak or unbounded allocation across cases
A test (or the code it exercises) accumulates memory that is never released - a growing global, an unclosed resource, or a fixture loaded per case - until the process is killed.
Too much test parallelism for the runner
High -p/-parallel runs many memory-heavy packages or cases at once, and the combined footprint exceeds available RAM.
How to fix it
Reduce parallelism
Lower concurrent package and in-package parallelism so peak memory fits the runner.
Terminal
go test -p 2 -parallel 2 ./...
Bound memory-heavy tests
Identify the package the kill names and profile it (go test -memprofile mem.out).
Free large fixtures between cases and avoid loading whole datasets into memory.
Cap fuzz/benchmark scope in CI (-benchtime, smaller corpora).
Use a larger runner for the heavy suite
.github/workflows/ci.yml
jobs:test:runs-on:ubuntu-latest-4-cores
How to prevent it
Free large fixtures and close resources between test cases.
Tune -p/-parallel to the runner’s memory.
Bound fuzz/benchmark scope in CI runs.
Frequently asked questions
What causes "tests OOM-killed"?
A test (or the code it exercises) accumulates memory that is never released - a growing global, an unclosed resource, or a fixture loaded per case - until the process is killed.
How do I fix tests OOM-killed?
Lower concurrent package and in-package parallelism so peak memory fits the runner.
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.
