Liveness vs Readiness Probes in Kubernetes, Explained

A liveness probe tells Kubernetes when to restart a container because it’s stuck or deadlocked; a readiness probe tells it when a container is temporarily unable to serve traffic and should be pulled from load balancing without being restarted. They look similar in a pod spec — same probe types, same YAML shape — but they answer different questions, and mixing them up is one of the more common ways teams cause self-inflicted outages in Kubernetes.

What each probe actually controls

Kubernetes runs both probes on a schedule against each container, but the failure response is different:

• Liveness probe failure → the kubelet kills the container and restarts it, following the pod’s restart policy. This assumes the only fix for a broken container is a fresh process.
• Readiness probe failure → the pod is removed from the Service’s list of endpoints. Traffic stops being routed to it, but the container keeps running untouched. Once the probe passes again, it’s added back.

That distinction matters because the two failure modes call for opposite remedies. A container that’s deadlocked or stuck in an infinite loop needs a restart — that’s liveness. A container that’s temporarily overloaded, warming a cache, or waiting on a slow downstream dependency doesn’t need to be killed; it needs a moment out of the traffic rotation — that’s readiness.

Why a failing liveness probe on a slow dependency is dangerous

The most common misconfiguration is pointing a liveness probe at a check that depends on something external — a database connection, a downstream API, a cache warm-up. If that dependency degrades, every replica’s liveness probe starts failing simultaneously, and Kubernetes restarts all of them at once. The dependency is still down, so the new containers fail their liveness checks too, and you get a crash-restart loop across the entire deployment — turning a downstream slowdown into a full outage of a service that was otherwise fine.

The fix is to keep liveness probes narrow: they should only check that the process itself is alive and responsive, not that every downstream system it talks to is healthy. Readiness probes are the right place to check dependencies, because a readiness failure just pauses traffic to that one pod rather than restarting it.

Comparing the two

	Liveness probe	Readiness probe
Failure response	Restart the container	Remove pod from Service endpoints
Answers the question	Is this process stuck and needs a restart?	Can this pod handle traffic right now?
Good checks	Process responsiveness, deadlock detection	Dependency health, cache warm-up, connection pool status
Risky checks	Downstream dependencies, database connectivity	N/A — this is exactly what readiness is for
Runs during startup	Yes, after initialDelaySeconds (or gated by a startup probe)	Yes, continuously

A third option: startup probes

Kubernetes also supports a startup probe, added specifically to handle slow-starting containers — think a JVM application with a long class-loading phase, or a service that needs to rebuild an in-memory index before it’s useful. While a startup probe is configured, the liveness and readiness probes are disabled; only once the startup probe succeeds do the other two take over. This avoids the awkward tradeoff of setting a long initialDelaySeconds on the liveness probe (which slows down detecting a genuinely stuck container after startup) just to accommodate a slow boot.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5

Note the different paths: /healthz for liveness is typically a cheap, dependency-free check; /ready for readiness can afford to check connection pools, feature-flag fetches, or cache state, because failing it only pauses traffic rather than triggering a restart.

Configuring thresholds sensibly

A few settings determine how forgiving each probe is:

• initialDelaySeconds — how long to wait before the first probe. Set high enough that a normal, healthy startup doesn’t trip a false failure.
• periodSeconds — how often the probe runs.
• failureThreshold — how many consecutive failures before acting. A single slow response shouldn’t restart a container; a threshold of 3 or so absorbs transient blips.
• timeoutSeconds — how long the probe waits for a response before counting it as a failure.

Getting these too aggressive (short delays, low failure thresholds) makes a service brittle under normal load variance; too lax, and a genuinely stuck container stays in rotation or unrestarted for longer than necessary. This is the same tuning tension covered in our piece on SLAs, SLOs, and SLIs — the probe thresholds are effectively an internal SLO for “how long can this pod be unhealthy before we act.”

How this connects to rollouts and load balancing

Readiness probes are also what make rolling and blue-green deployments safe: a new pod’s traffic doesn’t start until its readiness probe passes, which prevents a deploy from sending live requests to a container that hasn’t finished initializing. Combined with a load balancer or the Service abstraction routing only to ready endpoints, this is what lets Kubernetes roll out changes without a visible dip in availability, as long as the readiness check accurately reflects when the pod is actually ready to serve.

The takeaway

Liveness probes exist to catch a genuinely stuck process and restart it; readiness probes exist to pull a temporarily unable pod out of traffic without touching it. Keep liveness checks narrow and dependency-free to avoid cascading restart loops, push dependency and warm-up checks into readiness, and use a startup probe for anything with a slow boot — get that split right and Kubernetes handles the rest of the self-healing and rollout safety on its own.