diff --git a/docs/development/adding-a-package-manager.md b/docs/development/adding-a-package-manager.md
index f13764d57cdfb64c035b64c4c6e0db88806b9f83..622d8d8ed2215bb136301f4cc4d2cdc3ca8e6a20 100644
--- a/docs/development/adding-a-package-manager.md
+++ b/docs/development/adding-a-package-manager.md
@@ -31,7 +31,7 @@ The function returns an array of detected/extracted dependencies, including:
 - currentValue
 - versioning used (e.g. SemVer, PEP 440)
 
-The `extractPackageFile` function doesn't need to fully _understand_ the file or syntax that it receives.
+The `extractPackageFile` function doesn't need to fully _understand_ the file or syntax that it gets.
 It needs to understand enough to extract an accurate list of dependencies.
 
 As a general approach, we extract _all_ dependencies from each dependency file, even if they contain values we don't support.
diff --git a/docs/development/design-decisions.md b/docs/development/design-decisions.md
index 2df2c70c71405754cb8c8ba05bc7de359ba2ec45..79b0dc69c15c57be201715611d095f6dbbf22c2f 100644
--- a/docs/development/design-decisions.md
+++ b/docs/development/design-decisions.md
@@ -73,7 +73,7 @@ Branches have names like `renovate/webpack-1.x` instead of `renovate/webpack-1.2
 
 We do this because:
 
-- Branches often receive updates (e.g. new patches) before they're merged
+- Branches often get updates (e.g. new patches) before they're merged
 - Naming the branch like `1.x` means its name still makes sense if a `1.2.1` release happens
 
 Note: You can configure the branch names by using the string template `branchName` and/or its sub-templates `branchPrefix` and `branchTopic`.
diff --git a/docs/usage/configuration-options.md b/docs/usage/configuration-options.md
index a0d41726516fe00ecfa6b123cd1dc24c64d53f31..d1e0db27ba5bfe09f3eb1dc9e11873a1fd0faada 100644
--- a/docs/usage/configuration-options.md
+++ b/docs/usage/configuration-options.md
@@ -1011,7 +1011,7 @@ To abort Renovate for errors for a specific `docker` host:
 }
 ```
 
-When this field is enabled, Renovate will abort its run if it encounters either (a) any low-level http error (e.g. `ETIMEDOUT`) or (b) receives a response _not_ matching any of the configured `abortIgnoreStatusCodes` (e.g. `500 Internal Error`);
+When this field is enabled, Renovate will abort its run if it encounters either (a) any low-level http error (e.g. `ETIMEDOUT`) or (b) gets a response _not_ matching any of the configured `abortIgnoreStatusCodes` (e.g. `500 Internal Error`);
 
 ### authType
 
@@ -1973,7 +1973,7 @@ Your test suite takes a bit of time to complete, so if you go look at the new PR
 You're basically waiting until you have the test results, before you can decide if you want to merge the PR or not.
 
 With prCreation set to `not-pending`, Renovate waits until all tests have finished running, and only then creates the PR.
-When you receive the PR notification, you can take action immediately, as you have the full test results.
+When you get the PR notification, you can take action immediately, as you have the full test results.
 
 When you set prCreation to `not-pending` you're reducing the "noise" but get notified of new PRs a bit later.
 
@@ -2535,7 +2535,7 @@ If instead you applied the 3.0.0 update then Renovate would clean up the unneede
 It is recommended that you leave this option to `true`, because of the polite way that Renovate handles this.
 For example, let's say in the above example that you decided you wouldn't update to Webpack 3 for a long time and don't want to build/test every time a new 3.x version arrives.
 In that case, simply close the "Update Webpack to version 3.x" PR and it _won't_ be recreated again even if subsequent Webpack 3.x versions are released.
-You can continue with Webpack 2.x for as long as you want and receive any updates/patches that are made for it.
+You can continue with Webpack 2.x for as long as you want and get any updates/patches that are made for it.
 Then eventually when you do want to update to Webpack 3.x you can make that update to `package.json` yourself and commit it to the base branch once it's tested.
 After that, Renovate will resume providing you updates to 3.x again!
 i.e. if you close a major upgrade PR then it won't come back again, but once you make the major upgrade yourself then Renovate will resume providing you with minor or patch updates.
@@ -2552,7 +2552,7 @@ If you wish to distinguish between patch and minor upgrades, for example if you
 
 ## separateMultipleMajor
 
-Configure this to `true` if you wish to receive one PR for every separate major version upgrade of a dependency.
+Configure this to `true` if you wish to get one PR for every separate major version upgrade of a dependency.
 e.g. if you are on webpack@v1 currently then default behavior is a PR for upgrading to webpack@v3 and not for webpack@v2.
 If this setting is true then you would get one PR for webpack@v2 and one for webpack@v3.
 
