Health Check¶
Test or assessment — instantiates Observability Instrumentation
Runs a repeatable test that indicates whether a service, asset, process, or organism is functioning within an acceptable range.
A Health Check is a self-contained, repeatable test that a thing runs on itself (or that is run against it) to return a single, interpretable verdict: is this functioning within its acceptable range, or not? Its defining move is compression — it collapses a bundle of internal conditions into a small ordered status (healthy / degraded / unhealthy, or pass / fail) that a supervisor, operator, or clinician can read at a glance and treat as an authoritative statement of fitness. Unlike a stream of raw measurements, a health check has already decided what "within range" means and bakes that judgement into its output. It answers exactly one question — "is this okay right now?" — and answers it the same way every time it is invoked, which is what makes it trustworthy as a gate.
Example¶
Before a commercial airliner pushes back from the gate, its avionics run a built-in test sequence: each major system — hydraulics, flight controls, pressurization, the sensors themselves — is exercised against a known reference and reports pass or fault to a consolidated status page. The crew do not read raw pressures and voltages; they read a screen that says, in effect, these systems are within limits, that one is degraded, this one is a no-go. The check has an authoritative range built in: a hydraulic pressure that would be unremarkable in flight might register as a fault on the ground because the acceptable band is defined per phase. A "no-go" result is not advice — it is a verdict that stops the flight. That is the essence of a health check: a repeatable test whose output is a fitness judgement, not a number to be interpreted later.
How it works¶
The check names a small set of conditions that together define "functioning," each with an explicit acceptable range, and evaluates them on demand or on a fixed cadence. Its distinguishing design choices are about the verdict: whether the statuses are ordered (a graded scale rather than a bare boolean), whether a shallow check confirms only that the thing is alive versus a deep check that confirms it can actually do its job, and how aggressively a single failing sub-condition is allowed to darken the whole result. The output is deliberately terminal — it is meant to be consumed as a state, not re-derived. A crucial subtlety is guarding against the false green: a check that reports healthy while the thing is in fact broken because it only tested something shallow and incidental.
Tuning parameters¶
- Depth: shallow vs. deep — whether the check merely confirms the subject responds, or exercises its real function end to end. Deeper checks catch subtle faults but cost more and can themselves perturb the subject.
- Acceptable-range width — how wide the "within limits" band is. Narrow bands flag early degradation but raise false-fail rates; wide bands pass quietly until failure is advanced.
- Verdict granularity — a bare pass/fail versus a graded healthy/degraded/unhealthy scale. Grades preserve nuance but demand that each level carry a defined meaning and a defined response.
- Cadence — on-demand, pre-use, or continuous re-testing. Frequent checks catch fast changes but add load and can mask trends behind a stream of independent verdicts.
When it helps, and when it misleads¶
Its strength is that it turns a diffuse worry — is this thing okay? — into a crisp, repeatable, gate-able answer, which is exactly what a supervisor loop or a go/no-go decision needs. Its dangerous failure is the false green: a shallow check that passes while the real function is broken, giving false confidence precisely where confidence is load-bearing.[n1] The classic misuse is treating a check that confirms the thing is running as if it confirmed the thing is working — the software distinction between liveness and readiness is the same trap in another domain. The guarding discipline is to make the check test the function that actually matters, to keep the acceptable range honest as the subject ages, and to prefer a graded verdict that can say degraded rather than forcing a brittle binary that only flips once failure is total.
How it implements the components¶
observability_question— it is built around one sharply posed question ("is this functioning within acceptable range?") and returns an answer to precisely that, on demand.baseline_and_threshold— the acceptable range is embedded in the check: each sub-condition carries the limits that separate pass from fault.signal_semantics— the ordered verdict has a defined meaning; "healthy," "degraded," and "no-go" each state what they do and do not assert about the subject.
It does not gather signals from outside the subject or spread its testing over a schedule to estimate typical behavior — those are proxy_signal and sampling_granularity_policy, which belong to its near-twin Synthetic Probe. A health check is an internal, on-demand fitness verdict; a synthetic probe fires an external, representative-by-sampling transaction and reports how the outside world experiences the system.
Related¶
- Instantiates: Observability Instrumentation — it supplies an interpreted fitness state ready to gate a decision.
- Sibling mechanisms: Synthetic Probe · Telemetry · Sensor Array · Process Metric · Social Indicator · Trace Instrumentation · Alerting Rule · Audit Log · Dashboard
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Health Check operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it runs a repeatable test that indicates whether a service, asset, process, or organism is functioning within an acceptable range
Independent corroboration: The frozen evidence defines Health Check as 'Runs a repeatable test that indicates whether a service, asset, process, or organism is functioning within an acceptable range', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Experiment, Test & Rehearsal — It evaluates the subject's present condition rather than deliberately exposing it to a constructed challenge.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: The page's operational distinction between liveness and readiness is characteristic of software service operations and distributed computing.
Related originating lineages:
- Engineering & Design — Condition monitoring and go/no-go functional checks arose independently in maintenance and reliability engineering.
- Medicine & Healthcare — Clinical examination independently formalized repeatable checks of whether an organism is functioning within acceptable bounds.
Review resolution: Kubernetes separately specifies liveness, readiness, and startup probes as operational tests of a running workload. That direct service-operations lineage matches the mechanism more closely than the older clinical metaphor, so computer_science is primary; medicine and reliability engineering remain genuinely convergent formative lineages. The retained alternate domains identify independent or materially shaping provenance, not downstream reach alone. domain_reach=universal because the mechanism is portable across essentially any field. The entry generalizes an established mechanism without inventing a new cross-domain composite.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- https://kubernetes.io/docs/concepts/workloads/pods/probes/ — Kubernetes documentation defining software liveness, readiness, and startup probes.
Notes¶
[n1] In service operations the standard guard against a false green is separating a liveness check (the process is running) from a readiness check (the process can actually serve requests). The same distinction generalizes: a health check is only as trustworthy as the gap between "is it alive" and "can it do its job" is small. ↩