skip to content

You've published a Build Scan for a slow build. How do you use the Timeline tab to find the single slowest task and understand why the overall build took so long?

level: juniorimportance: must knowfreq 60%

answer

  1. Timeline tab
  2. sort by duration
  3. bar length = wall-clock
  4. worker lanes show parallelism
  5. click bar for outcome

basics

~10 s

Open the Build Scan's Timeline tab, sort tasks by duration (longest first), and read the top entry. It shows each task's wall-clock time so you can see which task dominated the build.

solid answer

~40 s

The Timeline tab lists every task in the build as a horizontal bar whose length is its execution duration, laid out across the worker threads that ran them. To find the slowest task you sort by **Duration** (descending) using the sort control; the top row is the single longest-running task. Clicking a bar shows details: the task path, type, outcome (SUCCESS, FROM-CACHE, UP-TO-DATE, NO-SOURCE), and how long it ran. Reading the longest tasks tells you where to focus — often a few `:compileJava`, test, or packaging tasks account for most of the wall-clock time. The Timeline also reveals whether the slow task ran alone (serializing the build) or overlapped with others, which is the start of a parallelism investigation.

code

bash · 6 lines
bash
# Publish a Build Scan for the build you want to analyze
./gradlew build --scan

# Output ends with a publishable link, e.g.:
# Publishing build scan...
# https://gradle.com/s/abcd1234efgh

go deeper

for a junior

Know how to open the Timeline, sort by duration, and read the top task plus its outcome.

for a middle

Distinguish a single fat task from a serial chain and use outcome filters to isolate executed work.

for a senior

Reason about worker-lane occupancy to diagnose parallelism gaps and connect slow tasks to caching/avoidance opportunities.

for a principal

Frame Timeline reading as one input into a fleet-wide performance program, correlating recurring slow tasks across many scans via Develocity.

## What a Build Scan Timeline is A **Build Scan** is a shareable HTML record of a single Gradle build, published to scans.gradle.com (or a Develocity server) by applying the Gradle Enterprise / Develocity plugin or running with `--scan`. Among its tabs, the **Timeline** tab is the per-task, time-ordered view of execution. Each task is drawn as a **horizontal bar**. The bar's **horizontal position** is when the task started; its **length** is how long it executed (wall-clock). Bars are stacked across the **worker lanes** (threads) Gradle used, so you can literally see what ran in parallel and what ran alone. ## Finding the slowest task 1. Open the **Timeline** tab. 2. Use the **sort** control and choose **Duration** (longest first). The list reorders so the longest-running task is on top. 3. Click the top bar to open its detail panel: **task path** (e.g. `:app:compileJava`), **task type**, **outcome**, and **duration**. The outcome matters: a task that took real time shows `SUCCESS` (it actually executed). Tasks marked `FROM-CACHE`, `UP-TO-DATE`, or `NO-SOURCE` contributed little or no execution time and are work that was *avoided*. ## Why the whole build was slow The slowest single task is only part of the story. Two patterns dominate: - **One fat task** — a single `:test` or `:compileKotlin` that genuinely takes minutes. Fix by splitting, caching, or optimizing that task. - **A serial chain** — many medium tasks running one-after-another on a single lane because of dependencies or lack of parallelism. The Timeline shows this as a long single-lane staircase. ## Filtering The Timeline supports filters — by **outcome** (show only executed tasks, hide `UP-TO-DATE`), by **status**, and a text search over task paths. Filtering to executed tasks only is the fastest way to see real work. ```text Timeline (sorted by Duration desc) :app:test ███████████████ 42.1s SUCCESS :app:compileKotlin ████████ 18.3s SUCCESS :lib:compileKotlin ██ 4.0s FROM-CACHE (avoided) ```

  • On the Timeline, how can you tell whether a slow task ran serially or in parallel with others?
    Look at the worker lanes: if the slow bar occupies a lane alone while other lanes are idle around it, it serialized the build. If other bars overlap it in time on adjacent lanes, work ran concurrently.
  • What does a FROM-CACHE outcome on the Timeline tell you about that task's duration?
    It executed almost no work — Gradle restored its outputs from the build cache instead of running the task body, so its duration reflects only download/unpack time, not real computation.

saying these in an interview costs you the question

  • Claiming the Timeline shows configuration-phase cost — it's about task execution; configuration timing is a separate concern.
  • Assuming the longest task is always the bottleneck without checking whether it ran in parallel or serialized everything else.

context

resolving links…