diff --git a/pages/clustering/high-availability/best-practices.mdx b/pages/clustering/high-availability/best-practices.mdx
index 6ea252f75..a6cf6d67a 100644
--- a/pages/clustering/high-availability/best-practices.mdx
+++ b/pages/clustering/high-availability/best-practices.mdx
@@ -279,6 +279,20 @@ The configuration value can be controlled using the query:
 SET COORDINATOR SETTING 'max_replica_read_lag' TO '10' ;
 ```
 
+### `deltas_batch_progress_size`
+
+Users can control how often replicas report back to main that they're stil processing the data (transactions, WALs, snapshots)
+the main has sent to them. The default value is 100'000 which should be enough for the big part of your transactions.
+However, if processing 100'000 deltas take more than 30s (because you're dealing with large deltas or you have older CPUs)
+, you can set the configuration value `deltas_batch_progress_size` to a smaller value. This will avoid timeouts on replicas social
+you won't see query exception "At least one SYNC replica has not committed" but at the cost of a lower throughput since replica
+will sending more often in-progress messages to the main.
+
+```
+SET COORDINATOR SETTING 'deltas_batch_progress_size' TO '50000' ;
+```
+
+
 ## Observability
 
 Monitoring cluster health is essential. Key metrics include: