A slow build tells you where to start looking. The new Tasks page shows which Gradle tasks take the most time across builds, how often they execute, and how often they hit the cache.
Sort tasks by cumulative time to find repeated work that adds up, or compare p50, p90, and p99 durations to spot tasks with slow outliers. Filter by branch or environment to focus on the builds you want to improve.
Select a widget to explore execution trends, cache hit rates, or average and percentile durations over time. Open a task to inspect its individual executions, including outcomes and durations, then inspect an execution’s cache behavior and timing. Execution details link to the build behind them and back to the task overview.
Find it under Builds > Tasks in your Gradle project.
Large build outputs often change only in a few places, but traditional remote caches store every new version as a completely separate object. Kura now supports Bazel's content-defined remote cache chunking. The client splits a large output at stable content boundaries, uploads only chunks the cache does not already have, and records a compact recipe that reconstructs the original bytes.
This can reduce storage growth and upload work for successive versions of large artifacts while preserving the same verified content digest. Kura reconstructs downloads as a bounded stream, verifies every new recipe before accepting it, and safely falls back to a cache miss when a node cannot read the recipe. The capability is enabled by default for Bazel clients that negotiate it, while operators can temporarily disable new recipe writes during a reader-first fleet upgrade.
Module Cache reported how often the cache was hit, but not which modules were responsible. The new Modules page ranks every module by cache misses, with its hit rate and how many modules have to be rebuilt when it changes.
Each miss carries a reason. Changed means the module's own content moved, upstream means only a dependency did, and cold means there was nothing to compare against. Upstream misses are the ones better module boundaries can remove.
Opening a module adds every build it took part in, filterable by branch, commit SHA or reason, so a high upstream share leads to the commits behind it. Dependents needs the dependency edges newer CLI versions send; everything else works with the data the CLI already reports.
Find it under Module Cache › Modules.
Gradle build details now explain cache work that previously appeared only as a miss. The cache tab distinguishes confirmed remote misses, the time spent executing after those misses, and outputs stored for later builds. Its task table also identifies the reason a cacheable task ran again.
The new Build Setup tab shows configuration work by build, settings, and project phase. When Gradle uses its configuration cache, the tab records whether it was reused and lists invalidation reasons. It also lists the slowest artifact transforms, so dependency setup costs are visible beside task execution.
Existing Gradle integrations remain compatible. Older build reports continue to render normally, while newer plugin versions contribute the additional diagnostics when they are available.
The platform's programmatic interfaces now provide read parity for project configuration, shareable previews, automation alerts and their revision history, notification alert rules, continuous-integration runner activity including job logs, steps, and machine metrics, webhook delivery history, and account and project token metadata. Each operation follows the authorization policy of its platform domain. Token values remain unavailable after their one-time reveal, webhook signing secrets and encrypted automation action credentials are never returned, and webhook delivery data remains restricted to account administrators.
This makes it easier to investigate a project or audit its configuration from an agent without copying identifiers or sensitive token values into a conversation.
Organizations had two roles, admin and user, and both could act on what they saw. Muting a flaky test, deleting a preview, writing to the cache: a user could do all of it. Opening your build and test insights to the wider engineering team meant handing every one of them the ability to quarantine a test.
Members can now be added as viewers. A viewer reads projects, builds, test runs, previews, bundles, and runner activity, and cannot change any of it. Where a control would mutate something, a viewer sees the current value instead: a muted test case still reads as muted, it just cannot be un-muted from that page.
