Timeout Configuration Calculator

Calculate a recommended request timeout from observed p99 latency and a safety multiplier, and show the cascade impact across a call chain.

Inputs

P99 Latencyms

Observed 99th-percentile response latency for the downstream service.

Safety Multiplier×

Multiplier applied to p99 latency to set the timeout, leaving margin for natural variance.

Call Chain Depthservices

Number of sequential service hops in the call chain, each needing its own timeout budget.

Recommended Timeout (per hop)

450ms

Total Cascade Timeout Budget

1.35seconds

Recommended Timeout (per hop)

0.450seconds

Step by step

Recommended timeout: p99 × safety multiplier
300 × 1.5
= 450ms
Total cascade timeout budget across chain
450 × 3 hops
= 1350ms (1.35s)

How it works

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.

Formula

effective_timeout = min(client_timeout, gateway_timeout, upstream_timeout)

client_timeout: Client-side request timeout (ms)
gateway_timeout: API gateway/proxy timeout (ms)
upstream_timeout: Backend service timeout (ms)

Frequently Asked Questions

Why use p99 latency instead of average latency for timeout sizing?

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.

What's a reasonable safety multiplier?

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.

Why do timeouts need to grow at each hop in a call chain?

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.

How does this interact with retry policies?

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.

You might also need

Retry Policy Calculator Circuit Breaker Threshold Calculator Service Mesh Overhead Calculator