diff --git a/doc/administration/auth/ldap/ldap-troubleshooting.md b/doc/administration/auth/ldap/ldap-troubleshooting.md
index b0965818d761246ded0e2bf5e4f7858126113d29..6348dd7d4a41e1c7c786fb6f674ea55febc4e4c4 100644
--- a/doc/administration/auth/ldap/ldap-troubleshooting.md
+++ b/doc/administration/auth/ldap/ldap-troubleshooting.md
@@ -196,7 +196,7 @@ same user) has the email `email@example.com` set as a secondary email, which
 is throwing this error.
 
 We can check where this conflicting email address is coming from using the
-[rails console](#rails-console). Once in the console, run the following:
+[rails console](#rails-console). In the console, run the following:
 
 ```ruby
 # This searches for an email among the primary AND secondary emails
@@ -546,7 +546,7 @@ this entry, it could be due to a mismatched DN stored in GitLab. See
 ```shell
 User with DN `uid=john0,ou=people,dc=example,dc=com` should have access
 to 'my_group' group but there is no user in GitLab with that
-identity. Membership will be updated once the user signs in for
+identity. Membership will be updated when the user signs in for
 the first time.
 ```
 
@@ -556,7 +556,7 @@ Finally, the following entry says syncing has finished for this group:
 Finished syncing all providers for 'my_group' group
 ```
 
-Once all the configured group links have been synchronized, GitLab looks
+When all the configured group links have been synchronized, GitLab looks
 for any Administrators or External users to sync:
 
 ```shell
diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md
index 08b1a15522d00e95665a9f318760763e85a0f3ea..80707afaccaf05b926b5a23d1c89ce2040d42c8c 100644
--- a/doc/administration/geo/disaster_recovery/planned_failover.md
+++ b/doc/administration/geo/disaster_recovery/planned_failover.md
@@ -14,7 +14,7 @@ downtime.
 
 As replication between Geo sites is asynchronous, a planned failover requires
 a maintenance window in which updates to the **primary** site are blocked. The
-length of this window is determined by your replication capacity - once the
+length of this window is determined by your replication capacity - when the
 **secondary** site is completely synchronized with the **primary** site, the failover can occur without
 data loss.
 
diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index df54ea402bdb1727deb7df074d985e307047cc76..e6fc7567ecdc694b0e30869e5d1b590d578b447f 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -306,7 +306,7 @@ For an example of how to set up a location-aware Git remote URL with AWS Route53
 
 ### Backfill
 
-Once a **secondary** site is set up, it starts replicating missing data from
+When a **secondary** site is set up, it starts replicating missing data from
 the **primary** site in a process known as **backfill**. You can monitor the
 synchronization process on each Geo site from the **primary** site's **Geo Nodes**
 dashboard in your browser.
diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index fa74f16cdc8e01b02075d0c2aa25d66240706031..ee92d05c81e976cfadeb8041ea4de4110a171a18 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -239,8 +239,9 @@ keys must be manually replicated to the **secondary** site.
 
    If any of the checks fail, check the [troubleshooting documentation](troubleshooting.md).
 
-Once added to the Geo administration page and restarted, the **secondary** site automatically starts
-replicating missing data from the **primary** site in a process known as **backfill**.
+After the **secondary** site is added to the Geo administration page and restarted,
+the site automatically starts replicating missing data from the **primary** site
+in a process known as **backfill**.
 Meanwhile, the **primary** site starts to notify each **secondary** site of any changes, so
 that the **secondary** site can act on those notifications immediately.
 
diff --git a/doc/administration/geo/replication/remove_geo_site.md b/doc/administration/geo/replication/remove_geo_site.md
index 62b1d9fdf7b0c6b09d7118686e88c478dec5d927..4b9f31dc08c948809e2e637ddbc1898e1eb0b1a2 100644
--- a/doc/administration/geo/replication/remove_geo_site.md
+++ b/doc/administration/geo/replication/remove_geo_site.md
@@ -14,7 +14,8 @@ type: howto
 1. Select the **Remove** button for the **secondary** site you want to remove.
 1. Confirm by selecting **Remove** when the prompt appears.
 
-Once removed from the Geo administration page, you must stop and uninstall the **secondary** site. For each node on your secondary Geo site:
+After the **secondary** site is removed from the Geo administration page, you must
+stop and uninstall this site. For each node on your secondary Geo site:
 
 1. Stop GitLab:
 
@@ -35,7 +36,7 @@ Once removed from the Geo administration page, you must stop and uninstall the *
    sudo rpm --erase gitlab-ee
    ```
 
-Once GitLab has been uninstalled from each node on the **secondary** site, the replication slot must be dropped from the **primary** site's database as follows:
+When GitLab has been uninstalled from each node on the **secondary** site, the replication slot must be dropped from the **primary** site's database as follows:
 
 1. On the **primary** site's database node, start a PostgreSQL console session:
 
diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index 3a87d128792bfff463f9f3c39c4f6b1055d0ea68..fdb1c15970944ccb7e80077b64ac4c4bc592735c 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -619,7 +619,7 @@ If you still haven't [migrated from repmgr to Patroni](#migrating-from-repmgr-to
 1. Before migrating, we recommend that there is no replication lag between the **primary** and **secondary** sites and that replication is paused. In GitLab 13.2 and later, you can pause and resume replication with `gitlab-ctl geo-replication-pause` and `gitlab-ctl geo-replication-resume` on a Geo secondary database node.
 1. Follow the [instructions to migrate repmgr to Patroni](../../postgresql/replication_and_failover.md#switching-from-repmgr-to-patroni). When configuring Patroni on each **primary** site database node, add `patroni['replication_slots'] = { '<slot_name>' => 'physical' }`
 to `gitlab.rb` where `<slot_name>` is the name of the replication slot for your **secondary** site. This ensures that Patroni recognizes the replication slot as permanent and not drop it upon restarting.
-1. If database replication to the **secondary** site was paused before migration, resume replication once Patroni is confirmed working on the **primary** site.
+1. If database replication to the **secondary** site was paused before migration, resume replication after Patroni is confirmed working on the **primary** site.
 
 ### Migrating a single PostgreSQL node to Patroni
 
diff --git a/doc/administration/geo/setup/external_database.md b/doc/administration/geo/setup/external_database.md
index eabed7c10f3aeee580f7807b97950d22b7e8719b..93948d8bec644d162f405f29e0d930a07c80983a 100644
--- a/doc/administration/geo/setup/external_database.md
+++ b/doc/administration/geo/setup/external_database.md
@@ -78,7 +78,7 @@ cloud providers:
 - Azure Database for PostgreSQL - [Create and manage read replicas in Azure Database for PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/single-server/how-to-read-replicas-portal)
 - Google Cloud SQL - [Creating read replicas](https://cloud.google.com/sql/docs/postgres/replication/create-replica)
 
-Once your read-only replica is set up, you can skip to [configure your secondary site](#configure-secondary-site-to-use-the-external-read-replica)
+When your read-only replica is set up, you can skip to [configure your secondary site](#configure-secondary-site-to-use-the-external-read-replica)
 
 #### Manually configure the primary database for replication
 
diff --git a/doc/administration/git_protocol.md b/doc/administration/git_protocol.md
index f900c5a6867da56a726ab469f61df54d17e4aa40..fd9d4347df29b0d37d4c9280e90b41026563cdf6 100644
--- a/doc/administration/git_protocol.md
+++ b/doc/administration/git_protocol.md
@@ -36,7 +36,7 @@ the SSH configuration of your server manually by adding this line to the `/etc/s
 AcceptEnv GIT_PROTOCOL
 ```
 
-Once configured, restart the SSH daemon for the change to take effect:
+When you have configured the SSH daemon, restart it for the change to take effect:
 
 ```shell
 # CentOS 6 / RHEL 6
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index e3b198d10128c295cfdad4419ac31fc4abda7073..415b305056345d46168feb505ed3396f7e094f53 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -285,7 +285,7 @@ praefect['database_direct_dbname'] = 'praefect_production'
 #praefect['database_direct_sslrootcert'] = '...'
 ```
 
-Once configured, this connection is automatically used for the
+When configured, this connection is automatically used for the
 [SQL LISTEN](https://www.postgresql.org/docs/11/sql-listen.html) feature and
 allows Praefect to receive notifications from PostgreSQL for cache invalidation.
 
diff --git a/doc/administration/logs/tracing_correlation_id.md b/doc/administration/logs/tracing_correlation_id.md
index f651455a0883d5764628d935476e082c49a8ae1c..906dcd3cea94ff4e130212bf916402732a7acdb5 100644
--- a/doc/administration/logs/tracing_correlation_id.md
+++ b/doc/administration/logs/tracing_correlation_id.md
@@ -103,7 +103,7 @@ sudo gitlab-ctl tail gitlab-rails/production_json.log | grep '"username":"bob"'
 
 ## Searching your logs for the correlation ID
 
-Once you have the correlation ID you can start searching for relevant log
+When you have the correlation ID you can start searching for relevant log
 entries. You can filter the lines by the correlation ID itself.
 Combining a `find` and `grep` should be sufficient to find the entries you are looking for.
 
diff --git a/doc/administration/maintenance_mode/index.md b/doc/administration/maintenance_mode/index.md
index 12f3c4c1cc3e8d3252e420c2708b277a3fb516f5..91d9c4767e4be527c674939aa153d09284a00293 100644
--- a/doc/administration/maintenance_mode/index.md
+++ b/doc/administration/maintenance_mode/index.md
@@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Maintenance Mode allows administrators to reduce write operations to a minimum while maintenance tasks are performed. The main goal is to block all external actions that change the internal state, including the PostgreSQL database, but especially files, Git repositories, Container repositories, and so on.
 
-Once Maintenance Mode is enabled, in-progress actions finish relatively quickly since no new actions are coming in, and internal state changes are minimal.
+When Maintenance Mode is enabled, in-progress actions finish relatively quickly since no new actions are coming in, and internal state changes are minimal.
 In that state, various maintenance tasks are easier, and services can be stopped completely or be
 further degraded for a much shorter period of time than might otherwise be needed. For example, stopping cron jobs and draining queues should be fairly quick.
 
@@ -150,7 +150,7 @@ is turned off.
 
 Deployments don't go through because pipelines are unfinished.
 
-It is recommended to disable auto deploys during Maintenance Mode, and enable them once it is disabled.
+It is recommended to disable auto deploys during Maintenance Mode, and enable them when it is disabled.
 
 #### Terraform integration
 
diff --git a/doc/administration/monitoring/gitlab_self_monitoring_project/index.md b/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
index e1625ef82317bb1f6e66f7b2c1c7c75599a843d8..35dc64a05947782371c95d5459d6572bdaa6efd6 100644
--- a/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
+++ b/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
@@ -85,7 +85,7 @@ you [configure it manually](../../../user/project/integrations/prometheus.md#man
 You can [add a Prometheus integration](../../../operations/incident_management/integrations.md)
 to GitLab to receive notifications of any alerts.
 
-Once the integration is setup, you can
+When the integration is set up, you can
 [take action on incoming alerts](../../../operations/metrics/alerts.md#trigger-actions-from-alerts).
 
 ## Add custom metrics to the self-monitoring project
@@ -118,4 +118,4 @@ If this returns true, the first administrator user is an external user.
 If you face this issue, you can temporarily
 [make the administrator user a non-external user](../../../user/permissions.md#external-users)
 and then try to create the project.
-Once the project is created, the administrator user can be changed back to an external user.
+After the project is created, the administrator user can be changed back to an external user.
diff --git a/doc/administration/nfs.md b/doc/administration/nfs.md
index b72bc57fd604bef5fb413fe932cda783de425985..084cb189841089cdba53a0c9566eef5a20ef0305 100644
--- a/doc/administration/nfs.md
+++ b/doc/administration/nfs.md
@@ -352,7 +352,7 @@ are empty before attempting a restore. Read more about the
 
 ## Testing NFS
 
-Once you've set up the NFS server and client, you can verify NFS is configured correctly
+When you've set up the NFS server and client, you can verify NFS is configured correctly
 by testing the following commands:
 
 ```shell