Skip to content
Latchkey

Gradle "Gradle build daemon disappeared unexpectedly" in CI

The Gradle daemon process vanished mid-build. On CI this is almost always the kernel OOM killer terminating the daemon because it (plus the test/compile JVMs) exceeded the runner’s memory.

What this error means

A build that was progressing suddenly fails with Gradle build daemon disappeared unexpectedly. There is no compile or test error - the daemon process was killed, often with no stack trace, mid-task.

gradle output
> Gradle build daemon disappeared unexpectedly (it may have been killed
  or may have crashed)
FAILURE: Build failed with an exception.

Common causes

OOM killer terminated the daemon

The daemon’s heap plus forked test/compile JVMs exceeded the runner’s RAM. The kernel SIGKILLs the heaviest process - the daemon - leaving no catchable error.

Daemon heap set too high for the runner

An org.gradle.jvmargs=-Xmx4g on a 4 GB runner leaves nothing for forked workers and the OS, so the build OOMs.

How to fix it

Cap the daemon heap to fit the runner

Set the daemon JVM args so the heap, plus forked workers, fits in the runner’s memory.

gradle.properties
# gradle.properties
org.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=512m
org.gradle.workers.max=2

Disable the daemon in CI

Ephemeral CI gets no benefit from a persistent daemon. Running with --no-daemon keeps memory bounded to a single build.

Terminal
./gradlew --no-daemon build
# or persist it:
# gradle.properties: org.gradle.daemon=false

How to prevent it

  • Run CI with --no-daemon or org.gradle.daemon=false.
  • Size org.gradle.jvmargs and org.gradle.workers.max to the runner’s RAM.
  • Use a larger runner for memory-heavy multi-module builds.

Frequently asked questions

What causes ""daemon disappeared unexpectedly""?
The daemon’s heap plus forked test/compile JVMs exceeded the runner’s RAM. The kernel SIGKILLs the heaviest process - the daemon - leaving no catchable error.
How do I fix "daemon disappeared unexpectedly"?
Set the daemon JVM args so the heap, plus forked workers, fits in the runner’s memory.
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.

Related guides

References

Latchkey auto-heals failures like this one - detected, fixed, and retried without you. Start free → 30-day trial · No credit card