diff --git a/docs/src/main/paradox/bootstrap/istio.md b/docs/src/main/paradox/bootstrap/istio.md
index daad74d6..4ef28351 100644
--- a/docs/src/main/paradox/bootstrap/istio.md
+++ b/docs/src/main/paradox/bootstrap/istio.md
@@ -1,6 +1,6 @@
 # Istio
 
-[Istio](https://istio.io/) is a service mesh that handles many of the concerns of service to service communication for you, such as routing, load balancing, authentication, authorization, and observability. In certain use cases, it can complement an Pekko cluster well. Typically, Pekko cluster communication is used for multiple nodes of the same service to communicate with each other, to achieve things such as sharding, replication and peer to peer communication, while a service mesh might be used for nodes of different services to communicate with each other, through REST and gRPC APIs.
+[Istio](https://istio.io/) is a service mesh that handles many of the concerns of service to service communication for you, such as routing, load balancing, authentication, authorization, and observability. In certain use cases, it can complement a Pekko cluster well. Typically, Pekko cluster communication is used for multiple nodes of the same service to communicate with each other, to achieve things such as sharding, replication and peer to peer communication, while a service mesh might be used for nodes of different services to communicate with each other, through REST and gRPC APIs.
 
 To bootstrap a Pekko cluster in Istio, Istio must be configured to allow Pekko cluster communication to bypass the Istio sidecar proxy. Istio's routing design is made such that services don't need to be aware of each others location, they just communicate with the proxy, and the mesh figures out how to route and secure the communication. However, Pekko cluster communication is fundamentally location aware, in order to, for example, route messages to sharded actors. Hence a service mesh is not a suitable communication medium for cluster traffic, so it needs to be bypassed.
 
@@ -32,7 +32,7 @@ If you offer any other services on other ports, they can be added as a comma sep
 
 ## Example
 
-Here is an example deployment spec for an Pekko cluster deployed to Istio, which uses the explicit include inbound ports annotation to ensure that incoming remoting and management traffic isn't redirected through the proxy:
+Here is an example deployment spec for a Pekko cluster deployed to Istio, which uses the explicit include inbound ports annotation to ensure that incoming remoting and management traffic isn't redirected through the proxy:
 
 ```yaml
 apiVersion: apps/v1
diff --git a/docs/src/main/paradox/bootstrap/recipes.md b/docs/src/main/paradox/bootstrap/recipes.md
index 262a08aa..cf8f313b 100644
--- a/docs/src/main/paradox/bootstrap/recipes.md
+++ b/docs/src/main/paradox/bootstrap/recipes.md
@@ -108,7 +108,7 @@ does not support `publishNotReadyAddresses` yet then use the `kubernetes-api` di
 
 ### Running in Istio
 
-For considerations and configuration necessary for bootstrapping a Pekko cluster in Istio, see @ref[Bootstrapping an Pekko cluster in Istio](istio.md).
+For considerations and configuration necessary for bootstrapping a Pekko cluster in Istio, see @ref[Bootstrapping a Pekko cluster in Istio](istio.md).
 
 ### Running the Kubernetes demos
 
diff --git a/docs/src/main/paradox/healthchecks.md b/docs/src/main/paradox/healthchecks.md
index 5e5f1172..64010bdf 100644
--- a/docs/src/main/paradox/healthchecks.md
+++ b/docs/src/main/paradox/healthchecks.md
@@ -53,7 +53,7 @@ Application specific health checks can be added a `name = <fully qualified class
 
 @@snip [reference.conf](/management-cluster-http/src/main/resources/reference.conf)  { #health }
 
-## Hosting health checks as an Pekko Management Route
+## Hosting health checks as a Pekko Management Route
 
 Health checks can be hosted via the Pekko management HTTP server. The `pekko.management.HealthCheckRoutes` is enabled
 by default as a Pekko management route provider.
diff --git a/docs/src/main/paradox/kubernetes-deployment/forming-a-cluster.md b/docs/src/main/paradox/kubernetes-deployment/forming-a-cluster.md
index c3f499ab..afeba824 100644
--- a/docs/src/main/paradox/kubernetes-deployment/forming-a-cluster.md
+++ b/docs/src/main/paradox/kubernetes-deployment/forming-a-cluster.md
@@ -1,4 +1,4 @@
-# Forming an Pekko Cluster
+# Forming a Pekko Cluster
 
 Services that use Pekko Cluster have additional requirements over stateless applications.
 To form a cluster, each pod needs to know which other pods have been deployed as part of that service, 
@@ -106,7 +106,7 @@ Java
 ## Role-Based Access Control
 
 By default, pods are unable to use the Kubernetes API because they are not authenticated to do so. 
-In order to allow the applications pods to form an Pekko Cluster using the Kubernetes API, we need to define some Role-Based Access Control (RBAC) roles and bindings.
+In order to allow the applications pods to form a Pekko Cluster using the Kubernetes API, we need to define some Role-Based Access Control (RBAC) roles and bindings.
 
 RBAC allows the configuration of access control using two key concepts, roles, and role bindings. A role is a set of permissions to access something 
 in the Kubernetes API. For example, a `pod-reader` role may have permission to perform the `list`, `get` and `watch` operations on the `pods` resource in a particular namespace, by default the same namespace that the role is configured in. In fact, that's exactly what we are going to configure, as this is the permission that our pods need. Here's the spec for the `pod-reader` role to be added in `kubernetes/pekko-cluster.yaml`: