Glossary
Health check endpoint
A health check endpoint is a route a service exposes so that monitoring, a load balancer or an orchestrator can ask whether it is working. It answers with a status code that means healthy or not, and usually a very short body. The distinction worth knowing is between liveness — is this process alive — and readiness — is it able to serve traffic right now, which are different questions with different consequences when the answer is no.
Liveness and readiness are not the same check
A liveness check asks whether the process should be restarted. Failing it repeatedly usually means something kills and replaces the instance.
A readiness check asks whether the instance should receive traffic. Failing it means the instance is taken out of rotation and left running.
Conflating them is how a service that is merely waiting on a dependency gets restarted in a loop, which turns a temporary degradation into an outage.
A third variant, a startup check, exists so that a slow-starting service is not killed by a liveness check before it has finished booting.
What the response should contain
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, enough for a person reading it during an incident.
Nothing else. No version numbers, no internal hostnames, no database names, no dependency list, no queue depths.
The detailed variant is genuinely useful and belongs behind authentication or on an internal interface, not on the public route a monitor polls every thirty seconds.
Why the detailed version ends up public
Frameworks and orchestration tooling ship a health route that reports component status, because that is the right default when the route is internal.
The route becomes public the day the service is put behind a load balancer, and nobody revisits it — it works perfectly and nothing draws attention to it.
The result is a public URL naming your database engine, your cache, your message broker and frequently their versions.
That is not an entry point; it is a description of the stack, which is the kind of disclosure no amount of header hardening elsewhere offsets.
How it is observed
Health and readiness routes met during a crawl or while observing an API are reported. No path list is tried and nothing is enumerated.
The status code and the shape of the body are read, and whether the body discloses versions, hostnames or dependency detail.
A public health endpoint is not reported as a vulnerability, because it is not one. What it discloses is what gets reported.
A route requiring authentication returns a refusal, which is recorded as exactly that rather than as a failure.
Frequently asked questions
- Should a health endpoint be public?
- Usually yes, because external uptime monitoring has to reach it. The question is what it returns, and a status code plus a short string is enough for that job.
- What breaks if liveness and readiness are the same check?
- A service waiting on a slow dependency fails the check, gets restarted, waits again, and restarts in a loop — turning a degradation into an outage.
- Is a detailed health response a vulnerability?
- No, a disclosure. It names your components and often their versions, which is reconnaissance rather than a way in. Keeping the detail behind authentication is a cheap fix.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website