Is a Prebid upgrade quietly timing out your bidders?

Yes, it can, and nothing will throw an error when it does. A bidder that answers after the auction timeout is dropped, its bid never reaches Google Ad Manager, and the report shows a slightly cheaper impression. To catch it, count timed-out requests per bidder on the page before and after each Prebid release, then find where the time went.

Prebid.js 11.48.0, released on 9 November, makes the counting easier. The AUCTION_END event now carries the requests that timed out (pull request 16076), so an analytics adapter or your own listener gets the whole auction from one event. This post walks through the check, from the console to the report.

Why a wrapper upgrade can make bidders late

Prebid ships a release almost every week. Between 24 October and 9 November there were five, from 11.44.0 to 11.48.0. Most of the changes are new adapters and fixes, and most upgrades change nothing you can measure. A few kinds of change can move the timing of an auction, though, and they rarely read as dangerous in the release notes.

The first is work that happens before the auction starts. The Prebid timeouts page warns that the consent tool, User ID modules and Real Time Data modules can all add time before bids are even requested. Version 11.45.0 on 28 October changed consent management ("late cmp api availability support"). We have no evidence this release slows anyone down. It is the kind of change worth a before and after measurement on your own pages, because consent timing differs by region and by CMP.

The second is how requests leave the browser. 11.48.0 adds a bidderSettings switch, disableGzipCompression, and the same release reverts OpenX's always-on gzip for bid requests. Compression costs CPU time on the page and saves bytes on the wire. Which side wins depends on the device, and a bidder that changes how it builds its request can land on the wrong side of your timeout on slow phones.

The third is the adapter itself. In 11.44.0 the Bidscube adapter was stubbed out, with its tests and docs removed. A bidder whose adapter became a stub stops bidding without timing out, so it never appears in a timeout count. You find it in the Ad Manager report further down, as a bidder whose impressions go to zero on the release day.

The last one is the timeout setting. A build that changes how your wrapper reads its config can bring a different bidderTimeout to the page than the one you meant to send. Check the value on the live page, not in the repository.

What a timeout looks like on the page

Prebid closes the auction when the timer fires. The troubleshooting guide is plain about the result: any bid response that comes back after the timeout you configured is not sent to the ad server. The bid may have been the highest one on the page. It still loses.

The getEvents reference gives the order of events: on an auction timeout you receive auctionTimeout first, then bidTimeout, then auctionEnd. The bidTimeout event carries an array of the timed-out bids. Since 11.48.0 the same requests also travel inside auctionEnd, under timedOutRequests.

The timer itself is not exact. The setConfig reference notes that the timeout can fire later than set, because setTimeout queues its callback on the browser's event loop and a busy page delays it. On a heavy article template the effective timeout is longer than the number in your config, which can hide a slow bidder on desktop and expose it on a phone.

How to count timeouts per bidder in the console

Open a page on the template that earns the most, with the live wrapper, and run these in the browser console after the first auction has finished:

// 1. The timeout the page is actually using
pbjs.getConfig('bidderTimeout');

// 2. Timed-out requests per bidder since the page loaded
pbjs.getEvents()
  .filter(e => e.eventType === 'bidTimeout')
  .flatMap(e => e.args)
  .reduce((n, b) => { n[b.bidder] = (n[b.bidder] || 0) + 1; return n; }, {});

// 3. What did come back, per ad unit
pbjs.getBidResponses();

If the wrapper is on 11.48.0 or later, the auctionEnd events carry the same list, and one listener on auctionEnd is enough to log it.

Add ?pbjs_debug=true to the URL to see Prebid's own log lines, including errors it otherwise suppresses. Then repeat the three commands with the network throttled to a mid-range phone profile in DevTools. A bidder that answers in time on office wifi and misses the timeout on a throttled connection is the case this test exists for.

One page view tells you very little. Do this on three or four pages, on the old build and the new one, at about the same hour. You are looking for a bidder whose count moves, not a single late response.

Where the time goes: before the auction or inside it

Once you know who is late, find out where the delay is. The Prebid timeouts page suggests measuring the time between the start of the auction and the moment bids are sent. If that gap grew after the upgrade, the bidders are not slower: something before them is, usually consent, an ID module or an RTD module. If the gap is unchanged and one bidder's response time grew, the cause is that adapter or that bidder's endpoint.

Then check the pattern across bidders. The same page recommends asking two questions: are timeouts affecting all bidders or only some, and do they vary by region? All bidders late at once points at the page or the pre-auction modules. One bidder late points at that bidder. One region late points at the CMP or the network path for that region.

If you run Prebid Server, there is a second timeout to keep in line. The docs recommend setting s2sConfig.timeout to 50% to 75% of the auction timeout, and by default it is 75% of the Prebid.js timeout. It goes to Prebid Server as tmax. If an upgrade or a config change raised one timeout and not the other, the server-side bidders can be cut off while the client-side ones are fine.

Keep the failsafe in mind too: the setTimeout you set outside Prebid to call the ad server if something breaks. The docs say it should be much larger than the auction timeout. If someone lowers the failsafe to match a shorter auction, the ad server can be called before Prebid has finished, and every bidder looks late.

What to watch in Ad Manager after the release

Ad Manager cannot tell you that a bid was late, but it can show you the bidder that stopped winning. Prebid's key-values docs describe hb_bidder as the bidder code, used for reporting which bidder has the higher fill rate or CPM. If it is not reportable yet, set it as a reportable key under Inventory, then Key-values. Google's help page on reporting on targeting keys says reports do not backfill dates before the key was made reportable, so do this before the next upgrade, not after it.

With the key in place, pull a daily report of Prebid line item impressions and revenue by the hb_bidder value, for the seven days before the release and the days after it. A bidder whose share falls on the release day and stays down is the one to look at in the console. If you send all bids, the bidder-specific keys such as hb_pb_bidderA show bids that were present on the request even when they did not win, which helps tell a late bidder from one that is bidding lower.

When you report on key-values for line items, Google's help page recommends the targeted impression metrics. Without them, every key-value on the matching request is counted, and the totals will not add up the way you expect.

A release checklist for Prebid upgrades

This is the short version to keep next to the deploy notes. Our earlier post on how to know when your ad tags stop loading covers the broader page checks.

1. Read the release notes for every version between your current build and the new one. Note any adapter you run that was stubbed or removed, and any change to consent, user sync or request building.
2. Before the deploy, record per-bidder timeout counts and bidderTimeout on three high-traffic templates, desktop and throttled mobile.
3. Confirm hb_bidder is a reportable key and save a seven-day baseline of impressions by bidder.
4. After the deploy, repeat step 2 on the same pages at the same hour, and compare.
5. Check that s2sConfig.timeout and the failsafe timeout still make sense against the auction timeout.
6. Two days later, compare the hb_bidder report with the baseline. One bidder down means look at that bidder. All bidders down means look at the page.

PubPilot's on-page script checks that googletag and Prebid load and that ad slots render on real visitors' pages, and alerts you when they stop; the per-bidder timeout count above is still a check you run yourself, with the release in front of you.