Filtering Waiting Room Traffic with Bypass Rules

Cloudflare has extended its Waiting Room product with Waiting Room Bypass Rules, giving Enterprise customers on an Advanced Purchase plan granular control over which requests are queued. The feature uses the Ruleset Engine to let customers define expressions based on fields like IP address, URI path, query string, or country, so only the traffic they choose is subjected to queueing.

Waiting Room itself provides always-on protection during traffic surges by placing excess visitors in a customizable virtual queue instead of showing error pages or degrading site performance. Customers commonly pair it with Event Scheduling to manage traffic around product restocks, ticket sales, and seasonal promotions, with options to pre-queue early arrivals and offload origin traffic after events end. Until now, though, every request to a waiting room's configured hostname and path fell under its coverage. That left no straightforward way to let internal administrators through, skip monitoring user agents, or exclude specific subpaths and query strings.

Writing Rules for Who and What Gets Queued

Bypass rules let customers specify exactly which traffic should skip the queue. Because they supersede all Waiting Room states—including Queue-all mode and event pre-queuing—requests that match an enabled rule's expression are never queued and never receive a waiting room cookie. Rules are managed per waiting room through the Waiting Room API or the dashboard's standard rule builder interface. From the dashboard, each waiting room's expanded view shows a Manage rules option where rules can be created, disabled, or deleted.

The feature builds on the Ruleset Engine, the same infrastructure behind Origin Rules and WAF Managed Rulesets. The engine provides a unified representation for rules and a shared library for executing them, meaning the expression language and API semantics feel familiar to anyone who has worked with other Cloudflare rules products. Behind the scenes, creating a rule for a waiting room attaches a hidden ruleset to that room. A Cloudflare-managed ruleset runs on every request to a zone and dispatches to the customer's custom ruleset when the request matches the attached waiting room. If a rule's condition evaluates to true, the bypass action clears the flag that would have routed the request into Waiting Room logic, so the request is untouched and does not affect waiting room statistics.

Example: Administrative IP Bypass from the Dashboard

A common need is ensuring that internal employees can always reach a production site, particularly ahead of an event when pre-queueing has already begun. To set this up, first create an IP list if more than a handful of addresses are involved, then configure a waiting room. From the waiting room's expanded view, open Manage rules and build an expression with the rule builder:

  • Select IP Source Address from the Field drop-down.
  • Choose is in list from the Operator drop-down.
  • Select the name of the IP list.

The rule can be saved as a draft for later deployment or saved and enabled immediately. Once active, all requests matching the expression bypass the waiting room entirely. The waiting room table shows an indicator when a given room has active rules, so it is easy to see at a glance which rooms are applying bypass conditions.

Path bypass via the API

Waiting Room Bypass Rules also make it possible to exclude specific paths from a configured waiting room. Since a waiting room applies to a hostname/path combination and everything under that path, customers sometimes need to carve out particular URLs or query strings. A common example: a movie ticketing platform that uses a waiting room at ticketing.example.com/ to absorb purchasing surges for blockbuster releases. After a purchase, the platform emails or texts customers a link to ticketing.example.com/myaccount/mobiletickets/userverified?ticketid=, which opens a QR-code page in the mobile browser — the ticket the theater scans at the door. Those customers must not be put in a queue.

To make that exception, create a bypass rule with the Waiting Room API call below, after configuring the waiting room itself:

curl -X POST \"https://api.cloudflare.com/client/v4/zones/<ZONE_ID>/waiting_rooms/<ROOM_ID>/rules" \-H "Authorization: Bearer <API_TOKEN>" \
-d '{    
"description": "ticket holders bypass waiting room",    
"expression": "ends_with(http.request.uri.path, \"/userverified\")  
 "action": "bypass_waiting_room"
}'

The request URL needs the zone ID and waiting room ID, and the Authorization header carries the API token. The new rule is appended after any existing rules for that waiting room.

The request body starts with an optional description for easy reference:

"description": "ticket holders bypass waiting room"

The expression field defines which traffic bypasses the room. Since the direct links end with the path userverified, the rule uses an ends_with condition:

"expression": "ends_with(http.request.uri.path, \"/userverified\")

When writing an expression that bypasses a path, query string, or URL, remember to exclude subrequests that load page assets under the waiting room. Here, assets are hosted on a different subdomain not covered by the room, so no subrequest exclusions are needed.

Finally, set action to bypass_waiting_room and deploy. With that rule in place, the waiting room shields the ticket-purchase flow while mobile ticket QR pages load immediately for customers at the theater.

Waiting Room Bypass Rules let customers scope a waiting room precisely to the traffic they intend to protect. The Developer Documentation has further details and examples.