Run 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.
Use the protocol your framework 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
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
Watch every service on one server.
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
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.
See 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 13 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
For the technically curious.
Ships with the health proto
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 live on.
Frequently asked questions
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 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.
