diff --git a/docs/modules/trino/pages/usage-guide/operations/pod-disruptions.adoc b/docs/modules/trino/pages/usage-guide/operations/pod-disruptions.adoc
index 5e16c489..4de2daa6 100644
--- a/docs/modules/trino/pages/usage-guide/operations/pod-disruptions.adoc
+++ b/docs/modules/trino/pages/usage-guide/operations/pod-disruptions.adoc
@@ -1,16 +1,16 @@
 = Allowed Pod disruptions
 
-You can configure the allowed Pod disruptions for Trino nodes as described in xref:concepts:operations/pod_disruptions.adoc[].
+You can configure the permitted Pod disruptions for Trino nodes as described in xref:concepts:operations/pod_disruptions.adoc[].
 
-Unless you configure something else or disable our PodDisruptionBudgets (PDBs), we write the following PDBs:
+Unless you configure something else or disable the provided PodDisruptionBudgets (PDBs), the following PDBs are written:
 
 == Coordinators
-We only allow a single coordinator to be offline at any given time, regardless of the number of replicas or `roleGroups`.
+The provided PDBs only allow a single coordinator to be offline at any given time, regardless of the number of replicas or `roleGroups`.
 
 == Workers
 Normally users deploy multiple workers to speed up queries, handle multiple queries in parallel or to just have enough memory available in the Cluster to execute a big query.
 
-Taking this into consideration, our operator uses the following algorithm to determine the maximum number of workers allowed to be unavailable at the same time:
+Taking this into consideration, the operator uses the following algorithm to determine the maximum number of workers allowed to be unavailable at the same time:
 
 `num_workers` is the number of workers in the Trino cluster, summed over all `roleGroups`.
 
@@ -47,7 +47,7 @@ This results e.g. in the following numbers:
 |===
 
 == Reduce rolling redeployment durations
-The default PDBs we write out are pessimistic and will cause the rolling redeployment to take a considerable amount of time.
+The default PDBs of the operator are pessimistic and will cause the rolling redeployment to take a considerable amount of time.
 As an example, in a cluster with 100 workers, 10 workers are restarted at the same time. Assuming a worker takes 5 minutes to properly restart, the whole redeployment will take (100 nodes / 10 nodes simultaneous * 5 minutest = ) 50 minutes.
 
 You can use the following measures to speed this up:
@@ -55,4 +55,4 @@ You can use the following measures to speed this up:
 1. Increase `maxUnavailable` using the `spec.workers.roleConfig.podDisruptionBudget.maxUnavailable` field as described in xref:concepts:operations/pod_disruptions.adoc[].
 2. Write your own PDBs as described in xref:concepts:operations/pod_disruptions.adoc#_using_you_own_custom_pdbs[Using you own custom PDBs].
 
-WARNING: In cases you modify or disable the default PDBs, it's your responsibility to either make sure there are enough DataNodes available or accept the risk of blocks not being available!
+WARNING: In case you modify or disable the default PDBs, it is your responsibility to make sure there are enough workers available to manage the existing workload and performance requirements!