Health and logs
Check service status, probes, dependencies, one-shot jobs, and logs.
Start with Compose state, then distinguish container status, dependency reachability, and end-to-end feature behavior.
Access
Host Docker access is required. Prepare to redact URLs, credentials, signed links, cookies, personal data, and content before sharing output.
Inspect state
docker compose -f docker-compose.prod.yaml ps -a
docker compose -f docker-compose.prod.yaml logs --tail=200 migrate minio-setup
docker compose -f docker-compose.prod.yaml logs --tail=200The first log command checks the one-shot tasks. Use the broad log command locally, then narrow to the relevant Compose service or time range without copying secrets into a ticket.
Know what each check proves
| Component | Available check | What it does not prove |
|---|---|---|
| Migration | One-shot exits 0 | Application features work |
| Object setup | Logs plus an unauthenticated test GET | Exit 0 alone does not prove bucket or policy setup succeeded |
| Postgres | Declared readiness check | Queries beyond server/database readiness work |
| Redis | Declared authenticated PONG check | Worker progress, cache invalidation, or queue replay works |
| Core API | Compose /health runs select 1 |
Redis, object storage, uploads, auth, or Worker works |
| Delivery API | Compose /health runs select 1 |
Redis cache/invalidation or content delivery works |
| Admin app | Compose / gets an HTTP response |
Sign-in, SSR authorization, Core calls, or Delivery calls work |
| Worker | Starts after Core API is healthy | Use a non-sensitive upload and inspect processing |
| Object storage | No declared health check | Test bucket policy and an original-object request |
| Image service | No declared health check | Test one signed transform |
Core API and Delivery API both declare database-backed Compose health checks. Worker waits for Core API health before it starts. Delivery API can still start without waiting for Redis health and may report healthy while cache or invalidation is failing.
Probe the database-backed and HTTP-only public routes:
curl -fsS "$CORE_API_PUBLIC_URL/health"
curl -fsS "$DELIVERY_API_PUBLIC_URL/health"
curl -fsS "$ADMIN_APP_PUBLIC_URL/" > /dev/nullThen test the feature that failed. For a deployment smoke test, cover sign-in, a safe Draft write, published delivery, a non-sensitive upload, Worker metadata completion, public original download, and a signed image transform.
After correcting configuration, recreate only affected consumers and repeat the original reproduction plus its dependent checks. If the regression remains, restore the last coherent configuration or release; preserve all named volumes.
The production drill required migration and object setup to exit 0, every declared service check to become healthy, no unexpected startup errors, exact Published parity through REST/Context MCP, and a public original-object read. The stack still ships no log aggregation, retention, alerts, Worker liveness, object readiness, image readiness, or end-to-end synthetic monitor.