## The short version

Deployment diagnostics for a Flask app on Ample.

### WHAT WAS VERIFIED

Verified on Flask: 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 <deployment_id> --kind runtime`, so 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 from app.py reading PORT on the python-3.12 template.

## INFRASTRUCTURE

### What it needs

- [Compute](/content/discover/primitive/compute/index.html): verified (Apps run in isolated x86_64 Firecracker microVMs; sizes are the priced VM sizes.)

## PREREQUISITES

### Before you start

- A Flask project (pip install into .ample/python from requirements.txt, then waitress from app.py reading PORT on the python-3.12 template)
- An Ample account token with servers:write

## STEP BY STEP

### 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.

2. 2

### Read the build log

The last lines name the failing command and its output.

```
   ample logs <deployment_id> --kind build
   ```

3. 3

### Read the runtime log

For health_check_failed the runtime log carries the Flask 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
   ```

4. 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. 5

### Verify

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

```
   ample logs <deployment_id> --kind build
   ```

## EXAMPLES

### Tested examples

- **Flask pattern fixture** (`tests/deploy-canaries/flask-patterns`): Verified deployment diagnostics on Flask.

## SUCCESS CHECKS

### How to know it worked

- failed deploy reports health_check_failed synchronously
- runtime log carries the app's own error line

## COST

### Cost estimate

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

- app server x1 `s-1vcpu-1gb`: 5.00 USD

Upper-bound monthly price of the tested sizes. Buckets are allocation-priced per quota and not included.

## EVIDENCE

### Verification evidence

- canary_run on 2026-09-21T02:23:07Z at revision `50dbac567d2c5cc8e55e6c748a646be0025d9cfb (CLI 0.1.21)`: Flask pattern fixture deployed on Ample with CANARY_FAIL=boot (pip install into .ample/python from requirements.txt, then waitress from app.py reading PORT on the python-3.12 template); 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 <deployment_id> --kind runtime`, so the cause is read from the framework's output rather than guessed. (expires 2027-03-20T02:23:07Z)

## EXECUTION

### Execution binding

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

## NEXT ACTIONS

### Typed next actions

- Browse the catalog index (`GET /v1/catalog` on the api origin; authentication not required, approval not required)
- Search published recipes by intent, stack and constraints (`POST /v1/catalog/search` on the api origin; authentication not required, approval not required)
- Prepare a side-effect-free deployment plan for an authorized project (`POST /v1/catalog/plan` on the api origin; authentication required, approval not required)
- Read the existing agent authentication setup (`GET /mcp/setup` on the api origin; authentication not required, approval not required)
- Browse Flask (`GET /v1/catalog/nodes/stack%3Aframework-flask` on the api origin; authentication not required, approval not required)
- Browse Troubleshoot deployment (`GET /v1/catalog/nodes/intent%3Atroubleshoot-deployment` on the api origin; authentication not required, approval not required)
- Browse Public web service (`GET /v1/catalog/nodes/pattern%3Apublic-web-service` on the api origin; authentication not required, approval not required)

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.

## ABOUT THIS RECIPE

### Identifiers and status

Recipe `page:guides:flask:deployment-diagnostics`. Revision r1.

release **published** support **verified** execution **unbound**

Formats: [HTML](/content/guides/flask/deployment-diagnostics/index.html) | [Markdown](/content/guides/flask/deployment-diagnostics.md) | [JSON contract](https://api.ample.computer/v1/catalog/recipes/page%3Aguides%3Aflask%3Adeployment-diagnostics)