Kubernetes readiness probe failures pull Pods from traffic, not restart containers

A dev.to article takes aim at one of the most persistent misunderstandings in Kubernetes operations: the assumption that a failing readiness probe triggers a container restart. According to the piece, readiness has nothing to do with restarts. Its purpose is to govern whether a Pod takes traffic from Services; restarts are the business of liveness probes and process supervision.

What a readiness probe actually controls

As the dev.to author explains, the kubelet executes each container's readiness probe on whatever schedule the probe configuration specifies. A successful probe lets Kubernetes mark the container as ready, and when all the readiness conditions a Pod requires are satisfied, its Ready condition turns true. Once the probe starts failing, the container flips to not-ready, which normally makes the entire Pod not ready too.

That state change is a signal to service discovery rather than a kill switch for the process. Controllers update the matching EndpointSlices, dropping the not-ready Pod from the backends eligible for regular Service traffic, and components such as kube-proxy — or whichever implementation handles Service routing in the cluster — converge on the new endpoint state.

The container keeps running

According to the article, none of this touches the container itself. Nothing kills the process, nothing resets its filesystem, and the restart counter stays put just because readiness failed. The kubelet simply keeps probing. If the application recovers and the probe succeeds again, the Pod can return to ready status and rejoin the Service's pool of backends without ever being restarted.

That behavior is what makes readiness probes the right tool for temporary inability to serve, the author argues. An application can still be running while temporarily unable to handle requests — reloading configuration, re-establishing a connection to a dependency, warming a cache, or draining work. A readiness failure isolates that instance from new traffic while preserving whatever in-memory recovery is underway.

Losing endpoints is not the same as stopping traffic

One nuance the article stresses is that removal from Service endpoints is not an instant cancellation mechanism. Endpoint updates have to propagate, and connections that are already established may stay open. A client with a long-lived TCP connection can keep directing requests at the same Pod long after it stopped being ready. Readiness steers routing decisions; it does not promise that traffic halts at the exact moment a probe fails.

When a restart is actually wanted

If the intended response to an unhealthy container is termination followed by a fresh start, the article points to liveness probes as the mechanism for that policy. When a liveness check fails, the kubelet may restart the container, following the restart policy set on the Pod. The author cautions against reaching for liveness when the underlying condition would clear on its own: doing so invites restart loops that destroy precisely the recovery progress a readiness probe would have protected.

The corrected rule of thumb: a failed readiness probe takes a Pod out of ordinary Service traffic and nothing more — the container is left running.

Why it matters

Confusing the two probe types carries real operational costs. Teams that expect readiness failures to restart containers will misread their dashboards: a stable restart count looks like health even while the Pod sits outside the Service, silently receiving no traffic. Worse, using liveness probes to force restarts for conditions that recover on their own can convert a brief slowdown into a restart loop, discarding in-flight recovery work and amplifying the incident. Keeping the distinction straight lets operators match the probe to the failure mode — graceful removal from rotation for recoverable states, restarts only for containers that genuinely cannot come back on their own.