diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt
index adc41bb72eb236ac651ccc95620416208420cb70..de7fb45490dd8ee3ea2fe73a0ff85f88de955edb 100644
--- a/doc/.vale/gitlab/spelling-exceptions.txt
+++ b/doc/.vale/gitlab/spelling-exceptions.txt
@@ -73,6 +73,7 @@ blockquoting
 boolean
 booleans
 Bootsnap
+Bottlerocket
 browsable
 bugfix
 bugfixed
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index f43f9f5d6c1f87f45ae91bfd5139b5b99da013bc..5d5081bf810e92cbfc304cff36606866a17a1f6d 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -330,7 +330,7 @@ Gitaly Cluster uses the PostgreSQL metadata store with the storage layout to ens
 deletion, and move operations. The disk operations can't be atomically applied across multiple storages. However, PostgreSQL guarantees
 the atomicity of the metadata operations. Gitaly Cluster models the operations in a manner that the failing operations always leave
 the metadata consistent. The disks may contain stale state even after successful operations. This is expected and the leftover state
-won't intefere with future operations but may use up disk space unnecessarily until a clean up is performed.
+won't interfere with future operations but may use up disk space unnecessarily until a clean up is performed.
 
 There is on-going work on a [background crawler](https://gitlab.com/gitlab-org/gitaly/-/issues/3719) that cleans up the leftover
 repositories from the storages.
diff --git a/doc/api/group_wikis.md b/doc/api/group_wikis.md
index a78f989a755642aadc8cf28e2dc1926e5431d213..50bb67b81730833416fe623d2bad179708790925 100644
--- a/doc/api/group_wikis.md
+++ b/doc/api/group_wikis.md
@@ -72,7 +72,7 @@ GET /groups/:id/wikis/:slug
 | `id`      | integer/string | yes      | The ID or [URL-encoded path of the group](index.md#namespaced-path-encoding) |
 | `slug`    | string         | yes      | URL-encoded slug (a unique string) of the wiki page, such as `dir%2Fpage_name`      |
 | `render_html`      | boolean    | no      | Return the rendered HTML of the wiki page  |
-| `version`      | string    | no      | Wiki page version sha  |
+| `version`      | string    | no      | Wiki page version SHA  |
 
 ```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/1/wikis/home"
diff --git a/doc/api/wikis.md b/doc/api/wikis.md
index 0122872becfb670f3a3db925a704a4a3ebc209c8..ebdaa700aa7f8c68f60804b8bb57c1c31bb3ccaa 100644
--- a/doc/api/wikis.md
+++ b/doc/api/wikis.md
@@ -70,7 +70,7 @@ GET /projects/:id/wikis/:slug
 | `id`      | integer/string    | yes      | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) |
 | `slug` | string  | yes       | URL encoded slug (a unique string) of the wiki page, such as `dir%2Fpage_name`  |
 | `render_html`      | boolean    | no      | Return the rendered HTML of the wiki page  |
-| `version`      | string    | no      | Wiki page version sha  |
+| `version`      | string    | no      | Wiki page version SHA  |
 
 ```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/wikis/home"
diff --git a/doc/architecture/blueprints/database_scaling/size-limits.md b/doc/architecture/blueprints/database_scaling/size-limits.md
index a05084886203b0227f301005bb8dcc1b9091a198..968059691d9b2bbb4aa9921776e5557a20d1575a 100644
--- a/doc/architecture/blueprints/database_scaling/size-limits.md
+++ b/doc/architecture/blueprints/database_scaling/size-limits.md
@@ -36,7 +36,7 @@ Large tables on GitLab.com are a major problem - for both operations and develop
 1. **Table maintenance** becomes much more costly. Vacuum activity has become a significant concern on GitLab.com - with large tables only seeing infrequent (once per day) processing and vacuum runs taking many hours to complete. This has various negative consequences and a very large table has potential to impact seemingly unrelated parts of the database and hence overall application performance suffers.
 1. **Data migrations** on large tables are significantly more complex to implement and incur development overhead. They have potential to cause stability problems on GitLab.com and take a long time to execute on large datasets.
 1. **Indexes size** is significant. This directly impacts performance as smaller parts of the index are kept in memory and also makes the indexes harder to maintain (think repacking).
-1. **Index creation times** go up significantly - in 2021, we see btree creation take up to 6 hours for a single btree index. This impacts our ability to deploy frequently and leads to vacuum-related problems (delayed cleanup).
+1. **Index creation times** go up significantly - in 2021, we see B-Tree creation take up to 6 hours for a single B-Tree index. This impacts our ability to deploy frequently and leads to vacuum-related problems (delayed cleanup).
 1. We tend to add **many indexes** to mitigate, but this eventually causes significant overhead, can confuse the query planner and a large number of indexes is a smell of a design problem.
 
 ## Examples
diff --git a/doc/development/database/loose_foreign_keys.md b/doc/development/database/loose_foreign_keys.md
index 3db24793f1b075ad09e6f75c38581a9044e523dc..c8f930bb2614ef776266ccb1522b7cf65bbaf669 100644
--- a/doc/development/database/loose_foreign_keys.md
+++ b/doc/development/database/loose_foreign_keys.md
@@ -255,7 +255,7 @@ When the loose foreign key definition is no longer needed (parent table is remov
 we need to remove the definition from the YAML file and ensure that we don't leave pending deleted
 records in the database.
 
-1. Remove the loose foreign key definition from the config (`config/gitlab_loose_foreign_keys.yml`).
+1. Remove the loose foreign key definition from the configuration (`config/gitlab_loose_foreign_keys.yml`).
 1. Remove the deletion tracking trigger from the parent table (if the parent table is still there).
 1. Remove leftover deleted records from the `loose_foreign_keys_deleted_records` table.
 
diff --git a/doc/development/database/pagination_guidelines.md b/doc/development/database/pagination_guidelines.md
index 08840124535b2b6f8000fe80a8720278840e104f..b5cbae9ad05b3c96dcc562b62bf9856189e7708c 100644
--- a/doc/development/database/pagination_guidelines.md
+++ b/doc/development/database/pagination_guidelines.md
@@ -302,7 +302,7 @@ LIMIT 20
 
 ##### Tooling
 
-A generic keyset pagination library is available within the GitLab project which can most of the cases easily replace the existing, kaminari based pagination with significant performance improvements when dealing with large datasets.
+A generic keyset pagination library is available within the GitLab project which can most of the cases easily replace the existing, Kaminari based pagination with significant performance improvements when dealing with large datasets.
 
 Example:
 
diff --git a/doc/development/distributed_tracing.md b/doc/development/distributed_tracing.md
index b4f347449cc2fc5630b9a15ee3be2bd5bd4811e0..aa0dc8118b697fa618f149ad3e6300d9d0c3e438 100644
--- a/doc/development/distributed_tracing.md
+++ b/doc/development/distributed_tracing.md
@@ -71,7 +71,7 @@ GITLAB_TRACING=opentracing://<driver>?<param_name>=<param_value>&<param_name_2>=
 
 In this example, we have the following hypothetical values:
 
-- `driver`: the driver such a jaegar.
+- `driver`: the driver such a Jaeger.
 - `param_name`, `param_value`: these are driver specific configuration values. Configuration
   parameters for Jaeger are documented [further on in this
   document](#2-configure-the-gitlab_tracing-environment-variable) they should be URL encoded.
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 5cfdaff04482b4e9e7896723293a9c2a28959312..c83a6d30950f4651d9691f7f404c3da120154d0f 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -462,7 +462,7 @@ export const createLocalState = () => {
 };
 ```
 
-Pass the cache config to your Apollo Client:
+Pass the cache configuration to your Apollo Client:
 
 ```javascript
 // index.js
diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md
index ff4b77dec2cb7b8a8eab04a86c399157b1bbfe8a..1351d5b5b855a6f519fa8dca59b5ad7d29c783bd 100644
--- a/doc/development/testing_guide/review_apps.md
+++ b/doc/development/testing_guide/review_apps.md
@@ -12,7 +12,7 @@ Review Apps are deployed using the `start-review-app-pipeline` job. This job tri
 
 For any of the following scenarios, the `start-review-app-pipeline` job would be automatically started:
 
-- for merge requests with CI config changes
+- for merge requests with CI configuration changes
 - for merge requests with frontend changes
 - for merge requests with changes to `{,ee/,jh/}{app/controllers}/**/*`
 - for merge requests with changes to `{,ee/,jh/}{app/models}/**/*`
diff --git a/doc/install/docker.md b/doc/install/docker.md
index dcb44882ca897b8d230678cc4be3f6c152afec54..a70df3050a56194970f4e4ebf3fcef9f1479a76b 100644
--- a/doc/install/docker.md
+++ b/doc/install/docker.md
@@ -643,7 +643,7 @@ sudo setfacl -mR default:group:docker:rwx $GITLAB_HOME
 The default group is `docker`. If you changed the group, be sure to update your
 commands.
 
-### /dev/shm mount not having enough space in Docker container
+### `/dev/shm` mount not having enough space in Docker container
 
 GitLab comes with a Prometheus metrics endpoint at `/-/metrics` to expose a
 variety of statistics on the health and performance of GitLab. The files
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index e3fdb267f409e374c362f8bd3ef1498cfc261f2a..5ba6bd9fb14df1501f1b0a1afcd0a2e8152ec3ff 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -1591,7 +1591,7 @@ To prepare the new server:
 1. Test that the GitLab instance is working as expected.
 1. If applicable, re-enable [incoming email](../administration/incoming_email.md) and test it is working as expected.
 1. Update your DNS or load balancer to point at the new server.
-1. Unblock new CI/CD jobs from starting by removing the custom NGINX config
+1. Unblock new CI/CD jobs from starting by removing the custom NGINX configuration
    you added previously:
 
    ```ruby
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index 87d49ffa324ad2eb91c2355c9d8deb5a0fffec19..7cf1faa4177b8abbdda1a67c01d96c7b0de9d9ba 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -1030,7 +1030,7 @@ ensure that it can reach your private repository. Here is an example configurati
    setuptools.ssl_support.cert_paths = ['internal.crt']
    ```
 
-## Hosting a copy of the gemnasium_db advisory database
+## Hosting a copy of the `gemnasium_db` advisory database
 
 The [`gemnasium_db`](https://gitlab.com/gitlab-org/security-products/gemnasium-db) Git repository is
 used by `gemnasium`, `gemnasium-maven`, and `gemnasium-python` as the source of vulnerability data.
diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md
index 38f26b7578d175c0c31bafc9f2772311626f3b2c..7a4123c252fb88a5213f4ace699aa5f7510f78de 100644
--- a/doc/user/application_security/sast/index.md
+++ b/doc/user/application_security/sast/index.md
@@ -539,7 +539,7 @@ file `gosec-config.json`:
     value = "gosec-config.json"
 ```
 
-##### Passthrough chain for semgrep
+##### Passthrough chain for Semgrep
 
 In the below example, we generate a custom configuration under the `/sgrules`
 target directory with a total `timeout` of 60 seconds.
@@ -560,7 +560,7 @@ Several passthrouh types generate a configuration for the target analyzer:
 - The `url` entry fetches a configuration made available through a URL and
   stores it in the `/sgrules/gosec.yml` file.
 
-Afterwards, semgrep is invoked with the final configuration located under
+Afterwards, Semgrep is invoked with the final configuration located under
 `/sgrules`.
 
 ```toml
@@ -632,12 +632,12 @@ created when preceding passthroughs in the chain find a naming
 collision. If `mode` is set to `append`, a passthrough appends data to the
 files created by its predecessors instead of overwriting.
 
-In the below semgrep configuration,`/sgrules/insecure.yml` assembles two passthroughs. The rules are:
+In the below Semgrep configuration,`/sgrules/insecure.yml` assembles two passthroughs. The rules are:
 
 - `insecure`
 - `secret`
 
-These rules add a search pattern to the analyzer and extends semgrep capabilities.
+These rules add a search pattern to the analyzer and extends Semgrep capabilities.
 
 For passthrough chains we recommend that you enable validation. To enable validation,
 you can either: