Check type

Health endpoint URL

Interval

How often to check

Timeout

Max time per check

Retries

Failures before unhealthy

Start period

Startup grace period

Dockerfile

HEALTHCHECK \
  --interval=30s \
  --timeout=10s \
  --retries=3 \
  --start-period=40s \
  CMD curl -f http://localhost:3000/health || exit 1

docker-compose.yml

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 is an instruction that tells the Docker daemon how to verify that a container is still functioning correctly. It runs a command inside the container at a configurable interval, and if the command fails consecutively beyond the retry threshold, Docker marks the container as unhealthy. Orchestrators like Docker Swarm and Kubernetes can then automatically restart or replace unhealthy containers. Without a healthcheck, Docker only knows whether a process is running — not whether it is actually serving requests correctly.

How to Use

Select the check type: HTTP (curl to an endpoint), TCP (netcat to a port), Redis (PING/PONG), or a custom shell command
Enter the target URL, host:port, or command that proves the service is healthy
Configure interval (how often to check), timeout (max time per check), retries (consecutive failures before unhealthy), and start-period (grace period on startup)
Copy the Dockerfile HEALTHCHECK instruction or the docker-compose healthcheck block
Paste into your Dockerfile after the CMD/ENTRYPOINT, or into your docker-compose.yml under the service definition

Why Use This Tool?

Generates 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 (PING)

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 is considered failed (default 30s). Start-period: grace period after container start during which failures do not 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.

When should I NOT use Docker HEALTHCHECK?

Do not use HEALTHCHECK for services that are inherently short-lived (one-shot tasks, batch jobs) or for containers that run to completion. Also, Kubernetes ignores Docker HEALTHCHECK — it uses its own liveness and readiness probes defined in the Pod spec with different YAML syntax.

Is my configuration data private when using this tool?

Yes. All generation happens entirely in your browser. Your healthcheck URLs, hostnames, and commands are never sent to any server, logged, or stored.

Can I use HEALTHCHECK with 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.

Real-world Examples

Healthcheck for a Node.js API server

A Node.js Express app exposes a /health endpoint that returns 200 when the server is ready to accept requests.

Input

Type: HTTP | URL: http://localhost:3000/health | Interval: 30s | Timeout: 10s | Retries: 3 | Start: 40s

Output

HEALTHCHECK --interval=30s --timeout=10s --retries=3 --start-period=40s \
  CMD curl -f http://localhost:3000/health || exit 1

Healthcheck for PostgreSQL in docker-compose

A PostgreSQL container uses pg_isready to verify the database is accepting connections before dependent services start.