How do reactive health checks differ from blocking ones, and what happens to a blocking HealthIndicator in a WebFlux app?

## Blocking vs reactive foundations Spring MVC uses a thread-per-request model; blocking a request thread only hurts that request. **Spring WebFlux** runs on a small pool of **Netty event-loop threads**; blocking one of them stalls many concurrent requests. So Actuator provides a **reactive health API** for WebFlux apps. ## ReactiveHealthIndicator ```java public interface ReactiveHealthIndicator extends ReactiveHealthContributor { Mono<Health> health(); } ``` `Mono<Health>` is Project Reactor's container for **0..1 asynchronous value**. Returning a `Mono` means the check is **deferred and non-blocking**: you compose it from reactive clients (`R2DBC`, reactive Redis/Mongo, `WebClient`) so no thread is parked waiting on I/O. ## AbstractReactiveHealthIndicator The convenience base class mirrors the blocking `AbstractHealthIndicator`: ```java protected abstract Mono<Health> doHealthCheck(Health.Builder builder); ``` Its `health()` calls `doHealthCheck`, and any error signal (`onError`) is translated into a **DOWN** with the exception recorded — the same auto-DOWN behaviour, in the reactive domain. Use it so you don't hand-write `onErrorResume`. ## Composition, reactively The contributor tree has reactive twins: - `ReactiveHealthContributor` — marker - `ReactiveHealthIndicator` — leaf - `CompositeReactiveHealthContributor` — branch (`fromMap(...)`) - `ReactiveHealthContributorRegistry` — the registry Actuator walks in WebFlux apps ## What happens to blocking indicators in WebFlux This is the key interview point. A WebFlux app can still have plenty of plain **blocking `HealthIndicator`** beans (yours, or auto-configured ones). Actuator does **not** ignore them: it **adapts** each blocking `HealthIndicator` into a reactive one and runs the blocking `health()` on a **bounded elastic scheduler** — `Schedulers.boundedElastic()` (historically the "elastic" scheduler) — via `subscribeOn`. That keeps the blocking call **off the event loop**. The adapter is applied so both reactive and blocking contributors coexist in the reactive registry. Conversely, in a **Spring MVC** app there is no reactive endpoint; a `ReactiveHealthIndicator` would just be treated as a regular contributor whose `Mono` is subscribed/blocked as needed. The reactive API is really about WebFlux. ## Aggregation and HTTP mapping are unchanged Worst-status-wins aggregation (`StatusAggregator`), the DOWN→503 / UP→200 mapping, `show-details`, and health groups all behave **identically**. Reactivity only changes *how* each leaf is executed, not the semantics of the result. ## Gotchas / principal-level concerns - **Never block inside a `ReactiveHealthIndicator`** (no `.block()`, no JDBC). Blocking-detection tools (BlockHound) will flag it; in production it silently starves the event loop. - **Always add a timeout**: `.timeout(Duration.ofSeconds(2))` so a hung dependency yields DOWN quickly instead of stalling every probe. A slow health check can itself cause a readiness probe to fail and trigger pod restarts. - **Backpressure/parallelism**: composites subscribe to children; a badly-behaved reactive child can delay the whole tree — bound each child. - **Scheduler saturation**: many adapted blocking indicators all hitting `boundedElastic` under frequent probes can exhaust that pool; prefer truly reactive clients for hot checks, and keep probe intervals sane. - **Don't mix concerns**: readiness checks that gate traffic should be cheap and local; deep dependency checks belong in a separate group so a downstream blip doesn't cordon your pod. ## When to use Use `ReactiveHealthIndicator`/`AbstractReactiveHealthIndicator` whenever the underlying client is reactive and the app is WebFlux. If your only client is blocking, a plain `HealthIndicator` is fine — Spring will schedule it safely — but wrap it in a timeout regardless.