2.2.2 Reading Build Output

Non-zero exit codes from 1.1.9 Exit Codes mean Bazel reported a problem. The build log tells you where it failed. Bazel still has the three responsibilities from 2.2.1 Loading, Analysis & Execution, and the INFO: Analyzed target ... line (or INFO: Analyzed N targets ...) is a useful clue: Bazel completed analysis for the named targets. It is not proof that no execution began earlier, because 2.2.4 Skymeld can run ready actions while analysis of the remaining request continues.^1,2

Read the headline lines first

INFO: Analyzed target //foo:foo (14 packages loaded, 48 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
  bazel-bin/foo/foo
INFO: Elapsed time: 9.905s, Critical Path: 3.25s
INFO: Build completed successfully, 6 total actions

The first headline is the analysis-completion summary for the named targets. packages loaded is loading work: how many packages Bazel had to read to understand the request's reachable closure. targets configured is analysis work: how many configured targets Bazel had to validate and turn into an action plan.^1,2 If a small-looking target reports a surprisingly high package count, that usually means the requested slice is wider than you expected, not that execution suddenly became slow. That is the same reachability story from 2.1.2 Laziness & Slicing, now exposed in the log.¹

Use the analyzed summary as evidence

Loading and analysis are distinct responsibilities, but their work can interleave while Bazel builds the target graph.² For everyday debugging, first ask whether Bazel reported an INFO: Analyzed ... summary (Analyzed target ... or Analyzed N targets ...). That line confirms analysis completed for the named targets and that Bazel produced their action plan. It does not assign every later log line to execution.

If no analyzed summary appears, inspect the error itself for a loading or analysis responsibility: BUILD / .bzl evaluation, package resolution, dependency declarations, or rule validation.¹ This is where the message families from 1.1.10 Common Error Messages live. Such failures often stop the request before Bazel prints the summary, sometimes with only partial counters.

If the summary appears, Bazel has a valid action plan for the named targets, the boundary that 2.2.3 Static Action Graph sharpens. Classify any failure by its message and responsibility: compiler and linker errors, test failures, and tools producing wrong outputs belong to execution, while a declaration or configuration error for other work still belongs to loading or analysis. When the summary is too terse, the next debugging tools live in 2.3.4 First-Response Debugging Flags.¹

Read the counters together, not in isolation

Build completed successfully, K total actions is the execution-side summary, but it is not a pure "how many compilers ran" counter. In a null build, Bazel reports 0 packages loaded, 0 targets configured, and still ends with 1 total action.¹ The important signal is the combination of numbers: near-zero loading and analysis counts plus an immediate success message means Bazel reused prior work, which is the operator-visible effect behind 1.1.3 Server/Client Architecture and later 2.4.1 Skyframe & Incrementality.

During execution, Bazel can also print progress messages showing the current step and completed-versus-total actions.¹ Read those as "how much of the planned work remains," not as a separate fourth phase. Modern Bazel may start ready actions while analysis of the whole request is still finishing, as 2.2.4 Skymeld explains, so the log is not always three non-overlapping time blocks. The responsibilities stay distinct: loading discovers packages, analysis configures targets and registers actions, and execution runs ready actions.