Where in a GraphQL response do per-field timings go, and is their format specified?

## The response map is closed, with one open entry The GraphQL specification defines the response to a request as a map. It may contain `data`, it may contain `errors`, it may contain `extensions`, and it must not contain any other top-level entry. That closing clause is what makes this question have a single answer: however tidy it would look, a server may not return a `tracing` key sitting beside `data`. Everything a server wants to report about an execution that is neither the result nor an error has exactly one place to go. `extensions` is that place. The specification says it must be a map, and then stops on purpose. Its contents are reserved for the implementation to use as it sees fit, with no required keys, no naming scheme and no registry of well-known values. It is the one sanctioned extension point in the response map, and it exists precisely so that servers can add things like timings without anybody having to amend the specification. ## Which means there is no standard tracing format Follow that through and a widespread misconception falls apart. Engineers talk about "GraphQL tracing" as though it were a defined artefact with a schema. It is not. What exists is a payload shape that one server implementation published years ago and many others copied: a format version, a request start and end timestamp, and a flat list of resolved fields, each carrying its response path, its parent type and field name, and a start offset and duration measured in nanoseconds from the start of the request. That shape is widespread and well understood, and it is still a convention. No part of GraphQL validation touches it; the schema does not describe it; two servers may disagree about it and both be conformant. The same is true of everything else that turns up in that slot: a computed cost score, a cache-policy summary, a document hash, a list of deprecation warnings. All conventions living in a spec-reserved box. ## What it looks like on the wire A read against a ticketing graph might come back with the result and a timing block beside it. The nesting under `extensions` — the key name, the units, the field list — is the server's choice, not the specification's: ```json { "data": { "performance": { "id": "perf-88213", "seatMap": { "sectionCount": 14 } } }, "extensions": { "fieldTimings": { "durationNs": 41870000, "fields": [ { "path": "performance", "startNs": 120000, "durationNs": 41310000 }, { "path": "performance.seatMap", "startNs": 41500000, "durationNs": 310000 } ] } } } ``` A different server, tracing the same operation, may return an entirely different structure under an entirely different key, and a tool that reads one will not read the other. ## Why the placement matters operationally Three practical consequences follow from timings living in the response body rather than in a server-side pipeline. **It is disclosed to the caller.** Whoever can run the operation can read the timings. A public ticketing endpoint that returns per-field durations is telling anyone who asks which of its backends is slow, roughly how expensive a seat-availability check is, and — through which paths appear at all — the internal shape of resolution. That is useful reconnaissance for someone probing for an expensive query to hammer, and it is a performance leak on top. The usual posture is off by default, switched on by a request header that only internal callers can set, or enabled only outside production. **It costs bytes on every response it is enabled for.** One entry per resolved field means the timing block can dwarf `data`. A seat-map read that resolves 1,847 seats produces a timing entry per seat field; the block can be several times the size of the result. Compression hides some of that and none of the parse cost on the client. **A failed request can still carry it.** `extensions` is independent of the other two entries. A request that failed validation before execution began — so `data` is absent and `errors` is present — can still carry `extensions`, and a partially successful response carries all three. That is genuinely useful, because the timing of a request that ended badly is often the timing you most want, and it is the case people forget when they write a client that only reads `extensions` on success. ## The request has an extensions map too Worth knowing that `extensions` is not only a response entry: a GraphQL request may carry its own `extensions` map alongside `query`, `operationName` and `variables`, which is how the Automatic Persisted Queries hash handshake travels. Same principle in the other direction — a reserved, contents-undefined slot that conventions have colonised. ## The short answer to give Timings go under `extensions`, because the response map is otherwise closed to `data` and `errors`; the specification defines the slot and refuses to define its contents; every per-field timing payload you have seen there is a vendor convention rather than a specified format; and because it travels in the response body, switching it on in production is a disclosure decision as much as a performance one.