This page defines the health vocabulary as Knock materialises it. The model follows MicroProfile Health 4.0; implementation choices are described in Internals.

Health check

A health check is an application-supplied diagnostic. It implements org.eclipse.microprofile.health.HealthCheck and returns a HealthCheckResponse carrying a name, a status (UP/DOWN) and an optional data map. A check is associated with exactly one probe through its qualifier.

Probe type

A probe is a category of checks answering a specific operational question. Knock models them with the ProbeType enum:

ProbeType Selects

LIVENESS

Checks qualified with @Liveness.

READINESS

Checks qualified with @Readiness.

STARTUP

Checks qualified with @Startup.

ALL

Every registered check (backs GET /health).

Registry

The registry holds the registered checks and returns them filtered by probe type. The contract is the HealthCheckRegistry interface (in knock-api); the standalone implementation is KnockHealthCheckRegistry (in knock-core). It is virtual-thread friendly: state lives in a ConcurrentHashMap, never guarded by synchronized.

Aggregation

Aggregation reduces a set of individual responses to a single status. The rule (spec §3.2): the group is DOWN if at least one check is DOWN; an empty group is UP; an exception is folded into a DOWN check rather than being propagated. KnockAggregator implements this and produces a HealthSnapshot.

Snapshot

A snapshot (HealthSnapshot, an immutable record) captures the result of an aggregation: the probe type, the overall status, and the immutable list of individual checks. It is the input handed to serialisation, decoupling computation from rendering.

JSON contract

The JSON contract (spec §3.1) is fixed:

  • top-level status (UP/DOWN) and a checks array;

  • each entry has name, status, and an optional data object;

  • data is omitted when empty;

  • HTTP 200 when UP, 503 when DOWN.

Knock renders it with Jakarta JSON-P only — no StringBuilder, no third-party JSON library. HealthReport wraps the serialised payload together with the HTTP status.

CDI discovery

In a CDI deployment, checks are discovered by a Build Compatible Extension (HealthCheckCdiExtension) running on Vauban. It validates the single-qualifier rule at build time, then HealthCheckRegistrar registers each discovered bean into the registry when @Initialized(ApplicationScoped.class) fires. Outside CDI, the same registry is fed manually — the core never depends on a container.

Module boundaries

Knock keeps responsibilities split so the core stays dependency-light:

  • knock-api — re-exported MicroProfile Health spec types + Knock SPI (ProbeType, HealthCheckRegistry, Knock).

  • knock-core — registry, aggregation, JSON-P serialisation, runtime facade. Pure Java SE.

  • knock-cdi-vauban — CDI discovery and auto-registration.

  • knock-jaxrs — the /health* Jakarta REST resource.

Internal packages (io.vidocq.knock.internal, io.vidocq.knock.cdi.internal) are never exported.

See also

  • Internals — how these concepts are implemented.

  • Reference — artefacts, packages, endpoints.