Invocations in the dashboard
The Bazel invocations page lists recent invocations for your workspace. Select one to see its details.Invocations from the CLI
The observability CLI commands require nsc v0.0.546 or later. Run
nsc version ensure --at_least 0.0.546 to check and update the CLI if needed.List recent invocations
List the most recent invocations with:Narrow the results
Use--since to narrow the list to a time window, and --max_entries to control how many rows come back:
List invocations for scripts and agents
When scripting or driving the command from an agent, pass--output json to get machine-readable output:
Pull a report
Stream a report for a single invocation with:What a report contains
A report is newline-delimited JSON, one record per line:metadata,
configurations, metrics, build_tool_logs, and targets, plus fetches and
actions when the invocation fetched or executed anything. On larger builds
actions is split across several records rather than one.
Much of that is what Bazel already knows: action counts, timing per phase, the
critical path, targets and their outputs. The part Bazel does not have is in
actions, where every remotely executed action records whether it hit the cache,
which worker ran it, how long it queued, and how its time split between
hydration, execution, and output upload.
Reports scale with the invocation. A one-action
bazel run might produce a few kilobytes, while a 1500-action build can produce over 400 KB. Slice out what you need before handing a large one to something with a limited context window:Debugging failed builds
When a failure is in your code or your build definition, Bazel’s own output is usually enough. A compile error or a failing test assertion points at itself. Reports are for the failures Bazel cannot explain. Resource limits, configuration constraints, and images that fail to start all reach Bazel as an opaque failure. So does a test that depends on the environment, such as one that starts a database in a container, where the reason may only appear in that container’s output. Reports carry the surrounding detail, including which worker ran each action, so a failure can be traced back to the machine it ran on. That detail is spread across a lot of records, which makes it a good candidate for handing to an agent rather than reading yourself.Analyzing a report with an agent
Reports are built for machine consumption. They carry most of what was observed during an invocation, which is more than is practical to read line by line, so handing one to an agent is often faster than reading it yourself.Analyze a slow build
Save a report and point an agent at it:Agent Prompt
Analyze a failed build
The same approach works for a failure rather than a slow build:Agent Prompt