Skip to content
ENExplore Calculators

Timeout Configuration Calculator

Determine appropriate request timeout values across a chain of dependent services.

About Timeout Configuration Calculator

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)

Worked example

With the default values below, Timeout Configuration Calculator returns Recommended Timeout (per hop) of 450. Change any input above and every figure here is recalculated in your browser.

Inputs used

P99 Latencyaccepts 1–1,000,000 ms
300 ms
Safety Multiplieraccepts 1–10 ×
1.5 ×
Call Chain Depthaccepts 1–100 services
3 services

Results

Recommended Timeout (per hop)
450 ms
Total Cascade Timeout Budget
1.35 seconds
Recommended Timeout (per hop)
0.450 seconds

Step by step

  1. 1Recommended timeout: p99 × safety multiplier= 450ms
  2. 2Total cascade timeout budget across chain= 1350ms (1.35s)

Assumptions and limits

  • The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
  • In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
  • Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

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.

Related Calculators

Timeout Configuration Calculator | Calcrivo