RTB Architecture

RTB latency calculator: split the tmax budget and estimate the risk of timeouts

Published November 10, 2026 · Last updated November 10, 2026
Next scheduled review: 9 May 2027

This RTB latency calculator splits an exchange's tmax deadline into network time, processing stages and a safety margin. It then estimates how often your bidder will answer too late. Network round trips come from measured region pairs, and header bidding timeouts follow the Prebid.js and Prebid Server formulas. Every assumed value is labelled.

RTB latency calculator

Calculator view

Exchange deadline (ms)Region pairMedian round trip (ms)99th percentile round trip (ms), optionalSafety margin (%)Connection

Region values are Azure backbone medians for the 30 days ending 30 July 2026.

Processing stages

Stage 1 namep50 (ms)p99 (ms)

Stage 2 namep50 (ms)p99 (ms)

Stage 3 namep50 (ms)p99 (ms)

Stage 4 namep50 (ms)p99 (ms)

Stage 5 namep50 (ms)p99 (ms)

Stage 6 namep50 (ms)p99 (ms)

Internal budget 96.0 ms · Headroom 65.0 ms (fits)

Estimated late responses 0.00% (low). Network p99 12.0 ms · Margin 12.0 ms.

Network p99 · 12.0 ms
Safety margin · 12.0 ms
1. Parse and pre-filter · 9.3 ms
2. Campaign match · 15.5 ms
3. User profile lookup · 31.0 ms
4. Model score · 31.0 ms
5. Budget and pacing gate · 3.1 ms
6. Build response · 6.2 ms

Stage	Median	99th percentile	Budget	Slack
Parse and pre-filter	1.0 ms	3.0 ms	9.3 ms	6.3 ms
Campaign match	2.0 ms	5.0 ms	15.5 ms	10.5 ms
User profile lookup	4.0 ms	10.0 ms	31.0 ms	21.0 ms
Model score	5.0 ms	10.0 ms	31.0 ms	21.0 ms
Budget and pacing gate	0.5 ms	1.0 ms	3.1 ms	2.1 ms
Build response	1.0 ms	2.0 ms	6.2 ms	4.2 ms

Contents

Key facts

The deadline includes the network. OpenRTB 2.6 defines tmax as the "maximum time in milliseconds the exchange allows for bids to be received including Internet latency to avoid timeout" (IAB Tech Lab, OpenRTB 2.6).
Google sets two bars. Its deadline "typically ranges from 80 to 1000 ms", and Google requires 85 percent of responses inside it or throttles the bidder (Google Authorized Buyers, peering guide, updated 17 September 2026). To qualify for a trading location, at most 2% of requests should be late (test guide, updated 17 September 2026).
Prebid suggests one second. Its FAQ recommends 1,000 milliseconds or less for the auction timeout and 3,000 or less for the failsafe (Prebid.org FAQ, accessed 9 November 2026).
Distance costs more than code. Microsoft measured a median round trip of 83 ms from its East US region to West Europe and 224 ms to Southeast Asia. The data covers the 30 days ending 30 July 2026 (Azure network latency statistics).
Not every exchange subtracts its own latency. Index Exchange says its tmax "does not subtract internet latency between Index and the DSP" (Index Exchange knowledge base, updated 7 October 2026).

Jump to the table

How to use the calculator

Enter the deadline. Use the tmax from the bid requests you receive, or the shortest one you accept. Google's range starts at 80 ms.
Pick the two ends of the wire. Choose the exchange's trading location and your bidder's region, or type a measured round trip. Set whether connections are kept alive or opened per request.
Check the processing stages. The defaults are assumptions taken from the worked example in RTB bidder architecture. Replace them with your own median and 99th-percentile timings.
Set a safety margin. The default is 10% of tmax, an assumption. Google recommends targeting "a total time well below the deadline" (Google, peering guide).
Read the result. You get a budget per stage, the headroom left, the estimated share of late answers and how that compares with Google's 2% and 85% rules. Header bidding users can start from the Prebid tab instead.

What the calculator adds up

A bid must leave your server, cross the network and arrive before the deadline. The calculator treats that as a sum of three parts. The network part depends on distance and on how many round trips each request needs. The processing part is the time your stages take. The margin absorbs everything you did not model.

