Fix typos, formatting

Author: Blargian

docs/en/cloud/manage/_snippets/_network_transfer_rates.md

@@ -9,7 +9,7 @@ The table below shows how data transfer charges for egress vary across public in
             <th>Region</th>
             <th>Public Internet Egress</th>
             <th>Same region</th>
-            <th>Cross-region (all Tier 1)</th>
+            <th>Cross-region <br/>(all Tier 1)</th>
         </tr>
     </thead>
     <tbody>
@@ -112,40 +112,40 @@ $^*$Data transfer charges are in $ per GB of data transferred
         <td>`us-central1`</td>
         <td>`$0.1140`</td>
         <td>`$0.0000`</td>
-        <td>`$0.0360 (Tier 1)`</td>
-        <td>`$0.0720 (Tier 2)`</td>
-        <td>`$0.1200 (Tier 3)`</td>
-        <td>`$0.1620 (Tier 4)`</td>
+        <td>`$0.0360` (Tier 1)</td>
+        <td>`$0.0720` (Tier 2)</td>
+        <td>`$0.1200` (Tier 3)</td>
+        <td>`$0.1620` (Tier 4)</td>
     </tr>
     <tr>
         <td>`GCP`</td>
         <td>`us-east1`</td>
         <td>`$0.1140`</td>
         <td>`$0.0000`</td>
-        <td>`$0.0360 (Tier 1)`</td>
-        <td>`$0.0720 (Tier 2)`</td>
-        <td>`$0.1200 (Tier 3)`</td>
-        <td>`$0.1620 (Tier 4)`</td>
+        <td>`$0.0360` (Tier 1)</td>
+        <td>`$0.0720` (Tier 2)</td>
+        <td>`$0.1200` (Tier 3)</td>
+        <td>`$0.1620` (Tier 4)</td>
     </tr>
     <tr>
         <td>`GCP`</td>
         <td>`europe-west4`</td>
         <td>`$0.1140`</td>
         <td>`$0.0000`</td>
-        <td>`$0.0720 (Tier 2)`</td>
-        <td>`$0.0360 (Tier 1)`</td>
-        <td>`$0.1200 (Tier 3)`</td>
-        <td>`$0.1620 (Tier 4)`</td>
+        <td>`$0.0720` (Tier 2)</td>
+        <td>`$0.0360` (Tier 1)</td>
+        <td>`$0.1200` (Tier 3)</td>
+        <td>`$0.1620` (Tier 4)</td>
     </tr>
     <tr>
         <td>`GCP`</td>
         <td>`asia-southeast1`</td>
         <td>`$0.1440`</td>
         <td>`$0.0000`</td>
-        <td>`$0.1200 (Tier 3)`</td>
-        <td>`$0.1200 (Tier 3)`</td>
-        <td>`$0.1200 (Tier 3)`</td>
-        <td>`$0.1620 (Tier 4)`</td>
+        <td>`$0.1200` (Tier 3)</td>
+        <td>`$0.1200` (Tier 3)</td>
+        <td>`$0.1200` (Tier 3)</td>
+        <td>`$0.1620` (Tier 4)</td>
     </tr>
     </tbody>
 </table>
@@ -176,30 +176,30 @@ $^*$Data transfer charges are in $ per GB of data transferred
         <td>`eastus2`</td>
         <td>`$0.1020`</td>
         <td>`$0.0000`</td>
-        <td>`$0.0300 (Tier 1)`</td>
-        <td>`$0.0660 (Tier 2)`</td>
-        <td>`$0.0660 (Tier 2)`</td>
-        <td>`$0.0660 (Tier 2)`</td>
+        <td>`$0.0300` (Tier 1)</td>
+        <td>`$0.0660` (Tier 2)</td>
+        <td>`$0.0660` (Tier 2)</td>
+        <td>`$0.0660` (Tier 2)</td>
     </tr>
     <tr>
         <td>`Azure`</td>
         <td>`westus3`</td>
         <td>`$0.1020`</td>
         <td>`$0.0000`</td>
