Kubernetes liveness and readiness probes are health checks that help keep applications reliable. A liveness probe determines whether a container should be restarted when it stops functioning correctly, while a readiness probe determines whether a Pod is ready to receive traffic. Understanding the difference helps DevOps teams prevent unnecessary container restarts, reduce failed requests, and manage deployments more safely. This guide compares Kubernetes liveness vs readiness probes, explains when to use each one, and provides practical YAML configuration examples.
What Probes Do in Kubernetes?
Kubernetes constantly watches Pods and containers to keep workloads running. Probes are small health checks defined on a container that guide these decisions.
Kubernetes manages containerized applications, making container architecture an important foundation for understanding health probes. Readers who are new to container technology can explore our comparison of containers vs virtual machines to understand how containers operate, how they differ from traditional virtual machines, and why orchestration platforms use them.
A probe result can influence restarts, traffic routing, and rollout behavior. That makes probes a core part of day to day reliability, not an optional extra.
- Availability: Keeps traffic away from instances that cannot serve requests.
- Self Healing: Restarts containers that are stuck or deadlocked.
- Safer Deployments: Reduces failed rollouts and flapping during startup.
Once probes are in place, Kubernetes can make better decisions automatically with less manual intervention.
The official Kubernetes documentation on Kubernetes liveness, readiness, and startup probes explains how the kubelet evaluates container health and how different probe results influence application recovery and availability.
Kubernetes Liveness Probes Explained
A liveness probe answers one question – should this container be restarted. If the check fails repeatedly, kubelet treats the container as unhealthy and restarts it according to the restart policy.
Liveness is designed for situations where a process is running but not making progress. Common examples include deadlocks, hung event loops, or a service that no longer responds even though the process is still alive.
When A Liveness Probe is the Right Tool
Liveness works best when a restart is a safe and effective recovery action. It should be conservative because a bad liveness probe can cause endless restarts.
- Deadlock Detection: The process is alive but cannot respond to a basic check.
- Broken Internal State: A restart reliably clears the issue.
- Stuck Startup After Initialization: The app never progresses to a usable state.
- Unrecoverable Runtime Failure: The application becomes permanently unresponsive after startup, and restarting the container is an appropriate recovery action.
Use liveness for true crash recovery, not for load related slowness or temporary downstream failures.
Kubernetes Readiness Probes Explained
A readiness probe determines whether a container is prepared to handle incoming requests. When the check fails, Kubernetes marks the container as not ready, which can make the Pod’s Ready condition false. Kubernetes Services normally stop directing new traffic to an unready Pod. The container continues running and can become ready again after subsequent successful checks.
Readiness is ideal for startup, warmups, and dependency checks. Unlike liveness, a readiness failure does not restart the container by itself.
When A Readiness Probe is the Right Tool
Readiness should reflect whether the application can handle real requests. This often includes internal state and connectivity that may change over time.
- Startup Warmup: The app needs time to load routes, caches, or models before serving.
- Dependency Awareness: Check dependencies only when their availability directly determines whether the application can serve requests. Avoid making every Pod unready because of a temporary failure in a shared external service, as this can unnecessarily remove healthy application instances from traffic.
- Graceful Degradation: Temporarily stop receiving new traffic during overload or maintenance.
Readiness is the primary control for traffic management during rollouts and scaling events.
Readiness probes work alongside Kubernetes Service routing to help direct traffic toward available application instances. However, application health checks and external traffic management are different responsibilities. To understand how these components support application availability, read our comparison of API gateway vs load balancer, which explains their roles in routing requests across modern cloud applications.
Kubernetes Startup Probes Explained
A startup probe checks whether an application has finished starting. It is especially useful for applications that require extra initialization time, such as services loading large datasets, building caches, or completing other startup tasks.
When a startup probe is configured, Kubernetes delays liveness and readiness checks until the startup probe succeeds. This prevents a slow-starting application from being restarted too early by its liveness probe.
Startup probes are particularly helpful when application startup times vary between deployments. Teams can give an application enough time to initialize without making liveness checks unnecessarily slow after startup.
For example, a startup probe with a period of 10 seconds and a failure threshold of 30 allows approximately five minutes for successful initialization before Kubernetes treats repeated startup failures as a reason to restart the container.
When Should You Use A Startup Probe?
- Slow Application Startup: The service takes significant time to initialize.
- Variable Initialization Time: Startup duration changes because of caching, configuration loading, or infrastructure conditions.
- Premature Liveness Restarts: Containers are repeatedly restarted before completing startup.
A startup probe is not required for every application. Use it when startup behavior needs separate handling from normal application health checks.
Liveness Vs Readiness Key Differences
Liveness probes help applications recover from failures by restarting containers that are no longer functioning correctly. Readiness probes protect service availability by preventing Pods that are not ready from receiving normal Service traffic. Liveness focuses on container recovery, while readiness focuses on whether the application can serve requests.
Both can be used together on the same container. The combination is powerful when tuned carefully.
| Topic | Liveness Probe | Readiness Probe |
|---|---|---|
| Primary Goal | Decide when to restart a container | Decide when a Pod can receive traffic |
| Failure Result | Container restart after repeated failures | Pod removed from Service endpoints |
| Best for | Deadlocks and unrecoverable internal state | Startup, warmup, and dependency readiness |
| Risk When Misconfigured | Crash loop and rollout instability | Traffic starvation and slow scale up |
This difference is the reason readiness is usually more complex, while liveness should stay simple and stable.
Readiness also affects how Kubernetes Services select application backends. The official documentation on Kubernetes EndpointSlice conditions explains how endpoint readiness, serving state, and termination status help determine whether a Pod should receive Service traffic.
Kubernetes Probe Types: HTTP, TCP, Exec, and gRPC
Kubernetes supports several probe handlers, including HTTP GET requests, TCP socket checks, commands executed inside containers, and gRPC health checks. The appropriate handler depends on the application’s protocol, available health endpoints, and performance requirements.
Http Get Probes
HTTP probes call an endpoint on the container, typically a health route. They are easy to reason about and integrate well with web services.
Return codes in the 200 to 399 range are treated as success. Keep the endpoint lightweight and independent from slow external calls.
Tcp Socket Probes
TCP probes check whether a port is accepting connections. They work well for simple network services where an open port is a good signal.
They do not validate application level correctness. Use them when HTTP is not available or not meaningful.
Exec Probes
Exec probes run a command inside the container. Success is based on exit code, which makes them flexible for custom checks.
Avoid heavy scripts that consume CPU or create lock contention. Exec probes can become noisy on busy nodes.
gRPC Probes
Kubernetes also supports native gRPC health probes for applications that implement the standard gRPC Health Checking Protocol. These probes allow Kubernetes to query a gRPC service’s health status without requiring a separate HTTP endpoint.
A gRPC probe can be configured for liveness, readiness, or startup checks. The application must expose a compatible health-checking service, and the probe must use the appropriate numeric port.
gRPC probes are useful for microservices that communicate primarily through gRPC. However, teams should ensure that their health-checking service accurately represents application health and responds quickly.
The official gRPC Health Checking guide explains how services expose standardized health responses. Developers can use this guidance when implementing the health-checking service required by native Kubernetes gRPC probes.
Simple Examples in Pod Spec YAML
The fastest way to understand probes is to see how they look in a container spec. These examples are intentionally minimal and focus on the fields most teams tune.
The following examples are YAML fragments intended to be placed inside an individual container definition under spec.containers in a Kubernetes Pod or Deployment manifest. They are not complete, standalone Pod configuration files. Replace the example paths and ports with values appropriate for your application.
Readiness Probe Http Get Example
This pattern blocks traffic until a health endpoint responds successfully. It is commonly paired with a separate liveness check.
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3
Liveness Probe Http Get Example
This check should only fail when the container needs a restart. Keep it stable even during normal load spikes.
livenessProbe:
httpGet:
path: /live
port: 8080
initialDelaySeconds: 20
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 3
Tcp Socket Example
This check is useful for protocols where an open port indicates the service is functioning. It can be used for either readiness or liveness depending on your needs.
readinessProbe:
tcpSocket:
port: 5432
initialDelaySeconds: 5
periodSeconds: 10readinessProbe
tcpSocket
port 5432
initialDelaySeconds 5
periodSeconds 10
After you add probes, validate behavior during startup, during shutdown, and during a rolling update.
For complete Pod manifests and additional configuration options, consult the official Kubernetes probe configuration guide. It provides examples of HTTP, TCP, command-based, gRPC, and startup health checks that can help teams configure and validate their workloads.
How to Tune Probe Timing Without Flapping?
Most probe problems come from timing. A probe that is too aggressive creates false failures, while a probe that is too relaxed delays recovery and rollout speed.
- Initial Delay: Use initialDelaySeconds to postpone the first probe after the container starts. For applications with long or unpredictable initialization times, consider a startup probe instead of relying on a large liveness delay.
- Period Seconds: Choose a cadence that balances quick detection with overhead on the node and application.
- Timeout Seconds: Keep low for simple endpoints, but raise it if TLS handshakes or heavy startup work makes timeouts likely.
- Failure Threshold: Increase to tolerate brief hiccups, especially for readiness where temporary removal from endpoints is acceptable.
- Success Threshold: Use successThreshold to require multiple consecutive successful readiness checks before a previously failing probe is considered successful. For liveness and startup probes, Kubernetes requires this value to be 1.
Good tuning starts with observing startup duration, typical latency, and how your service behaves under deployment pressure.
Health probe settings should be reviewed as part of the application’s deployment configuration. DevOps teams can include probe validation in automated delivery workflows and use version-controlled configuration to track changes across environments. Our guide to GitOps vs CI/CD explains how automated pipelines and declarative deployment practices work together to improve consistency in Kubernetes environments.
Common Mistakes That Break Reliability
Misconfigured probes can reduce availability rather than improve it. The safest approach is to start with conservative settings and tighten after measuring behavior.
Reliable health checks are only one part of application availability. Even correctly configured probes cannot eliminate outages caused by a shared database failure, unavailable network infrastructure, or another critical dependency. For a broader reliability strategy, explore our guide to avoiding single points of failure, which explains how redundancy, failover planning, and monitoring reduce infrastructure risks.
- Using Liveness for Dependency Checks: Restarting because a database is down creates extra churn and does not restore service.
- Health Endpoints That Do Too Much: A probe that hits downstream services can cause cascading failures across a cluster.
- Using the Same Health Criteria For Both Probes: Liveness and readiness checks may use the same lightweight endpoint in suitable applications, but they should represent different recovery decisions. Configure their failure thresholds carefully, or use separate endpoints when readiness must account for conditions that should not trigger a restart.
- Too Short Initial Delay: Causes crash loops during cold start, image pulls, or first time initialization.
- Ignoring Graceful Termination: During shutdown, applications should stop accepting new work where appropriate, complete or safely terminate active requests, and honor Kubernetes termination signals. Review terminationGracePeriodSeconds, application shutdown behavior, and endpoint termination handling to reduce interrupted requests during rolling deployments.
Probe configuration should also be coordinated with container shutdown behavior. The Kubernetes Pod lifecycle documentation explains how Pods transition between lifecycle states and how termination signals and grace periods affect application shutdown.
Fixing these issues usually improves rollout stability and reduces noisy alerts more than any other single change.
How to Validate Kubernetes Health Probes?
Configuring health probes is only the first step. Teams should test how their applications respond to failed health checks before relying on the settings in production.
Follow these checks when validating Kubernetes probes:
- Check Pod Readiness: Run kubectl get pods to confirm that containers reach the expected ready state after startup.
- Inspect Probe Failures: Use kubectl describe pod POD_NAME to review warning events and identify failing health checks.
- Review Container Restarts: Check restart counts and container logs to determine whether liveness checks are causing unexpected restarts.
- Test Temporary Failures: In a controlled test environment, verify that a readiness failure stops normal Service traffic without unnecessarily restarting the container.
- Validate Deployments: Test startup, rolling updates, and graceful shutdown to confirm that Pods become ready and stop serving traffic at the appropriate times.
These checks help teams identify overly aggressive probe settings and reduce deployment failures before they affect production users.
Conclusion
Kubernetes liveness and readiness probes solve different problems. Liveness triggers restarts when a container cannot recover on its own, while readiness controls whether a Pod should receive traffic.
Choose a probe type that matches the decision you want Kubernetes to make. Keep checks lightweight, tune timings based on real behavior, and separate liveness from readiness to avoid unnecessary restarts.
Frequently Asked Questions
Do I Need Both Liveness and Readiness Probes?
Many services benefit from both, but they serve different purposes. Use readiness to control traffic flow and liveness only when restarting is the correct recovery action. If you are unsure, start with readiness and add liveness after validating restart behavior.
What Should A Good Readiness Endpoint Check?
A readiness endpoint should reflect the ability to handle requests right now. It can include internal initialization state and required dependencies, but it should stay fast and predictable. Avoid heavy queries and long chains of downstream calls.
Why Does My Pod Restart Even Though Readiness is Failing?
Readiness failures alone do not restart containers. Restarts usually come from a failing liveness probe, a crashing process, or node level issues such as out of memory kills. Check container logs and describe output to confirm which signal triggered the restart.
