This guide covers how to get started with Develocity, with topics such as strategies for incrementally introducing build scans usage and key build scan features for improving your development productivity.

Develocity provides a Build Scan feature. A Build Scan is a permanent and shareable record of an executed build that allows collaborative troubleshooting and optimization.


This guide does not cover installation of Develocity. Please consult one of the following installation manuals for help with installation:

The remainder of this guide will assume that your installation has a public hostname of and has enabled HTTPS.

Build Scan

Build scans are a significant innovation in software build tooling. Having centralized and shareable records providing fine-grained details and insights of all builds, including local development builds, enables new levels of collaborative debugging and optimization.

Applying the plugin

You apply the Develocity sbt plugin to your build by adding the following configuration block to a new or existing project/plugins.sbt file in your sbt project. The sbt plugin will be downloaded automatically from Maven Central once you load your build.

addSbtPlugin("com.gradle" % "sbt-develocity" % "1.0.1")

All Develocity settings are grouped under one configuration object that needs to be set in the ThisBuild scope. Unless you intend to publish build scans to, the minimum configuration required is that of the Develocity server URL.

ThisBuild / develocityConfiguration :=
      server = Server(
          url = Some(url(""))))

You may encounter a warning about an untrusted certificate when connecting to Develocity over HTTPS. The ideal solution is for someone to add a valid SSL certificate to the Develocity instance, but we recognise that you may not be able to do that. In this case, set the allowUntrusted option to true:

ThisBuild / develocityConfiguration :=
      server = Server(
          url = Some(url("")),
          allowUntrusted = true))

This is a convenient workaround, but you shouldn’t use it in a production environment.

Given the above configuration, you can now run your build as usual. As the build completes, the last lines of the output will be similar to:

Publishing build scan...

Follow that link to view your build scan.

More detailed information about the Develocity sbt plugin can be found in the Develocity sbt Plugin User Manual.

Build scan highlights

Find and view any build scan

Search through all the captured build scans by going to

scan list

This view allows searching by various criteria, including top-level project name, user name, build outcome, build start time and more. By default, the list is sorted to show the most recent scans first.

Beyond looking for a particular build scan, the listing can provide new insights into the actual builds being run at your organization and by your colleagues. You may find occurrences of previously unknown errors with your build, or that the build is taking longer in certain cases than you expected, or that certain build users are executing more commands than they need to and are therefore subjecting themselves to more build time than they need to, and other previously unknown behaviors.

Share console logs

Build scans include the console output produced by the build. Many tools used by the build, such as compilers, often write diagnostic information to the console log.

Use the left navigation menu to visit the Console log section.


Click on any line to highlight it or shift-click two different lines to highlight a block of lines. Note that the browser’s current location has been updated. By sharing that URL with a colleague, you can direct them to the exact console output that you wish them to see.

Many aspects of build scans are directly linkable to facilitate sharing and collaboration.

Inspect test results

If your build executed tests, then their results will be included in your build scan. Use the left navigation menu to visit the Tests section.


This section shows the results of all the tests that ran during your build, along with their outcome and durations. The results are broken down by task, test suite and test case. Select any test suite or test case to see details about each of their individual executions, in case of test retry. Different durations are available for tasks, test suites and test cases. Generally, the total time corresponds to the wall clock time that an execution lasted. The own time is the time that was spent preparing for the actual work (eg. preparing your framework). Finally, the serial time is the time the operation would have taken if all its sub-steps occurred sequentially. Under some circumstances, some durations may be missing. Please refer to Viewing test results for more details.

The results are broken down by task, test suite and test case. Select any test suite or test case to see details about each of their individual executions, in case of test retry.

Analyze build performance

A key benefit of build scans are the various insights they provide into build performance. Many builds provide different functions for different people and will perform differently on different machines. Having deep performance insights available for every build enables optimizing all corners of the build, for all users.

Use the left navigation menu to visit the Timeline section.


This section provides insights into the task executions, visualizing them as a timeline. This representation clearly shows the parallel utilization of your build.

The table below the graph provides a concise breakdown of the tasks executed during the build. The table provides more detail on individual tasks (click the details inspector icon when hovering over a task) and can be used to understand dependencies between tasks.

Next steps

Always publishing a build scan

The Develocity sbt plugin can be configured to:

  • Publish a build scan for every build invocation

  • Always publish if programmatically-defined criteria are met

  • Always publish if the build fails

The dedicated Develocity sbt plugin user manual provides a section outlining how to do this.

It is strongly recommended to configure your builds to always publish build scans, for every build. Collecting build scans for every build yields deeper visibility and insights into how your build is performing and being used.

Build scans can be enriched with metadata particular to your environment by several means.

Extending your build scans with tags, values and links is strongly recommended. In particular:

  • VCS information such as commit identifiers, branch names, etc.

  • Tags for different types of builds (e.g. CI vs. local)

  • Links to CI system record of build for CI builds

This adds useful context to your build scans.

Integrating your CI tool

Build scans are passive with regard to the build process. That is, enabling build scans does not affect the outcome or outputs of your build. As such, it is generally safe to simply add the necessary configuration to your projects to enable sending build scans to your Develocity installation and check it in to version control, enabling it for all users of the build.

The build scan plugin will not cause build failures, even when there is no connection available to the Develocity server when trying to publish.

Getting help or asking questions

If you are currently using Develocity as part of your trial sign-up or license purchase, you will have received instructions on how to access the priority Develocity support channel. If you have any issues with or questions about Develocity, please raise a support request.

Alternatively, or if you are not yet using Develocity, you can use the Gradle discussion forum if you are able to discuss your issue publicly. If you are unable to discuss your issue publicly, please use our contact form.

Keeping up to date

Develocity is constantly evolving with regular updates that add new features and capabilities. The monthly Gradle newsletter is an easy way to stay informed about new releases, features and events.