Spring Boot Actuator Health Checks: Liveness, Readiness & Health Endpoints Explained

Modern applications are no longer deployed as a single application running on one server. Today, applications are built using microservices and deployed inside Docker containers, which are managed by container orchestration platforms like Kubernetes. These platforms automatically start, stop, restart, and scale applications based on demand.

But this raises an important question:

How does Kubernetes know whether a running application is healthy?

A container may still be running, but the application inside it might have crashed. Similarly, an application might have started successfully but still be initializing its database connections or loading configuration files, making it unable to serve client requests.

This is where Liveness and Readiness probes come into the picture. These health checks help Kubernetes determine the current state of an application and decide whether it should restart the application or route traffic to it.

In this article, we’ll understand these concepts from scratch using simple explanations, real-world examples, Spring Boot Actuator, and interview-oriented insights.

---

Why Do We Need Health Checks?

Imagine you deploy a Spring Boot microservice inside a Docker container.

Spring Boot Application
          │
          ▼
   Docker Container
          │
          ▼
     Kubernetes

Once deployed, Kubernetes continuously manages your application.

Its responsibilities include:

• Restarting crashed applications
• Replacing unhealthy containers
• Scaling applications up or down
• Distributing client requests among healthy instances

However, Kubernetes cannot inspect your application’s source code to determine whether it is working correctly.

It needs the application itself to report its health.

This is exactly what health probes are designed for.

---

Understanding Application Health

Many beginners assume that if a Spring Boot application starts successfully, it is healthy.

That’s not always true.

Consider the following startup sequence:

Application Starts
        │
        ▼
Tomcat Starts
        │
        ▼
Spring Beans Created
        │
        ▼
Database Connection
        │
        ▼
RabbitMQ Connection
        │
        ▼
Cache Initialization
        │
        ▼
Ready to Accept Requests

The application process may already be running while it is still connecting to the database or RabbitMQ.

Similarly, the application may continue running even if RabbitMQ suddenly becomes unavailable.

Therefore, “application running” and “application healthy” are not always the same thing.

---

What is a Liveness Probe?

A Liveness Probe answers one simple question:

“Is this application still alive?”

It does not check whether the application is ready to process requests.

Instead, it simply verifies whether the application is still running correctly.

If the liveness check fails, Kubernetes assumes that the application has become unhealthy and attempts to recover it by restarting the container.

The workflow looks like this:

Kubernetes
      │
      ▼
Is Application Alive?
      │
 ┌────┴────┐
 │         │
Yes       No
 │         │
 │     Restart Container
 │
Continue Running

In simple words:

• Liveness checks determine whether the application should continue running.
• If the answer is “No,” Kubernetes restarts the container.

---

Real-Life Example of Liveness

Imagine a boxer sitting in the corner before a match.

Boxer Sitting

✓ Breathing
✓ Drinking Water
✓ Listening to Coach

Although the boxer is not fighting yet, he is clearly alive.

Similarly, a Spring Boot application may not be serving requests yet, but it is still running correctly.

This represents the Liveness state.

---

What is a Readiness Probe?

A Readiness Probe answers a different question:

“Is this application ready to receive client requests?”

An application may already be alive but still be performing background tasks like:

• Connecting to the database
• Loading configuration
• Initializing caches
• Establishing RabbitMQ connections
• Creating thread pools

During this time, sending user requests to the application could result in failures.

Instead of routing traffic immediately, Kubernetes waits until the application reports that it is ready.

The workflow becomes:

Kubernetes
      │
      ▼
Is Application Ready?
      │
 ┌────┴─────┐
 │          │
Yes        No
 │          │
Route      Wait
Traffic

Unlike liveness, a failed readiness check does not restart the application.

Instead, Kubernetes simply removes that instance from the load balancer until it becomes ready again.

---

Real-Life Example of Readiness

Consider the same boxer.

Initially:

Boxer Sitting

Alive ✓
Ready ✗

After warming up, the boxer walks to the center of the ring.

Standing

Gloves Ready

Alive ✓
Ready ✓

Now he is both alive and ready to fight.

The same concept applies to microservices.

---

Liveness vs Readiness

Although these terms sound similar, they serve completely different purposes.

Liveness	Readiness
Checks whether the application is alive	Checks whether the application is ready to accept traffic
Failed check causes container restart	Failed check stops traffic routing
Used for self-healing	Used for traffic management
Answers “Should Kubernetes restart this application?”	Answers “Can Kubernetes send requests to this application?”

Understanding this difference is one of the most common interview topics for backend developers.

---

Spring Boot Actuator Health Endpoints

Spring Boot provides built-in support for health monitoring through Spring Boot Actuator.

After adding the Actuator dependency, several health endpoints become available.

The most common endpoint is:

/actuator/health

This endpoint returns the overall health status of the application.

Example:

{
  "status": "UP"
}

Spring Boot also exposes dedicated endpoints for Kubernetes.

/actuator/health/liveness

