From 9a223470ae24688f6479e9f534eb631dfd13825a Mon Sep 17 00:00:00 2001
From: joedrf <joe@buoyant.io>
Date: Sun, 26 Jul 2026 17:24:31 +0100
Subject: [PATCH 1/3] fix(docs): correct spelling and duplicated words in
 reference docs

- Conncections -> Connections
- unavailble -> unavailable
- minumum -> minimum
- crytpographic -> cryptographic
- duplicated 'which which'
- decribes -> describes
- precendence -> precedence
- 'authenticate thes' -> 'authenticates the'

Applied across all versioned docs directories (2-edge, docs, 2.10-2.19),
following the convention in linkerd/website#1961 and #2137.

Signed-off-by: joedrf <joe@buoyant.io>
---
 linkerd.io/content/2-edge/reference/architecture.md         | 2 +-
 linkerd.io/content/2-edge/reference/authorization-policy.md | 6 +++---
 linkerd.io/content/2-edge/reference/circuit-breaking.md     | 6 +++---
 linkerd.io/content/2-edge/reference/proxy-metrics.md        | 4 ++--
 linkerd.io/content/2.12/reference/authorization-policy.md   | 6 +++---
 linkerd.io/content/2.13/reference/authorization-policy.md   | 6 +++---
 linkerd.io/content/2.13/reference/circuit-breaking.md       | 6 +++---
 linkerd.io/content/2.13/reference/proxy-metrics.md          | 2 +-
 linkerd.io/content/2.14/reference/authorization-policy.md   | 6 +++---
 linkerd.io/content/2.14/reference/circuit-breaking.md       | 6 +++---
 linkerd.io/content/2.14/reference/proxy-metrics.md          | 2 +-
 linkerd.io/content/2.15/reference/authorization-policy.md   | 6 +++---
 linkerd.io/content/2.15/reference/circuit-breaking.md       | 6 +++---
 linkerd.io/content/2.15/reference/proxy-metrics.md          | 2 +-
 linkerd.io/content/2.16/reference/architecture.md           | 2 +-
 linkerd.io/content/2.16/reference/authorization-policy.md   | 6 +++---
 linkerd.io/content/2.16/reference/circuit-breaking.md       | 6 +++---
 linkerd.io/content/2.16/reference/proxy-metrics.md          | 2 +-
 linkerd.io/content/2.17/reference/architecture.md           | 2 +-
 linkerd.io/content/2.17/reference/authorization-policy.md   | 6 +++---
 linkerd.io/content/2.17/reference/circuit-breaking.md       | 6 +++---
 linkerd.io/content/2.17/reference/proxy-metrics.md          | 2 +-
 linkerd.io/content/2.18/reference/architecture.md           | 2 +-
 linkerd.io/content/2.18/reference/authorization-policy.md   | 6 +++---
 linkerd.io/content/2.18/reference/circuit-breaking.md       | 6 +++---
 linkerd.io/content/2.18/reference/proxy-metrics.md          | 2 +-
 linkerd.io/content/2.19/reference/architecture.md           | 2 +-
 linkerd.io/content/2.19/reference/authorization-policy.md   | 6 +++---
 linkerd.io/content/2.19/reference/circuit-breaking.md       | 6 +++---
 linkerd.io/content/2.19/reference/proxy-metrics.md          | 4 ++--
 linkerd.io/content/docs/reference/architecture.md           | 2 +-
 linkerd.io/content/docs/reference/authorization-policy.md   | 6 +++---
 linkerd.io/content/docs/reference/circuit-breaking.md       | 6 +++---
 linkerd.io/content/docs/reference/proxy-metrics.md          | 4 ++--
 34 files changed, 75 insertions(+), 75 deletions(-)

