Can Your Ticketing Platform Survive an Onsale?

Key Takeaways

• Almost 40% of all ticketing-site traffic is bots, rising to as much as 90% during a major onsale and 96% in one 2026 sale of 3.3 million requests.
• Onsales fail from bot-driven concurrent load and fragile legacy tech, not real demand alone. You end up paying to scale infrastructure for traffic that was never going to buy anything.
• Layered defence keeps a platform standing: virtual waiting rooms, randomised queues, device fingerprinting and adaptive friction. Ticketmaster blocked over 13 billion bots across 17,000-plus events this way.
• Modern cloud architecture has sold 20,000-plus tickets in under five minutes without failure, while outdated stacks buckle at the same load.
• If you run your own branded ticketing brand, onsale reliability is the criterion to test before you sign, not after your first big drop.

Audio Overview

Resources & Downloads

• 📄 Full Report (PDF)
• 📊 Slide Deck (PDF)

Picture a Friday morning in Auckland. A promoter has spent eight weeks and a decent five figures building demand for a show at Spark Arena. Tickets go live at 9am. By 9:00:04 the site is a spinning wheel, the queue counter is frozen, and the promoter's phone is filling with screenshots of error pages. The tickets are fine. The demand is real. The platform underneath just could not stand up.

That morning is the whole game. Everything else a ticketing brand does, all the branding and the fee structure and the loyalty emails, gets judged in the ninety seconds when a few thousand people try to buy at once. And if you are weighing whether to build your own platform or white-label one, this is the part of the decision that actually matters. Not the logo. The load.

What actually happens to a ticketing platform during a hot onsale?

Most of the traffic is not human.

Almost 40% of all traffic to ticketing sites is bots on a normal day. During a big onsale that figure climbs to as much as 90%. In one 2026 concert sale, 96% of the traffic was automated: 3.16 million bot requests out of 3.3 million total. The German Football Association reported over 160 million bot requests for a single DFB Cup final. These are not scattered scalpers on laptops. They run on residential and mobile proxy networks so they look like ordinary households, which is exactly why the old trick of blocking suspicious IP addresses does nothing anymore.

So when your server melts, understand what melted it. Not fans. Machines. A single bot operation can buy over 1,000 tickets in one minute, and the infrastructure has to survive all of that noise while still letting a nurse in Whakatāne check out on her phone. Building a system that holds under that kind of asymmetric load is genuinely hard, which is the honest thing most vendors leave off the pricing page. It is also harder than it looks from the outside.

How much of an onsale is real demand?

Less than the traffic graph suggests, and that gap is expensive.

Here is the part that annoys me about how this gets sold. Operators look at a peak-traffic chart, see a wall of requests, and assume they need to provision servers for all of it. But if 90% of those requests are bots, you are buying capacity for an audience that was never going to spend a cent. You pay for the infrastructure, the bandwidth, and the on-call engineer at 3am, all to serve robots.

That cost is real and it lands on the operator, not the platform. When you are running the unit economics of a ticketing business, a defence layer that strips bot traffic before it hits your checkout is not a nice-to-have. It is the thing that stops you over-provisioning for a phantom crowd. And every bot request that reaches your payment page is also a chance for something worse, because a slow checkout under load is where genuine buyers abandon and revenue quietly leaks away.

Why do ticketing sites crash exactly when they matter most?

Two reasons, and they compound.

The first is the concurrent load I just described. Millions of requests arriving in the same few seconds, most of them automated, all fighting for the same limited inventory. The second is quieter and more damaging: old technology. As Josh Katz of Beach Lane put it, "the live entertainment business has been very slow to move towards the use of new technologies, and many of the incumbent tech stacks might not be able to do much integration because of how outdated and old they are."

That technical debt is why so many established platforms feel fragile at exactly the wrong moment. A stack designed in 2012 was never built to autoscale across regions or run behavioural bot detection in real time. It just holds on until it doesn't.

Modern architecture behaves differently. Platforms that migrated to cloud infrastructure with autoscaling have sold 20,000-plus tickets in under five minutes without a single failure. Same demand, same bots, opposite outcome. The difference is not effort or luck. It is what the thing was built on.

What does a platform that survives an onsale actually do?

It does not build one big wall. It layers.

The pattern that works is called layered defence, and it runs across three moments: before the sale, during it, and at the door. No single control stops everything, so you stack several so that a bot getting past one still hits the next.

Here is what those layers look like in practice, drawn from how the leading platforms handled real 2026 onsales:

Virtual waiting rooms are the workhorse. Instead of first-come-first-served, which hands victory to whichever bot has the fastest connection, you hold everyone in a queue and randomise their position. That single change neutralises the millisecond speed advantage that makes bots profitable. Ticketmaster has used this approach to block over 13 billion bots across more than 17,000 events. It is not exotic. It is table stakes now.

The ticketing mistakes that quietly cost operators hundreds of thousands almost always trace back to skipping one of these layers to save time or money before a big drop.

Can you stop bots without punishing real fans?

Yes, and the platforms that get this right treat it as the whole point.

The lazy version of bot defence is a hard CAPTCHA in front of every visitor. It stops some bots. It also makes your grandmother solve a puzzle about traffic lights while the tickets she wanted sell out. That is a loss disguised as security.

The better version is adaptive. You only challenge sessions that look suspicious, based on behaviour like mouse movement, scroll cadence, and purchase velocity. Device fingerprinting maps hardware signatures to orders, so if one device tries 20 orders in two minutes the system flags and blocks it before the payment settles, while a normal buyer never sees a thing. Softer identity checks of this kind have been shown to cut fraud 34% while keeping conversion rates intact. You do not have to choose between safe and smooth.

This matters beyond the sale, too. Every real buyer you protect is a real customer record you keep, and your attendee data is worth more than your lineup when it comes time to sell the next show. The same layered thinking carries all the way to the gate, where smoother entry and scanning with rotating barcodes stops the screenshot-and-share fraud that a static QR code invites.

What questions should you ask a white-label vendor about onsale reliability?

Ask the ones the sales deck skips.

When you put your own brand on a ticketing operation, the platform's worst day is your worst day. So test it before you sign, not after. Four questions surface almost everything:

1. Show me a real onsale. How many tickets have you sold in the first five minutes of a drop, for a real client, without degradation? Vague answers here are the answer.
2. How do you queue? First-come-first-served rewards bots. Ask specifically whether they randomise queue position and how the waiting room behaves at peak.
3. What is your bot defence, layer by layer? You want to hear about behavioural detection and device fingerprinting, not "we have a CAPTCHA."
4. Where does the load actually run? Autoscaling cloud infrastructure survives surges. A single fixed server does not. If they cannot describe how they scale, assume they don't.

These sit alongside the broader set of nine questions to ask before you buy any white-label platform. Reliability is the one that never makes the brochure, because it is the one that is hardest to fake.

What is the bottom line?

An onsale is not a marketing event. It is a load test with your reputation on the line. Up to 90% of the traffic will be bots, the demand that crashes the site is mostly fake, and the platforms that stay upright do it through layered defence and modern architecture, not luck. If you are building your own ticketing brand, the reliability of the platform underneath is not a technical footnote. It is the product. Test it at peak before your first big drop, because the market only gives you one first onsale, and 7am is built to make sure that one holds.

Frequently Asked Questions