The Go runtime aborted because the OS refused a memory request. In CI this happens when a build, test, or data job exceeds the runner RAM (or a container memory limit).
What this error means
A Go step prints fatal error: runtime: out of memory with a runtime stack and exits. Lowering parallelism or using a larger runner clears a one-off spike with no code change.
shell
fatal error: runtime: out of memory
runtime stack:
runtime.throw({0x...})
/usr/local/go/src/runtime/panic.go:1047
Common causes
The job exceeded available RAM
A large go test ./..., race-detector run, or data load can spike past the runner memory.
A container or cgroup limit
A --memory limit caps the runtime even when the host has free RAM.
How to fix it
Lower memory pressure
Reduce concurrency and disable the memory-heavy race detector where not needed.
shell
go test -p 2 ./... # fewer parallel packages
# avoid -race in memory-tight jobs
GOMEMLIMIT=3GiB go build ./...
Right-size the runner
Move memory-heavy Go jobs to a runner with more RAM.
Raise or remove a tight container --memory limit.
Split very large test runs into smaller jobs.
How to prevent it
Set GOMEMLIMIT to keep the runtime under the ceiling.
Bound go test parallelism in CI.
Right-size memory for race-detector runs.
Frequently asked questions
What causes "Go runtime OOM"?
A large go test ./..., race-detector run, or data load can spike past the runner memory.
How do I fix Go runtime OOM?
Reduce concurrency and disable the memory-heavy race detector where not needed.
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.