Docker Healthcheck Generator

Build HEALTHCHECK commands for Dockerfile and docker-compose

How often to check

Max time per check

Failures before unhealthy

Startup grace period

HEALTHCHECK \
  --interval=30s \
  --timeout=10s \
  --retries=3 \
  --start-period=40s \
  CMD curl -f http://localhost:3000/health || exit 1
healthcheck:
  test: ["CMD-SHELL", "curl -f http://localhost:3000/health || exit 1"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 40s

Generated command

curl -f http://localhost:3000/health || exit 1

What is Docker Healthcheck Generator?

Docker HEALTHCHECK tells the Docker daemon how to test a container to check that it is still working. It runs a command inside the container at a configurable interval. If the check fails enough times in a row, the container is marked as "unhealthy" and can be restarted by orchestrators like Docker Swarm or Kubernetes.

How to Use

  1. Select the check type: HTTP (curl), TCP (netcat), Redis (redis-cli ping), or a custom command.
  2. Enter the endpoint or host/port to check.
  3. Configure interval (how often to check), timeout (max time per check), retries (failures before unhealthy), and start-period (grace period on startup).
  4. Copy the Dockerfile HEALTHCHECK instruction or docker-compose healthcheck block.
  5. Paste into your Dockerfile or docker-compose.yml.

Why Use This Tool?

Generate correct HEALTHCHECK syntax without memorizing Docker documentation
Produces both Dockerfile and docker-compose.yml formats simultaneously
Presets for common services: web apps (HTTP), databases (TCP), Redis
Start-period prevents false positives during container startup
All generation happens in your browser — no server calls

Tips & Best Practices

  • Set start-period to at least as long as your app takes to boot (e.g. 40s for a Spring Boot app)
  • Keep timeout shorter than interval to avoid overlapping checks
  • HTTP checks: use a dedicated /health endpoint that returns 200, not the app root
  • TCP checks only verify the port is open, not that the service is actually healthy
  • Use retries=3 as a starting point; reduce to 1-2 for faster failure detection

Frequently Asked Questions

What is the difference between interval, timeout, and start-period?

interval: how often Docker runs the check (default 30s). timeout: maximum time the check command can take before it's considered failed (default 30s). start-period: grace period after container start during which failures don't count toward retries (default 0s). retries: how many consecutive failures mark the container unhealthy (default 3).

How do I check health in docker-compose depends_on?

Use "condition: service_healthy" in depends_on. Example: depends_on: { db: { condition: service_healthy } }. This makes Docker Compose wait until the dependency container's HEALTHCHECK passes before starting the dependent service.

Why use --start-period instead of retries for startup?

Without start-period, failures during startup count toward the retries limit. If your app takes 30 seconds to start and the interval is 10s with retries=3, the container becomes unhealthy before it even finishes starting. start-period delays the retry countdown until the container is expected to be fully running.

Can I use HEALTHCHECK in Kubernetes?

Kubernetes uses its own liveness and readiness probes defined in the Pod spec — it does not read Docker HEALTHCHECK instructions. The logic is the same (HTTP/TCP checks, intervals, timeouts), but the YAML syntax is different. For Kubernetes, define livenessProbe and readinessProbe in your Deployment manifest instead.

Related Tools