skip to content

What does the 'Reusing configuration cache.' message mean, and what message do you expect on the very first run?

level: middleimportance: should knowfreq 55%

answer

  1. hit prints 'Reusing configuration cache.'
  2. miss prints 'Calculating task graph...'
  3. first run = store, no entry yet
  4. requested tasks are part of the key
  5. entries under .gradle/configuration-cache/

basics

~20 s

'Reusing configuration cache.' means Gradle found a valid cached task graph and skipped the configuration phase. On the first run there is no entry, so it instead reports that it is calculating/storing the task graph.

solid answer

~40 s

`Reusing configuration cache.` is the log line Gradle prints when it gets a **hit**: a previous run stored a serialized task graph whose inputs still match, so Gradle skips the entire configuration phase and proceeds straight to execution. On the **first** run (or after any input change), there is no usable entry, so Gradle prints something like `Calculating task graph as no configuration cache is available for tasks: <requested tasks>` and then stores a new entry. Seeing `Reusing configuration cache.` is the quickest way to confirm the cache is actually working — if you never see it, your configuration inputs are changing between runs (a different requested task set, a script edit, or reading mutable environment/system-property/file inputs at configuration time), so every run is a miss.

go deeper

for a junior

Know that 'Reusing configuration cache.' means it worked (a hit) and that the first run can't reuse anything.

for a middle

Describe both the hit and miss messages and name common reasons the cache keeps missing.

for a senior

Explain that requested tasks plus configuration inputs form the key, and how to assert hits in CI by grepping the log.

for a principal

Use the hit/miss signal as a fleet metric — track config-cache hit rate across CI and treat persistent misses as a buildscript hygiene defect.

## The messages, by scenario The configuration cache reports its state on every run so you can see whether it hit or missed. - **Cold / first run (store):** `Calculating task graph as no configuration cache is available for tasks: assemble` Gradle runs configuration normally and *stores* a serialized entry at the end. - **Warm run, same inputs (hit):** `Reusing configuration cache.` Configuration is skipped entirely; only execution runs. - **Warm run, inputs changed (store, with reason):** `Calculating task graph as configuration cache cannot be reused because <reason — e.g. file 'build.gradle.kts' has changed>.` Gradle reconfigures and stores a fresh entry. ## Why you might never see a hit A `Reusing configuration cache.` only appears when *all* the recorded inputs are identical. Common reasons it keeps missing: - You requested a **different set of tasks** (the requested tasks are part of the key). - A **build script or plugin** changed. - The configuration phase **read a mutable input** — `System.getenv(...)`, `System.getProperty(...)`, a `providers.exec`, or a file whose content changed — which becomes a tracked input, so any change invalidates the entry. ## Practical use In CI or local benchmarking, grep the output for `Reusing configuration cache.` to assert the cache hit. Pair it with `--configuration-cache` (or the property) so the feature is active in the first place. ```bash ./gradlew help --configuration-cache | grep -i 'configuration cache' ``` The cache entries themselves live under `.gradle/configuration-cache/` in the project directory; deleting that folder forces a cold rebuild of the entry.

  • You run the same command twice but never see 'Reusing configuration cache.' — what would you check?
    Whether the requested task set differs, whether a build script/plugin changed, and whether configuration-time code reads mutable inputs (env vars, system properties, files) that change between runs and thus invalidate the entry.
  • Where are configuration cache entries stored on disk?
    Under the project's `.gradle/configuration-cache/` directory; deleting it forces Gradle to recompute and store a fresh entry.

saying these in an interview costs you the question

  • Saying the first run prints 'Reusing configuration cache.' — the first run is a store, not a hit.
  • Claiming a hit re-runs configuration but caches outputs — a hit skips configuration entirely.
  • Assuming the same command always hits, ignoring that requested tasks and config inputs form the key.

context

resolving links…