Banish bots from your Waiting Room and improve wait times for real users

Waiting Room gains bot filtering and session control

Cloudflare has expanded its Waiting Room product with two capabilities aimed at improving the experience for legitimate visitors during traffic surges. The first adds Turnstile bot detection to the queue itself, while the second gives origins a way to end user sessions early after key actions such as a purchase.

The changes address a longstanding problem with high-demand events: bots competing with humans for limited inventory. Scalper bots and similar automated traffic occupy queue slots, inflate wait times, and can consume stock faster than any human shopper. A widely cited example was the PlayStation 5 launch in November 2020, when bots bought up consoles quickly and drove prices up significantly.

Detecting bots in the queue

Waiting Room now embeds an invisible Turnstile challenge into its queuing page for all customers. The challenge is presented only while the waiting room is queueing, so users who are admitted to the application do not face additional interruptions. Advanced Waiting Room customers can choose between invisible, managed, or non-interactive widget modes.

Cloudflare reports that many large traffic spikes come from user agents that do not even attempt to run the challenge. These requests are counted as "Likely Bots" in Waiting Room Analytics. Small businesses with low baseline traffic have seen tens of thousands of such requests in a short period. When that happens, every visitor ends up queued, not just the bots.

More sophisticated bots do run the challenge but fail it. Turnstile checks the browser for evidence that it is being driven by automation software such as Selenium. Failed challenges are reported to analytics as "Bots," while successful ones are counted as "Likely Humans." Cloudflare says roughly 1 in 20 users that run the challenge do not pass it. These metrics are available in the analytics dashboard and through the analytics GraphQL API.

Embedding Turnstile follows the standard integration pattern. The queuing page template receives the widget HTML in a turnstile variable. The default template and any newly created custom templates include this variable already. Existing custom templates must add {{{turnstile}}} to indicate where the widget should be placed. Waiting Room uses Mustache templates, so raw HTML requires three curly braces to avoid escaping.

Once the challenge completes, fails, or times out, the page refreshes and passes the Turnstile token to the Waiting Room worker. The worker validates it against Turnstile's siteverify endpoint, reports the outcome to analytics, and optionally routes failed traffic to the infinite queue.

Infinite Queue wastes bot resources

Advanced Waiting Room customers can enable the Infinite Queue feature. Traffic that fails the Turnstile challenge is sent to a page that matches the normal queuing experience, but the bot is never actually placed in the real queue. The bot spends its time and resources waiting for a queue that will never admit it.

The infinite queue is designed to be indistinguishable from the real one. Bots receive a cookie that looks like a normal waiting room cookie, but its encrypted contents include a boolean flag that routes requests to the infinite queue instead of the real one. When the flag is present, the worker skips all normal queuing logic and renders a queuing page.

The page shows a fake estimated time remaining based on an asymptotic curve. It appears to decrease linearly at first, then flattens over time, so the estimate never quite reaches zero. Waiting Room Analytics tracks "infinite queue refreshes" to show how much time bots have wasted attempting to reach the site.

Ending sessions with origin commands

The second new feature, Session Revocation, lets origins actively terminate a user session rather than waiting for it to expire naturally. This is useful for applications with dynamic user flows where the session duration is configured high enough to accommodate users who send infrequent requests.

Waiting Room tracks users in time-based buckets. Each request moves a session from its previous bucket to the latest one. Once a bucket is older than the configured session duration, those sessions are considered expired and cleaned up, opening new slots. Because the system runs per request, it does not know when a user stops accessing the application. A user who visits briefly still counts toward the total active users until the session duration limit passes. With a high session duration configured, this can reduce throughput and increase wait times.

Session Revocation works through an HTTP header called Cf-Waiting-Room-Command. When an origin returns this header with the value revoke, the Waiting Room removes the session associated with the current response and decreases the total active user count for the bucket where the session was last tracked.

To enable the feature, check "Allow session termination via origin commands" in the user session settings, and configure the origin to return the header when appropriate. The analytics dashboard and the sessionsRevoked field in the GraphQL API show how many sessions were revoked per minute.

A large online retailer with frequent limited-edition product drops has already used this capability. Previously, the retailer had to restrict users to one item per cart and force them to wait after each checkout before rejoining the queue. With session revocation, the retailer ends the session immediately after purchase, placing the user back in the queue if applicable without a preset timeout. This reduces unnecessary wait times and streamlines the purchase process.

Together, the Turnstile integration and Session Revocation filter out automated traffic and free up queue slots more quickly, producing shorter wait times for genuine users.