Configuration settings
You can customize a variety of options for your waiting rooms.
Dashboard settings Additional details| Settings | Notes | ||||
| Dashboard Setting | API parameter | Required? | Description | Best practices | |
| Name | name | Yes | Unique waiting room name. | ||
| Hostname | host | Yes | Hostname for which the waiting room will be applied (no wildcards). | Do not include | |
| Path | path | No | Case-sensitive path of the waiting room. The waiting room will be enabled for all subpaths. Wildcards and query parameters are not supported. | If your server does not allow letter casing, use numbers in your | |
| Additional Hostnames and Paths | additional_routes | No | Add additional hostnames and/or paths to your waiting room coverage. | Additional hostnames must be within the same zone. Hostname and path combinations must be unique per waiting room. | |
| Custom Cookie Suffix | cookie_suffix | Required when using additional_routes. | Customize the suffix of your waiting room cookie. Suffix will be added to | Ensure your cookie name is compliant. Do not change this often. | |
| Total active users | total_active_users | Yes | The maximum number of active sessions allowed in | Set to 75% of origin traffic capacity and adjust as needed. Adjustments may affect estimated wait time shown to end users. | |
| New users per minute | new_users_per_minute | Yes | A threshold of users per minute that can be allowed into | Set to 100% of peak traffic to ensure users are only queued when necessary | |
| Session duration | session_duration | No | The amount of time in minutes (between 1 and 30) that a user who left | ||
| Session Revocation | | No | Revoke a user's session when they perform a specific action by sending a command to the waiting room using an HTTP header on the response from your origin. | Enable this setting in the dashboard and add the Cf-Waiting-Room-Command: revoke HTTP header to the response from your origin. | |
| Description | description | No | Description of the waiting room. | ||
| Disable session renewal | disable_session_renewal | No | Only available to Enterprise customers with purchase. If true, users only have | ||
| JSON response | json_response_enabled | No, defaults to false. | Send JSON body when receiving an | Set to | |
| Queueing status code | queueing_status_code | No, defaults 200 (OK). | HTTP status code to be returned while a user is queuing. | ||
When you configure new users per minute, this value is not the number of users added per minute.
Instead, it is the threshold of users allowed per minute (less than or equal to the number of total active users). You should set this value at 100% of your expected peak traffic to ensure users are only queued when necessary.
Session duration improves user experience in two ways.
First, it prevents visitors from having to pass through a waiting room twice for the same transaction. For example, a visitor might want to make a purchase at example.com. There's a lot of traffic at example.com, so they queue in the waiting room before entering the online store. After a period of time, they leave the waiting room and enter the online store. They make a purchase and leave the online store.
However, they forgot to add a note to the order or request a receipt. As long as their session cookie is still valid (for the length of time specified by the session duration), they can re-enter your application without having to re-queue in the waiting room.
Second, session duration lets your waiting room create a dynamic outflow from your application (in addition to dynamic inflow). A user's session cookie expires after a period of inactivity, meaning that new spots can open up as soon as space becomes available and estimated wait times are lower and more accurate.