Medium10 minContainerization
UpdatedAug 2, 2026
Edit

Docker Health Checks

CONCEPTS:Docker Health Checks

Question Variations

  • "How do you implement a health check in a Dockerfile?"
  • "What is the difference between an application being 'alive' and being 'ready'?"
  • "How does Docker Compose react when a container's health check fails?"
  • "What are the performance considerations when choosing a health check command (e.g., `curl` vs. a custom script)?"

Why This Is Asked

Interviewers want to see if you build “self-healing” systems. Knowing how to implement health checks is the difference between a system that fails silently and one that automatically recovers from internal application errors.

Key Concepts

  • Liveness vs. Readiness: While Docker only has one HEALTHCHECK, understanding the difference (is the process alive vs. is it ready to serve traffic) is key.
  • Exit Codes: How Docker uses the exit code of the health check command (0 for success, 1 for failure).
  • Orchestration Integration: How health status affects container lifecycle in Compose or Swarm.
  • Overhead: Ensuring the health check command doesn’t consume too many resources.

Question Variations

  • “How do you implement a health check in a Dockerfile?”
  • “What is the difference between an application being ‘alive’ and being ‘ready’?”
  • “How does Docker Compose react when a container’s health check fails?”
  • “What are the performance considerations when choosing a health check command (e.g., curl vs. a custom script)?”

Answers by Technology

+ Add Variant
DockerImprove this answer ✏️

Expected Answer

A Health Check is a command that runs inside a container to verify that the application is functioning correctly. Unlike the container’s status (which only checks if the PID is alive), a health check can detect if an app is deadlocked, can’t connect to the database, or is stuck in an infinite loop.

You define it in a Dockerfile using the HEALTHCHECK instruction. It executes a command; if the command returns exit code 0, the container is healthy. If it returns 1, it is unhealthy.

Why It Matters

In a production environment, you don’t want to send traffic to a container that is technically “running” but not actually working. Orchestrators use this status to:

  1. Restart unhealthy containers.
  2. Delay service startup until the container is ready.
  3. Stop routing load balancer traffic to an unhealthy instance.

Example Code

Dockerfile Health Check

FROM nginx:alpine

# Check if the Nginx welcome page is accessible every 30s
HEALTHCHECK --interval=30s --timeout=30s --start-period=5s --retries=3 
  CMD curl -f http://localhost/ || exit 1

Docker Compose Health Check

services:
  web:
    image: my-app:latest
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 1m30s
      timeout: 10s
      retries: 3
      start_period: 40s

Common Mistakes

  • Not having curl or wget in the image: If you use a minimal image like Alpine or Distroless, the curl command might not exist, causing the health check to always fail.
  • Too frequent checks: Running an expensive health check every second can put unnecessary load on your application.
  • Ignoring start-period: If your app takes 30 seconds to boot but you start checking after 5 seconds, the container will be marked unhealthy before it even has a chance to start.

Follow-up Questions

  • What happens to an unhealthy container in Docker Compose? (Answer: By default, Compose doesn’t restart it unless you use a restart policy, but other services using depends_on with a service_healthy condition will wait for it).
  • Can you disable a health check defined in a base image? (Answer: Yes, by using HEALTHCHECK NONE).
  • Where can you see the output of a failed health check? (Answer: By running docker inspect <container_id>; look for the Health section).

References