RDoc-4121 Cloud docs update for the October 2026 deployment

cloud/cloud-account.mdx

@@ -35,8 +35,13 @@ Each account user can be assigned specific roles that extend the range of functi
 | API Access                       | Controls programmatic access to the platform. Generate, manage, and revoke API keys.              |
 | Support                          | Create and manage support requests for general issues or specific products, active or terminated. |
 | Account                          | Provides access to general account information.                                                   |
-| Account with User Management     | Grants permissions to manage account users — invite or remove members, assign their [account roles](#account-roles), and manage their [product permissions](#product-permissions). |
+| Account with User Management     | Grants permissions to manage account users — invite or remove members, assign their [account roles](#account-roles), and manage their [product permissions](#product-permissions). With [External SSO](./cloud-sso.mdx#who-can-configure-sso) set up, it also adds SSO users and edits the SCIM group to role mapping. |
 | Account with Billing Information | Update credit cards, billing addresses, and payment contacts for your account.                    |
+| External SSO & User Management   | Set up and manage single sign-on (OIDC) and SCIM user provisioning. See [External SSO & User Management](./cloud-sso.mdx). |
+
+<Admonition type="note" title="">
+Account owners hold every role, including **External SSO & User Management**.
+</Admonition>
 
 ## Product permissions
 
@@ -62,7 +67,7 @@ Per-product access is assigned as a single **preset** — you choose one preset
 | Admin          | Everything a Manager can do, plus terminate the product. Does not include security settings.                         |
 | Security admin | Manages the product's security settings — client certificates, IP allowlists, monitoring IPs, and SNMP credentials.  |
 
-**Security admin** is an **add-on** enabled on top of a base preset (Viewer / Operator / Manager / Admin) with a dedicated toggle. It cannot be enabled for **No access**, and it cannot be toggled for a **Custom (legacy)** access level — an access level that predates the presets, shown (and locked) when editing such a user.
+**Security admin** is an **add-on** enabled on top of a base preset (Viewer / Operator / Manager / Admin). It is a switch at the bottom of each product's access-level menu, and an icon next to the selected level shows when it is on. It cannot be enabled for **No access**, and it cannot be toggled for a **Custom (legacy)** access level — an access level that predates the presets, shown (and locked) when editing such a user.
 
 <Admonition type="note" title="Security-related features">
 The **Monitoring/OpenTelemetry** and **Power BI** features are a special case. **Enabling or disabling** them requires the **Manager** (or **Admin**) preset **together with** the **Security admin** add-on. To only **configure** such a feature once it is enabled, the **Security admin** add-on is sufficient.
@@ -86,7 +91,7 @@ Permissions are assigned from the [Users & Access](./portal/cloud-portal-users-a
 
 Each account member carries a per-user **default product-permission set**. When a new product is provisioned, every member whose default is non-empty is automatically granted those permissions on the new product. A member with an empty default receives no access (this is the out-of-the-box value).
 
-* The default is set by the **Account Owner** only, in the invite-user and edit-user flows. Users with the **Account with User Management** role can manage per-product permissions, but they cannot change a user's default access for new products.
+* The default is set by the **Account Owner** only, in the **New products** section of the invite-user and edit-user panels. Users with the **Account with User Management** role can manage per-product permissions, but they cannot change a user's default access for new products.
 * It applies only to products created **after** it is set — it does not retroactively change access to existing products.
 
 <Admonition type="note" title="Product creator">

cloud/cloud-aws-marketplace.mdx

@@ -77,6 +77,9 @@ Provide the necessary information required to end the registration process:
 
 ![RavenDB Cloud AWS Marketplace Landing Page](./assets/cloud-ravendb-aws-marketplace-landing-page.png)
 
+The **Customer Identifier** and **AWS Account ID** at the top of the page are filled in from your *AWS* subscription.
+You only need them to [convert an existing Cloud account](../cloud/cloud-aws-marketplace.mdx#conversion-from-a-regular-cloud-account-to-an-aws-marketplace-account) to this subscription.
+
 1. **Email Address**  
    Provide an email address that you will use in RavenDB Cloud.
 
@@ -124,5 +127,6 @@ Successful cancellation process is also confirmed by an email from *AWS Marketpl
 
 ## Conversion from a regular Cloud Account to an AWS Marketplace Account
 
-If you would like to convert your existing *Cloud Account* to an *AWS Marketplace Account* to pay for your services using a credit card associated with your *AWS* account, please submit a support request from Cloud Account owner via the *RavenDB Cloud Portal*.
+If you would like to convert your existing *Cloud Account* to an *AWS Marketplace Account* to pay for your services using a credit card associated with your *AWS* account, please submit a support request from Cloud Account owner via the *RavenDB Cloud Portal*.  
+Include the **Customer Identifier** and **AWS Account ID** shown on the RavenDB Cloud page you reach from *AWS Marketplace* after subscribing.
 

cloud/cloud-backup-and-restore.mdx

@@ -76,7 +76,7 @@ Key constraints to keep in mind:
 - On undersized tiers the backup job may time out, be terminated due to memory exhaustion,
   or fail mid-run — leaving you without a usable recovery point.
 
-**Example:** A product running on a **PS10** (entry-level Performance tier) that hosts a
+**Example:** A product running on a **PS10** (the smallest Production instance type) that hosts a
 **500 GB database** will reliably fail to complete backups. The instance does not have enough
 resources — disk IOPS, memory, or both — to snapshot a database of that size. Customers in this
 situation must upgrade to a higher tier before backups can succeed.
@@ -201,28 +201,33 @@ Backup files that have already been created, are listed in the backups tab.
 * Open your portal's Backups tab, and choose the product whose database you want to restore.  
   Its backups will be shown, listed by the databases they've been created for.  
 * Click "Generate Restore Link" for the database you want to restore.  
-  The backup link window will open.
+  The **Restore Link** dialog will open.
   ![Backups List](./assets/portal-backups-database-list.png "Backups List")  
 #### Restore the Database  
 Clicking the **Generate Restore Link** button will show you a simple procedure. Follow it to restore your database.  
 
-![Backup Link](./assets/portal-backups-restore-link-modal.png)  
+![Restore Link](./assets/portal-backups-restore-link-modal.png)  
 
-* **A.** Create a **New Database From Backup**  
+The restore link is valid for **2 hours** by default. The dialog also estimates how long the restore will take,
+based on the size of the backup. If you need more time, pick a validity of up to **36 hours** in **Token Expiration**
+and click **Regenerate restore link**.
+
+* **Steps 1-3.** Create a **New Database From Backup**  
   ![New DB From Backup](./assets/studio-databases-new-database-from-backup.png)  
-* **B.** Choose **Cloud** as your Source  
+* **Step 4.** Choose **Cloud** as your Source  
   ![Source Is Cloud](./assets/studio-new-database-from-backup-source-cloud.png)  
-* **C.** Copy the Backup Link you've been given in the Backups Tab, to the **Backup Link** box here.  
+* **Step 5.** Copy the Restore Link you've been given in the Backups Tab, to the **Backup Link** box here.  
   ![Paste Backup Link Here](./assets/studio-new-database-from-backup-backup-link.png)  
-* **D.** Choose a **Restore Point**  
+* **Step 6.** Choose a **Restore Point**  
   ![Choose Restore Point](./assets/studio-new-database-from-backup-restore-point.png)  
-* **E.** Encryption Key for an **Encrypted** Database  
-  If your original database **is** encrypted, its backup has been encrypted with the same key. Find it and paste it here.  
-  ![Encryption Key: Encrypted Database](./assets/studio-new-database-from-backup-encryption-key.png)  
-* **F.**  Encryption Key for an **Unencrypted** Database  
-  If your original database is **not** encrypted, we used your account-wide encryption key to encrypt your backup file.  
-  Copy it from the right Backups Tab box.  
-  ![Encryption Key: Unencrypted Database](./assets/portal-backups-restore-link-modal-restore-key.png)  
+* **Step 7.** Provide the key that decrypts the backup:  
+  * **Snapshot backup of an encrypted database**  
+    The backup has been encrypted with the database's own key. Find it and paste it here.  
+    ![Encryption Key: Encrypted Database](./assets/studio-new-database-from-backup-encryption-key.png)  
+  * **Standard backup, or a database that is not encrypted**  
+    We used your account-wide encryption key to encrypt your backup file.  
+    Click **Show** next to the **restore key** in the dialog, or **Copy to clipboard**, and paste it here.  
+    ![Restore key in the Restore Link dialog](./assets/portal-backups-restore-link-modal-restore-key.png)  
 
 
 

cloud/cloud-features.mdx

@@ -200,15 +200,27 @@ You can read step by step OpenTelemetry & Grafana configuration [here](https://r
 *RavenDB Cloud* can resize your instance automatically, within a range you choose, so it follows your actual workload
 instead of being fixed to the size you provisioned.
 
-Scaling is driven by three sustained signals, each watched independently:
+Scaling is driven by three sustained signals:
 
 * **Load average** — how busy the node's CPUs are.
 * **Available memory** — how much memory is left for processing.
 * **IO wait** — how much time the node spends waiting on disk.
 
-Each signal has a low and a high limit, and each limit has its own duration. A limit must be breached for the whole of
-its duration before it counts, and a **grace period** then applies before the resize itself, so a brief spike never
-moves your instance.
+Each signal has a low and a high limit, and each limit has its own duration. Load average and available memory are
+averaged over that duration, and IO wait must stay past its limit for the whole of it, so a brief spike never moves
+your instance.
+
+The two directions combine the signals differently:
+
+* **Scaling up** takes one signal on one node. The cluster scales up when **any node** has a load average at or above
+  the high limit, available memory at or below the low limit, **or** IO wait above the max value.
+* **Scaling down** takes all three signals on every node. The cluster scales down only when **every node** has a load
+  average at or below the low limit, available memory at or above the high limit, **and** IO wait at or below the min
+  value.
+
+Each direction also has a **grace period**: a cooldown counted from the moment the last resize finished, including a
+resize you made yourself. The cluster does not scale up until the upscaling grace period has passed since then, and
+does not scale down until the downscaling grace period has passed.
 
 ### Autoscaling range
 
@@ -226,7 +238,7 @@ split into upscaling and downscaling parameters.
 
 | Parameter                            | Range       | Description                                                                                          |
 |--------------------------------------|-------------|------------------------------------------------------------------------------------------------------|
-| Upscaling grace period               | 3–60 min    | The delay before upscaling begins after a high resource threshold is exceeded, so short spikes do not trigger a resize. |
+| Upscaling grace period               | 3–1440 min  | The minimum time after the last resize, including a manual one, before the cluster can scale up again. |
 | High load average threshold          | 50–90%      | The average load percentage, over the *high load average threshold duration*, that triggers upscaling. |
 | High load average threshold duration | 180–600 sec | How long the average load must stay above the threshold before upscaling is triggered.               |
 | Low available memory threshold       | 1–15%       | The available memory percentage below which upscaling is triggered.                                  |
@@ -239,7 +251,7 @@ split into upscaling and downscaling parameters.
 
 | Parameter                           | Range       | Description                                                                                           |
 |-------------------------------------|-------------|-------------------------------------------------------------------------------------------------------|
-| Downscaling grace period            | 3–60 min    | The delay before downscaling begins after a low resource threshold is reached.                        |
+| Downscaling grace period            | 3–1440 min  | The minimum time after the last resize, including a manual one, before the cluster can scale down again. |
 | Low load average threshold          | 1–35%       | The average load percentage, over the *low load average threshold duration*, that triggers downscaling. |
 | Low load average threshold duration | 180–600 sec | How long the average load must stay below the threshold before downscaling is triggered.              |
 | High available memory threshold     | 20–90%      | The available memory percentage above which downscaling is allowed.                                   |

cloud/cloud-instances.mdx

@@ -111,7 +111,8 @@ with configurations that suit your needs.
 
 *Production tier* clusters can be also extended by [additional product nodes](../cloud/portal/cloud-portal-products-tab.mdx#nodes-additional-product-nodes).  
 <Admonition type="info" title="">
-This option is not available for **PS** instance types.
+This option is not available for **PS** and **PN** instance types, for Serverless products, or for
+products on a yearly contract.
 </Admonition>
 
 ![Production Tier](./assets/portal-product-create-plan-tier-production.png)
@@ -216,8 +217,8 @@ For instructions on how to create a Serverless product, see
 ### Autoscaling
 
 The cluster scales up and down automatically within a band you choose, driven by three sustained signals:
-**load average**, **available memory** and **IO wait**. Scaling moves one step at a time, and a grace period is applied
-before each step to prevent flapping caused by short load spikes.
+**load average**, **available memory** and **IO wait**. Scaling moves one step at a time, a signal counts only once it
+has been sustained, and a grace period after each resize keeps the cluster from flapping between sizes.
 
 Serverless Autoscaling is always enabled, and only its instance range — the lowest and highest type — is configurable;
 the thresholds and grace periods are managed for you. See

cloud/cloud-maintenance-troubleshooting.mdx

@@ -118,23 +118,24 @@ Suggestions are generated based on a 60-day period divided in half.
 
 #### Suggestion types
 
-**Cluster Health** is able to generate suggestions for *five* usage areas:
+**Cluster Health** is able to generate suggestions for *six* usage areas:
 
 - High CPU usage                                                         
 - High IO usage                        
 - Low memory mode                      
 - Low CPU credits                                                                      
 - Server restarted due to Out of Memory
+- Not responding
 
 #### Analyses
 
 Suggestions are generated using three types of analyses for specific suggestion types:
 
 | Analyse type                                     | Applicable to                                                   | Description                                                                                                 |
 |--------------------------------------------------|-----------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------|
-| Current period above previous period by percents | High CPU usage, High IO usage, Low memory mode, Low CPU credits | The duration of a specific event was longer in the current period than in the previous period.              |
-| Current period above previous period by numbers  | Server restarted due to Out of Memory                           | The number of occurrences of a specific event was higher in the previous period than in the current period. |
-| Current period above threshold by percents       | High CPU usage, High IO usage, Low memory mode, Low CPU credits | The duration of a specific event in the current period was longer than the threshold (5%).                  |
+| Current period above previous period by percents | High CPU usage, High IO usage, Low memory mode, Low CPU credits, Not responding | The duration of a specific event was longer in the current period than in the previous period, by at least 4 percentage points (0.01 for Not responding). |
+| Current period above previous period by numbers  | Server restarted due to Out of Memory                           | The number of occurrences of a specific event was higher in the current period than in the previous period, by at least 4. |
+| Current period above threshold by percents       | High CPU usage, High IO usage, Low memory mode, Low CPU credits, Not responding | The duration of a specific event in the current period was longer than the threshold (5%; 0.01% for Not responding). |
 
 Below examples of the suggestions with the analyses: 
 
@@ -169,7 +170,15 @@ A product can have **at most one** daily summary.
 
 * It covers **every** trigger event, so there is nothing to choose - the panel lists them all for reference.
 * The email groups the events by name and includes the counts for the period.
-* It also carries the current [Suggestions](#suggestions) for the product, when there are any.
+* It also lists **suggestions** worked out from **that day's events only** - not the 30-day
+  [Suggestions](#suggestions) shown on the Cluster Health page. A node gets a suggestion when, in the
+  last 24 hours, it had:
+  * *High CPU usage* for at least **5%** of the time,
+  * *High IO usage* for at least **3%** of the time,
+  * *Low memory mode* for at least **2%** of the time, or
+  * any *Low CPU credits*, *Not responding* or *Server restarted due to Out of Memory* event.
+* Only the part of an event that falls within the period counts. A suggestion whose event is still in
+  progress when the email is sent is marked as ongoing.
 * If nothing happened in the period, **no email is sent** - a daily summary never arrives empty.
 
 ### Custom alerts