Deployment states

A deployment goes through states in order. Five are progress; four are outcomes.

Progress

State	What is happening	Can it be cancelled?
Preparing	The deployment was accepted and is being validated; it awaits a place in the queue	Yes
Building	The code is being fetched and the image built	Yes
Deploying	The artifact was pushed and the new version is being applied	No
Verifying	The new version is starting, and the platform waits for it to become ready before it receives traffic	No
Rolling back	A previous version is being restored	No

The cancellation window closes when the artifact is pushed. From then on, the way out is restoring the previous version.

Outcomes

State	What it means	What to do
Online	The new version became ready and is now the active one	Nothing. The address is confirmed by the first real request — see How far it was confirmed
Could not deploy	It failed. The previous version is still active and intact	The screen gives the reason and the action; also look at the log of the step that failed
Cancelled	Cancelled before the traffic switch. No visible change	Deploy again whenever you want
Previous version restored	The previous version is serving again	Investigate the problematic version

When the application does not become ready

For the platform, an instance is ready when it accepts TCP connections on the service's port — the port the application receives in the PORT variable. See How the application runs.

While it waits, the deployment's timeline narrates what is happening, with sentences such as:

• "The application started, but is not accepting connections on port 8080 yet."
• "The application exited right after starting (code 1); trying again."
• "The environment has not managed to pull this version's image yet."
• "Waiting for free capacity in the environment for the instance."

The wait has a 5-minute deadline. If the application does not become ready within it, the deployment fails with the reason — and nothing is switched: the previous version, if there was one, keeps being the one that answers. When the reason is definitive, the deployment ends in about 30 seconds, without waiting for the whole deadline.

On the deployment screen, the Answering step shows as failed, with the problem and the action. The same code appears in the API and in the CLI:

Code	What the screen says	What happened	What to do
APPLICATION_NOT_STARTED	The application never started	The image could not be pulled, the environment refused to create the process, or there was no capacity	Deploy again. If the reason comes back, talk to whoever administers the platform — it is not something you fix in the application
APPLICATION_CRASHED_ON_START	The application stopped right after starting	The process exited several times in a row; the screen says how many and with which code	Look at the last lines under Logs → Runtime. It is usually a missing environment variable or an unconfigured dependency
HEALTH_CHECK_FAILED	The application started but did not answer	The process is up and did not accept connections on the service's port within the deadline	Make the application listen on 0.0.0.0, on the port from the PORT variable

The guarantees

These always hold, and day-to-day operation rests on them:

1. A failed deployment never leaves the service without an active version, when there already was one.
2. The traffic switch only happens after the new version becomes ready.
3. No deployed version is overwritten — every attempt creates a new one.
4. Once the artifact is pushed, the way out stops being cancellation and becomes restoration.
5. Every transition records when it happened, who asked for it, the reason, and the evidence when there is a failure.

How far it was confirmed

Beyond the state, each deployment shows how much was actually proven, on a four-step ladder:

Step	Meaning
Image checked	The image was built and its integrity confirmed
Configuration applied	The platform accepted this version's configuration
Application answering	The instances became ready: they accept connections on the service's port
Address confirmed	A real request, coming from the internet after this version was activated, reached the application and was answered by it

Before the first step, the screen says Not verified yet.

"Address confirmed" only comes from real traffic. A response the platform generates itself when it cannot reach the application — a 503 with "upstream connect error", for example — does not count as proof. 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.

"Configuration applied" and "Address confirmed" are different claims. The ladder exists so nobody announces a version that is not answering yet.

Next steps

• Following a deployment
• Restoring a previous version
• Common problems