Understanding the health endpoints
MobilityManager exposes health endpoints that let orchestrators, load balancers, and monitoring tools check whether the application is alive and ready to serve traffic. This article describes each endpoint and how to use them.
The endpoints
| Endpoint | Meaning | Typical use |
|---|---|---|
/healthz | Combined health — all checks must pass. | Startup probe, general health check. |
/livez | Liveness — only checks tagged live must pass. | Liveness probe: is the process responsive? |
/readyz | Readiness — only checks tagged ready must pass. | Readiness probe: can it accept traffic? |
/health | Combined health, equivalent to /healthz. | Alternative health path. |
All of these are available in every environment, because production monitoring depends on them. Each returns HTTP 200 when healthy and a non-200 status when a required check fails.
Liveness versus readiness
- Liveness (
/livez) answers "is the app running?" A persistent failure signals the orchestrator to restart the container. - Readiness (
/readyz) answers "can the app accept traffic right now?" A failure removes the pod from the load balancer without restarting it. - Combined (
/healthz) requires every check to pass and is well suited to a startup probe that gates traffic until the app has fully initialised.
Note: Health-check requests are excluded from distributed tracing, so probing frequently does not add telemetry noise.
How Kubernetes uses them
The provided Kubernetes Deployment maps the endpoints to probes:
- livenessProbe →
/livez - readinessProbe →
/readyz - startupProbe →
/healthz
The startup probe gives the app time to initialise before liveness and readiness checks take over. Docker Compose likewise uses /healthz for its container health check.
Checking health manually
curl -i http://localhost:8080/healthz
curl -i http://localhost:8080/livez
curl -i http://localhost:8080/readyzA healthy instance returns 200 OK for each. A readiness failure with a passing liveness check usually means the app is up but a dependency (such as the database) is not yet available.
Tip: The onboarding redirect never intercepts these paths, so probes keep succeeding even while the system is unconfigured and waiting for the setup wizard.
Related
- Kubernetes deployment overview
- Migrations and the onboarding redirect on startup
- Troubleshooting a failed startup
- Production hardening checklist
