When a deployment fails
A deployment that stops before going live is Failed, and traffic is not moved: whatever was serving keeps serving. Its page says which phase failed, whose problem it is, and what to do next, with the raw message from the infrastructure one disclosure down under Advanced details.
The title is Build failed when the image could not be built, and Deployment failed otherwise. Below it, one sentence names the cause. The sentences fall into three groups.
Your application's
These are things in the repository or the running code. The page offers View relevant logs, which opens the stream that failed with errors selected, and Redeploy.
| Failure | What it means | What to do |
|---|---|---|
| The Dockerfile Kuppit was told to build no longer exists | The service's Dockerfile path points at a file the commit does not have. | Fix the path on Settings, or restore the file. |
| Build settings no longer match the repository | The commit changed shape since the settings were saved, for example a Dockerfile appeared. | Choose Inspect latest on Settings, review, save. |
| The repository is too large for Kuppit to build | More than 20,000 files, or extraction took over a minute. | Narrow the Root directory, or remove what is not needed to build. |
| The repository source could not be read | The archive from GitHub was malformed. | Push again. If it repeats, check the repository for files Git cannot represent. |
| The build failed | Your build command or Dockerfile step exited with an error. | Read the Build log. |
| The build ran out of time | The build exceeded 15 minutes. | Cache better, build less, or move to a Dockerfile with a tighter build. |
| The new revision could not start | The container exited before it was healthy. | Read the Runtime log. A missing start command or a crash on boot lands here. |
| The application did not become healthy | The container ran but never answered on PORT. | Listen on PORT and 0.0.0.0. See the PORT contract. |
Yours to fix on the Variables tab
A reference that cannot be resolved stops the deployment before anything is built. The page says Check this service's variables, then deploy again and offers Edit variables.
| Failure | What to do |
|---|---|
| A variable references a database that no longer exists | Remove the variable or point it at a database that exists. |
| A variable references a database that is being deleted | The same. The deletion will finish; the reference will not come back. |
| A variable references something the database does not expose | Choose one of the six variables a database exposes. |
| The referenced database is still being created | Wait for Ready, then redeploy. |
Kuppit's own
Some failures are Kuppit's to fix, not something in your repository, and the page says so. They include an internal build error, a build Kuppit lost track of, traffic that did not move to the new revision in time, a deployment that stopped making progress and was abandoned, and a referenced database that failed to provision or cannot be reached from this service. Redeploy once; if it fails the same way, it is being looked at.
After a failure
The failed deployment stays in the history with its logs. Fix the cause, then push, or choose Redeploy on the failure or Redeploy this commit in the menu, to build the same commit again with the service's current settings and variables.