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.

Related guides

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