Readiness Probe

A readiness probe is the check that decides whether a container should receive traffic. The Kubernetes documentation defines three kinds of probe, “each serving a different purpose,” and summarizes the two possible reactions: based on the results, Kubernetes “can restart unhealthy containers or stop sending traffic to containers that are not ready.” Readiness is the second of those. Quotations were read in September 2026; field defaults are versioned.

Keeping the three apart is most of the value here, because the common configuration error is putting a check in the wrong one.

Probe	Question	Failing it causes	Runs
Readiness	Should traffic go here?	Removal from Service endpoints. No restart	“During its whole lifecycle”
Liveness	Is it stuck?	Restart of the container	Periodically
Startup	Has it finished starting?	The kubelet “kills the container”	At startup only

What failing readiness actually does

The mechanism is specific and worth knowing exactly: “if the readiness probe returns a failed state, the EndpointSlice controller removes the Pod’s IP address from the EndpointSlices of all Services that match the Pod.”

So the Pod keeps running, keeps its place in the workload’s replica count, and stops being a destination. Nothing is killed and nothing is restarted. That makes readiness the right tool for conditions that are temporary, and the documentation names both ends of the lifecycle: it is “useful when waiting for an application to perform time-consuming initial tasks, such as establishing network connections, loading files, and warming caches,” and “can also be useful later in the container’s lifecycle, for example, when recovering from temporary faults or overloads.”

That second clause is the underused one. A Pod that is briefly overwhelmed can withdraw from rotation, recover, and return — which is backpressure expressed through the platform’s routing instead of through the protocol. It only works because the probe keeps running: “readiness probes run on the container during its whole lifecycle,” not just at startup.

The object being edited is the endpoint set that a Service maintains — its controller “continuously scans for Pods that match its selector, and then makes any necessary updates to the set of EndpointSlices.” So readiness is one of the two inputs to that set; the other is the label selector.

What to check in it, and what not to

The question a readiness endpoint should answer is “can this instance serve a request right now?” Three things belong in it: initialization finished, required local resources available, and capacity to accept work.

Dependencies are the judgment call, and the answer depends on whether your service can do anything useful without them.

• Include a dependency when the service is useless without it — a database-backed API that can serve nothing while its database is unreachable is honestly not ready.
• Exclude it when the service can degrade — if some endpoints work without the cache, failing readiness on the cache takes the whole instance out of rotation for a partial problem.

And one systemic caution: a shared dependency checked by every replica’s readiness probe turns a single dependency blip into a total outage, because every instance withdraws at once. The failure mode of a dependency check in readiness is correlated across replicas, which is the opposite of what replicas are for — see partial failure.

Why the liveness confusion is expensive

Liveness answers a different question — “determine when to restart a container” — a liveness probe “could catch a deadlock, where an application is running, but unable to make progress” — and the documentation attaches an unusually strong warning to it. Probes “must be configured carefully to ensure that they truly indicate unrecoverable application failure, for example a deadlock,” because “incorrect implementation of liveness probes can lead to cascading failures. This results in restarting of container under high load; failed client requests as your application became less scalable; and increased workload on remaining pods due to some failed pods.”

Read that as a sequence, because it is an outage pattern rather than a caution.

1. Load rises and responses slow down.
2. The liveness probe times out — because the service is busy, not because it is stuck.
3. The container restarts, losing its in-flight work and its warm state.
4. Its traffic moves to the remaining Pods, which now slow down too.
5. Their probes start failing.

A liveness probe that measures load rather than deadlock converts a slow service into an unavailable one. The rule that avoids it: liveness should ask whether the process can still make progress at all, with a generous timeout; readiness should ask whether it should be handed more work; and “is it fast enough?” is neither — that is an SLO question. Note also that “liveness probes do not wait for readiness probes to succeed,” so the two run independently and a slow start can trigger restarts unless you account for it.

Slow starts get their own probe

Rather than loosening liveness for the sake of startup, use a startup probe: when one is configured, “Kubernetes does not execute liveness or readiness probes until the startup probe succeeds, allowing the application time to finish its initialization.” It “is only executed at startup,” and if it fails “the kubelet kills the container, and the container is subjected to its restart policy.”

The documented decision rule is arithmetic rather than a matter of taste: if the container usually takes longer than \(initialDelaySeconds + failureThreshold \times periodSeconds\) to start, add a startup probe checking the same endpoint as liveness. “The default for periodSeconds is 10s.”

Readiness and shutdown are one design

A useful clarification for a common belief: you do not need a readiness probe purely to drain traffic on deletion. “If you want to be able to drain requests when the Pod is deleted, you do not necessarily need a readiness probe; when the Pod is deleted, the corresponding endpoint in the EndpointSlice will update its conditions: the endpoint ready condition will be set to false, so load balancers will not use the Pod for regular traffic.”

The platform handles the routing side of deletion on its own. What it cannot do is make your process finish in-flight work before exiting, and endpoint removal is concurrent with the termination signal rather than strictly before it — so a process that exits immediately can still refuse requests already in transit. Designing readiness and termination together is what closes that window: see graceful shutdown.

One framing to close. A probe is implemented by the kubelet, which “either executes code within the container or makes a network request” — but what it checks is code you wrote. Probes are application code that the platform depends on, which means “it works when we run it” is not the same as “it behaves correctly when the platform starts, routes to, and stops it.” See Ephemeral by Default for how this fits with the rest of a workload’s declarations.

References, read September 2026: Kubernetes: Liveness, Readiness, and Startup Probes; Service. Field names and defaults are versioned.