A 6,904-target test build in 4m 8s at a 95% local action cache hit rate, critical path 26s. Aspect’s own instance.
A month of retained build events: 37.6M actions, 10,151 targets ranked and trended.
Written for Platform and developer-experience leads already running Bazel at scale.
The argument
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.
The shape is predictable: a BEP consumer, an object store, a job that flattens events into summary tables, a dashboard, and a wiki page explaining which numbers to trust.
It works, for a while. Then it rots, for structural reasons rather than because anyone built it badly.
The alternative isn’t a better in-house pipeline. It’s treating build-event retention as a platform capability you buy, rather than a project you staff and then quietly stop maintaining.
One design goal: make keeping everything the default, rather than the thing you trade away first.
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.
A 6,904-target test build in 4m 8s at a 95% local action cache hit rate, critical path 26s. Aspect’s own instance.
A month of retained build events: 37.6M actions, 10,151 targets ranked and trended.
You don’t need to commit to a platform to find out whether this is worth anything to you.
Every figure here comes from Aspect’s own production instance, running our own monorepo. A number without its workload attached isn’t evidence.
Three ways to run this, and the axis that separates them is isolation, not hosting.
| Option | Infrastructure | Cloud account | Operated by |
|---|---|---|---|
| Aspect Cloud | Shared, scoped to your organization | Aspect’s | Aspect |
| Aspect Enterprise, hosted by Aspect | Isolated, yours alone | Aspect’s | Aspect |
| Aspect Enterprise, self-hosted | Isolated, in your account | Yours | Aspect, or your team |
The last two are the same product, Aspect Enterprise. What differs is whose account it runs in and who holds operational control. Holding that control yourself is usually the point. Plenty of teams in finance, healthcare and government are not allowed to give a third party production access. For them we work over the shoulder: we guide and diagnose, their hands stay on the controls. It is what makes air-gapped and GovCloud deployments possible at all.