skip to content

When diagnosing a slow build, how does a build scan help you attribute time between configuration and execution more precisely than the console output alone?

level: seniorimportance: should knowfreq 40%

answer

  1. --scan -> persisted, URL-shareable report
  2. Performance > Build phases = config vs exec seconds
  3. per-project configuration timing
  4. timeline gantt + outcomes + parallelism
  5. suggestions flag config-time resolution

basics

~20 s

A build scan (--scan) records a full timeline and a Performance section that splits wall time into initialization, configuration, and execution, names the slowest projects/tasks, and flags issues like configuration-time resolution — detail the plain console log never shows.

solid answer

~50 s

The console log shows task outcomes but not a phase-level time breakdown. A **build scan** (run with `--scan`, which uploads an indexed report) gives you a **Performance** section that splits total wall time into initialization, configuration, dependency resolution, and execution, plus a **timeline** view of every task with start time, duration, and outcome, and a parallelism/critical-path view. For the config-vs-execution question specifically, the Performance tab states how many seconds went to configuration versus execution and surfaces actionable insights — e.g. configurations resolved during the configuration phase, projects that are slow to configure, and cache effectiveness. Because scans are persisted and shareable by URL, you can compare a clean build against an incremental one, or one machine against another, to confirm whether the configuration slice is the stable bottleneck. The console alone can't quantify any of this.

code

bash · 6 lines
bash
# Capture a shareable, phase-attributed report:
gradle build --scan
# Accept the terms once; the build prints a URL like
#   Publishing build scan...
#   https://gradle.com/s/abc123
# Open Performance > Build phases to read configuration vs execution seconds.

go deeper

for a junior

Know that --scan produces a richer shareable report than the console log.

for a middle

Find the Build phases split and per-task timeline to attribute time to a phase.

for a senior

Use scans to compare runs/machines, localize the slow project, and read the suggestions (config-time resolution, cache hits).

for a principal

Drive org-wide adoption (Develocity) so phase regressions and cache-miss trends are tracked across the fleet, not diagnosed one build at a time.

## What the console does and doesn't tell you The normal build log prints each task with an outcome (`EXECUTED`, `UP-TO-DATE`, `FROM-CACHE`, `NO-SOURCE`) and a final wall-clock total. What it does *not* give you is a **per-phase split** or per-task durations — so you can see *that* the build was slow, but not whether configuration or execution dominated, nor which task or project caused it. ## What a build scan adds Running with `--scan` captures a rich, indexed report (published to a server and accessed by URL; an on-prem Develocity server can host it privately). The sections most relevant to phase diagnosis: - **Performance > Build phases**: the headline split — seconds in initialization, configuration, dependency resolution, and execution. This is the direct answer to "config or execution?" - **Performance > Configuration**: per-project configuration time, so you can see which subproject is expensive to configure. - **Performance > Settings and suggestions**: actionable warnings, including configurations resolved during the configuration phase and whether the configuration cache / build cache are enabled. - **Timeline**: every task with its start offset, duration, outcome, and the worker that ran it — invaluable for spotting a single dominating task or poor parallelism. - **Performance > Dependency resolution**: how long resolution took and where. ## Why this beats `--profile` in some situations `--profile` gives a similar phase split but as a local, throwaway HTML file with less drill-down and no sharing. Scans are **persisted and URL-shareable**, so you can attach one to a ticket, diff two scans, or compare across machines/CI. For a team chasing a regression ("configuration got 8s slower after this plugin bump"), scans are the better instrument; for a quick offline local check, `--profile` is fine. Both correctly attribute config vs execution — the difference is depth, persistence, and collaboration. ## A practical workflow 1. Reproduce the slow build with `--scan`. 2. Open **Performance > Build phases**; read configuration vs execution seconds. 3. If configuration dominates, drill into per-project configuration time and the suggestions (e.g. config-time resolution). If execution dominates, open the timeline to find the heavy tasks and check their outcomes/cache hits. 4. Share the URL so the team sees the same evidence. ```text --scan -> https://<server>/s/<id> Performance Build phases: init 0.4s | config 18.2s | exec 9.7s <-- config-bound Configuration: :app 11s, :core 5s ... Suggestions: 'runtimeClasspath' resolved during configuration Timeline: per-task gantt with outcomes ```

  • What advantage does a scan have over a local `--profile` report?
    Scans are persisted and shareable by URL with deeper drill-down (timeline, per-project config time, suggestions, cache insights), so teams can compare runs and attach evidence to tickets; `--profile` is a local throwaway HTML file.
  • How would you use scans to confirm a configuration-time regression after a plugin upgrade?
    Capture a scan before and after the upgrade and compare the Performance > Build phases configuration seconds and per-project configuration timing; a jump localized to configuration confirms the regression.
  • Can scans be used without sending data to gradle.com?
    Yes — Develocity (formerly Gradle Enterprise) lets an organization host scans on a private server, which is how regulated teams adopt them.

saying these in an interview costs you the question

  • Saying the console log already shows a per-phase time split — it does not.
  • Treating scans and `--profile` as identical; scans add persistence, timeline, and suggestions.
  • Assuming scans must go to a public server — Develocity supports on-prem hosting.

context

resolving links…