skip to content

What does the -Dorg.gradle.internal.tasks.stats system property give you, and how does it differ from --profile?

level: seniorimportance: should knowfreq 25%

answer

  1. internal system property, not public CLI
  2. aggregates by task TYPE and OUTCOME
  3. outcome = executed/up-to-date/from-cache/skipped
  4. console text, grep-able for CI
  5. format not guaranteed stable

basics

~20 s

Setting -Dorg.gradle.internal.tasks.stats=true makes Gradle print, at the end of the build, an aggregate breakdown of task execution by task type and by outcome (executed, up-to-date, from-cache, skipped) — a text summary, not an HTML report.

solid answer

~40 s

`-Dorg.gradle.internal.tasks.stats` is an *internal* Gradle system property that, when enabled, prints a console summary after the build aggregating tasks by **implementation type** and by **outcome** (EXECUTED, UP-TO-DATE, FROM-CACHE, NO-SOURCE, SKIPPED), with counts and total durations. Where `--profile` answers "which *phase* and which *individual tasks* were slow" via HTML, this property answers "across the whole build, which task *types* dominate and how effective is incrementality/caching" via plain text. It's handy in CI logs and scripts because it's grep-able, and it's good for spotting that, say, all your time is in one custom task type or that cache effectiveness is poor. Caveat: it's an *internal* property — undocumented and not guaranteed stable across Gradle versions — so treat output format as best-effort.

code

bash · 3 lines
bash
./gradlew build -Dorg.gradle.internal.tasks.stats=true 2>&1 | tee build.log
# Inspect cache/incrementality health
grep -iE 'EXECUTED|FROM-CACHE|UP-TO-DATE|SKIPPED' build.log

go deeper

for a junior

Awareness only: it's an internal property that prints task statistics at the end of the build.

for a middle

Know it aggregates by task type and outcome as console text, distinct from --profile's HTML.

for a senior

Use it to diagnose caching/incrementality health and dominant task types; know it's internal and unstable.

for a principal

Decide when grep-able console stats beat HTML in CI; understand outcome distribution as a fleet-wide cache-effectiveness signal and pair it with the build cache strategy.

## The property ```bash ./gradlew build -Dorg.gradle.internal.tasks.stats=true ``` Being under `org.gradle.internal.*`, this is an **internal** knob: not part of the public, documented CLI surface, and its presence/format can change between Gradle releases. Use it for diagnostics, not as a contract. ## What it prints At the end of the build Gradle emits an aggregated table to the console, grouping executed tasks two ways: - **By task type (implementation class)** — e.g. how many `JavaCompile`, `Test`, or `MyCustomTask` instances ran and their combined time. This is the key differentiator: it rolls up *across* tasks of the same kind. - **By outcome** — counts of tasks that were `EXECUTED`, `UP-TO-DATE`, `FROM-CACHE`, `NO-SOURCE`, or `SKIPPED`. That outcome breakdown is effectively a **cache/incrementality health summary**: a high `EXECUTED` share when you expected reuse signals poor up-to-date checking or cache misses worth investigating. ## Contrast with --profile | Dimension | --profile | tasks.stats | |---|---|---| | Output | HTML report (file) | console text | | Granularity | per individual task + per phase | aggregated by task *type* and *outcome* | | Phase view (config/resolution) | yes | no — it's task-execution focused | | Stability | public flag | internal property, may change | | Best for | "which phase / which task is slow" | "which task *type* dominates; how good is reuse" | They're complementary. `--profile` finds the one slow task; `tasks.stats` tells you if a whole *category* of tasks (or poor caching) is the systemic problem. ## Practical pattern Drop it into a CI job's diagnostic run and grep the log: ```bash ./gradlew build -Dorg.gradle.internal.tasks.stats=true 2>&1 | tee build.log grep -iE 'EXECUTED|FROM-CACHE|UP-TO-DATE' build.log ``` ## Why not always on? Because it's internal/undocumented and the summary adds noise; reach for it when triaging caching effectiveness or a suspiciously dominant task type, then turn it off.

  • Is tasks.stats a supported public flag?
    No — it lives under org.gradle.internal.*, which is internal and undocumented. The format can change between versions, so don't build tooling that depends on it staying stable.
  • What does a high EXECUTED count (vs UP-TO-DATE / FROM-CACHE) tell you?
    That incrementality or caching isn't kicking in as expected — tasks are doing full work each run. It's a prompt to check task input/output declarations, cacheability (@CacheableTask), and whether the build cache is enabled.

saying these in an interview costs you the question

  • Treating it as a stable, documented public API (it's internal — format may change).
  • Claiming it produces an HTML report like --profile (it's console text, aggregated by type/outcome).

context

resolving links…