Health Checks in Docker Compose: Startup Order and Self-Healing

Effective health checks in Docker Compose are crucial for ensuring your applications run smoothly. Health checks should reflect real readiness, not just whether a process is running. Docker can determine if a process is alive, but it cannot assess if it works. Health checks address this gap by running a command inside the container at regular intervals, returning a healthy or unhealthy status.

A good health check has a start period, which is often overlooked. The start period allows slow-booting apps to avoid being marked as unhealthy during normal startup. For the CMD-SHELL variant, you can use a fallback that works with slim images. An example is `curl -fsS URL || wget -q --spider URL`.

Key parameters include the interval (how often to probe), timeout (how long one probe may take), and retries (consecutive failures before marking unhealthy). The `start_period` gives a grace window at boot, during which failure counts are ignored.

The check should verify that the app can serve requests, ensuring the process is responsive and critical dependencies are reachable. Instead of checking for existence, ready the readiness of the endpoint. For databases and infrastructure, use purpose-built tools like `pg_isready` for PostgreSQL, `mysqladmin ping` for MySQL, and `redis-cli ping` for Redis.

Health checks should gate startup ordering. Relying solely on `depends_on` is insufficient because it only ensures containers start in the correct order, not that they're ready to accept connections. Use `condition: service_healthy` to wait for actual readiness and prevent race conditions where apps may crash if they connect during a brief window.

Operationally, health checks enable zero-downtime deploys, as the platform only switches traffic to a new container after its health check passes. If a release is bad, it aborts instead of going live. Health checks also facilitate self-healing by using them in conjunction with restart policies, allowing the platform or a monitor to replace a wedged-but-running container, thus preventing hours of errors for users.

In summary, defining a healthcheck on every service that has dependents or serves traffic is a simple yet powerful habit that significantly enhances the reliability of your applications.