Health-check the listener your gRPC traffic actually uses
One of the easiest ways to break a gRPC service in production is health-checking the wrong listener.
A common issue I see teams run into when adopting gRPC is leaving readiness checks pointed at their HTTP listener while production traffic actually flows through gRPC.
Everything looks fine until it suddenly doesn’t.
🤔 The Problem
Many gRPC services run two listeners: one for HTTP and one for gRPC.
The HTTP listener often exists for metrics, liveness checks, and management APIs. Teams moving to gRPC often reuse the HTTP health checks they set up for their REST-based services.
It’s generally a good idea to reuse what you already have, but in this case, it can be misleading.
⚠️ Health-Check What Serves Traffic
If customers connect through gRPC, your first readiness check should too.
Your HTTP listener can be perfectly healthy while the gRPC listener is misconfigured, hung, or otherwise failing.
Meanwhile, Kubernetes, load balancers, and dashboards might all show green. ✅
This happens more often than people think.
🩺 Better Ways to Monitor gRPC
There are better ways to monitor your gRPC service.
gRPC Health Probe ✅
Use a real gRPC health check request against the listener.
This validates the actual serving path and confirms the service can respond over gRPC.
A strong default option.
Build a Status gRPC Service 📋
Expose an internal status method in your gRPC API.
This gives you flexibility to check deeper dependencies, such as database readiness, downstream systems, internal state, and maintenance toggles.
It’s more work, but more control.
Use a Single Shared Listener ☝️
Because gRPC runs on top of HTTP/2, many languages and frameworks can serve HTTP and gRPC traffic on the same listener.
That means an HTTP health endpoint may be acceptable because it checks the same network path. It still does not fully validate gRPC behavior, but it is better than checking an entirely separate listener.
🧠 Final Thoughts
gRPC is awesome.
But making a service production-ready means revisiting configurations inherited from REST services.
- Health checks
- Load balancing behavior
- Connection management
- Contracts
- Operational tooling
None of these changes are difficult. They’re just easy to miss.
Originally published at https://bencane.com on May 21, 2026.
