Liveness, Readiness, and Startup Probes — Without the Hand-Waving

Kubernetes gives you three health probes that look almost identical in YAML and behave nothing alike at runtime. Confusing them is how you end up with a healthy app stuck in a restart loop.

The one-line difference

• Liveness — “is this container broken?” Failing it restarts the pod.
• Readiness — “can this container serve traffic right now?” Failing it removes the pod from the Service, but does not restart it.
• Startup — “has this container finished booting?” It gates the other two until the app is up.

Why the distinction matters

Using a liveness probe where you needed a readiness probe is the classic outage-maker: a slow dependency makes the app briefly unable to serve, the liveness probe fails, Kubernetes restarts it, and the restart makes things worse.

readinessProbe:
  httpGet:
    path: /healthz/ready
    port: 8080
  periodSeconds: 5
livenessProbe:
  httpGet:
    path: /healthz/live
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

Keep the two endpoints separate. /ready can check downstream dependencies; /live should only report whether the process itself is deadlocked — never its dependencies.

Startup probes buy slow apps time

For a JVM app that takes 40 seconds to warm up, a startup probe prevents the liveness probe from killing it mid-boot:

startupProbe:
  httpGet:
    path: /healthz/live
    port: 8080
  failureThreshold: 30
  periodSeconds: 2

That’s up to 60 seconds to start, after which the normal probes take over.

The rule of thumb

If failing the check should restart the container, it’s liveness. If it should just stop traffic, it’s readiness. When in doubt, prefer readiness — it fails safe.