network_p50   = round_trips × RTT_p50          round_trips = 1 (kept-alive) or 3 (new TCP + TLS 1.3)
network_p99   = round_trips × RTT_p99          RTT_p99 defaults to 1.5 × RTT_p50 (assumption)
processing    = Σ stage times (p50 and p99)
margin        = tmax × margin%
internal      = tmax − network_p99 − margin     time your stages may use
headroom      = internal − processing_p99       spare time for queueing under load
stage budget  = internal × stage_p99 / processing_p99
P(late)       = 1 − Φ( (ln tmax − ln total_p50) / σ ),  σ = ln(total_p99 / total_p50) / 2.326

Three round trips for a new connection follow from the protocols. TCP opens with a three-way handshake that costs one round trip (RFC 9293). A full TLS 1.3 handshake adds one more (RFC 8446). The request and response take the third. That is why persistent connections matter so much for bidders.

The risk line fits a log-normal curve through your median and 99th-percentile totals. It is a planning estimate, not a measurement. Adding the 99th percentiles of each part assumes they are slow together, which overstates the tail; the log-normal shape is our assumption too. Measure p99 latency per exchange and replace the estimate as soon as you can.

Network round trips by region

Google lists four trading locations: Northern Virginia, the San Francisco Bay Area, Amsterdam and Singapore (Google, peering guide). Exchanges do not publish their own round-trip tables, so the calculator uses Microsoft's measured medians between Azure regions as a proxy. Azure's East US region is in Virginia, West US in California, West Europe in the Netherlands and Southeast Asia in Singapore (Azure regions list).

10 of 10 rows

Density


East US	East US 2	8 ms	Bidder in the same metro as Northern Virginia
East US	West US	69 ms	US East exchange to a West Coast bidder
East US	West Europe	83 ms	Northern Virginia to an Amsterdam bidder
West Europe	UK South	11 ms	Amsterdam to a London bidder
West Europe	North Europe	17 ms	Amsterdam to a Dublin bidder
West Europe	Southeast Asia	169 ms	Amsterdam to a Singapore bidder
East US	Southeast Asia	224 ms	Northern Virginia to a Singapore bidder
Southeast Asia	Australia East	95 ms	Singapore to a Sydney bidder
Southeast Asia	Japan East	72 ms	Singapore to a Tokyo bidder
East US	Brazil South	117 ms	Northern Virginia to a São Paulo bidder

East US

To (Azure region): East US 2
Median round trip: 8 ms
Use as a proxy for: Bidder in the same metro as Northern Virginia

East US

To (Azure region): West US
Median round trip: 69 ms
Use as a proxy for: US East exchange to a West Coast bidder

East US

To (Azure region): West Europe
Median round trip: 83 ms
Use as a proxy for: Northern Virginia to an Amsterdam bidder

West Europe

To (Azure region): UK South
Median round trip: 11 ms
Use as a proxy for: Amsterdam to a London bidder

West Europe

To (Azure region): North Europe
Median round trip: 17 ms
Use as a proxy for: Amsterdam to a Dublin bidder

West Europe

To (Azure region): Southeast Asia
Median round trip: 169 ms
Use as a proxy for: Amsterdam to a Singapore bidder

East US

To (Azure region): Southeast Asia
Median round trip: 224 ms
Use as a proxy for: Northern Virginia to a Singapore bidder

Southeast Asia

To (Azure region): Australia East
Median round trip: 95 ms
Use as a proxy for: Singapore to a Sydney bidder

Southeast Asia

To (Azure region): Japan East
Median round trip: 72 ms
Use as a proxy for: Singapore to a Tokyo bidder

East US

To (Azure region): Brazil South
Median round trip: 117 ms
Use as a proxy for: Northern Virginia to a São Paulo bidder

Download JSON

Table by AdSovereign, CC BY 4.0.

All values are P50 round trips for the 30 days ending 30 July 2026, read in the direction shown (Azure network latency statistics). They travel over Microsoft's backbone. Public internet paths between two companies are usually slower and noisier, which is why Google recommends peering for high volumes.

Processing stages: the default assumptions