-        <td>`$0.0300 (Tier 1)`</td>
-        <td>`$0.0660 (Tier 2)`</td>
-        <td>`$0.0660 (Tier 2)`</td>
-        <td>`$0.0660 (Tier 2)`</td>
+        <td>`$0.0300` (Tier 1)</td>
+        <td>`$0.0660` (Tier 2)</td>
+        <td>`$0.0660` (Tier 2)</td>
+        <td>`$0.0660` (Tier 2)</td>
     </tr>
     <tr>
         <td>`Azure`</td>
         <td>`germanywestcentral`</td>
         <td>`$0.1020`</td>
         <td>`$0.0000`</td>
-        <td>`$0.0660 (Tier 2)`</td>
-        <td>`$0.0300 (Tier 1)`</td>
-        <td>`$0.0660 (Tier 2)`</td>
-        <td>`$0.0660 (Tier 2)`</td>
+        <td>`$0.0660` (Tier 2)</td>
+        <td>`$0.0300` (Tier 1)</td>
+        <td>`$0.0660` (Tier 2)</td>
+        <td>`$0.0660` (Tier 2)</td>
     </tr>
     </tbody>
 </table>

docs/en/cloud/manage/backups.md

@@ -178,8 +178,9 @@ Change the `ENGINE` to `ReplicatedMergeTree` without any parameters when you run
 Use the `remoteSecure` function to pull the data from the newly restored ClickHouse Cloud service into your original service:
 
   ```sql
-  INSERT INTO db.table SELECT * FROM
-  remoteSecure('source-hostname', db, table, 'exporter', 'password-here')
+  INSERT INTO db.table 
+  SELECT * 
+  FROM remoteSecure('source-hostname', db, table, 'exporter', 'password-here')
   ```
 
 After you have successfully inserted the data into your original service, make sure to verify the data in the service. You should also delete the new  service once the data is verified.
@@ -197,6 +198,7 @@ To prevent accidental deletion of data, please note that by default it is not po
 Should you wish to drop tables greater than this threshold you can use setting `max_table_size_to_drop` to do so:
 
 ```sql
-DROP TABLE IF EXISTS table_to_drop SYNC SETTINGS max_table_size_to_drop=2097152 -- increases the limit to 2TB
+DROP TABLE IF EXISTS table_to_drop 
+SYNC SETTINGS max_table_size_to_drop=2097152 -- increases the limit to 2TB
 ```
 :::

docs/en/cloud/manage/billing/index.md

@@ -7,9 +7,9 @@ keywords: [billing, payment thresholds, trouble shooting, marketplace]
 
 This section of the documentation covers topics related to billing, and contains the following pages:
 
-| Page                                  | Description                                                           |
-|---------------------------------------|-----------------------------------------------------------------------|
-| [Overview](/docs/en/cloud/marketplace/marketplace-billing)                       | Overview and FAQ page for marketplace billing.                        | 
+| Page                                  | Description                                                          |
+|---------------------------------------|----------------------------------------------------------------------|
+| [Overview](/docs/en/cloud/marketplace/marketplace-billing)                       | Overview and FAQ pages for marketplace billing.                      | 
 | [Payment Thresholds](/docs/en/cloud/billing/payment-thresholds)             | Learn more about how payment thresholds work and how to adjust them. |
-| [Troubleshooting Billing Issues](/docs/en/manage/troubleshooting-billing-issues) | Troubleshoot common billing issues.                                   |
-| [Marketplace](/docs/en/cloud/manage/)                    | Landing page for further marketplace related topics.                  |
+| [Troubleshooting Billing Issues](/docs/en/manage/troubleshooting-billing-issues) | Troubleshoot common billing issues.                                  |
+| [Marketplace](/docs/en/cloud/manage/)                    | Landing page for further marketplace related topics.                 |

docs/en/cloud/manage/billing/payment-thresholds.md

@@ -8,7 +8,11 @@ keywords: [billing, payment thresholds, automatic invoicing, invoice]
 
 # Payment Thresholds
 
