Random Queueing and New Customization Options Arrive in Cloudflare Waiting Room

Cloudflare Waiting Room is now generally available to Enterprise customers, and the company has expanded the product with several user-experience-focused features. The most significant addition is a new random queueing method, which joins the existing first-in-first-out (FIFO) approach. Support for custom web and mobile applications via a JSON response, plus configurable SameSite and Secure cookie attributes for embedding Waiting Rooms in IFrames, also ship with this release.

Why Random Queueing?

Waiting Room initially launched with FIFO queueing, a model familiar from everyday life where users are processed in the order they arrive. That approach served an early deployment protecting COVID-19 vaccine distributors under Project Fair Shot, but it has a drawback: users who join late may see long estimated wait times and abandon the page entirely.

Random queueing is designed to address that. Rather than guaranteeing that earlier arrivals are admitted first, every queued user has an equal chance at any given time of being let into the application. Early joiners still get more attempts, since they spend more time in the queue, but they gain no inherent advantage per draw.

This makes random queueing a strong fit for short-lived, high-demand events where hype drives traffic: product launches, limited-time sales, holiday rushes, and special promotions. FIFO remains the more suitable choice for steady-state scenarios, given its widely accepted structure and accurate estimated wait times.

Seamless Transitions Between Queueing Methods

One of the notable engineering details is that random queueing does not require a separate internal mechanism. The underlying structure that powers FIFO is preserved; switching methods in the dashboard simply changes which admission logic is applied. If you transition from FIFO to random and then back, users retain their original FIFO queue positions.

This works because Waiting Room still assigns users to minute-groups via an encrypted cookie’s bucketId, which is the timestamp of the user’s first request rounded down to the nearest minute. When random queueing is active, the system effectively pretends every user is new, ignoring the reserved slot logic that FIFO relies on. Because bucketId and reserved slots are still maintained, the queue can revert to FIFO without losing the original arrival order.

The slot allocation process is consistent across both methods. Given configurable limits for Total Active Users and New Users Per Minute, available slots are computed as the minimum of the open capacity and the per-minute limit. These slots are then distributed to each Cloudflare edge data center based on historical traffic share, and further divided among the Workers within a data center.

In FIFO mode, slots are reserved for users in the earliest bucketId groups first. If queued users do not consume all available slots, the remainder is offered to new users arriving without a cookie. In random mode, all available slots—regardless of how many users are queued—are offered to both queued and new users alike.

Checking the “Randomness”

Cloudflare took steps to prevent exploitation of the random admission process. Because queued users are limited by a per-user refreshIntervalSeconds value stored in the encrypted cookie, spamming the refresh button provides no advantage; the browser only updates when the interval has elapsed.

A more subtle vulnerability involved timing. If all users checked in at predictable intervals, such as the :00 and :30 marks, a new user who joined at :15 could monopolize the window between checks. Conversely, if new slots were always released at a fixed time, late joiners could be locked out entirely. To mitigate this, the implementation now releases slots randomly and adds a small, pseudo-random offset to each user’s refresh interval for every check-in. A user who typically refreshes every 30 seconds might wait 29 seconds, then 31, then 27. Over time, these variations spread check-in times out, making the queue less predictable.

Cloudflare also ran a simulation to validate the behavior empirically, modeling 10,000 users joining uniformly over 30 minutes, with each user spending about a minute on the origin after admission. Plots of wait times against arrival minute showed FIFO producing a linear relationship with minimal variance, while random queueing produced a widely scattered distribution. Heatmaps of the same data confirmed that users were admitted across the full range of arrival times, with the bulk concentrated at lower wait times—a pattern expected from a system where many users are admitted in the initial wave before Total Active Users capacity fills.

Estimating Wait Times for Random Queueing

Because any individual user can be admitted at any moment, random queueing cannot offer a precise estimated wait time. Instead, Cloudflare provides a probabilistic range based on two known values: letInPerMinute (the average admissions per minute) and currentlyWaiting (the number of users queued). The probability of being admitted in the next minute is:

P(LetInOverMinute) = letInPerMinute / currentlyWaiting

From there, the minutes needed for a given probability of admission p can be derived:

n = log(1 - p) / log(1 - P(LetInOverMinute))

Custom Mustache HTML templates can now surface these estimates using the variables waitTime25Percentile, waitTime50Percentile, and waitTime75Percentile, representing the wait times at p = .25, p = .5, and p = .75, respectively. Additional variables—queueingMethod, isFIFOQueue, and isRandomQueue—allow templates to adapt their messaging based on the active method.

JSON Responses for Dynamic Applications

Static Mustache HTML templates work well for many deployments, but they break when a custom application needs to maintain state across refreshes. A user watching an embedded video while queuing, for instance, would have that video reset each time the browser automatically reloads the page.

The new JSON response addresses this by giving full control to the application. When enabled for a Waiting Room, any request carrying the header Accept: application/json returns a JSON object containing all the fields available in the Mustache template. The application decides what to render and when to issue the next check-in request.

Three practical notes apply: first, the Waiting Room cookie must be included in requests, or the user will appear to be joining fresh each time. Second, the application is responsible for reading the Refresh response header or the refreshIntervalSeconds property and sending follow-up requests accordingly. Third, a user who is admitted to the origin may not receive JSON, so the origin should be configured to return JSON when the Accept: application/json header is present to keep client-side parsing straightforward.

SameSite Cookies and IFrame Support

Previously, Waiting Room cookies defaulted to SameSite=Lax because the attribute was not set. That meant a Waiting Room rendered inside an IFrame from a third-party site would never update its cookie—the user appeared as a new visitor on every request.

Cloudflare now allows the SameSite and Secure attributes to be configured through the Cloudflare API, a necessary step for IFrame deployments. The default setting is "auto", which selects the most flexible option: SameSite=None and Secure are applied if Always Use HTTPS is enabled, since SameSite=None requires Secure. Otherwise, SameSite=Lax is used without Secure.

Manual configuration is available, but it carries caveats. Setting secure="always" without Always Use HTTPS enabled will cause browsers to block the cookie for users on plain HTTP requests. The API does guard against configuring SameSite=None without Secure.

With this release, Waiting Room expands beyond its initial FIFO-only deployment into a more flexible tool, able to handle both bursty, hype-driven traffic and long-running spikes with appropriate queueing semantics, custom client experiences, and broader embedding options.