A deployment failed

The platform ran the deployment and ended it in error. Most often the build failed: a dependency did not install, a build command exited with an error, or the Dockerfile has a step that fails.

Read the Build log from the bottom up; the first error above the end is the one to fix. Fix it in the repository or in the service's build settings, then press Deploy. For build types and commands, see Build settings.

The build and the deployment finished, but two minutes later no container of the service was running. Whatever the container starts ended on its own: the process crashed, a variable it needs is missing, the start command is wrong, or the image's own command exits when nothing is typed at it.

Open the service's Logs tab for what it printed before it stopped, and check its Overview for the alert "The engine keeps restarting this service". The service keeps restarting walks through each cause.

The database was deployed, but no container of it was running two minutes later.

Open the database's Logs tab for what it printed, then press Deploy again. If it fails the same way twice, contact support with the project and service names.

The platform refused the deployment or never received it. Nothing changed: what ran before still runs.

Press Deploy again in a minute. If it keeps failing with this sentence, contact support.

Every deployment of a GitHub service asks GitHub for a fresh token to clone the repository, and GitHub refused. The usual causes: the repository was removed from the Cahaves GitHub App's list of repositories, the App was uninstalled or suspended on GitHub, or the repository was renamed or moved to another owner.

On GitHub, open the App's installation settings for the account and make sure the repository is selected. If the repository moved or was renamed, choose it again on the service's Source card and press Save source. Then press Deploy. See GitHub will not connect if the account itself needs connecting again.

A deployment may take at most two hours. This one was still building, so Cloud stopped it.

Read the Build log for the step that was running when it stopped: a step waiting on input, or a very long download or compile. Shorten the build, then press Deploy.

Cloud lost track of the deployment: the platform never reported how it ended, and after two hours Cloud released the service so you can act on it.

The deployment may have finished anyway. Check the service's state chip, its Logs tab and its address with Visit before you press Deploy again. If the state looks wrong, contact support.

This one appears on a deployment that is still in progress. Cloud asked the platform to deploy and has not yet been able to confirm what happened, so it checks again every minute. Until it knows, or two hours pass, the service counts as deploying: it cannot be deployed again, and its domains and volumes cannot be changed.

Wait. The deployment ends on its own, either with the real outcome or with the two-hour sentence above. If you need the service sooner, contact support.

The deployment ended Cancelled because your account was suspended before it reached the platform. While an account is suspended, nothing can be deployed.

Contact support to have the suspension lifted. Then press Deploy.

The deployment ended Cancelled because the organization's paid services were stopped for billing while it was queued or building. While they are stopped, no paid service in the organization is deployed; your free application and free database are not affected.

Clear the cause on Billing, as Stopped for billing describes. Once the services are back, press Deploy.

The deployment could not start because the workspace of the service's organization is not ready. See Your workspace is still being prepared.

The service was created on a platform Cloud no longer runs it on, so nothing can deploy it. This is not something you can fix from the console. Contact support with the project and service names.

A service built with nixpacks needs to know what to run, and it decides while it builds. A Node repository whose package.json has no start script fails the build with this line before any container exists.

On the service's Overview, in the Source card, fill Start command with what starts your application, for example npm run start, press Save source, then press Deploy. Or add a start script to package.json and push. See Build settings.