diff --git a/br/br-compact-log-backup.md b/br/br-compact-log-backup.md
index 9c969f1148e52..02578015aa2af 100644
--- a/br/br-compact-log-backup.md
+++ b/br/br-compact-log-backup.md
@@ -49,11 +49,11 @@ br operator base64ify --storage "s3://your/log/backup/storage/here" --load-creds
 > **Note:**
 >
 > - If the `--load-creds` option is included when you execute the preceding command, the encoded Base64 string contains credential information loaded from the current BR environment. Note to ensure proper security and access control.
-> - The `--storage` value matches the storage output from the `log status` command of the log backup task.
+> - The `--storage` value should match the output from the `log status` command of the log backup task.
 
 #### Step 2: Execute log compaction
 
-With the Base64-encoded storage, you can initiate the compaction using `tikv-ctl`. Note that the default log level of `tikv-ctl` is `warning`. Use `--log-level info` to obtain more detailed information:
+Once you have the Base64-encoded string from the previous step, you can start compaction using `tikv-ctl`. By default, the log level of `tikv-ctl` is `warning`. Use `--log-level info` to get more detailed information:
 
 ```shell
 tikv-ctl --log-level info compact-log-backup \
@@ -63,7 +63,7 @@ tikv-ctl --log-level info compact-log-backup \
 
 Parameter descriptions:
 
-- `-s`: the Base64-encoded storage string obtained earlier.
+- `-s`: the Base64-encoded string obtained in the previous step.
 - `-N`: the maximum number of concurrent log compaction tasks.
 - `--from`: the start timestamp for compaction.
 - `--until`: the end timestamp for compaction.
diff --git a/tidb-cloud/built-in-monitoring.md b/tidb-cloud/built-in-monitoring.md
index b24b2d5bd8ae9..c918879ee17a9 100644
--- a/tidb-cloud/built-in-monitoring.md
+++ b/tidb-cloud/built-in-monitoring.md
@@ -107,7 +107,7 @@ The following table illustrates the instance-level main metrics under the **Inst
 | :------------| :------| :-------------------------------------------- |
 | Request Units | RU per second | The Request Unit (RU) is a unit of measurement used to track the resource consumption of a query or transaction in a {{{ .starter }}} instance. Besides user queries, background activities can also consume RUs, so when QPS is 0, RU usage per second might still be nonzero.|
 | Capacity vs Usage (RU/s) | Provisioned capacity (RCU), Consumed RU/s | The Request Capacity Units (RCUs) and the consumed Request Units (RU) per second in a {{{ .essential }}} instance. |
-| Used Storage Size | Row-based storage, Row-based standard storage, Columnar storage | The size of row-based storage, row-based standard storage, and columnar storage. This metric is displayed only when the size of each storage type is 50 MiB or larger. Currently, **Row-based standard storage** has the same meaning as **Row-based storage**. |
+| Used Storage Size | Row-based storage, Row-based standard storage, Columnar storage | The size of row-based storage, row-based standard storage, and columnar storage. TiDB Cloud displays this metric only when the size of each storage type is 50 MiB or larger. **Row-based standard storage** has the same meaning as **Row-based storage**. |
 | Query Per Second | All, {SQL type} | The number of SQL statements executed per second, which are collected by SQL types, such as `SELECT`, `INSERT`, and `UPDATE`. |
 | Query Duration | Avg, P99, P99-{SQL type} | The duration from receiving a request from the client to the {{{ .starter }}} or {{{ .essential }}} instance until the instance executes the request and returns the result to the client. |
 | Failed Query | All | The number of SQL statement execution errors per second. |