skip to content

How do you read the current liveness/readiness state programmatically in Spring Boot, and what are the possible state values?

level: middleimportance: should knowfreq 45%

answer

  1. ApplicationAvailability bean = read side
  2. LivenessState: CORRECT / BROKEN
  3. ReadinessState: ACCEPTING_TRAFFIC / REFUSING_TRAFFIC
  4. AvailabilityState = marker interface
  5. read via getter, change via event

basics

~10 s

Inject the ApplicationAvailability bean and call getLivenessState() or getReadinessState(). Liveness is CORRECT or BROKEN; readiness is ACCEPTING_TRAFFIC or REFUSING_TRAFFIC. Both implement the AvailabilityState interface.

solid answer

~40 s

Spring Boot exposes an `ApplicationAvailability` bean (auto-configured). Inject it and call `getLivenessState()`, which returns a `LivenessState` enum (`CORRECT` or `BROKEN`), or `getReadinessState()`, which returns a `ReadinessState` enum (`ACCEPTING_TRAFFIC` or `REFUSING_TRAFFIC`). Both enums implement the marker interface `AvailabilityState`. You can also call the generic `getState(Class<? extends AvailabilityState>)` for custom availability dimensions you define yourself. The state is what the '/actuator/health/liveness' and '/actuator/health/readiness' probe groups report — `BROKEN` and `REFUSING_TRAFFIC` map to a DOWN/OUT_OF_SERVICE health status. You read state to make decisions (e.g., a scheduled job that should pause when the app is refusing traffic), and you change state by publishing an `AvailabilityChangeEvent` rather than mutating the bean directly.

code

java · 22 lines
java
import org.springframework.boot.availability.ApplicationAvailability;
import org.springframework.boot.availability.LivenessState;
import org.springframework.boot.availability.ReadinessState;
import org.springframework.stereotype.Component;

@Component
public class AvailabilityReader {

    private final ApplicationAvailability availability;

    public AvailabilityReader(ApplicationAvailability availability) {
        this.availability = availability;
    }

    public boolean healthyInternally() {
        return availability.getLivenessState() == LivenessState.CORRECT;
    }

    public boolean acceptingTraffic() {
        return availability.getReadinessState() == ReadinessState.ACCEPTING_TRAFFIC;
    }
}

go deeper

for a junior

Know the two getters and the four enum values.

for a middle

Explain the read-only nature and the marker-interface relationship; map states to probe status.

for a senior

Discuss custom AvailabilityState dimensions and how health indicators translate state to Health.

for a principal

Consider using availability state as a coordination primitive across components without coupling to Actuator internals.

## The ApplicationAvailability abstraction Spring Boot models availability as a small state machine you can both **read** and **update**. The read side is the `org.springframework.boot.availability.ApplicationAvailability` interface, auto-configured as a bean. Key methods: - `LivenessState getLivenessState()` - `ReadinessState getReadinessState()` - `<S extends AvailabilityState> S getState(Class<S> stateType)` — generic, for custom dimensions - `AvailabilityChangeEvent<?> getLastChangeEvent(Class<S> stateType)` — the last event that set a state ## The state enums Both are enums implementing the marker interface `AvailabilityState`: **`LivenessState`** - `CORRECT` — internal state is fine (probe UP) - `BROKEN` — unrecoverable internal state (probe DOWN -> Kubernetes restarts) **`ReadinessState`** - `ACCEPTING_TRAFFIC` — ready to serve (probe UP) - `REFUSING_TRAFFIC` — not ready / draining (probe OUT_OF_SERVICE -> pulled from load balancer) ## Reading state ```java @Component class StateReader { private final ApplicationAvailability availability; StateReader(ApplicationAvailability availability) { this.availability = availability; } boolean isServing() { return availability.getReadinessState() == ReadinessState.ACCEPTING_TRAFFIC; } } ``` ## How state maps to the probe endpoint The liveness/readiness health groups are backed by `LivenessStateHealthIndicator` and `ReadinessStateHealthIndicator`, which translate the current `AvailabilityState` into a Health status. So the probe HTTP response is a direct reflection of what `ApplicationAvailability` currently holds. ## Custom availability dimensions You aren't limited to the two built-ins. You can define your own enum implementing `AvailabilityState` and track it via `getState(MyState.class)` and events. This is useful for internal coordination but is not wired to Kubernetes probes unless you add your own health group. ## Gotchas - Don't mutate state by trying to 'set' it — `ApplicationAvailability` is read-only. You change it by publishing an `AvailabilityChangeEvent`. - The initial states after startup are `LivenessState.CORRECT` and `ReadinessState.ACCEPTING_TRAFFIC` (readiness flips to ACCEPTING only after the application is fully started / `ApplicationReadyEvent`). - `getLastChangeEvent(...)` is handy in tests to assert what last drove a state change.

  • What are the initial states right after the application starts?
    LivenessState.CORRECT and ReadinessState.ACCEPTING_TRAFFIC. Readiness only reaches ACCEPTING_TRAFFIC once the application is fully started (around ApplicationReadyEvent); during shutdown it flips to REFUSING_TRAFFIC.
  • Can you track availability dimensions beyond liveness and readiness?
    Yes. Define your own enum implementing AvailabilityState, read it with getState(MyState.class), and drive it with AvailabilityChangeEvent. It won't affect Kubernetes probes unless you wire it into a health group yourself.

saying these in an interview costs you the question

  • Thinking ApplicationAvailability has setters to change state directly
  • Mixing up the enum values (e.g., saying liveness is UP/DOWN or readiness is CORRECT/BROKEN)
  • Not knowing AvailabilityState is the common marker interface for both enums

context

resolving links…