Orbit
Orbit Project Analytics
The Analytics tab is the full picture of how a project is behaving: how long builds take, how often they succeed, how much of your plan's build minutes and bandwidth the project is using, and where the time is going when a build is slow.
Where Analytics Lives
Open Orbit, click the project, and choose Analytics under the Observability group in the project tab strip. The page is titled Analytics and covers build performance, traffic and deploy frequency for this project.
Two neighbouring tabs slice the same data differently. Build Insights focuses on build duration percentiles and cache behaviour, and Web Vitals covers real-user performance. See Orbit Build Insights and Orbit Web Vitals.
The Summary Cards
Five cards sit across the top:
| Card | What it counts |
|---|---|
| Build minutes | Total build minutes for this project over six months |
| Origin requests | Requests that reached your origin, so cache misses only, over six months |
| Origin bandwidth | Bytes served from origin over six months |
| Success rate | Succeeded against total finished builds over 30 days |
| Cache time saved | Build time saved by cache hits across the last 100 builds |
Origin requests and origin bandwidth are exactly that: origin only. Anything served from the edge cache is not counted here, which is why a busy, well-cached site can show surprisingly small numbers. That is the system working, not a reporting gap.
Usage This Month
Below the cards is a panel headed Usage this month, showing your plan name and making clear that these figures are account-wide, not per project. Two meters are drawn:
- Build minutes, used against your plan's monthly allowance, with this project's share called out separately and the minutes you have left.
- Bandwidth (origin), the same shape in gigabytes.
If you go past an allowance, the panel shows the overage and what it costs: build minutes bill at US$0.05 per minute and origin bandwidth at US$0.03 per GB, on top of your plan.
It also projects forward to the end of the month based on the rate so far, with an estimated overage if you continue as you are. That projection is the useful number, because it tells you about a problem while you can still do something about it.
A runaway build loop is the classic way to burn an allowance. A deploy hook wired into a job that itself triggers on deploy will happily consume minutes all night. If the projection jumps sharply, check the Deployments tab for a repeating pattern before assuming your traffic grew. A spending cap gives you a hard stop: see Orbit Spending Cap.
Build Insights
The Build Insights block reads the data and writes the observation for you, in plain language, rather than leaving you to spot it in a chart. What appears depends on what is true of your project, for example:
- A success-rate statement, either praise for good reliability or a prompt to review recent failures.
- Build time up or down compared with the previous fortnight, with both averages quoted.
- A low cache hit rate, with the count of builds that used a warm cache and a nudge about keeping the cache key stable between commits.
- Monday builds being slower, which usually means the cache expires over the weekend.
- The worst-performing branch by success rate.
- An average queue wait over 90 seconds, meaning builds are waiting for a runner.
Treat these as leads, not verdicts. Each points at a section further down the page with the underlying numbers.
Deploy Frequency, Reliability and Activity
Three visualisations cover cadence:
- Deploy frequency: last 30 days shows deploys per day.
- Reliability: last 8 weeks stacks succeeded against failed per week, with the trend against the prior four weeks.
- Deploy activity: past year is a calendar heatmap, shaded by volume and coloured by whether the day's deploys succeeded.
The year heatmap is the one to show someone who asks how active a project is. Gaps and clusters are visible instantly.
Build Performance
Build performance charts the last run of successful deploys as bars, with average and fastest build time and the cache hit rate. Hovering a bar shows the branch and commit, and whether that build hit the cache.
Build time trend reduces each week to its P50 and reports whether this week is faster or slower.
Build time percentiles gives P50, P90 and P99. The footnote is the important part: a lower P90 means more consistent builds. If your P50 is fine but your P90 is triple it, most builds are quick and something occasionally goes badly wrong, which is a different problem from being uniformly slow.
Cache Efficiency
The Cache efficiency block compares cold builds against cached builds directly: the average duration of each, the total time saved, and the resulting speed improvement.
If the cached average is barely better than the cold average, the cache is being restored but not helping, usually because the install step is not the slow part of your build. If the hit rate itself is low, the cache is being invalidated too often; a lockfile that changes on every commit will do that.
Per-environment build stats breaks builds and cache hits down by production, staging and preview, which is where you find out that previews are doing most of your build minutes.
Per-Branch and Per-Author Stats
Two tables cover the last 30 days:
- Per-branch build stats: deploys, success rate and average build time by branch.
- Per-author deploy stats: the same by the person who pushed.
The per-branch table is the practical one. A branch with a low success rate is usually a branch with a broken test or type-check that everyone has learned to ignore.
Queue Wait and Time Of Day
Build queue wait: last 14 days measures the gap between a build being queued and a builder picking it up. The footnote sets the expectation: under five seconds is typical, and spikes indicate contention.
Build time by hour: last 90 days is a day-of-week by hour-of-day heatmap in UTC, showing when your builds are slowest, with cells needing at least two builds before they are shaded. Combined with queue wait, it tells you whether a slow build is your build or a busy moment.
Failure Causes
Failed deployments over the last 30 days are classified by root cause: compile error, install failure, test failure, lint error, timeout, out of memory, network error, or unknown. The section calls out the top category and how much of your failures it accounts for.
This is the fastest route from "our builds keep failing" to a specific thing to fix. If two thirds of failures are install failures, the problem is dependency resolution, not your code. Troubleshooting Failed Builds covers what to do with each category.
Artifact Size
Artifact size over time tracks how large each build's output is, labelled growing, shrinking or stable, with the oldest and latest sizes.
A steadily growing artifact is worth investigating before it becomes a slow site. The usual culprits are an image directory that nobody prunes and a dependency that pulled in something enormous.
Web Analytics
The bottom section shows Core Web Vitals from real visitors over the last 30 days, with top pages, countries, referrers, and per-page p75 performance.
If you have not added the collection snippet yet, this section is empty and offers a link to set it up. See Orbit Web Vitals for the snippet and what each metric means.
Where To Go Next
- Orbit Build Insights for percentiles and cache detail.
- Orbit Spending Cap to put a ceiling on overage.
- Orbit Plan Limits for what your plan includes.