--- title: "What Is a Virtual Waiting Room for a Website? | Evaluat" description: "A virtual waiting room queues website visitors once traffic passes a limit you set. How it works, when shops use one, and how to choose how many to let in." url: "https://www.evaluat.com/blog/product-drop-queues-waiting-rooms" last_modified: "2026-10-28" --- [Blog](https://www.evaluat.com/blog) [Ecommerce Performance](https://www.evaluat.com/blog/category/ecommerce-performance) # What is a virtual waiting room? A virtual waiting room is a holding page in front of a website that lets visitors in at a rate the site can serve and queues everyone else, so a busy sale becomes a wait instead of a crash. Installing one is the easy part. Choosing how many shoppers it lets in is the hard part, and that number has to be measured. Written by: [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · 28 October 2026 [Beginner's guide](https://www.evaluat.com/blog/beginners-guide) Part 17Where slowness comes from ![A virtual waiting room drawn as a queue, a gate and a shop. On the left, a crowd of shoppers waits in the queue. In the middle, the gate lets them in at 150 a minute. On the right, the site holds 900 shoppers at once and stays fast for everyone inside. The queue is the easy part; the number at the gate has to be measured.](https://www.evaluat.com/blog/product-drop-queues-waiting-rooms-cover.svg) Summary A virtual waiting room is a holding page that sits in front of a website during a busy moment, such as a ticket sale or a product drop. When traffic passes a limit you set, new visitors are held on a queue page and let in at a steady rate, so the site behind it stays fast for the people already shopping. Some waiting rooms let people in the order they arrived. Others gather everyone before a sale starts and shuffle them at random, which takes away the advantage of fast bots. The hard part is choosing how many to let in. Set the rate too high and the site still falls over behind the queue. Set it too low and paying customers wait for no reason. The number should come from a measurement, not a guess. Find out how many shoppers your slowest journey, usually checkout, can serve at once while staying fast. Divide that by how long a visit lasts to get a rate per minute, then leave some headroom. A waiting room does not add capacity, and it does not stop bots on its own. It turns a spike into a steady flow, and a load test in real browsers is how you find the flow your site can take. Listen to this article · 1:13 [Download the audio summary (MP3)](https://www.evaluat.com/blog/audio/product-drop-queues-waiting-rooms.mp3) Key takeaways - A virtual waiting room holds visitors on a queue page once traffic passes a limit, and lets them in at a set rate. - The limit is either people on the site at once or new people per minute; visit length converts one into the other. - The rate should come from a measured capacity of your slowest journey, usually checkout, with headroom left over. - Using a concurrency figure as a per-minute rate can overshoot your capacity several times over. - A waiting room adds no capacity and does not stop bots by itself; it buys you a steady flow. ## What is a virtual waiting room? A virtual waiting room is a holding page that sits in front of a website and controls how many visitors reach it. While traffic stays under a limit you set, visitors pass straight through. Above it, new arrivals see a queue page with their place in line and are let in at a steady rate as space frees up. Think of the door of a busy club. The person on the door has a clicker. When the room is full, new arrivals wait outside and are let in at a pace the bar can keep up with. Nobody inside notices the crowd on the pavement, because the room never gets fuller than the staff can serve. Cloudflare’s documentation describes the website version in one line: its waiting room [queues visitors when your traffic approaches a previously defined threshold](https://developers.cloudflare.com/waiting-room/about/). The same idea goes by other names, including website waiting room, online queue and virtual queue. (The phrase also names the lobby of a video appointment with a doctor. This guide is about websites.) A waiting room is a decision to turn a crash into a wait. [Part 15 of this guide](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic) showed how a site that receives more requests than it can serve slows down, times out and then falls over. A waiting room stops the extra visitors before they ever become requests. ## How does a virtual waiting room work? A waiting room checks every visitor to the protected pages for a pass, usually a cookie. Those with a valid pass go straight through. Visitors without one get a pass if there is room, or a place in the queue if there is not. The queue is released at a rate you set, and passes expire after a spell of inactivity. In the order a visitor meets them, the steps are: 1. **The check.** A visitor asks for a protected page. The waiting room, which usually runs at the edge in front of your servers, looks for a valid pass. 2. **The count.** It compares how busy the site is with the limit you set. Under the limit, the visitor gets a pass and never notices anything. 3. **The queue page.** Over the limit, the visitor sees a holding page, usually with a place in line and an estimated wait, and the page checks back on its own. 4. **The release.** Visitors leave the queue as fast as the limit allows. 5. **The timeout.** A visitor counts as active until they have been idle for a while. On Cloudflare that period is the session duration, which [defaults to 5 minutes](https://developers.cloudflare.com/waiting-room/reference/configuration-settings/). ### People at once, or people per minute Waiting rooms count traffic in one of two ways. Cloudflare’s total active users setting is [a target threshold for how many simultaneous users you want to allow](https://developers.cloudflare.com/waiting-room/about/), and a second setting limits how many new users arrive per minute. Queue-it works on a rate: [you choose the rate at which visitors flow from the waiting room to your site, measured in visitors per minute](https://queue-it.com/how-does-queue-it-work/). CrowdHandler also uses a rate, which its documentation describes as [the number of new users you are happy to invite onto your site every minute](https://www.crowdhandler.com/docs/80001016979). The two are linked by how long a visit lasts, which is why choosing the number is less obvious than it looks. More on that below. ### First come, first served, or a raffle The other choice is order. A first-in, first-out queue admits people in the order they arrived. For a sale with a start time, some waiting rooms gather early visitors on a countdown page instead and shuffle them when the sale opens. Queue-it explains that [while in the pre-queue, visitors do not get a position in line](https://www.queue-it.com/blog/first-in-first-out-randomization), and that the shuffle [removes the speed advantages of bots](https://www.queue-it.com/blog/first-in-first-out-randomization). Anyone who arrives after the start joins the back of the line. Glastonbury used the shuffled version for its 2027 tickets. The Press Association reported that fans were [randomly assigned a place in a queue](https://www.irishnews.com/news/uk/tickets-for-glastonbury-festival-2027-sell-out-in-less-than-45-minutes-ON3QWDWCJJPBHKU25VHLFISAEU/), and that general sale tickets sold out in less than 45 minutes. ### Always on, or only for events A waiting room can sit in front of a site all year as a safety net, doing nothing until traffic crosses the limit, or it can be switched on for a scheduled drop. Queue-it describes the safety-net setup as one where [customers are redirected to a customizable waiting room only when traffic exceeds the capacity you’ve set](https://queue-it.com/how-does-queue-it-work/). ## When do websites use a waiting room? Websites use waiting rooms when demand will arrive faster than they can serve it, usually at a known moment: ticket sales, limited product drops, the opening minutes of a Black Friday sale, and public services that everyone needs on the same day. The common thread is a crowd that arrives within minutes rather than spread across the day. Two well-documented examples show the scale. - **NHS vaccine bookings, 2021.** The national booking service used Akamai [to hold people in a waiting area based on a percentage that we control](https://digital.nhs.uk/blog/tech-talk/2021/dealing-with-our-glastonbury), wrote Rob Sinclair, a lead architect at NHS Digital. At any one time it [allowed approximately 12,000 people to access the bookings](https://digital.nhs.uk/blog/tech-talk/2021/dealing-with-our-glastonbury), and at its busiest it was [taking over 150,000 bookings in an hour](https://digital.nhs.uk/blog/tech-talk/2021/dealing-with-our-glastonbury). - **The Eras Tour presale, November 2022.** Ticketmaster said [over 3.5 million people pre-registered](https://business.ticketmaster.com/business-solutions/taylor-swift-the-eras-tour-onsale-explained/) for the presale and that the on-sale produced [3.5 billion total system requests](https://business.ticketmaster.com/business-solutions/taylor-swift-the-eras-tour-onsale-explained/), four times its previous peak. It estimated that [about 15% of interactions across the site experienced issues](https://business.ticketmaster.com/business-solutions/taylor-swift-the-eras-tour-onsale-explained/). Shoppers seem to prefer a queue to a broken site, at least when asked. In a survey of more than 1,000 consumers published by Queue-it, which sells waiting rooms, [84% would rather queue than face a crash or error page](https://queue-it.com/news/reliability-over-speed-online-queue-survey/). ## Waiting room, autoscaling or rate limiting: what is the difference? A waiting room limits whole visitors at the door. The other tools teams reach for during a traffic spike work on servers or on individual requests, and each protects against something different. They are not substitutes for each other, and most busy sites use several. | Tool | What it does | What it protects | What it cannot do | | -------------------- | --------------------------------------------------------------- | ---------------------------------------- | ------------------------------------------------------------------------- | | Virtual waiting room | Holds visitors on a queue page and admits them at a set rate | The whole journey for the people inside | Add capacity, or stop bots on its own | | Autoscaling | Adds servers as load rises | Gradual growth in traffic | Catch a jump that lands in seconds, or add database connections | | Rate limiting | Refuses requests over a limit per client or overall | The site from abusive or runaway clients | Keep a journey together; it can refuse a request halfway through checkout | | CDN | Serves copies of pages and files that are the same for everyone | Cacheable pages and images | Help baskets and checkouts, which are built for each shopper | The difference between the first and third rows matters most on sale day. Rate limiting refuses requests, so a shopper can be turned away between the basket and the payment page. A waiting room decides at the door, so someone who gets in can finish. [Part 14](https://www.evaluat.com/blog/what-is-a-cdn) covered why the CDN cannot carry the checkout for you. ## How do you choose the admission rate? Measure it. Find how many shoppers your slowest journey, usually checkout, can serve at once while staying within your targets. Divide that by the average visit length in minutes to get a rate per minute, then hold some back as headroom. Queue-it’s own guidance is that [the best way to determine your rate is a load test](https://queue-it.com/how-does-queue-it-work/). Guessing is the common alternative, and it usually guesses high. CrowdHandler’s documentation is candid about its customers: [most of our customers think they can handle much more traffic than they can in reality](https://www.crowdhandler.com/docs/80001016979). Its advice, when a team has no evidence, is that they [might want to start at 10](https://www.crowdhandler.com/docs/80001016979) a minute and raise it from there. ### A worked example Take a shop preparing a trainer drop. 1. **Measure the ceiling.** A [capacity test](https://www.evaluat.com/blog/what-is-capacity-testing) of the drop journey, product page, size, add to basket and checkout up to payment, shows checkout staying within its response-time target up to 1,200 shoppers at once. Above that, response times climb and errors start. 2. **Find the visit length.** Analytics from the last drop show a visit lasting six minutes on average. 3. **Convert to a rate.** Shoppers on the site at once equal the arrival rate multiplied by the visit length, the same arithmetic [part 7](https://www.evaluat.com/blog/how-many-concurrent-users) used for concurrent users. So the ceiling is 1,200 divided by 6, or 200 new shoppers a minute. 4. **Leave headroom.** Cloudflare’s guidance for its active-users limit is to [set the value to 75% of your origin’s traffic capacity](https://developers.cloudflare.com/waiting-room/reference/best-practices/). Three-quarters of the ceiling is 900 shoppers at once, or 150 a minute. Now the common mistake. Type the concurrency figure of 1,200 into a per-minute setting, and after six minutes 7,200 shoppers are on a site that holds 1,200. Queue-it describes the same error with a ten-minute journey, concluding that [you’ve actually overestimated your true capacity tenfold](https://queue-it.com/blog/website-capacity-mistake/). ### Check the slowest dependency Your own servers may not be the limit. A payment provider, a fraud check or a stock service can run out first. Queue-it flags that [checkout processes and payment gateways, for example, are huge bottlenecks for transactional websites](https://queue-it.com/blog/website-capacity-mistake/). CrowdHandler suggests that [working back from peak orders per minute](https://www.crowdhandler.com/docs/80001016979) is a good way to set the rate. In the example, if one admitted shopper in four buys, 150 a minute means about 38 orders a minute, and the payment provider has to accept that. Teams that run the biggest queues work this way. The NHS booking service’s 12,000 figure, Sinclair wrote, [was determined through extensive performance testing and monitoring key components within the solution](https://digital.nhs.uk/blog/tech-talk/2021/dealing-with-our-glastonbury). ## What does a waiting room not fix? A waiting room controls how many people arrive. It does nothing about how well the site serves them once they are in, it does not separate people from bots, and while it is queueing, search engines can be queued too. Plan for each of those separately. - **Capacity.** If the rate is wrong, the site still fails behind the queue, and the people who waited longest meet the error page. - **Bots.** Queue-it’s own developer guide says that [bot and abuse mitigation is a cat-and-mouse game with no single silver bullet](https://queue-it.com/developers/bots-abuse-management/), and lists [navigating directly to the target URL](https://queue-it.com/developers/bots-abuse-management/) as a way to skip the line. A waiting room has to be enforced on every protected URL, alongside bot management. - **Search engines.** Cloudflare warns that [SEO crawlers may end up in a queue during active queueing](https://developers.cloudflare.com/waiting-room/reference/best-practices/). Cloudflare’s queue page answers with a normal 200 status [by default](https://developers.cloudflare.com/waiting-room/reference/configuration-settings/), so a queued crawler sees the holding page where the product should be. If you switch it to a 429, Google’s documentation says [5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling](https://developers.google.com/search/docs/crawling-indexing/http-network-errors). Check your provider’s crawler settings before a big event. - **Patience.** A queue is still a wait. When Shopify first queued its flash-sale checkouts, its engineers wrote that [users were upset about waiting on the queue page for up to 40 minutes](https://shopify.engineering/surviving-flashes-of-high-write-traffic-using-scriptable-load-balancers-part-i). When demand dwarfs supply, a queue may not be the fairest tool at all. A draw, where people register and winners are picked at random, avoids a race at a fixed time altogether. ## Common mistakes with virtual waiting rooms Most of them come from setting the number once, by feel, and never checking it. - **Guessing the rate.** Use a measured ceiling, not last year’s homepage traffic or the server count. - **Mixing up the units.** People at once and people per minute differ by the visit length. Convert before you type. - **Testing the wrong journey.** A drop sends everyone to one product page and the checkout. Measure that journey, not a general browse. - **Starting high and lowering.** CrowdHandler’s documentation warns that [starting high and lowering the rate is riskier](https://www.crowdhandler.com/docs/80001016979) than the other way round. - **Leaving gaps.** A direct link to the product, the checkout URL or an API the page calls can let visitors around the queue. - **Never re-measuring.** A new release, a cold cache or a new payment step changes the ceiling. Re-test before each big event. ## How Evaluat helps you set the rate Evaluat runs each virtual user in its own real browser and ramps them up to the level you choose, so a capacity test walks the same drop journey a shopper does: the product page, the basket and the checkout, with every image, script and API call loaded. The report shows response times and errors per URL, p95 and p99 percentiles, and Core Web Vitals, which tells you the level at which checkout stops meeting its target. That level, divided by your visit length, is your starting rate. A waiting room also changes what the site has to survive. Instead of a spike at the start of a sale, the servers see a steady flow at the rate you chose. Evaluat’s virtual users ramp up over minutes and then hold steady, which is the same shape. When a run starts to fail, open a session from that moment and watch what the shopper saw, with the network log showing which request slowed first. Open the session. Watch the moment it broke. The boundaries are worth stating. Run the test against the site behind the waiting room, with the room switched off for the test or set to let it through, because a test that is itself queued measures the queue. Evaluat measures from the outside, the way shoppers arrive, so pair it with your server monitoring to see which limit was hit. And it does not test the waiting-room provider’s own capacity, which is theirs to prove. A waiting room turns a crash into a wait, but only if the number behind it is right. Measure what your checkout can take, convert it to a rate, and leave room to spare. Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.com/demo?intent=performance) to find the number your waiting room needs. [Previous · Part 16Caching explained: browser, CDN, full-page and object caches](https://www.evaluat.com/blog/caching-explained) [Next · Part 18Third-party scripts and tag managers: the slowdown you did not write](https://www.evaluat.com/blog/third-party-scripts-performance) ![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.com/authors/ahmad-farzan.jpg) About the author [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · Founder at Evaluat Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them. [Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad) [More from Ahmad](https://www.evaluat.com/authors/ahmad-farzan) Common questions ## FAQ ### What is a virtual waiting room? A virtual waiting room is a holding page in front of a website that queues visitors when traffic passes a limit the site owner sets. Visitors are then let in at a controlled rate, so the site keeps serving the people already on it. It is also called an online queue or website waiting room. ### How do virtual waiting rooms work? The waiting room checks each visitor for a pass, usually a cookie. If the site is under its limit, the visitor gets a pass and goes straight through; if not, they see a queue page and are let in as space frees up. Passes expire after a period of inactivity, which frees space for the next person. ### Are virtual waiting rooms random or first-come, first-served? Both exist. A first-in, first-out queue lets people in the order they arrived. For a sale with a start time, many waiting rooms gather early visitors on a countdown page and shuffle them at random when the sale opens, then add later arrivals to the back of the line. ### Why can't websites just scale to handle demand? Adding servers takes minutes, and it does not add database connections, stock-checking capacity or payment provider throughput. A drop or on-sale can bring more people in one minute than a site sees in a normal day. A waiting room caps the flow at what the slowest part can serve. ### How do you decide how many visitors to let in? Measure it. Run a load test on your busiest journey, usually product page to checkout, and find how many shoppers it serves at once while staying fast. Divide that by the average visit length in minutes to get a rate per minute, then leave a quarter or so as headroom. ### Is a waiting room the same as rate limiting? No. Rate limiting refuses individual requests once a client or the whole site goes over a limit, which can break a shopper mid-checkout. A waiting room limits whole visitors at the door, so someone who gets in can finish their journey. ### Do virtual waiting rooms stop bots? Not on their own. Randomising the queue at the start of a sale removes the advantage of arriving first, but bots can still join many times or try to skip the queue by going straight to a product URL. Waiting rooms work alongside bot management, not instead of it. ### Does a virtual waiting room affect SEO? It can, while queueing is active. Search engine crawlers can be placed in the queue like anyone else and see the holding page instead of the product. Some providers let verified crawlers bypass the queue, so check the setting before a big event. Related reading ## More from the blog [![A capacity test steps the load up in plateaus, from 500 to 1,750 virtual users, while the 95th percentile response time is read at each step. Response time stays under the two second target up to 1,250 users, which is the usable ceiling, crosses the target at 1,500, and the site only breaks at 1,750. Capacity is the last step that still meets the target, not the breaking point.](https://www.evaluat.com/blog/what-is-capacity-testing-cover.svg)](https://www.evaluat.com/blog/what-is-capacity-testing) ### [What is capacity testing?](https://www.evaluat.com/blog/what-is-capacity-testing) [Most teams can tell you when their site falls over. Far fewer can tell you when it stops being good enough, and that second number is the one customers feel. Capacity testing, in performance testing, finds it. It measures how many users your site can serve while still meeting the speed and error targets you set in advance.](https://www.evaluat.com/blog/what-is-capacity-testing) [Ahmad Farzan · 18 September 2026](https://www.evaluat.com/blog/what-is-capacity-testing) [![The five stages a busy website fails in, drawn as a descending staircase. First, requests queue and pages slow. Second, timeouts turn slow requests into 502 and 504 errors. Third, retries and refreshes multiply the load. Fourth, overloaded servers miss health checks and are pulled from service. Fifth, the failure cascades to the next part of the system, often the database. The order barely changes; what runs out first does.](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic-cover.svg)](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic) ### [Why websites crash under high traffic](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic) [Most websites do not simply switch off when traffic spikes. Requests queue for a limited resource, pages slow, timeouts turn slow into failed, and retries and failed health checks pile on more load until the site falls over. The symptoms arrive in roughly that order every time. What differs is which part runs out first.](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic) [Ahmad Farzan · 21 October 2026](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic) [![The concurrent users formula worked through: 12,000 sessions in the peak hour, multiplied by an average session of 5 minutes, divided by 60, gives 1,000 concurrent users. A bar comparison shows how small that is next to the 12,000 sessions in the same hour. Load tests are sized from the people on the site at the same moment.](https://www.evaluat.com/blog/how-many-concurrent-users-cover.svg)](https://www.evaluat.com/blog/how-many-concurrent-users) ### [How many concurrent users can my website handle? (with calculator)](https://www.evaluat.com/blog/how-many-concurrent-users) [Visitors per hour multiplied by session length. That is the whole formula for concurrent users, and most teams have never run it. It tells you how many people are on your site at the same moment, which is the number that loads your servers. How many your site can handle is a second question, and no server specification can answer it.](https://www.evaluat.com/blog/how-many-concurrent-users) [Ahmad Farzan · 23 September 2026](https://www.evaluat.com/blog/how-many-concurrent-users) See it on your site Test in real browsers.\ Debug in real sessions. ## Want to see this measured on your app? 30 minutes. We build a scenario on your real customer journey, run a small test, and walk you through the report. [Book a demo](https://www.evaluat.com/demo?intent=performance) [How it works](https://www.evaluat.com/how-it-works)