Microservices Health Checks

A running process does not always mean a working service. A service can hold its port open while its database connection has died. Health checks give the platform a quick way to ask each service, "Can you do your job right now?" The answer drives restarts, traffic routing, and alerts.

Layman Explanation

A nurse checks a pulse, asks a few questions, and decides whether a patient needs help. A health check endpoint plays the nurse for software. A load balancer or orchestrator calls it every few seconds and reacts to the reply.

Three Kinds of Checks

Liveness Check

The liveness check asks, "Is the process alive and not stuck?" A failed liveness check tells the platform to restart the service. The check stays simple: respond quickly if the main loop works.

Readiness Check

The readiness check asks, "Can you accept customer traffic now?" A service that is still loading data or waiting for its database answers not ready. The platform pauses traffic to it without restarting it.

Startup Check

The startup check protects slow starters. It gives a heavy service extra time to boot before liveness checks begin, so the platform does not kill it by mistake.

Diagram: Traffic Follows Health

              +----------------+
Customers --> | Load Balancer  |
              +-------+--------+
                      | asks /health/ready every 5 seconds
        +-------------+-------------+
        |             |             |
   Instance A    Instance B    Instance C
    READY         NOT READY      READY
    gets traffic  paused         gets traffic

Instance B recovers its database link after thirty seconds. Its readiness answer flips to ready, and traffic returns without human action.

Designing a Good Health Endpoint

Sample Response

GET /health/ready

200 OK
{
  "status": "UP",
  "checks": {
    "database": "UP",
    "messageQueue": "UP",
    "diskSpace": "UP"
  }
}

A failing dependency returns status code 503 and names the broken part in the body. Operators read that line and know where to look.

Rules for Useful Checks

• Return within a second or two.
• Test only the dependencies the service cannot work without.
• Skip heavy queries that could slow the database.
• Protect detailed output from the public internet.

A Trap: Checking Too Much

Suppose every service reports not ready whenever any other service is down. One failing service then turns the entire system unready, and the platform removes every instance from traffic. A readiness check should cover the service's own essentials. Remote services belong to fault tolerance patterns such as timeouts and fallbacks.

Platform Example: Kubernetes

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  periodSeconds: 5

Kubernetes reads these settings, calls the paths on schedule, restarts failing containers, and removes unready ones from the service endpoint list.

Health Checks and Monitoring

Dashboards gather health results into one view. Alerts trigger when an instance stays unready beyond a set time. Teams review patterns, such as a service that restarts every night, and fix the root cause.

Graceful Shutdown

Health checks help during deployments. A service that receives a stop signal first switches its readiness answer to not ready. The platform stops sending new requests, the service finishes the work in progress, and the process exits cleanly. Customers never see half-finished requests.

Key Takeaways

Liveness decides restarts, readiness decides traffic, and startup protects slow boots. Keep checks fast, focused, and honest, and the platform heals many problems before customers notice.