Find the build
Select the project, time range, status, command, branch, or metadata that identifies the affected work.
Using Hermetiq
Use Hermetiq to investigate builds
Find and group builds, inspect invocation evidence, compare runs, and interpret cache, profile, test, RBE, trend, and cost views.
A practical investigation workflow
Start in Build History, narrow the list to the change or CI run you care about, open an invocation, and then move to comparison or trend views when the question spans more than one invocation.
Inspect one invocation
Open its failures, cache metrics, logs, actions, targets, outputs, tests, command line, and available profile evidence.
Compare or trend
Compare two relevant invocations for a controlled before-and-after view, or use Trends to inspect a population over time.
Builds and invocations
An invocation is one Bazel command. A logical build can contain one invocation or several related commands, such as a build followed by tests in the same CI job.
To make related commands appear as one build-level record, pass the same --build_request_id to each invocation. Use a value that is stable for that CI run and unique across unrelated runs.
CI grouping example
# Reuse one logical build ID across related Bazel commands
bazel build //... --build_request_id="<CI_BUILD_ID>"
bazel test //... --build_request_id="<CI_BUILD_ID>"In Build History, switch to the build-grouped view when you want one row per build request. Open a child invocation when you need command-specific details.
Review build grouping configuration →Find the right build
Use the project selector and time range first, then reduce the result set with filters that are present in your data. Common dimensions include status, Bazel command, branch, repository, commit, role, build ID, invocation ID, and custom build metadata.
- Basic filters cover common investigation fields.
- Advanced filters support more specific field and value combinations when the basic controls are not enough.
- Group by Build ID combines invocations that share a build request ID.
- Auto-refresh is useful while a build is running; disable it when you need a stable comparison set.
The history chart can also narrow the visible time window. Keep the selected project and filters in mind when a build you expect does not appear.
Read an invocation
The tabs shown for an invocation depend on its status, captured events, and enabled integrations.
Overview
Command, timing, status, identity, metadata, and the high-level signals available for the invocation.
Failures
Failed targets, actions, tests, and error context captured from the build.
Cache Metrics
Available local, remote, and execution outcomes. Action-level miss reasoning requires the relevant cache-event integration.
Build Logs
Progress output retained by the deployment. Log availability and retention depend on project storage configuration.
Actions
Action identity and timing; remote queue, fetch, execution, upload, and worker detail requires completed-action data.
Command Line
The Bazel command and options recorded for the invocation, useful for spotting configuration drift.
Targets and outputs
Target outcomes and published output files that were captured and remain accessible.
Test Results
Test status and available attempt or failure details emitted through BEP.
Compare two invocations
Use Compare Builds for a before-and-after question: a fast run versus a slow run, a successful invocation versus a failure, or two branches with different cache behavior. Select two comparable invocations and keep command, target scope, Bazel version, platform, and workload differences in view.
Use Analytics & Trends
Trend views answer questions about a population of builds rather than one invocation. Depending on project configuration, the product can expose Overview, Profile & Critical Path, Failures, Test Analytics, Targets, Remote Cache Analytics, Remote Execution Analytics, and Project Activity.
- Keep project, time range, branch, command, and other filters consistent when comparing periods.
- Use profile views for client-side phases, critical path, and parallelism; use remote-execution views for queues, workers, and remote action timing.
- Treat an empty tab as a prompt to verify the underlying integration and time range, not as proof that the behavior did not occur.
Read cache metrics precisely
Observed action outcomes
The share of non-internal actions whose recorded outcome was a remote hit. Its denominator is the eligible action population represented in the invocation or filtered trend set.
Action Cache lookups
The share of observed Action Cache lookup events that hit. This requires cache-event capture and can have a different denominator from BEP-derived action outcomes.
Do not compare these percentages as if they were the same measurement. Check the metric label, denominator, filters, and data-source availability before drawing a conclusion.
Last reviewedSeptember 1, 2026