Interface HealthPluginOptions

Include indicator data and latency in HTTP responses. Defaults to false. Only the HTTP bodies change: programmatic reports stay full, and diagnostics keep recording minimized observations without indicator data.

The opt-in health-observation policy (M98d). Absent by default: the plugin registers an inert, disabled source under CAPABILITIES.HEALTH_DIAGNOSTICS and performs no capture. When present, the plugin retains the latest minimized outcome per approved indicator alias and, when scheduled is present, performs bounded scheduled checks. This never changes the /health, /live, or /ready behavior.

Endpoint path configuration.

Defaults to { health: '/health', live: '/live', ready: '/ready' }.

Additional indicators to register.

An instance entry is registered during register(), unchanged from the pre-factory behaviour. A factory entry is resolved and registered at the start of the onInit phase — before the CAPABILITIES.HEALTH_INDICATOR contribution drain — so it can resolve a capability registered by a plugin that registers after this one. A factory that throws rejects start(), naming the option and the entry.

Defaults to [].

Deadline applied independently to every selected indicator, in milliseconds (M90b). Must be a positive finite number; anything else — zero, negative, NaN, Infinity — throws at plugin construction. The identical check runs in the barrel-exported HealthService constructor, so constructing the service directly cannot bypass it.

An indicator that has not settled within the deadline is recorded as { status: 'down', data: { reason: 'timeout' } }; one that rejects is recorded as { status: 'down', data: { reason: 'error' } }. Either way the report itself stays bounded, so a dead dependency can no longer leave the whole endpoint pending.

Override contributor readiness membership by exact indicator name. Lists must contain non-empty strings, cannot overlap, and cannot name self. Unmatched names produce one count-only warning at initialization.