Kubernetes Probes: Separate Startup, Recovery, and Traffic Readiness
Understand how startup, liveness, and readiness affect container restarts and Service endpoint state, and how dependency failures and aggressive checks can create operational risk.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
Kubernetes probes are kubelet diagnostics that influence startup delays, container restarts, and whether a Pod receives service traffic. A startup probe checks initialization, a liveness probe checks whether restarting may recover a stuck process, and a readiness probe checks whether the container should receive requests. Each failure has a different effect, so the checks should represent distinct conditions rather than blindly reuse one endpoint.
What each probe changes
A startup probe delays liveness and readiness checks while an application initializes. Once startup succeeds, the other probes begin. If startup continues to fail until its configured failure limit is reached, the kubelet terminates the container and the Pod restart policy determines what follows. For an application that starts slowly, the startup period and failure threshold can allow the expected initialization time without weakening the later liveness interval.
A liveness probe is useful when a process can remain running but become unable to recover on its own, such as a deadlock. If it fails, the kubelet kills the container; restart behavior then follows the Pod’s restart policy. A separate liveness probe may be unnecessary when the process reliably exits on failure and Kubernetes already restarts it according to policy. A liveness check that treats a temporary dependency outage as a local deadlock can instead restart healthy containers repeatedly.
A readiness probe indicates whether the container should currently receive requests. When readiness fails, the container is marked not Ready and is removed from normal traffic selection for matching Services. Readiness does not restart the container. It is useful for conditions such as completing initial data loading or reaching a state in which the application can accept its intended work. Define the condition around serving capability, not every internal warning.
Probe mechanisms
Kubernetes supports HTTP, TCP, gRPC, and exec checks. An HTTP probe sends a GET to a path and port on the Pod IP; status codes from 200 through 399 count as success. A TCP probe tests whether a port accepts a connection, which does not prove that the application can return a correct response. A gRPC probe uses the health-checking protocol, while an exec probe runs a command in the container and uses its exit result. Choose the mechanism that best represents the condition you intend to test.
Timing and failure thresholds
The settings periodSeconds, timeoutSeconds, failureThreshold, successThreshold, and initialDelaySeconds shape the cadence and decision window. With a startup probe, liveness and readiness delays do not begin until startup succeeds. Very short intervals can mistake transient slowness for failure; overly long intervals can delay restart or traffic removal. Tune the values against observed startup and recovery behavior rather than selecting the same aggressive defaults for every container.
The Kubernetes documentation cautions that exec probes create or fork processes on every run. At high Pod density and short intervals, that work can add CPU overhead on the node. Consider whether a lightweight HTTP or TCP signal is adequate, and avoid making each probe execute an expensive database query or traverse multiple external dependencies. A probe is a control input for kubelet action, not a high-frequency substitute for broader service monitoring.
Dependency failures and the readiness boundary
A process can function while a required backend is unavailable. For strict dependencies, Kubernetes describes liveness for the application itself and readiness for application plus backend availability. Readiness failure changes endpoint state used for ordinary Service traffic selection; it does not promise to close existing connections or update every proxy at once.
Putting every remote dependency in liveness can turn one shared outage into restarts across Pods. Identify what is essential to serve requests, scope readiness to that decision, and track user impact and causes through service monitoring outside the probe loop.
Practitioner perspective: keep symptoms and causes separate
Google SRE’s monitoring chapter distinguishes user-visible symptoms from their causes and describes using black-box signals alongside white-box information. Applied to probes, readiness can represent that a container should stop receiving work, while liveness should target a local condition for which a restart is an appropriate recovery action. If liveness incorporates every remote dependency, a dependency incident can trigger restarts across otherwise healthy Pods and make recovery harder.
Test startup delay, readiness failure, and recoverable process stalls separately; check Pod and endpoint state, restart behavior under the configured policy, and recovery. Use service metrics and external checks for user symptoms and root-cause investigation. A passing probe confirms only its configured diagnostic. Kubernetes defines probe behavior; Google SRE provides the broader monitoring lens.