Docker Compose check · low
depends_on alone makes Compose start a service after its dependency's container has started, not after it is ready to accept connections. Without a healthcheck on the dependency, Compose has no way to know when it is ready. The explainer flags, as low, any service that others depend on but that has no healthcheck. Add one and use condition: service_healthy.
$ explain docker-compose.yml ! cache has no healthcheck line 9 fix: see below $
What the free Docker Compose explainer reports on the risky example below.
A database container counts as started as soon as its process launches, often seconds before it accepts connections. Dependents that connect right away fail, and depending on the restart policy they crash-loop or stay down.
Teams often work around this with sleeps or retry scripts in the entrypoint, which hide the problem rather than describe it.
A healthcheck also gives `docker compose ps` and monitoring a real readiness signal, not just whether the process exists.
services:
api:
image: example/api:2.3.0
depends_on:
- cache
restart: unless-stopped
mem_limit: 512m
cache:
image: redis:7.4.1
restart: unless-stopped
mem_limit: 512m
services:
api:
image: example/api:2.3.0
depends_on:
cache:
condition: service_healthy
restart: unless-stopped
mem_limit: 512m
cache:
image: redis:7.4.1
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 5s
timeout: 3s
retries: 5
restart: unless-stopped
mem_limit: 512m
The risky example is loaded below. Paste your own file to check it for this and every other Docker Compose rule. It runs in your browser; nothing is uploaded.
Parsed in your browser. Nothing is uploaded.
2 services defined: api, cache.
Runs the image example/api:2.3.0.
This service starts after: cache (waits only until it has started, not until it is ready).
Restarts if it stops or after a daemon restart (unless-stopped), but stays down if you stopped it manually.
Limits memory to 512m. The container is killed if it exceeds this.
Runs the image redis:7.4.1.
Restarts if it stops or after a daemon restart (unless-stopped), but stays down if you stopped it manually.
Limits memory to 512m. The container is killed if it exceeds this.
Not by default. It waits for the container to start. To wait for readiness, give the database a healthcheck and use condition: service_healthy.
Add a healthcheck to the Postgres service that runs pg_isready, then set depends_on with condition: service_healthy on the services that use it.
No. It only flags services that another service lists in depends_on, because that is where a missing readiness signal causes start-up failures.