[Waiting Room] Update waiting room capitalization usage (cloudflare#6657

)

* Corrected capitalization

* Changed capitalization

content/fundamentals/api/reference/permissions.md

@@ -146,8 +146,8 @@ The applicable scope of zone permissions is `com.cloudflare.api.account.zone`.
 | SSL and Certificates Edit        | Grants write access to SSL configuration and certificate management.     |
 | Sanitize Read                    | Grants read access to sanitization.                                      |
 | Sanitize Edit                    | Grants write access to sanitization.                                     |
-| Waiting Rooms Read               | Grants read access to Waiting Rooms.                                     |
-| Waiting Rooms Edit               | Grants write access to Waiting Rooms.                                    |
+| Waiting Room Read               | Grants read access to Waiting Room.                                     |
+| Waiting Room Edit               | Grants write access to Waiting Room.                                    |
 | Web3 Hostnames Read              | Grants read access to Web3 Hostnames.                                    |
 | Web3 Hostnames Edit              | Grants write access to Web3 Hostnames.                                   |
 | Workers Routes Read              | Grants read access to Cloudflare Workers and Workers KV Storage.         |

content/fundamentals/get-started/concepts/what-is-cloudflare.md

@@ -12,7 +12,7 @@ When you add your application to Cloudflare, we use this edge network to sit in
 
 ![Cloudflare sits in between requests and your origin server.](/fundamentals/static/images/get-started/website-with-cloudflare.svg)
 
