skip to content

Daemon Idle Timeout & Lifecycle

4 roadmaps5 questions

The daemon idle timeout and when stale daemons are evicted. Interviewers ask because a generous timeout on a shared machine keeps gigabytes resident for no benefit.

on this pageshow

explore

questions

5

What does the org.gradle.daemon.idletimeout property control, and what is its default?

level: juniorimportance: must knowfreq 45%

answer

  1. milliseconds, not seconds
  2. default 3 hours = 10800000
  3. idle-only timer, resets on build
  4. set in gradle.properties
  5. frees warm-JVM heap

basics

~10 s

It sets how long (in milliseconds) an idle Gradle daemon stays alive before shutting itself down. The default is 10800000 ms — three hours.

solid answer

~30 s

`org.gradle.daemon.idletimeout` is a build-environment property (set in `gradle.properties`) expressed in **milliseconds**. After a build finishes, the daemon process stays warm waiting for the next build; if no build arrives within the idle window it terminates and frees its memory. The default is `10800000` ms = **3 hours**. You lower it (e.g. to a few minutes) on shared or memory-constrained machines so stale daemons don't sit around holding heap, and raise it on a dev box where you want maximum warm-JVM reuse. It only governs *idle* shutdown — an active build, or hitting the daemon process limit, are separate concerns.

code

toml · 3 lines
toml
# gradle.properties
org.gradle.daemon.idletimeout=600000
# 600000 ms = 10 minutes of idle before the daemon exits

go deeper

for a junior

Know it's a millisecond idle timer with a 3-hour default, set in gradle.properties.

for a middle

Explain why you'd shorten it (memory/CI) vs lengthen it (warm reuse) and that it's idle-only.

for a senior

Tie it to per-JVM-arg daemon multiplication and machine-wide memory budgeting via the user-level gradle.properties.

for a principal

Frame it as one lever in an org-wide build-environment baseline (idletimeout + jvmargs + daemon policy) shipped to every dev and agent.

## What the Gradle daemon is (just enough) The Gradle **daemon** is a long-lived background JVM that runs your builds. The first build pays JVM startup, class loading and JIT warm-up; subsequent builds reuse that warm process, so they're much faster. To avoid leaking memory forever, an idle daemon eventually shuts itself down. ## The idletimeout knob `org.gradle.daemon.idletimeout` is the timer for that self-shutdown. Key facts: - **Unit: milliseconds.** This trips people up — `10800000` is 3 hours, not 3 seconds. - **Default: `10800000` (3 hours).** - **Scope: idle only.** The clock starts when a build *finishes*. Any new build resets it; while a build runs, the timeout is irrelevant. - **Where you set it:** a `gradle.properties` file. Project-level `./gradle.properties` or user-level `~/.gradle/gradle.properties` (the user-level one applies to every project on the machine). ```properties # ~/.gradle/gradle.properties org.gradle.daemon.idletimeout=900000 # 15 minutes ``` ## Why tune it - **Memory pressure / shared CI agents:** a daemon can hold a multi-hundred-MB heap. A short idletimeout reclaims that quickly after the build. - **Many projects on one machine:** each distinct JVM-arg/JDK combination spins up its *own* daemon; long timeouts mean several fat JVMs idling at once. - **Pure dev throughput:** a long timeout maximizes warm reuse across a day of edit-build cycles. ## What it does NOT do - It does not disable the daemon — that's `org.gradle.daemon=false` / `--no-daemon`. - It does not control how many daemons exist or how Gradle finds a compatible one. - It does not force-kill busy daemons; only idle ones honor it. Think of it as the "how long an empty desk stays reserved before it's freed" timer.

  • If you set idletimeout to 1000, will builds restart a daemon almost every time?
    Yes — 1000 ms is one second, so after each build the daemon shuts down almost immediately and the next build pays cold-start cost, defeating the daemon's purpose.
  • Does idletimeout affect a build that's currently running?
    No. The timer only starts counting when the daemon goes idle (a build finishes). A long-running build is never killed by idletimeout.

A warm car left idling: idletimeout is how long it keeps running before auto-shutting off to save fuel — only counts while parked, not while you're driving.

saying these in an interview costs you the question

  • Saying the value is in seconds — it is milliseconds.
  • Claiming idletimeout disables the daemon; that's a different property.
  • Thinking it can terminate an active build.

context

resolving links…

open as a page

How do you inspect which Gradle daemons are alive and in what state, and how do you force them to stop? When would you reach for each command?

level: middleimportance: should knowfreq 38%

basics

~10 s

gradle --status lists live daemons with their PID, Gradle version and status (IDLE/BUSY). gradle --stop terminates all daemons for that Gradle version. Use --status to inspect, --stop to clear stale/misbehaving daemons immediately.

open as a page

On a memory-constrained or shared CI agent, how would you tune the daemon idle timeout, and what trade-off are you making?

level: middleimportance: should knowfreq 40%

basics

~10 s

Lower org.gradle.daemon.idletimeout (e.g. to 1–5 minutes) so idle daemons exit fast and release their heap. The trade-off: more cold starts, so slightly slower first builds.

open as a page

Why might Gradle start a brand-new daemon and leave the old one idle even though one was already warm? How does idletimeout relate to that stale daemon?

level: seniorimportance: should knowfreq 35%

basics

~20 s

A daemon's JVM args and JDK are fixed at startup. If a build requests incompatible args (different heap, JDK, etc.), Gradle can't reuse the warm daemon, so it starts a fresh one. The old daemon sits idle and is only reclaimed when its idletimeout expires.

open as a page

What happens if you set org.gradle.daemon.idletimeout to 0 (or a very small value)? Is that the same as disabling the daemon?

level: seniorimportance: nice to knowfreq 22%

basics

~20 s

Setting idletimeout to 0 (or tiny) means the daemon shuts down almost as soon as it goes idle — so you lose warm reuse between builds. It is NOT the same as disabling the daemon: a daemon still forks, runs your build, then exits.

open as a page