# Diagnose deployment failures for Spring Boot

Deployment diagnostics for a Spring Boot app on Ample. Verified on Spring Boot: 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:

```bash
./mvnw -q -DskipTests package  # (or the Gradle wrapper)
java -jar on the jvm-21 template (Temurin JDK 21) with server.port read from PORT.
```

## Representative Queries
- Diagnose deployment failures for Spring Boot
- Where can I host Diagnose deployment failures built with Spring Boot?
- I need framework-specific failure signatures and validation checks using only actual available observability interfaces.

## Prerequisites
- A Spring Boot project (./mvnw -q -DskipTests package (or the Gradle wrapper) producing one application jar, then java -jar on the jvm-21 template (Temurin JDK 21) with server.port read from PORT)
- An Ample account token with servers:write

## 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 Spring Boot 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`

## Examples
- **Spring Boot pattern fixture**  
  Verified deployment diagnostics on Spring Boot.  Source Ref: `tests/deploy-canaries/spring-boot-patterns`

## 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 jvm-21 template at s-1vcpu-2gb; other sizes and Spring Boot 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  
  - Basis: size prices from pricing.toml (loaded by the API) at build revision 1ac5595375130d45290090e82ed0f554ccd45405-dirty  
  - Components:  
    - Name: app server  
      Size: s-1vcpu-1gb  
      Quantity: 1.0  
      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
- **Canary Run**  
  Summary: Spring Boot pattern fixture deployed on Ample with CANARY_FAIL=boot. The deliberate boot failure's error line was readable from the framework's output rather than guessed.  Observed At: 2026-09-21T02:23:07Z

## Formats
- [HTML Documentation](/content/guides/spring-boot/deployment-diagnostics/index.html)  
- [Markdown Documentation](/content/guides/spring-boot/deployment-diagnostics.md)  
- [JSON Documentation](https://api.ample.computer/v1/catalog/recipes/page%3Aguides%3Aspring-boot%3Adeployment-diagnostics)

## Next Actions
- **Browse the catalog index** - GET `/v1/catalog`
- **Search published recipes by intent, stack, and constraints** - POST `/v1/catalog/search`
- **Prepare a side-effect-free deployment plan for an authorized project** - POST `/v1/catalog/plan`