gRPC Health Checking Protocol
Fast recall
Quick revision
Core answer
grpc.health.v1.Health) that exposes a Check (unary) and Watch (server streaming) RPC for liveness and readiness probes. Load balancers and orchestrators (Kubernetes, Envoy) call Check to determine whether a service is ready to accept traffic. The grpc-spring-boot-starter auto-configures this service and integrates it with Spring's HealthIndicator beans.Checks production awareness.
Running gRPC in Kubernetes without health checks means the orchestrator cannot detect unhealthy pods.
Interviewers want to see you know both the protocol standard and the Spring Boot integration.
Interview-ready guide
Interview answer
The gRPC Health Checking Protocol is a standard service every production gRPC deployment needs from day one. HTTP health endpoints don't work on gRPC ports — an HTTP GET to a gRPC port returns garbage because gRPC speaks HTTP/2 with binary protobuf framing.
The protocol:
- The standard service at
grpc.health.v1.Healthexposes two RPCs:Checkreturns the current status —SERVINGorNOT_SERVING— andWatchis a server-streaming RPC that pushes status changes in real time to load balancers without constant polling - The
servicefield provides per-service granularity — an empty string checks overall health; a specific service name lets load balancers route around degraded services without marking the entire pod unhealthy
Spring Boot integration:
- With
grpc-spring-boot-starter, the health service is auto-configured and wired to Spring Actuator's health indicators; if a database connection fails, Actuator reports DOWN, the gRPC health flips toNOT_SERVING, and Kubernetes removes the pod from traffic rotation - Kubernetes 1.24+ supports native gRPC probes — configure
grpc.port: 9090inlivenessProbeandreadinessProbedirectly; no workarounds needed
The liveness vs readiness distinction — the most important rule:
- Liveness failure triggers a pod restart; readiness failure stops traffic without restarting
- A slow database should fail readiness (drain traffic) but not liveness (don't restart the pod); confusing the two causes cascading restarts that amplify an existing outage — every restart triggers a reconnect storm that makes a struggling database worse
I recommend wiring health checks to your database and external dependency indicators from day one, and always keeping liveness and readiness as separate probes with different thresholds.
gRPC Health Checking Protocol
Direct Answer
The gRPC Health Checking Protocol is a standard gRPC service defined by Google (grpc.health.v1.Health) that exposes a Check (unary) and Watch (server streaming) RPC for liveness and readiness probes. Load balancers and orchestrators (Kubernetes, Envoy) call Check to determine whether a service is ready to accept traffic. The grpc-spring-boot-starter auto-configures this service and integrates it with Spring's HealthIndicator beans.
Common Mistakes & Pitfalls
Running gRPC in Kubernetes without health checks means the orchestrator cannot detect unhealthy pods.
Check your understanding
Answer these without looking back at the article.
- How do you report per-service health (e.g. only the OrderService is NOT_SERVING) using the health checking protocol?
- How does Envoy use the Watch RPC for endpoint health in a service mesh?
- What happens to in-flight gRPC calls when Kubernetes sends SIGTERM to a pod?
Related interview prep categories
1Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.