Free tools Windows power users keep installed
One-click scans. No signup required.
Readiness and liveness probes trigger different Kubernetes actions. A failed readiness probe removes a Pod from Service load balancing while its container keeps running. A failed liveness probe, after the configured consecutive-failure threshold, tells the kubelet to restart that container. A startup probe is the guard for slow initialization: until it succeeds, Kubernetes does not run the readiness or liveness checks.
The operational difference in one view
Think of the probes as answers to separate questions, not as three grades of the same health score. Readiness decides whether traffic should be sent to this Pod at this moment. Liveness decides whether restarting the process is an appropriate recovery action. Startup decides when the application has initialized enough for the other two decisions to be meaningful.
As an Amazon Associate I earn from qualifying purchases.
| Axis | Readiness probe | Liveness probe | Startup probe |
|---|---|---|---|
| Question | Can this container serve requests now? | Is the process stuck or otherwise unable to recover without a restart? | Has initialization finished so normal health checks can begin? |
| Failure effect | The Pod’s Ready condition becomes false and the Pod is removed from Service load balancers. The container remains running. | After the configured consecutive failures, the kubelet restarts the container. | Readiness and liveness checks remain on hold. If startup never succeeds within its allowed window, the container is treated as failed. |
| Typical signal | A temporary inability to accept useful work, such as loading required data or entering a controlled drain state. | An unrecoverable application condition such as a deadlock, where a fresh process can restore service. | A cheap test that confirms initialization is complete. |
| After a failure | Checks continue throughout the container lifecycle; the Pod can become ready again without a restart. | The restart follows the Pod’s restart policy and the container’s restart behavior. | Normal checks start only after a successful startup result. |
| Main risk | False negatives remove healthy capacity and can concentrate traffic on fewer Pods. | False positives restart working processes, potentially creating restart loops or cascading failures under load. | An allowance that is too short kills applications during legitimate initialization. |
These behaviors are independent. Readiness and liveness may run at the same time, and success in one does not make the other succeed. Configure each endpoint or command for the decision it controls rather than assuming that one generic “health” result is suitable for every probe.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsWhat a failed readiness probe actually does
When a readiness check fails, Kubernetes marks the Pod unready. Service endpoint management then stops advertising that Pod as an eligible backend, so new Service-routed traffic is directed elsewhere. The application process is not restarted merely because it is unready. The kubelet keeps running the readiness check, and a later success can make the Pod eligible again.
#1 Best Overall
This makes readiness appropriate for conditions that should stop new work but may clear without replacing the process. Examples include a server still loading configuration, a replica intentionally warming a cache, a controlled maintenance mode, or an application that cannot currently accept requests but is expected to recover in place.
A readiness check should represent the traffic contract of the application. If a request would fail or produce an unusable result while the check is false, removing the Pod from load balancing is usually the safer action. Do not make it depend on every remote system unless losing that dependency truly means this instance cannot serve any useful request; an overly broad dependency test can withdraw all capacity during a partial outage.
What a failed liveness probe actually does
A liveness failure is a restart decision. The kubelet counts consecutive failed results and restarts the container when the configured failureThreshold is reached. Use this only when the process is in a condition from which it is unlikely to recover on its own and a restart is a reasonable remedy. A deadlock, an event loop that has stopped making progress, or a permanently wedged internal subsystem can fit that definition.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Do not use liveness as a synonym for “the application returned an error.” Temporary overload, a slow database, a brief network partition, or a long garbage-collection pause may make a probe fail even though keeping the process alive would allow it to recover. Restarting every replica in response to such a transient condition can turn a local problem into a cluster-wide outage. Kubernetes documentation explicitly cautions that an incorrect liveness implementation can cause cascading failures.
If the process exits by itself when it becomes unhealthy, a liveness probe may add no value: the kubelet already applies the Pod restart policy to a terminated container. Add a liveness check when it can detect a failure mode that does not cause the process to exit and when restarting is demonstrably better than waiting.
Why slow applications need a startup probe
Applications that need substantial time to initialize often get misdiagnosed as unhealthy. A startup probe solves that timing problem. While it is configured, Kubernetes does not run the readiness or liveness probes until the startup probe succeeds. You can therefore give initialization its own, longer window without weakening the steady-state liveness policy.
Set the startup probe’s allowed window to cover the slowest expected legitimate initialization, including image startup, migrations, loading large models or indexes, and normal storage variance. If the probe never succeeds before its failure threshold is exhausted, Kubernetes treats startup as failed; increasing the window does not fix an application that cannot actually complete initialization.
The Kubernetes documentation shows an example with failureThreshold: 30 and periodSeconds: 10. That permits up to 300 seconds of startup checking. It is an illustrative configuration, not a universal default. Measure or establish your workload’s initialization envelope and choose values accordingly.
Probe mechanisms: choose the one that observes the right state
Kubernetes supports HTTP GET, TCP socket, gRPC and exec probes. They are alternatives, not interchangeable spellings. Pick the mechanism that can observe the condition you intend to test while adding as little work as possible to the application.
| Mechanism | Good fit | Important details |
|---|---|---|
| HTTP GET | HTTP servers that can expose a dedicated health endpoint. | HTTP status codes from 200 through 399 count as success. Use a minimal response body; the kubelet stops reading a response body after 10 KiB, and status is the decisive result. |
| TCP socket | A process where accepting a connection is the useful liveness or readiness signal and an HTTP endpoint is unavailable. | A listening port proves reachability, not that requests are correctly processed. Avoid using it when the server can accept sockets while its worker system is wedged. |
| gRPC | A gRPC service that implements an appropriate health service. | Use the service’s health semantics rather than treating any open port as application readiness. |
| Exec | A local condition that can only be checked inside the container, such as a specific process or local subsystem state. | Keep the command fast and deterministic. An expensive command consumes CPU and can become a failure source under pressure. |
A dedicated endpoint should do only the work needed to answer its probe question. Avoid a check that performs a full user transaction, scans a large data set, or depends on a chain of remote services unless that exact dependency is part of the traffic decision.
Timing fields and what the defaults mean
The documented defaults are configuration starting points, not guaranteed detection times:
| Field | Documented default | How to interpret it |
|---|---|---|
periodSeconds |
10 seconds | How often Kubernetes schedules a probe after the previous cycle; actual timing also depends on execution and scheduling. |
timeoutSeconds |
1 second | How long an individual probe may run before that attempt fails. A one-second timeout may be too strict for a busy endpoint. |
failureThreshold |
3 consecutive failures | How many failed attempts are needed for the probe’s failure action. For readiness, the Pod becomes unready; for liveness or startup, the container is treated as failed after the threshold. |
successThreshold |
1 | How many successes are needed to recover. It must remain 1 for liveness and startup probes; readiness can use a higher value when flapping must be damped. |
Do not multiply these values and present the result as an exact outage-detection guarantee. Probe execution, process scheduling and kubelet behavior affect when an action occurs. Use the values to express tolerance for transient failures, then validate them under realistic load.
Rank #3
A complete example with separate startup, readiness and liveness decisions
The following Pod fragment labels every probe by the action its result controls. Replace the paths and port with endpoints implemented by your application.
apiVersion: v1
kind: Pod
metadata:
name: api
spec:
containers:
- name: api
image: example/api:1.0
ports:
- containerPort: 8080
startupProbe:
httpGet:
path: /health/startup
port: 8080
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 30
readinessProbe:
httpGet:
path: /health/ready
port: 8080
periodSeconds: 5
timeoutSeconds: 1
failureThreshold: 2
successThreshold: 1
livenessProbe:
httpGet:
path: /health/live
port: 8080
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 6
successThreshold: 1In this example, startup can take as long as the documented 30-by-10-second example window before normal checks begin. Once startup succeeds, readiness can remove the Pod after two failed checks without killing it, while liveness tolerates six failed checks before requesting a restart. The numbers are illustrative; choose them from observed behavior and recovery objectives.
It is acceptable for two probes to call the same inexpensive endpoint when the application truly has one reliable signal. Separate endpoints make the operational intent clearer and allow readiness to include traffic eligibility while liveness remains focused on process progress. A common pattern is to give liveness a higher failure threshold than readiness so a temporarily impaired container is first left out of traffic and restarted only if it does not recover.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Designing a readiness check that protects capacity
Return failure for traffic-specific conditions
Return a failed result when this instance should not receive new requests. During startup, graceful shutdown, controlled draining, or a known local state that prevents successful service, readiness should turn false. The process can continue long enough to finish existing work or recover.
Keep the check local and cheap
Probe handlers run repeatedly. They should avoid heavyweight queries and should not create a dependency storm. If a remote dependency is optional for some routes, do not make the entire Pod unready merely because that dependency is unavailable; instead, make the endpoint reflect the subset of traffic the Pod can no longer serve.
Expect recovery without replacement
A readiness failure is reversible. Verify that the endpoint returns to success after the condition clears and that Service endpoint updates follow that transition. This is especially important for applications that reload configuration or recover a connection pool in place.
Designing a liveness check that avoids restart loops
Test progress, not perfection
A liveness endpoint should answer whether the process can make forward progress, not whether every downstream feature is currently healthy. A dependency outage that all replicas share is usually a poor reason to restart every replica.
Recommended Free Tools
Allow for load and legitimate pauses
Set timeoutSeconds, periodSeconds and failureThreshold so ordinary CPU contention, garbage collection or brief scheduling delays do not look like a deadlock. A check that is reliable on an idle development machine can become a restart trigger at production concurrency.
Prove that restart helps
Before enabling liveness, identify the failure mode it detects, how the process becomes stuck without exiting, and why a restart restores service. If you cannot answer those questions, begin with readiness and process-level crash handling rather than adding a speculative liveness action.
How the three probes interact during a rollout
- Container starts: If a startup probe exists, Kubernetes runs it first and withholds readiness and liveness evaluation until it succeeds.
- Startup succeeds: Readiness begins determining whether the Pod can receive traffic, and liveness begins determining whether a restart is warranted. These checks operate independently.
- Readiness fails: The Pod leaves Service load balancing, but the container stays alive and readiness checks continue.
- Readiness recovers: A successful result can make the Pod eligible for traffic again, subject to the configured success threshold and normal endpoint propagation.
- Liveness reaches its failure threshold: The kubelet restarts the container. The startup probe, if configured, governs the next initialization period before normal checks resume.
This sequence explains why a Pod can be running but not ready, or ready at one moment and restarted later. “Running,” “Ready” and “healthy enough to avoid restart” are separate states.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common configuration failures and fixes
A readiness failure is restarting the container
Check whether the failing check is actually declared under livenessProbe, whether a startup probe is timing out, or whether the application is exiting independently. A readiness failure alone only changes traffic eligibility.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallA slow-starting container restarts before it is usable
Add a startup probe and make its failure window cover legitimate initialization. Do not simply make liveness extremely permissive for the entire container lifetime; that delays detection of a genuine deadlock after startup.
All replicas disappear from a Service
Inspect the readiness endpoint and its dependencies. A shared dependency in the check can make every Pod unready at once. Narrow the condition to what the Pod must have to serve the intended traffic, and confirm that the endpoint returns a 200–399 status when the Pod is usable.
Pods restart repeatedly during traffic spikes
Review liveness timeout and threshold values against peak latency, CPU throttling and garbage-collection pauses. Move load-sensitive or dependency-sensitive conditions to readiness, increase liveness tolerance where justified, and keep the liveness handler minimal.
The probe itself consumes noticeable resources
Measure the handler or command. Reduce response work, avoid external calls, and use a TCP or local exec check only when it observes the required state accurately. A probe that adds significant load can create the failure it is meant to detect.
An HTTP probe reports failure despite a visible page
Check the exact path, port, scheme and returned status code from inside the Pod’s network context. Kubernetes considers 200 through 399 successful; redirects outside that range, authentication responses and server errors are failures. Keep the response body small because the kubelet stops reading after 10 KiB.
A practical decision framework
- Should this Pod receive new traffic right now? Configure readiness.
- Would replacing this process likely clear a persistent, non-exiting fault? Consider liveness.
- Can startup legitimately exceed the liveness window? Add startup and size its allowance for initialization.
- Does the process already exit when unhealthy? Rely on the restart policy unless liveness detects an additional non-exiting failure mode.
- Could a false positive affect every replica? Make the liveness signal narrower, cheaper and more tolerant before enabling it.
- Can the condition clear without replacement? Prefer readiness for that condition.
The safest configuration is not the one with the most probes. It is the one where every probe has a single, explicit operational consequence and enough tolerance for normal behavior.
Testing probes before production
- Exercise the startup path with the slowest expected initialization and verify that startup succeeds before its threshold is exhausted.
- Force a readiness-only condition, such as a controlled drain, and confirm that the Pod leaves Service endpoints while the process remains running.
- Clear that condition and verify that readiness returns without recreating the Pod.
- Simulate the specific non-exiting fault that liveness is intended to detect. Confirm that the configured consecutive failures lead to one restart rather than a rapid loop.
- Repeat the tests under CPU and network pressure. Probe handlers must remain responsive enough that normal contention does not produce false failures.
- Observe events, container restart counts and Service endpoints together; looking at only the Pod’s “Running” state can hide a readiness failure.
Bottom line for Kubernetes readiness vs liveness probes
Use readiness to control where traffic goes, liveness to decide when a process should be restarted, and startup to protect both decisions during initialization. Keep the checks independent, cheap and tied to the action their failure causes. A conservative readiness check can remove an impaired Pod without destroying it; a carefully justified liveness check can recover a genuine deadlock. An overly broad or aggressive liveness check can instead amplify a transient problem into a cascading outage.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
