gRPC monitor basics

DevFlow checks gRPC services the same way you'd test them locally — load the proto, dial, send, assert.

upload your proto

Drop your .proto files into the workspace once. They're versioned and reusable across monitors:

devflow proto push --file ./payments.proto --service PaymentsService

We compile descriptors server-side. If your protos import other protos, push them all together with --include-dir.

monitor shape

name: payments-grpc-charge
type: grpc
target: payments-api.example.com:443
service: payments.v1.PaymentsService
method: CreateCharge
proto: payments
request:
  amount_cents: 100
  currency: usd
deadline_ms: 4000
tls:
  enabled: true
  verify: true
assertions:
  - response_field_eq:
      path: status
      eq: SUCCEEDED
  - latency_lt_ms: 600

tls and mtls

Plaintext gRPC is supported (tls: { enabled: false }) for internal-only use. For mutual TLS, attach a client cert pair from the workspace secrets — see mtls for the full setup.

deadlines

deadline_ms is the gRPC deadline propagated in metadata. Most teams set it to 80% of the target service's timeout SLO so a slow check fails fast and doesn't queue.

status codes and errors

We surface every gRPC status code. OK is the default success. DEADLINE_EXCEEDED and UNAVAILABLE are the two most common red signals — alert on those before INTERNAL.

For multi-region rollout and quorum behaviour, see multi-region-setup.