Orbit
Orbit Build Insights and Delivery Insights
Orbit has two insight views: a per-project Build Insights tab that answers "why are our builds slow", and an account-wide Insights page that answers "how well are we shipping". This guide covers both and when to use which.
Where the Two Views Live
Build Insights is per project. Open Orbit, click the project, and choose Build Insights under the Observability group in the project tab strip.
Insights is account-wide. Open Orbit and choose Insights from the top-level navigation, next to Mission control and Usage.
Build Insights: The Summary Cards
The tab describes itself as build duration percentiles, cache hit rate, success rate and trend over your selected window, and the window is adjustable at the top of the page.
| Card | What it tells you |
|---|---|
| Total builds | How many builds ran, split into succeeded and failed |
| Success rate | Rated Healthy, OK or Needs attention |
| Build duration p50 | The median build, with p95 and p99 underneath |
| Cache hit rate | Hits against misses |
| Cache savings | Compute time the cache saved you |
The pairing of p50 with p95 and p99 is the point. A p50 of 90 seconds with a p99 of 95 seconds is a well-behaved build. A p50 of 90 seconds with a p99 of eleven minutes means something occasionally goes very wrong, and averaging would have hidden it completely.
If the window has no builds in it, the page says so and suggests picking a larger window if your deploys are older.
Build Volume and Duration Trend
The trend chart plots daily build counts across the window with an average duration overlay. Hovering a day gives the count, the succeeded and failed split, and the average.
Read the two series together. Volume up with duration flat is a healthy team shipping more. Volume flat with duration climbing is a build that is quietly rotting, usually through dependency growth or a cache that stopped working.
Frameworks and Package Managers
Two breakdowns sit below the trend:
- By framework, grouping successful builds by the framework Orbit detected.
- Package managers, across all builds.
On a single-app project these are one row each and not very interesting. On a monorepo or an account with several projects they are how you spot the outlier: one app on a different package manager, or a framework that is dragging the average.
Framework detection is what drives Orbit's default build settings too: see Frameworks Orbit Supports.
Slowest Builds
The Slowest 10 successful builds table lists your worst performers with their branch, duration and queue time, described on the page as anchor candidates for optimisation.
Note the Queued column specifically. A build that took eight minutes of which six were spent queued is not a slow build, it is a busy build host, and no amount of optimising your npm ci will help. A build that took eight minutes with no queue time is genuinely slow and worth attacking.
Attack the slowest build's install phase before its build phase. Install is where a warm cache pays off, and it is usually the easiest win. Configuring Your Build Command and Output Directory covers the settings involved.
Cache Savings
The tab quantifies what the build cache has saved you in compute time over the window. That number is the argument for keeping the cache healthy.
If the cache hit rate is low, the usual causes are:
- A lockfile that changes on every commit, invalidating the cache each time.
- Builds that were cleared deliberately and have not warmed up again.
- Long gaps between deploys.
Clearing the cache resets this, which is worth remembering before you clear it out of habit while debugging.
Delivery Insights: DORA Metrics
The account-wide Insights page covers the last 30 days across every project, and frames the numbers as DORA metrics with a performance band of Elite, High, Medium or Low, plus a comparison against the previous 30 days.
| Metric | Definition on the page |
|---|---|
| Deploy frequency | How often you deploy, all environments, all projects |
| Lead time (P50) | Commit queued to deployed, with P95 alongside |
| Change failure rate | Production deploys that failed |
| MTTR (median) | Failure to the next production success |
These four are deliberately in tension. You can make change failure rate look perfect by deploying once a month, and you can make deploy frequency look excellent by shipping constantly and breaking things. The set is only meaningful read together, and the trend against the previous 30 days matters more than the absolute band.
Project Breakdown
Underneath the metrics is a table of every project over the same 30 days: deploys, successes, failures and average build time.
This is the quickest way to find the project that is dragging the account: the one with a low success rate, or the one whose average build is several times everyone else's. Open its Build Insights tab next for the detail.
If there is no data at all, the page says so and prompts you to push to a branch to get started.
Which View To Open
- A build is slow. Build Insights, on the project. Look at p50 against p95, then queue wait, then the slowest builds table.
- Builds keep failing. Build Insights for the rate, then the Analytics tab's failure-cause classification for the reason: see Orbit Project Analytics.
- Someone asks how the team is delivering. Insights, account-wide. The four DORA metrics with their trend arrows answer that question directly.
- You are choosing what to work on next. Insights first to find the project, Build Insights second to find the cause.
Troubleshooting
The page is empty but I know we deploy. Widen the window. Build Insights defaults to a shorter window than you may expect, and the account-wide page is fixed at 30 days.
Cache hit rate is zero. Either the cache was recently cleared, or your plan does not include build caching. See Orbit Plan Limits.
Lead time looks enormous. Lead time is measured from commit to live, so a long-lived branch that was merged weeks after its first commit inflates it. That is real information, not a bug: it is telling you that work is sitting unmerged.
MTTR is blank. There have been no production failures in the window, so there is nothing to recover from. That is the good case.
Where To Go Next
- Orbit Project Analytics for the fuller per-project picture.
- Troubleshooting Failed Builds once you know which builds fail.
- Orbit Deployment Pipeline for the gates that sit between a commit and production.