@@ -2715,7 +2715,7 @@ For this to work, you must first ensure you have enabled "[Dependency graph](htt
 Additionally, if you are running Renovate in app mode then you must make sure that the app has been granted the permissions to read "Vulnerability alerts".
 If you are the account admin, browse to the app (e.g. [https://github.com/apps/renovate](https://github.com/apps/renovate)), select "Configure", and then scroll down to the "Permissions" section and verify that read access to "vulnerability alerts" is mentioned.
 
-Once the above conditions are met, and you have received one or more vulnerability alerts from GitHub for this repository, then Renovate will attempt to raise fix PRs accordingly.
+Once the above conditions are met, and you got one or more vulnerability alerts from GitHub for this repository, then Renovate will attempt to raise fix PRs accordingly.
 
 Use the `vulnerabilityAlerts` configuration object if you want to customise vulnerability-fix PRs specifically.
 For example, to configure custom labels and assignees:
diff --git a/docs/usage/dependency-pinning.md b/docs/usage/dependency-pinning.md
index 5675c1e61567b1d4ffde1d69d403ec0a31eea5aa..20cdd3b33f67d57e19e9293622b4ea4fb65faa64 100644
--- a/docs/usage/dependency-pinning.md
+++ b/docs/usage/dependency-pinning.md
@@ -75,7 +75,7 @@ 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.
 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 receive a PR for `foobar@1.2.0` which awaits your approval.
+Alternatively, if you were instead pinning `foobar` then you would get a PR for `foobar@1.2.0` which awaits your approval.
 So first of all, you can choose to read the release notes and/or visually inspect the branch yourself before merging, hopefully saving you from pushing this faulty code to production.
 
 If you did not catch the fault before merging, you are still better off with a pinned version.
@@ -88,7 +88,7 @@ As you can see in the above, pinning dependencies makes your build more consiste
 ### Downside of pinned dependencies - upgrade "noise"
 
 The one major downside to your development workflow of pinning dependencies is the potential for increased "noise" in your repository.
-As mentioned above, you can expect to receive Pull Requests whenever there is a new version of your dependencies available.
+As mentioned above, you can expect to get Pull Requests whenever there is a new version of your dependencies available.
 Depending on how many repositories you maintain, and how many dependencies are in each, you may find this default approach to be overwhelming (e.g. waking up to 10 new Pull Requests each day).
 
 ## Reducing the "noise" of dependency updates
@@ -109,7 +109,7 @@ In that case if the `pg` package has a minor or patch update and passes all test
 
 ### Branch automerging
 
-In the above suggestion of Pull Request automerging, you might still find it annoying if you receive GitHub Notifications for every PR that is created and merged.
+In the above suggestion of Pull Request automerging, you might still find it annoying if you get GitHub Notifications for every PR that is created and merged.
 In that case, you could set `automergeType` to `branch`, which means Renovate will:
 
 - Create a new branch for testing
@@ -121,7 +121,7 @@ With this approach, updates will be essentially "silent" - causing no notificati
 
 ### Scheduling
 
-Although it can feel satisfying to receive updates "immediately" when they're available, the reality is that you usually don't _need_ updates so frequently.
+Although it can feel satisfying to get updates "immediately" when they're available, the reality is that you usually don't _need_ updates so frequently.
 And worse still, npm package versions that are less than 24 hours [can be unpublished](https://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy), which would really break your build if you've pinned to a version that no longer exists.
 
 So to reduce the interruptions of automated dependency updates, consider putting Renovate on a schedule, such as:
diff --git a/docs/usage/docker.md b/docs/usage/docker.md
index 5849775303de533f0a6100891f09dbd4a0ad2a05..14eb179cfabc928333ac9c9481364eb95e92de9a 100644
--- a/docs/usage/docker.md
+++ b/docs/usage/docker.md
@@ -93,13 +93,13 @@ Read on to see how Renovate updates Docker digests.
 
 ## Digest Updating
 
-If you follow our advice to go from a simple tag like `node:14` to using a pinned digest `node:14@sha256:d938c1761e3afbae9242848ffbb95b9cc1cb0a24d889f8bd955204d347a7266e`, you will receive Renovate PRs whenever the `node:14` image is updated on Docker Hub.
+If you follow our advice to go from a simple tag like `node:14` to using a pinned digest `node:14@sha256:d938c1761e3afbae9242848ffbb95b9cc1cb0a24d889f8bd955204d347a7266e`, you will get Renovate PRs whenever the `node:14` image is updated on Docker Hub.
 
 Previously this update would have been "invisible" to you - one day you pull code that represents `node:14.15.0` and the next day you get code that represents `node:14.15.1`.
 But you can never be sure, especially as Docker caches.
 Perhaps some of your colleagues or worse still your build machine are stuck on an older version with a security vulnerability.
 
-By pinning to a digest instead, you will receive these updates via Pull Requests, or even committed directly to your repository if you enable branch automerge for convenience.
+By pinning to a digest instead, you will get these updates via Pull Requests, or even committed directly to your repository if you enable branch automerge for convenience.
 This ensures everyone on the team uses the latest versions and is in sync.
 
 ## Version Upgrading
diff --git a/docs/usage/getting-started/installing-onboarding.md b/docs/usage/getting-started/installing-onboarding.md
index 9b46b917a533c9ae900b011b0c7e744735c0199c..26f3d81cc901ba54143ecb99a2e3d52340f0c14d 100644
--- a/docs/usage/getting-started/installing-onboarding.md
+++ b/docs/usage/getting-started/installing-onboarding.md
@@ -41,7 +41,7 @@ For more details on GitLab security for bots, please see the [GitLab Bot Securit
 
 ## Repository onboarding
 
-Once you have enabled Renovate on a repository, you will receive a "Configure Renovate" Pull Request looking something like this:
+Once you have enabled Renovate on a repository, you will get a "Configure Renovate" Pull Request looking something like this:
 
 ![Onboarding](../assets/images/onboarding.png)
 
@@ -134,4 +134,4 @@ Any existing Renovate PRs will be closed after you've completed these steps.
 1. Remove the current Renovate configuration file (e.g. `renovate.json`) from your mainline branch
 
 Following these steps will trick Renovate into thinking that your repository was _never_ onboarded, and will trigger a new "Configure Renovate" PR.
-If you're using the hosted WhiteSource Renovate App and you don't receive a new onboarding PR within a few hours, then please create a Discussions post to request staff trigger it manually.
+If you're using the hosted WhiteSource Renovate App and you don't get a new onboarding PR within a few hours, then please create a Discussions post to request staff trigger it manually.
diff --git a/docs/usage/key-concepts/scheduling.md b/docs/usage/key-concepts/scheduling.md
index 579b76a3064b6ce1d4b5459e1630784cebe5a68a..7eabf25657d00e71b985a245fac26ef337c9c774 100644
--- a/docs/usage/key-concepts/scheduling.md
+++ b/docs/usage/key-concepts/scheduling.md
@@ -8,7 +8,7 @@ This document describes Renovate's scheduling.
 ## Default behavior
 
 By default, Renovate bot runs as often as its administrator has configured it to (e.g. hourly, daily, etc.).
-The exact frequency at which Renovate can process individual repositories depends on the combination of how often it runs, how many repositories are installed, and whether there's a lot of work to be done in each repository (e.g. if a commonly used dependency has recently received a new update, which triggers a lot of PRs to be created).
+The exact frequency at which Renovate can process individual repositories depends on the combination of how often it runs, how many repositories are installed, and whether there's a lot of work to be done in each repository (e.g. if a commonly used dependency has recently gotten a new update, which triggers a lot of PRs to be created).
 
 By default, Renovate schedules use the UTC timezone.
 You can override the default timezone by setting your own `timezone` config option.
diff --git a/lib/manager/terragrunt/readme.md b/lib/manager/terragrunt/readme.md
index 5c1c9d63a22a6cb9b8fa5599a5ffabb5585b45fa..7ed995cc5021fc3300eefc882a88b9f074205410 100644
--- a/lib/manager/terragrunt/readme.md
+++ b/lib/manager/terragrunt/readme.md
@@ -11,7 +11,7 @@ For example, if you want to reference a tag like `module-v1.2.5`, a block like t
 }
 ```
 
-Pinned Terragrunt dependencies like the following will receive a PR whenever there is a newer version available:
+Pinned Terragrunt dependencies like the following will get a PR whenever there is a newer version available:
 
 ```hcl
 terraform {
diff --git a/lib/platform/bitbucket-server/index.md b/lib/platform/bitbucket-server/index.md
index ffd56859d7b0ebd581e5a51edaf702d05247b97d..813bf51fec0bad16dc535e134fb2ffc74e01ad84 100644
--- a/lib/platform/bitbucket-server/index.md
+++ b/lib/platform/bitbucket-server/index.md
@@ -47,7 +47,7 @@ export LOG_LEVEL=debug
 yarn start --autodiscover=true
 ```
 
-You should then receive a "Configure Renovate" onboarding PR in any projects that `@renovate-bot` has been invited to.
+You should then get a "Configure Renovate" onboarding PR in any projects that `@renovate-bot` has been invited to.
 
 ## Supported versions
 
diff --git a/readme.md b/readme.md
index 4aaee96c05179d4f558bde5413b1b45e435c1907..71533fa7baa1ed9911183cca73a6e96d277e22a3 100644
--- a/readme.md
+++ b/readme.md
@@ -12,7 +12,7 @@ Multi-platform and multi-language.
 
 ## Why Use Renovate?
 
-- Receive automated Pull Requests whenever dependencies need updating
+- Get automated Pull Requests whenever dependencies need updating
 - Define schedules to avoid unnecessary noise in projects (e.g. for weekends or outside of working hours, or weekly updates, etc.)
 - Relevant package files are discovered automatically (e.g. supports monorepo architecture such as Lerna or Yarn workspaces without further configuration)
 - Bot behavior is extremely customizable via configuration files (config as code)