Planning for traffic you know is coming
Waiting Room has always acted as a safety net: when traffic surges past a site’s configured capacity, excess visitors are held in a virtual queue and admitted dynamically as spots open up. The queuing page itself is customizable, so users never feel as though they’ve left the site. Many customers run it as an always-on failsafe. But event-based traffic presents a different problem: the surge is expected, and the site’s behavior often needs to change at precise moments before, during, and after the event.
During a product drop or ticket sale, for example, a site might need to queue early visitors before the event starts, tighten session duration limits during the event itself, and then block access entirely once it has ended. Each stage requires different waiting room settings and a different queuing page — all switched over at exactly the right time. Manually updating configuration in lockstep with an event timeline is impractical when those changes are critical to the event’s success. Waiting Room Event Scheduling, available now to enterprise customers with an advanced Waiting Room subscription, lets you plan those changes in advance.
Scheduling cascading changes
With Event Scheduling, you set up discrete events that alter a waiting room’s behavior automatically at scheduled times. For each event you can customize traffic thresholds, session duration, queuing method, and the queuing page’s content and styling. The Create Event API documentation lists the full set of customizable settings.
Two new queuing methods extend the options for controlling user flow across the event lifecycle:
- Reject offloads traffic from your site entirely, presenting users with a static, fully customizable HTML page. This suits the post-event period, when you want to block access to event pages and let users know the event is over.
- Passthrough gives all visitors unrestricted access. Unlike disabling the waiting room, Passthrough can be scheduled to switch on or off ahead of time and still reports user traffic stats through the Waiting Room status endpoint.
Pre-queueing to protect the pre-event rush
You can also configure an event with a pre-queue: a virtual holding area for visitors who arrive before the event’s start time. Without it, enthusiastic fans may refresh a static landing page in the minutes before a ticket sale opens. Multiply that behavior by thousands of visitors, and the site can be overwhelmed before the event even begins. A pre-queue absorbs that early traffic, and since the pre-queue page is fully customizable, the pre-event moment can still be on-brand and build anticipation.
For events using First in First Out queuing, you can optionally shuffle the pre-queue. When the event starts, users who queued early are randomly assigned a place in line. This promotes fairness in events that span multiple time zones, preventing visitors in earlier time zones from gaining a systematic advantage. The order of entry for both the pre-queue and overflow queuing during the event is configurable, so you can tailor fairness to your event’s specific audience needs.
Deploying an event
Setting up an event requires a baseline waiting room first. Then it’s done entirely from the Waiting Room dashboard, with no coding or application changes. You specify the event’s start and end time, and optionally configure a pre-queue.
The event inherits its parent waiting room’s settings by default, so you only adjust what needs to change for the event’s duration. You can create an event-specific queuing page and preview it across queuing states and browsers to catch rendering issues before go-live.
Before saving, the dashboard shows the waiting room and event settings side by side, so you can verify how behavior will change during the event window.
Once saved, the event appears nested under its waiting room in the dashboard. The default view shows the date of each room’s next event, making it easy to spot which rooms will change. Expanding a row lists upcoming events with their durations, and a green dot next to the date confirms that a live event has kicked in.
A Flash Sale Walkthrough
To see how Event Scheduling works in practice, consider a fashion retailer preparing for a one-day flash sale with 40% off spring arrivals and free shipping. The marketing team plans an email campaign to targeted customers, and the web team needs to ensure the site stays up under the expected spike in traffic.
Setting Up the Sale
A week before the sale, Shopflare's web team builds a landing page with a countdown at example.com/sales/spring_flash_sale and attaches a waiting room configured with a First In First Out queuing method and traffic thresholds that keep the site performant. Early traffic to the landing page is therefore managed by the baseline waiting room. The team also schedules two cascading waiting room events ahead of time to handle the different phases of the sale.
Pre-Queueing and Overflow Control
Hours before the sale starts, Shopflare wants shoppers to be able to line up early, but a straight FIFO line would reward customers in earlier time zones. To keep things fair, they enable a randomized pre-queue: early arrivals are placed in line, then shuffled when the sale begins. The event creation workflow covers four steps: Details, Settings, Customization, and Review. On the Details page, the team enters the sale start and end times, sets the pre-queue start time, and enables “Shuffle at Event Start.”
During the sale itself, traffic in excess of the waiting room's configured limits is held in an overflow queue that admits users FIFO as spots open. Because the underlying waiting room already enforces the desired thresholds, the Settings page is left unchanged and the event inherits those limits.
Customizing the Queue Experience
On the Customization step, Shopflare uploads a single custom HTML template that covers both the pre-queueing page and the overflow queue. The pre-queue page is branded for the flash sale, shows the time remaining until the event starts, and reassures shoppers that the page refreshes automatically. The overflow page keeps the same look and feel but updates the messaging: it confirms shoppers are in the right place, provides an estimated wait time, and explains why they are queuing.
Wrapping Up the Sale
Once the sale concludes, Shopflare needs a five-minute grace period so active shoppers can finish their purchases, while new visitors should be turned away. For 48 hours after the sale, they want a static page informing visitors the sale has ended and linking back to the homepage.
They create a second event that starts when the first one ends, with no pre-queue. On the Settings page, they set session duration to five minutes, disable session renewal, and select the Reject All queuing method. This offloads all new traffic while giving active shoppers time to check out.
On the Customization tab, they override the underlying waiting room template once more and upload custom HTML for the reject page. After reviewing and saving, both events appear in the Waiting Room dashboard alongside the baseline configuration.
With the waiting room and its two scheduled events in place, Shopflare's site is protected throughout the sale, and shoppers get a transparent, on-brand queuing experience at every stage. Event Scheduling for Cloudflare Waiting Rooms provides the controls needed to tailor queue behavior to the specific requirements of any online event.
