Goal
Know where to look when a project deployment does not behave the way you expect.Prerequisites
- An existing project
Workflow
1
Use build history to inspect build stages and failures.
2
Use deployment history to see what is live and what changed.
3
Use project logs to inspect runtime output after deploy.
4
Use rollback actions when the latest deployment should not remain active.
Best debugging order
- Build first: did the artifact get produced correctly?
- Deployment second: did the release actually become live?
- Logs third: what is the running application doing now?
What each surface tells you
- Build history explains source and image creation problems.
- Deployment history explains release transitions and rollback choices.
- Logs explain the current runtime behavior after the deployment is live or failing.
How runtime shape affects lifecycle
- Worker services can still build and deploy, but they do not expose a public URL or domain ingress.
- Contract-build workloads stop at artifact creation and should be treated as build-only output rather than a live runtime.
- If a project is intentionally build-only, deploy actions are less relevant than build success, artifacts, and logs.
Expected result
You can trace a project issue from build to deployment to live runtime logs.
Related guides
Project troubleshooting
Common project-side failure modes, especially when the app built successfully but does not come up healthy.
Resource activity
Follow builds, deployments, releases and database operations from the resource you are working on.