Queue-it
Waiting room
Also known as: Virtual Waiting Room, queueittoken
Not a bot blocker at all: a fairness queue that answers with 302 redirects, so its signature is a redirect to a queue-it.net waiting room rather than an error.
Queue-it is included here because it is regularly mistaken for bot protection. It is a virtual waiting room, used for ticket sales, product drops, exam results, and anything else where demand arrives in a spike. It does not decide whether you are a bot; it decides when it is your turn.
The mechanics are redirect-based and unusually transparent. When a site is over capacity, visitors are sent to a branded waiting room with an HTTP 302. When their turn comes, they are 302'd back to the original destination with a queueittoken query parameter appended. That token is a delimited structure carrying the event and queue identifiers, a timestamp, and an HMAC-SHA256 signature computed with the operator's secret. A connector at the origin validates that signature before letting the request through.
Because the signature is keyed on a secret only the operator holds, a token cannot be constructed by a client. Arriving at the destination URL without a valid token simply sends you back to the queue, which is why direct navigation to a queued URL loops.
How to identify it
- A 302 to a hostname under queue-it.net.
- A queueittoken parameter appended to the destination URL after release.
- A QueueITAccepted cookie set once the connector has validated the token.
- Waiting room page copy showing a position in line and an estimated wait.
Cookies
- QueueITAccepted: Set by the connector after it validates the queue token. Carries the proof that this session came through the waiting room.
Status codes
302 Redirect into the waiting room
Rate limited. Documented by the vendor.
The site is over its configured capacity and this session has been placed in the queue.
What triggers it
- Traffic above the operator's configured throughput for the event.
- Any request to a protected URL without a valid queue token.
How to confirm it
- A Location header pointing at a queue-it.net host, carrying the event identifier.
What to do about it
- Follow the redirect and wait. This is one of the very few responses in this glossary where patience is precisely the intended behaviour and it genuinely works.
- Do not attempt to skip the queue. The token is HMAC signed with a secret you do not have, so the only outcomes available are waiting or looping.
- Preserve cookies across the wait. A client that discards them will rejoin the queue at the back each time.
HTTP/2 302 location: https://example.queue-it.net/?c=example&e=eventid&t=https%3A%2F%2Fwww.example.com%2Fcheckout
302 Release to the destination
Allowed. Documented by the vendor.
The queue released this session and is redirecting it back to the original URL with a signed token.
What triggers it
- The session reaching the front of the queue.
How to confirm it
- A Location header pointing at the original destination with a queueittoken parameter appended.
What to do about it
- Follow the redirect promptly and keep the token intact. Stripping the query string, or normalising the URL, discards the proof of your place in line.
- Tokens are time-bounded, so a client that sits on a release for too long will be sent back to the queue.
If you run a site behind it
- A waiting room solves fairness and capacity, not abuse. Pair it with actual bot management if the demand you are queueing is worth automating against, or you will simply queue the bots politely.
- Validate the token at the origin on every protected request. The redirect alone is not enforcement.
If your traffic is being caught by it
- A 302 to queue-it.net is not a block. Nothing is wrong with your client and nothing needs fixing.
- Keep cookies and follow redirects, and the queue resolves itself.