Developer Productivity Engineering Blog

How to use the Develocity IntelliJ plugin to speed up Gradle builds with real-time insights

By Stefan Wolf
October 6, 2025

If you’re anything like us on the Gradle engineering team, your day revolves around two things: writing great code and verifying it by running Gradle builds. While Gradle is powerful, sometimes those local build times, especially when you’re troubleshooting, can turn that “quick fix” into a painful waiting game.

We’re excited to share a tool designed to cut down on that frustrating cycle and bring build performance analysis right where you spend most of your time: your favorite IntelliJ IDE, like IDEA or Android Studio.

We’re talking about the Develocity IntelliJ Plugin, which integrates powerful real-time analysis directly into your IDE.

Why Local Troubleshooting Needs a Boost

As developers, we often start from a working state, a “green build”, make a small change, and then iterate several times to get back to a functional, green build. The time it takes for this cycle, the “Inner Development loop”, is crucial for productivity.

We know that you can’t fix a problem faster than you can build the code. Our goal is two-fold: make builds faster and simplify complex troubleshooting issues.

The Develocity IntelliJ plugin helps achieve this by providing powerful insights at every build, helping you understand where bottlenecks lie.

Introducing the Develocity IntelliJ Plugin

One of the standout features of this initial release is the Live Build Timeline. This timeline gives you immediate insights into your Gradle build performance with a detailed visualization of task execution and resource consumption (CPU and memory). Crucially, you get this initial level of insight without needing a Develocity server, subscription, or connection to the free public Build Scan® service.

As tasks run, they appear in the timeline in real-time. This helps you quickly identify bottlenecks, such as a single task taking an unusually long time to execute, suggesting it might be beneficial to parallelize the run.

The plugin is also designed to streamline connecting to Develocity or scans.gradle.com if you wish, allowing you to dive deeper and use the full power of Build Scan reports.

Installation and Setup: Get Started Today!

While the Develocity IntelliJ Plugin is powerful when connected to a server, its core feature, the Live Build Timeline, is immediately available for local build analysis even if you aren’t ready to publish reports or connect to a Develocity instance.

Installation

The Develocity IntelliJ Plugin is available on the JetBrains Marketplace.

  1. Go to File > Settings (or IntelliJ IDEA > Settings on macOS)
  2. Navigate to Plugins > Marketplace
  3. Search for “Develocity”
  4. Click Install next to the “Develocity” plugin and restart your IDE when prompted.

Quick Start: Enabling the Live Build Timeline

The Live Build Timeline feature requires the Develocity Gradle plugin 4.1 or newer to be applied to your Gradle build so that the IntelliJ plugin can receive data from the build process. Let’s use the Develocity settings to do that.

  1. Go to File > Settings (or IntelliJ IDEA > Settings on macOS)
  2. Navigate to Tools > Develocity
  3. Check Apply Develocity Gradle plugin
  4. Enter 4.2 into the textbox to select the version
  5. Press OK.

Check out the user manual for more information on the different ways to set-up the plugin.

Case Study: Diagnosing Unnecessary Test Re-execution

Let’s walk through a common scenario where the Live Build Timeline helps pinpoint a hidden performance issue using the google/ksp repository as an example.

Step 1: Initial Investigation

We start by running the check1 task via IntelliJ’s Run All dialog.

Looking at the Timeline view in the “Run” window, we observe the task execution. It’s clear that tests are taking up the majority of the build time, which is common in many projects.

Step 2: The Mysterious Re-execution

We re-run the check task without making any source code changes. Surprisingly, two test tasks re-execute instead of being marked as “UP-TO-DATE”.

If you were just looking at the console output, you might scratch your head or assume it’s just a Gradle hiccup. But with the Develocity plugin, we can investigate immediately.

Step 3: Pinpointing the Root Cause

By looking closer at the timeline and clicking on the re-executed task, we get a detailed task summary showing the “Out of date reasons”.

Here, the timeline reveals that the tasks re-executed due to specific file changes. We see input properties like jvmArgumentProviders.$2.file listed as problematic.

Diving into the build file reveals a configuration issue: The java.io.tmpdir location for the test JVM is being modified as intended, but it’s also being added as an input file to the task:

jvmArgumentProviders.add(RelativizingPathProvider("java.io.tmpdir",temporaryDir))

Since tests will always write temporary files to the tmp directory, and that directory is incorrectly treated as a task input, Gradle sees the contents of the “input” directory as changed every time and is forced to re-execute the test tasks, even if the actual source code hasn’t changed.

Step 4: Applying the Targeted Fix

The solution is to tell Gradle to ignore the temporary directory as an input for task dependency checking. We simply swap out the provider in the build file.

We change this:

jvmArgumentProviders.add(RelativizingPathProvider("java.io.tmpdir", temporaryDir))

To this:

jvmArgumentProviders.add(RelativizingInternalPathProvider("java.io.tmpdir", temporaryDir))

Step 5: The Speedy Result

On a final re-run, with the issue fixed, the test tasks are now correctly marked as up-to-date, and the entire build time plummets to roughly 1 second.

That’s real, measurable performance optimization achieved without leaving your IDE!

And we can now contribute the improvement back to the community: https://github.com/google/ksp/pull/2612

Going Further: Dive deeper with Build Scan reports

While the Live Timeline is fantastic for local debugging, the plugin truly shines when connected to Develocity or scans.gradle.com. Let’s connect to scans.gradle.com!

  1. Go to File > Settings (or IntelliJ IDEA > Settings on macOS)
  2. Navigate to Tools > Develocity
  3. Check Configure Develocity integration
  4. Agree to the Terms of Use
  5. Press OK

When you run a Gradle build now, you will get a pop-up pointing you to the published Build Scan, and you can also navigate deep into it from an individual task in the IntelliJ timeline.

This immediate access is invaluable when you encounter failures. You can open the failed task in the browser with one click, accessing advanced features like AI-driven Failure Grouping in Develocity. For example, in this Build Scan from the Apache Kafka project 5 separate test failures failed for the same reason and are grouped together. And there is so much more value in Develocity, check out https://gradle.com/develocity/.

What’s Next?

We are continuously working to expand the functionality of the plugin, with future features slated to include contextual data for your build failures from Develocity, integration with your AI agent, and more!

If you are using Gradle builds in IntelliJ IDEs, we recommend trying out the plugin. The goal is simple: ensure all developers using Gradle (and later Maven) have an exceptional experience right in their IDE.

If you get a chance to try it, please share your feedback!

—

1Actually, we are running check -x :integration-test:check to avoid running the integration tests