5.4.5 Bazel Invocation Analyzer (BIA)

Bazel Invocation Analyzer (BIA) turns one Bazel JSON trace profile into a ranked set of performance hypotheses. Use it when you have a representative slow invocation but do not yet know which parts of the trace deserve manual investigation. It accelerates triage. It does not prove that a proposed change will improve your workload.

Choose the access mode before capturing data

BIA is an Apache-2.0 open-source project developed by EngFlow. The upstream project exposes the analyzer as a Java library and a terminal program, while EngFlow also operates a public web UI.¹ These paths provide the same kind of profile analysis, but they have different operational boundaries:

Mode	Best fit	Data boundary
Public web UI	Fast, installation-free exploration of a profile that policy permits you to send to a third party	The browser uploads the profile to analyzer.engflow.com
CLI from source	Sensitive profiles, repeatable local analysis, or automation	The CLI reads a profile path from the local filesystem
Embedded library	A team is building its own analysis or reporting integration	The application controls input, execution, and presentation

The upstream repository currently publishes source rather than versioned GitHub releases. The snapshot verified at commit 118a359c56f909df0087b07849c52c21fda21d95 on 2026-07-18 pinned Bazel 8.3.1 and documented Bazel 6.3 or newer as the build dependency.² Treat that as a source snapshot, not a durable BIA release number: use the repository's .bazelversion when building the CLI and record the commit you ran.

A trace profile is not automatically safe to share. Its metadata can include the invocation ID, date, and output-base path, while event descriptions can identify actions and outputs.³ Additional profiling flags can expose target labels. The analyzer landing page says uploaded profiles are held only in memory for the duration of automated analysis and are not stored.⁴ That is a specific statement about the hosted analyzer's handling of profile uploads, not a general confidentiality promise.

Read it together with the upload terms. Those terms grant EngFlow rights to use, analyze, copy, modify, and create derivative works from submitted content, with sublicensing rights, as needed to operate and provide the service, including producing insights and improving the service and related technologies.⁵ They also require the uploader to have the rights needed to provide the content. Therefore, the landing-page retention statement does not replace your organization's data-handling rules. You must also have the rights needed to provide the content, and its submission and use must not infringe the rights identified by the terms. Check the file and the applicable policy before uploading. When that boundary is unclear, run the open-source CLI locally instead.

Capture the workload you actually want to improve

Start from a named scenario: a clean CI build, a warm no-op build, or a specific developer edit. Keep the targets, configuration, machine class, execution strategy, and cache state representative. Capture it explicitly so another command does not replace the evidence:

bazel build //app:release --profile=release-profile.json.gz

Bazel writes a gzip-compressed JSON trace when the path ends in .gz. It also records profiles for build-like commands by default, but an explicit path is easier to archive with the revision, Bazel version, invocation flags, and scenario notes.³

Do not reflexively run bazel clean or disable caches just because a tool's example does so. Those choices answer a particular question about an uncached build and usually make the invocation slower. They do not represent a warm or incremental complaint. Capture the user-visible problem first. Create a second, deliberately uncached profile only when comparing cache behavior is part of the hypothesis.

For local analysis, clone the upstream project and pass the profile path after the Bazel target:

bazel run //cli -- /absolute/path/release-profile.json.gz

For the hosted path, upload that same profile at analyzer.engflow.com. The web UI can reject profiles beyond its upload limit. Large or sensitive profiles are another reason to prefer the CLI.⁶

Read suggestions as a triage queue

BIA extracts facts from the trace, then runs suggestion providers over those facts. At verified commit 118a359c56f909df0087b07849c52c21fda21d95, the open-source providers cover signals such as phase duration, critical-path duration, action concurrency, garbage collection, remote-cache and execution observations, local actions during remote execution, cache misses or skips, Skymeld-related profile signals, merged events, and Build without the Bytes.^1,7,2 The exact list evolves with the source, so rely on the output of the commit you ran rather than a frozen feature checklist.

Each result should be read in four parts:

1. Recommendation: the experiment or investigation BIA proposes.
2. Rationale: the observed profile facts that triggered it.
3. Potential improvement: an estimate or upper bound, when the provider can calculate one.
4. Caveats: missing data, ambiguity, or assumptions that limit the result.

Prioritization is useful, but “largest potential improvement” does not mean “guaranteed largest speedup.” For example, converting a long cache miss into a hit matters only if the action should be reusable in the scenario and the miss can actually be prevented. Likewise, a bottleneck recommendation can identify low action concurrency without proving whether the cause is an artifact dependency, resource contention, remote queueing, or coarse action design.

Use the suggestion to choose the next evidence source:

BIA signal	Manual follow-up
Long or bottleneck action	Locate it in the trace, then use 5.2.3 bazel aquery — Action Graph to inspect its command, inputs, outputs, and producer relationship
Critical-path opportunity	Read the timed chain and near-critical work using 5.4.2 Critical Path
Expensive cache miss or cache skip	Confirm expected reuse and investigate cache-key or execution evidence rather than assuming the action is misconfigured
Local action during remote execution	Check whether the action is eligible and hermetic before attempting to move it remotely
Major garbage collection	Correlate pauses with heap pressure and continue with 5.6.5 Memory Diagnostics before changing JVM settings
Merged or incomplete events	Recapture with the suggested profile settings before trusting fine-grained estimates

This separation matters because the analyzer sees what the trace contains. It does not know the intended dependency design, the correctness constraints of a rule, the economics of a remote service, or which build mode users care about. It can detect a pattern and explain why it is suspicious. An engineer must still establish the cause.

Close the loop with a controlled experiment

Turn one suggestion into one falsifiable change. Record the baseline, change one relevant factor, and repeat the same scenario several times. Compare end-to-end latency as well as the metric behind the suggestion. A change that reduces critical-path time but increases analysis enough to leave wall time unchanged is not a win for that scenario.

Keep these manual validation boundaries explicit:

• A recommendation is a hypothesis, not permission to remove declared inputs, weaken hermeticity, or bypass correctness checks.
• A potential improvement is normally conditional or best-case. Competing and near-critical work can cap the realized gain.
• A single trace captures one cache state and one scheduling outcome. Confirm conclusions against comparable runs and the workload distribution that matters.
• Absence of a suggestion is not evidence that the invocation is optimal. A provider may not recognize the pattern, the needed events may be absent, or the bottleneck may require an execution log, BEP data, or rule-level evidence.

When timing order is not enough to establish why actions were serialized, continue with 5.4.6 Execution Log Graph. That structural evidence complements BIA's profile-based triage rather than competing with it.