Skip to content
Latchkey

Go Tests OOM-Killed - Fix "signal: killed" Test Runs in CI

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

  1. Identify the package the kill names and profile it (go test -memprofile mem.out).
  2. Free large fixtures between cases and avoid loading whole datasets into memory.
  3. 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.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →