Request timeout

A timeout is the client's own deadline. Without one, a request to a server that never answers can hold a connection, a thread and the user's patience indefinitely. Timeouts usually come in parts: how long to wait to connect, how long to wait for the first byte, and how long the whole exchange may take.

How it works

When the deadline passes, the client aborts and reports an error — in the browser through AbortController, in most libraries as a timeout exception. Every hop has its own: browser, CDN, load balancer, gateway and application. When an inner timeout is longer than an outer one, the outer layer gives up first and the work inside carries on with nobody waiting for it.

The misconception

That a timed-out request did not happen. The server may have received it and completed it after the client stopped listening; a timed-out POST may have created the order. Treat a timeout as "unknown outcome", and make writes safe to retry with an idempotency key.

Try it here

GET /protocol/v1/gateway-timeout waits about three seconds before answering 504, and GET /pizza/v1/oven/preheat takes about three seconds before succeeding — set a two-second client timeout and compare what each one does.

Sources

Other terms

ETag — An opaque version identifier for a representation, used to avoid re-sending it and to detect conflicting writes.
Safe and idempotent methods — Two independent properties of HTTP methods that decide what a client is allowed to retry.
PUT vs PATCH — PUT replaces a resource with the representation you send; PATCH applies a set of changes to it.
Retry-After — A response header telling the client how long to wait before trying again, in seconds or as a date.
Exponential backoff — A retry strategy where each wait is longer than the last, with randomness added so clients do not retry in sync.

All glossary terms · Testing techniques · All 39 mock REST APIs

Last updated 16 October 2026