Health Checks: Is Your Service Alive or Just Running?
A health check answers 'Can you do your job?', not just 'Are you running?'. Load balancers and orchestrators use this API endpoint to stop routing traffic to sick instances.
Why it exists
A service can be running as a process but still be incapable of handling requests. For example, it might have run out of database connections or lost connectivity to a critical downstream service. We need a way to detect this 'zombie' state to stop sending users to a broken service and to alert operators.
The mental model
Think of a health check as a doctor asking, "Can you touch your nose?" It's a functional test, not just checking for a pulse. A simple "I'm running" isn't enough. The service must prove it can perform its core function by reporting on its own internal state and the health of its critical dependencies.
How it works
A service exposes a dedicated API endpoint, like HTTP GET /health. When an external client (like a load balancer or monitoring tool) calls this endpoint, the service runs a series of internal checks. These checks might include verifying its connection to a database, ensuring it can reach other microservices, or checking host resources like disk space. It then returns a simple status, typically an HTTP 200 OK for healthy and a 5xx status code (like 503 Service Unavailable) for unhealthy.
When to use it
This pattern is essential in microservice architectures and distributed systems. Load balancers use health checks to remove unhealthy instances from their routing pool. Service registries use them to de-register failing instances so other services don't try to call them. Container orchestrators like Kubernetes use them to determine if a container needs to be restarted.
When not to use it
A health check is not a substitute for comprehensive observability. It provides a binary signal (healthy/unhealthy) but lacks the detailed metrics, logs, and traces needed for deep debugging. Also, a service can fail in the window between two consecutive health checks, so clients must still be prepared for failed requests.
One canonical example
The Spring Boot Actuator module automatically provides a /health endpoint for applications. By default, it checks basic system health like disk space. Developers can add custom logic by implementing Spring's HealthIndicator interface to create more comprehensive checks, such as verifying a database connection or the availability of a critical external API.
Interview question
What is the primary purpose of a health check endpoint, distinguishing it from merely confirming a service process is running?
- a.To automatically trigger a service restart when resource utilization exceeds predefined thresholds.
- b.To provide detailed performance metrics for system administrators.
- c.To generate comprehensive audit logs of all incoming and outgoing requests.
- d.To allow external systems to detect if the service can perform its core functions and route traffic accordingly.Correct
Why? this is the answer
The card explicitly states that a health check answers 'Can you do your job?', enabling load balancers and orchestrators to stop routing traffic to sick instances. Options A and D are incorrect because health checks provide a binary signal, not detailed metrics or comprehensive logs. Option A is a distractor because while orchestrators may restart services based on health checks, the health check itself provides the signal of functional impairment, not the direct trigger for a restart based solely on resource thresholds.
Just read this? Test yourself on what you have been reading.
Read the original → microservices.io
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on monitoring — each one lists the topics its interview covers.
See open roles