OpenShift Health Checks: Liveness, Readiness and Startup Probes

Learn how OpenShift monitors Spring Boot applications using Liveness, Readiness, and Startup Probes. Understand probe architecture, Spring Boot Actuator integration, self-healing, zero-downtime deployments, and enterprise best practices.

Introduction

Imagine your Spring Boot application has been successfully deployed to OpenShift.

After a few hours:

Database connections become unavailable.
JVM enters a deadlock.
Memory usage continues increasing.
External APIs stop responding.
The application stops serving requests.

How does OpenShift know that the application is unhealthy?

How does it recover automatically?

The answer is Health Probes.

OpenShift continuously checks the health of every application using three probe types:

Startup Probe
Liveness Probe
Readiness Probe

These probes allow OpenShift to automatically restart unhealthy containers, prevent traffic from reaching unhealthy Pods, and enable zero-downtime deployments.

Learning Objectives

By the end of this article, you will understand:

Why health checks are important
Liveness Probe
Readiness Probe
Startup Probe
Spring Boot Actuator Integration
Self-Healing
Rolling Deployments
Enterprise Best Practices

Why Health Checks?

Without probes:

Dead applications continue running.
Users receive errors.
Traffic reaches unhealthy Pods.
Failed deployments remain active.

Health probes allow OpenShift to automatically detect and recover from failures.

Health Check Architecture

flowchart LR
    A[OpenShift Kubelet]
    B[Health Probe]
    C[Spring Boot Pod]
    D[Actuator Health Endpoint]

    A --> B
    B --> C
    C --> D

Probe Lifecycle

flowchart LR
    A[Container Starts]
    B[Startup Probe]
    C[Readiness Probe]
    D[Liveness Probe]

    A --> B
    B --> C
    C --> D

Three Probe Types

Probe	Purpose
Startup	Has the application finished starting?
Readiness	Can the application receive traffic?
Liveness	Is the application still alive?

Startup Probe

Startup Probe is executed only during application startup.

It prevents OpenShift from restarting applications that require a long startup time.

Examples:

Spring Boot applications
Hibernate initialization
Cache loading
Large JVM startup
Database migrations

Startup Probe Flow

flowchart LR
    A[Pod Created]
    B[Application Starting]
    C[Startup Probe]
    D{Application Started?}
    E[Enable Readiness]
    F[Retry]

    A --> B
    B --> C
    C --> D
    D -->|Yes| E
    D -->|No| F

Startup Probe Configuration

startupProbe:
  httpGet:
    path: /actuator/health
    port: 8080

  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 30

Readiness Probe

Readiness determines whether the application can receive user traffic.

If the probe fails:

Pod remains running
Service removes the Pod
No new requests are routed

Readiness Flow

flowchart LR
    A[Client]
    B[OpenShift Service]
    C{Readiness OK?}
    D[Healthy Pod]
    E[Unhealthy Pod]

    A --> B
    B --> C
    C -->|Yes| D
    C -->|No| E

Readiness Configuration

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080

  initialDelaySeconds: 15
  periodSeconds: 10

Liveness Probe

Liveness checks whether the application is still functioning.

If the probe fails repeatedly:

OpenShift kills the container.
A new container is started automatically.

Liveness Flow

flowchart LR
    A[Running Pod]
    B[Liveness Probe]
    C{Healthy?}
    D[Continue Running]
    E[Restart Container]

    A --> B
    B --> C
    C -->|Yes| D
    C -->|No| E

Liveness Configuration

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080

  initialDelaySeconds: 30
  periodSeconds: 15

Spring Boot Actuator

Add dependency

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

Enable Health Endpoints

management.endpoint.health.probes.enabled=true

management.endpoints.web.exposure.include=health

management.health.livenessState.enabled=true

management.health.readinessState.enabled=true

Available Endpoints

Endpoint	Purpose
/actuator/health	Overall Health
/actuator/health/liveness	Liveness
/actuator/health/readiness	Readiness

Spring Boot Health Architecture

flowchart LR
    A[Spring Boot]
    B[Actuator]
    C[Liveness]
    D[Readiness]

    A --> B
    B --> C
    B --> D

Self-Healing

If an application enters a deadlock:

flowchart LR
    A[Deadlocked Pod]
    B[Liveness Failed]
    C[Kubelet]
    D[Restart Container]

    A --> B
    B --> C
    C --> D

No manual intervention is required.

Rolling Deployment

flowchart LR
    A[Old Pod]
    B[New Pod]
    C[Readiness Successful]
    D[Traffic Shift]

    A --> B
    B --> C
    C --> D

Traffic is routed only after the new Pod becomes ready.

Banking Example

flowchart LR
    A[Customer]
    B[Route]
    C[Payment Service]
    D[(Oracle Database)]

    A --> B
    B --> C
    C --> D

If Oracle becomes unavailable:

Readiness Probe fails.
OpenShift stops routing traffic.
Healthy Pods continue serving requests.

Enterprise Health Check Architecture

flowchart TD
    A[OpenShift Router]
    B[Service]
    C[Pod 1]
    D[Pod 2]
    E[Pod 3]

    B --> C
    B --> D
    B --> E

    A --> B

Only Pods passing the Readiness Probe receive traffic.

Verify Health

Browser

http://localhost:8080/actuator/health

OpenShift

curl http://payment-service:8080/actuator/health

Useful Commands

View Pods

oc get pods

Describe Pod

oc describe pod payment-service

View Events

oc get events

View Logs

oc logs payment-service

Common Problems

Pod Restarting Frequently

Possible causes:

Liveness Probe timeout
OutOfMemoryError
Deadlock
Wrong probe path

Readiness Always Failing

Verify:

Database connectivity
External API availability
Actuator endpoint
Port configuration

Startup Probe Timeout

Increase:

failureThreshold: 60

Large Spring Boot applications often require longer startup times.

Production Best Practices

Enable all three probe types.
Use Spring Boot Actuator.
Separate readiness and liveness endpoints.
Keep health checks lightweight.
Avoid expensive database queries in probes.
Configure realistic timeout values.
Test probe failures before production.
Monitor probe failures using Prometheus.
Use rolling deployments.
Combine probes with Horizontal Pod Autoscaling.

Common Mistakes

❌ Using the same endpoint for every probe without understanding the differences.

❌ Performing expensive database operations inside health checks.

❌ Restarting applications due to slow startup.

❌ Ignoring readiness failures.

❌ Using very short timeout values.

Advantages

Automatic recovery
Self-healing applications
Zero-downtime deployments
Faster failure detection
Improved availability
Better user experience
Kubernetes-native health monitoring
Enterprise-ready operations

Summary

Health probes are essential for running reliable Spring Boot applications on OpenShift.

Key takeaways:

Startup Probes protect slow-starting applications.
Readiness Probes determine whether Pods receive traffic.
Liveness Probes detect unhealthy applications and trigger automatic restarts.
Spring Boot Actuator integrates seamlessly with OpenShift health checks.
Properly configured probes improve reliability, resilience, and zero-downtime deployments.

Interview Questions

What is the difference between Liveness and Readiness Probes?
Why was the Startup Probe introduced?
What happens when a Readiness Probe fails?
What happens when a Liveness Probe fails?
Which Spring Boot endpoints are used for probes?
Why shouldn't probes execute expensive database queries?
How do health probes enable self-healing?
How do probes support rolling deployments?
How does OpenShift determine whether a Pod should receive traffic?
What are the production best practices for configuring health probes?