Build "Killed" (Exit 137) During Maven/Gradle - OOM-Kill in CI
By Kaveh Alemi·Latchkey
The build process was SIGKILLed by the kernel OOM killer (exit 137) because the JVM, plus forked workers and the OS, exceeded the runner memory. There is no Java stack trace - the process was terminated from outside.
What this error means
A build that was progressing prints a bare Killed and the step exits with code 137. No OutOfMemoryError is logged because the kernel, not the JVM, ended the process.
shell
>Task :app:test
Killed
##[error]Process completed with exit code 137.
Common causes
Total memory exceeds the runner
The daemon/Maven JVM heap plus forked compile/test JVMs and the OS overshoot the runner RAM. The kernel kills the largest process - usually the build JVM.
Unbounded heap on a constrained runner
A large -Xmx (or default heap sized to host RAM) on a small container leaves no headroom, so the kernel OOM-kills the process under load.
How to fix it
Cap heap and parallelism to fit the runner
Bound the JVM heap and worker counts so total memory stays under the runner limit.
Bound JVM heap and worker counts to the runner RAM, limit forked-JVM memory, and use a larger-RAM runner for heavy builds.
Frequently asked questions
What causes ""Killed" / exit code 137"?
The daemon/Maven JVM heap plus forked compile/test JVMs and the OS overshoot the runner RAM. The kernel kills the largest process - usually the build JVM.
How do I fix "Killed" / exit code 137?
Bound the JVM heap and worker counts so total memory stays under the runner limit.
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.