/actuator/health/readiness

These endpoints allow Kubernetes to independently determine whether the application is alive and whether it is ready to serve requests.

---

What Does /actuator/health Actually Check?

Many developers assume that /actuator/health only checks whether the Spring Boot application is running.

That is not true.

Instead, Spring Boot combines the results of multiple Health Indicators.

Internally, it performs checks like:

Application
      │
      ├── JVM Health
      ├── Disk Space
      ├── Database
      ├── RabbitMQ
      ├── Redis
      ├── Kafka
      ├── Custom Health Checks
      ▼
Overall Health

Each component reports either:

UP

or

DOWN

Spring Boot aggregates these results and returns the final application health.

---

Why Did RabbitMQ Make the Health Endpoint Return DOWN?

This is one of the most common questions beginners ask.

Suppose your Config Server uses RabbitMQ.

Config Server
      │
      ▼
RabbitMQ

When you call:

/actuator/health

Spring Boot automatically tries to establish a connection with RabbitMQ using the built-in RabbitMQ Health Indicator.

If RabbitMQ is running:

RabbitMQ

↓

Connection Successful

↓

Status = UP

If RabbitMQ is stopped:

RabbitMQ

↓

Connection Failed

↓

Status = DOWN

Since RabbitMQ is considered an important dependency, the overall health becomes:

Application    UP

RabbitMQ       DOWN

Disk           UP

Overall        DOWN

Notice something important here.

The Spring Boot application is still running.

It is not crashed.

However, because one of its critical dependencies is unavailable, the overall health endpoint reports DOWN.

---

Does Spring Boot Check Other Microservices?

A common misconception is that /actuator/health automatically checks services like:

• User Service
• Cart Service
• Order Service
• Payment Service

The answer is No.

By default, Spring Boot only checks:

• The current application
• Dependencies directly connected to the application
• Built-in Health Indicators

For example:

User Service
      │
      ▼
Database

Spring Boot can automatically verify the database connection.

However, it will not automatically call:

Cart Service

Order Service

Payment Service

If you want to monitor another microservice, you must create a custom Health Indicator that explicitly calls that service.

This design prevents unnecessary network calls and avoids creating circular health dependencies between microservices.

---

Enabling Liveness and Readiness in Spring Boot

Spring Boot makes enabling these probes straightforward.

First, add the Actuator dependency.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Next, enable health probes inside application.yml.

management:
  health:
    livenessstate:
      enabled: true
    readinessstate:
      enabled: true

  endpoint:
    health:
      probes:
        enabled: true

Once configured, the following endpoints become available:

/actuator/health

/actuator/health/liveness

/actuator/health/readiness

These endpoints are commonly used by Kubernetes to monitor application health.

---

How Kubernetes Uses These Probes

Suppose you deploy three instances of your application.

Pod 1

Pod 2

Pod 3

Kubernetes continuously checks each pod.

If Liveness Fails

Application Dead

↓

Restart Container

If Readiness Fails

Application Alive

↓

Not Ready

↓

Remove from Load Balancer

↓

Do Not Send Traffic

Once the readiness probe becomes successful again, Kubernetes automatically starts routing requests to that instance.

---

Best Practices

When implementing health probes in production, follow these recommendations:

• Use Liveness only to determine whether the application process is healthy.
• Use Readiness to verify external dependencies required to serve requests.
• Avoid placing expensive database queries inside health checks.
• Do not make unnecessary remote service calls inside liveness probes.
• Keep health checks lightweight and fast.

---

Frequently Asked Interview Questions

1. What is the difference between Liveness and Readiness?

Liveness determines whether the application is alive and should continue running. Readiness determines whether the application is ready to receive client requests.

---

2. What happens if the Liveness Probe fails?

Kubernetes considers the application unhealthy and restarts the container.

---

3. What happens if the Readiness Probe fails?

The application is removed from the load balancer, but it is not restarted.

---

4. Does /actuator/health check other microservices automatically?

No. It only checks the current application and its registered health indicators. Other microservices must be checked using custom health indicators if required.

---

5. Why did /actuator/health return DOWN when RabbitMQ was stopped?

Because Spring Boot automatically registered a RabbitMQ Health Indicator. When the connection to RabbitMQ failed, the overall application health was reported as DOWN, even though the application itself was still running.

---

Conclusion

Liveness and Readiness probes are fundamental concepts in cloud-native application development. While they appear similar, they solve two completely different problems.

A Liveness Probe ensures that the application is still running and enables Kubernetes to automatically recover failed applications by restarting containers.

A Readiness Probe ensures that an application receives client traffic only after it has completed all required initialization tasks and is fully prepared to handle requests.

Spring Boot simplifies the implementation of these probes through Spring Boot Actuator, which exposes dedicated health endpoints that integrate seamlessly with Docker and Kubernetes. Understanding how these probes work—and how they differ from the overall /actuator/health endpoint—will help you build more reliable microservices and confidently answer one of the most frequently asked backend interview questions.