Compose depends_on service_healthy and Docker HEALTHCHECK: startup ordering versus application readiness

When a dependent service uses Compose depends_on long syntax with condition: service_healthy, startup is gated until the dependency's Docker HEALTHCHECK reports healthy. The goal is to decide whether that gating is sufficient for the dependent service to start successfully, or whether it only orders container creation and leaves an application-readiness gap.

The uncertainty is operational. A container can pass its configured probe while still failing to accept the dependent's traffic, because service_healthy reflects only the probe result, not a broader readiness contract. Behavior is also version-sensitive: Compose file format 3.x dropped depends_on conditions, while the Compose Specification used by docker compose reintroduced them and added service_completed_successfully. In addition, HEALTHCHECK timing flags such as start-period and retries change when a container becomes healthy, so the same file can produce different startup ordering across hosts or image changes.

Should the integration rely solely on Compose health gating, or should the dependent service include its own retry/backoff logic? Is there a documented boundary where service_healthy is intended to imply readiness for dependent services? How can teams verify that their chosen Compose schema enforces the intended condition without silently normalizing it?