When a build fails
A build that stops now tells you why and what to do about it, in one sentence each. You do not need to read a build log first, and you should never need to ask support to decode an error for you.
You will see the cause in two places, both saying the same thing:
- the deployment panel, which describes the last attempt;
- Recent builds, which lists every attempt with its own cause.
One place that answers it for the whole environment
The environment's Overview carries a Deployment diagnosis panel. It names every application that has stopped or is still moving, and for each one: whether it was the build or the release task that stopped, the cause in the same words as the table below, whose move it is, the one next action, and how long that has held — so a release that has been waiting for you for an hour does not read like one that went ready ten seconds ago.
An environment where nothing has stopped says exactly that instead of showing an empty panel. If the panel cannot read one application's deployment, it names that application and claims nothing about it either way, rather than reporting it as healthy.
Reproducing a failed build where you can edit the code
A stopped build tells you the exact thing to reproduce it with, and none of it is new to you — it is the same record your build history already shows: the branch, the commit, the recipe digest, the toolchain digest and the runtime image, beside the application they belong to.
The panel gives you the command that checks out that exact revision in your own copy of the repository, for example:
git fetch origin main && git checkout 0123456789abcdef0123456789abcdef01234567
That is the whole mechanism: nothing is downloaded from the platform, no session is opened into the build, and the code stays where you can change it. Build the checked-out revision with the same recipe and toolchain to reproduce what the platform ran.
What each cause means
| What you see | Who acts | Try again? | What to do |
|---|---|---|---|
| The build could not read your source repository | You | Yes | Check the repository connection and that this branch still exists. |
| The build could not find the commit it was asked to build | You | Yes | Rebuild from the branch head rather than a commit that has moved. |
| Your configuration asks for something this build cannot do | You | Yes | Compare the configuration against what the build accepts, then save it again. |
| The build ran past its time budget and was stopped | You | Yes | Reduce what the build does, or ask for a larger time budget. |
| The build produced something that failed validation | You | Yes | Read the build output for the file it rejected, then rebuild. |
| The build worker did not report back | Us | No | Nothing — it is ours to fix, and the retry button is hidden because retrying cannot help. |
| A base image the build needs could not be fetched | Us | No | Nothing — we are on it. |
| The platform was refused permission to place the workload | Us | No | Nothing — a permission problem on our side will refuse again if you retry. |
| A connection failed while the platform was working | Us | No | Nothing — we retry it ourselves. |
| The build stopped for a reason the platform has not classified yet | Us | No | Nothing. Tell support if it repeats, because an unclassified cause is one we have not seen before. |
The retry button follows the answer. When the cause is yours it stays available; when the cause is ours it is replaced by a plain statement that we are handling it, so you never spend a retry on something a retry cannot change.
What the message will never contain
The cause is written for you, so it deliberately leaves out the things only the platform can read: raw exception text, namespace names, internal object names and anything credential-shaped. Those stay in the build's own record for staff.
That is why the sentence is sometimes less specific than the log. If you want the detail, the build's output is always available from Recent builds — and it is the same output support will look at.
A failed build takes nothing down; a failed deploy depends on how the application is replaced
A failed build produces no release at all and changes nothing that is already running. Whatever was serving keeps serving, and there is nothing half-deployed to clean up.
A deploy is the case that depends on the application. Where the platform can start the new release beside the old one — a build with no writable storage and an unchanged listening port — the old one keeps serving until the new one is ready, so a release that never becomes ready leaves the previous release serving the site.
Where the application rewrites its own files or changes its port, the old copy has to stop before the new one starts. A release that never becomes ready then leaves the site not serving until a working release lands, and the panel says the release failed rather than implying the old one is still there.
If a later attempt succeeds, the earlier failure stops being reported: the panel describes the state of the application now, not its history.
Getting further help
If the cause is unclassified, or a cause that should be yours keeps failing, use the Troubleshooting page for your environment. It carries the values support will ask for — the namespace, the desired generation and the applied generation — so you can quote them rather than hunt for them.