Every Bazel invocation emits a structured stream describing each target it considered, each action it executed, every cache decision it made and every attempt of every test it ran. Almost nobody keeps it, and not out of negligence. Retaining it at monorepo volume has been expensive enough that most teams sample it, keep a few days, or skip it entirely.

A single large build in our own monorepo covers 120,539 actions across roughly 2.07 million graph nodes. Our instance carries 37.6 million build actions per month across 10,151 tracked targets, all from one monorepo. Most organisations running Bazel at scale produce considerably more than that, and keep considerably less of it.

• You are already producing the signal. The only question is whether you keep it long enough for a trend to be visible.
• Hand-wired reporting is a false economy. Every monorepo eventually builds its own build-metrics pipeline. It is undifferentiated work, it decays as soon as its author changes teams, and it answers fewer questions each year.
• A different class of question opens up. Not “how was this build?” but “how has this target behaved across every build for the last month, and what did it cost?”

• Standard protocol, nothing to instrument. Events stream over gRPC; any Bazel client works, local or CI. No fork, no plugin, no wrapper script.
• Local builds count. Most teams watch only CI, so they see about half their build activity. The half they miss is the half their engineers actually experience.
• Ingest is isolated from the build path. Heavy event traffic and heavy build traffic don’t contend. Observability that slows down the thing it observes doesn’t survive contact with a platform team.
• Retention measured in months, not days. Long enough that a trend is a trend.

What that buys you: event volume stops being the thing that limits what you can ask. No sampling decisions, no retention window to negotiate down, no “we would have to add that field first.” The question you want to ask next week is already answerable, because the data is already there.

You don’t need to commit to a platform to find out whether this is worth anything to you.

• Ask your own team the four questions. Is the build slower than last quarter? Which target is most responsible? Which test is flakiest, and by how much? What did last month’s builds cost? If the answers are estimates, the gap in this paper is your gap.
• Check what you actually retain. Not what the pipeline was designed to retain, but what is queryable right now, and over what window. Teams are routinely surprised.
• Point one repository at a hosted instance. Trends need history, so the first day tells you far less than the first week.