skip to content

Scan Timeline And Cache Insights

4 roadmaps6 questions

Using a scan's timeline and performance views to find slow tasks, serial bottlenecks, and per-task cache outcomes. Asked because it turns 'the build is slow' into a specific task with a specific reason.

on this pageshow

explore

questions

6

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…

open as a page

On a Build Scan, what's the difference between UP-TO-DATE, FROM-CACHE, NO-SOURCE, and SUCCESS outcomes, and how does the scan quantify the savings from avoidance?

level: middleimportance: must knowfreq 50%

basics

~20 s

SUCCESS = the task ran. UP-TO-DATE = incremental check passed, skipped. FROM-CACHE = outputs restored from the build cache. NO-SOURCE = no inputs to act on. The scan tallies avoided tasks and estimates the time saved.

open as a page

Walk me through the Performance tab of a Build Scan. What breakdown does it give you and how do you use it to decide where to optimize?

level: middleimportance: must knowfreq 55%

basics

~20 s

The Performance tab splits total build time into phases — startup, settings/configuration, and task execution — and breaks execution into serial vs parallel time. You use it to see whether time went into configuration or execution before drilling in.

open as a page

A task you expected to be FROM-CACHE shows up as SUCCESS (a cache miss) in the Build Scan. How do you use the scan to diagnose why it missed?

level: seniorimportance: should knowfreq 45%

basics

~10 s

Open the task in the scan, check its outcome and cacheability, and compare its cache key/inputs against a previous build's scan. A changed input hash or a non-portable absolute path usually explains the miss.

open as a page

Using a Build Scan, how would you identify a serial bottleneck — a task or chain that prevents the build from parallelizing — and what does the critical path tell you?

level: seniorimportance: should knowfreq 40%

basics

~20 s

On the Timeline, look for a long stretch where one task runs while other worker lanes sit idle — that's a serial bottleneck. The critical path is the longest dependency chain; shortening it shortens the whole build.

open as a page