Health endpoint checker

Health and readiness routes met during the crawl, or while the API endpoints were being observed. Nothing is enumerated and no path list is tried.

The status code returned, which is what a monitoring service acts on.

The shape of the response body: whether it is a short status or a structured document describing components.

Whether the body discloses versions, hostnames or dependency detail — which is the part that turns a convenience into a disclosure.

A status code that distinguishes healthy from unhealthy, because that is the signal every monitoring service is built around.

A short status string. Two or three words are enough for a human reading it during an incident.

Nothing else. No version numbers, no internal hostnames, no database names, no queue depths, no dependency list.

The detailed version of all that is worth having — and it belongs behind authentication, or on an internal network interface, not on the same public route a monitoring service polls every thirty seconds.

Most frameworks and orchestration tooling ship a health route that reports component status, because that is genuinely useful when the route is internal.

The route then becomes public the day the service is put behind a load balancer and nobody revisits the default, since it works perfectly and nothing draws attention to it.

The result is a public URL that names your database engine, your cache, your message broker and frequently their versions — a description of the stack that no amount of header hardening elsewhere will offset.

Splitting the route in two is the usual fix: a public one that answers with a status code and a word, and a detailed one that requires a credential.

Only endpoints already met are reported. No enumeration is performed, so a health route on an unconventional path that nothing references is not found.

A public health endpoint is not reported as a vulnerability, because it is not one. What is reported is what it discloses.

Whether the endpoint's answer is accurate — whether a healthy response really means the service is healthy — cannot be established from outside.

A health route requiring authentication returns a refusal, and the check records exactly that rather than treating the refusal as a failure.

`devops.health_endpoints` reports the health and readiness endpoints already met during the crawl or the API observation, without enumerating anything.

`devops.observability_public` and `monitoring.status_page` complete the picture of what is publicly visible about how the service is watched.

`api.errors.disclosure` covers the adjacent case: technical detail leaking through an error response rather than through a status route.

After moving a service behind a load balancer or an ingress, which is the change that quietly makes an internal route public.

After a framework or orchestration upgrade, since both tend to reinstate a default health route with a more detailed body than the one you had configured.

Whenever a dependency is added, because component-reporting health routes list dependencies automatically and the new one appears without anyone deciding it should.