diff --git a/linkerd.io/content/2-edge/reference/architecture.md b/linkerd.io/content/2-edge/reference/architecture.md
index 3b4fab06a8..8ee6942c28 100644
--- a/linkerd.io/content/2-edge/reference/architecture.md
+++ b/linkerd.io/content/2-edge/reference/architecture.md
@@ -93,7 +93,7 @@ You can read more about these micro-proxies here:
 - [Why Linkerd doesn't use Envoy](/2020/12/03/why-linkerd-doesnt-use-envoy/)
 - [Under the hood of Linkerd's state-of-the-art Rust proxy, Linkerd2-proxy](/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/)
 
-### Meshed Conncections
+### Meshed Connections
 
 When one pod establishes a TCP connection to another pod and both of those pods
 are injected with the Linkerd proxy, we say that the connection is _meshed_. The
diff --git a/linkerd.io/content/2-edge/reference/authorization-policy.md b/linkerd.io/content/2-edge/reference/authorization-policy.md
index 19cce7123b..ed9eebd254 100644
--- a/linkerd.io/content/2-edge/reference/authorization-policy.md
+++ b/linkerd.io/content/2-edge/reference/authorization-policy.md
@@ -47,7 +47,7 @@ The general pattern for authorization is:
 - A `Server` describes a set of pods, and a single port on those pods.
 - Optionally, an `HTTPRoute` references that `Server` and describes a subset of
   HTTP traffic to it.
-- A `MeshTLSAuthentication` or `NetworkAuthentication` decribes who is allowed
+- A `MeshTLSAuthentication` or `NetworkAuthentication` describes who is allowed
   access.
 - An `AuthorizationPolicy` references the `HTTPRoute` or `Server` (the thing to
   be authorized) and the `MeshTLSAuthentication` or `NetworkAuthentication` (the
@@ -169,7 +169,7 @@ lifecycle.
 
 A given HTTP request can only match one HTTPRoute. If multiple HTTPRoutes are
 present that match a request, one will be picked according to the
-[Gateway API rules of precendence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+[Gateway API rules of precedence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
 
 {{< /note >}}
 
@@ -333,7 +333,7 @@ spec:
     - "webapp.booksapp.serviceaccount.identity.linkerd.cluster.local"
 ```
 
-A `MeshTLSAuthentication` which authenticate thes `books` and `webapp` mesh
+A `MeshTLSAuthentication` which authenticates the `books` and `webapp` mesh
 identities. This is an alternative way to specify the same thing as the above
 example.
 
diff --git a/linkerd.io/content/2-edge/reference/circuit-breaking.md b/linkerd.io/content/2-edge/reference/circuit-breaking.md
index 66b1463aa6..c3f551254b 100644
--- a/linkerd.io/content/2-edge/reference/circuit-breaking.md
+++ b/linkerd.io/content/2-edge/reference/circuit-breaking.md
@@ -85,7 +85,7 @@ accrual, see [Rate Limit Aware Load Balancing](../tasks/rate-limit-aware-load-ba
 
 ## Probation and Backoffs
 
-Once a failure accrual policy makes an endpoint unavailble, the circuit breaker
+Once a failure accrual policy makes an endpoint unavailable, the circuit breaker
 will attempt to determine whether the endpoint is still in a failing state, and
 transition it back to available if it has recovered. This process is called
 _probation_. When an endpoint enters probation, it is temporarily made available
@@ -106,7 +106,7 @@ application traffic must succeed for the endpoint to become available again.
 {{< /note >}}
 
 When an endpoint's failure accrual policy trips the circuit breaker, it will
-remain unavailble for at least a _minimum penalty_ duration. After this duration
+remain unavailable for at least a _minimum penalty_ duration. After this duration
 has elapsed, the endpoint will enter probation. When a probe request fails, the
 endpoint will not be placed in probation again until a backoff duration has
 elapsed. Every time a probe request fails, [the backoff increases
@@ -160,7 +160,7 @@ configure parameters for the consecutive-failures failure accrual policy:
   unavailable. Must be an integer. If this annotation is not present, the
   default value is 7.
 - `balancer.linkerd.io/failure-accrual-consecutive-min-penalty`: Sets the
-  minumum penalty duration for which an endpoint will be marked as unavailable
+  minimum penalty duration for which an endpoint will be marked as unavailable
   after `max-failures` consecutive failures occur. After this period of time
   elapses, the endpoint will be [probed](#probation-and-backoffs). This duration
   must be non-zero, and may not be greater than the max-penalty duration. If
diff --git a/linkerd.io/content/2-edge/reference/proxy-metrics.md b/linkerd.io/content/2-edge/reference/proxy-metrics.md
index 2cae1aa634..63907d169d 100644
--- a/linkerd.io/content/2-edge/reference/proxy-metrics.md
+++ b/linkerd.io/content/2-edge/reference/proxy-metrics.md
@@ -20,7 +20,7 @@ port (default: `:4191`) in the [Prometheus format][prom-format].
   - `tls_kx_groups`: The set of key exchange algorithms the proxy will use,
     sorted by preference order.
   - `tls_rand`: The secure randomness provider
-  - `tls_key_provider`: The crytpographic key provider
+  - `tls_key_provider`: The cryptographic key provider
   - `tls_fips`: A boolean denoting if the proxy's connections are
     FIPS-compliant.
 - `tokio_rt_*`: A set of counters and gauges with stats on the proxy's
@@ -350,7 +350,7 @@ Kubernetes resources to which traffic is routed by the proxy:
   route resource through which the proxy discovered the route binding. This will
   either reference an [HTTPRoute] resource or a default (synthesized) route.
 - `backend_group`, `backend_kind`, `backend_name`, and `backend_namespace`
-  reference the backend resource to which which the proxy routed the request.
+  reference the backend resource to which the proxy routed the request.
   This will always be a Service.
 
 In addition, the `outbound_http_balancer_endpoints` gauge metric adds the
diff --git a/linkerd.io/content/2.12/reference/authorization-policy.md b/linkerd.io/content/2.12/reference/authorization-policy.md
index a66c7af988..393b97359c 100644
--- a/linkerd.io/content/2.12/reference/authorization-policy.md
+++ b/linkerd.io/content/2.12/reference/authorization-policy.md
@@ -45,7 +45,7 @@ The general pattern for authorization is:
 - A `Server` describes a set of pods, and a single port on those pods.
 - Optionally, an `HTTPRoute` references that `Server` and describes a subset of
   HTTP traffic to it.
-- A `MeshTLSAuthentication` or `NetworkAuthentication` decribes who is allowed
+- A `MeshTLSAuthentication` or `NetworkAuthentication` describes who is allowed
   access.
 - An `AuthorizationPolicy` references the `HTTPRoute` or `Server` (the thing to
   be authorized) and the `MeshTLSAuthentication` or `NetworkAuthentication` (the
@@ -155,7 +155,7 @@ completed during the request or response lifecycle.
 
 A given HTTP request can only match one HTTPRoute. If multiple HTTPRoutes are
 present that match a request, one will be picked according to the
-[Gateway API rules of precendence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+[Gateway API rules of precedence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
 
 {{< /note >}}
 
@@ -502,7 +502,7 @@ spec:
     - "webapp.booksapp.serviceaccount.identity.linkerd.cluster.local"
 ```
 
-A `MeshTLSAuthentication` which authenticate thes `books` and `webapp` mesh
+A `MeshTLSAuthentication` which authenticates the `books` and `webapp` mesh
 identities. This is an alternative way to specify the same thing as the above
 example.
 
diff --git a/linkerd.io/content/2.13/reference/authorization-policy.md b/linkerd.io/content/2.13/reference/authorization-policy.md
index b1a31b4fec..5c21b41fd8 100644
--- a/linkerd.io/content/2.13/reference/authorization-policy.md
+++ b/linkerd.io/content/2.13/reference/authorization-policy.md
@@ -45,7 +45,7 @@ The general pattern for authorization is:
 - A `Server` describes a set of pods, and a single port on those pods.
 - Optionally, an `HTTPRoute` references that `Server` and describes a subset of
   HTTP traffic to it.
-- A `MeshTLSAuthentication` or `NetworkAuthentication` decribes who is allowed
+- A `MeshTLSAuthentication` or `NetworkAuthentication` describes who is allowed
   access.
 - An `AuthorizationPolicy` references the `HTTPRoute` or `Server` (the thing to
   be authorized) and the `MeshTLSAuthentication` or `NetworkAuthentication` (the
@@ -156,7 +156,7 @@ lifecycle.
 
 A given HTTP request can only match one HTTPRoute. If multiple HTTPRoutes are
 present that match a request, one will be picked according to the
-[Gateway API rules of precendence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+[Gateway API rules of precedence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
 
 {{< /note >}}
 
@@ -303,7 +303,7 @@ spec:
     - "webapp.booksapp.serviceaccount.identity.linkerd.cluster.local"
 ```
 
-A `MeshTLSAuthentication` which authenticate thes `books` and `webapp` mesh
+A `MeshTLSAuthentication` which authenticates the `books` and `webapp` mesh
 identities. This is an alternative way to specify the same thing as the above
 example.
 
diff --git a/linkerd.io/content/2.13/reference/circuit-breaking.md b/linkerd.io/content/2.13/reference/circuit-breaking.md
index 5d346904ee..0f2c5a0c1a 100644
--- a/linkerd.io/content/2.13/reference/circuit-breaking.md
+++ b/linkerd.io/content/2.13/reference/circuit-breaking.md
@@ -58,7 +58,7 @@ made unavailable once 7 failures occur in a row with no successes.
 
 ## Probation and Backoffs
 
-Once a failure accrual policy makes an endpoint unavailble, the circuit breaker
+Once a failure accrual policy makes an endpoint unavailable, the circuit breaker
 will attempt to determine whether the endpoint is still in a failing state, and
 transition it back to available if it has recovered. This process is called
 _probation_. When an endpoint enters probation, it is temporarily made available
@@ -79,7 +79,7 @@ application traffic must succeed for the endpoint to become available again.
 {{< /note >}}
 
 When an endpoint's failure accrual policy trips the circuit breaker, it will
-remain unavailble for at least a _minimum penalty_ duration. After this duration
+remain unavailable for at least a _minimum penalty_ duration. After this duration
 has elapsed, the endpoint will enter probation. When a probe request fails, the
 endpoint will not be placed in probation again until a backoff duration has
 elapsed. Every time a probe request fails, [the backoff increases
@@ -134,7 +134,7 @@ configure parameters for the consecutive-failures failure accrual policy:
   unavailable. Must be an integer. If this annotation is not present, the
   default value is 7.
 - `balancer.linkerd.io/failure-accrual-consecutive-min-penalty`: Sets the
-  minumum penalty duration for which an endpoint will be marked as unavailable
+  minimum penalty duration for which an endpoint will be marked as unavailable
   after `max-failures` consecutive failures occur. After this period of time
   elapses, the endpoint will be [probed](#probation-and-backoffs). This duration
   must be non-zero, and may not be greater than the max-penalty duration. If
diff --git a/linkerd.io/content/2.13/reference/proxy-metrics.md b/linkerd.io/content/2.13/reference/proxy-metrics.md
index 2e6c6beee3..b155c78099 100644
--- a/linkerd.io/content/2.13/reference/proxy-metrics.md
+++ b/linkerd.io/content/2.13/reference/proxy-metrics.md
@@ -252,7 +252,7 @@ Kubernetes resources to which traffic is routed by the proxy:
   route resource through which the proxy discovered the route binding. This will
   either reference an HTTPRoute resource or a default (synthesized) route.
 - `backend_group`, `backend_kind`, `backend_name`, and `backend_namespace`
-  reference the backend resource to which which the proxy routed the request.
+  reference the backend resource to which the proxy routed the request.
   This will always be a Service.
 
 In addition, the `outbound_http_balancer_endpoints` gauge metric adds the
diff --git a/linkerd.io/content/2.14/reference/authorization-policy.md b/linkerd.io/content/2.14/reference/authorization-policy.md
index b57c8f1b71..301146f420 100644
--- a/linkerd.io/content/2.14/reference/authorization-policy.md
+++ b/linkerd.io/content/2.14/reference/authorization-policy.md
@@ -45,7 +45,7 @@ The general pattern for authorization is:
 - A `Server` describes a set of pods, and a single port on those pods.
 - Optionally, an `HTTPRoute` references that `Server` and describes a subset of
   HTTP traffic to it.
-- A `MeshTLSAuthentication` or `NetworkAuthentication` decribes who is allowed
+- A `MeshTLSAuthentication` or `NetworkAuthentication` describes who is allowed
   access.
 - An `AuthorizationPolicy` references the `HTTPRoute` or `Server` (the thing to
   be authorized) and the `MeshTLSAuthentication` or `NetworkAuthentication` (the
@@ -156,7 +156,7 @@ lifecycle.
 
 A given HTTP request can only match one HTTPRoute. If multiple HTTPRoutes are
 present that match a request, one will be picked according to the
-[Gateway API rules of precendence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+[Gateway API rules of precedence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
 
 {{< /note >}}
 
@@ -320,7 +320,7 @@ spec:
     - "webapp.booksapp.serviceaccount.identity.linkerd.cluster.local"
 ```
 
-A `MeshTLSAuthentication` which authenticate thes `books` and `webapp` mesh
+A `MeshTLSAuthentication` which authenticates the `books` and `webapp` mesh
 identities. This is an alternative way to specify the same thing as the above
 example.
 
diff --git a/linkerd.io/content/2.14/reference/circuit-breaking.md b/linkerd.io/content/2.14/reference/circuit-breaking.md
index 5d346904ee..0f2c5a0c1a 100644
--- a/linkerd.io/content/2.14/reference/circuit-breaking.md
+++ b/linkerd.io/content/2.14/reference/circuit-breaking.md
@@ -58,7 +58,7 @@ made unavailable once 7 failures occur in a row with no successes.
 
 ## Probation and Backoffs
 
-Once a failure accrual policy makes an endpoint unavailble, the circuit breaker
+Once a failure accrual policy makes an endpoint unavailable, the circuit breaker
 will attempt to determine whether the endpoint is still in a failing state, and
 transition it back to available if it has recovered. This process is called
 _probation_. When an endpoint enters probation, it is temporarily made available
@@ -79,7 +79,7 @@ application traffic must succeed for the endpoint to become available again.
 {{< /note >}}
 
 When an endpoint's failure accrual policy trips the circuit breaker, it will
-remain unavailble for at least a _minimum penalty_ duration. After this duration
+remain unavailable for at least a _minimum penalty_ duration. After this duration
 has elapsed, the endpoint will enter probation. When a probe request fails, the
 endpoint will not be placed in probation again until a backoff duration has
 elapsed. Every time a probe request fails, [the backoff increases
@@ -134,7 +134,7 @@ configure parameters for the consecutive-failures failure accrual policy:
   unavailable. Must be an integer. If this annotation is not present, the
   default value is 7.
 - `balancer.linkerd.io/failure-accrual-consecutive-min-penalty`: Sets the
-  minumum penalty duration for which an endpoint will be marked as unavailable
+  minimum penalty duration for which an endpoint will be marked as unavailable
   after `max-failures` consecutive failures occur. After this period of time
   elapses, the endpoint will be [probed](#probation-and-backoffs). This duration
   must be non-zero, and may not be greater than the max-penalty duration. If
diff --git a/linkerd.io/content/2.14/reference/proxy-metrics.md b/linkerd.io/content/2.14/reference/proxy-metrics.md
index af739a5cc7..bb00c5595c 100644
--- a/linkerd.io/content/2.14/reference/proxy-metrics.md
+++ b/linkerd.io/content/2.14/reference/proxy-metrics.md
@@ -252,7 +252,7 @@ Kubernetes resources to which traffic is routed by the proxy:
   route resource through which the proxy discovered the route binding. This will
   either reference an [HTTPRoute] resource or a default (synthesized) route.
 - `backend_group`, `backend_kind`, `backend_name`, and `backend_namespace`
-  reference the backend resource to which which the proxy routed the request.
+  reference the backend resource to which the proxy routed the request.
   This will always be a Service.
 
 In addition, the `outbound_http_balancer_endpoints` gauge metric adds the
diff --git a/linkerd.io/content/2.15/reference/authorization-policy.md b/linkerd.io/content/2.15/reference/authorization-policy.md
index b57c8f1b71..301146f420 100644
--- a/linkerd.io/content/2.15/reference/authorization-policy.md
+++ b/linkerd.io/content/2.15/reference/authorization-policy.md
@@ -45,7 +45,7 @@ The general pattern for authorization is:
 - A `Server` describes a set of pods, and a single port on those pods.
 - Optionally, an `HTTPRoute` references that `Server` and describes a subset of
   HTTP traffic to it.
-- A `MeshTLSAuthentication` or `NetworkAuthentication` decribes who is allowed
+- A `MeshTLSAuthentication` or `NetworkAuthentication` describes who is allowed
   access.
 - An `AuthorizationPolicy` references the `HTTPRoute` or `Server` (the thing to
   be authorized) and the `MeshTLSAuthentication` or `NetworkAuthentication` (the
@@ -156,7 +156,7 @@ lifecycle.
 
 A given HTTP request can only match one HTTPRoute. If multiple HTTPRoutes are
 present that match a request, one will be picked according to the
-[Gateway API rules of precendence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+[Gateway API rules of precedence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
 
 {{< /note >}}
 
@@ -320,7 +320,7 @@ spec:
     - "webapp.booksapp.serviceaccount.identity.linkerd.cluster.local"
 ```
 
-A `MeshTLSAuthentication` which authenticate thes `books` and `webapp` mesh
+A `MeshTLSAuthentication` which authenticates the `books` and `webapp` mesh
 identities. This is an alternative way to specify the same thing as the above
 example.
 
diff --git a/linkerd.io/content/2.15/reference/circuit-breaking.md b/linkerd.io/content/2.15/reference/circuit-breaking.md
index 5d346904ee..0f2c5a0c1a 100644
--- a/linkerd.io/content/2.15/reference/circuit-breaking.md
+++ b/linkerd.io/content/2.15/reference/circuit-breaking.md
@@ -58,7 +58,7 @@ made unavailable once 7 failures occur in a row with no successes.
 
 ## Probation and Backoffs
 
-Once a failure accrual policy makes an endpoint unavailble, the circuit breaker
+Once a failure accrual policy makes an endpoint unavailable, the circuit breaker
 will attempt to determine whether the endpoint is still in a failing state, and
 transition it back to available if it has recovered. This process is called
 _probation_. When an endpoint enters probation, it is temporarily made available
@@ -79,7 +79,7 @@ application traffic must succeed for the endpoint to become available again.
 {{< /note >}}
 
 When an endpoint's failure accrual policy trips the circuit breaker, it will
-remain unavailble for at least a _minimum penalty_ duration. After this duration
+remain unavailable for at least a _minimum penalty_ duration. After this duration
 has elapsed, the endpoint will enter probation. When a probe request fails, the
 endpoint will not be placed in probation again until a backoff duration has
 elapsed. Every time a probe request fails, [the backoff increases
@@ -134,7 +134,7 @@ configure parameters for the consecutive-failures failure accrual policy:
   unavailable. Must be an integer. If this annotation is not present, the
   default value is 7.
 - `balancer.linkerd.io/failure-accrual-consecutive-min-penalty`: Sets the
-  minumum penalty duration for which an endpoint will be marked as unavailable
+  minimum penalty duration for which an endpoint will be marked as unavailable
   after `max-failures` consecutive failures occur. After this period of time
   elapses, the endpoint will be [probed](#probation-and-backoffs). This duration
   must be non-zero, and may not be greater than the max-penalty duration. If
diff --git a/linkerd.io/content/2.15/reference/proxy-metrics.md b/linkerd.io/content/2.15/reference/proxy-metrics.md
index af739a5cc7..bb00c5595c 100644
--- a/linkerd.io/content/2.15/reference/proxy-metrics.md
+++ b/linkerd.io/content/2.15/reference/proxy-metrics.md
@@ -252,7 +252,7 @@ Kubernetes resources to which traffic is routed by the proxy:
   route resource through which the proxy discovered the route binding. This will
   either reference an [HTTPRoute] resource or a default (synthesized) route.
 - `backend_group`, `backend_kind`, `backend_name`, and `backend_namespace`
-  reference the backend resource to which which the proxy routed the request.
+  reference the backend resource to which the proxy routed the request.
   This will always be a Service.
 
 In addition, the `outbound_http_balancer_endpoints` gauge metric adds the
diff --git a/linkerd.io/content/2.16/reference/architecture.md b/linkerd.io/content/2.16/reference/architecture.md
index 8dc18491ef..331cf10a93 100644
--- a/linkerd.io/content/2.16/reference/architecture.md
+++ b/linkerd.io/content/2.16/reference/architecture.md
@@ -91,7 +91,7 @@ You can read more about these micro-proxies here:
 - [Why Linkerd doesn't use Envoy](/2020/12/03/why-linkerd-doesnt-use-envoy/)
 - [Under the hood of Linkerd's state-of-the-art Rust proxy, Linkerd2-proxy](/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/)
 
-### Meshed Conncections
+### Meshed Connections
 
 When one pod establishes a TCP connection to another pod and both of those pods
 are injected with the Linkerd proxy, we say that the connection is _meshed_. The
diff --git a/linkerd.io/content/2.16/reference/authorization-policy.md b/linkerd.io/content/2.16/reference/authorization-policy.md
index 19cce7123b..ed9eebd254 100644
--- a/linkerd.io/content/2.16/reference/authorization-policy.md
+++ b/linkerd.io/content/2.16/reference/authorization-policy.md
@@ -47,7 +47,7 @@ The general pattern for authorization is:
 - A `Server` describes a set of pods, and a single port on those pods.
 - Optionally, an `HTTPRoute` references that `Server` and describes a subset of
   HTTP traffic to it.
-- A `MeshTLSAuthentication` or `NetworkAuthentication` decribes who is allowed
+- A `MeshTLSAuthentication` or `NetworkAuthentication` describes who is allowed
   access.
 - An `AuthorizationPolicy` references the `HTTPRoute` or `Server` (the thing to
   be authorized) and the `MeshTLSAuthentication` or `NetworkAuthentication` (the
@@ -169,7 +169,7 @@ lifecycle.
 
 A given HTTP request can only match one HTTPRoute. If multiple HTTPRoutes are
 present that match a request, one will be picked according to the
-[Gateway API rules of precendence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+[Gateway API rules of precedence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
 
 {{< /note >}}
 
@@ -333,7 +333,7 @@ spec:
     - "webapp.booksapp.serviceaccount.identity.linkerd.cluster.local"
 ```
 
-A `MeshTLSAuthentication` which authenticate thes `books` and `webapp` mesh
+A `MeshTLSAuthentication` which authenticates the `books` and `webapp` mesh
 identities. This is an alternative way to specify the same thing as the above
 example.
 
diff --git a/linkerd.io/content/2.16/reference/circuit-breaking.md b/linkerd.io/content/2.16/reference/circuit-breaking.md
index df45e09039..3c56a1c1fd 100644
--- a/linkerd.io/content/2.16/reference/circuit-breaking.md
+++ b/linkerd.io/content/2.16/reference/circuit-breaking.md
@@ -58,7 +58,7 @@ made unavailable once 7 failures occur in a row with no successes.
 
 ## Probation and Backoffs
 
-Once a failure accrual policy makes an endpoint unavailble, the circuit breaker
+Once a failure accrual policy makes an endpoint unavailable, the circuit breaker
 will attempt to determine whether the endpoint is still in a failing state, and
 transition it back to available if it has recovered. This process is called
 _probation_. When an endpoint enters probation, it is temporarily made available
@@ -79,7 +79,7 @@ application traffic must succeed for the endpoint to become available again.
 {{< /note >}}
 
 When an endpoint's failure accrual policy trips the circuit breaker, it will
-remain unavailble for at least a _minimum penalty_ duration. After this duration
+remain unavailable for at least a _minimum penalty_ duration. After this duration
 has elapsed, the endpoint will enter probation. When a probe request fails, the
 endpoint will not be placed in probation again until a backoff duration has
 elapsed. Every time a probe request fails, [the backoff increases
@@ -134,7 +134,7 @@ configure parameters for the consecutive-failures failure accrual policy:
   unavailable. Must be an integer. If this annotation is not present, the
   default value is 7.
 - `balancer.linkerd.io/failure-accrual-consecutive-min-penalty`: Sets the
-  minumum penalty duration for which an endpoint will be marked as unavailable
+  minimum penalty duration for which an endpoint will be marked as unavailable
   after `max-failures` consecutive failures occur. After this period of time
   elapses, the endpoint will be [probed](#probation-and-backoffs). This duration
   must be non-zero, and may not be greater than the max-penalty duration. If
diff --git a/linkerd.io/content/2.16/reference/proxy-metrics.md b/linkerd.io/content/2.16/reference/proxy-metrics.md
index 989ce4034e..238a65f604 100644
--- a/linkerd.io/content/2.16/reference/proxy-metrics.md
+++ b/linkerd.io/content/2.16/reference/proxy-metrics.md
@@ -270,7 +270,7 @@ Kubernetes resources to which traffic is routed by the proxy:
   route resource through which the proxy discovered the route binding. This will
   either reference an [HTTPRoute] resource or a default (synthesized) route.
 - `backend_group`, `backend_kind`, `backend_name`, and `backend_namespace`
-  reference the backend resource to which which the proxy routed the request.
+  reference the backend resource to which the proxy routed the request.
   This will always be a Service.
 
 In addition, the `outbound_http_balancer_endpoints` gauge metric adds the
diff --git a/linkerd.io/content/2.17/reference/architecture.md b/linkerd.io/content/2.17/reference/architecture.md
index 8dc18491ef..331cf10a93 100644
--- a/linkerd.io/content/2.17/reference/architecture.md
+++ b/linkerd.io/content/2.17/reference/architecture.md
@@ -91,7 +91,7 @@ You can read more about these micro-proxies here:
 - [Why Linkerd doesn't use Envoy](/2020/12/03/why-linkerd-doesnt-use-envoy/)
 - [Under the hood of Linkerd's state-of-the-art Rust proxy, Linkerd2-proxy](/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/)
 
-### Meshed Conncections
+### Meshed Connections
 
 When one pod establishes a TCP connection to another pod and both of those pods
 are injected with the Linkerd proxy, we say that the connection is _meshed_. The
diff --git a/linkerd.io/content/2.17/reference/authorization-policy.md b/linkerd.io/content/2.17/reference/authorization-policy.md
index 19cce7123b..ed9eebd254 100644
--- a/linkerd.io/content/2.17/reference/authorization-policy.md
+++ b/linkerd.io/content/2.17/reference/authorization-policy.md
@@ -47,7 +47,7 @@ The general pattern for authorization is:
 - A `Server` describes a set of pods, and a single port on those pods.
 - Optionally, an `HTTPRoute` references that `Server` and describes a subset of
   HTTP traffic to it.
-- A `MeshTLSAuthentication` or `NetworkAuthentication` decribes who is allowed
+- A `MeshTLSAuthentication` or `NetworkAuthentication` describes who is allowed
   access.
 - An `AuthorizationPolicy` references the `HTTPRoute` or `Server` (the thing to
   be authorized) and the `MeshTLSAuthentication` or `NetworkAuthentication` (the
@@ -169,7 +169,7 @@ lifecycle.
 
 A given HTTP request can only match one HTTPRoute. If multiple HTTPRoutes are
 present that match a request, one will be picked according to the
-[Gateway API rules of precendence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+[Gateway API rules of precedence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
 
 {{< /note >}}
 
@@ -333,7 +333,7 @@ spec:
     - "webapp.booksapp.serviceaccount.identity.linkerd.cluster.local"
 ```
 
-A `MeshTLSAuthentication` which authenticate thes `books` and `webapp` mesh
+A `MeshTLSAuthentication` which authenticates the `books` and `webapp` mesh
 identities. This is an alternative way to specify the same thing as the above
 example.
 
diff --git a/linkerd.io/content/2.17/reference/circuit-breaking.md b/linkerd.io/content/2.17/reference/circuit-breaking.md
index df45e09039..3c56a1c1fd 100644
--- a/linkerd.io/content/2.17/reference/circuit-breaking.md
+++ b/linkerd.io/content/2.17/reference/circuit-breaking.md
@@ -58,7 +58,7 @@ made unavailable once 7 failures occur in a row with no successes.
 
 ## Probation and Backoffs
 
-Once a failure accrual policy makes an endpoint unavailble, the circuit breaker
+Once a failure accrual policy makes an endpoint unavailable, the circuit breaker
 will attempt to determine whether the endpoint is still in a failing state, and
 transition it back to available if it has recovered. This process is called
 _probation_. When an endpoint enters probation, it is temporarily made available
@@ -79,7 +79,7 @@ application traffic must succeed for the endpoint to become available again.
 {{< /note >}}
 
 When an endpoint's failure accrual policy trips the circuit breaker, it will
-remain unavailble for at least a _minimum penalty_ duration. After this duration
+remain unavailable for at least a _minimum penalty_ duration. After this duration
 has elapsed, the endpoint will enter probation. When a probe request fails, the
 endpoint will not be placed in probation again until a backoff duration has
 elapsed. Every time a probe request fails, [the backoff increases
@@ -134,7 +134,7 @@ configure parameters for the consecutive-failures failure accrual policy:
   unavailable. Must be an integer. If this annotation is not present, the
   default value is 7.
 - `balancer.linkerd.io/failure-accrual-consecutive-min-penalty`: Sets the
-  minumum penalty duration for which an endpoint will be marked as unavailable
+  minimum penalty duration for which an endpoint will be marked as unavailable
   after `max-failures` consecutive failures occur. After this period of time
   elapses, the endpoint will be [probed](#probation-and-backoffs). This duration
   must be non-zero, and may not be greater than the max-penalty duration. If
diff --git a/linkerd.io/content/2.17/reference/proxy-metrics.md b/linkerd.io/content/2.17/reference/proxy-metrics.md
index 989ce4034e..238a65f604 100644
--- a/linkerd.io/content/2.17/reference/proxy-metrics.md
+++ b/linkerd.io/content/2.17/reference/proxy-metrics.md
@@ -270,7 +270,7 @@ Kubernetes resources to which traffic is routed by the proxy:
   route resource through which the proxy discovered the route binding. This will
   either reference an [HTTPRoute] resource or a default (synthesized) route.
 - `backend_group`, `backend_kind`, `backend_name`, and `backend_namespace`
-  reference the backend resource to which which the proxy routed the request.
+  reference the backend resource to which the proxy routed the request.
   This will always be a Service.
 
 In addition, the `outbound_http_balancer_endpoints` gauge metric adds the
diff --git a/linkerd.io/content/2.18/reference/architecture.md b/linkerd.io/content/2.18/reference/architecture.md
index 8dc18491ef..331cf10a93 100644
--- a/linkerd.io/content/2.18/reference/architecture.md
+++ b/linkerd.io/content/2.18/reference/architecture.md
@@ -91,7 +91,7 @@ You can read more about these micro-proxies here:
 - [Why Linkerd doesn't use Envoy](/2020/12/03/why-linkerd-doesnt-use-envoy/)
 - [Under the hood of Linkerd's state-of-the-art Rust proxy, Linkerd2-proxy](/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/)
 
-### Meshed Conncections
+### Meshed Connections
 
 When one pod establishes a TCP connection to another pod and both of those pods
 are injected with the Linkerd proxy, we say that the connection is _meshed_. The
diff --git a/linkerd.io/content/2.18/reference/authorization-policy.md b/linkerd.io/content/2.18/reference/authorization-policy.md
index 19cce7123b..ed9eebd254 100644
--- a/linkerd.io/content/2.18/reference/authorization-policy.md
+++ b/linkerd.io/content/2.18/reference/authorization-policy.md
@@ -47,7 +47,7 @@ The general pattern for authorization is:
 - A `Server` describes a set of pods, and a single port on those pods.
 - Optionally, an `HTTPRoute` references that `Server` and describes a subset of
   HTTP traffic to it.
-- A `MeshTLSAuthentication` or `NetworkAuthentication` decribes who is allowed
+- A `MeshTLSAuthentication` or `NetworkAuthentication` describes who is allowed
   access.
 - An `AuthorizationPolicy` references the `HTTPRoute` or `Server` (the thing to
   be authorized) and the `MeshTLSAuthentication` or `NetworkAuthentication` (the
@@ -169,7 +169,7 @@ lifecycle.
 
 A given HTTP request can only match one HTTPRoute. If multiple HTTPRoutes are
 present that match a request, one will be picked according to the
-[Gateway API rules of precendence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+[Gateway API rules of precedence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
 
 {{< /note >}}
 
@@ -333,7 +333,7 @@ spec:
     - "webapp.booksapp.serviceaccount.identity.linkerd.cluster.local"
 ```
 
-A `MeshTLSAuthentication` which authenticate thes `books` and `webapp` mesh
+A `MeshTLSAuthentication` which authenticates the `books` and `webapp` mesh
 identities. This is an alternative way to specify the same thing as the above
 example.
 
diff --git a/linkerd.io/content/2.18/reference/circuit-breaking.md b/linkerd.io/content/2.18/reference/circuit-breaking.md
index df45e09039..3c56a1c1fd 100644
--- a/linkerd.io/content/2.18/reference/circuit-breaking.md
+++ b/linkerd.io/content/2.18/reference/circuit-breaking.md
@@ -58,7 +58,7 @@ made unavailable once 7 failures occur in a row with no successes.
 
 ## Probation and Backoffs
 
-Once a failure accrual policy makes an endpoint unavailble, the circuit breaker
+Once a failure accrual policy makes an endpoint unavailable, the circuit breaker
 will attempt to determine whether the endpoint is still in a failing state, and
 transition it back to available if it has recovered. This process is called
 _probation_. When an endpoint enters probation, it is temporarily made available
@@ -79,7 +79,7 @@ application traffic must succeed for the endpoint to become available again.
 {{< /note >}}
 
 When an endpoint's failure accrual policy trips the circuit breaker, it will
-remain unavailble for at least a _minimum penalty_ duration. After this duration
+remain unavailable for at least a _minimum penalty_ duration. After this duration
 has elapsed, the endpoint will enter probation. When a probe request fails, the
 endpoint will not be placed in probation again until a backoff duration has
 elapsed. Every time a probe request fails, [the backoff increases
@@ -134,7 +134,7 @@ configure parameters for the consecutive-failures failure accrual policy:
   unavailable. Must be an integer. If this annotation is not present, the
   default value is 7.
 - `balancer.linkerd.io/failure-accrual-consecutive-min-penalty`: Sets the
-  minumum penalty duration for which an endpoint will be marked as unavailable
+  minimum penalty duration for which an endpoint will be marked as unavailable
   after `max-failures` consecutive failures occur. After this period of time
   elapses, the endpoint will be [probed](#probation-and-backoffs). This duration
   must be non-zero, and may not be greater than the max-penalty duration. If
diff --git a/linkerd.io/content/2.18/reference/proxy-metrics.md b/linkerd.io/content/2.18/reference/proxy-metrics.md
index 989ce4034e..238a65f604 100644
--- a/linkerd.io/content/2.18/reference/proxy-metrics.md
+++ b/linkerd.io/content/2.18/reference/proxy-metrics.md
@@ -270,7 +270,7 @@ Kubernetes resources to which traffic is routed by the proxy:
   route resource through which the proxy discovered the route binding. This will
   either reference an [HTTPRoute] resource or a default (synthesized) route.
 - `backend_group`, `backend_kind`, `backend_name`, and `backend_namespace`
-  reference the backend resource to which which the proxy routed the request.
+  reference the backend resource to which the proxy routed the request.
   This will always be a Service.
 
 In addition, the `outbound_http_balancer_endpoints` gauge metric adds the
diff --git a/linkerd.io/content/2.19/reference/architecture.md b/linkerd.io/content/2.19/reference/architecture.md
index 8dc18491ef..331cf10a93 100644
--- a/linkerd.io/content/2.19/reference/architecture.md
+++ b/linkerd.io/content/2.19/reference/architecture.md
@@ -91,7 +91,7 @@ You can read more about these micro-proxies here:
 - [Why Linkerd doesn't use Envoy](/2020/12/03/why-linkerd-doesnt-use-envoy/)
 - [Under the hood of Linkerd's state-of-the-art Rust proxy, Linkerd2-proxy](/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/)
 
-### Meshed Conncections
+### Meshed Connections
 
 When one pod establishes a TCP connection to another pod and both of those pods
 are injected with the Linkerd proxy, we say that the connection is _meshed_. The
diff --git a/linkerd.io/content/2.19/reference/authorization-policy.md b/linkerd.io/content/2.19/reference/authorization-policy.md
index 19cce7123b..ed9eebd254 100644
--- a/linkerd.io/content/2.19/reference/authorization-policy.md
+++ b/linkerd.io/content/2.19/reference/authorization-policy.md
@@ -47,7 +47,7 @@ The general pattern for authorization is:
 - A `Server` describes a set of pods, and a single port on those pods.
 - Optionally, an `HTTPRoute` references that `Server` and describes a subset of
   HTTP traffic to it.
-- A `MeshTLSAuthentication` or `NetworkAuthentication` decribes who is allowed
+- A `MeshTLSAuthentication` or `NetworkAuthentication` describes who is allowed
   access.
 - An `AuthorizationPolicy` references the `HTTPRoute` or `Server` (the thing to
   be authorized) and the `MeshTLSAuthentication` or `NetworkAuthentication` (the
@@ -169,7 +169,7 @@ lifecycle.
 
 A given HTTP request can only match one HTTPRoute. If multiple HTTPRoutes are
 present that match a request, one will be picked according to the
-[Gateway API rules of precendence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+[Gateway API rules of precedence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
 
 {{< /note >}}
 
@@ -333,7 +333,7 @@ spec:
     - "webapp.booksapp.serviceaccount.identity.linkerd.cluster.local"
 ```
 
-A `MeshTLSAuthentication` which authenticate thes `books` and `webapp` mesh
+A `MeshTLSAuthentication` which authenticates the `books` and `webapp` mesh
 identities. This is an alternative way to specify the same thing as the above
 example.
 
diff --git a/linkerd.io/content/2.19/reference/circuit-breaking.md b/linkerd.io/content/2.19/reference/circuit-breaking.md
index df45e09039..3c56a1c1fd 100644
--- a/linkerd.io/content/2.19/reference/circuit-breaking.md
+++ b/linkerd.io/content/2.19/reference/circuit-breaking.md
@@ -58,7 +58,7 @@ made unavailable once 7 failures occur in a row with no successes.
 
 ## Probation and Backoffs
 
-Once a failure accrual policy makes an endpoint unavailble, the circuit breaker
+Once a failure accrual policy makes an endpoint unavailable, the circuit breaker
 will attempt to determine whether the endpoint is still in a failing state, and
 transition it back to available if it has recovered. This process is called
 _probation_. When an endpoint enters probation, it is temporarily made available
@@ -79,7 +79,7 @@ application traffic must succeed for the endpoint to become available again.
 {{< /note >}}
 
 When an endpoint's failure accrual policy trips the circuit breaker, it will
-remain unavailble for at least a _minimum penalty_ duration. After this duration
+remain unavailable for at least a _minimum penalty_ duration. After this duration
 has elapsed, the endpoint will enter probation. When a probe request fails, the
 endpoint will not be placed in probation again until a backoff duration has
 elapsed. Every time a probe request fails, [the backoff increases
@@ -134,7 +134,7 @@ configure parameters for the consecutive-failures failure accrual policy:
   unavailable. Must be an integer. If this annotation is not present, the
   default value is 7.
 - `balancer.linkerd.io/failure-accrual-consecutive-min-penalty`: Sets the
-  minumum penalty duration for which an endpoint will be marked as unavailable
+  minimum penalty duration for which an endpoint will be marked as unavailable
   after `max-failures` consecutive failures occur. After this period of time
   elapses, the endpoint will be [probed](#probation-and-backoffs). This duration
   must be non-zero, and may not be greater than the max-penalty duration. If
diff --git a/linkerd.io/content/2.19/reference/proxy-metrics.md b/linkerd.io/content/2.19/reference/proxy-metrics.md
index 22c5623f37..6d8881fce8 100644
--- a/linkerd.io/content/2.19/reference/proxy-metrics.md
+++ b/linkerd.io/content/2.19/reference/proxy-metrics.md
@@ -20,7 +20,7 @@ port (default: `:4191`) in the [Prometheus format][prom-format].
   - `tls_kx_groups`: The set of key exchange algorithms the proxy will use,
     sorted by preference order.
   - `tls_rand`: The secure randomness provider
-  - `tls_key_provider`: The crytpographic key provider
+  - `tls_key_provider`: The cryptographic key provider
   - `tls_fips`: A boolean denoting if the proxy's connections are
     FIPS-compliant.
 - `tokio_rt_*`: A set of counters and gauges with stats on the proxy's
@@ -319,7 +319,7 @@ Kubernetes resources to which traffic is routed by the proxy:
   route resource through which the proxy discovered the route binding. This will
   either reference an [HTTPRoute] resource or a default (synthesized) route.
 - `backend_group`, `backend_kind`, `backend_name`, and `backend_namespace`
-  reference the backend resource to which which the proxy routed the request.
+  reference the backend resource to which the proxy routed the request.
   This will always be a Service.
 
 In addition, the `outbound_http_balancer_endpoints` gauge metric adds the
diff --git a/linkerd.io/content/docs/reference/architecture.md b/linkerd.io/content/docs/reference/architecture.md
index 3b4fab06a8..8ee6942c28 100644
--- a/linkerd.io/content/docs/reference/architecture.md
+++ b/linkerd.io/content/docs/reference/architecture.md
@@ -93,7 +93,7 @@ You can read more about these micro-proxies here:
 - [Why Linkerd doesn't use Envoy](/2020/12/03/why-linkerd-doesnt-use-envoy/)
 - [Under the hood of Linkerd's state-of-the-art Rust proxy, Linkerd2-proxy](/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/)
 
-### Meshed Conncections
+### Meshed Connections
 
 When one pod establishes a TCP connection to another pod and both of those pods
 are injected with the Linkerd proxy, we say that the connection is _meshed_. The
diff --git a/linkerd.io/content/docs/reference/authorization-policy.md b/linkerd.io/content/docs/reference/authorization-policy.md
index 19cce7123b..ed9eebd254 100644
--- a/linkerd.io/content/docs/reference/authorization-policy.md
+++ b/linkerd.io/content/docs/reference/authorization-policy.md
@@ -47,7 +47,7 @@ The general pattern for authorization is:
 - A `Server` describes a set of pods, and a single port on those pods.
 - Optionally, an `HTTPRoute` references that `Server` and describes a subset of
   HTTP traffic to it.
-- A `MeshTLSAuthentication` or `NetworkAuthentication` decribes who is allowed
+- A `MeshTLSAuthentication` or `NetworkAuthentication` describes who is allowed
   access.
 - An `AuthorizationPolicy` references the `HTTPRoute` or `Server` (the thing to
   be authorized) and the `MeshTLSAuthentication` or `NetworkAuthentication` (the
@@ -169,7 +169,7 @@ lifecycle.
 
 A given HTTP request can only match one HTTPRoute. If multiple HTTPRoutes are
 present that match a request, one will be picked according to the
-[Gateway API rules of precendence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+[Gateway API rules of precedence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
 
 {{< /note >}}
 
@@ -333,7 +333,7 @@ spec:
     - "webapp.booksapp.serviceaccount.identity.linkerd.cluster.local"
 ```
 
-A `MeshTLSAuthentication` which authenticate thes `books` and `webapp` mesh
+A `MeshTLSAuthentication` which authenticates the `books` and `webapp` mesh
 identities. This is an alternative way to specify the same thing as the above
 example.
 
diff --git a/linkerd.io/content/docs/reference/circuit-breaking.md b/linkerd.io/content/docs/reference/circuit-breaking.md
index 66b1463aa6..c3f551254b 100644
--- a/linkerd.io/content/docs/reference/circuit-breaking.md
+++ b/linkerd.io/content/docs/reference/circuit-breaking.md
@@ -85,7 +85,7 @@ accrual, see [Rate Limit Aware Load Balancing](../tasks/rate-limit-aware-load-ba
 
 ## Probation and Backoffs
 
-Once a failure accrual policy makes an endpoint unavailble, the circuit breaker
+Once a failure accrual policy makes an endpoint unavailable, the circuit breaker
 will attempt to determine whether the endpoint is still in a failing state, and
 transition it back to available if it has recovered. This process is called
 _probation_. When an endpoint enters probation, it is temporarily made available
@@ -106,7 +106,7 @@ application traffic must succeed for the endpoint to become available again.
 {{< /note >}}
 
 When an endpoint's failure accrual policy trips the circuit breaker, it will
-remain unavailble for at least a _minimum penalty_ duration. After this duration
+remain unavailable for at least a _minimum penalty_ duration. After this duration
 has elapsed, the endpoint will enter probation. When a probe request fails, the
 endpoint will not be placed in probation again until a backoff duration has
 elapsed. Every time a probe request fails, [the backoff increases
@@ -160,7 +160,7 @@ configure parameters for the consecutive-failures failure accrual policy:
   unavailable. Must be an integer. If this annotation is not present, the
   default value is 7.
 - `balancer.linkerd.io/failure-accrual-consecutive-min-penalty`: Sets the
-  minumum penalty duration for which an endpoint will be marked as unavailable
+  minimum penalty duration for which an endpoint will be marked as unavailable
   after `max-failures` consecutive failures occur. After this period of time
   elapses, the endpoint will be [probed](#probation-and-backoffs). This duration
   must be non-zero, and may not be greater than the max-penalty duration. If
diff --git a/linkerd.io/content/docs/reference/proxy-metrics.md b/linkerd.io/content/docs/reference/proxy-metrics.md
index 2cae1aa634..63907d169d 100644
--- a/linkerd.io/content/docs/reference/proxy-metrics.md
+++ b/linkerd.io/content/docs/reference/proxy-metrics.md
@@ -20,7 +20,7 @@ port (default: `:4191`) in the [Prometheus format][prom-format].
   - `tls_kx_groups`: The set of key exchange algorithms the proxy will use,
     sorted by preference order.
   - `tls_rand`: The secure randomness provider
-  - `tls_key_provider`: The crytpographic key provider
+  - `tls_key_provider`: The cryptographic key provider
   - `tls_fips`: A boolean denoting if the proxy's connections are
     FIPS-compliant.
 - `tokio_rt_*`: A set of counters and gauges with stats on the proxy's
@@ -350,7 +350,7 @@ Kubernetes resources to which traffic is routed by the proxy:
   route resource through which the proxy discovered the route binding. This will
   either reference an [HTTPRoute] resource or a default (synthesized) route.
 - `backend_group`, `backend_kind`, `backend_name`, and `backend_namespace`
-  reference the backend resource to which which the proxy routed the request.
+  reference the backend resource to which the proxy routed the request.
   This will always be a Service.
 
 In addition, the `outbound_http_balancer_endpoints` gauge metric adds the

From 52a13afe07caa7898e511fbec357414e9e32dfba Mon Sep 17 00:00:00 2001
From: joedrf <joe@buoyant.io>
Date: Sun, 26 Jul 2026 17:24:31 +0100
Subject: [PATCH 2/3] fix(docs): correct spelling and duplicated words in task
 docs

- accross -> across
- resiliant -> resilient
- dyanmic -> dynamic
- proxy-injnector -> proxy-injector
- dupliate -> duplicate
- tutoral -> tutorial
- consective -> consecutive
- Instrunctions -> Instructions
- recieve -> receive
- duplicated 'the the'
- instaneously -> instantaneously
- Uninstallating -> Uninstalling
- duplicated 'as as'
- wil -> will
- duplicated 'to to'
- duplicated 'to to'
- duplicated 'with with'
- stray double comma

Applied across all versioned docs directories (2-edge, docs, 2.10-2.19),
following the convention in linkerd/website#1961 and #2137.

Signed-off-by: joedrf <joe@buoyant.io>
---
 .../automatically-rotating-control-plane-tls-credentials.md   | 2 +-
 linkerd.io/content/2-edge/tasks/circuit-breakers.md           | 4 ++--
 .../2-edge/tasks/configuring-dynamic-request-routing.md       | 2 +-
 linkerd.io/content/2-edge/tasks/federated-services.md         | 4 ++--
 linkerd.io/content/2-edge/tasks/generate-certificates.md      | 2 +-
 linkerd.io/content/2-edge/tasks/grafana.md                    | 2 +-
 linkerd.io/content/2-edge/tasks/install-helm.md               | 2 +-
 linkerd.io/content/2-edge/tasks/install.md                    | 2 +-
 .../content/2-edge/tasks/rotating_webhooks_certificates.md    | 2 +-
 .../content/2-edge/tasks/setting-up-service-profiles.md       | 2 +-
 linkerd.io/content/2-edge/tasks/traffic-shifting.md           | 4 ++--
 linkerd.io/content/2-edge/tasks/troubleshooting.md            | 4 ++--
 linkerd.io/content/2-edge/tasks/uninstall.md                  | 2 +-
 linkerd.io/content/2-edge/tasks/using-ingress.md              | 4 ++--
 linkerd.io/content/2.10/tasks/generate-certificates.md        | 2 +-
 .../content/2.10/tasks/rotating_webhooks_certificates.md      | 2 +-
 linkerd.io/content/2.10/tasks/setting-up-service-profiles.md  | 2 +-
 linkerd.io/content/2.10/tasks/troubleshooting.md              | 2 +-
 linkerd.io/content/2.10/tasks/uninstall.md                    | 2 +-
 linkerd.io/content/2.11/tasks/generate-certificates.md        | 2 +-
 linkerd.io/content/2.11/tasks/grafana.md                      | 2 +-
 linkerd.io/content/2.11/tasks/install-helm.md                 | 2 +-
 linkerd.io/content/2.11/tasks/install.md                      | 2 +-
 .../content/2.11/tasks/rotating_webhooks_certificates.md      | 2 +-
 linkerd.io/content/2.11/tasks/setting-up-service-profiles.md  | 2 +-
 linkerd.io/content/2.11/tasks/troubleshooting.md              | 2 +-
 linkerd.io/content/2.11/tasks/uninstall.md                    | 2 +-
 linkerd.io/content/2.12/tasks/generate-certificates.md        | 2 +-
 linkerd.io/content/2.12/tasks/grafana.md                      | 2 +-
 linkerd.io/content/2.12/tasks/install-helm.md                 | 2 +-
 linkerd.io/content/2.12/tasks/install.md                      | 2 +-
 .../content/2.12/tasks/rotating_webhooks_certificates.md      | 2 +-
 linkerd.io/content/2.12/tasks/setting-up-service-profiles.md  | 2 +-
 linkerd.io/content/2.12/tasks/troubleshooting.md              | 2 +-
 linkerd.io/content/2.12/tasks/uninstall.md                    | 2 +-
 linkerd.io/content/2.13/tasks/circuit-breakers.md             | 4 ++--
 linkerd.io/content/2.13/tasks/generate-certificates.md        | 2 +-
 linkerd.io/content/2.13/tasks/grafana.md                      | 2 +-
 linkerd.io/content/2.13/tasks/install-helm.md                 | 2 +-
 linkerd.io/content/2.13/tasks/install.md                      | 2 +-
 .../content/2.13/tasks/rotating_webhooks_certificates.md      | 2 +-
 linkerd.io/content/2.13/tasks/setting-up-service-profiles.md  | 2 +-
 linkerd.io/content/2.13/tasks/troubleshooting.md              | 2 +-
 linkerd.io/content/2.13/tasks/uninstall.md                    | 2 +-
 linkerd.io/content/2.13/tasks/using-ingress.md                | 4 ++--
 .../automatically-rotating-control-plane-tls-credentials.md   | 2 +-
 linkerd.io/content/2.14/tasks/circuit-breakers.md             | 4 ++--
 linkerd.io/content/2.14/tasks/generate-certificates.md        | 2 +-
 linkerd.io/content/2.14/tasks/grafana.md                      | 2 +-
 linkerd.io/content/2.14/tasks/install-helm.md                 | 2 +-
 linkerd.io/content/2.14/tasks/install.md                      | 2 +-
 .../content/2.14/tasks/rotating_webhooks_certificates.md      | 2 +-
 linkerd.io/content/2.14/tasks/setting-up-service-profiles.md  | 2 +-
 linkerd.io/content/2.14/tasks/troubleshooting.md              | 2 +-
 linkerd.io/content/2.14/tasks/uninstall.md                    | 2 +-
 linkerd.io/content/2.14/tasks/using-ingress.md                | 4 ++--
 .../automatically-rotating-control-plane-tls-credentials.md   | 2 +-
 linkerd.io/content/2.15/tasks/circuit-breakers.md             | 4 ++--
 linkerd.io/content/2.15/tasks/generate-certificates.md        | 2 +-
 linkerd.io/content/2.15/tasks/grafana.md                      | 2 +-
 linkerd.io/content/2.15/tasks/install-helm.md                 | 2 +-
 linkerd.io/content/2.15/tasks/install.md                      | 2 +-
 .../content/2.15/tasks/rotating_webhooks_certificates.md      | 2 +-
 linkerd.io/content/2.15/tasks/setting-up-service-profiles.md  | 2 +-
 linkerd.io/content/2.15/tasks/troubleshooting.md              | 2 +-
 linkerd.io/content/2.15/tasks/uninstall.md                    | 2 +-
 linkerd.io/content/2.15/tasks/using-ingress.md                | 4 ++--
 .../automatically-rotating-control-plane-tls-credentials.md   | 2 +-
 linkerd.io/content/2.16/tasks/circuit-breakers.md             | 4 ++--
 .../content/2.16/tasks/configuring-dynamic-request-routing.md | 2 +-
 linkerd.io/content/2.16/tasks/generate-certificates.md        | 2 +-
 linkerd.io/content/2.16/tasks/grafana.md                      | 2 +-
 linkerd.io/content/2.16/tasks/install-helm.md                 | 2 +-
 linkerd.io/content/2.16/tasks/install.md                      | 2 +-
 .../content/2.16/tasks/rotating_webhooks_certificates.md      | 2 +-
 linkerd.io/content/2.16/tasks/setting-up-service-profiles.md  | 2 +-
 linkerd.io/content/2.16/tasks/traffic-shifting.md             | 4 ++--
 linkerd.io/content/2.16/tasks/troubleshooting.md              | 2 +-
 linkerd.io/content/2.16/tasks/uninstall.md                    | 2 +-
 linkerd.io/content/2.16/tasks/using-ingress.md                | 4 ++--
 .../automatically-rotating-control-plane-tls-credentials.md   | 2 +-
 linkerd.io/content/2.17/tasks/circuit-breakers.md             | 4 ++--
 .../content/2.17/tasks/configuring-dynamic-request-routing.md | 2 +-
 linkerd.io/content/2.17/tasks/federated-services.md           | 4 ++--
 linkerd.io/content/2.17/tasks/generate-certificates.md        | 2 +-
 linkerd.io/content/2.17/tasks/grafana.md                      | 2 +-
 linkerd.io/content/2.17/tasks/install-helm.md                 | 2 +-
 linkerd.io/content/2.17/tasks/install.md                      | 2 +-
 .../content/2.17/tasks/rotating_webhooks_certificates.md      | 2 +-
 linkerd.io/content/2.17/tasks/setting-up-service-profiles.md  | 2 +-
 linkerd.io/content/2.17/tasks/traffic-shifting.md             | 4 ++--
 linkerd.io/content/2.17/tasks/troubleshooting.md              | 4 ++--
 linkerd.io/content/2.17/tasks/uninstall.md                    | 2 +-
 linkerd.io/content/2.17/tasks/using-ingress.md                | 4 ++--
 .../automatically-rotating-control-plane-tls-credentials.md   | 2 +-
 linkerd.io/content/2.18/tasks/circuit-breakers.md             | 4 ++--
 .../content/2.18/tasks/configuring-dynamic-request-routing.md | 2 +-
 linkerd.io/content/2.18/tasks/federated-services.md           | 4 ++--
 linkerd.io/content/2.18/tasks/generate-certificates.md        | 2 +-
 linkerd.io/content/2.18/tasks/grafana.md                      | 2 +-
 linkerd.io/content/2.18/tasks/install-helm.md                 | 2 +-
 linkerd.io/content/2.18/tasks/install.md                      | 2 +-
 .../content/2.18/tasks/rotating_webhooks_certificates.md      | 2 +-
 linkerd.io/content/2.18/tasks/setting-up-service-profiles.md  | 2 +-
 linkerd.io/content/2.18/tasks/traffic-shifting.md             | 4 ++--
 linkerd.io/content/2.18/tasks/troubleshooting.md              | 4 ++--
 linkerd.io/content/2.18/tasks/uninstall.md                    | 2 +-
 linkerd.io/content/2.18/tasks/using-ingress.md                | 4 ++--
 .../automatically-rotating-control-plane-tls-credentials.md   | 2 +-
 linkerd.io/content/2.19/tasks/circuit-breakers.md             | 4 ++--
 .../content/2.19/tasks/configuring-dynamic-request-routing.md | 2 +-
 linkerd.io/content/2.19/tasks/federated-services.md           | 4 ++--
 linkerd.io/content/2.19/tasks/generate-certificates.md        | 2 +-
 linkerd.io/content/2.19/tasks/grafana.md                      | 2 +-
 linkerd.io/content/2.19/tasks/install-helm.md                 | 2 +-
 linkerd.io/content/2.19/tasks/install.md                      | 2 +-
 .../content/2.19/tasks/rotating_webhooks_certificates.md      | 2 +-
 linkerd.io/content/2.19/tasks/setting-up-service-profiles.md  | 2 +-
 linkerd.io/content/2.19/tasks/traffic-shifting.md             | 4 ++--
 linkerd.io/content/2.19/tasks/troubleshooting.md              | 4 ++--
 linkerd.io/content/2.19/tasks/uninstall.md                    | 2 +-
 linkerd.io/content/2.19/tasks/using-ingress.md                | 4 ++--
 .../automatically-rotating-control-plane-tls-credentials.md   | 2 +-
 linkerd.io/content/docs/tasks/circuit-breakers.md             | 4 ++--
 .../content/docs/tasks/configuring-dynamic-request-routing.md | 2 +-
 linkerd.io/content/docs/tasks/federated-services.md           | 4 ++--
 linkerd.io/content/docs/tasks/generate-certificates.md        | 2 +-
 linkerd.io/content/docs/tasks/grafana.md                      | 2 +-
 linkerd.io/content/docs/tasks/install-helm.md                 | 2 +-
 linkerd.io/content/docs/tasks/install.md                      | 2 +-
 .../content/docs/tasks/rotating_webhooks_certificates.md      | 2 +-
 linkerd.io/content/docs/tasks/setting-up-service-profiles.md  | 2 +-
 linkerd.io/content/docs/tasks/traffic-shifting.md             | 4 ++--
 linkerd.io/content/docs/tasks/troubleshooting.md              | 4 ++--
 linkerd.io/content/docs/tasks/uninstall.md                    | 2 +-
 linkerd.io/content/docs/tasks/using-ingress.md                | 4 ++--
 136 files changed, 170 insertions(+), 170 deletions(-)

diff --git a/linkerd.io/content/2-edge/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2-edge/tasks/automatically-rotating-control-plane-tls-credentials.md
index 425dd65dad..de2ec39c1b 100644
--- a/linkerd.io/content/2-edge/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2-edge/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -388,7 +388,7 @@ Almost done! We only need one more thing: the _trust bundle_ will lets Linkerd
 know which trust anchors to accept. We'll use trust-manager for this, but
 there's a catch: when rotating the trust anchor, both the control plane and the
 data plane (the proxies) need to be restarted. Since that can't happen
-instaneously, we need to have both the old trust anchor and the new trust anchor
+instantaneously, we need to have both the old trust anchor and the new trust anchor
 in the trust bundle until all the restarts have completed.
 
 trust-manager can do this, but it needs a specific source for _each_ certificate
diff --git a/linkerd.io/content/2-edge/tasks/circuit-breakers.md b/linkerd.io/content/2-edge/tasks/circuit-breakers.md
index d038ccf382..524e9fec5e 100644
--- a/linkerd.io/content/2-edge/tasks/circuit-breakers.md
+++ b/linkerd.io/content/2-edge/tasks/circuit-breakers.md
@@ -7,7 +7,7 @@ Circuit breaking is a powerful feature where Linkerd will temporarily stop
 routing requests to an endpoint if that endpoint is deemed to be unhealthy,
 instead routing that request to other replicas in the Service.
 
-In this tutoral, we'll see how to enable circuit breaking on a Service to
+In this tutorial, we'll see how to enable circuit breaking on a Service to
 improve client success rate when a backend replica is unhealthy.
 
 See the [reference documentation](../reference/circuit-breaking/) for more
@@ -217,7 +217,7 @@ failure accrual:
 
 This tells us that Linkerd will use `ConsecutiveFailures` failure accrual when
 talking to the `bb` Service. It also tells us that the `max_failures` is 7,
-meaning that it will trip the circuit breaker once it observes 7 consective
+meaning that it will trip the circuit breaker once it observes 7 consecutive
 failures. We'll talk more about each of the parameters here at the end of this
 article.
 
diff --git a/linkerd.io/content/2-edge/tasks/configuring-dynamic-request-routing.md b/linkerd.io/content/2-edge/tasks/configuring-dynamic-request-routing.md
index 004b50ded6..32186af1ff 100644
--- a/linkerd.io/content/2-edge/tasks/configuring-dynamic-request-routing.md
+++ b/linkerd.io/content/2-edge/tasks/configuring-dynamic-request-routing.md
@@ -156,7 +156,7 @@ In the example above, we used the `x-request-id` header, which is a common
 header that is forwarded by podinfo. However, the same technique will work with
 arbitrary headers, as long as the application forwards them.
 
-Note also that dyanmic request routing is client-side behavior, so while the
+Note also that dynamic request routing is client-side behavior, so while the
 traffic source (in this case, the frontend pod) needs to be meshed, strictly
 speaking, the destination does not need to be meshed.
 
diff --git a/linkerd.io/content/2-edge/tasks/federated-services.md b/linkerd.io/content/2-edge/tasks/federated-services.md
index 73487c1b9c..0ae2bedeca 100644
--- a/linkerd.io/content/2-edge/tasks/federated-services.md
+++ b/linkerd.io/content/2-edge/tasks/federated-services.md
@@ -8,7 +8,7 @@ which act as a union of multiple services in different clusters with the same
 name and namespace. By sending traffic to the federated service, that traffic
 will be load balanced among all endpoints of that service in all linked
 clusters. This allows the client to be cluster agnostic, balance traffic across
-multiple clusters, and be resiliant to the failure of any individual cluster.
+multiple clusters, and be resilient to the failure of any individual cluster.
 
 Federated services send traffic directly to the pods of the member services
 rather than through a gateway. Therefore, federated services have the same
@@ -362,7 +362,7 @@ is distributing requests across all three clusters:
 
 ## Next Steps
 
-We now have a federated service that balances traffic accross services in three
+We now have a federated service that balances traffic across services in three
 clusters. Additional clusters can be added simply by:
 
 - Updating the linkerd-multicluster config in `west` to add the required
diff --git a/linkerd.io/content/2-edge/tasks/generate-certificates.md b/linkerd.io/content/2-edge/tasks/generate-certificates.md
index 33dd6751d1..cb43b52098 100644
--- a/linkerd.io/content/2-edge/tasks/generate-certificates.md
+++ b/linkerd.io/content/2-edge/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/2-edge/tasks/grafana.md b/linkerd.io/content/2-edge/tasks/grafana.md
index 24f88e6dc3..4b40f1afb5 100644
--- a/linkerd.io/content/2-edge/tasks/grafana.md
+++ b/linkerd.io/content/2-edge/tasks/grafana.md
@@ -81,7 +81,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 
diff --git a/linkerd.io/content/2-edge/tasks/install-helm.md b/linkerd.io/content/2-edge/tasks/install-helm.md
index 5f31f1d3a9..014e3be9ff 100644
--- a/linkerd.io/content/2-edge/tasks/install-helm.md
+++ b/linkerd.io/content/2-edge/tasks/install-helm.md
@@ -43,7 +43,7 @@ then `linkerd-control-plane`.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2-edge/tasks/install.md b/linkerd.io/content/2-edge/tasks/install.md
index 0eaf611bd3..c42b3af035 100644
--- a/linkerd.io/content/2-edge/tasks/install.md
+++ b/linkerd.io/content/2-edge/tasks/install.md
@@ -66,7 +66,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2-edge/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/2-edge/tasks/rotating_webhooks_certificates.md
index 3784403a60..834ce27399 100644
--- a/linkerd.io/content/2-edge/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/2-edge/tasks/rotating_webhooks_certificates.md
@@ -64,7 +64,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2-edge/tasks/setting-up-service-profiles.md b/linkerd.io/content/2-edge/tasks/setting-up-service-profiles.md
index be9284058e..0c15421ba4 100644
--- a/linkerd.io/content/2-edge/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/2-edge/tasks/setting-up-service-profiles.md
@@ -19,7 +19,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 per-route metric, retries, and timeouts.
 
 The `destination service` for a request is computed by selecting the value of
diff --git a/linkerd.io/content/2-edge/tasks/traffic-shifting.md b/linkerd.io/content/2-edge/tasks/traffic-shifting.md
index 1091aa6198..4525d5fa8f 100644
--- a/linkerd.io/content/2-edge/tasks/traffic-shifting.md
+++ b/linkerd.io/content/2-edge/tasks/traffic-shifting.md
@@ -14,8 +14,8 @@ Traffic splitting is accomplished with [HTTPRoute] and [GRPCRoute] types.
 
 Earlier versions of Linkerd provided a
 [TrafficSplit](https://github.com/servicemeshinterface/smi-spec/blob/main/apis/traffic-split/v1alpha2/traffic-split.md/)
-resource as part of the the [Linkerd SMI extension](linkerd-smi/) for traffic
-splitting. This approach is still supported but will not recieve further feature
+resource as part of the [Linkerd SMI extension](linkerd-smi/) for traffic
+splitting. This approach is still supported but will not receive further feature
 development.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2-edge/tasks/troubleshooting.md b/linkerd.io/content/2-edge/tasks/troubleshooting.md
index a9081f9e9b..929d16c5fe 100644
--- a/linkerd.io/content/2-edge/tasks/troubleshooting.md
+++ b/linkerd.io/content/2-edge/tasks/troubleshooting.md
@@ -703,7 +703,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
@@ -1161,7 +1161,7 @@ triggered if an extension value is used for the label key more than once across
 the cluster.
 
 To resolve this warning, ensure that the `linkerd.io/extension` namespace label
-does not have any dupliate values, indicating that an extension has been
+does not have any duplicate values, indicating that an extension has been
 installed more than once in different namespaces.
 
 ### Extensions checks
diff --git a/linkerd.io/content/2-edge/tasks/uninstall.md b/linkerd.io/content/2-edge/tasks/uninstall.md
index 7dbd4496fd..fc362e83bf 100644
--- a/linkerd.io/content/2-edge/tasks/uninstall.md
+++ b/linkerd.io/content/2-edge/tasks/uninstall.md
@@ -31,7 +31,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2-edge/tasks/using-ingress.md b/linkerd.io/content/2-edge/tasks/using-ingress.md
index 618c00d615..0d9468aa23 100644
--- a/linkerd.io/content/2-edge/tasks/using-ingress.md
+++ b/linkerd.io/content/2-edge/tasks/using-ingress.md
@@ -333,8 +333,8 @@ spec:
 
 ## GCE
 
-The GCE ingress should be meshed with with
-[ingress mode enabled](#ingress-mode), , i.e. with the
+The GCE ingress should be meshed with
+[ingress mode enabled](#ingress-mode), i.e. with the
 `linkerd.io/inject: ingress` annotation rather than the default `enabled`.
 
 This example shows how to use a
diff --git a/linkerd.io/content/2.10/tasks/generate-certificates.md b/linkerd.io/content/2.10/tasks/generate-certificates.md
index f3ebf8dce5..7f6ab8bdc5 100644
--- a/linkerd.io/content/2.10/tasks/generate-certificates.md
+++ b/linkerd.io/content/2.10/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/2.10/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/2.10/tasks/rotating_webhooks_certificates.md
index bfa5b61e2d..0fd9c9e6e7 100644
--- a/linkerd.io/content/2.10/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/2.10/tasks/rotating_webhooks_certificates.md
@@ -68,7 +68,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.10/tasks/setting-up-service-profiles.md b/linkerd.io/content/2.10/tasks/setting-up-service-profiles.md
index 8108dcbe90..ad19186f26 100644
--- a/linkerd.io/content/2.10/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/2.10/tasks/setting-up-service-profiles.md
@@ -9,7 +9,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 [per-route metrics](getting-per-route-metrics/), [retries](configuring-retries/)
 and [timeouts](configuring-timeouts/).
 
diff --git a/linkerd.io/content/2.10/tasks/troubleshooting.md b/linkerd.io/content/2.10/tasks/troubleshooting.md
index 06147f6c97..6a11b4ab7b 100644
--- a/linkerd.io/content/2.10/tasks/troubleshooting.md
+++ b/linkerd.io/content/2.10/tasks/troubleshooting.md
@@ -724,7 +724,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
diff --git a/linkerd.io/content/2.10/tasks/uninstall.md b/linkerd.io/content/2.10/tasks/uninstall.md
index bf10a09044..cf58c367b4 100644
--- a/linkerd.io/content/2.10/tasks/uninstall.md
+++ b/linkerd.io/content/2.10/tasks/uninstall.md
@@ -34,7 +34,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.11/tasks/generate-certificates.md b/linkerd.io/content/2.11/tasks/generate-certificates.md
index f3ebf8dce5..7f6ab8bdc5 100644
--- a/linkerd.io/content/2.11/tasks/generate-certificates.md
+++ b/linkerd.io/content/2.11/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/2.11/tasks/grafana.md b/linkerd.io/content/2.11/tasks/grafana.md
index 908f199780..f382d57dc9 100644
--- a/linkerd.io/content/2.11/tasks/grafana.md
+++ b/linkerd.io/content/2.11/tasks/grafana.md
@@ -65,7 +65,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 
diff --git a/linkerd.io/content/2.11/tasks/install-helm.md b/linkerd.io/content/2.11/tasks/install-helm.md
index 15c4c1b502..8bba2f2eea 100644
--- a/linkerd.io/content/2.11/tasks/install-helm.md
+++ b/linkerd.io/content/2.11/tasks/install-helm.md
@@ -48,7 +48,7 @@ the `2.12.0` stable release as well when it comes out.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.11/tasks/install.md b/linkerd.io/content/2.11/tasks/install.md
index 3e16de2696..1e7d54fa02 100644
--- a/linkerd.io/content/2.11/tasks/install.md
+++ b/linkerd.io/content/2.11/tasks/install.md
@@ -46,7 +46,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.11/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/2.11/tasks/rotating_webhooks_certificates.md
index 6a866e3cb2..e37f48002a 100644
--- a/linkerd.io/content/2.11/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/2.11/tasks/rotating_webhooks_certificates.md
@@ -68,7 +68,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.11/tasks/setting-up-service-profiles.md b/linkerd.io/content/2.11/tasks/setting-up-service-profiles.md
index 8108dcbe90..ad19186f26 100644
--- a/linkerd.io/content/2.11/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/2.11/tasks/setting-up-service-profiles.md
@@ -9,7 +9,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 [per-route metrics](getting-per-route-metrics/), [retries](configuring-retries/)
 and [timeouts](configuring-timeouts/).
 
diff --git a/linkerd.io/content/2.11/tasks/troubleshooting.md b/linkerd.io/content/2.11/tasks/troubleshooting.md
index d6205179f5..7df5f92857 100644
--- a/linkerd.io/content/2.11/tasks/troubleshooting.md
+++ b/linkerd.io/content/2.11/tasks/troubleshooting.md
@@ -755,7 +755,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
diff --git a/linkerd.io/content/2.11/tasks/uninstall.md b/linkerd.io/content/2.11/tasks/uninstall.md
index bf10a09044..cf58c367b4 100644
--- a/linkerd.io/content/2.11/tasks/uninstall.md
+++ b/linkerd.io/content/2.11/tasks/uninstall.md
@@ -34,7 +34,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.12/tasks/generate-certificates.md b/linkerd.io/content/2.12/tasks/generate-certificates.md
index 33dd6751d1..cb43b52098 100644
--- a/linkerd.io/content/2.12/tasks/generate-certificates.md
+++ b/linkerd.io/content/2.12/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/2.12/tasks/grafana.md b/linkerd.io/content/2.12/tasks/grafana.md
index d1c77b336e..d7498a7747 100644
--- a/linkerd.io/content/2.12/tasks/grafana.md
+++ b/linkerd.io/content/2.12/tasks/grafana.md
@@ -67,7 +67,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 
diff --git a/linkerd.io/content/2.12/tasks/install-helm.md b/linkerd.io/content/2.12/tasks/install-helm.md
index 5df22b05c2..5e25072ecb 100644
--- a/linkerd.io/content/2.12/tasks/install-helm.md
+++ b/linkerd.io/content/2.12/tasks/install-helm.md
@@ -42,7 +42,7 @@ then `linkerd-control-plane`.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.12/tasks/install.md b/linkerd.io/content/2.12/tasks/install.md
index be571c39ef..baa1c8189e 100644
--- a/linkerd.io/content/2.12/tasks/install.md
+++ b/linkerd.io/content/2.12/tasks/install.md
@@ -46,7 +46,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.12/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/2.12/tasks/rotating_webhooks_certificates.md
index 6a866e3cb2..e37f48002a 100644
--- a/linkerd.io/content/2.12/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/2.12/tasks/rotating_webhooks_certificates.md
@@ -68,7 +68,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.12/tasks/setting-up-service-profiles.md b/linkerd.io/content/2.12/tasks/setting-up-service-profiles.md
index 8108dcbe90..ad19186f26 100644
--- a/linkerd.io/content/2.12/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/2.12/tasks/setting-up-service-profiles.md
@@ -9,7 +9,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 [per-route metrics](getting-per-route-metrics/), [retries](configuring-retries/)
 and [timeouts](configuring-timeouts/).
 
diff --git a/linkerd.io/content/2.12/tasks/troubleshooting.md b/linkerd.io/content/2.12/tasks/troubleshooting.md
index e8eaaa529c..d8e347ae62 100644
--- a/linkerd.io/content/2.12/tasks/troubleshooting.md
+++ b/linkerd.io/content/2.12/tasks/troubleshooting.md
@@ -647,7 +647,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
diff --git a/linkerd.io/content/2.12/tasks/uninstall.md b/linkerd.io/content/2.12/tasks/uninstall.md
index bf10a09044..cf58c367b4 100644
--- a/linkerd.io/content/2.12/tasks/uninstall.md
+++ b/linkerd.io/content/2.12/tasks/uninstall.md
@@ -34,7 +34,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.13/tasks/circuit-breakers.md b/linkerd.io/content/2.13/tasks/circuit-breakers.md
index d038ccf382..524e9fec5e 100644
--- a/linkerd.io/content/2.13/tasks/circuit-breakers.md
+++ b/linkerd.io/content/2.13/tasks/circuit-breakers.md
@@ -7,7 +7,7 @@ Circuit breaking is a powerful feature where Linkerd will temporarily stop
 routing requests to an endpoint if that endpoint is deemed to be unhealthy,
 instead routing that request to other replicas in the Service.
 
-In this tutoral, we'll see how to enable circuit breaking on a Service to
+In this tutorial, we'll see how to enable circuit breaking on a Service to
 improve client success rate when a backend replica is unhealthy.
 
 See the [reference documentation](../reference/circuit-breaking/) for more
@@ -217,7 +217,7 @@ failure accrual:
 
 This tells us that Linkerd will use `ConsecutiveFailures` failure accrual when
 talking to the `bb` Service. It also tells us that the `max_failures` is 7,
-meaning that it will trip the circuit breaker once it observes 7 consective
+meaning that it will trip the circuit breaker once it observes 7 consecutive
 failures. We'll talk more about each of the parameters here at the end of this
 article.
 
diff --git a/linkerd.io/content/2.13/tasks/generate-certificates.md b/linkerd.io/content/2.13/tasks/generate-certificates.md
index 33dd6751d1..cb43b52098 100644
--- a/linkerd.io/content/2.13/tasks/generate-certificates.md
+++ b/linkerd.io/content/2.13/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/2.13/tasks/grafana.md b/linkerd.io/content/2.13/tasks/grafana.md
index a30d3792e5..23753e783e 100644
--- a/linkerd.io/content/2.13/tasks/grafana.md
+++ b/linkerd.io/content/2.13/tasks/grafana.md
@@ -78,7 +78,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 
diff --git a/linkerd.io/content/2.13/tasks/install-helm.md b/linkerd.io/content/2.13/tasks/install-helm.md
index 5df22b05c2..5e25072ecb 100644
--- a/linkerd.io/content/2.13/tasks/install-helm.md
+++ b/linkerd.io/content/2.13/tasks/install-helm.md
@@ -42,7 +42,7 @@ then `linkerd-control-plane`.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.13/tasks/install.md b/linkerd.io/content/2.13/tasks/install.md
index be571c39ef..baa1c8189e 100644
--- a/linkerd.io/content/2.13/tasks/install.md
+++ b/linkerd.io/content/2.13/tasks/install.md
@@ -46,7 +46,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.13/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/2.13/tasks/rotating_webhooks_certificates.md
index 6a866e3cb2..e37f48002a 100644
--- a/linkerd.io/content/2.13/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/2.13/tasks/rotating_webhooks_certificates.md
@@ -68,7 +68,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.13/tasks/setting-up-service-profiles.md b/linkerd.io/content/2.13/tasks/setting-up-service-profiles.md
index 8108dcbe90..ad19186f26 100644
--- a/linkerd.io/content/2.13/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/2.13/tasks/setting-up-service-profiles.md
@@ -9,7 +9,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 [per-route metrics](getting-per-route-metrics/), [retries](configuring-retries/)
 and [timeouts](configuring-timeouts/).
 
diff --git a/linkerd.io/content/2.13/tasks/troubleshooting.md b/linkerd.io/content/2.13/tasks/troubleshooting.md
index e8eaaa529c..d8e347ae62 100644
--- a/linkerd.io/content/2.13/tasks/troubleshooting.md
+++ b/linkerd.io/content/2.13/tasks/troubleshooting.md
@@ -647,7 +647,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
diff --git a/linkerd.io/content/2.13/tasks/uninstall.md b/linkerd.io/content/2.13/tasks/uninstall.md
index bf10a09044..cf58c367b4 100644
--- a/linkerd.io/content/2.13/tasks/uninstall.md
+++ b/linkerd.io/content/2.13/tasks/uninstall.md
@@ -34,7 +34,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.13/tasks/using-ingress.md b/linkerd.io/content/2.13/tasks/using-ingress.md
index a2cd3e281b..92b1f77a10 100644
--- a/linkerd.io/content/2.13/tasks/using-ingress.md
+++ b/linkerd.io/content/2.13/tasks/using-ingress.md
@@ -282,8 +282,8 @@ spec:
 
 ## GCE
 
-The GCE ingress should be meshed with with
-[ingress mode enabled](#ingress-mode), , i.e. with the
+The GCE ingress should be meshed with
+[ingress mode enabled](#ingress-mode), i.e. with the
 `linkerd.io/inject: ingress` annotation rather than the default `enabled`.
 
 This example shows how to use a
diff --git a/linkerd.io/content/2.14/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.14/tasks/automatically-rotating-control-plane-tls-credentials.md
index 425dd65dad..de2ec39c1b 100644
--- a/linkerd.io/content/2.14/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.14/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -388,7 +388,7 @@ Almost done! We only need one more thing: the _trust bundle_ will lets Linkerd
 know which trust anchors to accept. We'll use trust-manager for this, but
 there's a catch: when rotating the trust anchor, both the control plane and the
 data plane (the proxies) need to be restarted. Since that can't happen
-instaneously, we need to have both the old trust anchor and the new trust anchor
+instantaneously, we need to have both the old trust anchor and the new trust anchor
 in the trust bundle until all the restarts have completed.
 
 trust-manager can do this, but it needs a specific source for _each_ certificate
diff --git a/linkerd.io/content/2.14/tasks/circuit-breakers.md b/linkerd.io/content/2.14/tasks/circuit-breakers.md
index d038ccf382..524e9fec5e 100644
--- a/linkerd.io/content/2.14/tasks/circuit-breakers.md
+++ b/linkerd.io/content/2.14/tasks/circuit-breakers.md
@@ -7,7 +7,7 @@ Circuit breaking is a powerful feature where Linkerd will temporarily stop
 routing requests to an endpoint if that endpoint is deemed to be unhealthy,
 instead routing that request to other replicas in the Service.
 
-In this tutoral, we'll see how to enable circuit breaking on a Service to
+In this tutorial, we'll see how to enable circuit breaking on a Service to
 improve client success rate when a backend replica is unhealthy.
 
 See the [reference documentation](../reference/circuit-breaking/) for more
@@ -217,7 +217,7 @@ failure accrual:
 
 This tells us that Linkerd will use `ConsecutiveFailures` failure accrual when
 talking to the `bb` Service. It also tells us that the `max_failures` is 7,
-meaning that it will trip the circuit breaker once it observes 7 consective
+meaning that it will trip the circuit breaker once it observes 7 consecutive
 failures. We'll talk more about each of the parameters here at the end of this
 article.
 
diff --git a/linkerd.io/content/2.14/tasks/generate-certificates.md b/linkerd.io/content/2.14/tasks/generate-certificates.md
index 33dd6751d1..cb43b52098 100644
--- a/linkerd.io/content/2.14/tasks/generate-certificates.md
+++ b/linkerd.io/content/2.14/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/2.14/tasks/grafana.md b/linkerd.io/content/2.14/tasks/grafana.md
index a30d3792e5..23753e783e 100644
--- a/linkerd.io/content/2.14/tasks/grafana.md
+++ b/linkerd.io/content/2.14/tasks/grafana.md
@@ -78,7 +78,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 
diff --git a/linkerd.io/content/2.14/tasks/install-helm.md b/linkerd.io/content/2.14/tasks/install-helm.md
index 5df22b05c2..5e25072ecb 100644
--- a/linkerd.io/content/2.14/tasks/install-helm.md
+++ b/linkerd.io/content/2.14/tasks/install-helm.md
@@ -42,7 +42,7 @@ then `linkerd-control-plane`.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.14/tasks/install.md b/linkerd.io/content/2.14/tasks/install.md
index 0923182020..a1fa00c758 100644
--- a/linkerd.io/content/2.14/tasks/install.md
+++ b/linkerd.io/content/2.14/tasks/install.md
@@ -49,7 +49,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.14/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/2.14/tasks/rotating_webhooks_certificates.md
index 6a866e3cb2..e37f48002a 100644
--- a/linkerd.io/content/2.14/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/2.14/tasks/rotating_webhooks_certificates.md
@@ -68,7 +68,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.14/tasks/setting-up-service-profiles.md b/linkerd.io/content/2.14/tasks/setting-up-service-profiles.md
index 8108dcbe90..ad19186f26 100644
--- a/linkerd.io/content/2.14/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/2.14/tasks/setting-up-service-profiles.md
@@ -9,7 +9,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 [per-route metrics](getting-per-route-metrics/), [retries](configuring-retries/)
 and [timeouts](configuring-timeouts/).
 
diff --git a/linkerd.io/content/2.14/tasks/troubleshooting.md b/linkerd.io/content/2.14/tasks/troubleshooting.md
index e8eaaa529c..d8e347ae62 100644
--- a/linkerd.io/content/2.14/tasks/troubleshooting.md
+++ b/linkerd.io/content/2.14/tasks/troubleshooting.md
@@ -647,7 +647,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
diff --git a/linkerd.io/content/2.14/tasks/uninstall.md b/linkerd.io/content/2.14/tasks/uninstall.md
index bf10a09044..cf58c367b4 100644
--- a/linkerd.io/content/2.14/tasks/uninstall.md
+++ b/linkerd.io/content/2.14/tasks/uninstall.md
@@ -34,7 +34,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.14/tasks/using-ingress.md b/linkerd.io/content/2.14/tasks/using-ingress.md
index a7dbddd7ae..fffde8273b 100644
--- a/linkerd.io/content/2.14/tasks/using-ingress.md
+++ b/linkerd.io/content/2.14/tasks/using-ingress.md
@@ -324,8 +324,8 @@ spec:
 
 ## GCE
 
-The GCE ingress should be meshed with with
-[ingress mode enabled](#ingress-mode), , i.e. with the
+The GCE ingress should be meshed with
+[ingress mode enabled](#ingress-mode), i.e. with the
 `linkerd.io/inject: ingress` annotation rather than the default `enabled`.
 
 This example shows how to use a
diff --git a/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
index 425dd65dad..de2ec39c1b 100644
--- a/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -388,7 +388,7 @@ Almost done! We only need one more thing: the _trust bundle_ will lets Linkerd
 know which trust anchors to accept. We'll use trust-manager for this, but
 there's a catch: when rotating the trust anchor, both the control plane and the
 data plane (the proxies) need to be restarted. Since that can't happen
-instaneously, we need to have both the old trust anchor and the new trust anchor
+instantaneously, we need to have both the old trust anchor and the new trust anchor
 in the trust bundle until all the restarts have completed.
 
 trust-manager can do this, but it needs a specific source for _each_ certificate
diff --git a/linkerd.io/content/2.15/tasks/circuit-breakers.md b/linkerd.io/content/2.15/tasks/circuit-breakers.md
index d038ccf382..524e9fec5e 100644
--- a/linkerd.io/content/2.15/tasks/circuit-breakers.md
+++ b/linkerd.io/content/2.15/tasks/circuit-breakers.md
@@ -7,7 +7,7 @@ Circuit breaking is a powerful feature where Linkerd will temporarily stop
 routing requests to an endpoint if that endpoint is deemed to be unhealthy,
 instead routing that request to other replicas in the Service.
 
-In this tutoral, we'll see how to enable circuit breaking on a Service to
+In this tutorial, we'll see how to enable circuit breaking on a Service to
 improve client success rate when a backend replica is unhealthy.
 
 See the [reference documentation](../reference/circuit-breaking/) for more
@@ -217,7 +217,7 @@ failure accrual:
 
 This tells us that Linkerd will use `ConsecutiveFailures` failure accrual when
 talking to the `bb` Service. It also tells us that the `max_failures` is 7,
-meaning that it will trip the circuit breaker once it observes 7 consective
+meaning that it will trip the circuit breaker once it observes 7 consecutive
 failures. We'll talk more about each of the parameters here at the end of this
 article.
 
diff --git a/linkerd.io/content/2.15/tasks/generate-certificates.md b/linkerd.io/content/2.15/tasks/generate-certificates.md
index 33dd6751d1..cb43b52098 100644
--- a/linkerd.io/content/2.15/tasks/generate-certificates.md
+++ b/linkerd.io/content/2.15/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/2.15/tasks/grafana.md b/linkerd.io/content/2.15/tasks/grafana.md
index 9be0209fbb..46aa37e1e3 100644
--- a/linkerd.io/content/2.15/tasks/grafana.md
+++ b/linkerd.io/content/2.15/tasks/grafana.md
@@ -78,7 +78,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 
diff --git a/linkerd.io/content/2.15/tasks/install-helm.md b/linkerd.io/content/2.15/tasks/install-helm.md
index d9ae6e768b..16a83a1898 100644
--- a/linkerd.io/content/2.15/tasks/install-helm.md
+++ b/linkerd.io/content/2.15/tasks/install-helm.md
@@ -33,7 +33,7 @@ then `linkerd-control-plane`.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.15/tasks/install.md b/linkerd.io/content/2.15/tasks/install.md
index a0ad854e96..7cc4488737 100644
--- a/linkerd.io/content/2.15/tasks/install.md
+++ b/linkerd.io/content/2.15/tasks/install.md
@@ -59,7 +59,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.15/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/2.15/tasks/rotating_webhooks_certificates.md
index 6a866e3cb2..e37f48002a 100644
--- a/linkerd.io/content/2.15/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/2.15/tasks/rotating_webhooks_certificates.md
@@ -68,7 +68,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.15/tasks/setting-up-service-profiles.md b/linkerd.io/content/2.15/tasks/setting-up-service-profiles.md
index 8108dcbe90..ad19186f26 100644
--- a/linkerd.io/content/2.15/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/2.15/tasks/setting-up-service-profiles.md
@@ -9,7 +9,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 [per-route metrics](getting-per-route-metrics/), [retries](configuring-retries/)
 and [timeouts](configuring-timeouts/).
 
diff --git a/linkerd.io/content/2.15/tasks/troubleshooting.md b/linkerd.io/content/2.15/tasks/troubleshooting.md
index 0f92c96332..4f9859b350 100644
--- a/linkerd.io/content/2.15/tasks/troubleshooting.md
+++ b/linkerd.io/content/2.15/tasks/troubleshooting.md
@@ -647,7 +647,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
diff --git a/linkerd.io/content/2.15/tasks/uninstall.md b/linkerd.io/content/2.15/tasks/uninstall.md
index bf10a09044..cf58c367b4 100644
--- a/linkerd.io/content/2.15/tasks/uninstall.md
+++ b/linkerd.io/content/2.15/tasks/uninstall.md
@@ -34,7 +34,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.15/tasks/using-ingress.md b/linkerd.io/content/2.15/tasks/using-ingress.md
index 30a1d9a0ca..5408590117 100644
--- a/linkerd.io/content/2.15/tasks/using-ingress.md
+++ b/linkerd.io/content/2.15/tasks/using-ingress.md
@@ -332,8 +332,8 @@ spec:
 
 ## GCE
 
-The GCE ingress should be meshed with with
-[ingress mode enabled](#ingress-mode), , i.e. with the
+The GCE ingress should be meshed with
+[ingress mode enabled](#ingress-mode), i.e. with the
 `linkerd.io/inject: ingress` annotation rather than the default `enabled`.
 
 This example shows how to use a
diff --git a/linkerd.io/content/2.16/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.16/tasks/automatically-rotating-control-plane-tls-credentials.md
index be6105ac54..8297c57129 100644
--- a/linkerd.io/content/2.16/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.16/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -388,7 +388,7 @@ Almost done! We only need one more thing: the _trust bundle_ will lets Linkerd
 know which trust anchors to accept. We'll use trust-manager for this, but
 there's a catch: when rotating the trust anchor, both the control plane and the
 data plane (the proxies) need to be restarted. Since that can't happen
-instaneously, we need to have both the old trust anchor and the new trust anchor
+instantaneously, we need to have both the old trust anchor and the new trust anchor
 in the trust bundle until all the restarts have completed.
 
 trust-manager can do this, but it needs a specific source for _each_ certificate
diff --git a/linkerd.io/content/2.16/tasks/circuit-breakers.md b/linkerd.io/content/2.16/tasks/circuit-breakers.md
index d038ccf382..524e9fec5e 100644
--- a/linkerd.io/content/2.16/tasks/circuit-breakers.md
+++ b/linkerd.io/content/2.16/tasks/circuit-breakers.md
@@ -7,7 +7,7 @@ Circuit breaking is a powerful feature where Linkerd will temporarily stop
 routing requests to an endpoint if that endpoint is deemed to be unhealthy,
 instead routing that request to other replicas in the Service.
 
-In this tutoral, we'll see how to enable circuit breaking on a Service to
+In this tutorial, we'll see how to enable circuit breaking on a Service to
 improve client success rate when a backend replica is unhealthy.
 
 See the [reference documentation](../reference/circuit-breaking/) for more
@@ -217,7 +217,7 @@ failure accrual:
 
 This tells us that Linkerd will use `ConsecutiveFailures` failure accrual when
 talking to the `bb` Service. It also tells us that the `max_failures` is 7,
-meaning that it will trip the circuit breaker once it observes 7 consective
+meaning that it will trip the circuit breaker once it observes 7 consecutive
 failures. We'll talk more about each of the parameters here at the end of this
 article.
 
diff --git a/linkerd.io/content/2.16/tasks/configuring-dynamic-request-routing.md b/linkerd.io/content/2.16/tasks/configuring-dynamic-request-routing.md
index 004b50ded6..32186af1ff 100644
--- a/linkerd.io/content/2.16/tasks/configuring-dynamic-request-routing.md
+++ b/linkerd.io/content/2.16/tasks/configuring-dynamic-request-routing.md
@@ -156,7 +156,7 @@ In the example above, we used the `x-request-id` header, which is a common
 header that is forwarded by podinfo. However, the same technique will work with
 arbitrary headers, as long as the application forwards them.
 
-Note also that dyanmic request routing is client-side behavior, so while the
+Note also that dynamic request routing is client-side behavior, so while the
 traffic source (in this case, the frontend pod) needs to be meshed, strictly
 speaking, the destination does not need to be meshed.
 
diff --git a/linkerd.io/content/2.16/tasks/generate-certificates.md b/linkerd.io/content/2.16/tasks/generate-certificates.md
index 33dd6751d1..cb43b52098 100644
--- a/linkerd.io/content/2.16/tasks/generate-certificates.md
+++ b/linkerd.io/content/2.16/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/2.16/tasks/grafana.md b/linkerd.io/content/2.16/tasks/grafana.md
index a30d3792e5..23753e783e 100644
--- a/linkerd.io/content/2.16/tasks/grafana.md
+++ b/linkerd.io/content/2.16/tasks/grafana.md
@@ -78,7 +78,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 
diff --git a/linkerd.io/content/2.16/tasks/install-helm.md b/linkerd.io/content/2.16/tasks/install-helm.md
index d9ae6e768b..16a83a1898 100644
--- a/linkerd.io/content/2.16/tasks/install-helm.md
+++ b/linkerd.io/content/2.16/tasks/install-helm.md
@@ -33,7 +33,7 @@ then `linkerd-control-plane`.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.16/tasks/install.md b/linkerd.io/content/2.16/tasks/install.md
index a0ad854e96..7cc4488737 100644
--- a/linkerd.io/content/2.16/tasks/install.md
+++ b/linkerd.io/content/2.16/tasks/install.md
@@ -59,7 +59,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.16/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/2.16/tasks/rotating_webhooks_certificates.md
index 6a866e3cb2..e37f48002a 100644
--- a/linkerd.io/content/2.16/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/2.16/tasks/rotating_webhooks_certificates.md
@@ -68,7 +68,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.16/tasks/setting-up-service-profiles.md b/linkerd.io/content/2.16/tasks/setting-up-service-profiles.md
index be9284058e..0c15421ba4 100644
--- a/linkerd.io/content/2.16/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/2.16/tasks/setting-up-service-profiles.md
@@ -19,7 +19,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 per-route metric, retries, and timeouts.
 
 The `destination service` for a request is computed by selecting the value of
diff --git a/linkerd.io/content/2.16/tasks/traffic-shifting.md b/linkerd.io/content/2.16/tasks/traffic-shifting.md
index 1091aa6198..4525d5fa8f 100644
--- a/linkerd.io/content/2.16/tasks/traffic-shifting.md
+++ b/linkerd.io/content/2.16/tasks/traffic-shifting.md
@@ -14,8 +14,8 @@ Traffic splitting is accomplished with [HTTPRoute] and [GRPCRoute] types.
 
 Earlier versions of Linkerd provided a
 [TrafficSplit](https://github.com/servicemeshinterface/smi-spec/blob/main/apis/traffic-split/v1alpha2/traffic-split.md/)
-resource as part of the the [Linkerd SMI extension](linkerd-smi/) for traffic
-splitting. This approach is still supported but will not recieve further feature
+resource as part of the [Linkerd SMI extension](linkerd-smi/) for traffic
+splitting. This approach is still supported but will not receive further feature
 development.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.16/tasks/troubleshooting.md b/linkerd.io/content/2.16/tasks/troubleshooting.md
index 0f92c96332..4f9859b350 100644
--- a/linkerd.io/content/2.16/tasks/troubleshooting.md
+++ b/linkerd.io/content/2.16/tasks/troubleshooting.md
@@ -647,7 +647,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
diff --git a/linkerd.io/content/2.16/tasks/uninstall.md b/linkerd.io/content/2.16/tasks/uninstall.md
index bf10a09044..cf58c367b4 100644
--- a/linkerd.io/content/2.16/tasks/uninstall.md
+++ b/linkerd.io/content/2.16/tasks/uninstall.md
@@ -34,7 +34,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.16/tasks/using-ingress.md b/linkerd.io/content/2.16/tasks/using-ingress.md
index 5a0c151050..241eafdb3d 100644
--- a/linkerd.io/content/2.16/tasks/using-ingress.md
+++ b/linkerd.io/content/2.16/tasks/using-ingress.md
@@ -303,8 +303,8 @@ Traefik's load balancing with weights is not compatible with explicit headers.
 
 ## GCE
 
-The GCE ingress should be meshed with with
-[ingress mode enabled](#ingress-mode), , i.e. with the
+The GCE ingress should be meshed with
+[ingress mode enabled](#ingress-mode), i.e. with the
 `linkerd.io/inject: ingress` annotation rather than the default `enabled`.
 
 This example shows how to use a
diff --git a/linkerd.io/content/2.17/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.17/tasks/automatically-rotating-control-plane-tls-credentials.md
index 425dd65dad..de2ec39c1b 100644
--- a/linkerd.io/content/2.17/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.17/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -388,7 +388,7 @@ Almost done! We only need one more thing: the _trust bundle_ will lets Linkerd
 know which trust anchors to accept. We'll use trust-manager for this, but
 there's a catch: when rotating the trust anchor, both the control plane and the
 data plane (the proxies) need to be restarted. Since that can't happen
-instaneously, we need to have both the old trust anchor and the new trust anchor
+instantaneously, we need to have both the old trust anchor and the new trust anchor
 in the trust bundle until all the restarts have completed.
 
 trust-manager can do this, but it needs a specific source for _each_ certificate
diff --git a/linkerd.io/content/2.17/tasks/circuit-breakers.md b/linkerd.io/content/2.17/tasks/circuit-breakers.md
index d038ccf382..524e9fec5e 100644
--- a/linkerd.io/content/2.17/tasks/circuit-breakers.md
+++ b/linkerd.io/content/2.17/tasks/circuit-breakers.md
@@ -7,7 +7,7 @@ Circuit breaking is a powerful feature where Linkerd will temporarily stop
 routing requests to an endpoint if that endpoint is deemed to be unhealthy,
 instead routing that request to other replicas in the Service.
 
-In this tutoral, we'll see how to enable circuit breaking on a Service to
+In this tutorial, we'll see how to enable circuit breaking on a Service to
 improve client success rate when a backend replica is unhealthy.
 
 See the [reference documentation](../reference/circuit-breaking/) for more
@@ -217,7 +217,7 @@ failure accrual:
 
 This tells us that Linkerd will use `ConsecutiveFailures` failure accrual when
 talking to the `bb` Service. It also tells us that the `max_failures` is 7,
-meaning that it will trip the circuit breaker once it observes 7 consective
+meaning that it will trip the circuit breaker once it observes 7 consecutive
 failures. We'll talk more about each of the parameters here at the end of this
 article.
 
diff --git a/linkerd.io/content/2.17/tasks/configuring-dynamic-request-routing.md b/linkerd.io/content/2.17/tasks/configuring-dynamic-request-routing.md
index 004b50ded6..32186af1ff 100644
--- a/linkerd.io/content/2.17/tasks/configuring-dynamic-request-routing.md
+++ b/linkerd.io/content/2.17/tasks/configuring-dynamic-request-routing.md
@@ -156,7 +156,7 @@ In the example above, we used the `x-request-id` header, which is a common
 header that is forwarded by podinfo. However, the same technique will work with
 arbitrary headers, as long as the application forwards them.
 
-Note also that dyanmic request routing is client-side behavior, so while the
+Note also that dynamic request routing is client-side behavior, so while the
 traffic source (in this case, the frontend pod) needs to be meshed, strictly
 speaking, the destination does not need to be meshed.
 
diff --git a/linkerd.io/content/2.17/tasks/federated-services.md b/linkerd.io/content/2.17/tasks/federated-services.md
index 3aa08fde70..529e7fe110 100644
--- a/linkerd.io/content/2.17/tasks/federated-services.md
+++ b/linkerd.io/content/2.17/tasks/federated-services.md
@@ -8,7 +8,7 @@ which act as a union of multiple services in different clusters with the same
 name and namespace. By sending traffic to the federated service, that traffic
 will be load balanced among all endpoints of that service in all linked
 clusters. This allows the client to be cluster agnostic, balance traffic across
-multiple clusters, and be resiliant to the failure of any individual cluster.
+multiple clusters, and be resilient to the failure of any individual cluster.
 
 Federated services send traffic directly to the pods of the member services
 rather than through a gateway. Therefore, federated services have the same
@@ -358,7 +358,7 @@ is distributing requests across all three clusters:
 
 ## Next Steps
 
-We now have a federated service that balances traffic accross services in three
+We now have a federated service that balances traffic across services in three
 clusters. Additional clusters can be added simply by linking the new cluster and
 adding the `mirror.linkerd.io/federated=member` label to the services that you
 wish to add to the federated service. Similarly, services can be removed from
diff --git a/linkerd.io/content/2.17/tasks/generate-certificates.md b/linkerd.io/content/2.17/tasks/generate-certificates.md
index 33dd6751d1..cb43b52098 100644
--- a/linkerd.io/content/2.17/tasks/generate-certificates.md
+++ b/linkerd.io/content/2.17/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/2.17/tasks/grafana.md b/linkerd.io/content/2.17/tasks/grafana.md
index a30d3792e5..23753e783e 100644
--- a/linkerd.io/content/2.17/tasks/grafana.md
+++ b/linkerd.io/content/2.17/tasks/grafana.md
@@ -78,7 +78,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 
diff --git a/linkerd.io/content/2.17/tasks/install-helm.md b/linkerd.io/content/2.17/tasks/install-helm.md
index d9ae6e768b..16a83a1898 100644
--- a/linkerd.io/content/2.17/tasks/install-helm.md
+++ b/linkerd.io/content/2.17/tasks/install-helm.md
@@ -33,7 +33,7 @@ then `linkerd-control-plane`.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.17/tasks/install.md b/linkerd.io/content/2.17/tasks/install.md
index a0ad854e96..7cc4488737 100644
--- a/linkerd.io/content/2.17/tasks/install.md
+++ b/linkerd.io/content/2.17/tasks/install.md
@@ -59,7 +59,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.17/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/2.17/tasks/rotating_webhooks_certificates.md
index 6a866e3cb2..e37f48002a 100644
--- a/linkerd.io/content/2.17/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/2.17/tasks/rotating_webhooks_certificates.md
@@ -68,7 +68,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.17/tasks/setting-up-service-profiles.md b/linkerd.io/content/2.17/tasks/setting-up-service-profiles.md
index be9284058e..0c15421ba4 100644
--- a/linkerd.io/content/2.17/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/2.17/tasks/setting-up-service-profiles.md
@@ -19,7 +19,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 per-route metric, retries, and timeouts.
 
 The `destination service` for a request is computed by selecting the value of
diff --git a/linkerd.io/content/2.17/tasks/traffic-shifting.md b/linkerd.io/content/2.17/tasks/traffic-shifting.md
index 1091aa6198..4525d5fa8f 100644
--- a/linkerd.io/content/2.17/tasks/traffic-shifting.md
+++ b/linkerd.io/content/2.17/tasks/traffic-shifting.md
@@ -14,8 +14,8 @@ Traffic splitting is accomplished with [HTTPRoute] and [GRPCRoute] types.
 
 Earlier versions of Linkerd provided a
 [TrafficSplit](https://github.com/servicemeshinterface/smi-spec/blob/main/apis/traffic-split/v1alpha2/traffic-split.md/)
-resource as part of the the [Linkerd SMI extension](linkerd-smi/) for traffic
-splitting. This approach is still supported but will not recieve further feature
+resource as part of the [Linkerd SMI extension](linkerd-smi/) for traffic
+splitting. This approach is still supported but will not receive further feature
 development.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.17/tasks/troubleshooting.md b/linkerd.io/content/2.17/tasks/troubleshooting.md
index 3aff757380..32abe8687a 100644
--- a/linkerd.io/content/2.17/tasks/troubleshooting.md
+++ b/linkerd.io/content/2.17/tasks/troubleshooting.md
@@ -647,7 +647,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
@@ -1097,7 +1097,7 @@ triggered if an extension value is used for the label key more than once across
 the cluster.
 
 To resolve this warning, ensure that the `linkerd.io/extension` namespace label
-does not have any dupliate values, indicating that an extension has been
+does not have any duplicate values, indicating that an extension has been
 installed more than once in different namespaces.
 
 ### Extensions checks
diff --git a/linkerd.io/content/2.17/tasks/uninstall.md b/linkerd.io/content/2.17/tasks/uninstall.md
index bf10a09044..cf58c367b4 100644
--- a/linkerd.io/content/2.17/tasks/uninstall.md
+++ b/linkerd.io/content/2.17/tasks/uninstall.md
@@ -34,7 +34,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.17/tasks/using-ingress.md b/linkerd.io/content/2.17/tasks/using-ingress.md
index 30a1d9a0ca..5408590117 100644
--- a/linkerd.io/content/2.17/tasks/using-ingress.md
+++ b/linkerd.io/content/2.17/tasks/using-ingress.md
@@ -332,8 +332,8 @@ spec:
 
 ## GCE
 
-The GCE ingress should be meshed with with
-[ingress mode enabled](#ingress-mode), , i.e. with the
+The GCE ingress should be meshed with
+[ingress mode enabled](#ingress-mode), i.e. with the
 `linkerd.io/inject: ingress` annotation rather than the default `enabled`.
 
 This example shows how to use a
diff --git a/linkerd.io/content/2.18/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.18/tasks/automatically-rotating-control-plane-tls-credentials.md
index 425dd65dad..de2ec39c1b 100644
--- a/linkerd.io/content/2.18/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.18/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -388,7 +388,7 @@ Almost done! We only need one more thing: the _trust bundle_ will lets Linkerd
 know which trust anchors to accept. We'll use trust-manager for this, but
 there's a catch: when rotating the trust anchor, both the control plane and the
 data plane (the proxies) need to be restarted. Since that can't happen
-instaneously, we need to have both the old trust anchor and the new trust anchor
+instantaneously, we need to have both the old trust anchor and the new trust anchor
 in the trust bundle until all the restarts have completed.
 
 trust-manager can do this, but it needs a specific source for _each_ certificate
diff --git a/linkerd.io/content/2.18/tasks/circuit-breakers.md b/linkerd.io/content/2.18/tasks/circuit-breakers.md
index d038ccf382..524e9fec5e 100644
--- a/linkerd.io/content/2.18/tasks/circuit-breakers.md
+++ b/linkerd.io/content/2.18/tasks/circuit-breakers.md
@@ -7,7 +7,7 @@ Circuit breaking is a powerful feature where Linkerd will temporarily stop
 routing requests to an endpoint if that endpoint is deemed to be unhealthy,
 instead routing that request to other replicas in the Service.
 
-In this tutoral, we'll see how to enable circuit breaking on a Service to
+In this tutorial, we'll see how to enable circuit breaking on a Service to
 improve client success rate when a backend replica is unhealthy.
 
 See the [reference documentation](../reference/circuit-breaking/) for more
@@ -217,7 +217,7 @@ failure accrual:
 
 This tells us that Linkerd will use `ConsecutiveFailures` failure accrual when
 talking to the `bb` Service. It also tells us that the `max_failures` is 7,
-meaning that it will trip the circuit breaker once it observes 7 consective
+meaning that it will trip the circuit breaker once it observes 7 consecutive
 failures. We'll talk more about each of the parameters here at the end of this
 article.
 
diff --git a/linkerd.io/content/2.18/tasks/configuring-dynamic-request-routing.md b/linkerd.io/content/2.18/tasks/configuring-dynamic-request-routing.md
index 004b50ded6..32186af1ff 100644
--- a/linkerd.io/content/2.18/tasks/configuring-dynamic-request-routing.md
+++ b/linkerd.io/content/2.18/tasks/configuring-dynamic-request-routing.md
@@ -156,7 +156,7 @@ In the example above, we used the `x-request-id` header, which is a common
 header that is forwarded by podinfo. However, the same technique will work with
 arbitrary headers, as long as the application forwards them.
 
-Note also that dyanmic request routing is client-side behavior, so while the
+Note also that dynamic request routing is client-side behavior, so while the
 traffic source (in this case, the frontend pod) needs to be meshed, strictly
 speaking, the destination does not need to be meshed.
 
diff --git a/linkerd.io/content/2.18/tasks/federated-services.md b/linkerd.io/content/2.18/tasks/federated-services.md
index 73487c1b9c..0ae2bedeca 100644
--- a/linkerd.io/content/2.18/tasks/federated-services.md
+++ b/linkerd.io/content/2.18/tasks/federated-services.md
@@ -8,7 +8,7 @@ which act as a union of multiple services in different clusters with the same
 name and namespace. By sending traffic to the federated service, that traffic
 will be load balanced among all endpoints of that service in all linked
 clusters. This allows the client to be cluster agnostic, balance traffic across
-multiple clusters, and be resiliant to the failure of any individual cluster.
+multiple clusters, and be resilient to the failure of any individual cluster.
 
 Federated services send traffic directly to the pods of the member services
 rather than through a gateway. Therefore, federated services have the same
@@ -362,7 +362,7 @@ is distributing requests across all three clusters:
 
 ## Next Steps
 
-We now have a federated service that balances traffic accross services in three
+We now have a federated service that balances traffic across services in three
 clusters. Additional clusters can be added simply by:
 
 - Updating the linkerd-multicluster config in `west` to add the required
diff --git a/linkerd.io/content/2.18/tasks/generate-certificates.md b/linkerd.io/content/2.18/tasks/generate-certificates.md
index 33dd6751d1..cb43b52098 100644
--- a/linkerd.io/content/2.18/tasks/generate-certificates.md
+++ b/linkerd.io/content/2.18/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/2.18/tasks/grafana.md b/linkerd.io/content/2.18/tasks/grafana.md
index 9be0209fbb..46aa37e1e3 100644
--- a/linkerd.io/content/2.18/tasks/grafana.md
+++ b/linkerd.io/content/2.18/tasks/grafana.md
@@ -78,7 +78,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 
diff --git a/linkerd.io/content/2.18/tasks/install-helm.md b/linkerd.io/content/2.18/tasks/install-helm.md
index 46970a8825..bd0d65505c 100644
--- a/linkerd.io/content/2.18/tasks/install-helm.md
+++ b/linkerd.io/content/2.18/tasks/install-helm.md
@@ -33,7 +33,7 @@ then `linkerd-control-plane`.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.18/tasks/install.md b/linkerd.io/content/2.18/tasks/install.md
index a0ad854e96..7cc4488737 100644
--- a/linkerd.io/content/2.18/tasks/install.md
+++ b/linkerd.io/content/2.18/tasks/install.md
@@ -59,7 +59,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.18/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/2.18/tasks/rotating_webhooks_certificates.md
index 6a866e3cb2..e37f48002a 100644
--- a/linkerd.io/content/2.18/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/2.18/tasks/rotating_webhooks_certificates.md
@@ -68,7 +68,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.18/tasks/setting-up-service-profiles.md b/linkerd.io/content/2.18/tasks/setting-up-service-profiles.md
index be9284058e..0c15421ba4 100644
--- a/linkerd.io/content/2.18/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/2.18/tasks/setting-up-service-profiles.md
@@ -19,7 +19,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 per-route metric, retries, and timeouts.
 
 The `destination service` for a request is computed by selecting the value of
diff --git a/linkerd.io/content/2.18/tasks/traffic-shifting.md b/linkerd.io/content/2.18/tasks/traffic-shifting.md
index 1091aa6198..4525d5fa8f 100644
--- a/linkerd.io/content/2.18/tasks/traffic-shifting.md
+++ b/linkerd.io/content/2.18/tasks/traffic-shifting.md
@@ -14,8 +14,8 @@ Traffic splitting is accomplished with [HTTPRoute] and [GRPCRoute] types.
 
 Earlier versions of Linkerd provided a
 [TrafficSplit](https://github.com/servicemeshinterface/smi-spec/blob/main/apis/traffic-split/v1alpha2/traffic-split.md/)
-resource as part of the the [Linkerd SMI extension](linkerd-smi/) for traffic
-splitting. This approach is still supported but will not recieve further feature
+resource as part of the [Linkerd SMI extension](linkerd-smi/) for traffic
+splitting. This approach is still supported but will not receive further feature
 development.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.18/tasks/troubleshooting.md b/linkerd.io/content/2.18/tasks/troubleshooting.md
index 776fe811ab..510d04498e 100644
--- a/linkerd.io/content/2.18/tasks/troubleshooting.md
+++ b/linkerd.io/content/2.18/tasks/troubleshooting.md
@@ -647,7 +647,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
@@ -1097,7 +1097,7 @@ triggered if an extension value is used for the label key more than once across
 the cluster.
 
 To resolve this warning, ensure that the `linkerd.io/extension` namespace label
-does not have any dupliate values, indicating that an extension has been
+does not have any duplicate values, indicating that an extension has been
 installed more than once in different namespaces.
 
 ### Extensions checks
diff --git a/linkerd.io/content/2.18/tasks/uninstall.md b/linkerd.io/content/2.18/tasks/uninstall.md
index bf10a09044..cf58c367b4 100644
--- a/linkerd.io/content/2.18/tasks/uninstall.md
+++ b/linkerd.io/content/2.18/tasks/uninstall.md
@@ -34,7 +34,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.18/tasks/using-ingress.md b/linkerd.io/content/2.18/tasks/using-ingress.md
index 618c00d615..0d9468aa23 100644
--- a/linkerd.io/content/2.18/tasks/using-ingress.md
+++ b/linkerd.io/content/2.18/tasks/using-ingress.md
@@ -333,8 +333,8 @@ spec:
 
 ## GCE
 
-The GCE ingress should be meshed with with
-[ingress mode enabled](#ingress-mode), , i.e. with the
+The GCE ingress should be meshed with
+[ingress mode enabled](#ingress-mode), i.e. with the
 `linkerd.io/inject: ingress` annotation rather than the default `enabled`.
 
 This example shows how to use a
diff --git a/linkerd.io/content/2.19/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.19/tasks/automatically-rotating-control-plane-tls-credentials.md
index 425dd65dad..de2ec39c1b 100644
--- a/linkerd.io/content/2.19/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.19/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -388,7 +388,7 @@ Almost done! We only need one more thing: the _trust bundle_ will lets Linkerd
 know which trust anchors to accept. We'll use trust-manager for this, but
 there's a catch: when rotating the trust anchor, both the control plane and the
 data plane (the proxies) need to be restarted. Since that can't happen
-instaneously, we need to have both the old trust anchor and the new trust anchor
+instantaneously, we need to have both the old trust anchor and the new trust anchor
 in the trust bundle until all the restarts have completed.
 
 trust-manager can do this, but it needs a specific source for _each_ certificate
diff --git a/linkerd.io/content/2.19/tasks/circuit-breakers.md b/linkerd.io/content/2.19/tasks/circuit-breakers.md
index d038ccf382..524e9fec5e 100644
--- a/linkerd.io/content/2.19/tasks/circuit-breakers.md
+++ b/linkerd.io/content/2.19/tasks/circuit-breakers.md
@@ -7,7 +7,7 @@ Circuit breaking is a powerful feature where Linkerd will temporarily stop
 routing requests to an endpoint if that endpoint is deemed to be unhealthy,
 instead routing that request to other replicas in the Service.
 
-In this tutoral, we'll see how to enable circuit breaking on a Service to
+In this tutorial, we'll see how to enable circuit breaking on a Service to
 improve client success rate when a backend replica is unhealthy.
 
 See the [reference documentation](../reference/circuit-breaking/) for more
@@ -217,7 +217,7 @@ failure accrual:
 
 This tells us that Linkerd will use `ConsecutiveFailures` failure accrual when
 talking to the `bb` Service. It also tells us that the `max_failures` is 7,
-meaning that it will trip the circuit breaker once it observes 7 consective
+meaning that it will trip the circuit breaker once it observes 7 consecutive
 failures. We'll talk more about each of the parameters here at the end of this
 article.
 
diff --git a/linkerd.io/content/2.19/tasks/configuring-dynamic-request-routing.md b/linkerd.io/content/2.19/tasks/configuring-dynamic-request-routing.md
index 004b50ded6..32186af1ff 100644
--- a/linkerd.io/content/2.19/tasks/configuring-dynamic-request-routing.md
+++ b/linkerd.io/content/2.19/tasks/configuring-dynamic-request-routing.md
@@ -156,7 +156,7 @@ In the example above, we used the `x-request-id` header, which is a common
 header that is forwarded by podinfo. However, the same technique will work with
 arbitrary headers, as long as the application forwards them.
 
-Note also that dyanmic request routing is client-side behavior, so while the
+Note also that dynamic request routing is client-side behavior, so while the
 traffic source (in this case, the frontend pod) needs to be meshed, strictly
 speaking, the destination does not need to be meshed.
 
diff --git a/linkerd.io/content/2.19/tasks/federated-services.md b/linkerd.io/content/2.19/tasks/federated-services.md
index 73487c1b9c..0ae2bedeca 100644
--- a/linkerd.io/content/2.19/tasks/federated-services.md
+++ b/linkerd.io/content/2.19/tasks/federated-services.md
@@ -8,7 +8,7 @@ which act as a union of multiple services in different clusters with the same
 name and namespace. By sending traffic to the federated service, that traffic
 will be load balanced among all endpoints of that service in all linked
 clusters. This allows the client to be cluster agnostic, balance traffic across
-multiple clusters, and be resiliant to the failure of any individual cluster.
+multiple clusters, and be resilient to the failure of any individual cluster.
 
 Federated services send traffic directly to the pods of the member services
 rather than through a gateway. Therefore, federated services have the same
@@ -362,7 +362,7 @@ is distributing requests across all three clusters:
 
 ## Next Steps
 
-We now have a federated service that balances traffic accross services in three
+We now have a federated service that balances traffic across services in three
 clusters. Additional clusters can be added simply by:
 
 - Updating the linkerd-multicluster config in `west` to add the required
diff --git a/linkerd.io/content/2.19/tasks/generate-certificates.md b/linkerd.io/content/2.19/tasks/generate-certificates.md
index 33dd6751d1..cb43b52098 100644
--- a/linkerd.io/content/2.19/tasks/generate-certificates.md
+++ b/linkerd.io/content/2.19/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/2.19/tasks/grafana.md b/linkerd.io/content/2.19/tasks/grafana.md
index 9be0209fbb..46aa37e1e3 100644
--- a/linkerd.io/content/2.19/tasks/grafana.md
+++ b/linkerd.io/content/2.19/tasks/grafana.md
@@ -78,7 +78,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 
diff --git a/linkerd.io/content/2.19/tasks/install-helm.md b/linkerd.io/content/2.19/tasks/install-helm.md
index 5f31f1d3a9..014e3be9ff 100644
--- a/linkerd.io/content/2.19/tasks/install-helm.md
+++ b/linkerd.io/content/2.19/tasks/install-helm.md
@@ -43,7 +43,7 @@ then `linkerd-control-plane`.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.19/tasks/install.md b/linkerd.io/content/2.19/tasks/install.md
index 0eaf611bd3..c42b3af035 100644
--- a/linkerd.io/content/2.19/tasks/install.md
+++ b/linkerd.io/content/2.19/tasks/install.md
@@ -66,7 +66,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.19/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/2.19/tasks/rotating_webhooks_certificates.md
index 3784403a60..834ce27399 100644
--- a/linkerd.io/content/2.19/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/2.19/tasks/rotating_webhooks_certificates.md
@@ -64,7 +64,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.19/tasks/setting-up-service-profiles.md b/linkerd.io/content/2.19/tasks/setting-up-service-profiles.md
index be9284058e..0c15421ba4 100644
--- a/linkerd.io/content/2.19/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/2.19/tasks/setting-up-service-profiles.md
@@ -19,7 +19,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 per-route metric, retries, and timeouts.
 
 The `destination service` for a request is computed by selecting the value of
diff --git a/linkerd.io/content/2.19/tasks/traffic-shifting.md b/linkerd.io/content/2.19/tasks/traffic-shifting.md
index 1091aa6198..4525d5fa8f 100644
--- a/linkerd.io/content/2.19/tasks/traffic-shifting.md
+++ b/linkerd.io/content/2.19/tasks/traffic-shifting.md
@@ -14,8 +14,8 @@ Traffic splitting is accomplished with [HTTPRoute] and [GRPCRoute] types.
 
 Earlier versions of Linkerd provided a
 [TrafficSplit](https://github.com/servicemeshinterface/smi-spec/blob/main/apis/traffic-split/v1alpha2/traffic-split.md/)
-resource as part of the the [Linkerd SMI extension](linkerd-smi/) for traffic
-splitting. This approach is still supported but will not recieve further feature
+resource as part of the [Linkerd SMI extension](linkerd-smi/) for traffic
+splitting. This approach is still supported but will not receive further feature
 development.
 
 {{< /note >}}
diff --git a/linkerd.io/content/2.19/tasks/troubleshooting.md b/linkerd.io/content/2.19/tasks/troubleshooting.md
index c574f7b2ce..603db116aa 100644
--- a/linkerd.io/content/2.19/tasks/troubleshooting.md
+++ b/linkerd.io/content/2.19/tasks/troubleshooting.md
@@ -647,7 +647,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
@@ -1097,7 +1097,7 @@ triggered if an extension value is used for the label key more than once across
 the cluster.
 
 To resolve this warning, ensure that the `linkerd.io/extension` namespace label
-does not have any dupliate values, indicating that an extension has been
+does not have any duplicate values, indicating that an extension has been
 installed more than once in different namespaces.
 
 ### Extensions checks
diff --git a/linkerd.io/content/2.19/tasks/uninstall.md b/linkerd.io/content/2.19/tasks/uninstall.md
index 7dbd4496fd..fc362e83bf 100644
--- a/linkerd.io/content/2.19/tasks/uninstall.md
+++ b/linkerd.io/content/2.19/tasks/uninstall.md
@@ -31,7 +31,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/2.19/tasks/using-ingress.md b/linkerd.io/content/2.19/tasks/using-ingress.md
index 618c00d615..0d9468aa23 100644
--- a/linkerd.io/content/2.19/tasks/using-ingress.md
+++ b/linkerd.io/content/2.19/tasks/using-ingress.md
@@ -333,8 +333,8 @@ spec:
 
 ## GCE
 
-The GCE ingress should be meshed with with
-[ingress mode enabled](#ingress-mode), , i.e. with the
+The GCE ingress should be meshed with
+[ingress mode enabled](#ingress-mode), i.e. with the
 `linkerd.io/inject: ingress` annotation rather than the default `enabled`.
 
 This example shows how to use a
diff --git a/linkerd.io/content/docs/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/docs/tasks/automatically-rotating-control-plane-tls-credentials.md
index 425dd65dad..de2ec39c1b 100644
--- a/linkerd.io/content/docs/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/docs/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -388,7 +388,7 @@ Almost done! We only need one more thing: the _trust bundle_ will lets Linkerd
 know which trust anchors to accept. We'll use trust-manager for this, but
 there's a catch: when rotating the trust anchor, both the control plane and the
 data plane (the proxies) need to be restarted. Since that can't happen
-instaneously, we need to have both the old trust anchor and the new trust anchor
+instantaneously, we need to have both the old trust anchor and the new trust anchor
 in the trust bundle until all the restarts have completed.
 
 trust-manager can do this, but it needs a specific source for _each_ certificate
diff --git a/linkerd.io/content/docs/tasks/circuit-breakers.md b/linkerd.io/content/docs/tasks/circuit-breakers.md
index d038ccf382..524e9fec5e 100644
--- a/linkerd.io/content/docs/tasks/circuit-breakers.md
+++ b/linkerd.io/content/docs/tasks/circuit-breakers.md
@@ -7,7 +7,7 @@ Circuit breaking is a powerful feature where Linkerd will temporarily stop
 routing requests to an endpoint if that endpoint is deemed to be unhealthy,
 instead routing that request to other replicas in the Service.
 
-In this tutoral, we'll see how to enable circuit breaking on a Service to
+In this tutorial, we'll see how to enable circuit breaking on a Service to
 improve client success rate when a backend replica is unhealthy.
 
 See the [reference documentation](../reference/circuit-breaking/) for more
@@ -217,7 +217,7 @@ failure accrual:
 
 This tells us that Linkerd will use `ConsecutiveFailures` failure accrual when
 talking to the `bb` Service. It also tells us that the `max_failures` is 7,
-meaning that it will trip the circuit breaker once it observes 7 consective
+meaning that it will trip the circuit breaker once it observes 7 consecutive
 failures. We'll talk more about each of the parameters here at the end of this
 article.
 
diff --git a/linkerd.io/content/docs/tasks/configuring-dynamic-request-routing.md b/linkerd.io/content/docs/tasks/configuring-dynamic-request-routing.md
index 004b50ded6..32186af1ff 100644
--- a/linkerd.io/content/docs/tasks/configuring-dynamic-request-routing.md
+++ b/linkerd.io/content/docs/tasks/configuring-dynamic-request-routing.md
@@ -156,7 +156,7 @@ In the example above, we used the `x-request-id` header, which is a common
 header that is forwarded by podinfo. However, the same technique will work with
 arbitrary headers, as long as the application forwards them.
 
-Note also that dyanmic request routing is client-side behavior, so while the
+Note also that dynamic request routing is client-side behavior, so while the
 traffic source (in this case, the frontend pod) needs to be meshed, strictly
 speaking, the destination does not need to be meshed.
 
diff --git a/linkerd.io/content/docs/tasks/federated-services.md b/linkerd.io/content/docs/tasks/federated-services.md
index 73487c1b9c..0ae2bedeca 100644
--- a/linkerd.io/content/docs/tasks/federated-services.md
+++ b/linkerd.io/content/docs/tasks/federated-services.md
@@ -8,7 +8,7 @@ which act as a union of multiple services in different clusters with the same
 name and namespace. By sending traffic to the federated service, that traffic
 will be load balanced among all endpoints of that service in all linked
 clusters. This allows the client to be cluster agnostic, balance traffic across
-multiple clusters, and be resiliant to the failure of any individual cluster.
+multiple clusters, and be resilient to the failure of any individual cluster.
 
 Federated services send traffic directly to the pods of the member services
 rather than through a gateway. Therefore, federated services have the same
@@ -362,7 +362,7 @@ is distributing requests across all three clusters:
 
 ## Next Steps
 
-We now have a federated service that balances traffic accross services in three
+We now have a federated service that balances traffic across services in three
 clusters. Additional clusters can be added simply by:
 
 - Updating the linkerd-multicluster config in `west` to add the required
diff --git a/linkerd.io/content/docs/tasks/generate-certificates.md b/linkerd.io/content/docs/tasks/generate-certificates.md
index 33dd6751d1..cb43b52098 100644
--- a/linkerd.io/content/docs/tasks/generate-certificates.md
+++ b/linkerd.io/content/docs/tasks/generate-certificates.md
@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 
diff --git a/linkerd.io/content/docs/tasks/grafana.md b/linkerd.io/content/docs/tasks/grafana.md
index 24f88e6dc3..4b40f1afb5 100644
--- a/linkerd.io/content/docs/tasks/grafana.md
+++ b/linkerd.io/content/docs/tasks/grafana.md
@@ -81,7 +81,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 
diff --git a/linkerd.io/content/docs/tasks/install-helm.md b/linkerd.io/content/docs/tasks/install-helm.md
index 5f31f1d3a9..014e3be9ff 100644
--- a/linkerd.io/content/docs/tasks/install-helm.md
+++ b/linkerd.io/content/docs/tasks/install-helm.md
@@ -43,7 +43,7 @@ then `linkerd-control-plane`.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/docs/tasks/install.md b/linkerd.io/content/docs/tasks/install.md
index 0eaf611bd3..c42b3af035 100644
--- a/linkerd.io/content/docs/tasks/install.md
+++ b/linkerd.io/content/docs/tasks/install.md
@@ -66,7 +66,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}
diff --git a/linkerd.io/content/docs/tasks/rotating_webhooks_certificates.md b/linkerd.io/content/docs/tasks/rotating_webhooks_certificates.md
index 3784403a60..834ce27399 100644
--- a/linkerd.io/content/docs/tasks/rotating_webhooks_certificates.md
+++ b/linkerd.io/content/docs/tasks/rotating_webhooks_certificates.md
@@ -64,7 +64,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/docs/tasks/setting-up-service-profiles.md b/linkerd.io/content/docs/tasks/setting-up-service-profiles.md
index be9284058e..0c15421ba4 100644
--- a/linkerd.io/content/docs/tasks/setting-up-service-profiles.md
+++ b/linkerd.io/content/docs/tasks/setting-up-service-profiles.md
@@ -19,7 +19,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 per-route metric, retries, and timeouts.
 
 The `destination service` for a request is computed by selecting the value of
diff --git a/linkerd.io/content/docs/tasks/traffic-shifting.md b/linkerd.io/content/docs/tasks/traffic-shifting.md
index 1091aa6198..4525d5fa8f 100644
--- a/linkerd.io/content/docs/tasks/traffic-shifting.md
+++ b/linkerd.io/content/docs/tasks/traffic-shifting.md
@@ -14,8 +14,8 @@ Traffic splitting is accomplished with [HTTPRoute] and [GRPCRoute] types.
 
 Earlier versions of Linkerd provided a
 [TrafficSplit](https://github.com/servicemeshinterface/smi-spec/blob/main/apis/traffic-split/v1alpha2/traffic-split.md/)
-resource as part of the the [Linkerd SMI extension](linkerd-smi/) for traffic
-splitting. This approach is still supported but will not recieve further feature
+resource as part of the [Linkerd SMI extension](linkerd-smi/) for traffic
+splitting. This approach is still supported but will not receive further feature
 development.
 
 {{< /note >}}
diff --git a/linkerd.io/content/docs/tasks/troubleshooting.md b/linkerd.io/content/docs/tasks/troubleshooting.md
index a9081f9e9b..929d16c5fe 100644
--- a/linkerd.io/content/docs/tasks/troubleshooting.md
+++ b/linkerd.io/content/docs/tasks/troubleshooting.md
@@ -703,7 +703,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
@@ -1161,7 +1161,7 @@ triggered if an extension value is used for the label key more than once across
 the cluster.
 
 To resolve this warning, ensure that the `linkerd.io/extension` namespace label
-does not have any dupliate values, indicating that an extension has been
+does not have any duplicate values, indicating that an extension has been
 installed more than once in different namespaces.
 
 ### Extensions checks
diff --git a/linkerd.io/content/docs/tasks/uninstall.md b/linkerd.io/content/docs/tasks/uninstall.md
index 7dbd4496fd..fc362e83bf 100644
--- a/linkerd.io/content/docs/tasks/uninstall.md
+++ b/linkerd.io/content/docs/tasks/uninstall.md
@@ -31,7 +31,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 
diff --git a/linkerd.io/content/docs/tasks/using-ingress.md b/linkerd.io/content/docs/tasks/using-ingress.md
index 618c00d615..0d9468aa23 100644
--- a/linkerd.io/content/docs/tasks/using-ingress.md
+++ b/linkerd.io/content/docs/tasks/using-ingress.md
@@ -333,8 +333,8 @@ spec:
 
 ## GCE
 
-The GCE ingress should be meshed with with
-[ingress mode enabled](#ingress-mode), , i.e. with the
+The GCE ingress should be meshed with
+[ingress mode enabled](#ingress-mode), i.e. with the
 `linkerd.io/inject: ingress` annotation rather than the default `enabled`.
 
 This example shows how to use a

From a7db217a7ca2bc6a0ce2c43848d0b2f29a853b85 Mon Sep 17 00:00:00 2001
From: joedrf <joe@buoyant.io>
Date: Sun, 26 Jul 2026 17:24:31 +0100
Subject: [PATCH 3/3] fix(docs): correct spelling and duplicated words in
 features docs

- Kuberentes -> Kubernetes
- Futher -> Further
- duplicated 'to to'

Applied across all versioned docs directories (2-edge, docs, 2.10-2.19),
following the convention in linkerd/website#1961 and #2137.

Signed-off-by: joedrf <joe@buoyant.io>
---
 linkerd.io/content/2-edge/features/automatic-mtls.md         | 2 +-
 linkerd.io/content/2-edge/features/dashboard.md              | 2 +-
 linkerd.io/content/2-edge/features/topology-aware-routing.md | 2 +-
 linkerd.io/content/2.10/features/automatic-mtls.md           | 2 +-
 linkerd.io/content/2.11/features/automatic-mtls.md           | 2 +-
 linkerd.io/content/2.12/features/automatic-mtls.md           | 2 +-
 linkerd.io/content/2.12/features/dashboard.md                | 2 +-
 linkerd.io/content/2.12/features/topology-aware-routing.md   | 2 +-
 linkerd.io/content/2.13/features/automatic-mtls.md           | 2 +-
 linkerd.io/content/2.13/features/dashboard.md                | 2 +-
 linkerd.io/content/2.13/features/topology-aware-routing.md   | 2 +-
 linkerd.io/content/2.14/features/automatic-mtls.md           | 2 +-
 linkerd.io/content/2.14/features/dashboard.md                | 2 +-
 linkerd.io/content/2.14/features/topology-aware-routing.md   | 2 +-
 linkerd.io/content/2.15/features/automatic-mtls.md           | 2 +-
 linkerd.io/content/2.15/features/dashboard.md                | 2 +-
 linkerd.io/content/2.15/features/topology-aware-routing.md   | 2 +-
 linkerd.io/content/2.16/features/automatic-mtls.md           | 2 +-
 linkerd.io/content/2.16/features/dashboard.md                | 2 +-
 linkerd.io/content/2.16/features/topology-aware-routing.md   | 2 +-
 linkerd.io/content/2.17/features/automatic-mtls.md           | 2 +-
 linkerd.io/content/2.17/features/dashboard.md                | 2 +-
 linkerd.io/content/2.17/features/topology-aware-routing.md   | 2 +-
 linkerd.io/content/2.18/features/automatic-mtls.md           | 2 +-
 linkerd.io/content/2.18/features/dashboard.md                | 2 +-
 linkerd.io/content/2.18/features/topology-aware-routing.md   | 2 +-
 linkerd.io/content/2.19/features/automatic-mtls.md           | 2 +-
 linkerd.io/content/2.19/features/dashboard.md                | 2 +-
 linkerd.io/content/2.19/features/topology-aware-routing.md   | 2 +-
 linkerd.io/content/docs/features/automatic-mtls.md           | 2 +-
 linkerd.io/content/docs/features/dashboard.md                | 2 +-
 linkerd.io/content/docs/features/topology-aware-routing.md   | 2 +-
 32 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/linkerd.io/content/2-edge/features/automatic-mtls.md b/linkerd.io/content/2-edge/features/automatic-mtls.md
index f9c813b492..464f656465 100644
--- a/linkerd.io/content/2-edge/features/automatic-mtls.md
+++ b/linkerd.io/content/2-edge/features/automatic-mtls.md
@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/2-edge/features/dashboard.md b/linkerd.io/content/2-edge/features/dashboard.md
index c69f941be4..a8f717af77 100644
--- a/linkerd.io/content/2-edge/features/dashboard.md
+++ b/linkerd.io/content/2-edge/features/dashboard.md
@@ -104,7 +104,7 @@ to use your browser instead:
 
 ![Tap](/images/docs/getting-started/tap.png 'Tap')
 
-## Futher reading
+## Further reading
 
 See [Exporting metrics](../tasks/exporting-metrics/) for alternative ways to
 consume Linkerd's metrics.
diff --git a/linkerd.io/content/2-edge/features/topology-aware-routing.md b/linkerd.io/content/2-edge/features/topology-aware-routing.md
index 2342588960..0638ab9292 100644
--- a/linkerd.io/content/2-edge/features/topology-aware-routing.md
+++ b/linkerd.io/content/2-edge/features/topology-aware-routing.md
@@ -13,7 +13,7 @@ multiple zones. Users can now implement routing constraints and prefer endpoints
 in a specific zone in order to limit cross-zone networking costs or improve
 performance through lowered cross-zone latency and bandwidth constraints.
 
-The goal of topology aware routing is to to provide a simpler way for users to
+The goal of topology aware routing is to provide a simpler way for users to
 prefer endpoints by basing decisions solely off the node's
 `topology.kubernetes.io/zone` label. If a client is in `zone-a`, then it should
 prefer endpoints marked for use by clients in `zone-a`. When the feature is
diff --git a/linkerd.io/content/2.10/features/automatic-mtls.md b/linkerd.io/content/2.10/features/automatic-mtls.md
index f4245d7ae7..13e49507b8 100644
--- a/linkerd.io/content/2.10/features/automatic-mtls.md
+++ b/linkerd.io/content/2.10/features/automatic-mtls.md
@@ -18,7 +18,7 @@ See [Caveats and future work](#caveats-and-future-work) below for some details.
 ## What is mTLS?
 
 A full definition of mTLS is outside the scope of this doc. For an overview of
-what mTLS is and how it works in Kuberentes clusters, we suggest reading through
+what mTLS is and how it works in Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/2.11/features/automatic-mtls.md b/linkerd.io/content/2.11/features/automatic-mtls.md
index b2d730d397..b5e21fad9d 100644
--- a/linkerd.io/content/2.11/features/automatic-mtls.md
+++ b/linkerd.io/content/2.11/features/automatic-mtls.md
@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/2.12/features/automatic-mtls.md b/linkerd.io/content/2.12/features/automatic-mtls.md
index 869e1a002e..9870af2dde 100644
--- a/linkerd.io/content/2.12/features/automatic-mtls.md
+++ b/linkerd.io/content/2.12/features/automatic-mtls.md
@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/2.12/features/dashboard.md b/linkerd.io/content/2.12/features/dashboard.md
index c69f941be4..a8f717af77 100644
--- a/linkerd.io/content/2.12/features/dashboard.md
+++ b/linkerd.io/content/2.12/features/dashboard.md
@@ -104,7 +104,7 @@ to use your browser instead:
 
 ![Tap](/images/docs/getting-started/tap.png 'Tap')
 
-## Futher reading
+## Further reading
 
 See [Exporting metrics](../tasks/exporting-metrics/) for alternative ways to
 consume Linkerd's metrics.
diff --git a/linkerd.io/content/2.12/features/topology-aware-routing.md b/linkerd.io/content/2.12/features/topology-aware-routing.md
index e70a129c16..e2e945b6e3 100644
--- a/linkerd.io/content/2.12/features/topology-aware-routing.md
+++ b/linkerd.io/content/2.12/features/topology-aware-routing.md
@@ -13,7 +13,7 @@ multiple zones. Users can now implement routing constraints and prefer endpoints
 in a specific zone in order to limit cross-zone networking costs or improve
 performance through lowered cross-zone latency and bandwidth constraints.
 
-The goal of topology aware routing is to to provide a simpler way for users to
+The goal of topology aware routing is to provide a simpler way for users to
 prefer endpoints by basing decisions solely off the node's
 `topology.kubernetes.io/zone` label. If a client is in `zone-a`, then it should
 prefer endpoints marked for use by clients in `zone-a`. When the feature is
diff --git a/linkerd.io/content/2.13/features/automatic-mtls.md b/linkerd.io/content/2.13/features/automatic-mtls.md
index 869e1a002e..9870af2dde 100644
--- a/linkerd.io/content/2.13/features/automatic-mtls.md
+++ b/linkerd.io/content/2.13/features/automatic-mtls.md
@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/2.13/features/dashboard.md b/linkerd.io/content/2.13/features/dashboard.md
index c69f941be4..a8f717af77 100644
--- a/linkerd.io/content/2.13/features/dashboard.md
+++ b/linkerd.io/content/2.13/features/dashboard.md
@@ -104,7 +104,7 @@ to use your browser instead:
 
 ![Tap](/images/docs/getting-started/tap.png 'Tap')
 
-## Futher reading
+## Further reading
 
 See [Exporting metrics](../tasks/exporting-metrics/) for alternative ways to
 consume Linkerd's metrics.
diff --git a/linkerd.io/content/2.13/features/topology-aware-routing.md b/linkerd.io/content/2.13/features/topology-aware-routing.md
index e70a129c16..e2e945b6e3 100644
--- a/linkerd.io/content/2.13/features/topology-aware-routing.md
+++ b/linkerd.io/content/2.13/features/topology-aware-routing.md
@@ -13,7 +13,7 @@ multiple zones. Users can now implement routing constraints and prefer endpoints
 in a specific zone in order to limit cross-zone networking costs or improve
 performance through lowered cross-zone latency and bandwidth constraints.
 
-The goal of topology aware routing is to to provide a simpler way for users to
+The goal of topology aware routing is to provide a simpler way for users to
 prefer endpoints by basing decisions solely off the node's
 `topology.kubernetes.io/zone` label. If a client is in `zone-a`, then it should
 prefer endpoints marked for use by clients in `zone-a`. When the feature is
diff --git a/linkerd.io/content/2.14/features/automatic-mtls.md b/linkerd.io/content/2.14/features/automatic-mtls.md
index 869e1a002e..9870af2dde 100644
--- a/linkerd.io/content/2.14/features/automatic-mtls.md
+++ b/linkerd.io/content/2.14/features/automatic-mtls.md
@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/2.14/features/dashboard.md b/linkerd.io/content/2.14/features/dashboard.md
index c69f941be4..a8f717af77 100644
--- a/linkerd.io/content/2.14/features/dashboard.md
+++ b/linkerd.io/content/2.14/features/dashboard.md
@@ -104,7 +104,7 @@ to use your browser instead:
 
 ![Tap](/images/docs/getting-started/tap.png 'Tap')
 
-## Futher reading
+## Further reading
 
 See [Exporting metrics](../tasks/exporting-metrics/) for alternative ways to
 consume Linkerd's metrics.
diff --git a/linkerd.io/content/2.14/features/topology-aware-routing.md b/linkerd.io/content/2.14/features/topology-aware-routing.md
index 077d82dd17..1897b755fc 100644
--- a/linkerd.io/content/2.14/features/topology-aware-routing.md
+++ b/linkerd.io/content/2.14/features/topology-aware-routing.md
@@ -13,7 +13,7 @@ multiple zones. Users can now implement routing constraints and prefer endpoints
 in a specific zone in order to limit cross-zone networking costs or improve
 performance through lowered cross-zone latency and bandwidth constraints.
 
-The goal of topology aware routing is to to provide a simpler way for users to
+The goal of topology aware routing is to provide a simpler way for users to
 prefer endpoints by basing decisions solely off the node's
 `topology.kubernetes.io/zone` label. If a client is in `zone-a`, then it should
 prefer endpoints marked for use by clients in `zone-a`. When the feature is
diff --git a/linkerd.io/content/2.15/features/automatic-mtls.md b/linkerd.io/content/2.15/features/automatic-mtls.md
index 869e1a002e..9870af2dde 100644
--- a/linkerd.io/content/2.15/features/automatic-mtls.md
+++ b/linkerd.io/content/2.15/features/automatic-mtls.md
@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/2.15/features/dashboard.md b/linkerd.io/content/2.15/features/dashboard.md
index c69f941be4..a8f717af77 100644
--- a/linkerd.io/content/2.15/features/dashboard.md
+++ b/linkerd.io/content/2.15/features/dashboard.md
@@ -104,7 +104,7 @@ to use your browser instead:
 
 ![Tap](/images/docs/getting-started/tap.png 'Tap')
 
-## Futher reading
+## Further reading
 
 See [Exporting metrics](../tasks/exporting-metrics/) for alternative ways to
 consume Linkerd's metrics.
diff --git a/linkerd.io/content/2.15/features/topology-aware-routing.md b/linkerd.io/content/2.15/features/topology-aware-routing.md
index 077d82dd17..1897b755fc 100644
--- a/linkerd.io/content/2.15/features/topology-aware-routing.md
+++ b/linkerd.io/content/2.15/features/topology-aware-routing.md
@@ -13,7 +13,7 @@ multiple zones. Users can now implement routing constraints and prefer endpoints
 in a specific zone in order to limit cross-zone networking costs or improve
 performance through lowered cross-zone latency and bandwidth constraints.
 
-The goal of topology aware routing is to to provide a simpler way for users to
+The goal of topology aware routing is to provide a simpler way for users to
 prefer endpoints by basing decisions solely off the node's
 `topology.kubernetes.io/zone` label. If a client is in `zone-a`, then it should
 prefer endpoints marked for use by clients in `zone-a`. When the feature is
diff --git a/linkerd.io/content/2.16/features/automatic-mtls.md b/linkerd.io/content/2.16/features/automatic-mtls.md
index 869e1a002e..9870af2dde 100644
--- a/linkerd.io/content/2.16/features/automatic-mtls.md
+++ b/linkerd.io/content/2.16/features/automatic-mtls.md
@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/2.16/features/dashboard.md b/linkerd.io/content/2.16/features/dashboard.md
index c69f941be4..a8f717af77 100644
--- a/linkerd.io/content/2.16/features/dashboard.md
+++ b/linkerd.io/content/2.16/features/dashboard.md
@@ -104,7 +104,7 @@ to use your browser instead:
 
 ![Tap](/images/docs/getting-started/tap.png 'Tap')
 
-## Futher reading
+## Further reading
 
 See [Exporting metrics](../tasks/exporting-metrics/) for alternative ways to
 consume Linkerd's metrics.
diff --git a/linkerd.io/content/2.16/features/topology-aware-routing.md b/linkerd.io/content/2.16/features/topology-aware-routing.md
index 077d82dd17..1897b755fc 100644
--- a/linkerd.io/content/2.16/features/topology-aware-routing.md
+++ b/linkerd.io/content/2.16/features/topology-aware-routing.md
@@ -13,7 +13,7 @@ multiple zones. Users can now implement routing constraints and prefer endpoints
 in a specific zone in order to limit cross-zone networking costs or improve
 performance through lowered cross-zone latency and bandwidth constraints.
 
-The goal of topology aware routing is to to provide a simpler way for users to
+The goal of topology aware routing is to provide a simpler way for users to
 prefer endpoints by basing decisions solely off the node's
 `topology.kubernetes.io/zone` label. If a client is in `zone-a`, then it should
 prefer endpoints marked for use by clients in `zone-a`. When the feature is
diff --git a/linkerd.io/content/2.17/features/automatic-mtls.md b/linkerd.io/content/2.17/features/automatic-mtls.md
index 869e1a002e..9870af2dde 100644
--- a/linkerd.io/content/2.17/features/automatic-mtls.md
+++ b/linkerd.io/content/2.17/features/automatic-mtls.md
@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/2.17/features/dashboard.md b/linkerd.io/content/2.17/features/dashboard.md
index c69f941be4..a8f717af77 100644
--- a/linkerd.io/content/2.17/features/dashboard.md
+++ b/linkerd.io/content/2.17/features/dashboard.md
@@ -104,7 +104,7 @@ to use your browser instead:
 
 ![Tap](/images/docs/getting-started/tap.png 'Tap')
 
-## Futher reading
+## Further reading
 
 See [Exporting metrics](../tasks/exporting-metrics/) for alternative ways to
 consume Linkerd's metrics.
diff --git a/linkerd.io/content/2.17/features/topology-aware-routing.md b/linkerd.io/content/2.17/features/topology-aware-routing.md
index 2342588960..0638ab9292 100644
--- a/linkerd.io/content/2.17/features/topology-aware-routing.md
+++ b/linkerd.io/content/2.17/features/topology-aware-routing.md
@@ -13,7 +13,7 @@ multiple zones. Users can now implement routing constraints and prefer endpoints
 in a specific zone in order to limit cross-zone networking costs or improve
 performance through lowered cross-zone latency and bandwidth constraints.
 
-The goal of topology aware routing is to to provide a simpler way for users to
+The goal of topology aware routing is to provide a simpler way for users to
 prefer endpoints by basing decisions solely off the node's
 `topology.kubernetes.io/zone` label. If a client is in `zone-a`, then it should
 prefer endpoints marked for use by clients in `zone-a`. When the feature is
diff --git a/linkerd.io/content/2.18/features/automatic-mtls.md b/linkerd.io/content/2.18/features/automatic-mtls.md
index 869e1a002e..9870af2dde 100644
--- a/linkerd.io/content/2.18/features/automatic-mtls.md
+++ b/linkerd.io/content/2.18/features/automatic-mtls.md
@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/2.18/features/dashboard.md b/linkerd.io/content/2.18/features/dashboard.md
index c69f941be4..a8f717af77 100644
--- a/linkerd.io/content/2.18/features/dashboard.md
+++ b/linkerd.io/content/2.18/features/dashboard.md
@@ -104,7 +104,7 @@ to use your browser instead:
 
 ![Tap](/images/docs/getting-started/tap.png 'Tap')
 
-## Futher reading
+## Further reading
 
 See [Exporting metrics](../tasks/exporting-metrics/) for alternative ways to
 consume Linkerd's metrics.
diff --git a/linkerd.io/content/2.18/features/topology-aware-routing.md b/linkerd.io/content/2.18/features/topology-aware-routing.md
index 2342588960..0638ab9292 100644
--- a/linkerd.io/content/2.18/features/topology-aware-routing.md
+++ b/linkerd.io/content/2.18/features/topology-aware-routing.md
@@ -13,7 +13,7 @@ multiple zones. Users can now implement routing constraints and prefer endpoints
 in a specific zone in order to limit cross-zone networking costs or improve
 performance through lowered cross-zone latency and bandwidth constraints.
 
-The goal of topology aware routing is to to provide a simpler way for users to
+The goal of topology aware routing is to provide a simpler way for users to
 prefer endpoints by basing decisions solely off the node's
 `topology.kubernetes.io/zone` label. If a client is in `zone-a`, then it should
 prefer endpoints marked for use by clients in `zone-a`. When the feature is
diff --git a/linkerd.io/content/2.19/features/automatic-mtls.md b/linkerd.io/content/2.19/features/automatic-mtls.md
index f9c813b492..464f656465 100644
--- a/linkerd.io/content/2.19/features/automatic-mtls.md
+++ b/linkerd.io/content/2.19/features/automatic-mtls.md
@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/2.19/features/dashboard.md b/linkerd.io/content/2.19/features/dashboard.md
index c69f941be4..a8f717af77 100644
--- a/linkerd.io/content/2.19/features/dashboard.md
+++ b/linkerd.io/content/2.19/features/dashboard.md
@@ -104,7 +104,7 @@ to use your browser instead:
 
 ![Tap](/images/docs/getting-started/tap.png 'Tap')
 
-## Futher reading
+## Further reading
 
 See [Exporting metrics](../tasks/exporting-metrics/) for alternative ways to
 consume Linkerd's metrics.
diff --git a/linkerd.io/content/2.19/features/topology-aware-routing.md b/linkerd.io/content/2.19/features/topology-aware-routing.md
index 2342588960..0638ab9292 100644
--- a/linkerd.io/content/2.19/features/topology-aware-routing.md
+++ b/linkerd.io/content/2.19/features/topology-aware-routing.md
@@ -13,7 +13,7 @@ multiple zones. Users can now implement routing constraints and prefer endpoints
 in a specific zone in order to limit cross-zone networking costs or improve
 performance through lowered cross-zone latency and bandwidth constraints.
 
-The goal of topology aware routing is to to provide a simpler way for users to
+The goal of topology aware routing is to provide a simpler way for users to
 prefer endpoints by basing decisions solely off the node's
 `topology.kubernetes.io/zone` label. If a client is in `zone-a`, then it should
 prefer endpoints marked for use by clients in `zone-a`. When the feature is
diff --git a/linkerd.io/content/docs/features/automatic-mtls.md b/linkerd.io/content/docs/features/automatic-mtls.md
index f9c813b492..464f656465 100644
--- a/linkerd.io/content/docs/features/automatic-mtls.md
+++ b/linkerd.io/content/docs/features/automatic-mtls.md
@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?
diff --git a/linkerd.io/content/docs/features/dashboard.md b/linkerd.io/content/docs/features/dashboard.md
index c69f941be4..a8f717af77 100644
--- a/linkerd.io/content/docs/features/dashboard.md
+++ b/linkerd.io/content/docs/features/dashboard.md
@@ -104,7 +104,7 @@ to use your browser instead:
 
 ![Tap](/images/docs/getting-started/tap.png 'Tap')
 
-## Futher reading
+## Further reading
 
 See [Exporting metrics](../tasks/exporting-metrics/) for alternative ways to
 consume Linkerd's metrics.
diff --git a/linkerd.io/content/docs/features/topology-aware-routing.md b/linkerd.io/content/docs/features/topology-aware-routing.md
index 2342588960..0638ab9292 100644
--- a/linkerd.io/content/docs/features/topology-aware-routing.md
+++ b/linkerd.io/content/docs/features/topology-aware-routing.md
@@ -13,7 +13,7 @@ multiple zones. Users can now implement routing constraints and prefer endpoints
 in a specific zone in order to limit cross-zone networking costs or improve
 performance through lowered cross-zone latency and bandwidth constraints.
 
-The goal of topology aware routing is to to provide a simpler way for users to
+The goal of topology aware routing is to provide a simpler way for users to
 prefer endpoints by basing decisions solely off the node's
 `topology.kubernetes.io/zone` label. If a client is in `zone-a`, then it should
 prefer endpoints marked for use by clients in `zone-a`. When the feature is