# Diagnose Deployment Failures for Gin

## Summary
Deployment diagnostics for a Gin app on Ample. Verified on Gin: 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`, so the cause is read from the framework's output rather than guessed. Build and start: CGO_ENABLED=0 go build -o app ./... then ./app on the ubuntu-24.04 template (go.sum committed for a reproducible build).

## Workload
Diagnose deployment failures

## Prerequisites
- A Gin project (CGO_ENABLED=0 go build -o app ./... then ./app on the ubuntu-24.04 template (go.sum committed for a reproducible build))
- An Ample account token with servers:write

## Tested Configuration
- **Template**: ubuntu-24.04
- **Runtime**: go
- **Size**: s-1vcpu-1gb
- **Build**: CGO_ENABLED=0 go build -o app ./...
- **Start**: ./app

## 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 (a request handler or bootstrap failed); exit 2 means a required preflight action is blocking.

2. **Read the build log**  
   The last lines name the failing command and its output.  
   Command: `ample logs  --kind build`

3. **Read the runtime log**  
   For health_check_failed the runtime log carries the Gin 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.  
   Command: `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.  
   Command: `ample logs  --kind build`

## Success Checks
- Failed deploy reports health_check_failed synchronously  
  Expect: `ample deploy exits 1 with error.code health_check_failed`
- Runtime log carries the app's own error line  
  Expect: `ample logs  --kind runtime shows the framework's error output before the health-check verdict`

## Limitations
- Verified on the ubuntu-24.04 template at s-1vcpu-1gb; other sizes and Gin major versions are not verified.
- Region, compliance attestations and request-duration limits are unknown and not claimed.

## Cost Estimate
- **Currency**: USD
- **Monthly Amount**: 5.0
- **Note**: Always-on monthly price of the tested sizes; apps auto-pause when idle. Buckets are allocation-priced per quota and not included.

## Evidence Summary
- **Kind**: canary_run  
- **Summary**: Gin pattern fixture deployed on Ample with CANARY_FAIL=boot (CGO_ENABLED=0 go build -o app ./... then ./app on the ubuntu-24.04 template (go.sum committed for a reproducible build)); 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`, so the cause is read from the framework's output rather than guessed.
- **Observed At**: 2026-09-21T02:23:07Z