Tutorial · cloudflare · Published 2026-08-15 · 4 min read
Cloudflare Waiting Room basics
Set up Cloudflare Waiting Room to queue excess traffic during launches. How total_active_users, new users per minute and session duration work.
What Waiting Room does
Cloudflare Waiting Room is a queue you place in front of a URL when traffic may exceed what the origin can handle. Instead of letting every concurrent visitor hit your servers at once and tipping them over, the edge admits traffic up to a configured limit and holds the rest in a queue with an estimated wait time. It is built for ticket drops, product launches, timed sales, and any burst where too many users at once would be worse than asking some to wait.
It is a queue, not a load balancer. The load balancer spreads a manageable level of traffic across pools; Waiting Room shapes the rate of arrival so the origin never receives more than its limit. See the load balancing guide for the pool side of that story.
How the queue decides who gets in
Two threshold settings control admission, and the user's browser holds a signed cookie that tracks their place:
| Setting | Meaning |
|---|---|
| Total active users | The maximum simultaneous sessions allowed on the covered path at any moment |
| New users per minute | The maximum rate at which new visitors are admitted every minute |
| Session duration | How long (1 to 30 minutes, default 5) a user stays "active" after their last request |
Visitors behind the thresholds land in the waiting room. Their page refreshes every 20 seconds while queued so they see an updated wait estimate. When a spot opens, the first group in is admitted first (FIFO), and the session cookie lets them return to the covered pages for the session duration without re-queuing.
The session_duration value also defines when a user is considered active, so it doubles as the valve that frees capacity: once a user goes quiet for that long, their slot can be reused.
Set the thresholds
- In the dashboard, open Traffic > Waiting Room and create a waiting room.
- Choose the hostname and path you are protecting. This is usually a specific page or checkout, not the whole site, so normal browsing stays unaffected.
- Set
total_active_users. Cloudflare recommends roughly 75% of your origin's real capacity so there is headroom under load. - Set
new_users_per_minuteto the sustainable arrival rate. Value it at about 100% of expected peak traffic so the queue only engages when demand is genuinely high. - Choose the session duration, then save and enable the waiting room.
A minimal rule for a launch page:
| Parameter | Example value |
|---|---|
| Path | /launch |
| Total active users | 1500 |
| New users per minute | 60 |
| Session duration | 10 minutes |
Test before you go live
Waiting Room does not change your origin configuration, so enable it on a staging path first and load-test the origin to learn its breaking point; the threshold you set should sit below that figure. Verify the covered path shows the queue page when you exceed the limit from a couple of test browsers, and confirm normal traffic passes straight through when you are under it. For a new ticketing or sale launch, run one short rehearsal with a low limit so a roll-out error surfaces before real customers queue.
Design notes
- Protect the narrowest path. A page-wide waiting room can queue bots and asset requests along with real visitors. Point it at the action that matters.
- Pair the queue with a load test. Waiting Room shifts the arrival curve; it does not invent capacity, so know the limit you are defending.
- The edge decides locally per data center, so admission is approximate across regions, not a single global counter.
When the queue fails because the origin is simply down
Waiting Room assumes the origin can serve the admitted traffic. If the origin is erroring, a 503 to every admitted visitor leaves them stuck in a broken session. Fix the origin first, then re-enable the queue. See HTTP 503 for separating a capacity problem from an origin outage.