diff --git a/docs/en/operations/settings/settings.md b/docs/en/operations/settings/settings.md
index cbb1e02c44ba6eb25f490b88bbdc7dbe839fca7b..fce10da8f9b26512ce27faebbe78ecd0bb9debdc 100644
--- a/docs/en/operations/settings/settings.md
+++ b/docs/en/operations/settings/settings.md
@@ -894,4 +894,19 @@ Error count of each replica is capped at this value, preventing a single replica
 - [Table engine Distributed](../../operations/table_engines/distributed.md)
 - [`distributed_replica_error_half_life`](#settings-distributed_replica_error_half_life)
 
+## os_thread_priority {#setting-os_thread_priority}
+
+Sets the priority ([nice](https://en.wikipedia.org/wiki/Nice_(Unix))) for threads that execute queries. OS scheduler considers this priority when choosing the next thread to run on each available CPU core.
+
+!!! warning "Warning"
+    To use this setting, you need to set the `CAP_SYS_NICE` capability. The `clickhouse-server` package sets it up during installation. Some virtual environments don't allow to set the `CAP_SYS_NICE` capability. In this case `clickhouse-server` shows a message about it at the start.
+
+Possible values:
+
+You can set values in the `[-20, 19]` range.
+
+The lower value means a higher priority. Threads with low values of `nice` priority are executed more frequently than threads with high values. High values are preferable for long running non-interactive queries because it allows them to quickly give up resources in favour of short interactive queries when they arrive.
+
+Default value: 0.
+
 [Original article](https://clickhouse.yandex/docs/en/operations/settings/settings/) <!-- hide -->
diff --git a/docs/en/operations/system_tables.md b/docs/en/operations/system_tables.md
index 0b6481de3c1ff6d0aea48531ae6b60e72676716b..85c6f755f87c328111838f913aa7026542fb138d 100644
--- a/docs/en/operations/system_tables.md
+++ b/docs/en/operations/system_tables.md
@@ -62,7 +62,7 @@ Columns:
 
 Please note that `errors_count` is updated once per query to the cluster, but `estimated_recovery_time` is recalculated on-demand. So there could be a case of non-zero `errors_count` and zero `estimated_recovery_time`, that next query will zero `errors_count` and try to use replica as if it has no errors.
 
-** See also **
+**See also**
 
 - [Table engine Distributed](table_engines/distributed.md)
 - [distributed_replica_error_cap setting](settings/settings.md#settings-distributed_replica_error_cap)