page:guides:django:deployment diagnostics

Diagnose Deployment Failures for Django

Summary

Deployment diagnostics for a Django app on Ample. Verified on Django: the same app deployed with a deliberate boot failure (CANARY_FAIL=boot): ample deploy exited 1 with a coded failure (health_check_failed when the process dies at boot, public_ingress_failed when the framework boots but every request answers 500) and the app's own error line was readable with ample logs --kind runtime. The cause is read from the framework's output rather than guessed.

Build and start: pip install into .ample/python from requirements.txt, then waitress serving project.wsgi from run.py reading PORT on the python-3.12 template.

Prerequisites

Workflow Steps

  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.
  2. Read the build log
    The last lines name the failing command and its output.
    ample logs --kind build
  3. Read the runtime log
    For health_check_failed, the runtime log carries the Django process output.
    ample logs --kind runtime
  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.
  5. Verify
    Fetch the live URL on the example; on failure read the build and runtime logs.
    ample logs --kind build

Limitations

Cost Estimate

Evidence Summary

Success Checks