Waiting Room now spans multiple hostnames and paths
Cloudflare Waiting Room protects sites from traffic surges by placing excess visitors in a customizable queue and admitting them dynamically as capacity frees up. Previously, each waiting room could only be tied to one hostname and path combination. The service now supports a single waiting room covering multiple hostname and path combinations — a feature available to Enterprise customers with an Advanced Purchase of Waiting Room.
When deploying a waiting room, customers specify a hostname and path to indicate which pages it covers. Requests to that hostname and path, plus any subpaths, receive a waiting room cookie that either admits the visitor or queues them if the site is at capacity. Waiting Room Bypass Rules, introduced last year, already allowed for exceptions like user agent bypassing, geo-targeting, URL exclusions, and administrative IP bypassing. But those rules refined coverage rather than expanding it.
The limitation surfaced in common site architectures. An online store using a single domain with path-based flow — example.com/, example.com/shop/product1, example.com/checkout — was already fully covered by one waiting room at example.com/ thanks to the implied wildcard after the configured path. Once a visitor passed the waiting room, they wouldn’t get re-queued later in the flow, since the same cookie persists across URLs.
Many sites, however, split shopping steps across subdomains — for instance, a checkout page at checkout.example.com. Prior to this update, protecting such a site with one waiting room was impossible without deploying separate waiting rooms per subdomain, which counted each queue entry separately and could place the same visitor in two lines during one journey.
There are still legitimate reasons to keep waiting rooms separate. A ticketing site, for example, might place a waiting room at the apex domain to protect the main entry point, then use additional waiting rooms with pre-queues on specific event pages. The new multi-hostname and path support gives customers the choice of one or many waiting rooms based on their site structure and use case.
Configuring additional routes
Customers can now add multiple hostname and path combinations — called routes — within the same zone. From the Waiting Room dashboard, select Create and then Add Hostname and Path to include another route. Since each path carries an implied wildcard, only URLs that wouldn’t be covered by existing routes need their own entry.
When a waiting room spans multiple hostname and path combinations, a unique cookie name is required during configuration. Deployment then follows the standard workflow.
Single waiting room for multilingual sites
One recurring customer request was a single waiting room for a multilingual site that serves different text per language while counting all traffic toward shared limits. Sites typically structure languages either by path (example.com/en, example.com/es) or by subdomain (en.example.com/, es.example.com/).
Path-based structures were already supported when gating the whole site using a waiting room at example.com/. But protecting specific high-demand product pages across languages — like example.com/en/product_123 and example.com/es/product_123 — previously required complex bypass logic. Subdomain-based language structures couldn’t be covered by a single waiting room at all.
With multi-hostname and path coverage, both approaches now work. To serve different languages while users queue, build a template that reads the URL to determine the locale and renders the appropriate translations. Locale extraction from the URL path uses locale = location.pathname.split("/")[1], with a default of "en" if no matching locale exists in the translations object. For subdomain-based sites, the locale is extracted from the hostname instead: locale = location.hostname.split(".")[0].
Starter templates demonstrating this approach are available in the developer documentation. They can be extended to additional languages by adding entries to the translations object, so a single template serves multiple locales whether sites delineate by subdomain or path.
How cookies work across multiple routes
Waiting Room assigns each user a __cfwaitingroom cookie that tracks queue position and other state needed for admission decisions. With a single hostname and path, the cookie is straightforward to set: __cfwaitingroom=[cookie-value]; Domain=example.com; Path=/es/product_123. Sharing one cookie across different subdomains or paths introduced complications.
Two approaches were evaluated for setting cookies across multiple routes. The first — issuing multiple Set-Cookie headers in the HTTP response — was rejected as unscalable. Browsers enforce implementation-specific response header limits (Chrome, for instance, fails at 256K bytes), and the header would grow proportionally with every additional route while repeating the same cookie value unnecessarily.
The second approach, which was implemented, sets the cookie on the apex domain or most common subdomain among the configured routes. For paths, the least common prefix across all routes is used as the path attribute. Given routes a.example.com/shoes/product_123 and b.example.com/shoes/product_456, the cookie domain becomes example.com and the path becomes /shoes.
Cookie collisions remain possible when multiple waiting rooms on the same site resolve to the same domain and path. Two waiting rooms covering shoes/product_123 and shoes/product_456 on different subdomains would both produce Domain=example.com; Path=/shoes, making it impossible to distinguish which waiting room applies. To avoid this, a custom cookie suffix unique to the customer’s zone is required when configuring a waiting room with multiple hostnames or paths. Distinct suffixes — “a” for Waiting Room A and “b” for Waiting Room B — let Waiting Room determine which cookie corresponds to a given request and apply the right queueing settings based on the visitor’s location on the site.
