Trace OpenRTB Timeouts and No-Bids Without Treating Every Empty Auction as an Error

A publisher sees eligible impressions but low bid density, while the exchange reports a mixture of HTTP 204, empty seatbid arrays, and responses that arrive after the auction closes. Those outcomes are not interchangeable. A deliberate no-bid, an invalid request, an adapter deadline, and a late valid response require different owners and different fixes.

Use the sequence below as a diagnostic method, not as a promise that one setting fits every host; verify its example paths, privileges, and backup assumptions while working to follow one OpenRTB request from inventory eligibility through tmax, adapter processing, bid validation, and the final no-bid reason before changing floors or timeouts.

Likely failure paths

• The buyer intentionally declines because the impression, geography, device, privacy state, creative format, or floor is outside its campaign eligibility.
• The effective bidder budget is smaller than the request’s tmax after network transit, exchange processing, serialization, and a safety buffer are deducted.
• A bid is produced but rejected for a missing required field, currency or floor mismatch, blocked creative attribute, invalid markup, or an ID that cannot be correlated to the request.

The branches are ordered to protect the strongest evidence around this possibility: the buyer intentionally declines because the impression, geography, device, privacy state, creative format, or floor is outside its campaign eligibility. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Programmatic failures cross publisher code, consent and identity modules, wrappers, supply platforms, demand platforms, and the ad server; a blank slot is only the last visible result; auction IDs, request timing, authorization records, and bid status are the evidence that identifies the responsible boundary; in this guide, the practical goal is to follow one OpenRTB request from inventory eligibility through tmax, adapter processing, bid validation, and the final no-bid reason before changing floors or timeouts.

A controlled investigation

1. Choose one auction ID and preserve send, receive, and close timestamps at every boundary; aggregate bid rate is not enough to distinguish selection from lateness.
2. Validate the request shape: unique request ID, at least one impression, supported media object, sizes, secure flag, currency, bid floor, privacy signals, and the maximum response time in milliseconds.
3. Separate transport outcomes from auction outcomes: connection error, non-2xx response, explicit no-bid, empty seatbid, invalid bid, valid late bid, and valid in-time bid.
4. For a returned bid, correlate bid.id, bid.impid, seat, price, currency, creative payload, advertiser domain, and any loss or no-bid reason exposed by the platform.

The sequence moves from observation toward intervention. Preserve the result of the final check—for a returned bid, correlate bid.id, bid.impid, seat, price, currency, creative payload, advertiser domain, and any loss or no-bid reason exposed by the platform—because it provides a useful comparison after the repair.

curl -sS -o /tmp/ortb-response.json -w 'http=%{http_code} total=%{time_total}\n' \
  -H 'content-type: application/json' --data-binary @request.sanitized.json \
  https://BID_ENDPOINT/openrtb2/auction

jq '{id, nbr, seats:(.seatbid // [] | length),
     bids:[.seatbid[]?.bid[]? | {id, impid, price, adomain}]}' \
  /tmp/ortb-response.json

Make the smallest durable change

1. Correct the smallest request-contract defect shown by validation and replay a sanitized fixture against a test endpoint.
2. Build a measured deadline budget from the publisher auction back toward each bidder; reduce avoidable wrapper or exchange work before lengthening the user-visible wait.
3. Segment eligibility and no-bid rates by format, placement, floor band, geography, device, consent state, and buyer so a commercial coverage gap is not misdiagnosed as a protocol outage.

Before applying “Correct the smallest request-contract defect shown by validation and replay a sanitized fixture against a test endpoint,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can replay a fixed corpus and confirm every request lands in exactly one outcome bucket with an auction ID and elapsed time; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Close the incident with evidence

• Replay a fixed corpus and confirm every request lands in exactly one outcome bucket with an auction ID and elapsed time.
• Compare p50, p95, and p99 adapter latency plus late-bid rate before and after the change, while holding inventory and traffic mix constant.
• Confirm that higher bid density does not come from invalid traffic, a floor mistake, a longer page delay, or bids later discarded by the ad server.

One successful refresh is not closure. Keep the incident open until you can also compare p50, p95, and p99 adapter latency plus late-bid rate before and after the change, while holding inventory and traffic mix constant, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

A useful monetization escalation includes the page and ad unit, UTC time, auction and transaction IDs, geography and device, consent state, configured timeout, sanitized OpenRTB fragment, bidder events, and the exact ad-server targeting produced; remove user identifiers, cookies, IP addresses, and commercial credentials before sharing; include the result of this first observation: choose one auction ID and preserve send, receive, and close timestamps at every boundary; aggregate bid rate is not enough to distinguish selection from lateness.

State what was tested, including the result of “Choose one auction ID and preserve send, receive, and close timestamps at every boundary; aggregate bid rate is not enough to distinguish selection from lateness,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Do not trade visibility for a green screen

• Do not convert every 204 or empty seatbid into a retry; no-bid is often a valid business decision and retries can duplicate load.
• Do not publish full bid requests in tickets: they may contain device, location, consent, user, or commercial identifiers.

Primary references

• IAB Tech Lab OpenRTB 2.6 specification — official reference consulted for this guide.
• Prebid Server OpenRTB auction endpoint — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Correct the smallest request-contract defect shown by validation and replay a sanitized fixture against a test endpoint”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.