Locate the timeout boundary
| Layer | Observable signal | What to change | What not to change |
|---|---|---|---|
| Your client | The client records its own timeout, cancellation or stopped stream reader. | Inspect that client’s configured timeout and cancellation handling; confirm whether it stopped reading while the response was still open. | Do not infer a provider failure from a client-side timeout alone. |
| An intermediary | A proxy, gateway, CDN or network log records an idle close or its own timeout. A gateway’s 504 points to a missing timely upstream response. | Check the client-to-intermediary path, buffering and idle-connection policy; use the intermediary’s documented settings. | Do not change the request body or provider generation settings without evidence. |
| The provider | A documented provider error or its status/support records identify an upstream delay; a request ID helps correlate that report. | Keep the redacted response and request ID; follow that provider’s status, retry and support guidance. | Do not lengthen every timeout or retry an open request as a substitute for provider evidence. |
Under RFC 9110, 408 means the server did not receive a complete request in time; it is not a slow accepted generation. 504 means a gateway or proxy did not receive a timely upstream response. Neither identifies the failing component by itself. RFC 9110, sections 15.5.9 and 15.6.5
Check the stream ending
An SSE line that begins with : is a comment, not response content. MDN notes that a server can send comment lines to help keep a connection alive and prevent idle timeouts. Our usage-only.sse fixture starts with that valid comment; it is not dirty data and adds no answer text. MDN: SSE comments and event stream format
If your client still reports the response as open while no new event arrives, the stream is stalled. If it reports the response ended, the connection has closed. For this site’s OpenAI-style fixtures, check three markers: [DONE], a finish frame and an error frame. If two are missing, do not call the stream complete; missing markers alone do not identify the failing layer.
Save the status, headers and full body with the response capture guide. Interpret a returned error with the API error guide, including its Retry-After guidance. If the same issue remains reproducible, prepare a redacted provider support report.