diff --git a/doc/.vale/gitlab/British.yml b/doc/.vale/gitlab/British.yml
new file mode 100644
index 0000000000000000000000000000000000000000..943e85beba15f26f83c93d546602651b6dbb21d1
--- /dev/null
+++ b/doc/.vale/gitlab/British.yml
@@ -0,0 +1,106 @@
+---
+# Checks for use of some of the top misused terms at GitLab.
+#
+# For a list of all options, see https://errata-ai.github.io/vale/styles/
+extends: substitution
+message: 'Use the American spelling "%s" instead of the British "%s".'
+link: https://about.gitlab.com/handbook/communication/#top-misused-terms
+level: error
+ignorecase: true
+swap:
+  aeon: eon
+  aeroplane: airplane
+  ageing: aging
+  aluminium: aluminum
+  anaemia: anemia
+  anaesthesia: anesthesia
+  analyse: analyze
+  annexe: annex
+  apologise: apologize
+  behaviour: behavior
+  busses: buses
+  calibre: caliber
+  centre: center
+  cheque: check
+  civilisation: civilization
+  civilise: civilize
+  colour: color
+  cosy: cozy
+  cypher: cipher
+  dependant: dependent
+  defence: defense
+  distil: distill
+  draught: draft
+  encyclopaedia: encyclopedia
+  enquiry: inquiry
+  enrol: enroll
+  enrolment: enrollment
+  enthral: enthrall
+  # equalled: equaled // Under discussion
+  # equalling: equaling // Under discussion
+  favourite: favorite
+  fibre: fiber
+  fillet: filet
+  flavour: flavor
+  furore: furor
+  fulfil: fulfill
+  gaol: jail
+  grey: gray
+  humour: humor
+  honour: honor
+  initialled: initialed
+  initialling: initialing
+  instil: instill
+  jewellery: jewelry
+  labelling: labeling
+  labelled: labeled
+  labour: labor
+  libellous: libelous
+  licence: license
+  likeable: likable
+  liveable: livable
+  lustre: luster
+  manoeuvre: maneuver
+  marvellous: marvelous
+  matt: matte
+  meagre: meager
+  metre: meter
+  mitre: miter
+  modelling: modeling
+  moustache: mustache
+  neighbour: neighbor
+  normalise: normalize
+  offence: offense
+  organise: organize
+  orientated: oriented
+  paralyse: paralyze
+  plough: plow
+  pretence: pretense
+  programme: program
+  pyjamas: pajamas
+  rateable: ratable
+  realise: realize
+  recognise: recognize
+  reconnoitre: reconnoiter
+  rumour: rumor
+  sabre: saber
+  saleable: salable
+  saltpetre: saltpeter
+  sceptic: skeptic
+  sepulchre: sepulcher
+  signalling: signaling
+  sizeable: sizable
+  skilful: skillful
+  sombre: somber
+  smoulder: smolder
+  speciality: specialty
+  spectre: specter
+  splendour: splendor
+  sulphur: sulfur
+  theatre: theater
+  travelled: traveled
+  traveller: traveler
+  travelling: traveling
+  unshakeable: unshakable
+  wilful: willful
+  yoghurt: yogurt
diff --git a/doc/administration/database_load_balancing.md b/doc/administration/database_load_balancing.md
index cecc372f3874c3d5ed3405b2b2c820f3ae64b6d9..b208a5052cbe1a37461d81c6ca43d194cbcf4ec2 100644
--- a/doc/administration/database_load_balancing.md
+++ b/doc/administration/database_load_balancing.md
@@ -246,7 +246,7 @@ is in sync with the primary. If the data is determined to be recent enough the
 secondary can be used, otherwise it will be ignored. To reduce the overhead of
 these checks we only perform these checks at certain intervals.
 
-There are three configuration options that influence this behaviour:
+There are three configuration options that influence this behavior:
 
 | Option                       | Description                                                                                                    | Default    |
 |------------------------------|----------------------------------------------------------------------------------------------------------------|------------|
diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md
index 6d6aee08c9553fbea76c068cb613bc1ab294ab4e..5b24c222f063e5eb46198d87a642eed56a23fc38 100644
--- a/doc/administration/geo/disaster_recovery/background_verification.md
+++ b/doc/administration/geo/disaster_recovery/background_verification.md
@@ -54,14 +54,14 @@ Feature.enable('geo_repository_verification')
 Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **primary** node and expand
 the **Verification information** tab for that node to view automatic checksumming
 status for repositories and wikis. Successes are shown in green, pending work
-in grey, and failures in red.
+in gray, and failures in red.
 
 ![Verification status](img/verification-status-primary.png)
 
 Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node and expand
 the **Verification information** tab for that node to view automatic verification
 status for repositories and wikis. As with checksumming, successes are shown in
-green, pending work in grey, and failures in red.
+green, pending work in gray, and failures in red.
 
 ![Verification status](img/verification-status-secondary.png)
 
diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md
index 4b3b464b710906cd1bbff0f220ebefbf23b7b76d..00ca1e4b8b01c360861d3db52b1fbad2142cce51 100644
--- a/doc/administration/geo/disaster_recovery/planned_failover.md
+++ b/doc/administration/geo/disaster_recovery/planned_failover.md
@@ -95,7 +95,7 @@ ensure these processes are close to 100% as possible during active use.
 Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node to
 review status. Replicated objects (shown in green) should be close to 100%,
 and there should be no failures (shown in red). If a large proportion of
-objects aren't yet replicated (shown in grey), consider giving the node more
+objects aren't yet replicated (shown in gray), consider giving the node more
 time to complete
 
 ![Replication status](img/replication-status.png)
diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md
index fd5d8694cdf2b7255e9d7177d59496a25b810362..d63afcb8cf92160a32b2383a70d9e5ec99b74560 100644
--- a/doc/administration/high_availability/nfs.md
+++ b/doc/administration/high_availability/nfs.md
@@ -184,7 +184,7 @@ The NFS man page states:
 Read the [Linux man page](https://linux.die.net/man/5/nfs) to understand the difference,
 and if you do use `soft`, ensure that you've taken steps to mitigate the risks.
 
-If you experience behaviour that might have been caused by
+If you experience behavior that might have been caused by
 writes to disk on the NFS server not occurring, such as commits going missing,
 use the `hard` option, because (from the man page):
 
diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index 1b0c7f8a907b4ff04e429717b3703f65c7c02c3f..aec5f7f5566f0129bf511f81720fb67528a0ac85 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -98,9 +98,9 @@ object storage back end, like when Git clients request large files via LFS or wh
 downloading CI artifacts and logs.
 
 When the files are stored on local block storage or NFS, GitLab has to act as a proxy.
-This is not the default behaviour with object storage.
+This is not the default behavior with object storage.
 
-The `proxy_download` setting controls this behaviour: the default is generally `false`.
+The `proxy_download` setting controls this behavior: the default is generally `false`.
 Verify this in the documentation for each use case. Set it to `true` so that GitLab proxies
 the files.
 
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index aaf1ca2908465e6ba01b37adc24c32e19f4c9b6b..102ae32062512bfdfc8176f4758d5e746737da74 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -427,7 +427,7 @@ NOTE: **Note:**
 
 By default, users accessing a registry configured with a remote backend are redirected to the default backend for the storage driver. For example, registries can be configured using the `s3` storage driver, which redirects requests to a remote S3 bucket to alleviate load on the GitLab server.
 
-However, this behaviour is undesirable for registries used by internal hosts that usually can't access public servers. To disable redirects, set the `disable` flag to true as follows. This makes all traffic to always go through the Registry service. This results in improved security (less surface attack as the storage backend is not publicly accessible), but worse performance (all traffic is redirected via the service).
+However, this behavior is undesirable for registries used by internal hosts that usually can't access public servers. To disable redirects, set the `disable` flag to true as follows. This makes all traffic to always go through the Registry service. This results in improved security (less surface attack as the storage backend is not publicly accessible), but worse performance (all traffic is redirected via the service).
 
 **Omnibus GitLab installations**
 
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 3b0a527897edc3691d5a36c81c463e273e2b2ed7..9da1224a9b94047c732ce69acb5b7b4857bbfe8d 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -2607,7 +2607,7 @@ rspec:
 
 > Introduced in GitLab 9.4.
 
-The default behaviour of a caching job is to download the files at the start of
+The default behavior of a caching job is to download the files at the start of
 execution, and to re-upload them at the end. This allows any changes made by the
 job to be persisted for future runs, and is known as the `pull-push` cache
 policy.
@@ -3198,7 +3198,7 @@ job1:
 ### `retry`
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12909) in GitLab 9.5.
-> - [Behaviour expanded](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21758) in GitLab 11.5 to control on which failures to retry.
+> - [Behavior expanded](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21758) in GitLab 11.5 to control on which failures to retry.
 
 `retry` allows you to configure how many times a job is going to be retried in
 case of a failure.
diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index f19016968d4427bcfbd01ab6ea8977f2a9ef6005..68da6b01aabba19d244903555d9df81218f8dcbf 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -110,7 +110,7 @@ When exposing an `ID` field on a type, we will by default try to
 expose a global ID by calling `to_global_id` on the resource being
 rendered.
 
-To override this behaviour, you can implement an `id` method on the
+To override this behavior, you can implement an `id` method on the
 type for which you are exposing an ID. Please make sure that when
 exposing a `GraphQL::ID_TYPE` using a custom method that it is
 globally unique.
@@ -598,7 +598,7 @@ ID. Otherwise use a [globally unique ID](#exposing-global-ids).
 
 We already have a `FullPathLoader` that can be included in other
 resolvers to quickly find Projects and Namespaces which will have a
-lot of dependant objects.
+lot of dependent objects.
 
 To limit the amount of queries performed, we can use `BatchLoader`.
 
diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md
index 948644fa786778aff53c734d543fbb9c9f70de69..25c8cbd3fde9295f2999e3040badc6e228938c16 100644
--- a/doc/development/api_styleguide.md
+++ b/doc/development/api_styleguide.md
@@ -100,7 +100,7 @@ Model.create(foo: params[:foo])
 
 ## Using HTTP status helpers
 
-For non-200 HTTP responses, use the provided helpers in `lib/api/helpers.rb` to ensure correct behaviour (`not_found!`, `no_content!` etc.). These will `throw` inside Grape and abort the execution of your endpoint.
+For non-200 HTTP responses, use the provided helpers in `lib/api/helpers.rb` to ensure correct behavior (`not_found!`, `no_content!` etc.). These will `throw` inside Grape and abort the execution of your endpoint.
 
 For `DELETE` requests, you should also generally use the `destroy_conditionally!` helper which by default returns a `204 No Content` response on success, or a `412 Precondition Failed` response if the given `If-Unmodified-Since` header is out of range. This helper calls `#destroy` on the passed resource, but you can also implement a custom deletion method by passing a block.
 
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index 13ff35ed65cd1857fb089cc45936a177e26410a5..ddd4e84bfd1f5fbbbd055144931830bc514b244c 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -36,7 +36,7 @@ project.
 
 To allow for asynchronous issue handling, we use [milestones](https://gitlab.com/groups/gitlab-org/-/milestones)
 and [labels](https://gitlab.com/gitlab-org/gitlab/-/labels). Leads and product managers handle most of the
-scheduling into milestones. Labelling is a task for everyone.
+scheduling into milestones. Labeling is a task for everyone.
 
 Most issues will have labels for at least one of the following:
 
@@ -156,9 +156,9 @@ As a team needs some way to collect the work their members are planning to be as
 Normally there is a 1:1 relationship between Stage labels and Group labels. In
 the spirit of "Everyone can contribute", any issue can be picked up by any group,
 depending on current priorities. When picking up an issue belonging to a different
-group, it should be relabelled. For example, if an issue labelled `~"devops::create"`
+group, it should be relabeled. For example, if an issue labeled `~"devops::create"`
 and `~"group::knowledge"` is picked up by someone in the Access group of the Plan stage,
-the issue should be relabelled as `~"group::access"` while keeping the original
+the issue should be relabeled as `~"group::access"` while keeping the original
 `~"devops::create"` unchanged.
 
 We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/).
@@ -347,7 +347,7 @@ there is the ~"stewardship" label.
 
 This label is to be used for issues in which the stewardship of GitLab
 is a topic of discussion. For instance if GitLab Inc. is planning to add
-features from GitLab EE to GitLab CE, related issues would be labelled with
+features from GitLab EE to GitLab CE, related issues would be labeled with
 ~"stewardship".
 
 A recent example of this was the issue for
@@ -461,7 +461,7 @@ fixing in the same MR, but not worth creating a follow-up issue for. Renaming a
 method that is used in many places to make its intent slightly clearer may be
 worth fixing, but it should not happen in the same MR, and is generally not
 worth the overhead of having an issue of its own. These issues would invariably
-be labelled `~P4 ~S4` if we were to create them.
+be labeled `~P4 ~S4` if we were to create them.
 
 More severe technical debt can have implications for development velocity. If
 it isn't addressed in a timely manner, the codebase becomes needlessly difficult
diff --git a/doc/development/dangerbot.md b/doc/development/dangerbot.md
index e090281f2bfd32ec507037eb083eb88b805e3524..483559672a7c87adba1b68d09aad215aec18f112 100644
--- a/doc/development/dangerbot.md
+++ b/doc/development/dangerbot.md
@@ -65,7 +65,7 @@ First, be aware of GitLab's [commitment to dogfooding](https://about.gitlab.com/
 The code we write for Danger is GitLab-specific, and it **may not** be most
 appropriate place to implement functionality that addresses a need we encounter.
 Our users, customers, and even our own satellite projects, such as [Gitaly](https://gitlab.com/gitlab-org/gitaly),
-often face similar challenges, after all. Think about how you could fulfil the
+often face similar challenges, after all. Think about how you could fulfill the
 same need while ensuring everyone can benefit from the work, and do that instead
 if you can.
 
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index bd70d5b87ba0c6352fc17a44a6d641a42d594b43..c9fd1b75606d861c8efc47ab7b9b55a4fec51658 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -111,7 +111,7 @@ There are a few gotchas with it:
   smaller methods. Or create a "hook" method that is empty in CE,
   and with the EE-specific implementation in EE.
 - when the original implementation contains a guard clause (e.g.
-  `return unless condition`), we cannot easily extend the behaviour by
+  `return unless condition`), we cannot easily extend the behavior by
   overriding the method, because we can't know when the overridden method
   (i.e. calling `super` in the overriding method) would want to stop early.
   In this case, we shouldn't just override it, but update the original method
@@ -131,7 +131,7 @@ There are a few gotchas with it:
   ```
 
   Instead of just overriding `Base#execute`, we should update it and extract
-  the behaviour into another method:
+  the behavior into another method:
 
   ```ruby
     class Base
@@ -613,9 +613,9 @@ module EE
 end
 ```
 
-#### EE-specific behaviour
+#### EE-specific behavior
 
-Sometimes we need EE-specific behaviour in some of the APIs. Normally we could
+Sometimes we need EE-specific behavior in some of the APIs. Normally we could
 use EE methods to override CE methods, however API routes are not methods and
 therefore can't be simply overridden. We need to extract them into a standalone
 method, or introduce some "hooks" where we could inject behavior in the CE
diff --git a/doc/development/fe_guide/frontend_faq.md b/doc/development/fe_guide/frontend_faq.md
index 3b0b1d8f0da8de641c677b32f7d4158a3c72b3e2..8f8f162609a09f8b0cd9a8efaa9b1c2595e7e43e 100644
--- a/doc/development/fe_guide/frontend_faq.md
+++ b/doc/development/fe_guide/frontend_faq.md
@@ -39,7 +39,7 @@ bundle exec rake routes | grep "issues"
 
 ### 2. `modal_copy_button` vs `clipboard_button`
 
-The `clipboard_button` uses the `copy_to_clipboard.js` behaviour, which is
+The `clipboard_button` uses the `copy_to_clipboard.js` behavior, which is
 initialized on page load, so if there are vue-based clipboard buttons that
 don't exist at page load (such as ones in a `GlModal`), they do not have the
 click handlers associated with the clipboard package.
diff --git a/doc/development/fe_guide/style/javascript.md b/doc/development/fe_guide/style/javascript.md
index 7951c702601c98203a0e9692a09841126449804f..2f0ed3c8918dbcbfa21dc4fb56069b3ea9b27d97 100644
--- a/doc/development/fe_guide/style/javascript.md
+++ b/doc/development/fe_guide/style/javascript.md
@@ -192,7 +192,7 @@ if (isThingNull) {
 
 ## ESLint
 
-ESLint behaviour can be found in our [tooling guide](../tooling.md).
+ESLint behavior can be found in our [tooling guide](../tooling.md).
 
 ## IIFEs
 
diff --git a/doc/development/hash_indexes.md b/doc/development/hash_indexes.md
index 417ea18e22f186e4594a6b05fe95c6a1bd5e18a2..bc962ac0cd6cdbf25b9b8f5424363baf4eda3ecc 100644
--- a/doc/development/hash_indexes.md
+++ b/doc/development/hash_indexes.md
@@ -14,7 +14,7 @@ documentation:
 > answers to queries that subsequently use them. For these reasons, hash index
 > use is presently discouraged.
 
-RuboCop is configured to register an offence when it detects the use of a hash
+RuboCop is configured to register an offense when it detects the use of a hash
 index.
 
 Instead of using hash indexes you should use regular btree indexes.
diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md
index 4a9b5d26aeff95f125f018ae4d8d368d9e7f19ed..b51fc681e2706b3d0041c60afecada2fc711dea5 100644
--- a/doc/development/merge_request_performance_guidelines.md
+++ b/doc/development/merge_request_performance_guidelines.md
@@ -24,7 +24,7 @@ The term `SHOULD` per the [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) means
 > carefully weighed before choosing a different course.
 
 Ideally, each of these tradeoffs should be documented
-in the separate issues, labelled accordingly and linked
+in the separate issues, labeled accordingly and linked
 to original issue and epic.
 
 ## Impact Analysis
diff --git a/doc/development/packages.md b/doc/development/packages.md
index 66b50ce12c87df08308be8a5c4d58b339978e848..c6d874d68154e71580aa94012ce1551c51f80c33 100644
--- a/doc/development/packages.md
+++ b/doc/development/packages.md
@@ -139,7 +139,7 @@ During this phase, the idea is to collect as much information as possible about
 - **Requests**: Which requests are needed to have a working MVC. Ideally, produce
   a list of all the requests needed for the MVC (including required actions). Further
   investigation could provide an example for each request with the request and the response bodies.
-- **Upload**: Carefully analyse how the upload process works. This will probably be the most
+- **Upload**: Carefully analyze how the upload process works. This will probably be the most
   complex request to implement. A detailed analysis is desired here as uploads can be
   encoded in different ways (body or multipart) and can even be in a totally different
   format (for example, a JSON structure where the package file is a Base64 value of
diff --git a/doc/development/performance.md b/doc/development/performance.md
index 5068103ff1614f5db03da0d847375153d6f02127..8eb8c4eada9787fa04273e8d7673230ca40f31c6 100644
--- a/doc/development/performance.md
+++ b/doc/development/performance.md
@@ -109,7 +109,7 @@ In short:
 By collecting snapshots of process state at regular intervals, profiling allows
 you to see where time is spent in a process. The [StackProf](https://github.com/tmm1/stackprof)
 gem is included in GitLab's development environment, allowing you to investigate
-the behaviour of suspect code in detail.
+the behavior of suspect code in detail.
 
 It's important to note that profiling an application *alters its performance*,
 and will generally be done *in an unrepresentative environment*. In particular,
diff --git a/doc/development/reactive_caching.md b/doc/development/reactive_caching.md
index bc5fbb58af98332bad2716b4a9133be8c0a3ded5..0021dceefc87ec0388f1a837fac87a49fc131b63 100644
--- a/doc/development/reactive_caching.md
+++ b/doc/development/reactive_caching.md
@@ -256,7 +256,7 @@ which `calculate_reactive_cache` can be called.
   end
   ```
 
-- The default behaviour can be overridden by defining a custom `reactive_cache_worker_finder`.
+- The default behavior can be overridden by defining a custom `reactive_cache_worker_finder`.
 
   ```ruby
   class Foo < ApplicationRecord
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index 8e34f5490504c19c802288cb52ff358791a60b85..b473c310647203decb9d2ea99e6595f2d65b77bb 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -78,7 +78,7 @@ The output of this example is `#<MatchData "bar">`, as Ruby treats the input `te
 
 #### Impact
 
-This Ruby Regex speciality can have security impact, as often regular expressions are used for validations or to impose restrictions on user-input.
+This Ruby Regex specialty can have security impact, as often regular expressions are used for validations or to impose restrictions on user-input.
 
 #### Examples
 
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 2baf4df8f75ec408cf36b11bc2ecf8286ff89a68..2cf939eddb422e3e339b67ac4409fc2110275301 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -337,7 +337,7 @@ Feature.enabled?(:ci_live_trace, project2) # => true
 
 The code exercised by a single GitLab test may access and modify many items of
 data. Without careful preparation before a test runs, and cleanup afterward,
-data can be changed by a test in such a way that it affects the behaviour of
+data can be changed by a test in such a way that it affects the behavior of
 following tests. This should be avoided at all costs! Fortunately, the existing
 test framework handles most cases already.
 
diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md
index 331b829b34d468181d8edd0820e51bc109854567..a7baec23e38808978b48e4c6b5638377b05860d8 100644
--- a/doc/development/testing_guide/testing_levels.md
+++ b/doc/development/testing_guide/testing_levels.md
@@ -540,7 +540,7 @@ and the basic idea is that the cost of a test includes:
 
 ### Frontend-related tests
 
-There are cases where the behaviour you are testing is not worth the time spent
+There are cases where the behavior you are testing is not worth the time spent
 running the full application, for example, if you are testing styling, animation,
 edge cases or small actions that don't involve the backend,
 you should write an integration test using Jasmine.
diff --git a/doc/development/value_stream_analytics.md b/doc/development/value_stream_analytics.md
index 3ceb523ab73e5d4263328a92abb95807409b27b0..69b07eb7c86a3ac1cf908420d1da195e9eed21f7 100644
--- a/doc/development/value_stream_analytics.md
+++ b/doc/development/value_stream_analytics.md
@@ -185,7 +185,7 @@ Currently supported parents:
 
 The [original implementation](https://gitlab.com/gitlab-org/gitlab/issues/847) of value stream analytics defined 7 stages. These stages are always available for each parent, however altering these stages is not possible.
 ​
-To make things efficient and reduce the number of records created, the default stages are expressed as in-memory objects (not persisted). When the user creates a custom stage for the first time, all the stages will be persisted. This behaviour is implemented in the value stream analytics service objects.
+To make things efficient and reduce the number of records created, the default stages are expressed as in-memory objects (not persisted). When the user creates a custom stage for the first time, all the stages will be persisted. This behavior is implemented in the value stream analytics service objects.
 ​
 The reason for this was that we'd like to add the abilities to hide and order stages later on.
 
diff --git a/doc/development/verifying_database_capabilities.md b/doc/development/verifying_database_capabilities.md
index 1413c782c5d9403ee704a2b0b9b3f00c78b4fd6f..a5f5661ac9b088ffe85dbf905f834bf702318e9d 100644
--- a/doc/development/verifying_database_capabilities.md
+++ b/doc/development/verifying_database_capabilities.md
@@ -2,7 +2,7 @@
 
 Sometimes certain bits of code may only work on a certain database
 version. While we try to avoid such code as much as possible sometimes it is
-necessary to add database (version) specific behaviour.
+necessary to add database (version) specific behavior.
 
 To facilitate this we have the following methods that you can use:
 
diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md
index 325a87215c4683d404e87482191a33f0f0c7187d..03f2ddfc1de49afa7a3d523505a3cbf75f5b97c6 100644
--- a/doc/topics/git/lfs/index.md
+++ b/doc/topics/git/lfs/index.md
@@ -217,7 +217,7 @@ If you push a LFS object to a project and you receive an error similar to:
 the LFS client is trying to reach GitLab through HTTPS. However, your GitLab
 instance is being served on HTTP.
 
-This behaviour is caused by Git LFS using HTTPS connections by default when a
+This behavior is caused by Git LFS using HTTPS connections by default when a
 `lfsurl` is not set in the Git config.
 
 To prevent this from happening, set the lfs url in project Git config:
diff --git a/doc/university/support/README.md b/doc/university/support/README.md
index 0a81a5ddbcdf2c8720ea0b7754c338d940eb014a..5e824bcb6f9cfe00a63e2828ce706e12c9d89d4d 100644
--- a/doc/university/support/README.md
+++ b/doc/university/support/README.md
@@ -103,7 +103,7 @@ Our integrations add great value to GitLab. User questions often relate to integ
 
 ### Learn about the Support process
 
-Zendesk is our Support Centre and our main communication line with our Customers. We communicate with customers through several other channels too
+Zendesk is our Support Center and our main communication line with our Customers. We communicate with customers through several other channels too
 
 - Familiarize yourself with ZenDesk:
   - [UI Overview](https://support.zendesk.com/hc/en-us/articles/203661806-Introduction-to-the-Zendesk-agent-interface)
diff --git a/doc/user/project/integrations/bamboo.md b/doc/user/project/integrations/bamboo.md
index 8c7e6edbf389c41ab4fa1c39bbbf767dc834d58b..db8f24fc1e1d7315fa9d78e375c36cbb89be3b0f 100644
--- a/doc/user/project/integrations/bamboo.md
+++ b/doc/user/project/integrations/bamboo.md
@@ -27,7 +27,7 @@ need to be configured in a Bamboo build plan before GitLab can integrate.
 1. In the left pane, select a build stage. If you have multiple build stages
    you want to select the last stage that contains the Git checkout task.
 1. Select the 'Miscellaneous' tab.
-1. Under 'Pattern Match Labelling' put `${bamboo.repository.revision.number}`
+1. Under 'Pattern Match Labeling' put `${bamboo.repository.revision.number}`
    in the 'Labels' box.
 1. Save
 
diff --git a/doc/user/project/repository/index.md b/doc/user/project/repository/index.md
index 847397ebca9ec73c86f8c8f8182d6adb6d421b54..bcdac86d2a00fcb0ba7f5227d71742fd178f5c2a 100644
--- a/doc/user/project/repository/index.md
+++ b/doc/user/project/repository/index.md
@@ -215,7 +215,7 @@ minutes.
 ![Repository Languages bar](img/repository_languages_v12_2.gif)
 
 Not all files are detected, among others; documentation,
-vendored code, and most markup languages are excluded. This behaviour can be
+vendored code, and most markup languages are excluded. This behavior can be
 adjusted by overriding the default. For example, to enable `.proto` files to be
 detected, add the following to `.gitattributes` in the root of your repository.