gRPC monitoring

Health checks,the gRPC way.

Checkmate calls the standard gRPC health protocol on your services and treats anything but SERVING as down. If your framework ships the health service (most do), monitoring is one monitor away.

billing-api:50051SERVING
Host
billing-api.internal
Port
50051
Service name
billing.Billing
SERVING · replied in 14 ms
The standard

The protocol your framework already speaks.

grpc.health.v1 is the health convention the gRPC ecosystem settled on, the same one Kubernetes probes and load balancers use. Go, Java, Python and Node frameworks ship an implementation you can register in a few lines.

Checkmate speaks it natively. A monitor takes a host, a port and an optional service name, then calls Health/Check on your schedule. There is no gateway to deploy and no custom endpoint to write.

  • Standard grpc.health.v1 Health/Check calls
  • Host, port and service name, nothing else
  • No gateway or sidecar required
billing-api:50051gRPC
Serving / 7 days
99.97%
1 incident
Response
14 ms
avg this week
Checks
10,080
every 60 s
Last 40 checks
Strict by design

Only SERVING counts as up.

NOT_SERVING, SERVICE_UNKNOWN and connection errors all count as down. The monitor passes only when your service explicitly reports SERVING, so a process that is starting, draining or misregistered never passes by accident.

When a call fails, the alert carries the gRPC status name, UNAVAILABLE or DEADLINE_EXCEEDED instead of a bare error, which usually points at the fix before you open a terminal.

  • Down on every status except SERVING
  • gRPC status names in failure messages
What counts as upstrict
SERVINGThe monitor stays up
NOT_SERVINGDown, alerts fire
SERVICE_UNKNOWNDown, alerts fire
connection refusedDown, alerts fire
Only SERVING keeps the monitor green
Per service

One server, every service watched.

A gRPC server usually hosts several services, and the health protocol reports on each by name. Leave the service name blank to watch overall server health, or create a monitor per service you cannot afford to lose.

When one service degrades while its neighbours keep serving, the alert names the broken one instead of the whole server.

  • Blank service name checks the whole server
  • Named monitors for the services that matter
Per-service checksbilling-api:50051
billing.BillingSERVING
billing.ReportsSERVING
billing.LegacyExportNOT_SERVING
Leave the service name blank to check the whole server
Who runs this

For backends that dropped REST years ago.

Microservice platforms

Dozens of internal services, each with a health endpoint the ecosystem standardized for you. Checkmate turns them into one dashboard with history and alerting.

Kubernetes teams

Liveness probes restart broken pods, they don't tell a human anything. An external Health/Check monitor is the difference between self-healing and knowing your service was down 6 times yesterday.

Polyglot backends

The health protocol is language-neutral, so the Go payment service and the Python ML service report health the same way and land on the same dashboard.

Scope

What it covers, and what it doesn't.

Covered

  • Health/Check calls on your schedule
  • Whole-server or per-service health, by service name
  • Strict SERVING semantics, everything else is down
  • gRPC status names in failure messages
  • Response time recorded per check
  • Alerts on 12 notification channels

Out of scope

  • Your own RPC methods: the health protocol reports service health, it does not call business endpoints
  • Services without the health service registered: implement grpc.health.v1 first, most frameworks bundle it
  • Streaming behaviour: the check is a single unary health call
Under the hood

For the technically curious.

The health proto, bundled

Checkmate ships the grpc.health.v1 definition and loads it at check time, so you never upload a proto file. Point a monitor at a host and port, and the call works.

A 10-second deadline

Each Health/Check call carries a 10-second deadline. A service that cannot answer its own health check in that window is treated as down, so a hung server cannot hang the monitor with it.

Status semantics preserved

Responses and errors keep their gRPC vocabulary. SERVING, NOT_SERVING and SERVICE_UNKNOWN are reported as themselves, and transport failures surface as their status names.

Internal by default

gRPC ports rarely face the internet, and with a self-hosted monitor they don't have to. Checkmate reaches your services over the network they already live on.

FAQ

Frequently askedquestions.

It calls the standard gRPC Health Checking Protocol, grpc.health.v1 Health/Check, on the host and port you configure. The monitor is up only while the service replies SERVING.

Your service needs the grpc.health.v1 health service registered, which most gRPC frameworks include out of the box. If Kubernetes gRPC probes already work against it, Checkmate will too.

Yes. Set the service name on the monitor to check that service specifically, or leave it blank to check overall server health. Many teams run one monitor per critical service.

Everything except an explicit SERVING response: NOT_SERVING, SERVICE_UNKNOWN, unknown statuses, connection failures and calls that exceed the 10-second deadline all put the monitor down and fire alerts.

Yes. Checks run from your self-hosted instance, so services on private networks and service meshes are reachable without exposing a single port to the internet.

Checkmate is one. It is open source under AGPL-3.0, self-hosted and unlimited, so every service gets a monitor without per-check pricing.

Get started

Every feature,no paywall.

Checkmate is open source under AGPL-3.0. Self-host it and this feature ships free, on your servers, with your data.