-When your amount due in a billing period for ClickHouse Cloud reaches $10,000 USD or the equivalent value, your payment method will be automatically charged. A failed charge will result in the suspension or termination of your services after a grace period. This payment threshold does not apply to customers who have a committed spend contract or other negotiated contractual agreement with ClickHouse.
+When your amount due in a billing period for ClickHouse Cloud reaches $10,000 USD or the equivalent value, your payment method will be automatically charged. A failed charge will result in the suspension or termination of your services after a grace period. 
+
+:::note
+This payment threshold does not apply to customers who have a committed spend contract or other negotiated contractual agreement with ClickHouse.
+:::
 
 If your organization reaches 90% of the payment threshold and is on-track to exceed the payment threshold mid-period, the billing email associated with the organization will receive an email notification. You will also receive an email notification as well as an invoice when you exceed the payment threshold.
 

docs/en/cloud/manage/bring-your-own-bucket.md

@@ -55,6 +55,7 @@ You will need the following details to export/restore backups to your own CSP st
     ```
 2. Access HMAC key and HMAC secret.
 
+<hr/>
 # Backup / Restore
 
 ## Backup / Restore to AWS S3 Bucket
@@ -64,8 +65,8 @@ You will need the following details to export/restore backups to your own CSP st
 **Full Backup**
 
 ```sql
-BACKUP DATABASE test_backups TO 
-S3('https://testchbackups.s3.amazonaws.com/backups/<uuid>', '<key id>', '<key secret>')
+BACKUP DATABASE test_backups 
+TO S3('https://testchbackups.s3.amazonaws.com/backups/<uuid>', '<key id>', '<key secret>')
 ```
 
 Where `uuid` is a unique identifier, used to differentiate a set of backups.
@@ -100,7 +101,8 @@ See: [Configuring BACKUP/RESTORE to use an S3 Endpoint](/docs/en/operations/back
 **Full Backup**
 
 ```sql
