Health Check Patterns

⛔ DB-backed apps: a 200 on / is NOT healthy. When prepare-plan.json.services[] includes a database, probing only / (or any non-DB route) just proves the web server booted. Probe at least one data-backed route (derive from the app’s detected routes, e.g. a REST resource path) and inspect the body for DB errors (insecure transport, Access denied, connection refused, Unknown database, doesn't exist) → mark degraded, not healthy.

HTTP Redirect Handling (Container Apps)

⛔ ACA health probes do NOT follow HTTP redirects. A 301/302 response from the probe path causes ActivationFailed — the probe treats it as a failure, not a redirect.

If the first health check returns 301 or 302:

1. Read the Location header: curl -sI "https://{fqdn}{probePath}" | Select-String "^location:" -CaseSensitive:$false
2. Update probePath in Bicep to the redirect target (e.g., /wetty/ → /wetty)
3. Redeploy: az deployment sub create with updated Bicep
4. Re-check health after new revision activates

Common redirect patterns: Express trailing-slash normalization (/app/ → /app), framework-level path canonicalization, HTTPS redirects on mixed-content paths.

App Service Default Page Detection

⛔ HTTP 200 ≠ app started. Azure serves its own default page with 200 when the app fails to start — false positive.

After HTTP 200 from App Service, check first 2KB of body:

If detected → healthStatus: "degraded" + warning: "App Service default page detected — check logs: az webapp log tail -g {rg} -n {app}".

Non-HTTP Resources

Succeeded → healthy. Failed → degraded. Other → unknown.

⛔ Container Apps — run an explicit live HTTP probe (the pipeline status is NOT sufficient). After latestReadyRevisionName is set, run an observable request against the ingress FQDN and capture the result into deploy-result.json.endpoints[].healthStatus:

powershellCopy

iwr "https://{ingressFqdn}/{probePath}" -UseBasicParsing   # PowerShell
curl -sSfL "https://{ingressFqdn}/{probePath}"             # bash

This live HTTP call against *.azurecontainerapps.io IS the health verification — do NOT infer health from the revision’s internal status alone.

Output

Write to deploy-result.json.endpoints[]:

Overall healthStatus = worst status across all endpoints. If any unreachable → overall unreachable.

Functional Endpoint Verification

⛔ A 200 on / only proves the web server booted — not that the app works. After the HTTP check, confirm the app actually functions against the services the plan provisioned (database, cache, KV secrets), not just that it responds.

Health checks only confirm the web server is responding. Exercise a route that depends on the backing services — for example: