juniorKubernetes

What are liveness and readiness probes and how do they differ?

Updated Feb 20, 2026

Short answer

A readiness probe decides whether a pod should receive traffic; a liveness probe decides whether it should be killed and restarted. Failing readiness removes the pod from service endpoints but leaves it running; failing liveness restarts the container. Confusing the two is a common cause of outages, because a liveness probe that fails under load restarts healthy pods and makes the problem worse.

Deep explanation

ReadinessLivenessStartup
On failureremoved from endpointscontainer restartedcontainer restarted
Purpose"can I serve traffic now?""am I unrecoverably stuck?""have I finished booting?"
Recovers by itselfyes, when it passes againno, only via restartn/a
YAML
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
  failureThreshold: 3          # out of rotation after ~15s


livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3          # restarted after ~30s
  timeoutSeconds: 5


startupProbe:                  # protects slow starters from liveness
  httpGet: { path: /healthz, port: 8080 }
  failureThreshold: 30
  periodSeconds: 10            # up to 5 minutes to boot

The endpoints they check must differ. This is the mistake that causes cascading failure: if /healthz checks the database, then a brief database outage fails liveness on every pod simultaneously. Kubernetes restarts them all, they come back, still cannot reach the database, and restart again — turning a recoverable dependency blip into a full outage with CrashLoopBackOff.

The rule: *liveness should check only whether this process is irrecoverably stuck* — a deadlock, an exhausted event loop. It should not check dependencies. Readiness may check dependencies, because being removed from rotation is a safe, reversible response.

The startup probe exists because slow-booting applications otherwise need a long initialDelaySeconds on liveness, which then delays detection of genuine hangs for the container's whole life. A startup probe suspends liveness and readiness until it first succeeds, so you can allow five minutes to boot and still detect a hang within thirty seconds afterwards.

Readiness is also what makes rolling updates safe. During a rollout Kubernetes waits for a new pod to be Ready before terminating an old one. Without a meaningful readiness probe, traffic reaches pods that are still warming caches or opening connection pools, producing a burst of errors on every deploy.

Real-world example

A service that must drain gracefully during deploys:

Go
// readiness: flips false the moment SIGTERM arrives
http.HandleFunc("/ready", func(w http.ResponseWriter, r *http.Request) {
    if shuttingDown.Load() || !dbPool.Healthy() {
        w.WriteHeader(503); return          // out of rotation, NOT restarted
    }
    w.WriteHeader(200)
})


// liveness: only reports this process being stuck — no dependency checks
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    if time.Since(lastLoopTick.Load()) > 60*time.Second {
        w.WriteHeader(503); return          // event loop wedged -> restart me
    }
    w.WriteHeader(200)
})

On SIGTERM, readiness fails immediately so the pod leaves the load balancer, while in-flight requests finish. Liveness keeps passing throughout, so Kubernetes does not kill it mid-drain.

Common mistakes

  • - Pointing liveness at an endpoint that checks the database, so a dependency outage restarts every pod at once and escalates it into a full outage.
  • - Using the same endpoint for both probes, which inherits the above problem by construction.
  • - Setting `timeoutSeconds` too low, so probes fail under load exactly when the service is busiest and most needs to stay up.
  • - Omitting a readiness probe, so rolling updates send traffic to pods that are not yet warmed up.
  • - Using a long `initialDelaySeconds` on liveness instead of a startup probe, delaying hang detection for the container's entire life.
  • - Forgetting to fail readiness on SIGTERM, so the pod keeps receiving requests while it is shutting down.

Follow-up questions

  • Why shouldn't a liveness probe check external dependencies?
  • What problem does the startup probe solve?
  • How do readiness probes make rolling updates safe?
  • What is CrashLoopBackOff and how do probes cause it?

More Kubernetes interview questions

View all →