Build failed: find the line that matters, then fix the cause.

• Find the step. A deploy installs dependencies, builds, runs a release command if you set one, then starts the app. On Canner the summary names the step: install failed (exit 1) or build failed (exit 1), followed by the error lines it picked out.
• Skip the warnings. npm warn deprecated … lines and bundle-size warnings don’t fail a build. Canner’s summary drops lines marked as warnings for that reason.
• Read upward from the end. The last lines are usually the tool reporting that it exited. The cause is the first Error:, npm error, ✘ [ERROR] or Type error: above them.
• Note the exit code. It tells you whether the tool failed on its own or was stopped from outside (table below).

These are the messages Canner prints, and the tool messages it recognizes. On a failed deployment, Canner shows a How to fix it card for the cause it found, with the raw log one click away under Error details.

Canner installs dependencies with install scripts disabled, for supply-chain safety. Most packages don’t need one. Packages that compile or download a native binary (sharp, bcrypt, better-sqlite3, canvas) install without error and then fail when your code first imports them, which can be at runtime rather than in the build.

The build log warns you before that happens, naming the packages. Allow them in package.json; Canner then rebuilds just those, with network access blocked:

// package.json: let these packages run their install script
{
  "canner": { "allowedBuildScripts": ["sharp", "better-sqlite3"] }
}

// pnpm projects can use pnpm's own setting instead
{
  "pnpm": { "onlyBuiltDependencies": ["sharp", "better-sqlite3"] }
}

A deploy runs unattended. When a command prints something like Would you like to proceed? (y/N) and then goes quiet for about 20 seconds, Canner treats it as stuck at a question. For the release command, the deploy page shows the question and, where answers are turned on, offers Yes and No; with nobody there it stops after 5 minutes and tells you what was asked. The deploys docs list the usual flags: --force for prisma migrate reset and artisan migrate, --accept-data-loss for prisma db push, --noinput for Django’s collectstatic.

A build that succeeds still has to start. The new version must answer on / (or your health-check path) within 30 seconds. app did not respond on / within 30s almost always means the app listens on a hard-coded port instead of process.env.PORT, or crashed on boot over a missing variable. The failure message includes the end of your app’s own log, which usually holds the stack trace. A bot or job runner with no web server should be redeployed as a worker, which skips the check. The troubleshooting docs cover each case.

A failed release command stops the deploy before the new version starts, so the version already live keeps running.

“Works on my machine” builds usually differ in one of four ways: files that aren’t committed, a lockfile that isn’t current, a case-insensitive file system, or a different Node version. A clean Linux container rules out all four:

# Reproduce a clean Linux build on your machine
docker run --rm -it -v "$PWD":/app -w /app node:22 \
  sh -c "npm ci && NODE_ENV=production npm run build"

If you work with Claude Code or Cursor, Canner’s MCP server gives the agent canner_get_deployment, which returns a deployment in full, build log included. It can read the failure, fix the code and redeploy without you copying logs around. More guides are under hosting by framework.