The calculator starts with six stages and assumed timings. The 99th-percentile values match the stage budgets in the worked example in RTB bidder architecture, which rests on published figures of about 10 ms for profile lookups and external models. The medians are our assumptions. None of these numbers is an industry standard.

7 of 7 rows

Density


Parse and pre-filter	1 ms	3 ms
Campaign match	2 ms	5 ms
User profile lookup	4 ms	10 ms
Model score	5 ms	10 ms
Budget and pacing gate	0.5 ms	1 ms
Build response	1 ms	2 ms
Total	13.5 ms	31 ms

Parse and pre-filter

Median (assumption): 1 ms
99th percentile (assumption): 3 ms

Campaign match

Median (assumption): 2 ms
99th percentile (assumption): 5 ms

User profile lookup

Median (assumption): 4 ms
99th percentile (assumption): 10 ms

Model score

Median (assumption): 5 ms
99th percentile (assumption): 10 ms

Budget and pacing gate

Median (assumption): 0.5 ms
99th percentile (assumption): 1 ms

Build response

Median (assumption): 1 ms
99th percentile (assumption): 2 ms

Total

Median (assumption): 13.5 ms
99th percentile (assumption): 31 ms

Download JSON

Table by AdSovereign, CC BY 4.0.

Timeouts in Prebid and in SSPs

Header bidding adds deadlines before the exchange's own. In Prebid.js, the auction timeout (bidderTimeout) caps how long the page waits for bids. The Prebid Server timeout (s2sConfig.timeout) should sit below it, and Prebid sends it to Prebid Server as tmax (Prebid.org, timeouts reference). If you do not set it, it "defaults to 75% of bidderTimeout or 750ms, whichever is lesser" (Prebid.org, s2sConfig).

Prebid Server then trims the time it passes to each bidder. The Go and Java versions use different formulas, and the calculator applies both exactly as documented (Prebid.org, auction endpoint).

9 of 9 rows

Density


Prebid.js auction timeout	Docs example 3,000 ms; FAQ starting point 1,000 ms or less	setConfig; FAQ
Prebid.js failsafe timeout	3,000 ms or less, set outside Prebid	FAQ
s2sConfig.timeout	Default min(75% of auction timeout, 750 ms); timeouts page suggests 50% to 75%	s2sConfig; timeouts
Prebid Server Go	bidder_tmax = tmax − processing − network buffer − minimum response time; bidder skipped below the response preparation time	auction endpoint
Prebid Server Java	bidder_tmax = max(min(tmax, max) × percent − processing − upstream time − deduction, min); default max 5,000 ms, min 50 ms, at least 150 ms recommended	auction endpoint
Google Authorized Buyers	80 to 1,000 ms by format and auction type; 85% inside; at most 2% late per location	peering guide; test guide
Index Exchange	`tmax` required; latency to the DSP not subtracted unless agreed	Index Exchange KB, 7 Oct 2026
Microsoft Monetize (formerly Xandr)	Outgoing example requests show `tmax` of 150, 2,000 and 100 ms; incoming `tmax` from SSPs not supported	outgoing request docs; incoming request docs (both 29 Jul 2026)
Unity (ironSource Ads exchange)	`tmax` required; example requests show 996 and 998 ms	OpenRTB specs, updated 20 Aug 2026

Prebid.js auction timeout

Rule or default: Docs example 3,000 ms; FAQ starting point 1,000 ms or less
Source: setConfig; FAQ

Prebid.js failsafe timeout

Rule or default: 3,000 ms or less, set outside Prebid
Source: FAQ

s2sConfig.timeout

Rule or default: Default min(75% of auction timeout, 750 ms); timeouts page suggests 50% to 75%
Source: s2sConfig; timeouts

Prebid Server Go

Rule or default: bidder_tmax = tmax − processing − network buffer − minimum response time; bidder skipped below the response preparation time
Source: auction endpoint

Prebid Server Java

Rule or default: bidder_tmax = max(min(tmax, max) × percent − processing − upstream time − deduction, min); default max 5,000 ms, min 50 ms, at least 150 ms recommended
Source: auction endpoint

Google Authorized Buyers

