Timeout
A maximum wait for an operation before giving up, bounding latency and freeing resources. Timeouts are essential resiliency; without them, a slow dependency can hang your whole system. Always set them on every call.
- Every outbound call, always.
- Bounding request latency.
- Never — there's no good reason to skip timeouts.
Definition
A timeout is a deadline after which an operation is aborted. Connect/read/idle timeouts bound different phases. Without timeouts, blocked calls pile up, exhausting threads and connections until the system fails.
Why it exists
Networks and services fail slow (hang) as often as fast (error). Timeouts turn hangs into bounded failures, preventing resource exhaustion and cascading latency collapse.
How it works
Set a deadline per call (and propagate a budget across a call chain). On expiry, abort and fail or retry. Budgets (a shared deadline across hops) prevent summing per-hop timeouts into a multi-second request. Always set connect + read + overall timeouts.
Scaling limits
Too-short timeouts cause false failures under load; too-long ones let hangs propagate. Timeout budgets across services need propagation (e.g. deadlines in gRPC). Retries on timeout amplify load.
Cost shape
Free. The cost is choosing the right values and handling timeouts gracefully.
Alternatives
- Circuit breaker — Stops calling a failing dep entirely; complements timeouts.
- No timeout — Unbounded latency and resource exhaustion (don't).
Failure modes
- No timeout (hangs propagate).
- Too-long timeouts causing thread exhaustion.
- Retries amplifying load on timeout.