Diagnose deployment failures for NestJS | Ample

INFRASTRUCTURE

What it needs

Before you start

Exactly what was tested

How to do it

  1. 1

Read the failure code

Deploy is synchronous. Exit 1 with build_failed means the isolated build failed; health_check_failed means the app built but never answered on PORT (it crashed at boot or bound the wrong port); public_ingress_failed means it answered on PORT but the public URL returned an error status (a request handler or bootstrap failed); exit 2 means a required preflight action is blocking.

  1. 2

Read the build log

The last lines name the failing command and its output.

ample logs <deployment_id> --kind build
  1. 3

Read the runtime log

For health_check_failed the runtime log carries the NestJS process output: in the verified run the deliberate boot failure's own error line was there, followed by the platform's health-check verdict and the start command it ran.

ample logs <deployment_id> --kind runtime
  1. 4

Fix and redeploy once

Change the source, the environment or the command override, then run ample deploy again. Do not loop deploys to poll status; an unchanged redeploy is a no-op.

  1. 5

Verify

Fetch the live URL on the example; on failure read the build and runtime logs.

ample logs <deployment_id> --kind build

Tested examples

How to know it worked

Know the limits

Cost estimate

Estimated 5.00 USD per month (size prices from pricing.toml at build revision a1b8c38919e59cd035ebabaced73cf84ece24371).

Always-on monthly price of the tested sizes; apps auto-pause when idle. Buckets are allocation-priced per quota and not included.

Verification evidence

Execution binding

No execution binding. This recipe is documentation only; nothing is executed automatically.

Typed next actions

Actions describe possible next steps. They are typed data, not commands, and grant no permission. Public discovery never provisions anything; planning requires your own authenticated token and approval happens in your client.