An API times out: how do you distinguish connection, response and streaming failures?
For timeouts, first locate failed connection establishment or sending, then distinguish response waiting from mid-stream interruption instead of raising one global timeout. Stages have different causes, and SDK retries and proxies alter elapsed time.
Start troubleshooting here
For timeouts, first locate failed connection establishment or sending, then distinguish response waiting from mid-stream interruption instead of raising one global timeout. Stages have different causes, and SDK retries and proxies alter elapsed time. Record times and types and set task-appropriate budgets. Establish outcomes before retrying to avoid duplicate writes with unknown status.
Record connection, first-byte and stream-completion times
This applies to delayed first bytes, streams stalling after starting and intermittent failures under concurrency. Preserve safe request IDs and stage timings and establish whether browser, gateway or backend stopped first. An interface giving up does not mean the server canceled; record client state separately from remote execution.
Separate connection, read, write and pool waiting
Inspect connection and read limits, then write and pool-wait settings alongside proxy and server limits. Determine whether SDK retries extend total duration. A streaming heartbeat shows connection activity, not completed work. A quick first byte can precede slow output, so connection time is not full model-processing duration.
Set stage limits alongside a total task budget
Choose stage-specific limits while retaining an overall time budget. Retry temporary network failures only within policy. Supported asynchronous or streaming interfaces may suit long work but require honest progress handling. Query status or use idempotency before repeating external writes; a client timeout does not prove the operation never executed.
Check slow requests and real state after interruption
In a controlled test environment, exercise slow connections, slow responses and stream interruption and verify error types, truthful state and stopping at budget. Compare total and stage records without hiding retries. Success means a real result or explicit failure. Removing timeout messages, returning fragments and unknown remote status are not completion.
This article induced no external timeout or paid call and provides no universally suitable seconds. HTTP clients and SDKs define limits differently. Unlimited waiting occupies resources, and remote cancellation requires support. Keep unknown outcomes unresolved until checked instead of inferring business execution from an exception name.
Checked sources
These sources support the concepts and methods described here. Examples and test scope are labeled separately; check the version of the tools you use.