skip to content

How does the Gradle daemon's idle timeout work, and how do you configure it?

level: middleimportance: should knowfreq 45%

answer

  1. default 3h = 10,800,000 ms
  2. org.gradle.daemon.idletimeout (ms)
  3. lower = reclaim RAM, more cold starts
  4. 0 ≈ stop right after build
  5. one of several stop triggers

basics

~10 s

An idle daemon shuts itself down after a configurable period without builds — three hours by default. You change it with the org.gradle.daemon.idletimeout property, given in milliseconds.

solid answer

~40 s

After finishing a build a daemon stays alive and IDLE, ready to be reused. To avoid daemons living forever and hoarding RAM, each daemon self-terminates after an **idle timeout** with no work — the default is **10,800,000 ms (3 hours)**. You tune it via `org.gradle.daemon.idletimeout=<milliseconds>` in `gradle.properties` (project or `GRADLE_USER_HOME`). Setting it lower (e.g. a few minutes) reclaims memory faster on busy shared machines at the cost of paying cold-start more often; a value of `0` makes the daemon exit essentially right after a build. The timeout is one of several reasons a daemon may stop — Gradle also kills daemons under memory pressure or when an incompatible build requests different JVM args. The registry entry is removed when the daemon exits.

code

toml · 3 lines
toml
# gradle.properties
# value is in MILLISECONDS; default is 10800000 (3 hours)
org.gradle.daemon.idletimeout=600000   # 10 minutes

go deeper

for a junior

Know that idle daemons eventually shut down on their own.

for a middle

Name the property, that it's in milliseconds, and the 3-hour default; explain the memory-vs-warmth trade-off.

for a senior

Place idle timeout among the other stop triggers (--stop, memory, incompatible JVM args) and link it to registry pruning.

for a principal

Recommend timeout policy per host class: short on shared agents, default on laptops, daemon off in ephemeral CI.

## Why an idle timeout exists The daemon's whole point is to stick around between builds so the next build is fast. But a process that lives **forever** is a liability: on a developer laptop or a shared build host, abandoned daemons accumulate and consume heap. The **idle timeout** is the self-cleanup mechanism: a daemon that has gone a configured length of time without being asked to run a build shuts itself down and removes its entry from the registry. ## The default and how to change it The default idle timeout is **3 hours** = `10800000` milliseconds. Override it with a property (note the value is **milliseconds**): ```properties # gradle.properties (project or GRADLE_USER_HOME/gradle.properties) org.gradle.daemon.idletimeout=120000 # 2 minutes ``` - A **smaller** value reclaims memory sooner — good on memory-constrained or shared hosts — but you pay cold-start (JVM + JIT warm-up) more often. - A **larger** value keeps daemons warm longer, maximising reuse, at the cost of resident memory. - `0` effectively makes the daemon stop right after the build it just served. ## Where this sits among 'reasons a daemon stops' Idle timeout is only one trigger. A daemon may also stop because: - you ran `gradle --stop` (explicit graceful shutdown), - the OS or Gradle's own memory monitoring decides it's using too much heap, - a new build requests **incompatible** JVM args (different `-Xmx`, encoding, etc.), so Gradle won't reuse it. When any of these fire, the daemon exits and its entry is pruned from `GRADLE_USER_HOME/daemon/<version>/registry.bin`, so a later `--status` no longer lists it. ## Practical guidance Most teams leave the default on dev laptops. On CI you usually disable the daemon entirely (`org.gradle.daemon=false`) rather than tuning the timeout, since containers are ephemeral. The timeout is the knob you reach for on **long-lived shared build machines** where you want warmth without unbounded memory growth.

  • What unit is `org.gradle.daemon.idletimeout` in, and what's the default?
    Milliseconds. The default is 10,800,000 ms, i.e. 3 hours.
  • Besides the idle timeout, what else makes a daemon stop?
    An explicit `gradle --stop`, memory pressure, or a new build requesting incompatible JVM args so the existing daemon can't be reused.

saying these in an interview costs you the question

  • Stating the timeout is in seconds — it's milliseconds.
  • Claiming the daemon lives forever by default — it self-terminates after 3 hours idle.

context

resolving links…