GraphQL alerting: HTTP status codes vs. response-body errors array for low-noise failure detection

Trade-off

Teams monitoring GraphQL APIs must choose between two failure-detection strategies that each miss a different class of problems. Relying solely on HTTP status codes is simple but blind to the majority of resolver and validation failures, because GraphQL over HTTP conventionally returns 200 OK even when the JSON body contains a non-empty errors array. Scanning response bodies for errors entries catches field-level failures, authorization denials, and nullability violations, yet GraphQL’s partial-success semantics mean a single request can return both data and errors—triggering alerts for every entry creates notification noise.

Constraint

The alerting system must surface actionable failures (e.g., schema violations, upstream service outages) while suppressing expected partial-data responses that are valid by design. Error objects include extensions with codes or severity hints, but their presence and taxonomy vary across Apollo Router, GraphQL Yoga, Hasura, and custom gateways.

Open questions

1. Which error extensions codes or HTTP-status mappings does your gateway actually emit for resolver exceptions versus validation errors?
2. Can alert rules filter on path depth or extensions.code to distinguish systemic outages from single-field nullability violations without parsing raw error messages?
3. Does sampling a percentage of response bodies for errors arrays provide sufficient signal-to-noise compared to full-body inspection?