Orbit
Viewing Build Logs
Every Orbit deployment keeps its complete build log, plus a structured breakdown of what the build did and how long each phase took. This guide covers where to find the log, how to read the surrounding metadata, and the analysis Orbit runs over the log for you.
Viewing the Log For the Latest Deployment
Open the project in Orbit. The Latest build panel on the Overview tab shows the log for the most recent deployment. If a build is running right now, the log streams live, line by line, as the build agent produces it.
Click Full details to open the full deployment detail page.
Viewing Logs For a Specific Deployment
- Open your project in Orbit.
- Open the Deployments tab.
- Click any deployment to open its detail page.
- The full build log is on that page.
The Recent deployments list on the Overview tab has a View logs link on each row that goes to the same place. Preview deployments have the same link in the Preview deployments section.
Build Phases
The detail page splits the build into named phases with a duration for each:
| Phase | What happens |
|---|---|
| Clone | Fetching your repository at the deployed commit |
| Cache restore | Unpacking the cached node_modules, on plans with build cache |
| Install | Running your install command |
| Cache save | Repacking node_modules for the next build |
| Build | Running your build command |
| Upload | Packaging the output directory and storing the artifact |
| Done | The artifact is in front of traffic |
This is the fastest way to answer "why was that build slow". A long Install phase with a Cold build badge means the cache was missed. A long Build phase means your own build got slower.
Build Metadata
The cards above the log show the facts about the deployment:
| Card | What it shows |
|---|---|
| Status | Queued, Building, Deploying, Succeeded, Failed, Cancelled, Rolled back or Awaiting approval |
| Commit | The commit this deployment built, linking to the provider |
| Branch | The git branch it came from |
| Author | Who pushed the commit |
| Build time | Total wall-clock time, with a Fast, Normal or Slow rating against your own history |
| Artifact | Packaged output size, with a download link |
| Framework | The framework Orbit detected |
| Package manager | npm, yarn or pnpm, detected from your lockfile |
| Build cache | Cache hit or Cold build |
| Build host | Which build host ran it |
| Queue position | Your place in the queue, while the deployment is still queued |
| Pull request | The PR number, for a preview deployment |
| Health score | A score out of 100 with the deductions listed |
Analysis Orbit Runs Over the Log
The detail page is not just a text dump. Orbit parses the log and surfaces what matters.
- Build timeline with per-phase durations.
- Slow build detected when a build is significantly slower than your own median, with the percentage and your typical time from the last 10 builds.
- TypeScript errors, extracted and counted, when the build failed on type checking.
- Build analysis for Next.js builds: per-route sizes, first-load JS, and static, dynamic and ISR route counts.
- Bundle regression warnings when a route's first-load JS grows more than 20% versus the previous deployment, or the shared JS bundle grows.
- npm audit results parsed straight out of the install output, summarised by severity.
- Security headers audit scored out of 60 points.
- Smoke test results, if you have configured smoke test paths.
- Performance budgets exceeded, if you have set budgets.
- Build optimization advisor, listing concrete changes with an estimated size saving, ranked by impact.
- Real user metrics, the p75 Core Web Vitals recorded while that deployment was live.
What Environment Variables the Build Actually Saw
The detail page lists the environment variable keys that were injected at build time, and diffs them against your current configuration: added, changed, removed, unchanged. Teal keys came from an environment-specific override, grey ones from project level.
Values are never stored and never shown. Hovering a key gives you a SHA-256 fingerprint, which is enough to confirm two environments have the same value without revealing it.
This diff is the fastest way to answer "did my env var change actually get into the build". If the deployment predates the change, Orbit says so with an Environment variables updated since this deployment notice and reminds you the change will not take effect until you redeploy.
Comparing Two Deployments
Click Compare on a deployment to diff it against the previous one: build time, artifact size, cache state, framework, and the file-level artifact diff. This is the quickest route to "what actually changed" when a deploy behaves differently from the one before it.
When a Build Fails
The status card turns to Failed and the log shows where it stopped. Above the log, Orbit adds a categorised failure summary with a suggested fix. Recognised categories include out of memory, compile error, test failure, lint error, install error, network error and timeout, and Orbit matches specific patterns such as a missing module, an ERESOLVE peer dependency conflict, a TypeScript error code, a full build disk, a package 404 and an out-of-date lockfile.
There is also a Get AI diagnosis button, which reads the last 120 lines of the log along with the detected framework and failure category and returns a plain-language explanation.
The AI diagnosis is labelled AI-generated, verify before acting for a reason. It is very good at pointing you at the right line of the log, and it is not authoritative about your codebase. Read the log line it refers to before you change anything.
Retrying a Failed Build
On the deployment detail page, click Retry build to re-run the same commit without pushing a new one. This fixes transient failures such as a network error during install.
If you suspect a stale cached dependency, use More retry options, then Retry with cleared cache, which deletes the build cache before retrying.
Full failure-by-failure guidance is in Troubleshooting Failed Builds.
Cancelling a Running Build
Click Cancel while a build is running.
Cancelling terminates the build machine immediately and cannot be undone. The deployment is recorded as Cancelled, and the previously live deployment keeps serving traffic, so cancelling never takes your site down. Note that pushing a new commit to the same branch while a build is running cancels the in-flight build automatically, so a cancelled deployment followed by a running one is normal.
Downloading the Artifact
Every successful deployment keeps its packaged output. Click Download on the Artifact card to pull the exact bundle that was served. There is also an artifact browser for inspecting the contents without downloading the whole thing.
How long artifacts are kept is set in Settings, under Artifact retention: the number of successful artifacts to keep per environment, from 10 to 500, defaulting to 50. Older artifacts are deleted daily. The currently live deployment's artifact is always kept, whatever the setting.
Artifact retention is what makes rollback possible. Setting it too low shortens how far back you can roll a bad deploy without a rebuild. If you deploy many times a day, raise it rather than lower it.