Start a build
Open the project → Builds with project build permission
Check the branch, application root, build command, and required environment variables in Project Settings → Build.
Choose the target environment and start the build
For an environment-specific build, use Build in that environment's settings.
Open the new build and follow its status and logs
Queued means it is waiting; running means work is underway; success means the build completed; failed or cancelled requires another build before this version can be reviewed.
After success, open the preview and test a real route
Check the commit and environment before inviting reviewers.
Retry or cancel
Use Retry on a failed build after correcting the reported problem. Check the new build's commit and logs rather than assuming a retry changes the source version.
Use Cancel on a queued or running build when you have permission. Wait for its status to update; cancelling is a request and does not promise every process stops instantly. Start another build when you are ready.
Concurrency, timeout, and availability can depend on the active account configuration. Check the limit/error shown for that build and Billing rather than relying on an undocumented universal timeout.
Diagnose common failures
| Symptom | Check |
|---|---|
| Dependency / module missing | Lockfile, install command, declared dependencies, app root, and workspace package paths. |
| Required variable missing | Variable spelling, selected configuration, framework prefix, and whether the value is needed at build time or runtime. |
| Output directory missing | The build command completed and the configured directory matches its actual output. |
| SSR route fails after a successful build | Server runtime/adapter compatibility, runtime variables, app startup errors, and API access. Build success is not a server health test. |
| Preview login fails | The app's login route, test account, and authenticated-preview setup. |
Review the intended version
Reports and verification should refer to the build or deployment you actually tested. A new build can change the environment's current target; keep the original report's version context when comparing a fix.
If backend evidence or SDK instrumentation changed, rebuild before opening a new session. Evidence that was not captured in the original version cannot be added simply by revisiting an old report.