Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
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.

Project troubleshooting

Common project-side failure modes, especially when the app built successfully but does not come up healthy.