Split a timeout budget across the stages of one call
A single HTTP call breaks into stages: DNS lookup, connect, TLS handshake, server processing and reading the response. Enter the whole budget and the per-stage values, and this page computes the budget available per attempt, the stage total, the remaining slack and any overage, then lists each stage share in a table.
The key point is that when the inner timeouts add up past the outer budget, the outer one fires first. The generous inner values are then never used, because the call is cut at the outer deadline. With retries the budget has to be divided by the attempt count, so the total retry wait is subtracted first and the remainder divided by the attempts. The per-attempt budget is rounded down so that an overage cannot hide, and verdicts use the 1-decimal values shown on screen. Current as of October 2026.
There is no official standard for what share each stage should take. It depends on the network and on server processing time, so this page suggests no ratios and only reports the sum and overage of your own values. Cases where connection reuse skips the DNS, connect and TLS stages, or where a streaming response makes reading long, are not modelled, and generating configuration files is not supported.
Frequently Asked Questions
The outer timeout fires first. The generous inner values are never used because the call is cut at the outer deadline, so when an overage is shown you have to lower the stage values or raise the whole budget.
Subtract the total wait between retries and divide the remainder by the attempt count. Reusing the same stage timeouts on every attempt means the last attempt starts after the outer budget has already expired.
There is no official ratio. It depends on the network and on server processing time, so this page suggests none and only reports the sum and the overage of the values you enter.