Your GraphQL API Returns 200 When It Fails. We Notice Anyway.

Most GraphQL implementations return HTTP 200 even when the query fails. Failures live inside the response body — in the errors array, or as nulls inside the data object — not in the status code. Uptime-only monitoring marks failing GraphQL APIs as healthy. Real GraphQL monitoring has to inspect the response payload. See REST API monitoring →

Send a specific query payload, then assert against the response body. Check whether the top-level errors array is present or populated, validate query-specific data invariants in the response, and flag nulls in non-nullable fields. Some GraphQL servers encode domain failures inside the data object rather than populating errors — both signals are checked.

Yes. Each monitor runs a defined query or mutation payload. Monitor your most critical mutations (placeOrder, processPayment) individually to track per-operation latency, error rate, and partial failure rate.

All common auth schemes: Bearer Token (the most common for GraphQL), OAuth 2.0 with automatic refresh, JWT, API Key, Basic Auth, AWS Signature v4, mTLS, and custom headers. Secrets are masked through Secure Vault. See auth matrix →

Yes. Monitor the supergraph endpoint to verify the federation gateway is healthy, and monitor individual subgraph endpoints to isolate which service is failing when a federated query breaks. Works with Apollo Federation and similar architectures.

Total query latency is tracked, with P95/P99 percentiles per query. To pinpoint individual slow resolvers, pair monitoring with your APM tracing — synthetic monitoring confirms the customer-facing slowness; APM confirms which resolver is the bottleneck.

Yes. Deploy Private Agents inside your VPC or datacenter — common for backend-for-frontend (BFF) GraphQL services that aren’t publicly exposed.

Monitoring can include queries at various depths and complexity levels to verify your throttling and complexity limits are enforced. Pair with your WAF or query-complexity middleware for full protection.

GraphQL subscriptions typically use WebSocket — see our WebSocket monitoring for connection establishment, message delivery, and keepalive checks.

Monitor the supergraph endpoint to verify the federation gateway is healthy AND monitor individual subgraph endpoints separately to isolate which downstream service fails when a federated query breaks. Both monitors share alerting routes for consolidated incident response.

GraphQL subscriptions use WebSocket transport. Use our WebSocket monitoring product to validate that the subscription connection establishes correctly, receives expected events, and stays alive across long-running sessions.

Yes. Configure persisted query identifiers (Apollo Persisted Queries or Relay-style hashes) in the request and Dotcom-Monitor will send them as the operation reference rather than the full query string.

Build monitors at increasing query depth and complexity to verify your complexity-limit middleware enforces the threshold correctly. Pair monitor configuration with your GraphQL server complexity rules.