diff --git a/.github/actions/install-otlp-collector/action.yml b/.github/actions/install-otlp-collector/action.yml
index b163104579..c618df6640 100644
--- a/.github/actions/install-otlp-collector/action.yml
+++ b/.github/actions/install-otlp-collector/action.yml
@@ -41,7 +41,7 @@ runs:
           name: otlp
         EOF
 
-        # Add collector configuration : basic otlp grpc reciever to logging
+        # Add collector configuration : basic otlp grpc receiver to logging
         cat <<EOF | kubectl apply -n otlp -f -
         kind: ConfigMap
         apiVersion: v1
diff --git a/docs/modules/ROOT/attachments/schema/integration-schema.json b/docs/modules/ROOT/attachments/schema/integration-schema.json
index 4748720cab..09623f877f 100644
--- a/docs/modules/ROOT/attachments/schema/integration-schema.json
+++ b/docs/modules/ROOT/attachments/schema/integration-schema.json
@@ -3568,7 +3568,7 @@
                         "type": "string"
                       },
                       "whenUnsatisfiable": {
-                        "description": "WhenUnsatisfiable indicates how to deal with a pod if it doesn't satisfy the spread constraint. - DoNotSchedule (default) tells the scheduler not to schedule it. - ScheduleAnyway tells the scheduler to schedule the pod in any location,   but giving higher precedence to topologies that would help reduce the   skew. A constraint is considered \"Unsatisfiable\" for an incoming pod if and only if every possible node assigment for that pod would violate \"MaxSkew\" on some topology. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 3/1/1: | zone1 | zone2 | zone3 | | P P P |   P   |   P   | If WhenUnsatisfiable is set to DoNotSchedule, incoming pod can only be scheduled to zone2(zone3) to become 3/2/1(3/1/2) as ActualSkew(2-1) on zone2(zone3) satisfies MaxSkew(1). In other words, the cluster can still be imbalanced, but scheduler won't make it *more* imbalanced. It's a required field.",
+                        "description": "WhenUnsatisfiable indicates how to deal with a pod if it doesn't satisfy the spread constraint. - DoNotSchedule (default) tells the scheduler not to schedule it. - ScheduleAnyway tells the scheduler to schedule the pod in any location,   but giving higher precedence to topologies that would help reduce the   skew. A constraint is considered \"Unsatisfiable\" for an incoming pod if and only if every possible node assignment for that pod would violate \"MaxSkew\" on some topology. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 3/1/1: | zone1 | zone2 | zone3 | | P P P |   P   |   P   | If WhenUnsatisfiable is set to DoNotSchedule, incoming pod can only be scheduled to zone2(zone3) to become 3/2/1(3/1/2) as ActualSkew(2-1) on zone2(zone3) satisfies MaxSkew(1). In other words, the cluster can still be imbalanced, but scheduler won't make it *more* imbalanced. It's a required field.",
                         "type": "string"
                       }
                     }
diff --git a/docs/modules/ROOT/pages/contributing/local-execution.adoc b/docs/modules/ROOT/pages/contributing/local-execution.adoc
index 3ee259c8de..55a451a0e8 100644
--- a/docs/modules/ROOT/pages/contributing/local-execution.adoc
+++ b/docs/modules/ROOT/pages/contributing/local-execution.adoc
@@ -47,7 +47,7 @@ IMPORTANT: make sure no other Camel K Operators are watching this namespace, nei
 [[local-minikube]]
 == Local operator and local cluster
 
-If you want to run a local operator togheter with ``Minikube`` you will need an additional step in order to let the local operator push images in the local registry. We need to expose the local registry as described in https://minikube.sigs.k8s.io/docs/handbook/registry/#docker-on-windows[this procedure]:
+If you want to run a local operator together with ``Minikube`` you will need an additional step in order to let the local operator push images in the local registry. We need to expose the local registry as described in https://minikube.sigs.k8s.io/docs/handbook/registry/#docker-on-windows[this procedure]:
 
 Enable the addon registry (this should be already in place):
 ----
diff --git a/docs/modules/ROOT/pages/installation/advanced/maven-proxy.adoc b/docs/modules/ROOT/pages/installation/advanced/maven-proxy.adoc
index 7629840711..51e161e20a 100644
--- a/docs/modules/ROOT/pages/installation/advanced/maven-proxy.adoc
+++ b/docs/modules/ROOT/pages/installation/advanced/maven-proxy.adoc
@@ -7,7 +7,7 @@ If your environments has not yet any, here we provide some simple example that c
 
 == Nexus Maven repository manager
 
