The header bidding timeout is one of the most debated settings in publisher ad tech. Set it too short and you lose bids from slower demand partners, shrinking your auction and crushing CPMs. Set it too long and you destroy page speed, hurt Core Web Vitals, and annoy users. The difference between a good and bad timeout setting is routinely 15-25% of total revenue.

This guide explains how header bidding timeouts actually work, what the data shows about optimal values, how to tune them for your specific site, and the common mistakes that leave money on the table.

What Is a Header Bidding Timeout?

When a user loads your page, Prebid.js (or your header bidding wrapper) fires simultaneous requests to all configured demand partners asking "how much will you bid on this impression?" The timeout is the maximum number of milliseconds Prebid will wait for responses before closing the auction and moving on to the ad server.

Every bidder that has not responded by the timeout is excluded. Their bid, if they would have returned one, is lost forever for that impression. This is why timeout tuning matters: you are directly trading off the chance to catch more bids against the cost of delaying ad rendering.

The Three Timeouts You Need to Know

Prebid has more than one timeout concept, and they interact:

1. Bidder timeout (auction timeout): The main one. Set via pbjs.setConfig({bidderTimeout: 1500}). This is how long Prebid waits for all bidders to respond.

2. Failsafe timeout: A safety net that guarantees the ad server will be called even if Prebid itself crashes or hangs. Implemented via your own setTimeout wrapping pbjs.requestBids. Should be set to bidderTimeout + 500ms.

3. Per-bidder timeout overrides: Some bidders need more time than others. You can set individual bidder timeouts via bidders[].params.timeout, but this rarely improves total revenue and complicates debugging.

What the Data Shows About Optimal Values

Across a large sample of publishers running Prebid, here is the observed bid-response latency distribution:

This distribution tells you exactly what to do: a 1500ms timeout captures about 93% of all bids. Going from 1500ms to 2000ms catches an additional 3-4% of bids but adds 500ms to every page load. Going from 2000ms to 2500ms catches maybe 1% more bids but users start perceiving the page as slow.

The sweet spot for most publishers is 1500ms. This is where you capture the vast majority of bids without meaningfully damaging UX.

Fast Desktop Sites: 1000-1200ms

If you run a desktop-focused site with fast hosting and your users have high-bandwidth connections (primarily US/EU tier 1 markets), you can safely reduce to 1000ms. Your bidders are on low-latency networks and respond quickly. The tradeoff: you lose a few late bids from slower SSPs, but your page feels significantly snappier.

pbjs.setConfig({
  bidderTimeout: 1200
});

Monitor your pbjs.getBidResponses() output. If you see many bidders with empty responses consistently, push the timeout up to 1500ms.

Mobile Sites: 1500-1800ms

Mobile connections are slower and more variable. A user on 4G in India sees different latency than a user on WiFi in New York. For mobile-heavy sites (70%+ mobile traffic), use 1500-1800ms. Detect device and adjust:

var isMobile = /Mobi|Android/i.test(navigator.userAgent);
pbjs.setConfig({
  bidderTimeout: isMobile ? 1800 : 1200
});

Slow-Region Sites: 2000ms Maximum

If your traffic comes primarily from regions with slow internet (parts of Africa, South Asia, rural areas), you may need to go up to 2000ms. Beyond that, page speed degradation outweighs incremental bid capture. Better to lose the 5% of bids that take longer than 2 seconds than to hurt your LCP score.

The Failsafe Timeout Pattern

Prebid.js can occasionally hang if a bidder throws an unhandled exception or a network request gets stuck. Without a failsafe, your page would never render ads. Implement a failsafe wrapper:

var PREBID_TIMEOUT = 1500;
var FAILSAFE_TIMEOUT = 2000;  // bidder timeout + 500ms

var bidsBackHandler = function() {
  pbjs.setTargetingForGPTAsync();
  googletag.pubads().refresh();
};

pbjs.requestBids({
  bidsBackHandler: bidsBackHandler,
  timeout: PREBID_TIMEOUT
});

// Failsafe: if Prebid hangs, force the auction anyway
setTimeout(function() {
  if (!window._auctionComplete) {
    bidsBackHandler();
  }
}, FAILSAFE_TIMEOUT);

Common Mistakes

Mistake 1: Setting timeout to 3000ms+. This is the most common mistake. Publishers think "more time = more bids = more revenue" but the curve flattens hard after 2000ms. You add 1+ full second to LCP for maybe 2% more bids. Google penalizes the resulting CWV score. Net revenue usually drops.

Mistake 2: Forgetting the failsafe. Without a failsafe, a single buggy bidder can prevent ads from rendering on your page entirely. This happens rarely but when it does, it kills your revenue for hours.

Mistake 3: Using the same timeout for all pages. High-value pages (articles where users spend 5+ minutes) can afford a slightly longer timeout because users tolerate more initial delay. Low-value pages (bounce pages, tag archives) should have aggressive timeouts because the page will unload quickly anyway.

Mistake 4: Not measuring what actually works. Test multiple timeout values for 1 week each and compare total page RPM, not just CPMs. The right setting is the one that maximizes revenue per user, not bid win rate.

How to Measure Your Timeout's Effectiveness

Open your browser DevTools console on your own site. Type:

pbjs.getBidResponses()

This shows every bidder that responded and their latency. Look for:

Repeat 10-20 times on different pages and connections. Calculate how many bids you would lose at various timeout values. The optimal timeout is where you capture 90%+ of bids.

Advanced: Dynamic Timeout Based on Device and Connection

The most sophisticated setup adapts timeout to each user's connection quality using the Network Information API:

function getOptimalTimeout() {
  var conn = navigator.connection || navigator.mozConnection || navigator.webkitConnection;
  if (!conn) return 1500;
  if (conn.effectiveType === '4g') return 1200;
  if (conn.effectiveType === '3g') return 1800;
  if (conn.effectiveType === 'slow-2g' || conn.effectiveType === '2g') return 2500;
  return 1500;
}

pbjs.setConfig({bidderTimeout: getOptimalTimeout()});

This is overkill for most publishers but can extract an additional 3-5% revenue for sites with diverse traffic patterns.

The Lazy Loading Interaction

If you use lazy loading for below-the-fold ads, your timeout affects above-the-fold and below-the-fold slots differently. Above-the-fold ads run during page load and steal from LCP budget. Below-the-fold ads run when the user scrolls and have no LCP impact.

You can be more aggressive with lazy-loaded slots (2000ms+) since they do not affect page speed metrics. Some publishers run separate timeout configs for lazy slots. See our guide on lazy loading ads for details.

TL;DR: The Right Answer

For 90% of publishers, the answer is:

If you are building your Prebid setup from scratch, see our complete Prebid.js setup guide for full configuration.

Let WeForAds Tune It For You

At WeForAds, we continuously tune header bidding timeouts based on real-time latency data from millions of impressions across different regions, devices, and connection types. Publishers do not need to guess — our platform adapts automatically. See the lift on your site.