Following a deployment
A deployment takes time because it goes through build, image push, and activation. Zero shows that time rather than hiding it behind a stopped clock.
Deployment in progress
As soon as you deploy, the deployment shows up right away under Deployments, in a Deployment in progress section — with no need to reload the page.
The card says what is happening right now, with the name of the stage — for example, Building the image · next stage: Image built (2 of 9) — and who deployed.
View details is there from the first second and opens, right in the card:
- the elapsed time;
- the stages, done, in progress and pending — the same ones as on the Deployment page;
- the platform's narration, live: "Code pinned to the version that will be deployed.", "Application image built and stored.", and, if something goes wrong, the reason.
At first the deployment is not a Deployment yet: it is born when the version is registered, after the platform fetches the code and builds the image. From then on the panel gains Open the Deployment, and the Deployment enters the table on its own. Deployments that do not build — an address change, a scale adjustment — show the stages they do not go through as skipped.
The deployment list
The same list appears in two places: at the organization level, with every deployment; and inside a project, restricted to it.
| Column | What it shows |
|---|---|
| State | One of the visible states |
| Project | Only in the organization list |
| Version | The committed version — a dash when there is none yet |
| Duration | A dash while the work has not finished |
| When | When the deployment started |
Absence never becomes a number: a deployment with no committed version shows a dash, not zero.
An address change also shows up here, as Address change: it is the version that was already live, redeployed with the new address, without rebuilding.
The timeline
Opening a deployment shows the timeline, which is the source of truth about what happened. It has four tabs:
| Tab | Content |
|---|---|
| Overview | The steps taken, with the duration of each |
| Events | The chronological record, in product language |
| Configuration | The exact configuration of that deployment |
| Technical details | Internal identifiers and values, labeled as such |
While the deployment is in progress, the screen refreshes itself. When it finishes, it stops refreshing — there is no reason to keep polling an outcome that will not change.
While the platform waits for the application to become ready, the timeline narrates the wait — for example, "The application started, but is not accepting connections on port 8080 yet." or "Waiting for free capacity in the environment for the instance.". The sentence "Version N is live." only appears once readiness has actually been observed. If the application does not become ready, the deployment fails with the reason and the action; see Deployment states.
Deployment attempts
Not every attempt becomes a deployment. A source failure — an unreachable repository, a branch that does not exist — happens before there is a committed version, and an object that only comes into being after that would not record it.
That is why the project also has a list of deployment attempts: it shows the ones that died early, with the reason. That is where to look when you clicked Deploy and nothing appeared in the deployment list.
How far it was confirmed
Each deployment shows how much the platform actually proved, on a four-step ladder:
Image checked → Configuration applied → Application answering → Address confirmed
The console shows this as a ladder, not as a single green badge. "Configuration applied" and "Address confirmed" are different claims, and treating them as one makes someone announce a version that is not answering yet.
- Application answering is recorded when the instances become ready — they accept connections on the service's port.
- Address confirmed comes from real traffic: a request that came in from the internet after this version was activated and was answered by the application. A response generated by the platform itself when it cannot reach the application, such as a
503, does not count.
That is why a fresh deployment stays at 3 of 4 until the first real request arrives and is answered — opening the address in a browser is enough. From then on, 4 of 4 and Receiving traffic. The same traffic collection feeds the traffic charts.
On the project's Domains page, the same rigor applies to HTTPS and routing: the indicators say confirmed or not confirmed yet, never "error". Absence of proof is not proof of failure, and painting a freshly deployed address red teaches people to ignore red when it matters.
Common errors
| Symptom | What to look at |
|---|---|
| I clicked Deploy and nothing appears in the list | Deployment attempts — the failure happened before the version |
| I want to see what the deployment in progress is doing | View details on the card: stages and live narration |
| The deployment has been in Building for a long time | View details shows how far it got. The builder's output is in the Deployment's build log, once the version is registered; if the build fails before that, the reason is on the card itself |
| It reached Online and the ladder stopped at 3 of 4 | Normal: the first real request is missing. Open the address |
| It reached Online but the address does not answer | The Domains page: check whether HTTPS and routing are confirmed |
| The Answering step shows as failed | The application did not become ready; the screen gives the reason and the action. See Common problems |
Next steps
Was this page helpful?
Report a problem on this pageDo not send passwords, keys, tokens, or customer data.