Introduction

HEALTHCHECK and Kubernetes probes solve related but different problems. Docker HEALTHCHECK lets the container runtime mark a container as healthy or unhealthy. Kubernetes probes decide whether a Pod should receive traffic or be restarted. If you are running in Kubernetes, the probes in the Pod spec are usually the ones that actually matter operationally.

What Docker HEALTHCHECK Does

A HEALTHCHECK is defined in the image or container configuration.

HEALTHCHECK --interval=30s --timeout=3s --retries=3   CMD curl -f http://localhost:8080/health || exit 1

Docker then records whether the container is healthy, starting, or unhealthy.

This is useful in environments such as:

• plain docker run
• Docker Compose
• local development
• tooling that reads container health state directly

It is image-level metadata and runtime behavior inside the Docker ecosystem.

What Kubernetes livenessProbe Does

A livenessProbe answers this question:

"Should Kubernetes restart this container because it appears broken?"

1livenessProbe:
2  httpGet:
3    path: /health/live
4    port: 8080
5  initialDelaySeconds: 10
6  periodSeconds: 10

If the liveness probe fails repeatedly, Kubernetes restarts the container.

What Kubernetes readinessProbe Does

A readinessProbe answers a different question:

"Is this container ready to receive traffic right now?"

1readinessProbe:
2  httpGet:
3    path: /health/ready
4    port: 8080
5  initialDelaySeconds: 5
6  periodSeconds: 5

If readiness fails, the Pod stays running but is removed from Service endpoints until it becomes ready again.

That distinction is critical. Readiness affects traffic. Liveness affects restart behavior.

Why Kubernetes Probes Are Usually Preferred in Kubernetes

Even if your image has a Docker HEALTHCHECK, Kubernetes does not treat that as a substitute for explicit probe definitions. In practice, if the workload runs in Kubernetes, you should define the health behavior in the Pod spec where orchestration policy belongs.

That keeps deployment-specific health rules close to the deployment itself.

Add startupProbe for Slow Booting Apps

There is also a related Kubernetes probe worth knowing about: startupProbe.

Use it when the application takes a long time to initialize and you do not want liveness checks to kill it prematurely.

1startupProbe:
2  httpGet:
3    path: /health/startup
4    port: 8080
5  periodSeconds: 5
6  failureThreshold: 30

This is often a better fix than stretching liveness timings excessively.

Practical Guidance

Use Docker HEALTHCHECK when:

• the container is mainly run with Docker tools
• you want image-local health metadata
• you are working outside Kubernetes

Use readinessProbe when:

• the app may be alive but temporarily unable to serve requests
• you want safe rollout and traffic gating

Use livenessProbe when:

• the app can get stuck in a bad state and should be restarted automatically

In Kubernetes, readiness and liveness are usually more important than Docker image health state.

Common Pitfalls

A common mistake is using the same endpoint for readiness and liveness without thinking about the consequences. A dependency outage might mean "stop sending traffic" but not necessarily "restart the process."

Another mistake is relying on Docker HEALTHCHECK alone in Kubernetes. Kubernetes probe behavior should be defined explicitly.

Developers also often use liveness probes too aggressively and create restart loops for applications that are merely slow to start. startupProbe is often the correct fix there.

Summary

• Docker HEALTHCHECK marks container health inside Docker tooling.
• Kubernetes readinessProbe controls whether traffic should be sent to the Pod.
• Kubernetes livenessProbe controls whether the container should be restarted.
• In Kubernetes, define health behavior with Pod probes, not only with image metadata.
• Use startupProbe for slow-starting applications so liveness does not fire too early.