Usually not. In Kubernetes the kubelet runs probes against your container, so liveness and readiness endpoints do not need a public route. Keep them off the public ingress, return minimal output, and let only the platform and trusted monitoring call them.
How probes work
The Kubernetes documentation explains that the kubelet performs probes. For an HTTP probe, the kubelet sends an HTTP GET to the server in the container on a port you set. A failing liveness probe makes the kubelet kill and restart the container. A failing readiness probe marks the pod unready so Services stop sending it traffic. A startup probe delays the others until the app has started, and if it never succeeds the container is killed after 300 seconds and handled under the restart policy.
Because the caller is the kubelet on the node, these endpoints need no public path. Exposing them is a choice, and often an accident of a catch-all ingress rule.
What a public health endpoint can leak
A health endpoint that returns only a status code gives little away. Problems start when it returns detail.
- Dependency status. Telling the world your database or queue is down helps an attacker time an attack.
- Versions and build info. Library and framework versions help match known flaws.
- Internal hostnames and connection strings. Detailed checks sometimes print endpoints.
- Cost. A deep check that queries the database on every call can be abused as a cheap way to load your backend.
Frameworks make this easy to get wrong. For a concrete example see Spring Boot actuator exposure.
Recommended setup
- Separate routes. Serve probes on a path or port that your ingress never routes.
- Keep probes cheap. Liveness should check that the process is alive, not that every dependency works. A liveness probe that fails when a database is down can restart healthy pods during an outage and make it worse. The docs note that readiness and liveness do not depend on each other.
- Minimal body. Return a short status. Put detailed diagnostics behind authentication on an internal port.
- Use startupProbe for slow starts. The docs list initialDelaySeconds or a startupProbe as ways to wait before probing, and a startup probe copes better with variable start times.
- Network policy. Allow probe traffic from the node, and block other sources where your network plugin lets you.
External uptime monitors
If you need an external monitor, give it a dedicated public endpoint that returns only up or down and can be rate limited. Do not reuse the internal deep check. Treat any public endpoint as part of your attack surface and include it in your inventory.
Testing it
From outside your network, request the common health paths on your public hostnames and check what comes back. If you can read dependency names or versions, move that detail behind authentication. Repeat after framework upgrades, because defaults change.
Quick check
Who calls the liveness probe?
The kubelet on the node where the pod runs, not an external client. That is why it needs no public route.
Should liveness check the database?
Generally no. A liveness check tied to a dependency can restart healthy pods during an outage. Use readiness for traffic decisions and keep liveness simple.
Is a public /health returning ok a problem?
A bare ok is low risk, but make sure it is a dedicated endpoint, rate limited, and not a route to detailed diagnostics.
Where Safeguard fits
Safeguard's asset discovery helps you see what your services expose, and dependency scanning flags known vulnerable framework versions that could be revealed by verbose endpoints. Try a free scan.
Sources
Last reviewed: 19 October 2026.
