Waiting Room

Ta treść nie jest jeszcze dostępna w Twoim języku.

The Waiting Room is a queue in front of the pages that fill up: a launch, a ticket sale, a checkout. It holds the crowd outside your server and lets people in at a pace your server can take. You set that pace in one of two ways:

By rate: how many people per minute get in. Everyone else waits in a waiting room served by Qlyne and comes back to the exact page they were on when it is their turn.
By capacity: how many people are on the site at the same time. While there is room and nobody is waiting, visitors go straight in without seeing the waiting room. When the site is full, new visitors wait and get in as others leave.

Whoever gets in receives a pass, signed by Qlyne, in a cookie. The pass is renewed while the person keeps browsing, so a long checkout is not cut short. The queue covers only the paths you pick, and the rest of the site stays open.

The Waiting Room is part of the Pro plan.

Turn it on

It runs in the connector: the Qlyne proxy, hosted or the Cloudflare Worker. On Next.js, the queue by rate works and the cap on people at once does not. With the connector installed:

In the dashboard, open your site and go to Waiting Room, Queues, Create queue. Give it a name, a Target URL on the same site as the busy pages, and a Release rate. Click Save queue.
Go to Waiting Room, Configuration. Under Routes on your site, click Add route, type the path, such as /tickets/*, and pick the queue it goes to. Save.
Leave the connector on “Observe only” for a day and look at the Waiting Room Overview: it counts the visitors who would have been sent to the waiting room. When the numbers make sense, switch to “Enforce” in Connector.

On Cloudflare, the Worker’s routes must cover the pages with a queue. The install from the Cloudflare dashboard is enough; the waiting room doesn’t need Wrangler.

Settings

Routes

Each line under Routes on your site sends one path to one queue. The path starts with /, and * matches the rest: /tickets/* covers /tickets/ and every page below it. A site holds up to 20 routes.
A visitor without a pass for that queue goes to the waiting room while the queue is open. Pages outside the routes are not touched.
Scripts, styles, images and fonts never go to the waiting room, so the page a released person lands on loads whole.

The queue

Each queue under Waiting Room, Queues has:

Queue name and Event key: the name your team sees, and the key the routes use (letters, numbers, -, _ and .).
Target URL: an address on the same site as the routed pages. A released person goes back to the page they were on only when it is on the same host as this address. Otherwise they land on the Target URL.
Release rate: people per minute, from 1 to 60,000. At 60 per minute, the 600th person in line waits about 10 minutes.
Max queue size: when the line is this long, new people are refused. 10,000 by default.
Open to new entries: turned off, the queue stops holding anyone. Its routes let every visitor through.
Access time: how long the pass lasts, from 30 to 3,600 seconds, 300 by default. It is renewed while the person browses (see What visitors see).

Changes reach the connector and the waiting room within a minute.

Capacity

If your server can only take so many people, fill in Max people on the site at once in the queue. While there are free slots and nobody is waiting, visitors go straight to your site without seeing the waiting room. When the site is full, new visitors wait in line and get in as slots free up, in the order they arrived. Left empty, only the release rate applies.

Free a slot after: seconds without any request before a person gives up the slot, from 60 to 7,200, 300 by default. The pass expires with the slot, so in a capacity queue this takes the place of Access time.
The list of queues shows “X / Y on the site” for each capacity queue.
With a capacity, the release rate still paces people leaving the line, and never lets out more than the free slots.
The cap only acts in “Enforce” mode, through the connector.

The waiting room page

The waiting room page can carry your color and logo.

The Waiting Room has no protection levels. Routes and queues belong to your site, so you set each one by hand.

What visitors see

A page view on a routed path without a pass: a redirect (302) to the waiting room on wait.qlyne.com, where the person waits for their turn.
An API call (a request that doesn’t ask for HTML) on a routed path without a pass: 403 with {"code": "QUEUE_REQUIRED", "waiting_room_url": "..."}. Your front end can send the person to that address.
Their turn: the waiting room sends the person back to the page they were on with ?qlyne_pass=. The connector checks the pass, keeps it in the qlyne_pass_<event_key> cookie (HttpOnly, Secure, SameSite=Lax) and redirects to the same address without the parameter.
A capacity queue with a free slot: the page itself, with the pass set on the same response.
A forged or expired pass, or one from another site, in that return link: 403 with “Your place expired. Go back to the site to join the line again.” It doesn’t send the person back to the line, so a wrong connector secret never turns into a redirect loop.
Browsing on: the pass is renewed on requests to routed pages once less than half its time is left, up to 2 hours after it was issued. After that, the person goes through the line again.
In observe mode nobody waits.

Limits

Free has no queues. On Free, the routes you saved stay in the dashboard, but the connector doesn’t apply them until the site is on Pro again. Pro allows 5 queues per site, Business 50. See Plans.
A queue can’t open or close on its own at a set time yet. You open and close it with Open to new entries.
The waiting room needs JavaScript. Without it, the person stays on the waiting room page.
The capacity count is approximate. Activity reaches Qlyne every 10 seconds or so, and a pass copied to another browser holds one slot. When the site is empty, a burst of visitors can take every free slot within the same second, since the release rate only paces people leaving the line.
One IP address (a /64 for IPv6) gets at most 10 slots by going straight in. Anyone else from it waits in line.
When the connector asks for a slot and Qlyne doesn’t answer within 1.5 seconds, the connector lets the visitor in and asks again 10 seconds later. Your site keeps working if Qlyne is down.
In observe mode, a rate queue counts who would have waited. A capacity queue does nothing and counts nothing.
A pass copied to another browser works there until it expires, at most 2 hours after it was issued.

FAQ

Does a visitor lose their place if they reload?

No. Reloading the waiting room picks up the same place in line. While it is open, the waiting room checks in every few seconds. A person who closes it and stays away longer than Leave the line after (180 seconds by default) gives up the place. Once in, the pass keeps them in while they browse.

What about people already on the site?

They have no pass yet. The next time one of them opens a routed page, they go to the waiting room like everyone else. Pages outside the routes keep working for them. In a capacity queue, only requests to routed pages count, so route the whole buying path (/shop/*) if you want everyone on it counted.

Does it work with a cart and checkout?

Yes. The pass cookie is valid on the whole host (Path=/), so the cart’s API calls carry it too. Check three things:

Give Access time (or Free a slot after) room for the slowest step, such as typing a card. The pass is renewed only on routed pages, so route the checkout too.
Keep the checkout on the same host. A pass set on shop.example.com doesn’t reach pay.example.com.
Keep your payment provider’s callbacks off routed paths. A server calling /checkout/webhook has no pass and gets 403 QUEUE_REQUIRED. Move the callback outside the route, or trust the provider’s addresses under IP lists.

Can I open the queue only at certain times?

Not yet. A queue holds people from the moment its route is saved and the queue is open. Open and close it yourself: with Open to new entries off, its routes let everyone through. Turn it on a few minutes before the sale, since changes take up to a minute to reach the connector.

How many visitors can it take?

On 2026-10-11, on our servers, 279 visitors a second went through the whole line (join, wait, get in, pass checked) with 1,000 people at once, answering in 20 ms at the 95th percentile. The pace at which your visitors get in is the one you set, up to 60,000 per minute per queue. Pick a release rate or capacity your own server handles with room to spare.

Troubleshooting

Everyone lands in the waiting room

A rate queue sends every visitor without a pass to the waiting room, even when the site is empty. To let people straight in while there is room, fill in Max people on the site at once.
In a capacity queue, nobody goes straight in while someone is waiting. One IP address gets at most 10 direct slots, so a test run from one office uses them up early.
The route is wider than you meant. /* covers the whole site; narrow it to the busy pages.

The line never moves

The release rate is low for the crowd. At 60 per minute, 3,000 people take 50 minutes. Raise Release rate; the waiting room picks it up within a minute.
In a capacity queue, slots free up only when people leave. Someone who stops browsing holds the slot for Free a slot after (5 minutes by default). Lower it, down to 60 seconds.
The visitor’s browser blocks JavaScript or wait.qlyne.com. The waiting room can’t check the place without them.

The pass expires in the middle of checkout

The person was let in and is sent back to the waiting room a few pages later. Causes, from the most common:

A step longer than Access time (Free a slot after in a capacity queue) with no request to a routed page, such as filling in the card. The pass is renewed only on routed pages. Raise the time, or route the whole checkout.
The checkout moved to another host, where the pass cookie doesn’t reach.
The pass was issued more than 2 hours ago. Renewal stops there, and the person goes through the line again.