Determine appropriate request timeout values across a chain of dependent services.
A well-tuned timeout should comfortably exceed normal latency variance without waiting so long that a hung request holds resources indefinitely: timeout = p99_latency × safety_multiplier. In a call chain of several sequential hops, each upstream service's effective wait time compounds with every downstream hop it depends on, so the total end-to-end timeout budget across a chain of depth N is roughly N × per-hop timeout — a critical consideration since an under-provisioned outer timeout can fire before an inner retry/timeout sequence has a chance to complete.
effective_timeout = min(client_timeout, gateway_timeout, upstream_timeout)
Average latency hides tail behavior — if you set the timeout near the average, you'll time out a meaningful fraction of legitimately slow-but-successful requests; p99 (or p95 for less critical paths) captures the latency that only a small fraction of requests exceed, giving a much safer basis for the timeout.
1.5-3x over p99 is common — too tight and normal variance causes spurious timeouts, too loose and genuinely hung requests hold resources far longer than necessary before being cut off.
Each service in the chain is waiting on all the services beneath it to respond, so its own timeout must be at least as large as the sum of all downstream timeouts plus its own processing time — otherwise the outer service will time out and abandon the request before an inner retry sequence or slow-but-eventually-successful call chain completes.
If a hop retries on failure, its effective timeout budget must account for the full retry schedule (see the retry policy calculator's max total delay), not just a single attempt — failing to budget for retries is a common cause of premature upstream timeouts in deep call chains.