-BACKUP DATABASE test_backups TO AzureBlobStorage('<AzureBlobStorage endpoint connection string>', '<container>', '<blob>/<uuid>');
+BACKUP DATABASE test_backups 
+TO AzureBlobStorage('<AzureBlobStorage endpoint connection string>', '<container>', '<blob>/<uuid>');
 ```
 
 Where `uuid` is a unique identifier, used to differentiate a set of backups.

docs/en/cloud/manage/scaling.md

@@ -20,9 +20,9 @@ Currently, ClickHouse Cloud supports vertical autoscaling and manual horizontal
 
 For Enterprise tier services scaling works as follows:
 
-- Horizontal scaling: Manual horizontal scaling will be available across all standard and custom profiles on the enterprise tier.  
-- Vertical scaling:
-  - Standard profiles(1:4) will support vertical autoscaling.
+- **Horizontal scaling**: Manual horizontal scaling will be available across all standard and custom profiles on the enterprise tier.  
+- **Vertical scaling**:
+  - Standard profiles (1:4) will support vertical autoscaling.
   - Custom profiles will not support vertical autoscaling or manual vertical scaling at launch. However, these services can be scaled vertically by contacting support.
 
 :::note
@@ -37,9 +37,9 @@ We are introducing a new vertical scaling mechanism for compute replicas, which
 
 Scale and Enterprise services support autoscaling based on CPU and memory usage. We constantly monitor the historical usage of a service over a lookback window (spanning the past 30 hours) to make scaling decisions. If the usage rises above or falls below certain thresholds, we scale the service appropriately to match the demand. 
 
-CPU-based autoscaling kicks in when CPU usage crosses an upper threshold in the range of 50-75% (actual threshold depends on the size of the cluster). At this point, CPU allocation to the cluster is doubled. If CPU usage falls below half of the upper threshold (for instance, 25% in case of 50% upper threshold), CPU allocation is halved.
+CPU-based autoscaling kicks in when CPU usage crosses an upper threshold in the range of 50-75% (actual threshold depends on the size of the cluster). At this point, CPU allocation to the cluster is doubled. If CPU usage falls below half of the upper threshold (for instance, to 25% in case of a 50% upper threshold), CPU allocation is halved.
 
-Memory-based auto scaling scales the cluster to 125% of the maximum memory usage, or up to 150% if OOMs (out of memory errors) are encountered.
+Memory-based auto-scaling scales the cluster to 125% of the maximum memory usage, or up to 150% if OOM (out of memory) errors are encountered.
 
 The **larger** of the CPU or memory recommendation is picked, and CPU and memory allocated to the service are scaled in lockstep increments of `1` CPU and `4 GiB` memory.
 
@@ -57,7 +57,9 @@ Single replica services cannot be scaled for all tiers.
 
 Set the **Maximum memory** for your replicas at a higher value than the **Minimum memory**. The service will then scale as needed within those bounds. These settings are also available during the initial service creation flow. Each replica in your service will be allocated the same memory and CPU resources.
 
-You can also choose to set these values the same, essentially "pinning" the service to a specific configuration. Doing so will immediately force scaling to happen to the desired size you picked. It's important to note that this will disable any auto scaling on the cluster, and your service will not be protected against increases in CPU or memory usage beyond these settings.
+You can also choose to set these values the same, essentially "pinning" the service to a specific configuration. Doing so will immediately force scaling to the desired size you picked. 
+
+It's important to note that this will disable any auto scaling on the cluster, and your service will not be protected against increases in CPU or memory usage beyond these settings.
 
 :::note
 For Enterprise tier services, standard 1:4 profiles will support vertical autoscaling. 
@@ -105,14 +107,14 @@ To scale a service horizontally from the UI, you can adjust the number of replic
 
 *Service scaling settings from the ClickHouse Cloud console*
 
-Once the service has scaled, the metrics dashboard in the cloud console should show the right allocation to the service. The screenshot below shows the cluster having scaled to total memory of `96 GiB`, which is `6` replicas, each with GiB memory allocation.
+Once the service has scaled, the metrics dashboard in the cloud console should show the correct allocation to the service. The screenshot below shows the cluster having scaled to total memory of `96 GiB`, which is `6` replicas, each with `16 GiB` memory allocation.
 
 <img alt="Scaling settings page"
     style={{width: '500px', marginLeft: 0}}
     src={require('./images/scaling-memory-allocation.png').default} />
 
 ## Automatic Idling
-In the **Settings** page, you can also choose whether or not to allow automatic idling of your service when it is inactive as shown in the image above (i.e. when the service is not executing any user-submitted queries).  Automatic idling reduces the cost for your service as you are not billed for compute resources when the service is paused.
+In the **Settings** page, you can also choose whether or not to allow automatic idling of your service when it is inactive as shown in the image above (i.e. when the service is not executing any user-submitted queries).  Automatic idling reduces the cost of your service, as you are not billed for compute resources when the service is paused.
 
 :::note
 In certain special cases, for instance when a service has a high number of parts, the service will not be idled automatically.

docs/en/cloud/manage/upgrades.md

@@ -8,7 +8,7 @@ import ScalePlanFeatureBadge from '@theme/badges/ScalePlanFeatureBadge'
 
 # Upgrades
 
-With ClickHouse Cloud you never have to worry about patching and upgrades. We roll out upgrades that include fixes, new features and performance improvements on a periodic basis. For the full list of what is new with ClickHouse refer to our [Cloud changelog](/docs/en/cloud/reference/changelog.md).
+With ClickHouse Cloud you never have to worry about patching and upgrades. We roll out upgrades that include fixes, new features and performance improvements on a periodic basis. For the full list of what is new in ClickHouse refer to our [Cloud changelog](/docs/en/cloud/reference/changelog.md).
 
 :::note	
 We are introducing a new upgrade mechanism, a concept we call "make before break" (or MBB). With this new approach, we add updated replica(s) before removing the old one(s) during the upgrade operation. This results in more seamless upgrades that are less disruptive to running workloads.	
@@ -18,7 +18,7 @@ We are introducing a new upgrade mechanism, a concept we call "make before break
 
 ## Version compatibility
 
-When you create a service, the [`compatibility` setting](/docs/en/operations/settings/settings#compatibility) is set to the most up-to-date ClickHouse version offered on ClickHouse Cloud at the time your service is initially provisioned. 
+When you create a service, the [`compatibility`](/docs/en/operations/settings/settings#compatibility) setting is set to the most up-to-date ClickHouse version offered on ClickHouse Cloud at the time your service is initially provisioned. 
 
 The `compatibility` setting allows you to use default values of settings from previous versions. When your service is upgraded to a new version, the version specified for the `compatibility` setting does not change. This means that default values for settings that existed when you first created your service will not change (unless you have already overridden those default values, in which case they will persist after the upgrade).