skip to content

Profile HTML Report

4 roadmaps5 questions

The offline HTML profile report produced by --profile, broken into configuration, dependency resolution, and task execution. Interviewers ask about it as the option when publishing a scan is not permitted.

on this pageshow

explore

questions

5

What is the Gradle --profile HTML report and how do you generate one?

level: juniorimportance: must knowfreq 55%

answer

  1. --profile flag
  2. build/reports/profile/profile-*.html
  3. offline, no plugin
  4. config / dep-resolution / task-execution sections
  5. timestamped per run

basics

~10 s

Pass --profile to a build (e.g. ./gradlew build --profile). Gradle writes a self-contained HTML report to build/reports/profile/profile-<timestamp>.html showing where build time was spent.

solid answer

~40 s

The `--profile` command-line flag tells Gradle to instrument the build and emit an offline HTML report at `build/reports/profile/profile-<yyyy-MM-dd-HH-mm-ss>.html`. It requires no plugin, no network, and no account — it is built into Gradle. The report breaks total wall-clock time into phases: **Configuration** (per-project configuration time), **Dependency Resolution** (per-configuration resolve time), and **Task Execution** (per-task time, sorted slowest-first). A 'Summary' tab shows overall timings. You run it like `./gradlew assemble --profile`; each invocation produces a new timestamped file so you can compare runs. It is the simplest first step when a build feels slow and you can't or don't want to use a Build Scan.

code

bash · 3 lines
bash
./gradlew build --profile
# Report written to:
# build/reports/profile/profile-2026-06-30-09-12-44.html

go deeper

for a junior

Know the flag, the output path, and that it splits time into configuration/dependency-resolution/task-execution.

for a middle

Explain it's offline and plugin-free, why each run is timestamped, and that you read Summary first then drill in.

for a senior

Position --profile vs Build Scans (offline/coarse vs networked/rich) and stress running warm/repeated builds for valid numbers.

for a principal

Frame it as the zero-dependency baseline diagnostic suitable for restricted environments and CI artifact capture before standardizing on richer tooling.

## What `--profile` is `--profile` is a built-in Gradle command-line option that records timing data while a build runs and, at the end, writes a **self-contained HTML report** to: ``` <rootProject>/build/reports/profile/profile-<timestamp>.html ``` The timestamp (`yyyy-MM-dd-HH-mm-ss`) means every run produces a distinct file, so you can keep a history and diff runs by eye. The report is fully **offline** — no plugin, no Gradle account, no network call, unlike a Build Scan. That makes it safe for air-gapped or corporate environments. ## What it measures Gradle executes a build in phases, and the report mirrors them with tabs/sections: - **Summary** — total build time and a high-level breakdown. - **Configuration** — time spent *configuring* each project (running the build script bodies, registering tasks). High numbers here point at expensive configuration logic and are a classic argument for the **configuration cache**. - **Dependency Resolution** — time to resolve each `Configuration` (e.g. `compileClasspath`, `runtimeClasspath`). Spikes mean slow repositories, metadata downloads, or huge graphs. - **Task Execution** — every task that ran, with its duration, sorted slowest-first, plus its outcome (executed, `UP-TO-DATE`, `FROM-CACHE`, `NO-SOURCE`). ## How to generate and read it ```bash ./gradlew build --profile # -> build/reports/profile/profile-2026-06-30-09-12-44.html ``` Open the file in a browser. Start at **Summary** to see which phase dominates, then drill into that phase's section. Because the report is wall-clock based, run a **clean, warm-daemon** build for representative numbers, and run it more than once — the first run pays for compilation and downloads. ## When to reach for it `--profile` is the zero-setup, offline answer to 'why is my build slow?'. It's coarser than a Build Scan (no per-goal timeline, no cache-hit deep dive) but needs nothing installed and leaves an artifact you can attach to a ticket.

  • Where exactly is the report written?
    Under the root project's build dir: build/reports/profile/profile-<timestamp>.html, one new file per invocation.
  • Does --profile need a plugin or network access?
    No. It is built into Gradle and produces a fully offline, self-contained HTML file — unlike a Build Scan.

saying these in an interview costs you the question

  • Claiming you need to apply a plugin or sign in to use --profile
  • Confusing the offline profile report with a (network-published) Build Scan

context

resolving links…

open as a page

Walk through the sections of the --profile HTML report and what each one tells you.

level: middleimportance: must knowfreq 48%

basics

~10 s

The report has a Summary plus Configuration (per-project config time), Dependency Resolution (per-configuration resolve time), and Task Execution (per-task time with outcome). You read Summary first, then drill into the dominant phase.

open as a page

How do you make sure the numbers in a --profile report are trustworthy and reproducible?

level: middleimportance: should knowfreq 30%

basics

~10 s

Warm the daemon first, run the scenario more than once, control caches (clean vs incremental deliberately), keep the machine quiet, and compare like-for-like runs. The first cold run includes compilation/downloads and isn't representative.

open as a page

The profile report shows most time in the Configuration section. How do you interpret and act on that?

level: seniorimportance: should knowfreq 38%

basics

~10 s

High Configuration time means Gradle is spending too long running build scripts and configuring tasks every build. Reduce eager work, use lazy task registration, and enable the configuration cache so configuration is reused.

open as a page

When would you choose the --profile report over a Build Scan, and what are its limitations?

level: seniorimportance: should knowfreq 35%

basics

~20 s

Use --profile when you need a quick, offline, no-setup measurement — e.g. air-gapped CI or no Gradle account. It's coarser than a Build Scan: wall-clock phase breakdown only, single build, no per-task cache-hit insights or sharing.

open as a page