Kubernetes Liveness vs Readiness Probes Explained

In production Kubernetes environments, application availability is critical. Simply having a Pod in a Running state does not guarantee that your application is healthy or ready to serve user requests.

This is where Liveness and Readiness Probes play a vital role.

Although these probes are often confused, they solve two completely different problems.

---

What is a Liveness Probe?

A Liveness Probe checks whether the application inside the container is still functioning correctly.

If the application becomes unresponsive due to a deadlock, memory leak, or internal failure, Kubernetes automatically restarts the container.

Real-Time Example

Imagine an Internet Banking application where:

• Users are actively making fund transfers.
• The Java application encounters a thread deadlock.
• The process is still running, but API requests stop responding.

Without a liveness probe, Kubernetes considers the Pod healthy because the process is still alive.

With a liveness probe, Kubernetes detects the failure and automatically restarts the container, restoring service without manual intervention.

Example Configuration

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8081
  initialDelaySeconds: 60
  periodSeconds: 15
  timeoutSeconds: 5
  failureThreshold: 5

---

What is a Readiness Probe?

A Readiness Probe determines whether the application is ready to receive traffic.

Unlike a liveness probe, it does not restart the container. Instead, Kubernetes temporarily removes the Pod from the Service until it becomes ready.

Real-Time Example

A Spring Boot application starts successfully, but it still needs to connect to:

• Oracle Database
• Redis Cache
• Kafka
• Authentication Service

Without a readiness probe, users may receive HTTP 500 errors because the application is not fully initialized.

With a readiness probe, Kubernetes waits until all dependencies are available before routing traffic to the Pod.

Example Configuration

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8081
  initialDelaySeconds: 60
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

---

Liveness vs Readiness

Feature	Liveness Probe	Readiness Probe
Purpose	Checks if the application is alive	Checks if the application is ready
Restarts Container	✅ Yes	❌ No
Removes Pod from Service	❌ No	✅ Yes
Used During Startup	❌ No	✅ Yes
Prevents User Errors	Indirectly	Directly

---

Common Production Issues

CrashLoopBackOff

Usually caused by:

• Incorrect liveness endpoint
• Insufficient startup delay
• Application startup failures

Pod Not Receiving Traffic

Often due to:

• Readiness probe failures
• Database connectivity issues
• Redis or Kafka unavailable

HTTP 403 During Health Checks

This typically happens when Spring Security protects the health endpoint.

Expose the actuator health endpoints without authentication or configure the required permissions.

---

Production Best Practices

• Keep health endpoints lightweight.
• Separate liveness and readiness endpoints.
• Configure realistic startup delays.
• Test failure scenarios regularly.
• Monitor probe failures using Prometheus, Grafana, or Dynatrace.

---

Conclusion

Liveness and Readiness Probes are essential for building resilient Kubernetes applications.

A properly configured liveness probe enables automatic recovery from application failures, while a readiness probe ensures users only interact with healthy application instances.

Together, they improve availability, reduce downtime, and support zero-downtime deployments in production environments.

---

About DevOps with Patil

At DevOps with Patil, I share practical DevOps knowledge based on real production environments, including Kubernetes, OpenShift, Azure DevOps, CI/CD, GitOps, Infrastructure as Code, monitoring, troubleshooting, and interview preparation.

If you found this article helpful, follow DevOps with Patil for more hands-on DevOps content.