Exploring Builds

The Builds section is the event explorer. You can drill down from your whole team to a single test case, and at every level it helps you answer two questions: what is failing, and what is slow.

How your data is organised

Collected events are grouped into a hierarchy:

• An organisation maps to your version control organisation or group.
• A project maps to a repository.
• A module is a unit of work inside that repository, such as a Gradle subproject, a service or a package. Builds are recorded against a module.
• A build is one run of your pipeline.
• Events are the individual things that happened during that run: pipelines, jobs, steps, test suites, test classes, test cases, commands, files and properties.

You don't need to create this structure yourself. It appears as the CLI and your version control integration submit events, and the names come from the source. For example, your repository name becomes the project, and your workflow's run number becomes the build.

Team overview

The Builds page lists the organisations that reported events in the selected time range. If no events have arrived yet, the page prompts you to configure an integration instead. Follow Getting Started to connect one.

Open an organisation to see its projects. A project page shows a graph of its recent runs, with two tabs underneath.

Modules lists the modules that built in the selected range. Each one shows the commit that triggered its latest run, who pushed it and a row of status squares for recent runs. Commits lists the commits themselves, so you can start from a change instead of a pipeline.

When you open a commit, you see its message, its author and the files it added, removed and modified, followed by the pipeline timelines of every build it triggered. This is the fastest way to answer "did my change break the build?"

Module page

A module page starts with a stability graph. It shows successes and failures run by run across the selected range. You can switch it between dimensions such as pipelines, jobs, steps and tests, and between counts and rates. Below the graph is the table of builds, newest first.

Each row shows the build identifier, its status, the commit subject with its short SHA, the branch and author, a row of squares summarising the pipelines in the build, and when it ran. A spinning marker means the build is still running. The squares are the quickest way to read the page: if a row is all green except for one red square, you already know which stage to open.

Use the branch filter next to the time range to narrow everything to one branch. Comparing main with a feature branch here is usually enough to tell whether a regression comes from your branch or affects everyone. To bookmark a module you own, click the star in the header, and it appears in the left navigation on every page.

Build overview

A build has three tabs. Overview shows the commit that triggered the run, then the stability graph for context, then the pipeline breakdown.

The breakdown is a waterfall of pipelines, jobs and steps drawn against the build's total duration. Each bar starts where its stage started and is as long as the stage took. Bars are coloured by nesting depth and marked with a status icon. Expand a row to see what ran inside it.

Read the waterfall from left to right to find the critical path. Bars that start at the same time ran in parallel, and a gap before a bar means that stage was waiting, not working. Hover over any bar to see the full event detail, and click through to open that stage's event page.

Below the waterfall, the events table lists everything the build recorded. Each event shows its duration and what share of the build that duration represents. You can filter by name, by status (running, successful, failed, skipped, cancelled, unknown) and by category: file, test suite, test class, test case, pipeline, job, step, command or property. The filters are stored in the URL, so you can send a filtered view to a colleague as a link.

Tests

The Tests tab shows the test results collected for the build. It starts with a breakdown by status across test cases, classes and suites, then lists the results.

The donut charts show at a glance how bad things are. The list below shows exactly what failed. Each suite shows its duration and its success, failure and skip rates, and you can expand it to see the classes and cases inside. Every row links to the event page for that result.

Files

The Files tab lets you browse everything collected during the run. The file tree is on the left and a preview of the selected file is on the right.

The tree follows the paths the files were collected from, so a report keeps the same folder structure it had on the build agent. The selected file is stored in the URL, so a link to a specific report opens that report, not just the tab.

Event sheet

You can read an event without leaving the build. Click a row in the events table on the Overview tab, or a suite, class or case on the Tests tab, and a panel slides in from the right with the full details of that event.

The sheet doesn't dim or block the page behind it, so you can still read the table while it is open. Only one event is selected at a time, so clicking another row switches the sheet to that event. To close the sheet, press Escape or click anywhere outside both the table and the sheet. Some rows, such as stages that came from your CI provider, have an external link icon at the end. That icon opens the run in your CI provider instead of opening the sheet.

From top to bottom, the sheet contains:

• A statistics chart of this event across earlier builds, shown only when there is history to plot.
• A status panel with the name, status, duration and timestamp. If the failure has been analysed, the panel shows the AI summary with its reason and language badges. The raw message and stack trace are behind the Details toggle in this panel.
• Every file attached to the event, each previewed in place.
• The event's raw attributes as an expandable JSON tree, for anything the panels above don't show.

Working in the sheet keeps your filters and your place in the table. You can open a failure, read the summary and its console output, close the sheet and open the next one without losing the list you are working through. When you want the full event page, use the Details button at the top of the sheet, above the panels.

Event page

The event page is the last level of the drill-down: one test case, one step or one file.

If the AI summariser has analysed a failure, the status panel opens on a Summary. It gives a short explanation of what went wrong, tagged with the failure reason and the language it was detected in. The raw message and stack trace are one click away under Details, and the full event is available as JSON below for anything the panels don't show. See AI Insights to learn how to turn summaries on.

A statistics chart plots the same event across earlier builds. This is how you spot a slow or intermittent test: a flat line that jumps up on a particular date points to the change that caused it. The commit that produced the event is shown next to the chart, and any attachments are listed below.

Attachments and file views

You can view files collected during a build directly in the app, without downloading them first. The same viewer appears everywhere a file is shown: in the event sheet, on an event page and in the Files tab.

Each file has a header showing its name, the path it was collected from, its size, its content type and when it was collected. The ⋮ menu next to the header downloads the original file, whatever its type.

How a file is displayed depends on its content type, which the CLI sets from the file extension when it collects the file:

Files	Rendered as
.png, .jpg, .gif, .svg, and other images	The image itself
.mp4, .webm, and other video	An inline player with controls
.mp3, .wav, and other audio	An inline player with controls
.txt, .log, .conf, .list	Monospaced text, as-is
.md, .markdown	Rendered Markdown
.mmd, .mermaid	The drawn Mermaid diagram
.json	An expandable JSON tree
.oas.json, .oas.yaml, .openapi.json, .openapi.yaml, and their .yml equivalents	Browsable API documentation

For any other type, the viewer says that a preview is not available. The file is still collected and you can still download it from the ⋮ menu, so archives and binary artefacts are never lost. They just aren't displayed.

Keep two things in mind when you name your files. First, links inside rendered Markdown resolve relative to the path the file was collected from, including ./ and ../ segments. A report that links to a sibling page or embeds a sibling image works in the browser just as it did on the build agent. Second, API specifications are recognised only by their filename. api.openapi.yaml and api.oas.json are shown as API documentation, but a plain api.yaml is not, and api.json is shown as a JSON tree.

Test results automatically include their standard output and error streams as system-out.txt and system-err.txt attachments, so the console output for a failing suite is always one click away from the failure.