rtblintAlpha

Guides

tmax and bidder timeouts: why OpenRTB bids arrive too late

A bid that arrives after the deadline is worth nothing, no matter how high it is. That deadline is tmax, a single integer in the bid request, and misreading it is one of the most common reasons a bidder looks like it is not participating when it is. Here is what tmax actually governs and how to debug bids that keep arriving late.

What tmax means

BidRequest.tmax is the maximum time, in milliseconds, the exchange will wait for a bid response, and the spec is explicit that this budget includes Internet latency: the network time to deliver the request and return the response counts against it, not just the bidder's own compute. It also supersedes any prior guidance the exchange gave out of band; the value in the request is the one that binds for this auction.

That network-inclusive definition is the part bidders get wrong. If tmax is 100 milliseconds and the round-trip network time between exchange and bidder is 40, the bidder has 60 milliseconds to decide, not 100. Budget compute against what is left after the wire, not against the whole number.

A timeout is not a no-bid

These look identical in the logs, an impression the bidder did not win, but they are different failures with different fixes:

  • No-bid. The bidder responded in time and chose not to bid, ideally with a reason code. Covered in no-bid reason codes.
  • Timeout. The bidder's response did not arrive before tmax, so the exchange discarded it, whatever it contained. This is a latency problem, not a decisioning one.

Conflating the two sends you debugging the wrong system. A rising timeout rate points at infrastructure and network; a rising no-bid rate points at targeting and floors.

Typical values, and a sane floor

There is no single correct tmax; it depends on the channel and the supply path. Web display auctions often sit in the low hundreds of milliseconds; server-side and CTV paths may allow more. What matters is that the value is realistic and positive. A tmax of zero, a negative value, or an implausibly tiny number is simply a malformed request, and rtblint flags non-positive or implausible tmax as a plausibility issue for exactly that reason. See the tmax reference for the full semantics.

Debugging bids that arrive late

  1. Measure the network RTT between exchange and your endpoint. Subtract it from tmax to find your real compute budget.
  2. Check geographic placement. A bidder far from the exchange loses the race on the wire before it computes anything. Co-location or regional endpoints are the usual fix.
  3. Profile the slow path, not the average. Timeouts live in the tail. A p50 well under budget with a fat p99 still bleeds impressions.
  4. Fail fast internally. Cap your own decisioning below the remaining budget and return a no-bid rather than blowing the deadline with a bid that gets discarded anyway.
  5. Enable Keep-Alive and compression. Connection reuse and gzip cut wire time directly; see bid request best practices.

What to check

If you run an exchange, confirm tmax is present, positive, and accounts for the latency to your bidders; a value that ignores network time starves honest bidders. If you bid, instrument the gap between tmax and your delivered response time. Validate that tmax is well formed in the tester or the CLI.

Sources