Request Timeout

Overview

A Request Timeout is the maximum time a client, proxy, server, or dependency waits for a request stage to complete before treating it as unsuccessful or indeterminate. Testing Request Timeout should cover malformed input, denied access, rate limits, timeouts, duplicates, asynchronous completion, and version changes.

The main risks include duplicate operations after uncertain timeouts, resource leaks, overly short deadlines, cascading latency, and endless retries. A timeout does not prove the server performed no action, so retry safety depends on method semantics, idempotency controls, and authoritative status queries.

In production, teams should define ownership and apply separate timeout budgets, deadline propagation, cancellation, idempotency keys, status lookup, bounded retries, and dependency-specific tuning. Different connection, read, write, and total timeouts may apply. Changes to Request Timeout should be checked against older clients, stored payloads, enum growth, default behavior, and retry assumptions.

Useful measures include timeout rate, timeout stage, p95 duration, successful recovery rate, and indeterminate operation count. Request Timeout is closely connected to RPC Timeout, Idempotent Request, and Exponential Backoff. The Request Timeout contract should define identifiers, validation, authorization, status semantics, errors, limits, and version behavior at the same boundary.

A successful transport result from Request Timeout should not be interpreted beyond the exact API state documented by the provider. Observability for Request Timeout should record operation, version, principal, request ID, latency, retry count, error code, and final state without exposing secrets.

The Request Timeout owner should publish stable error semantics and guidance on whether correction, retry, status lookup, or escalation is appropriate.