Beyond HTTP 200: Observability With GraphQL
summary
HTTP 200 hides GraphQL failures and latency; observability requires logs, metrics and traces wired into federation. The Polar/Hygraph router emits a metric hive.router.graphql.errors so teams can track error counts and codes, and an outbound-timing metric HTTP.client.request.duration exposes which subgraph causes a P95 jump (example: account P95 rising from ~1s to ~5s). Distributed traces (OTel) plus GraphQL-native tooling like Hive Traces reveal where, when and which component (router, subgraph or downstream DB) actually failed.
AI-written summary · about
chapters (11)
- 0:00Introduction to observability
- 1:05Why HTTP 200 isn't enough
- 3:12Three pillars of observability
- 4:36Beyond HTTP 200 examples
- 6:44Logs for GraphQL errors
- 7:49Traces for request flow
- 8:33Metrics for trends and alerts
- 10:00Slow GraphQL responses
- 13:30GraphQL-native observability
- 16:42Key takeaways and summary
- 17:04Q&A session
related talks
32mWhat Could Go Wrong with a GraphQL Query & Can OpenTelemetry Help?
18mWhat Could Go Wrong with a GraphQL Query and Can OpenTelemetry Help?
25mUnlocking Insights: Navigating the World of GraphQL Observability
23mGraphQL Observability
21m200 NOT OK: High-Resolution Observability
32m200 Is Not OK: Strategies for Tracing Partial Responses w/ GraphQL
52mGraphQL Observability with Elastic and OpenTelemetry
27mHow The Guild is using GraphQL at scale