A health check evaluates whether an application, service, or container is functioning acceptably. In a multi-container system, it provides a status signal instead of treating every running process as fully usable. A container may be starting, healthy, or unhealthy; an application endpoint can check its own services and connections more selectively. section 3.2.2 section 3.8
Health checks matter because a container can remain running while its application is failing. An unhealthy result can point to faulty application code, networking trouble, or a problematic component update. Docker and Docker Compose can restart containers, while a production monitoring setup can log failures and notify operators. Orchestrators can also use status checks to alert administrators or restart containers. section 3.8 section 3.2.2
Use health checks at two related levels:
- Application level: expose an endpoint that reports system or application status. Make it as broad or fine-grained as needed, including checks of dependent services or connections. section 3.8
- Container level: define a Docker health check that runs a command and marks the container starting, healthy, or unhealthy. section 3.8
- Environment level: inspect container statuses alongside API availability. A healthy database does not establish that containers without checks, or the API itself, are healthy. section 7.5.2
Checking a PostgreSQL container
A PostgreSQL health check can run pg_isready with the configured database user. Docker runs the command every 30 seconds, allows a 3-second timeout, waits through a 10-second start period, and retries three times. After rebuilding and starting the containers, docker ps --format '{{.Names}} - {{.Status}}' can show the Postgres container as healthy. section 3.8
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
CMD pg_isready -U ${POSTGRES_USER} || exit 1
This Dockerfile instruction shows the check command and the timing, startup, timeout, and retry settings that control its evaluation. section 3.8
Start with a meaningful but simple check, then expand it as the system gains dependencies. A database table named health_check may help test connectivity or state, but it is only a starting point; the Docker check itself needs a command that verifies the container’s intended service. Pair status monitoring with API checks when users depend on application endpoints. section 3.2.2 section 7.5.2
