GraphQL Errors Hiding Behind a Calm HTTP 200 Status
Description
A meme using the 'Ryan Reynolds in 6 Underground' format. In the foreground, actor Ryan Reynolds leans casually against a wall with a calm, slightly bemused expression, labeled with the text 'HTTP 200'. In the background, a chaotic scene unfolds with a car flipping through the air and exploding, which is labeled 'GRAPHQL ERRORS'. This meme humorously critiques a core design choice of GraphQL, where the API server almost always responds with an HTTP 200 OK status code, regardless of whether the query was successful or contained errors. The actual errors are delivered within the JSON response body under an 'errors' key. This is a common pain point for developers accustomed to REST APIs, where HTTP status codes (like 4xx or 5xx) reliably indicate failure. The joke resonates with experienced engineers because it highlights how simplistic monitoring based on status codes can create a false sense of security, completely missing the catastrophic failures happening within the response payload
Comments
7Comment deleted
Our GraphQL API has 100% uptime according to the status code checks. Of course, it also has a 0% success rate for actual queries according to the people parsing the 'errors' array
GraphQL’s idea of “200 OK”: the error-rate SLO stays green while your resolvers are busy recreating Fury Road in the payload
After 15 years of building distributed systems, I've learned that GraphQL's 'everything is 200 OK' philosophy is like that senior architect who marks every code review as 'LGTM' while the entire codebase is on fire - technically correct, practically useless, and guaranteed to wake you up at 3 AM when your monitoring can't distinguish between 'query executed successfully with zero results' and 'the database is literally melting.'
GraphQL: where your monitoring dashboard shows 100% success rate while your error logs look like a Michael Bay film. Nothing says 'everything is fine' quite like wrapping catastrophic failures in a cheerful HTTP 200 envelope - because who needs proper status codes when you can make your APM tools completely useless and force every client to parse response bodies for the *actual* error state?
Nothing like burning your entire SLO budget behind a dashboard proudly showing 100% 200s - thanks, errors[]
GraphQL's HTTP 200: the polite lie that says 'success' while hiding errors - because overfetching anxiety wasn't enough
GraphQL: keeping SLAs green by shipping failures in the body and a 200 on the wire