What are Liveness and Readiness?¶
They are health probes used by Kubernetes to determine the state of your application.
Spring Boot Actuator exposes them as:
Why do we need them?¶
Imagine your Order Service.
Suppose Pod-1
- JVM is running
- HTTP server is running
BUT
- Database connection is broken.
Should Kubernetes restart it?
Not necessarily.
Should users send requests to it?
No.
This is where liveness and readiness have different responsibilities.
Liveness Probe¶
Question:
Is the application alive?
It only checks whether the application process is healthy enough to continue running.
If liveness fails,
Kubernetes assumes the application is stuck or dead.
It immediately restarts the container.
Example
Application
↓
Deadlock
↓
Infinite loop
↓
OutOfMemoryError
↓
No response
↓
Liveness = FAIL
↓
Restart Container
Example response
If unhealthy
Readiness Probe¶
Question:
Can this application receive traffic?
Readiness determines whether the application is ready to serve requests.
If it fails,
Kubernetes does not restart the pod.
Instead,
it removes it from the Service endpoints so traffic is no longer routed to it.
Traffic
↓
Pod
↓
Database Down
↓
Readiness FAIL
↓
Pod removed from Load Balancer
↓
No new traffic
↓
Pod keeps running
Difference¶
| Liveness | Readiness |
|---|---|
| Checks if app is alive | Checks if app is ready to serve traffic |
| Failure causes restart | Failure removes pod from load balancer |
| Detects deadlocks, stuck JVM, unrecoverable state | Detects unavailable dependencies or initialization |
| Container restarted | Container keeps running |
Example¶
Suppose
Inventory Service starts.
Startup takes
During startup
Application is
NOT READY
If Kubernetes sends requests immediately,
they fail.
Instead
No traffic.
Once initialization completes
Traffic begins.
Real Production Example¶
Payment Service depends on
- Database
- Kafka
- Redis
Database crashes.
Should Kubernetes restart Payment Service?
No.
Because restarting won't fix the database.
Instead
Suppose JVM enters a deadlock.
Enable Liveness and Readiness¶
Spring Boot
Spring Boot 3+ running on Kubernetes usually enables these automatically when it detects a Kubernetes environment.
Expose health
Then
Health Groups¶
Spring Boot internally groups indicators.
Health
├── Liveness
│ └── LivenessState
│
└── Readiness
├── Database
├── Redis
├── Kafka
└── Disk Space
Example
Kubernetes Configuration¶
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
initialDelaySeconds: 15
periodSeconds: 5
Interview Question¶
Why not use only one health endpoint?
Because the actions are different.
If the database is temporarily unavailable:
- Restarting the application wastes time and resources because the problem is external.
- It's better to mark the application as Not Ready, stop sending it traffic, and wait for the dependency to recover.
If the JVM is deadlocked:
- The application cannot recover on its own.
- Kubernetes should restart it, which is exactly what the liveness probe triggers.
Startup Probe¶
Another probe interviewers sometimes ask about is the startup probe.
It's useful for applications with slow startup times.
A startup probe delays liveness and readiness checks until the application has finished starting. This prevents Kubernetes from repeatedly restarting a healthy application that simply takes a long time to initialize.