Gradle "Daemon disappeared unexpectedly" (Test OOM) in CI
By Daniel Zoghalchali·Latchkey
When the Gradle daemon process is killed mid-build - most often OOM-killed by the kernel on a constrained runner during a heavy test or build phase - the client reports the daemon "disappeared unexpectedly" or crashed. It is an external termination, not a Gradle logic error.
What this error means
The build aborts with Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed), frequently right after a memory-heavy test or compilation task. The runner log may show an OOM kill.
gradle
> Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
----- Last 20 lines from daemon log file - daemon-1234.out.log -----
... process was terminated (exit code 137)
The daemon's heap/Metaspace plus the work it drives exceeds runner memory, and the kernel kills it (exit 137). This is the transient capacity case.
Native crash in the daemon
A native library or JVM crash in the daemon process can also make it disappear; the daemon log's last lines identify which.
How to fix it
Give the daemon more heap (and keep tests forked)
Raise the daemon JVM heap and bound test worker memory so totals fit in RAM.
gradle.properties
# gradle.properties
org.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=512m
# build.gradle: workers separate from the daemon
# test { maxHeapSize = '1g'; maxParallelForks = 1 }
Confirm OOM vs native crash
Read the printed daemon log tail: exit 137 = OOM kill; a JVM crash references an hs_err file.
Reduce concurrent work (parallel forks, --max-workers) if memory is the limit.
Use a larger runner for memory-heavy builds.
How to prevent it
Size org.gradle.jvmargs and test worker memory to the runner, avoid over-parallelism, and run heavy Gradle builds on larger runners.
Frequently asked questions
What causes Gradle "Daemon disappeared unexpectedly" (Test OOM) in CI?
There are 2 common causes: daemon jvm oom-killed and native crash in the daemon. The daemon's heap/Metaspace plus the work it drives exceeds runner memory, and the kernel kills it (exit 137).
How do I fix Gradle "Daemon disappeared unexpectedly" (Test OOM) in CI?
There are 2 fixes depending on which cause you have: give the daemon more heap (and keep tests forked) and confirm oom vs native crash. Work through them in order, since the first is the most common.
What does Gradle "Daemon disappeared unexpectedly" (Test OOM) in CI actually mean?
The build aborts with Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed), frequently right after a memory-heavy test or compilation task.
How do I stop Gradle "Daemon disappeared unexpectedly" (Test OOM) in CI happening again?
Size org.gradle.jvmargs and test worker memory to the runner, avoid over-parallelism, and run heavy Gradle builds on larger runners.
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.
