A header bidding timeout is how long the page waits for bids before it calls the ad server. It is one of the few settings that affects both revenue and page experience at the same time, and it is often set once at launch and never revisited. Set it too short and bids that would have won arrive after the auction has closed. Set it too long and every ad on the page loads later, readers scroll past empty slots, and the extra bids you waited for may not be worth the delay.
There is no universally correct number. The right timeout depends on your bidders, your audience's devices and networks, and how quickly your page starts the auction. This guide shows how to measure those things and test a change safely.
How the auction actually unfolds
In a typical client-side set-up, the sequence on each page view looks like this:
- The page starts loading and, at some point, loads the header bidding wrapper (for example Prebid.js).
- The wrapper sends bid requests to each configured bidder and starts the timeout clock.
- Bidders respond. Each response takes a different amount of time depending on the bidder, the user's network and the device.
- When every bidder has responded, or the timeout is reached, whichever comes first, the wrapper passes the bids it has to the ad server.
- The ad server chooses the winning line item and the creative renders.
Bids that arrive after step 4 are not used for that auction. The bidder may still have spent effort on the request, and in reports this usually shows up as a timeout for that bidder.
You may have more than one timeout
Before changing anything, list every timer that can end the auction. Many sites have several, and they interact.
- The wrapper timeout. In Prebid.js this is the
bidderTimeoutsetting, which can also be overridden per auction. - Separate integrations. Some demand sources run their own auction with their own timeout, alongside the wrapper.
- Server-side auctions. If some bidders run through a server (such as Prebid Server), that server has its own time limit for collecting responses.
- A failsafe timer. Many set-ups include a backup timer that calls the ad server regardless, in case the wrapper fails. If the failsafe is shorter than the wrapper timeout, it, not the wrapper, decides when the auction ends.
Write the values down in one place. If they disagree, you will not be able to interpret test results.
The clock starts later than you think
The timeout is measured from when bid requests are sent, not from when the page started loading. If the wrapper loads late, perhaps because it waits behind other scripts or waits for a consent decision, the first ad call happens at start delay + timeout, followed by the ad server response and rendering.
This matters because reducing the start delay often helps more than shaving the timeout. A wrapper that starts its auction earlier gives bidders the same amount of time while delivering ads sooner. Check where the wrapper loads in the page, what it waits for, and how long the consent step takes for users who have already made a choice.
What to measure
You need to see response times as a distribution, not an average. One slow bidder on slow mobile connections can be hidden inside a healthy-looking average.
- Response time per bidder: the median and a high percentile such as the 90th, split by device type and, if your traffic is international, by country.
- Timeout rate per bidder: the share of requests where the bidder did not respond before the auction closed.
- Win rate and revenue share per bidder: a bidder that often times out but rarely wins when it does respond is costing time, not money.
- Time to first ad render and viewability by slot, so you can see what the waiting costs.
Where to get this: a Prebid analytics adapter (several analytics providers offer one), the wrapper's own events (Prebid.js emits a bidTimeout event you can log), and for spot checks, Prebid's debug mode and your browser's network panel. The Prebid documentation describes the configuration options and events available in your version.
Reading the numbers
| What you see | What it often means | What to check next |
|---|---|---|
| Many bidders time out, mostly on mobile | Slower devices and networks need more time, or too many requests are competing | A separate mobile timeout; fewer bidders on mobile; moving some bidders server-side |
| One bidder times out far more than the others | That bidder's latency or a configuration problem | Raise it with the partner; check its parameters; consider running it server-side |
| Few timeouts, but ads still render late | The auction starts late | Script order, what the wrapper waits for, consent timing |
| Bids that arrive near the end of the window rarely win | The last part of the wait buys little revenue | Test a shorter timeout |
| Late bids are frequent and often high | The timeout may be cutting off valuable demand | Test a slightly longer timeout, and fix the start delay first |
How to test a new timeout
- Change one thing. Do not adjust the timeout, add bidders and move ad slots in the same test.
- Split traffic randomly. Assign users or page views at random to the current and new setting, and label each group so you can report on it, for example with a key-value passed to the ad server.
- Move in modest steps. Compare your current value with one a few hundred milliseconds shorter or longer, rather than halving or doubling it.
- Run for long enough. At least a full week, so both groups include weekdays and weekends. Avoid periods with unusual events.
- Judge on revenue per page view. Compare page RPM, impressions per page view and viewability, not just CPM or bid counts. A longer timeout can raise CPM while lowering the number of ads seen.
- Check page experience. Watch time to first ad and your Core Web Vitals for the test group.
Common mistakes
- One timeout for every device. Desktop and mobile users can have very different response time distributions.
- Adding bidders without reviewing the timeout. Each extra bidder adds requests and work in the browser, which can slow every other bidder.
- Ignoring lazy-loaded and refreshed slots. These auctions start as the reader approaches the slot. A long timeout can mean the slot is still empty when it scrolls into view.
- Counting bids instead of revenue. More bids received is not the goal. More revenue per page view, with a page readers are happy to use, is.
- Forgetting the failsafe. A shorter failsafe silently overrides everything else.
The checklist, in order
- List every timer that can end the auction and confirm they are consistent.
- Measure how long after page start the auction begins, and reduce that delay where you can.
- Collect response time percentiles and timeout rates per bidder, by device and country.
- Compare each bidder's timeout rate with its win rate and revenue share.
- Test one timeout change at a time with a random split, for at least a week.
- Decide on page RPM, impressions per page view, viewability and page speed together.
If your reports disagree about what bidders are contributing, or you are not sure which timer is really in control, an independent audit can map the set-up and measure it before anything is changed.
Common questions
What is a good header bidding timeout?
There is no single good value. It depends on how quickly your bidders respond for your audience, on which devices, and how early your page starts the auction. Measure response times and test changes against revenue per page view rather than copying another site's setting.
Does a longer timeout always increase revenue?
No. A longer timeout can collect more bids, but it delays every ad. Readers may scroll past slots before they fill, which lowers viewability and impressions. Beyond a certain point the extra bids rarely win.
Should I use a different timeout on mobile?
Often it is worth testing. Mobile devices and networks are usually slower, so response time distributions differ. Measure them separately and decide based on results for each device type.
Does server-side header bidding remove the timeout problem?
It reduces the work done in the browser, but the server still waits for bidders within its own time limit, and the browser still waits for the server. You still need to measure response times and test the settings.