Priority Protect - Waiting Room

This page describes every setting of a waiting room, and what happens when you change, deactivate or delete one. To choose values, see Best practices.

Create a waiting room

Go to Priority Protect > Priorities and click Create a waiting room. The form has two steps.

Step 1: Type

Choose the Activation Mode and the Visitor types, then click Next.

Time-Based: active between a start date and an end date. Best for product drops, flash sales and ticket releases.
Always on: active all the time. It holds visitors only when the site is full, which protects you against unexpected peaks.
Humans always go through the waiting room. AI agents recognised by DataDome always skip it, whatever you select here (see Direct access).

Step 2: Settings

General: the name and the rank.

Waiting room: capacity, scope, direct access, client-side validation and template.

Activation Period (Time-Based only): the start date, the pre-admission and the end date.

Click Create a waiting room. It usually applies on your site within a minute.

Settings

Setting	API field	Values	What it does
Activation Mode	`startAt` / `endAt`	Time-Based or Always on	A Time-Based waiting room is active between two dates. An Always on waiting room is active all the time and holds visitors only when the site is full
Name	`name`	Up to 64 characters	Identifies the waiting room in the Dashboard and the API. Visitors never see it
Rank (Priority)	`priority`	0 to 100,000, unique	Which waiting room applies when several match the same request. The lowest number wins. In the API, a waiting room without a rank gets 0
Maximum Concurrent Visitors	`maximumConcurrentVisitors`	0 or more	How many visitors can browse the protected pages at the same time. When it is reached, new visitors wait. With `0`, every visitor waits: useful for tests
No threshold		Checked or unchecked	No capacity limit: visitors are only paced by the admission rate
Admission Rate (Visitors Per Minute)	`admissionRatePerMinute`	Visitors per minute	How many waiting visitors are let in per minute when capacity is available
Inactivity Timeout (Minutes)	`inactivityTimeoutMinutes`	5 to 30. Default: 15	How long an admitted visitor keeps their place without making a request on a protected page. A session lasts at most 2 × this value
Matching Condition	`matchingCondition`	Traffic query	The requests the waiting room applies to
Direct access	`directAccessTrafficType`	Verified bots, Custom rules	Traffic that skips the waiting room and is not counted
Enforce client-side validation	`enforceClientSideValidation`	Checked or unchecked	Visitors leaving the waiting room must pass a challenge in their browser, for better AI threat detection
Template	`templateId`	Default or Custom	The page visitors see while they wait. The default page uses the browser's language
Waiting room start date	`startAt`	Activate immediately, or a date and hour	Time-Based only. Included. Must be before the end date
Pre waiting room setting › Duration (Minutes)	`preAdmission.durationMinutes`	0 to 1,440. Default: 30	Time-Based only. Visitors can join this many minutes before the start date. `0` turns pre-admission off. Needs a start date
Waiting room end date	`endAt`	No expiration date, or a date and hour	Time-Based only. Not included
Status	`isEnabled`	Activated or Deactivated	A deactivated waiting room keeps its settings but holds nobody

How visitors are counted

One visitor is one browser session, not an IP address or a request. Several tabs in the same browser count as one visitor.
A visitor counts from their first request on a protected page until their session expires. Each request on a protected page restarts the Session inactivity timeout.
Only requests that match the waiting room count. Pages outside the matching condition are not protected and not counted.
Direct access traffic, recognised AI agents and blocked bots are not counted.

Matching condition

The matching condition uses the traffic query syntax. You can combine fields with AND, OR, NOT and parentheses.

domain:shop.example.com AND url:/sale*                     every page under /sale
domain:shop.example.com AND (url:/sale* OR url:/api/sale*)  the pages and the app API
(countrycode:US OR countrycode:CA) AND url:/sale*           visitors from two countries
domain:*                                                    every domain of your account

Add * at the end of a path to include its sub-pages and query strings.
Include every URL variant, such as language prefixes (/fr/sale).
If customers can buy from your mobile app, add the API paths the app calls. Otherwise, app users skip the waiting room.

Rank

When a request matches several waiting rooms, only the one with the lowest rank applies. The others are ignored for that request. Give specific waiting rooms low numbers and broad ones high numbers, and leave gaps (100, 200, 300) to insert new ones later. Two waiting rooms cannot have the same rank.

Direct access

Direct access lets some traffic reach your site without waiting. This traffic is not counted in Maximum concurrent visitors, in the admission rate or in Metrics. It applies only to traffic that Bot Protect has already allowed.

Option	Who skips the waiting room	Recommendation
Verified bots	Search engine crawlers recognized by DataDome, such as Googlebot or Bingbot. A bot that only pretends to be one still waits	Turn it on to protect your SEO
Custom rules	Traffic that matches your Bot Protect Allow rules	Turn it on for partners, internal tools and monitoring

AI agents are handled by Agentic Trust, not by the waiting room. AI agents recognised by DataDome, such as Meta-ExternalAgent or ChatGPT-User, always skip the waiting room and are not counted. You decide which agents can access your site in https://docs.datadome.co/docs/agentic-trust-getting-started, built on Bot Protect. A bot that only pretends to be an AI agent still waits like any other visitor.

Time-Based waiting rooms

A time-based waiting room goes through three periods:

Period	What visitors see
Pre-admission (before the start date)	Everybody waits, whatever the traffic. The page can show the opening date
Between the start and end dates	Visitors wait only when Maximum concurrent visitors is reached. Admissions follow the admission rate
After the end date	The waiting room no longer applies

At the start date, size Maximum concurrent visitors for the opening rush: it decides how many pre-admitted visitors can be on your site at once.

Always on waiting rooms

An always-on waiting room starts holding visitors when traffic reaches Maximum concurrent visitors. It stops when nobody is waiting and traffic falls below 85% of the maximum. The gap avoids switching on and off when traffic hovers around the threshold.

Change a waiting room during an event

You can edit a waiting room while it holds visitors. Changes to capacity and admission rate apply within seconds.

Change	Effect
Raise Maximum concurrent visitors	More visitors are admitted, at the admission rate
Lower Maximum concurrent visitors	Visitors already on your site stay. New admissions stop until traffic is under the new value
Raise or lower the admission rate	The next admissions follow the new rate

Activate, deactivate or delete

Find the waiting room in Priority Protect > Priorities and open its actions menu (⋮). The menu also lets you Edit the waiting room, open its traffic in Explore, and Copy testing token.

Action	Settings	Visitors waiting	Metrics
Deactivate	Kept. You can reactivate it at any time	All admitted at once	Kept
Delete	Removed	All admitted at once	No longer available

❗️
Deactivating or deleting releases everyone at once
All waiting visitors reach your site within seconds. During an event, raise the admission rate step by step instead. Before deleting a waiting room, export the metrics you want to keep.

FAQ

What do waiting visitors receive?

An HTTP 429 response with the waiting room page. If a CDN or a monitoring tool sits in front of your site, make sure it does not cache this response and does not raise an alert for it during an event.

How long does a visitor keep their place once admitted?

Until their session expires: Session inactivity timeout after their last request on a protected page, and at most 2 × the timeout in total. After that, if visitors are waiting, they may go through the waiting room again.

Can several waiting rooms be active at the same time?

Yes. Each request goes through one waiting room at most: the matching one with the lowest rank. Each waiting room counts its own visitors.

How can my support team investigate a visitor's issue?

The waiting room page shows a Request ID. Search for it in Explore to see the session.