Troubleshooting playbook · Reviewed 2026-10-23
Docker production outage playbook
A containment-first path for a Docker service that is unhealthy, missing logs, failing after deploy, or unavailable to users.
When to use this
Use this for a running production incident. It aims to preserve evidence, restore a known-good service, and avoid destructive cleanup during an outage.
Protect data and access first
- Do not run broad prune or volume deletion commands during an active incident.
- Do not redeploy repeatedly without preserving the failing container logs, image digest, and compose configuration.
Before you change anything
- Record the affected service, time window, image tag or digest, and user impact.
- Confirm whether a prior known-good release exists.
- Keep production secrets out of copied logs and support notes.
Decision path
Contain and observe
Check service state, health status, recent events and logs without deleting containers or volumes.
Check: You have a timestamped symptom and failing component.
Compare with last known good
Compare image, environment variables, dependency availability and network configuration.
Check: A concrete difference is identified or ruled out.
Choose rollback or repair
Rollback to a verified release when impact is active; otherwise repair the smallest proven cause.
Check: Service health and a real request both recover.
Verify after recovery
Check logs, health checks and one representative user path before declaring the incident closed.
Check: The service stays healthy for an observed interval.
Stop and escalate when
- Data integrity is uncertain.
- A database migration may need reversal.
- Secrets, payments, or customer data may have been exposed.