Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Readiness and liveness probes make different decisions. A failed readiness probe removes a Pod from Service traffic while its container keeps running. A failed liveness probe, after the configured consecutive-failure limit, tells the kubelet to restart that container. If startup is slow, a startup probe gives initialization its own deadline before either check begins.
The practical difference: traffic or restart
Kubernetes asks two separate operational questions:
- Readiness: Can this container serve requests right now?
- Liveness: Is this container in a state where restarting it is an appropriate recovery action?
Those answers drive different actions. When readiness fails, Kubernetes marks the Pod unready and removes it from Service load balancing. The container is not restarted; it remains running, readiness checks continue, and the Pod can become ready again when the check succeeds.
Free tools Windows power users keep installed
One-click scans. No signup required.
When liveness fails repeatedly, Kubernetes restarts the affected container after the configured failureThreshold is reached. Liveness is therefore appropriate for a process that cannot recover by itself, such as one stuck in a deadlock. It is not a general-purpose “is anything wrong?” alarm.
#1 Best Overall
| Axis | Readiness probe | Liveness probe |
|---|---|---|
| Question | Can this container serve traffic now? | Should Kubernetes restart this container? |
| Failure effect | Pod Ready condition becomes false and the Pod is removed from Service load balancing; the container keeps running. | After the configured consecutive failures, the kubelet restarts the container. |
| Good signal | A temporary inability to serve, such as loading required data or a dependency condition that should stop new requests. | A condition such as a deadlock from which restarting is likely to recover the process. |
| Lifecycle | Runs throughout the container lifecycle and continues after a failure. | Runs as configured to detect a state that warrants a restart. |
| Main risk | False negatives remove healthy capacity; poorly designed checks can contribute to process growth and resource starvation. | False positives restart working containers, particularly under load, and can create cascading failures. |
Readiness and liveness are independent. They may run at the same time, and success of one does not make the other succeed. Configure each endpoint or check to represent its own decision rather than treating one result as a proxy for both.
Why startup probes are different
A slow initialization phase can look like a liveness failure even though the application is functioning normally once it finishes loading. A startup probe solves that timing problem. While a startup probe is configured and has not succeeded, Kubernetes does not begin readiness or liveness checks. The startup probe therefore protects initialization instead of deciding ongoing traffic eligibility or recovery.
Set the startup probe’s allowed window to cover the longest normal initialization path, including operations such as loading a large dataset or generating required in-memory state. The Kubernetes documentation illustrates a window of failureThreshold: 30 and periodSeconds: 10, which permits up to 300 seconds before startup is considered failed. That is an example, not a universal setting; measure or estimate your own startup time and include headroom.
After startup succeeds, readiness and liveness begin their own independent schedules. A later readiness failure still only removes the Pod from traffic. A later liveness failure still invokes the restart policy after its own consecutive-failure threshold.
Probe mechanisms and when to use each
Kubernetes supports four probe mechanisms. Choose the one that can observe the application state you actually care about.
HTTP GET
An HTTP probe sends a GET request to the configured path and port. Response status codes from 200 through 399 count as success. For a reliable check, expose a dedicated endpoint with a minimal response body. Probe success is determined by the status code; the kubelet stops reading a response body after 10 KiB, so a health endpoint should not generate a large payload.
Use separate paths when the decisions differ. For example, a readiness endpoint can report that required request-serving state is available, while a liveness endpoint can report that the process and its event loop are still making progress. The same low-cost endpoint can be used for both probes when that genuinely represents both decisions, but sharing it does not make readiness and liveness equivalent.
TCP socket
A TCP probe checks whether a connection can be opened on the configured port. It is useful when the service speaks a protocol other than HTTP and a listening socket is the meaningful minimum signal. A listening port alone does not prove that every request path is healthy, so do not use a TCP check for a deeper application condition that it cannot observe.
gRPC
A gRPC probe uses the gRPC health-check mechanism exposed by the application. Select it when the service’s health state is available through gRPC and an HTTP or TCP check would not represent that state.
Exec
An exec probe runs a command inside the container and treats the command result as the health signal. It can inspect local state that is not exposed over the network, but the command must be deterministic and inexpensive enough to run at the selected interval. A command that blocks or consumes significant resources can turn the probe itself into a source of instability.
Defaults, thresholds and detection timing
Documented probe defaults are:
| Setting | Default | What it controls |
|---|---|---|
periodSeconds |
10 | How often the kubelet performs the probe. |
timeoutSeconds |
1 | How long an individual probe attempt may take before it fails. |
failureThreshold |
3 | Consecutive failures required before the probe’s failure action is taken. |
successThreshold |
1 | Consecutive successes required to recover. It must remain 1 for liveness and startup probes. |
These are configuration defaults, not timing guarantees. Actual detection depends on the selected values, probe execution time, scheduling, and the behavior of the application. As a rough planning aid, a failure threshold multiplied by the probe period describes the cadence over which consecutive failures accumulate, but do not promise an exact restart or traffic-removal time from that multiplication alone.
For readiness, one failed check makes the Pod’s Ready condition false, and checks continue. For startup and liveness, the kubelet waits for the configured consecutive-failure threshold before treating the probe as failed and applying the restart behavior. Keep the threshold high enough to tolerate ordinary latency variation, but not so high that a genuinely wedged process remains indefinitely.
Rank #3
A complete configuration example
The following Deployment fragment gives startup, readiness and liveness distinct responsibilities. The startup probe allows a long initialization period. Readiness controls whether the Pod receives traffic. Liveness detects a process that has stopped making progress.
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
template:
spec:
containers:
- name: orders
image: example/orders:2.4
ports:
- name: http
containerPort: 8080
startupProbe:
httpGet:
path: /health/startup
port: http
periodSeconds: 10
failureThreshold: 30
readinessProbe:
httpGet:
path: /health/ready
port: http
periodSeconds: 10
timeoutSeconds: 1
failureThreshold: 3
successThreshold: 1
livenessProbe:
httpGet:
path: /health/live
port: http
periodSeconds: 10
timeoutSeconds: 1
failureThreshold: 3
In this example, Kubernetes does not evaluate the readiness or liveness paths until /health/startup succeeds. Once startup is complete, a failed /health/ready response stops new traffic to the Pod without killing the process. Three consecutive failed liveness checks, using the shown threshold, trigger a container restart. The endpoint names are illustrative; your application must implement equivalent semantics.
How to design the checks
Define the decision before writing the endpoint
Start with the operational action, not with a generic “health” URL. Ask whether a failure should stop traffic, restart the process, or merely be observed. Put only conditions that justify that action into the corresponding probe.
- Readiness should include conditions under which accepting a new request is unsafe or likely to fail. Temporary inability to access required configuration or data can belong here when the correct response is to drain traffic while the process remains available to recover.
- Liveness should include conditions from which the process cannot recover on its own and for which a restart is a sensible remedy. A deadlock is the canonical example.
- Startup should cover work that is expected during initialization but must not be mistaken for a runtime failure.
Keep probe handlers cheap and deterministic
A probe runs repeatedly, so its handler should finish within the selected timeout and avoid expensive work. Return a small response and make the result reproducible for the same application state. A check that performs a full business transaction, waits on a slow external system, or allocates large amounts of memory can create load precisely when the service is already stressed.
Be deliberate about dependencies
A dependency can be relevant to readiness when the application cannot safely serve requests without it. Decide whether a temporary dependency outage should remove this one Pod from traffic or whether the application can serve a degraded response. Do not automatically put every dependency into liveness: restarting all replicas because one shared dependency is slow can turn a recoverable incident into a restart storm.
Allow for normal load
False liveness failures under load are especially dangerous. Queueing, garbage collection, CPU throttling, or brief I/O delays can make a healthy process miss a one-second timeout. Tune timeout, period and failure threshold using observed behavior, and consider a higher liveness threshold when the process needs time to recover. The Kubernetes guidance describes a common pattern in which a higher liveness threshold lets a container remain not ready for a while before a restart is attempted; apply that pattern only when it matches the workload.
Readiness patterns that prevent bad traffic
Initialization and cache loading
During startup, use the startup probe to shield the application from premature liveness failures. After startup, readiness can remain false while a required cache, configuration snapshot or local index is unavailable. Once the state is loaded, the endpoint can return success and the Service can send traffic again.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Temporary overload
If the process is alive but cannot safely accept more work, readiness can be used to withdraw it from load balancing. This preserves the process and lets it recover, provided the application has a clear condition for becoming ready again.
Partial dependency failure
Only mark the Pod unready when the dependency failure actually prevents safe request handling. If the application has a useful fallback, keep readiness successful and expose the degraded behavior through normal monitoring rather than repeatedly removing and re-adding the Pod.
Liveness patterns that justify a restart
Deadlock or permanently stalled worker
A liveness endpoint should fail when the process is alive enough to answer the probe but no longer making the progress required to serve requests. A restart can clear the stuck state.
Unrecoverable internal state
If the application can detect that its in-memory state is irreparably corrupted and a restart is the documented recovery, liveness may represent that condition. Ensure the check cannot itself hang while diagnosing the problem.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →When no liveness probe is better
Not every application needs a liveness probe. If the process exits on its own when it becomes unhealthy, the kubelet can follow the Pod’s restart policy without an additional liveness check. Adding a broad probe in that situation can create false positives without improving recovery.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common mistakes and their consequences
Using liveness to express readiness
If a dependency is temporarily unavailable and the application could recover, making liveness fail causes restarts instead of simply stopping traffic. Repeated restarts can erase useful state, increase load on the dependency and delay recovery.
Making readiness and liveness identical by habit
Identical endpoints are valid only when the same condition truly answers both questions. Otherwise, a transient request-serving problem can trigger unnecessary restarts, or a process deadlock can remain in the load balancer because the readiness check is too shallow.
Checking an external dependency from liveness
A shared database or API outage can make every replica fail at once if it is embedded in liveness. That pattern can produce cascading failures: the dependency is slow, probes fail, containers restart, and the restart storm adds more work to the already-failing system.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, 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 minuteSetting a startup window shorter than normal initialization
If the startup threshold and period do not cover the normal initialization path, Kubernetes can classify a healthy application as failed before it is ready. Increase the allowed startup window to match measured behavior rather than weakening the runtime probes.
Returning a large or expensive HTTP response
Health responses should be minimal. HTTP probe success depends on the status code, and the kubelet stops reading after 10 KiB; generating more output does not improve the decision and can waste resources.
Troubleshooting by symptom
Pods repeatedly disappear from Service traffic but never restart
- Inspect the readiness endpoint from inside the Pod and record its status code and response time.
- Check whether the endpoint is reporting a temporary dependency, configuration or initialization condition.
- Confirm that the Pod’s Ready condition becomes false when the check fails; this is expected readiness behavior.
- Fix the underlying condition or adjust the readiness signal so it represents the minimum state required to serve traffic.
Containers restart during load spikes
- Determine whether liveness failures are consecutive probe timeouts or non-success responses.
- Compare probe timeout and period with normal request latency, CPU pressure and I/O behavior during the spike.
- Remove transient dependencies from liveness unless a restart is genuinely the recovery action.
- Increase tolerance through appropriate timeout or failure-threshold values, then verify that a real deadlock still causes recovery.
A slow-starting application never becomes ready
- Check whether a startup probe is configured. Without one, liveness may begin before initialization finishes.
- Measure the longest normal startup path, including data and configuration loading.
- Set the startup failure window to cover that path with headroom; the documented 30 failures at 10-second intervals is an example of a 300-second allowance, not a universal requirement.
- After startup succeeds, validate readiness and liveness independently.
The probe itself times out
- Verify that the probe mechanism, address, port and path match what the container actually exposes.
- Keep the handler lightweight and return a small body.
- Use a timeout appropriate for normal execution rather than assuming the one-second default fits every workload.
- Check whether the container is resource-starved; a probe cannot reliably measure health if it is consistently denied CPU or I/O time.
A decision framework for choosing probes
- Does the condition mean the Pod should stop receiving new requests? If yes, model it in readiness.
- Would restarting the process plausibly recover the condition? If yes, and the process will not recover unaided, model it in liveness.
- Is the condition expected only during initialization? If yes, protect it with a startup probe.
- Can the selected mechanism observe the condition? Choose HTTP, TCP, gRPC or exec according to the signal available from the application.
- Could a false positive affect many replicas at once? Test the probe under load and keep shared dependency failures out of liveness unless a restart is truly warranted.
Operational checklist
- Document in plain language what each probe’s success and failure mean.
- Use readiness to control Service eligibility, not to request a restart.
- Use liveness only for conditions that need process replacement.
- Add a startup probe when normal initialization can exceed the liveness window.
- Choose a mechanism that measures the intended state rather than merely the easiest endpoint.
- Keep HTTP responses small; status codes 200 through 399 are successful.
- Review
periodSeconds,timeoutSeconds,failureThresholdandsuccessThresholdas a set. - Remember that the documented defaults are 10 seconds, 1 second, 3 failures and 1 success respectively; they are not universal timing guarantees.
- Exercise probes during startup, dependency outages, overload and recovery.
- Watch for restart loops, sudden loss of ready capacity and synchronized failures across replicas.
Bottom line
Use a readiness probe when the right action is “stop sending this Pod traffic for now.” Use a liveness probe only when the right action is “replace this stuck process.” Add a startup probe when initialization needs protection from those runtime decisions. Treat the three checks as independent control signals, keep them cheap and specific, and tune their thresholds for real workload behavior so that health automation helps recovery instead of causing the next 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.