Rule or default: 80 to 1,000 ms by format and auction type; 85% inside; at most 2% late per location
Source: peering guide; test guide

Index Exchange

Rule or default: tmax required; latency to the DSP not subtracted unless agreed
Source: Index Exchange KB, 7 Oct 2026

Microsoft Monetize (formerly Xandr)

Rule or default: Outgoing example requests show tmax of 150, 2,000 and 100 ms; incoming tmax from SSPs not supported
Source: outgoing request docs; incoming request docs (both 29 Jul 2026)

Unity (ironSource Ads exchange)

Rule or default: tmax required; example requests show 996 and 998 ms
Source: OpenRTB specs, updated 20 Aug 2026

Download JSON

Table by AdSovereign, CC BY 4.0.

Example values in vendor documentation are examples, not commitments. Read the tmax in live requests, and ask each partner whether it subtracts its own network time before it sends the request.

Worked examples: same region, across the Atlantic, and through Prebid

A bidder next to the exchange. Take the OpenRTB 2.6 video example's 120 ms deadline (IAB Tech Lab, OpenRTB 2.6) and an 8 ms median round trip between two Virginia regions. With kept-alive connections and the default stages, the total is 21.5 ms at the median and 43 ms at the 99th percentile. Your stages may use 96 ms, leaving 65 ms of headroom, and the estimated late share rounds to 0.00%.

The same bidder serving Amsterdam from Virginia. The median round trip rises to 83 ms (Azure). The 99th-percentile total reaches 155.5 ms against a 120 ms deadline, so the budget is 47.5 ms short. The estimated late share is 14.40%. That is inside Google's 85% rule but far outside its 2% rule for a trading location. If each request opens a new connection, network time alone triples to 249 ms at the median, and nearly every bid arrives late.

A header bidding chain. A publisher sets a 1,000 ms Prebid.js timeout, so the Prebid Server timeout defaults to 750 ms (Prebid.org, s2sConfig). Assume Prebid Server Java with 90% of tmax for bidders, 15 ms of processing and 50 ms of upstream response time. The formula gives bidders 610 ms and enforces 685 ms. A bidder 83 ms away then has 393.5 ms of headroom. Header bidding is rarely short of time at the bidder; it is short of time at the page, where every extra millisecond delays the ad server call. The Prebid.js guide covers that side.

Methodology and limits

The calculator follows the specification and vendor documents linked on this page, read on 9 November 2026. It does not measure anything. Round trips are Azure backbone medians, stage timings are assumptions until you replace them, and the risk curve is a fitted estimate. Treat the budget status and the risk band as two separate questions: one asks whether the 99th percentile fits with a margin, the other estimates how often you will be late.

It also ignores queueing. At high load, requests wait for a free worker, and that wait grows sharply as utilisation nears capacity. The headroom figure is the time left for it. To turn a request rate into servers, use the bidder capacity planner; for the commercial effect of timeouts and QPS limits, read QPS, latency and bid performance. The auction itself is explained in how real-time bidding works, and the request fields in OpenRTB 2.6 explained. More engineering tools sit in the RTB architecture hub.

FAQ

What is tmax in OpenRTB?

It is the maximum time, in milliseconds, that the exchange allows for bids to arrive, network time included. The value in the request "supersedes any a priori guidance from the exchange" (IAB Tech Lab, OpenRTB 2.6). The OpenRTB bid request builder checks that the field is present and well formed.

What latency does Google Authorized Buyers require?

The deadline in BidRequest.tmax typically runs from 80 to 1,000 ms, measured from Google's call to Google's receipt of the reply. Google requires 85 percent of responses inside the deadline and says at most 2% should be late to qualify for a location (peering guide; test guide, both updated 17 September 2026).

What should I set my Prebid timeout to?

Prebid's FAQ suggests 1,000 milliseconds or less for the auction and 3,000 or less for the failsafe (Prebid.org FAQ). Set the Prebid Server timeout below the auction timeout; its default is 75% of it, capped at 750 ms. Then test against revenue, because longer waits delay the ad server call.

How much time does a bidder really have?

Take tmax, subtract the 99th-percentile network time for your connection type and a safety margin. What remains is your processing budget. A same-metro bidder on a 120 ms deadline keeps about 96 ms; a transatlantic one has none (Azure latency data).

