Post Deploy Verification

Post-Deploy Verification

Run these checks in order after a deployment completes. Report all results — do not stop at the first failure.

Step 1: Container is running

• list_containers to find the app's container
• Verify status is running (not exited, restarting, created)
• If container is missing or exited, skip remaining steps — the deployment failed at container level

Step 2: No restart loop

• container_inspect → check restart_count
• If restart_count > 0 within 60 seconds of deployment: container is crash-looping
• Check oom_killed — if true, the container exceeded its memory limit

Step 3: Port alignment

Four values must agree:

If any disagree, the app will be unreachable even though the container is running.

Step 4: Internal reachability

• container_exec ["curl", "-s", "-o", "/dev/null", "-w", "%{http_code}", "localhost:PORT"]
• Expect 200, 301, or 302
• If connection refused: app hasn't started listening yet (may need to wait) or wrong port
• If timeout: app is hanging during startup

Step 5: External reachability

• http_probe the public URL
• Expect 200 (or 301/302 for SPAs with redirect)
• If internal works but external fails: proxy/DNS/TLS issue — defer to domain-tls-routing

Step 6: Healthcheck endpoint

If the app has a healthcheck endpoint (/health, /healthz, /api/health, /ready):

• container_exec ["curl", "-s", "localhost:PORT/health"]
• Parse response: look for "status": "ok" or "healthy" or HTTP 200
• If unhealthy: the app started but a dependency (database, cache, external service) is down

Step 7: Log scan

• get_container_logs — last 50 lines
• Scan for error patterns:

• No errors in first 50 lines after startup = healthy

Step 8: Compose services (if applicable)

For docker-compose deployments:

• get_compose_services to list all services
• Run steps 1-7 for each service independently
• Verify service-to-service connectivity: primary app can reach its database/cache

Result format

Healthy: All checks PASS (or WARN/N/A for optional checks). Unhealthy: Any FAIL — report the first failing check as the likely root cause.

Related Skills

• failure-diagnosis — If verification fails, use failure diagnosis for deeper investigation
• domain-tls-routing — If internal reachability passes but external fails