Health Endpoint Monitoring
Health Endpoint Monitoring exposes liveness and readiness endpoints that probes use to detect failures and route traffic only to healthy instances. It enables automated self-healing but requires careful check depth, security, and tuning.
The Health Endpoint Monitoring pattern adds endpoints to an application that report its health when probed. External tools, load balancers, and orchestrators call these endpoints on a schedule to confirm the service is alive and functioning, and to take automated action when it is not.
The problem is detecting failures quickly in distributed, often unattended systems. A process may be running but unable to serve requests because a dependency is down. Simple ping checks miss this; a dedicated health check can verify real functionality.
How It Works
The application exposes one or more endpoints, conventionally paths like /health, /healthz, /ready, and /live. A probe issues an HTTP request and inspects the status code and, optionally, a body describing component states. A liveness check answers whether the process should be restarted; a readiness check answers whether it can receive traffic right now.
Checks can be shallow (the process responds) or deep (it verifies dependencies such as the database, cache, and downstream services). Load balancers remove unhealthy instances from rotation; orchestrators like Kubernetes restart failing pods and hold back traffic from not-ready ones; monitoring systems alert operators.
When to Use It
Use it for virtually every cloud service: behind load balancers, in Kubernetes (liveness and readiness probes), and with uptime monitors. Use deep checks to detect dependency failures and readiness checks to avoid sending traffic to instances still warming up.
Avoid making checks so heavy that probing itself loads the system, and avoid deep checks that cascade restarts when a shared dependency blips.
Trade-offs
Deep checks detect more but can cause false positives and restart storms if a shared dependency is briefly unavailable; many instances may report unhealthy at once. Endpoints can leak information, so they should be secured or limited in detail when exposed publicly. Tuning probe frequency, timeouts, and failure thresholds is necessary to avoid both slow detection and flapping.
Done well, it enables fast, automated failure detection and self-healing.
Related Patterns
It complements Circuit Breaker, which can surface dependency state in deep health checks, and Retry for transient issues. Deployment Stamps and load balancers rely on health checks to route traffic only to healthy units.
Example
A service exposes /live returning 200 if the process is up, and /ready returning 200 only when its database connection pool and cache are reachable. Kubernetes uses /live as a liveness probe to restart hung pods and /ready as a readiness probe so traffic is withheld during startup or when the database is unreachable. An external uptime monitor also polls /ready every minute and pages on-call after three consecutive failures.