Common problems

Always start with the same question: which step did it stop at? The deployment state already rules out half the possible causes.

The deployment fails at Building

The problem is in the image build. Open Logs → Build and choose the deployment.

In the log	Cause	What to do
Dockerfile: no such file or directory	The deployed folder has no Dockerfile	Fix the folder in the project's source
Authentication failure fetching the code	Private repository with no access token	Enter a token under Source, in the project
Dependency error	A difference between your machine and a clean build	Pin versions; the build does not reuse what exists locally
Out of memory during the build	The build is too heavy	Reduce steps, use a smaller base image, or use a multi-stage build

The application does not become ready

The build passed, but the application did not become ready — it did not accept connections on the service's port. The deployment fails with the reason, and 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 to do
APPLICATION_NOT_STARTED	The application never started	Deploy again. If the reason comes back, talk to whoever administers the platform: the image could not be pulled, the environment refused to create the process, or capacity ran out — none of that is fixed in the application
APPLICATION_CRASHED_ON_START	The application stopped right after starting	Look at the last lines under Logs → Runtime
HEALTH_CHECK_FAILED	The application started but did not answer	Make the application listen on 0.0.0.0, on the port from the PORT variable

Before failing, the timeline narrates the wait — "The application started, but is not accepting connections on port 8080 yet.", for example. Definitive reasons end in about 30 seconds; the others, within the 5-minute deadline.

What to look at, in order:

1. The port. The application must listen on 0.0.0.0, on the port given by the PORT variable — not on localhost, nor on a fixed port. EXPOSE in the Dockerfile does not change the port. This is the most common cause.
2. Startup. Open Logs → Runtime: an exception at startup shows up there.
3. Missing configuration. A missing variable or secret usually takes the application down at startup. See Configuration.
4. Writing to disk. The file system is read-only, except /tmp. Writing anywhere else fails — and, if it happens at startup, it usually takes the application down. See How the application runs.
5. Resources. Maximum memory set too low takes the application down while it starts. See Resources and limits.

Nothing was switched: the previous version keeps serving. If you need time to investigate, there is no rush to restore anything.

I clicked Deploy and nothing appears in the list

The failure happened before there was a committed version — an unreachable repository or a branch that does not exist, for example.

Open Deployment attempts in the project: that is where those are recorded, with the reason.

The address does not answer

Check	Where
Did the deployment reach Online?	Deployments
Was there an address change? The previous address stops answering once the new one is live	Domains, in the project
Are HTTPS and routing confirmed?	Domains, in the project
Is the application up?	Services — ready replicas
Is the application answering?	Logs → Runtime

If you use a custom domain, check the zone's state too: a zone that is not Ready does not serve addresses.

The deployment stayed at 3 of 4 steps

That is normal right after deploying. The last step, Address confirmed, is only marked when a real request comes in from the internet and the application answers it. Open the address in a browser: from the first response on, the ladder goes to 4 of 4 and shows Receiving traffic.

If you opened the address and the ladder did not move, see The address does not answer: a response generated by the platform when it cannot reach the application, such as a 503, does not count as proof.

The application is live, but with errors

1. Observability → Routes shows which route concentrates the errors. A 2% rate overall can be 100% on one specific route.
2. Logs → Runtime shows what the application wrote at the time.
3. If the errors started after a deployment, restore the previous version and investigate calmly.

I changed a variable and nothing changed

Configuration takes effect on the next deployment. The screen warns when a change has been declared and not applied.

If you deployed and the old value persists anyway, look at inheritance: the same name declared in a more specific scope wins. The variables page shows the whole chain and which value is effective.

The runtime log shows nothing

Three causes, in order of frequency:

1. No application is running yet — the screen says so explicitly, and that is different from an empty list.
2. The application writes to a file, not to stdout/stderr.
3. The selected period does not cover the moment of the problem.

A project does not reach another project's service

Check	Where
Do both projects have an environment in the same network?	Project network, in both
Was the calling project authorized for that service, and is the permission Allowed?	Project network, in the called project
Does the call use the internal name and the service's port?	Internal addresses of this project, in the called project
Is the service a web application or an internal service? Continuous processes and scheduled tasks receive no connections	Services

Resolving the name does not mean reaching: without permission, the name resolves and the connection does not complete. See Networking between projects.

A screen says the capability does not exist

It is not your error and there is nothing to configure: that capability is not available in this installation. The screen says what the platform does not do, without promising a date. See What exists today.

The custom domain zone does not confirm

The console shows the exact diagnosis. The most common cause is the name field in the provider's panel: some want only apps, others want the whole apps.acme.com. See Delegating at your provider.

When to ask for help

Have these at hand:

• the project and the deployment's address (the URL of the deployment page);
• which state it stopped at;
• the relevant excerpt from the log — build or runtime, depending on the step.

With those three items, support sees the same evidence you do.

Next steps

• Deployment states
• Logs
• What exists today