Bazel observability

Bazel observability that explains why a build changed.

Hermetiq turns the structured evidence Bazel and its execution infrastructure produce into a connected investigation: what changed, which target or action was affected, where time went, and which signal supports the conclusion.

What you can answer

Connect build outcomes to the Bazel evidence behind them.

  • Invocation, target, and test history
  • Failure recurrence and critical-path analysis
  • Action-level cache and remote-execution evidence
  • Comparisons across equivalent workloads
Questions Hermetiq helps answer

Start with the engineering question, then inspect the evidence.

Observability is useful when each answer can be traced back to a build event, profile, action, or infrastructure signal—not inferred from a CI status alone.

Invocation changes

Which targets, tests, actions, flags, or execution conditions differ between comparable invocations?

Critical path

Which build phase or dependency chain determined elapsed time, and did that path change?

Failure recurrence

Is this failure isolated, repeated across branches, or concentrated in one target, test, or action?

Execution boundary

Did the delay come from Bazel analysis, cache behavior, queueing, data transfer, a worker, or local execution?

Integration model

Build an evidence chain from Bazel first, then add execution context.

Available answers depend on the signals connected for a project. Begin with Bazel’s structured events, then add profiles, cache records, completed actions, or infrastructure telemetry when the investigation requires them.

01

Connect Bazel BEP

Use Build Event Protocol events to establish invocation identity, target and test outcomes, timing, and the build metadata actually reported.

02

Add the evidence you need

Connect JSON profiles, remote-cache events, completed remote actions, or OpenTelemetry signals when those layers are part of the question.

03

Compare equivalent builds

Hold workload, configuration, and environment as constant as possible before treating a change as a regression or improvement.

Product evidence

Inspect trends, then drill into the path that produced them.

Failure and test trends

Find repeated failures and changing outcomes across recorded invocations before opening the individual build evidence.

Critical-path analysis

Inspect the chain of work that determined elapsed time when the required profile data is available.

Evidence model

Know what each conclusion is based on—and where it stops.

BEP-derived outcomes

Invocation, target, test, timing, and status evidence comes from the Build Event Protocol events Hermetiq receives.

Profile-derived timing

Phase, parallelism, and critical-path analysis requires a compatible Bazel JSON trace profile.

Execution-derived behavior

Queue, transfer, worker, and action detail requires the corresponding remote-execution records or telemetry.

Infrastructure context

Scheduler, storage, network, and cost context depends on the metrics, logs, traces, and metadata configured for the deployment.

Technical references

Verify the underlying telemetry and performance model.

Technical review: August 29, 2026 · Verify configuration details against the Bazel and Buildbarn versions deployed in your environment.