Kubernetes offers built-in mechanisms called probes to check the health and availability of containers that are running inside the pods. These probes will help Kubernetes decide when you need to restart a container, when to stop the traffic flow, and when it is safe to terminate it during the shutdown.
The three main types of probes are Liveness, Readiness, and Startup probes. In this guide, we shall discuss the Kubernetes Readiness Probe with the specific purpose in maintaining the overall health and responsiveness of your application.
What Is a Readiness Probe?
A Readiness Probe shows Kubernetes whether a container is ready to accept the incoming traffic. Unlike the liveness probe, which checks if a container is still running, the readiness probe identifies whether the container is properly initialized and is capable of serving requests.
If the readiness check fails, Kubernetes will temporarily remove the Kubernetes pod from the service endpoint list until it passes again.
Why Should You Use a Readiness Probe?
Using a Kubernetes Readiness Probe makes sure that the application will only receive traffic when it is ready to handle it. Without the probe, Kubernetes may route traffic to a pod that is initializing or recovering from a temporary issue, which might lead to failed requests or a degraded user experience.
Get exclusive access to all things tech-savvy, and be the first to receive
the latest updates directly in your inbox.
Kubernetes Readiness Probe is especially valuable in application with the following:
- Long startup times
- Dynamic configuration loading
- Dependency on external services before becoming available
How Do Readiness Probes Work?
Kubernetes sends messages and requests periodically to the container based on the configuration that you provide, such as HTTP GET, TCP socket check, or a command execution. If the check succeeds, the pod is marked as ready and then it starts receiving the traffic. However, if it fails, the pod is then removed from the service endpoints, but it still does not restart, unlike the other failed liveness probe.
Related Articles: Best Kubernetes Alternatives: Top Systems for Modern DevOps
Types of Kubernetes Readiness Probes
There are three types of readiness probes supported by Kubernetes, each one suited for different container architecture and checking mechanisms.
- HTTP Probes
An HTTP readiness probe sends out an HTTP message to a specified endpoint on the container. If the response has a status code between 200 and 399, the pod is considered to be ready. HTTP probes are your best shot for web applications or APIs that expose a health check endpoint like /ready.
Example:
readinessProbe:
httpGet:
path: /ready

port: 8080
initialDelaySeconds: 5
periodSeconds: 10
- TCP Socket Probes
A TCP socket probes attempts to open a TCP connection to a certain port. If the connection is successful, then the pod is marked as ready. It is best for applications that do not expose HTTP endpoints but listen on a port, such as databases and socket servers.
Example:
readinessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 10
periodSeconds: 5
- Exec Probes
An Exec readiness probe runs the command inside a container. If the command exits with the status 0, the container is considered ready. It is best for applications that require internal logic or a custom script to verify the readiness.
Example:
readinessProbe:
exec:
command:
– cat
– /tmp/ready
initialDelaySeconds: 5
periodSeconds: 10
Setting Up a Readiness Probe (YAML Examples)
To correctly define a Kubernetes readiness probe, you need to set the right configurations in your container spec within a Pod manifest. Here are YAML-based examples for all the three of the major readiness probes.
- HTTP Readiness Probe
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
- TCP Socket Readiness Probe
readinessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 10
periodSeconds: 5
- Exec Readiness Probe
readinessProbe:
exec:
command:
– cat
– /tmp/ready
initialDelaySeconds: 5
periodSeconds: 10
Readiness vs Liveness vs Startup Probes
Probe Type | Purpose | When It Runs | What Happens on Failure |
Readiness | Checks if the pod is ready to serve traffic | Periodically during the pod’s life | Pod is removed from service endpoints |
Liveness | Checks if the pod is still running properly | Periodically during the pod’s life | Pod is restarted |
Startup | Used to delay other probes during slow startup | Only during pod initialization | Pod is killed and restarted |
Best Practices for Using Readiness Probes
To make the most out of the Kubernetes readiness probes, you can follow these best practices.
- Avoid adding logic that would require significant delays or complexity to keep the checks lightweight.
- Set reasonable timeouts so that you would get to know immediately if the probe fails or if something goes wrong.
- Choose HTTP, TCP, or Exec probes based on how your app signals react.
- Ensure that the apps are fully ready before progressing to production and include the readiness checks in CI/CD pipelines.
- Combine initialDelaySeconds and startupProbe for apps with slow startup times for graceful startup handling.
Troubleshooting For Common Kubernetes Readiness Probe Issues
Issue | Cause | Solution |
Probe always failing | Wrong path, port, or command | Double-check the path/port/command and test manually |
Application not receiving traffic | Readiness probe not succeeding | Review readiness settings and application logs |
Probe times out | The response takes too long | Increase timeoutSeconds or optimize the readiness endpoint |
Application restarts unexpectedly | Liveness probe misconfigured instead of readiness probe | Use readiness for availability, liveness for process health |
Delayed startup causes probe failures | Readiness or liveness probe starts too early | Use initialDelaySeconds or add a startupProbe |
Conclusion: Improve Availability with Readiness Probes
With regular monitoring and the right configurations, Kubernetes readiness probes will help you build more resilient, production-ready workloads that would scale smoothly with traffic. Leverage the full power of the probes so that your applications are never over-burdened with traffic and can deploy on zero-downtime.
FAQs
How is a Readiness Probe different from a Liveness Probe?
A Readiness Probe determines when a pod can serve traffic, while a Liveness Probe checks if a pod is still running. Failing a readiness check removes the pod from service; failing a liveness check may restart it.
What types of Readiness Probes can you configure in Kubernetes?
You can configure three types: HTTP, TCP, and exec (command-based). Each checks pod readiness using different methods.
Can a pod pass the liveness check but fail the readiness check?
Yes. A pod might be running (pass liveness) but not ready to serve traffic (fail readiness), such as during startup or after losing a dependency.