-The following configuration is a very simple one from where you can start your own self managed Maven repository manager. It is based on https://www.sonatype.com/products/sonatype-nexus-repository[Nexus] and once it's up and running, it can work togheter with Camel K as explained in /camel-k/next/installation/advanced/maven.html#maven-proxy[Maven proxy configuration].
+The following configuration is a very simple one from where you can start your own self managed Maven repository manager. It is based on https://www.sonatype.com/products/sonatype-nexus-repository[Nexus] and once it's up and running, it can work together with Camel K as explained in /camel-k/next/installation/advanced/maven.html#maven-proxy[Maven proxy configuration].
 
 NOTE: this configuration is NOT production ready. It is ephemeral and uses plain http protocol. It requires some important tuning in order to be used in a production environment.
 
@@ -63,4 +63,4 @@ spec:
           emptyDir: {}
 ```
 
-Once you have created a file with this content (ie, `nexus.yaml`), then, you can apply to your cluster via `kubectl apply -f nexus.yaml`. Et voilá, after a few seconds, you will be able to use http://nexus/ as a Maven proxy repository.
\ No newline at end of file
+Once you have created a file with this content (ie, `nexus.yaml`), then, you can apply to your cluster via `kubectl apply -f nexus.yaml`. Et voilá, after a few seconds, you will be able to use http://nexus/ as a Maven proxy repository.
diff --git a/docs/modules/ROOT/partials/apis/crds-html.adoc b/docs/modules/ROOT/partials/apis/crds-html.adoc
index c00bf43abb..60a1b94d29 100644
--- a/docs/modules/ROOT/partials/apis/crds-html.adoc
+++ b/docs/modules/ROOT/partials/apis/crds-html.adoc
@@ -5220,7 +5220,7 @@ ErrorHandlerSpec
 </em>
 </td>
 <td>
-<p>ErrorHandler is an optional handler called upon an error occuring in the integration</p>
+<p>ErrorHandler is an optional handler called upon an error occurring in the integration</p>
 </td>
 </tr>
 <tr>
@@ -6286,7 +6286,7 @@ ErrorHandlerSpec
 </em>
 </td>
 <td>
-<p>ErrorHandler is an optional handler called upon an error occuring in the integration</p>
+<p>ErrorHandler is an optional handler called upon an error occurring in the integration</p>
 </td>
 </tr>
 <tr>
diff --git a/docs/modules/traits/pages/telemetry.adoc b/docs/modules/traits/pages/telemetry.adoc
index 44f54204e7..a2e86f2cde 100644
--- a/docs/modules/traits/pages/telemetry.adoc
+++ b/docs/modules/traits/pages/telemetry.adoc
@@ -68,7 +68,7 @@ The following configuration options are available:
 [source,console]
 $ kamel run -t telemetry.enable=true ...
 
-* To define a specific deployed OTLP gRPC reciever: 
+* To define a specific deployed OTLP gRPC receiver:
 +
 [source,console]
 $ kamel run -t telemetry.enable=true -t telemetry.endpoint=http://instance-collector:4317 ...
diff --git a/pkg/util/uri/uri_test.go b/pkg/util/uri/uri_test.go
index 49ecb0c2dc..a4f79ba2c3 100644
--- a/pkg/util/uri/uri_test.go
+++ b/pkg/util/uri/uri_test.go
@@ -149,7 +149,7 @@ func TestCamelURIFormat(t *testing.T) {
 		invalid bool
 	}{
 		{
-			uri: "knative:channnel",
+			uri: "knative:channel",
 		},
 		{
 			uri: "atomix-value:",
diff --git a/proposals/service-binding.adoc b/proposals/service-binding.adoc
index d2a166b4ed..e7ad39d979 100644
--- a/proposals/service-binding.adoc
+++ b/proposals/service-binding.adoc
@@ -34,14 +34,14 @@ Users should be able to connect to a _Provisioned Service_ by specifying one or
 
 [source,console]
 ----
-$ kamel run intergration --connect database,broker
+$ kamel run integration --connect database,broker
 ----
 
 The _Service Binding_ could be referenced by name like shown above, in which case the _Service Binding_ already exists, or it could be created and managed by Camel K in which case the user would have to explicitly specify the _Provisioned Service_ they want to connect to:
 
 [source,console]
 ----
-$ kamel run intergration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo
+$ kamel run integration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo
 ----
 
 The user may then reference the binding properties inside the integration just like any other properties.