Require Compose dependency health when startup order is insufficient

A running database container may still be unable to serve the application starting after it.

Source facts

Docker Compose normally waits for a dependency to be running, not ready. A depends_on condition of service_healthy waits for its healthcheck, while service_completed_successfully supports a dependency expected to finish. Docker also documents restart propagation for explicit Compose operations when configured, which is distinct from ordinary process failure handling.

Source: Docker documentation — Control startup and shutdown order in Compose.

Applicability

Review startup conditions and explicit-operation restart propagation in a Compose dependency chain.

DSE recommendation

DSE recommends defining the dependency’s usable state before choosing a startup condition. Keep health checks narrow enough to diagnose the dependency and relevant enough to avoid a false ready signal. Applications should still handle later connection loss instead of assuming startup order eliminates runtime outages. Document whether a dependency is a continuing service or a one-time preparation task. Keep restart propagation expectations explicit so an operator does not assume every database process restart will automatically restart all dependents.

Verification

In a nonproduction stack, delay the dependency’s readiness and observe when the application is created or started. Exercise a failed healthcheck and a completed initialization task separately. After startup, interrupt a safe dependency connection and confirm the application’s own retry or recovery behavior remains appropriate. Retain the dependency condition, healthcheck definition and lifecycle timestamps. Ask the application owner to approve the exact readiness signal and the observed connection-recovery result instead of accepting container creation order alone.

Official reference

Docker documentation — Control startup and shutdown order in Compose. Reviewed October 20, 2026.