diff --git a/README.md b/README.md
index c86778755..50cbce1bd 100644
--- a/README.md
+++ b/README.md
@@ -314,16 +314,19 @@ Some capacity planning tips for VictoriaMetrics cluster:
 
 ## High availability
 
+The database is considered highly available if it continues accepting new data and processing incoming queries when some of its components are temporarily unavailable.
+VictoriaMetrics cluster is highly available according to this definition - see [cluster availability docs](#cluster-availability).
+
 It is recommended to run all the components for a single cluster in the same subnetwork with high bandwidth, low latency and low error rates.
-This improves cluster performance and availability.
-It isn't recommended spreading components for a single cluster across multiple availability zones, since cross-AZ network usually has lower bandwidth, higher latency
-and higher error rates comparing the network inside AZ.
+This improves cluster performance and availability. It isn't recommended spreading components for a single cluster
+across multiple availability zones, since cross-AZ network usually has lower bandwidth, higher latency and higher
+error rates comparing the network inside a single AZ.
 
 If you need multi-AZ setup, then it is recommended running independed clusters in each AZ and setting up
 [vmagent](https://docs.victoriametrics.com/vmagent.html) in front of these clusters, so it could replicate incoming data
-into all the cluster. Then [promxy](https://github.com/jacksontj/promxy) could be used for querying the data from multiple clusters.
+into all the cluster - see [these docs](https://docs.victoriametrics.com/vmagent.html#multitenancy) for details.
+Then [promxy](https://github.com/jacksontj/promxy) could be used for querying the data from multiple clusters.
 
-Another solution is to use [multi-level cluster setup](#multi-level-cluster-setup).
 
 ## Multi-level cluster setup
 
diff --git a/docs/Cluster-VictoriaMetrics.md b/docs/Cluster-VictoriaMetrics.md
index 581cce9f6..6782e4597 100644
--- a/docs/Cluster-VictoriaMetrics.md
+++ b/docs/Cluster-VictoriaMetrics.md
@@ -318,16 +318,19 @@ Some capacity planning tips for VictoriaMetrics cluster:
 
 ## High availability
 
+The database is considered highly available if it continues accepting new data and processing incoming queries when some of its components are temporarily unavailable.
+VictoriaMetrics cluster is highly available according to this definition - see [cluster availability docs](#cluster-availability).
+
 It is recommended to run all the components for a single cluster in the same subnetwork with high bandwidth, low latency and low error rates.
-This improves cluster performance and availability.
-It isn't recommended spreading components for a single cluster across multiple availability zones, since cross-AZ network usually has lower bandwidth, higher latency
-and higher error rates comparing the network inside AZ.
+This improves cluster performance and availability. It isn't recommended spreading components for a single cluster
+across multiple availability zones, since cross-AZ network usually has lower bandwidth, higher latency and higher
+error rates comparing the network inside a single AZ.
 
 If you need multi-AZ setup, then it is recommended running independed clusters in each AZ and setting up
 [vmagent](https://docs.victoriametrics.com/vmagent.html) in front of these clusters, so it could replicate incoming data
-into all the cluster. Then [promxy](https://github.com/jacksontj/promxy) could be used for querying the data from multiple clusters.
+into all the cluster - see [these docs](https://docs.victoriametrics.com/vmagent.html#multitenancy) for details.
+Then [promxy](https://github.com/jacksontj/promxy) could be used for querying the data from multiple clusters.
 
-Another solution is to use [multi-level cluster setup](#multi-level-cluster-setup).
 
 ## Multi-level cluster setup