Does tmax include network latency?

Yes, in the OpenRTB definition. Some exchanges send the full value without taking out their own network time, as Index Exchange documents (Index Exchange KB). Budget for the round trip yourself.

How do I reduce RTB timeouts?

Run bidders near each trading location, keep connections alive, put a hard timeout on every dependency and return a no-bid rather than a late bid. Google also recommends peering for bidders that receive high request volumes (Google, peering guide). Per-stage design patterns are in RTB bidder architecture.

How this works on owned infrastructure

The budget on this page has one part you cannot buy your way out of: the distance between the exchange and your bidder. When a vendor hosts the bidder, the regions, peering arrangements and per-stage timeouts are its choices, and a timeout problem reaches you as lower win rates. AdSovereign is an enterprise RTB stack designed to run on infrastructure you control, so you choose where bidders sit relative to each trading location and set each stage's timeout as configuration. The stage budget this calculator exports can become that configuration. The architecture page shows the bid path and its timeouts, and the SLA page describes how latency is reported.

Sources

IAB Tech Lab, "OpenRTB API Specification Version 2.6" (2.6.md, release 2.6-202606; accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md
Google for Developers, Authorized Buyers RTB, "Latency Restrictions and Peering" (last updated 17 September 2026). https://developers.google.com/authorized-buyers/rtb/peer-guide
Google for Developers, Authorized Buyers RTB, "Testing and Releasing Your Application" (last updated 17 September 2026). https://developers.google.com/authorized-buyers/rtb/test-guide
Prebid.org, "Prebid Timeouts" (accessed 9 November 2026). https://docs.prebid.org/features/timeouts.html
Prebid.org, "Prebid.js FAQ: What should my timeouts be?" (accessed 9 November 2026). https://docs.prebid.org/dev-docs/faq.html
Prebid.org, "Prebid Server module: s2sConfig" (accessed 9 November 2026). https://docs.prebid.org/dev-docs/modules/prebidServer.html
Prebid.org, "Prebid.js setConfig: Bidder Timeouts" (accessed 9 November 2026). https://docs.prebid.org/dev-docs/publisher-api-reference/setConfig.html
Prebid.org, "Prebid Server /openrtb2/auction: Timeout" (accessed 9 November 2026). https://docs.prebid.org/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html
Microsoft Learn, "Azure network round-trip latency statistics" (dataset for the 30 days ending 30 July 2026; page updated 20 August 2026). https://learn.microsoft.com/en-us/azure/networking/azure-network-latency
Microsoft Learn, "List of Azure regions" (accessed 9 November 2026). https://learn.microsoft.com/en-us/azure/reliability/regions-list

More sources (6)

IETF, RFC 9293, "Transmission Control Protocol (TCP)" (August 2022). https://www.rfc-editor.org/rfc/rfc9293.txt
IETF, RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3" (August 2018). https://www.rfc-editor.org/rfc/rfc8446.txt
Index Exchange, "List of supported OpenRTB bid request fields for DSPs" (last updated 7 October 2026). https://kb.indexexchange.com/dsps/open-rtb/list_of_supported_openrtb_bid_request_fields_dsp.htm
Microsoft Learn, Xandr, "Outgoing bid request to bidders" (29 July 2026). https://learn.microsoft.com/en-us/xandr/bidders/outgoing-bid-request-to-bidders
Microsoft Learn, Xandr, "Incoming bid request from SSPs" (29 July 2026). https://learn.microsoft.com/en-us/xandr/supply-partners/incoming-bid-request-from-ssps
Unity, "ironSource Ads exchange: OpenRTB specs" (last modified 20 August 2026). https://docs.unity.com/en-us/grow/programmatic/ironsource-exchange/openrtb-specs

Changelog

9 November 2026. First edition: deadline split, 10 region pairs, six assumed stages, Prebid and Prebid Server chain, timeout-risk estimate against Google's thresholds, 21 test cases. Next review 9 May 2027.

Download latency-pairs.json · CC BY 4.0

Author: Art Kukharenko, CEO, AdSovereign. Published: 10 November 2026. Last updated: 10 November 2026.