Just Dashboard Troubleshoot a deployment
Use Review findings and run evidence to fix source, build, startup, routing, and data problems.
Start with the evidence the dashboard already saved. For a new project, open Review and read what stops the deploy and the warnings to acknowledge. For an existing project, open Deployments → the failed run. The run names the step it failed at, the source revision and settings it used, a cause when it can identify one, and the build log line behind that cause. It links to the relevant setting when there is one.
The first release has not started
| What Review says | What to inspect |
|---|---|
| The application root or recipe is unsupported | Select the correct candidate in a monorepo, or choose a Dockerfile/Compose source that describes the application. The chosen build root must exist in the source revision. |
| A port or readiness check is missing | Set the application's internal listening port and a check it can answer. A web plan needs readiness evidence before it can go live. |
| A variable is required | Fill the value, connect a saved database, or accept a supported generated secret. Check its build/runtime/release-task scope. |
| A domain or certificate cannot be issued | Check the shown DNS address, inbound port 80, and which proxy owns public 80/443. A private Tailscale address is not a public certificate target. |
| The source moved since inspection | The branch has a newer commit than the one Review inspected. Press Inspect again, then review the new plan. |
Review uses the repository commit it inspected. A run checks the commit it builds again. If the plan changed, return to the affected step and deploy the current desired configuration.
Review shows the mounts the plan will keep, but it cannot discover every directory the application writes. If your app stores SQLite files, uploads, or keys, add a persistent volume for those paths before the first release.
The build failed
Open the failed run and select Show the line when offered, or read the transcript under the project's Logs → Builds. A failed install may need the lockfile's own package manager or a compatible toolchain version; an unfrozen install can also produce different dependencies for the same commit. A missing NEXT_PUBLIC_* or VITE_* build value belongs in build scope and becomes public in browser assets. A private registry or package registry requires an appropriate saved credential or install-scoped build secret. A missing output directory, executable, or generated client can require a corrected build command or release task.
The run distinguishes a registry or base-image failure from an application command failure. Fix the named cause before trying Rebuild without cache; a cache-free build alone cannot supply a missing variable or repository file.
The container started but did not become ready
Compare Settings → Runtime → Where it listens with the application's startup output. Inside a container, localhost is the container itself. The service usually needs to listen on 0.0.0.0 and on the internal port the plan exposes. The dashboard supplies PORT to ordinary container applications unless you set it explicitly; Compose and host-network applications keep their own conventions.
Check whether the readiness path redirects, requires login, or only answers under its public Host header. The dashboard probes a candidate with the planned hostname and can follow a bounded same-candidate redirect. A redirect to another origin cannot make the candidate healthy. HTTP, TCP, Docker health, and command checks, and smoke checks against the live route, each report their own failure and attempt evidence. Increase a legitimate slow startup's attempts or timeout under Settings → Runtime → Health checks; do not disable a check that is catching a real failure.
If the run says the application exited after starting, inspect its runtime output and command. A one-shot task that exits successfully is not a web server. If it mentions a missing database or a localhost database address, connect the database under Settings → Databases & backups and use the application URL for its container network. See database connections.
The release is live but the site is unreachable
Open the project's Runtime page to distinguish a healthy container from a working public route. Confirm the saved hostname resolves to the server's public address, the certificate covers that hostname, the managed ingress owns the route, and the visitor can reach standard HTTP/HTTPS ports. A public route may be unavailable even while a container answers on loopback. Use Logs → Requests to see whether the proxy received the attempt; use Logs → Output and Logs → Events for container failures. See domains and routing and traffic diagnostics.
A retry or rollback did not use the settings you expected
Retry replays the failed run's saved plan and variable revisions; once newer settings are saved it reads Retry with the settings it used. Choose Deploy changes in the header, or Deploy with current settings on the run, for newer saved settings. Rollback activates a retained release; it does not restore changed database rows, volumes, or external services. Confirm that the target artifact is still available, and restore data separately when the older application version needs its former schema. See release actions.