diff --git a/docs/usage/config-presets.md b/docs/usage/config-presets.md
index b6b168c09e3ceb244f344aedc36a1238b6cb0d4f..9e05cd2f3aaece7600de1a1251e4acf23adc1607 100644
--- a/docs/usage/config-presets.md
+++ b/docs/usage/config-presets.md
@@ -165,7 +165,7 @@ Here is how you would use these in your Renovate config:
 In short, the number of `{{argx}}` parameters in the definition is how many parameters you need to provide.
 Parameters must be strings, non-quoted, and separated by commas if there are more than one.
 
-If you find that you are repeating config a lot, you might consider publishing one of these types of parameterised presets yourself.
+If you find that you are repeating config a lot, you might consider publishing one of these types of parameterized presets yourself.
 Or if you think your preset would be valuable for others, please contribute a PR to the Renovate repository, see [Contributing to presets](#contributing-to-presets).
 
 ## GitHub-hosted Presets
diff --git a/docs/usage/configuration-options.md b/docs/usage/configuration-options.md
index b343f8d8d6fe7de95fd1cf5e5f4e6242f50555bd..726a0c24f4671883067a1d90f0f00138b632d36d 100644
--- a/docs/usage/configuration-options.md
+++ b/docs/usage/configuration-options.md
@@ -459,9 +459,9 @@ For example, To add `[skip ci]` to every commit you could configure:
 }
 ```
 
-Another example would be if you want to configure a DCO signoff to each commit.
+Another example would be if you want to configure a DCO sign off to each commit.
 
-If you want Renovate to signoff its commits, add the [`:gitSignOff` preset](./presets-default.md#gitsignoff) to your `extends` array:
+If you want Renovate to sign off its commits, add the [`:gitSignOff` preset](./presets-default.md#gitsignoff) to your `extends` array:
 
 ```json
 {
@@ -531,12 +531,12 @@ Composer `2.2` and up will be run with `--ignore-platform-req='ext-*' --ignore-p
 Older Composer versions will be run with `--ignore-platform-reqs`, which means that all platform constraints (including the PHP version) will be ignored by default.
 This can result in updated dependencies that are not compatible with your platform.
 
-To customize this behaviour, you can explicitly ignore platform requirements (for example `ext-zip`) by setting them separately in this array.
+To customize this behavior, you can explicitly ignore platform requirements (for example `ext-zip`) by setting them separately in this array.
 Each item will be added to the Composer command with `--ignore-platform-req`, resulting in it being ignored during its invocation.
 Note that this requires your project to use Composer V2, as V1 doesn't support excluding single platform requirements.
 The used PHP version will be guessed automatically from your `composer.json` definition, so `php` should not be added as explicit dependency.
 
-If an empty array is configured, Renovate uses its default behaviour.
+If an empty array is configured, Renovate uses its default behavior.
 
 Set to `null` (not recommended) to fully omit `--ignore-platform-reqs/--ignore-platform-req` during Composer invocation.
 This requires the Renovate image to be fully compatible with your Composer platform requirements in order for the Composer invocation to succeed, otherwise Renovate will fail to create the updated lock file.
@@ -1412,7 +1412,7 @@ For now, you can only use this option on the GitLab platform.
 
 For `followTag` to work, the datasource must support distribution streams or tags, like for example npm does.
 
-The main usecase is to follow a pre-release tag of a dependency, say TypeScripts's `"insiders"` build:
+The main use case is to follow a pre-release tag of a dependency, say TypeScripts's `"insiders"` build:
 
 ```json
 {
@@ -2165,7 +2165,7 @@ Consider this example:
 
 With the above config, every PR raised by Renovate will have the label `dependencies` while PRs containing `eslint`-related packages will instead have the label `linting`.
 
-Behaviour details:
+Behavior details:
 
 - On GitHub, GitLab and Gitea: Renovate will keep PR labels in sync with configured labels, provided that no other user or bot has made changes to the labels after PR creation. If labels are changed by any other account, Renovate will stop making further changes.
 - For other platforms, Renovate will add labels only at time of PR creation and not update them after that.
diff --git a/docs/usage/dependency-pinning.md b/docs/usage/dependency-pinning.md
index f001c127f2e41e074323ca6af4f2a0ea71f2863d..2503bb40bfdd386e6c565f9e21f4df577d2c4638 100644
--- a/docs/usage/dependency-pinning.md
+++ b/docs/usage/dependency-pinning.md
@@ -6,7 +6,7 @@ description: The pros and cons of dependency pinning for JavaScript/npm
 # Should you Pin your JavaScript Dependencies?
 
 Once you start using a tool/service like Renovate, probably the biggest decision you need to make is whether to "pin" your dependencies instead of using SemVer ranges.
-The answer is "It's your choice", but we can certainly make some generalisations/recommendations to help you.
+The answer is "It's your choice", but we can certainly make some generalizations/recommendations to help you.
 
 If you don't want to read the in-depth discussion, you can skip ahead to our recommendations in the ["So what's best?" section](#so-whats-best).
 
@@ -72,7 +72,7 @@ By pinning dependencies you know exactly what you're running and you know exactl
 Now consider a similar theoretical scenario where `foobar@1.2.0` is faulty but it is _not_ caught by any of your automated tests.
 This is more common and more dangerous.
 
-If you were using SemVer ranges then this new version of `foobar` will likely be deployed to production automatically one day, sometime after which you notice errors and realise you need to fix it.
+If you were using SemVer ranges then this new version of `foobar` will likely be deployed to production automatically one day, sometime after which you notice errors and realize you need to fix it.
 Like before, you need to manually work out which dependency caused it - assuming you guess correctly that it was a new dependency version at fault - and pin it manually by editing `package.json` one dependency at a time.
 
 Alternatively, if you were instead pinning `foobar` then you would get a PR for `foobar@1.2.0` which awaits your approval.
diff --git a/docs/usage/examples/self-hosting.md b/docs/usage/examples/self-hosting.md
index 2d5311451725f9212b998d742aafc31e2c4daa5a..1e457fc670e297bc9549c4b275677984a7172381 100644
--- a/docs/usage/examples/self-hosting.md
+++ b/docs/usage/examples/self-hosting.md
@@ -384,7 +384,7 @@ spec:
 ## Logging
 
 If you're ingesting/parsing logs into another system then we recommend you set `LOG_LEVEL=debug` and `LOG_FORMAT=json` in your environment variables.
-Debug logging is usually needed for any debugging, while JSON format will mean that the output is parseable.
+Debug logging is usually needed for any debugging, while JSON format will mean that the output is parsable.
 
 ### About the log level numbers
 
diff --git a/docs/usage/upgrade-best-practices.md b/docs/usage/upgrade-best-practices.md
index f180921b866872c1d4efa234d94b7374adfe7db0..9f95f0714aac0a6f60ba02cc99c350145c4be98e 100644
--- a/docs/usage/upgrade-best-practices.md
+++ b/docs/usage/upgrade-best-practices.md
@@ -80,7 +80,7 @@ The [GitHub Docs, using third-party actions](https://docs.github.com/en/actions/
 We recommend pinning _all_ Actions.
 That's why the `helpers:pinGitHubActionDigests` preset pins all GitHub Actions.
 
-For an in-depth explanation why you should pin your Github Actions, read the [Palo Alto Networks blogpost about the GitHub Actions worm](https://www.paloaltonetworks.com/blog/prisma-cloud/github-actions-worm-dependencies/).
+For an in-depth explanation why you should pin your Github Actions, read the [Palo Alto Networks blog post about the GitHub Actions worm](https://www.paloaltonetworks.com/blog/prisma-cloud/github-actions-worm-dependencies/).
 
 #### Extends `:pinDevDependencies`
 
diff --git a/docs/usage/user-stories/swissquote.md b/docs/usage/user-stories/swissquote.md
index e7f187f6bd2e8e50bdd93606a64fa57c15e8a837..c11367f0cf180bb8130b581365c7c4aba5f24cd7 100644
--- a/docs/usage/user-stories/swissquote.md
+++ b/docs/usage/user-stories/swissquote.md
@@ -10,7 +10,7 @@
 > This article was originally published on [Medium](https://medium.com/swissquote-engineering/how-swissquote-is-keeping-software-dependencies-up-to-date-with-renovate-6246e8b20437) by [Stéphane Goetz](https://onigoetz.ch/), Principal Software Engineer at [Swissquote Bank](https://github.com/swissquote/).
 
 Swissquote has more than 1000 distinct applications running in production.
-They come in many different flavors including services, daemons, and webapps, and their age can be counted from days to more than a decade.
+They come in many different flavors including services, daemons, and web apps, and their age can be counted from days to more than a decade.
 While there are many topics of interest when talking about software maintenance, today’s topic is software dependencies.
 We’ll see in this article why it’s important to keep them up-to-date and why it’s not as simple as one may think.
 
diff --git a/lib/config/options/index.ts b/lib/config/options/index.ts
index 0932f04a07bd14d9fcaf440f4b8a7af02cb6d650..d046fecc06a33f154dc393f270121dcb74cc3db4 100644
--- a/lib/config/options/index.ts
+++ b/lib/config/options/index.ts
@@ -1578,7 +1578,7 @@ const options: RenovateOptions[] = [
     cli: false,
     env: false,
   },
-  // Version behaviour
+  // Version behavior
   {
     name: 'allowedVersions',
     description:
@@ -1840,7 +1840,7 @@ const options: RenovateOptions[] = [
     allowedValues: ['auto', 'never'],
     default: 'auto',
   },
-  // PR Behaviour
+  // PR Behavior
   {
     name: 'keepUpdatedLabel',
     description:
diff --git a/lib/modules/datasource/go/base.ts b/lib/modules/datasource/go/base.ts
index 3bde8e040f1ab3e2c9b28ec9cd84c7010f014e4f..f963490eebf5a616b72ff6dff7322e00940d9424 100644
--- a/lib/modules/datasource/go/base.ts
+++ b/lib/modules/datasource/go/base.ts
@@ -255,7 +255,7 @@ export class BaseGoDatasource {
     if (datasource !== null) {
       return datasource;
     }
-    // fall back to old behaviour if detection did not work
+    // fall back to old behavior if detection did not work
 
     switch (detectPlatform(goImportURL)) {
       case 'github': {
diff --git a/lib/modules/manager/npm/utils.spec.ts b/lib/modules/manager/npm/utils.spec.ts
index 039b520e8c641a1a04fec0e7fffe82b2cef325f2..b154a83325b408e86c4f6fdbe2a9b8a1dc2dadb1 100644
--- a/lib/modules/manager/npm/utils.spec.ts
+++ b/lib/modules/manager/npm/utils.spec.ts
@@ -54,7 +54,7 @@ describe('modules/manager/npm/utils', () => {
       expect(lockFileComposed).toMatchSnapshot();
     });
 
-    it('adds trailing newline to match npms behaviour and avoid diffs', () => {
+    it('adds trailing newline to match npms behavior and avoid diffs', () => {
       const lockFile = Fixtures.get('lockfile-parsing/package-lock.json');
       const { detectedIndent, lockFileParsed } = parseLockFile(lockFile);
       // TODO #22198
diff --git a/lib/modules/platform/gitlab/index.ts b/lib/modules/platform/gitlab/index.ts
index 8f8b4debf45fd2b4ab97f075a9afe34eac7d13e1..e5b1e89368c945ddc8efb608627288e780c3842f 100644
--- a/lib/modules/platform/gitlab/index.ts
+++ b/lib/modules/platform/gitlab/index.ts
@@ -267,7 +267,7 @@ function getRepoUrl(
     res.body.http_url_to_repo === null
   ) {
     if (res.body.http_url_to_repo === null) {
-      logger.debug('no http_url_to_repo found. Falling back to old behaviour.');
+      logger.debug('no http_url_to_repo found. Falling back to old behavior.');
     }
     if (process.env.GITLAB_IGNORE_REPO_URL) {
       logger.warn(
diff --git a/lib/modules/versioning/rez/pattern.ts b/lib/modules/versioning/rez/pattern.ts
index 8eac443ec6a5c02a07b9df14a16c610eedae802d..96741017db5045040ab6dda2da8f7cf4f5811016 100644
--- a/lib/modules/versioning/rez/pattern.ts
+++ b/lib/modules/versioning/rez/pattern.ts
@@ -70,7 +70,7 @@ export const matchVersion = regEx(
 export const exactVersion = regEx(
   `^(?<exact_version>==(?<exact_version_group>${versionGroup})?)$`,
 ); /* Match an exact version number (e.g. ==1.0.0) */
-// inclusiveBound is called inclusive but behaviour in rez is this:
+// inclusiveBound is called inclusive but behavior in rez is this:
 // package-1..3 will match versions 1.2.3, 2.3.4, but not 3.0.0 or above
 export const inclusiveBound = regEx(
   `^(?<inclusive_bound>(?<inclusive_lower_version>${versionGroup})?\\.\\.(?<inclusive_upper_version>${versionGroup})?)$`,
diff --git a/tools/jest.mjs b/tools/jest.mjs
index 914cf82b36b106c6c0eebe39de6b20cd0c211abe..9a2c8830eb5a97ff7a3bf495a7cbabb6eaabdc10 100644
--- a/tools/jest.mjs
+++ b/tools/jest.mjs
@@ -14,7 +14,7 @@ const args = ['--experimental-vm-modules'];
  * - #27375
  * - https://nodejs.org/en/blog/vulnerability/february-2024-security-releases#nodejs-is-vulnerable-to-the-marvin-attack-timing-variant-of-the-bleichenbacher-attack-against-pkcs1-v15-padding-cve-2023-46809---medium
  *
- * Sadly there is no way to suppress `SECURITY WARNING: Reverting CVE-2023-46809: Marvin attack on PKCS#1 padding` warining
+ * Sadly there is no way to suppress this warning: `SECURITY WARNING: Reverting CVE-2023-46809: Marvin attack on PKCS#1 padding`
  */
 if (semver.satisfies(version, '^18.19.1 || ^20.11.1 || >=21.6.2')) {
   args.push('--security-revert=CVE-2023-46809');