-This [position](/fundamentals/get-started/concepts/how-cloudflare-works/) allows us to do several things — speeding up content delivery and user experience ([CDN](https://www.cloudflare.com/learning/cdn/what-is-a-cdn/)), protecting your website from malicious activity ([DDoS](https://www.cloudflare.com/learning/ddos/what-is-a-ddos-attack/), [Firewall](https://www.cloudflare.com/learning/ddos/glossary/web-application-firewall-waf/)), routing traffic ([Load balancing](/load-balancing/), [Waiting room](/waiting-room/)), and more.
+This [position](/fundamentals/get-started/concepts/how-cloudflare-works/) allows us to do several things — speeding up content delivery and user experience ([CDN](https://www.cloudflare.com/learning/cdn/what-is-a-cdn/)), protecting your website from malicious activity ([DDoS](https://www.cloudflare.com/learning/ddos/what-is-a-ddos-attack/), [Firewall](https://www.cloudflare.com/learning/ddos/glossary/web-application-firewall-waf/)), routing traffic ([Load balancing](/load-balancing/), [Waiting Room](/waiting-room/)), and more.
 
 {{<Aside type="note">}}
 

content/fundamentals/get-started/reference/cloudflare-cookies.md

@@ -51,11 +51,11 @@ The `cf_ob_info` cookie provides information on:
 
 The `cf_use_ob` cookie informs Cloudflare to fetch the requested resource from the Always Online cache on the designated port. Applicable values are: 0, 80, and 443. The `cf_ob_info` and `cf_use_ob` cookies are persistent cookies that expire after 30 seconds.
 
-### \_\_cfwaitingroom for Cloudflare Waiting Rooms
+### \_\_cfwaitingroom for Cloudflare Waiting Room
 
 [Cloudflare’s Waiting Room](/waiting-room/) product enables a waiting room for a particular host and path combination within a zone. Visitors are put in the waiting room and provided an estimate of when they will be allowed to access the application, if not immediately available.
 
-The `__cfwaitingroom` cookie is only used to track visitors that access a Waiting Room enabled host and path combination for a zone. Visitors using a browser that does not accept cookies cannot visit the host and path combination while the Waiting Room is active. For more details, see [Waiting Room cookie](/waiting-room/reference/waiting-room-cookie/).
+The `__cfwaitingroom` cookie is only used to track visitors that access a waiting room enabled host and path combination for a zone. Visitors using a browser that does not accept cookies cannot visit the host and path combination while the waiting room is active. For more details, refer to [Waiting Room cookies](/waiting-room/reference/waiting-room-cookie/).
 
 ### \_\_cfruid to support Cloudflare Rate Limiting (previous version)
 

content/http-applications/reference/available-settings.md

@@ -11,7 +11,7 @@ When you use HTTP applications, you can edit various configuration settings, inc
 Generally, you are allowed to edit all of the zone-level configurations except for the following:
 
 - DNS
-- Traffic (Load Balancing, Waiting Rooms, Health Checks, and more)
+- Traffic (Load Balancing, Waiting Room, Health Checks, and more)
 - Zero Trust and Access policies
 - SSL certifications (though you can test these with a separate [staging certificates](/ssl/edge-certificates/staging-environment/) feature)
 

content/tenant/reference/subscriptions.md

@@ -60,7 +60,7 @@ The following table lists sample values for various application performance and
 | [Load balancing](/load-balancing/) | `PARTNERS_LOAD_BALANCING`, `PARTNERS_LOAD_BALANCING_ENT`, `LOAD_BALANCING_BASIC_PLUS` |
 | [Rate limiting](/waf/rate-limiting-rules/) | `PARTNERS_RATE_LIMITING` |
 | [Spectrum](/spectrum/) | `PARTNERS_SPECTRUM` |
-| [Waiting room](/waiting-room/) | `WAITING_ROOMS_BASIC` |
+| [Waiting Room](/waiting-room/) | `WAITING_ROOMS_BASIC` |
 
 ## Getting new subscriptions
 

content/waiting-room/_index.md

@@ -12,9 +12,9 @@ Cloudflare Waiting Room protects websites by queueing site visitors when a websi
 
 ## Benefits
 
-Waiting rooms protect **your origin server** by preventing surges in legitimate traffic that may overload your origin.
+Waiting Room protects **your origin server** by preventing surges in legitimate traffic that may overload your origin.
 
-Waiting Rooms also benefit **your visitors** by:
+Waiting Room also benefits **your visitors** by:
 
 - Keeping your application online and preventing them from reaching error pages.
 - Showing estimated wait times that are continuously updated.
@@ -33,7 +33,7 @@ Once you have [created and activated a waiting room](/waiting-room/get-started/)
   - When a user exits the waiting room and reaches your application, they can leave and re-enter without waiting for the length of time specified by the [session duration](/waiting-room/reference/configuration-settings/#session-duration/).
   - Because waiting rooms support dynamic inflow and [outflow](/waiting-room/reference/configuration-settings/#session-duration/), new spots appear more quickly and estimated wait times are lower and more accurate.
 
-![Waiting room process flow showing how a request is managed by Cloudflare and placed in a waiting room before reaching the origin website](/waiting-room/static/waiting-room-process-flow.png)
+![Waiting Room process flow showing how a request is managed by Cloudflare and placed in a waiting room before reaching the origin website](/waiting-room/static/waiting-room-process-flow.png)
 
 ## Availability
 
@@ -46,9 +46,9 @@ Access to certain features depends on a customer's [plan type](/waiting-room/pla
 
 ## Prerequisites
 
-- Cloudflare’s CDN is required to use the waiting room feature.
+- Cloudflare’s CDN is required to use the Waiting Room feature.
 - Configure a [proxied DNS record](/dns/manage-dns-records/how-to/create-dns-records/) or a [proxied load balancer](/load-balancing/understand-basics/proxy-modes/) for the waiting room’s hostname. A DNS record is not auto-configured after a waiting room is created.
-- Visitors must enable cookies. Refer to [Waiting room cookie](/waiting-room/reference/waiting-room-cookie/) for information on how cookies are used in Cloudflare Waiting Rooms.
+- Visitors must enable cookies. Refer to [Waiting Room cookies](/waiting-room/reference/waiting-room-cookie/) for information on how cookies are used in Cloudflare Waiting Room.
 
 {{<button-group>}}
   {{<button type="primary" href="/waiting-room/get-started/">}}Get started{{</button>}}

content/waiting-room/additional-options/create-events.md

@@ -15,20 +15,20 @@ Any properties set on the event will override the default property on the waitin
 ## Create an event from the dashboard
 
 1.  Within your application, go to **Traffic** > **Waiting Rooms**.
-2.  Expand a Waiting Room  and click **Schedule Event**.
+2.  Expand a waiting room  and click **Schedule Event**.
 3.  Customize the details for your event: name the event, add a description (optional), and select a Start Date Time and an End Date Time.
 4.  You can also enable the pre-queueing — in this case you need to define a pre-queueing time. And you can also select **Shuffle at Event Start** and all users in the pre-queue will be randomly admitted at event start.
 5.  Click **Next**.
-6.  In the **Settings** section, you can define new values for your Total active users, New users per minute, Session duration, Session Renewal, and Queueing Method. For each of these settings you also have the option to always inherit the values defined in your waiting room. With this option, if you change the settings of your base Waiting Room, the corresponding Event setting will update as well.
+6.  In the **Settings** section, you can define new values for your Total active users, New users per minute, Session duration, Session Renewal, and Queueing Method. For each of these settings you also have the option to always inherit the values defined in your waiting room. With this option, if you change the settings of your base waiting room, the corresponding Event setting will update as well.
 
     {{<Aside type="note">}}If you choose to override the values of Total active users, you must also override the number of New users per minute, and vice versa.{{</Aside>}}
 
 7.  Click **Next**.
-8.  In the customization section, you can select Always inherit your Waiting Room’s template (default) or you can override it with a Custom Event Template. In this case, you need to import your own template. M​ake sure to preview the result before continuing.
+8.  In the customization section, you can select Always inherit your waiting room’s template (default) or you can override it with a Custom Event Template. In this case, you need to import your own template. M​ake sure to preview the result before continuing.
 9.  Click **Next** and review your Event details and settings.
 10.  Click **Save**.
 
-In your Waiting Room page, in the **Next Event** column you can visualize the date of the next event scheduled. This columns will read `N/A` in case there is no event scheduled for that waiting room. You can always suspend, edit or delete your event.
+In your waiting room page, in the **Next Event** column you can visualize the date of the next event scheduled. This columns will read `N/A` in case there is no event scheduled for that waiting room. You can always suspend, edit or delete your event.
 
 {{<Aside type="note">}}You have a limit of five events per waiting room.{{</Aside>}}
 

content/waiting-room/additional-options/embed-waiting-room-in-iframe.md

@@ -16,7 +16,7 @@ However, this behavior can prevent a waiting room from queueing a user properly
 
 ## Available options
 
-To customize how your waiting room responds to cookies, include the `cookie_attributes` object when you [create a Waiting Room](https://api.cloudflare.com/#waiting-room-create-waiting-room) (only available via the API).
+To customize how your waiting room responds to cookies, include the `cookie_attributes` object when you [create a waiting room](https://api.cloudflare.com/#waiting-room-create-waiting-room) (only available via the API).
 
 Available options include:
 
@@ -35,7 +35,7 @@ Available options include:
 
 ## Allow cookies to pass through iFrames
 
-If you are embedding a waiting room in an iFrame, specify the following values on `cookie_attributes` object when [creating a Waiting Room](https://api.cloudflare.com/#waiting-room-create-waiting-room) (only available via the API):
+If you are embedding a waiting room in an iFrame, specify the following values on `cookie_attributes` object when [creating a waiting room](https://api.cloudflare.com/#waiting-room-create-waiting-room) (only available via the API):
 
 *   `samesite`: `none`
 *   `secure`: If you have [**Always Use HTTPS**](/ssl/edge-certificates/additional-options/always-use-https/) enabled, set to `auto`. If you have it disabled, set to `always`.

content/waiting-room/additional-options/test-waiting-room.md

@@ -6,7 +6,7 @@ weight: 9
 
 # Test a waiting room
 
-Follow this tutorial to ensure your Waiting Room queues and admits users as expected.
+Follow this tutorial to ensure your waiting room queues and admits users as expected.
 
 {{<Aside type="warning" header="Warning:">}}
 This tutorial uses an open-sourced load testing tool that is not created or supported by Cloudflare.

content/waiting-room/additional-options/waiting-room-rules/bypass-rules.md

@@ -42,7 +42,7 @@ To create a new bypass rule:
 
 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account and domain.
 2. Within your application, go to **Traffic** > **Waiting Rooms**.
-3. Expand a Waiting Room and select **Go to rules**.
+3. Expand a waiting room and select **Go to rules**.
 4. Select **Create new Bypass rule**.
 5. Enter a descriptive name for the rule in **Rule name**.
 6. Under **When incoming requests match**, define the rule expression. Use the **Field** drop-down list to choose an HTTP property. For each request, the value of the property you choose for **Field** is compared to the value you specify for **Value** using the operator selected in **Operator**.

content/waiting-room/how-to/_index.md

@@ -8,6 +8,6 @@ meta:
 
 # Common tasks
 
-When working with Cloudflare Waiting Rooms, you will commonly perform the following tasks:
+When working with Cloudflare Waiting Room, you will commonly perform the following tasks:
 
 {{<directory-listing>}}

content/waiting-room/how-to/control-waiting-room.md

@@ -19,7 +19,7 @@ To enable a waiting room:
 
 By default, an active waiting room puts visitors in a queue when traffic approaches the target thresholds defined in **Total active users** and **New users per minute**. Refer to [Queuing activation](/waiting-room/how-to/monitor-waiting-room/#queueing-activation) for more information.
 
-However, if you want all visitors to be queued for a predefined amount of time — in preparation for a product release or other time-based event — use the Waiting Room [event prequeuing](/waiting-room/additional-options/create-events/) option.
+However, if you want all visitors to be queued for a predefined amount of time — in preparation for a product release or other time-based event — use the [Create scheduled events](/waiting-room/additional-options/create-events/) option.
 
 You may also use the **Queue All** option on a waiting room as an emergency stop to all traffic during unexpected or temporary downtime. As long as the waiting room is active and **Queue All** is enabled, no traffic will reach your application.
 

content/waiting-room/how-to/edit-delete-waiting-room.md

@@ -6,7 +6,7 @@ weight: 5
 
 # Edit and delete waiting rooms
 
-You can manage your waiting rooms using the [Waiting Rooms dashboard](/waiting-room/how-to/waiting-room-dashboard/) or the [API](/waiting-room/reference/waiting-room-api/).
+You can manage your waiting rooms using the [Waiting Room dashboard](/waiting-room/how-to/waiting-room-dashboard/) or the [API](/waiting-room/reference/waiting-room-api/).
 
 {{<Aside type="note">}}For details about updating an active waiting room, refer to [Best practices](/waiting-room/reference/best-practices/).{{</Aside>}}
 

content/waiting-room/how-to/json-response.md

@@ -51,9 +51,9 @@ header: Response
 
 ## Cookies in the request header
 
-Waiting Room is driven by a waiting room cookie, that determines the position of the user in the queue. Because of this, the cookie must be included in each of the subsequent requests to the waiting room API for the user. This is mandatory regardless of a user having been queued or not. If a request does not include a cookie, the waiting room will assume a new user and will return a new cookie in the response header. Consequently, this will place the user at the end of the queue. Thus, when consuming the waiting room in a non-browser environment it is important to include the waiting room cookie in the request header.
+Waiting Room is driven by a waiting room cookie, that determines the position of the user in the queue. Because of this, the cookie must be included in each of the subsequent requests to the Waiting Room API for the user. This is mandatory regardless of a user having been queued or not. If a request does not include a cookie, the waiting room will assume a new user and will return a new cookie in the response header. Consequently, this will place the user at the end of the queue. Thus, when consuming the waiting room in a non-browser environment it is important to include the waiting room cookie in the request header.
 
-Refer to the [waiting room cookies](/waiting-room/reference/waiting-room-cookie/), for more information.
+Refer to the [Waiting Room cookies](/waiting-room/reference/waiting-room-cookie/), for more information.
 
 ## Advancing in the queue
 
@@ -72,7 +72,7 @@ These are some of the places where the JSON-friendly response can be consumed (t
     - **Enable JSON response** - Via the dashboard or via the API.
     - **Consume JSON data** - Make a request to the waiting room endpoint with the `Accept: application/json` header.
 
-        Here is an example, demonstrating the usage of the waiting room endpoint inside a Worker. The request headers include the necessary `accept` and `cookie` header values that are required by the waiting room API. The accept header ensures that a JSON-friendly response is returned, if a user is queued. Otherwise, if the request is sent to the origin, then whatever the response origin returns gets returned back. In this example, a hardcoded `__cfwaitingroom` value is embedded in the cookie field. In a real-life application, however, we expect that a cookie returned by the waiting room API is used in each of the subsequent requests to ensure that the user is placed accordingly in the queue and let through to the origin when it is the users turn.
+        Here is an example, demonstrating the usage of the waiting room endpoint inside a Worker. The request headers include the necessary `accept` and `cookie` header values that are required by the Waiting Room API. The accept header ensures that a JSON-friendly response is returned, if a user is queued. Otherwise, if the request is sent to the origin, then whatever the response origin returns gets returned back. In this example, a hardcoded `__cfwaitingroom` value is embedded in the cookie field. In a real-life application, however, we expect that a cookie returned by the Waiting Room API is used in each of the subsequent requests to ensure that the user is placed accordingly in the queue and let through to the origin when it is the users turn.
 
 ```bash
 const waitingroomSite = 'https://examples.cloudflareworkers.com/waiting-room';
@@ -104,7 +104,7 @@ addEventListener('fetch', event => {
 
 {{<Aside type="note">}}
 
-Only Advanced waiting room customers can support JSON-friendly format with their waiting rooms. For more details, refer to our [Plans page](/waiting-room/plans/).
+Only Advanced Waiting Room customers can support JSON-friendly format with their waiting rooms. For more details, refer to our [Plans page](/waiting-room/plans/).
 
 {{</Aside>}}
 

content/waiting-room/how-to/monitor-waiting-room.md

@@ -10,7 +10,7 @@ You can monitor the status of your waiting rooms using the [dashboard](#status-i
 
 Note that the **Total active users** and **Queued users** shown in the dashboard, as well as through API endpoints are estimates. That data corresponding to each of these metrics is cached for around 30 seconds after the time it takes to be synced from all data centers globally. Therefore, the status will range between 20-50 seconds in the past, depending on the exact moment the data was queried, aggregated, as well as the age of the cache.
 
-{{<Aside>}}Future work will create a separate area of application analytics for Cloudflare Waiting Rooms.{{</Aside>}}
+{{<Aside>}}Future work will create a separate area of application analytics for Cloudflare Waiting Room.{{</Aside>}}
 
 ## Status in the dashboard