Read Timeout
also called Socket Timeout
The bound on how long a client waits for response data after a connection is established — distinct from the connect timeout, and the one that usually matters.
Most HTTP clients expose at least three separate timeouts and most applications configure one of them, usually the wrong one.
Connect timeout bounds establishing the TCP (and TLS) connection. Should be short — a second or two — because a healthy server accepts quickly and a slow accept means something is badly wrong.
Read timeout bounds waiting for response bytes. This is the one that protects you from a dependency that accepted your request and is now thinking about it, which is the common failure. It should be derived from the dependency's observed tail latency, not from a round number.
Total request timeout bounds the whole operation including redirects and retries. Without it, a client with a 2-second read timeout and three retries can still occupy a thread for eight seconds.
The failure this prevents: a connection pool where every connection is held by a request waiting on a dependency with no read timeout. Default timeouts in several popular clients are infinite, which means the default behaviour under a slow dependency is to hang until something else breaks.