How to Monitor gRPC and WebSocket Endpoints

HTTP monitoring covers the majority of modern infrastructure: web apps, REST APIs, health endpoints. But as microservice architectures and real-time applications become more common, two other protocols show up frequently: gRPC and WebSocket.

Neither of these behaves like HTTP. Checking them with a standard HTTP monitor gives you either false confidence or constant errors. Here's what monitoring each protocol actually requires.

gRPC monitoring

What gRPC is

gRPC is a remote procedure call framework built on HTTP/2 and Protocol Buffers. It's used heavily in microservice communication, for service-to-service calls that don't go through a browser, often running on internal networks or Kubernetes clusters.

A gRPC service doesn't have a path you GET. You call a method. The protocol is binary, not text. A standard HTTP monitor pointed at a gRPC endpoint will get a connection but usually can't decode the response as valid HTTP/1.1, and the "success" case isn't a 200. It's a gRPC status code.

What to check

The standard gRPC health checking protocol defines a Check RPC on the grpc.health.v1.Health service. Most gRPC server implementations support this. A properly implemented health check returns:

• SERVING: the service is healthy
• NOT_SERVING: the service is unhealthy
• SERVICE_UNKNOWN: the specific service name is not known

Beyond the health check endpoint, you can monitor specific service availability by checking whether the service responds to method calls at all, and whether response times stay within acceptable thresholds.

What UptimeWarden's gRPC monitor does

UptimeWarden's gRPC monitor connects to your endpoint and validates the health check response. It tracks response time and alerts if:

• The connection fails
• The health check returns NOT_SERVING or an error status
• Response time exceeds your configured threshold

You specify the host, port, and optionally the service name. No custom code is required on your end beyond having a standard gRPC health check endpoint, which most frameworks support out of the box.

Common issues gRPC monitoring catches

• A service that is reachable on the network but reporting NOT_SERVING due to a downstream dependency failure.
• A gRPC service that accepted the connection but stopped responding (latency spike or queue backup).
• A deployment that rolled back to a broken version and the health check is the fastest way to catch it before users do.

---

WebSocket monitoring

What WebSocket is

WebSocket is a full-duplex communication protocol over a persistent TCP connection. Unlike HTTP, where each request is independent, a WebSocket connection stays open, and either side can send messages at any time. It's used for real-time features: chat, live dashboards, collaborative tools, gaming, financial data feeds.

Why HTTP monitoring isn't enough

A WebSocket server typically also serves an HTTP handshake endpoint. An HTTP monitor can verify that the handshake path responds with a 101 Switching Protocols, but that only tells you the server accepted the upgrade request. It doesn't tell you whether:

• The connection actually becomes bidirectional and functional.
• Messages are being delivered.
• The connection stays alive under normal operating conditions.

A WebSocket service can return a successful 101 and then immediately close the connection, or silently drop all messages. An HTTP monitor will show it as healthy.

What to check

The WebSocket monitor should:

1. Complete the handshake. Issue an HTTP upgrade request and confirm the server responds with 101.
2. Establish the connection. Verify the full WebSocket connection is established, not just that the upgrade was accepted.
3. Validate response time. Track how long connection establishment takes and alert on latency spikes.

Optionally, you can send a test message and verify a response, but many WebSocket services require application-layer authentication to handle messages, so simpler connection validation is often sufficient for availability monitoring.

What UptimeWarden's WebSocket monitor does

UptimeWarden establishes a full WebSocket connection to your endpoint and validates that the handshake completes and the connection is functional. It checks:

• Connection establishment (not just HTTP 101)
• Response time from initiation to connected state
• Optional custom headers for environments that require authentication at the upgrade layer

Failures alert through your configured notification channels the same way any other monitor type does.

Common issues WebSocket monitoring catches

• A real-time feature that stopped working because the WebSocket server process crashed while the HTTP server stayed up.
• A load balancer that upgraded the connection but didn't actually proxy it to a live backend.
• A connection that takes 8 seconds to establish because of a misconfigured timeout: technically a success, but far too slow.
• A WebSocket server that accepts connections from only certain origins and started rejecting them after a configuration change.

---

Setting up both on UptimeWarden

gRPC and WebSocket monitors are created the same way as any other monitor type. In the monitor creation form, select the protocol, enter the host and port, configure your check interval and thresholds, and connect your notification channels.

Both types are available from the Free plan up (see the pricing page for per-plan monitor type availability). Check intervals start at 3 minutes on Free and go down to 30 seconds on Enterprise.

If you're running microservices and real-time features and only monitoring your HTTP endpoints, you have blind spots. Add gRPC and WebSocket monitors for free.