Start and health failures

Both failures happen after the build. The page is titled Deployment failed, and the Runtime log is the one to read: it is what the container wrote in the seconds before Kuppit gave up on it. Traffic was not moved.

The new revision could not start

The container exited before it was healthy. Something in your start-up path threw, or the process ended on its own.

Open View relevant logs. What you are looking for is the last thing the process printed. The usual causes:

• A crash on boot. An unhandled exception while connecting to something, reading configuration, or importing a module that is not in the image.
• A variable the code requires but the service does not have. Check the service's Variables tab, including what it inherits from the environment; a value set after the last deployment needs a redeploy to be present. See when a change takes effect.
• No start command, or the wrong one. For an automatic build, the Start command on Settings must start a server that stays running. A script that builds and exits, or a start that runs tests, ends the process.
• A database that is not ready or not reachable. A reference resolves to real credentials, but the application still has to connect. A connection error at boot is in your log, with the address it tried.

The application did not become healthy

The container ran, but nothing answered on the port Kuppit routes to, so the health check never passed.

Kuppit sets PORT and sends the health check to it. Your server must listen on that port, on all interfaces:

const port = Number(process.env.PORT ?? 8080)

server.listen(port, '0.0.0.0')

Check, in order:

• The port. A hard-coded port, or PORT read before it exists, means the health check knocks on a door nothing is behind. Nuxt and Next.js read PORT themselves; Express and plain Node do not.
• The interface. A server bound to localhost or 127.0.0.1 accepts nothing from outside the container.
• Start-up time. A process that takes minutes to be ready, building on boot or warming a large cache, can run out of the check's patience. Do that work at build time, or start listening first and finish warming after.
• The response. The check needs a response, not a healthy one: a server that answers with an error is up, a server that hangs is not. Something blocking the event loop at start-up is the usual cause of a hang.

The PORT contract has the full rule.