Written for Platform teams who own build health, and whoever gets asked why CI costs grew.
The question nobody can answer today
Ask a platform team whether the build got slower this quarter and you usually get an honest shrug.
Not because they don’t care, but because the data that would answer it was discarded a week after it was produced. Everything downstream of that is guesswork: which target regressed, whether the cache is working as well as it did, which tests are genuinely unreliable versus which ones somebody remembers being annoyed by, and what any of it costs.
We rebuilt how Aspect ingests and stores Bazel build events from the ground up, so keeping all of them stops being the thing you economise on.
- Direction of travel. A build that degrades 4% a week looks fine in every single observation and is 2.3× slower in six months. Without history there is no gradient.
- Attribution. “The build is slow” is not actionable. “This library sits on the critical path of 60% of builds” is.
- Evidence about flakes. Without retained per-attempt records, a flake is a claim with no number attached, so it never outranks feature work.
- Cost attribution. Finance sees one cloud line item, and nobody can decompose it into the work that produced it.
Measured on Aspect’s own production instance.
What changes when you keep it
Built on the protocol you already emit
Standard Build Event Protocol over gRPC, the same stream Bazel already produces. Any Bazel client works, local or CI. Nothing to instrument, no fork, no plugin, no changes to how your builds run.
Event ingest runs on its own capacity, separate from remote caching and execution, so heavy event traffic and heavy build traffic don’t contend with each other. Observability that slows down the thing it observes doesn’t survive contact with a platform team.
- Not application monitoring. It stores Bazel build events, not service telemetry, and doesn’t compete with your metrics stack.
- Not a warehouse you query yourself. The answers are already assembled.
Where it runs
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.