diff --git a/doc/administration/auth/atlassian.md b/doc/administration/auth/atlassian.md
index 7c3309346075f7a96f95daf00a0390a3bd5f0111..9da8c9c3c2fa77a48f56882b1380e4368c0921fe 100644
--- a/doc/administration/auth/atlassian.md
+++ b/doc/administration/auth/atlassian.md
@@ -24,9 +24,9 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu
 1. Select **+ Add** in the left sidebar under **APIS AND FEATURES**.
 1. Select **Add** for **Jira platform REST API** and then **Configure**.
 1. Select **Add** next to the following scopes:
-    - **View Jira issue data**
-    - **View user profiles**
-    - **Create and manage issues**
+   - **View Jira issue data**
+   - **View user profiles**
+   - **Create and manage issues**
 
 ## GitLab configuration
 
diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index 8cd8d4c1a3e5479494d7a9de452b71417b52247f..97bcf732904c8d38b95d6f329a2f02c2d968f63a 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -1112,7 +1112,7 @@ response to assign users as administrator based on group membership, configure G
 
 - Where to look for the groups in the OIDC response, using the `groups_attribute` setting.
 - Which group memberships grant the user administrator access, using the
- `admin_groups` setting.
+  `admin_groups` setting.
 
 ::Tabs
 
diff --git a/doc/administration/backup_restore/backup_archive_process.md b/doc/administration/backup_restore/backup_archive_process.md
index 090515f5d9ba93e03eb8f25b772131a04d3913bb..f6ec437933440df704d3305c55addb817cfbf524 100644
--- a/doc/administration/backup_restore/backup_archive_process.md
+++ b/doc/administration/backup_restore/backup_archive_process.md
@@ -35,8 +35,8 @@ To back up Git repositories, the `repositories` sub-task:
 1. Informs `gitaly-backup` which repositories to back up.
 1. Runs `gitaly-backup` to:
 
-    - Call a series of Remote Procedure Calls (RPCs) on Gitaly.
-    - Collect the backup data for each repository.
+   - Call a series of Remote Procedure Calls (RPCs) on Gitaly.
+   - Collect the backup data for each repository.
 
 1. Streams the collected data into a directory structure in the [backup staging directory](#backup-staging-directory).
 
diff --git a/doc/administration/dedicated/configure_instance.md b/doc/administration/dedicated/configure_instance.md
index d8915c95ddf6ac8b42e96f5cfaa9ec348090ff62..b60109c02928026da166be42c0333a0cd0dfb8e8 100644
--- a/doc/administration/dedicated/configure_instance.md
+++ b/doc/administration/dedicated/configure_instance.md
@@ -169,8 +169,8 @@ To enable an Outbound Private Link:
    will be available to GitLab Dedicated. Provide the associated `Service Endpoint Name` on a new
    [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
 1. Make sure you have configured a Network Load Balancer (NLB) for the endpoint service in the AZs to which your Dedicated instance was deployed. If you did not specify these during onboarding to Dedicated, you must either:
-    - Submit a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) to request the AZ IDs required to enable the connection and ensure the NLB is enabled in those AZs.
-    - Ensure the NLB is enabled in every AZ in the region.
+   - Submit a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) to request the AZ IDs required to enable the connection and ensure the NLB is enabled in those AZs.
+   - Ensure the NLB is enabled in every AZ in the region.
 1. In your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650), GitLab will provide you with the ARN of an
    IAM role that will be initiating the connection to your endpoint service. You must ensure this ARN is included, or otherwise covered by other
    entries, in the list of "Allowed Principals" on the Endpoint Service, as described by the [AWS documentation](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-permissions).
@@ -275,25 +275,25 @@ To activate SAML for your GitLab Dedicated instance:
 1. Expand **SAML Config**.
 1. Turn on the **Enable** toggle.
 1. Complete the required fields:
-    - SAML label
-    - IdP cert fingerprint
-    - IdP SSO target URL
+   - SAML label
+   - IdP cert fingerprint
+   - IdP SSO target URL
 1. Optional. To configure users based on SAML group membership, complete the following fields:
-    - SAML group attribute
-    - Admin groups
-    - Auditor groups
-    - External groups
-    - Required groups
+   - SAML group attribute
+   - Admin groups
+   - Auditor groups
+   - External groups
+   - Required groups
 1. Optional. To configure SAML request signing, complete the following fields:
-    - Name identifier format
-    - Attribute statements
-    - Security
+   - Name identifier format
+   - Attribute statements
+   - Security
 1. Select **Save**.
 1. Scroll up to the top of the page and select whether to apply the changes immediately or during the next maintenance window.
 1. Optional. To use group sync, [configure the SAML group links](../../user/group/saml_sso/group_sync.md#configure-saml-group-links).
 1. To verify the SAML configuration is successful:
-    - Check that the SSO button description is displayed on your instance's sign-in page.
-    - Go to the metadata URL of your instance (`https://INSTANCE-URL/users/auth/saml/metadata`). This page can be used to simplify much of the configuration of the identity provider, and manually validate the settings.
+   - Check that the SSO button description is displayed on your instance's sign-in page.
+   - Go to the metadata URL of your instance (`https://INSTANCE-URL/users/auth/saml/metadata`). This page can be used to simplify much of the configuration of the identity provider, and manually validate the settings.
 
 #### Activate SAML with a Support Request
 
diff --git a/doc/administration/dedicated/hosted_runners.md b/doc/administration/dedicated/hosted_runners.md
index d212e0dd56838f4935909c7fb8e3c9af68d9e9b5..ede13320dbad5033c63d18110d38530fc18e1dad 100644
--- a/doc/administration/dedicated/hosted_runners.md
+++ b/doc/administration/dedicated/hosted_runners.md
@@ -176,11 +176,11 @@ To migrate your jobs to use hosted runners:
 1. Use the small Linux x86-64 runner for untagged jobs.
 1. Add the appropriate tags to your job configurations in the `.gitlab-ci.yml` file:
 
-    ```yaml
-    job_name:
-      tags:
-        - linux-medium-amd64  # Use the medium-sized Linux runner
-    ```
+   ```yaml
+   job_name:
+     tags:
+       - linux-medium-amd64  # Use the medium-sized Linux runner
+   ```
 
 1. [Modify the tags](#configure-hosted-runners-in-gitlab) to match your existing job configurations.
 
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 68dcd6d6d66ba37d191469dcdd34a51dda58514f..3f31ade26b9473b557fa4b44442290d267bf9c19 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -1484,8 +1484,8 @@ sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefec
 - `-virtual-storage` is the virtual storage the repository is located in.
 - `-repository` is the repository's relative path in the storage.
 - `-replication-factor` is the desired replication factor of the repository. The minimum value is
- `1`, as the primary needs a copy of the repository. The maximum replication factor is the number of
- storages in the virtual storage.
+  `1`, as the primary needs a copy of the repository. The maximum replication factor is the number of
+  storages in the virtual storage.
 
 On success, the assigned host storages are printed. For example:
 
diff --git a/doc/administration/gitaly/recovery.md b/doc/administration/gitaly/recovery.md
index 5a4cd6f58150a2fa896850c82ec813752caa81b2..7eeab92827af1cdd4411e66433093370e4c14534 100644
--- a/doc/administration/gitaly/recovery.md
+++ b/doc/administration/gitaly/recovery.md
@@ -232,7 +232,7 @@ When accepting data loss, Praefect:
 1. Marks the chosen copy of the repository as the latest version.
 1. Replicates the copy to the other assigned Gitaly nodes.
 
-  This process overwrites any other copy of the repository so care must be taken.
+   This process overwrites any other copy of the repository so care must be taken.
 
 ## Data recovery
 
diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index 6590a4b0335cbd31d9c92d0681409e4c96339fcf..25350a637afd3d1a87169b3d87bd065546e56a23 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -1004,36 +1004,36 @@ In some situations, it may be helpful to test object storage settings using the
 1. Start a [Rails console](operations/rails_console.md).
 1. Set up the object storage connection, using the same parameters you set up in `/etc/gitlab/gitlab.rb`, in the following example format:
 
-Example connection using access keys:
+   Example connection using access keys:
 
-  ```ruby
-  connection = Fog::Storage.new(
-    {
-      provider: 'AWS',
-      region: `eu-central-1`,
-      aws_access_key_id: '<AWS_ACCESS_KEY_ID>',
-      aws_secret_access_key: '<AWS_SECRET_ACCESS_KEY>'
-    }
-  )
-  ```
+   ```ruby
+   connection = Fog::Storage.new(
+     {
+       provider: 'AWS',
+       region: `eu-central-1`,
+       aws_access_key_id: '<AWS_ACCESS_KEY_ID>',
+       aws_secret_access_key: '<AWS_SECRET_ACCESS_KEY>'
+     }
+   )
+   ```
 
-Example connection using AWS IAM Profiles:
+   Example connection using AWS IAM Profiles:
 
-  ```ruby
-  connection = Fog::Storage.new(
-    {
-      provider: 'AWS',
-      use_iam_profile: true,
-      region: 'us-east-1'
-    }
-  )
-  ```
+   ```ruby
+   connection = Fog::Storage.new(
+     {
+       provider: 'AWS',
+       use_iam_profile: true,
+       region: 'us-east-1'
+     }
+   )
+   ```
 
 1. Specify the bucket name to test against, write, and finally read a test file.
 
-  ```ruby
-  dir = connection.directories.new(key: '<bucket-name-here>')
-  f = dir.files.create(key: 'test.txt', body: 'test')
-  pp f
-  pp dir.files.head('test.txt')
-  ```
+   ```ruby
+   dir = connection.directories.new(key: '<bucket-name-here>')
+   f = dir.files.create(key: 'test.txt', body: 'test')
+   pp f
+   pp dir.files.head('test.txt')
+   ```
diff --git a/doc/administration/operations/filesystem_benchmarking.md b/doc/administration/operations/filesystem_benchmarking.md
index 16f20efe3c1e67e3a949c027c22ca0668b10becc..865302577c6303c24af1116dd413a5e734382d6e 100644
--- a/doc/administration/operations/filesystem_benchmarking.md
+++ b/doc/administration/operations/filesystem_benchmarking.md
@@ -107,9 +107,9 @@ executed, and then reads the same 1,000 files.
 
 1. Remove the test files:
 
-  ```shell
-  cd ../; rm -rf test
-  ```
+   ```shell
+   cd ../; rm -rf test
+   ```
 
 The output of the `time for ...` commands resemble the following. The
 important metric is the `real` time.
diff --git a/doc/administration/postgresql/database_load_balancing.md b/doc/administration/postgresql/database_load_balancing.md
index 17dec0e4a85eeb43716f7f5b5582345428004b61..ba508578880ad7eb31f2bcd93def6c518560f5d0 100644
--- a/doc/administration/postgresql/database_load_balancing.md
+++ b/doc/administration/postgresql/database_load_balancing.md
@@ -116,17 +116,17 @@ record. For example:
 
 1. On each GitLab Rails / Sidekiq node, edit `/etc/gitlab/gitlab.rb` and add the following:
 
-  ```ruby
-  gitlab_rails['db_load_balancing'] = { 'discover' => {
-      'nameserver' => 'localhost'
-      'record' => 'postgresql-ha.service.consul'
-      'record_type' => 'A'
-      'port' => '8600'
-      'interval' => '60'
-      'disconnect_timeout' => '120'
-    }
-  }
-  ```
+   ```ruby
+   gitlab_rails['db_load_balancing'] = { 'discover' => {
+       'nameserver' => 'localhost'
+       'record' => 'postgresql-ha.service.consul'
+       'record_type' => 'A'
+       'port' => '8600'
+       'interval' => '60'
+       'disconnect_timeout' => '120'
+     }
+   }
+   ```
 
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -134,12 +134,12 @@ record. For example:
 |----------------------|---------------------------------------------------------------------------------------------------|-----------|
 | `nameserver`         | The nameserver to use for looking up the DNS record.                                              | localhost |
 | `record`             | The record to look up. This option is required for service discovery to work.                     |           |
-| `record_type`        | Optional record type to look up. Can be either `A` or `SRV`.           | `A`       |
+| `record_type`        | Optional record type to look up. Can be either `A` or `SRV`.                                      | `A`       |
 | `port`               | The port of the nameserver.                                                                       | 8600      |
 | `interval`           | The minimum time in seconds between checking the DNS record.                                      | 60        |
 | `disconnect_timeout` | The time in seconds after which an old connection is closed, after the list of hosts was updated. | 120       |
 | `use_tcp`            | Lookup DNS resources using TCP instead of UDP                                                     | false     |
-| `max_replica_pools`  | The maximum number of replicas each Rails process connects to. This is useful if you run a lot of Postgres replicas and a lot of Rails processes because without this limit every Rails process connects to every replica by default. The default behavior is unlimited if not set.                                            | nil     |
+| `max_replica_pools`  | The maximum number of replicas each Rails process connects to. This is useful if you run a lot of Postgres replicas and a lot of Rails processes because without this limit every Rails process connects to every replica by default. The default behavior is unlimited if not set. | nil     |
 
 If `record_type` is set to `SRV`, then GitLab continues to use round-robin algorithm
 and ignores the `weight` and `priority` in the record. Since `SRV` records usually
diff --git a/doc/administration/postgresql/external.md b/doc/administration/postgresql/external.md
index ff6ba1c6f5f561fbe88847c963fd6ec6a1bbe69e..5735f2dbb8cbea508395ec2e495168dbe81c304b 100644
--- a/doc/administration/postgresql/external.md
+++ b/doc/administration/postgresql/external.md
@@ -57,9 +57,9 @@ If you use a cloud-managed service, or provide your own PostgreSQL instance:
 
 1. Restart PostgreSQL to enable the TCP port:
 
-  ```shell
-  sudo gitlab-ctl restart
-  ```
+   ```shell
+   sudo gitlab-ctl restart
+   ```
 
 ## Troubleshooting
 
diff --git a/doc/administration/postgresql/multiple_databases.md b/doc/administration/postgresql/multiple_databases.md
index 06a239738d5fde3f2b507a81ee8e9e5cd0f0afc6..b1ff4b086f932890332ac211bb2678bf31872cc5 100644
--- a/doc/administration/postgresql/multiple_databases.md
+++ b/doc/administration/postgresql/multiple_databases.md
@@ -56,17 +56,17 @@ If something unexpected happens during the migration, it is safe to start over.
 
 1. Verify available disk space:
 
-    - The database node that will store the `gitlabhq_production_ci` database needs enough space to store a copy of the existing database: we _duplicate_ `gitlabhq_production`. Run the following SQL query to find out how much space is needed. Add 25%, to ensure you will not run out of disk space.
+   - The database node that will store the `gitlabhq_production_ci` database needs enough space to store a copy of the existing database: we _duplicate_ `gitlabhq_production`. Run the following SQL query to find out how much space is needed. Add 25%, to ensure you will not run out of disk space.
 
-      ```shell
-      sudo gitlab-psql -c "SELECT pg_size_pretty( pg_database_size('gitlabhq_production') );"
-      ```
+     ```shell
+     sudo gitlab-psql -c "SELECT pg_size_pretty( pg_database_size('gitlabhq_production') );"
+     ```
 
-    - During the process, a dump of the `gitlabhq_production` database needs to be temporarily stored on the filesystem of the node that will run the migration. Execute the following SQL statement to find out how much local disk space will be used. Add 25%, to ensure you will not run out of disk space.
+   - During the process, a dump of the `gitlabhq_production` database needs to be temporarily stored on the filesystem of the node that will run the migration. Execute the following SQL statement to find out how much local disk space will be used. Add 25%, to ensure you will not run out of disk space.
 
-      ```shell
-      sudo gitlab-psql -c "select sum(pg_table_size(concat(table_schema,'.',table_name))) from information_schema.tables where table_catalog = 'gitlabhq_production' and table_type = 'BASE TABLE'"
-      ```
+     ```shell
+     sudo gitlab-psql -c "select sum(pg_table_size(concat(table_schema,'.',table_name))) from information_schema.tables where table_catalog = 'gitlabhq_production' and table_type = 'BASE TABLE'"
+     ```
 
 1. Plan for downtime. The downtime is dependent on the size of the `gitlabhq_production` database.
 
@@ -91,7 +91,7 @@ This process includes downtime. Running the migration script will stop the GitLa
 
 1. Edit `/etc/gitlab/gitlab.rb` and save the changes. Do **not** run the reconfigure command, the migration script will run that for you.
 
-    ```ruby
+   ```ruby
    gitlab_rails['env'] = { 'GITLAB_ALLOW_SEPARATE_CI_DATABASE' => 'true' }
    gitlab_rails['databases']['ci']['enable'] = true
    gitlab_rails['databases']['ci']['db_database'] = 'gitlabhq_production_ci'
diff --git a/doc/administration/postgresql/replication_and_failover.md b/doc/administration/postgresql/replication_and_failover.md
index 8246c3b8bc9d6fbe07530750292453247662511a..33a08be0f8265412bb07ee948325417746bf4f86 100644
--- a/doc/administration/postgresql/replication_and_failover.md
+++ b/doc/administration/postgresql/replication_and_failover.md
@@ -165,9 +165,9 @@ When using default setup, minimum configuration requires:
 - `CONSUL_DATABASE_PASSWORD`. Password for the database user.
 - `CONSUL_PASSWORD_HASH`. This is a hash generated out of Consul username/password pair. It can be generated with:
 
-   ```shell
-   sudo gitlab-ctl pg-password-md5 CONSUL_USERNAME
-   ```
+  ```shell
+  sudo gitlab-ctl pg-password-md5 CONSUL_USERNAME
+  ```
 
 - `CONSUL_SERVER_NODES`. The IP addresses or DNS records of the Consul server nodes.
 
diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md
index 06f7e43fdf2f543e44ee3c508025321fa1183c64..282b93ee54cd2529fa8a2ad81a112bb88ebb87ff 100644
--- a/doc/administration/raketasks/check.md
+++ b/doc/administration/raketasks/check.md
@@ -302,36 +302,36 @@ To reset broken tokens:
 1. Identify the broken tokens. For example `runners_token`.
 1. To reset broken tokens, run `gitlab:doctor:reset_encrypted_tokens` with `VERBOSE=true MODEL_NAMES=Model1,Model2 TOKEN_NAMES=broken_token1,broken_token2`. For example:
 
-    ```shell
-    VERBOSE=true MODEL_NAMES=Project,Group TOKEN_NAMES=runners_token bundle exec rake gitlab:doctor:reset_encrypted_tokens
-    ```
-
-    You will see every action this task would try to perform:
-
-    ```plain
-    I, [2023-09-26T16:20:23.230942 #88920]  INFO -- : Resetting runners_token on Project, Group if they can not be read
-    I, [2023-09-26T16:20:23.230975 #88920]  INFO -- : Executing in DRY RUN mode, no records will actually be updated
-    D, [2023-09-26T16:20:30.151585 #88920] DEBUG -- : > Fix Project[1].runners_token
-    I, [2023-09-26T16:20:30.151617 #88920]  INFO -- : Checked 1/9 Projects
-    D, [2023-09-26T16:20:30.151873 #88920] DEBUG -- : > Fix Project[3].runners_token
-    D, [2023-09-26T16:20:30.152975 #88920] DEBUG -- : > Fix Project[10].runners_token
-    I, [2023-09-26T16:20:30.152992 #88920]  INFO -- : Checked 11/29 Projects
-    I, [2023-09-26T16:20:30.153230 #88920]  INFO -- : Checked 21/29 Projects
-    I, [2023-09-26T16:20:30.153882 #88920]  INFO -- : Checked 29 Projects
-    D, [2023-09-26T16:20:30.195929 #88920] DEBUG -- : > Fix Group[22].runners_token
-    I, [2023-09-26T16:20:30.196125 #88920]  INFO -- : Checked 1/19 Groups
-    D, [2023-09-26T16:20:30.196192 #88920] DEBUG -- : > Fix Group[25].runners_token
-    D, [2023-09-26T16:20:30.197557 #88920] DEBUG -- : > Fix Group[82].runners_token
-    I, [2023-09-26T16:20:30.197581 #88920]  INFO -- : Checked 11/19 Groups
-    I, [2023-09-26T16:20:30.198455 #88920]  INFO -- : Checked 19 Groups
-    I, [2023-09-26T16:20:30.198462 #88920]  INFO -- : Done!
-    ```
+   ```shell
+   VERBOSE=true MODEL_NAMES=Project,Group TOKEN_NAMES=runners_token bundle exec rake gitlab:doctor:reset_encrypted_tokens
+   ```
+
+   You will see every action this task would try to perform:
+
+   ```plain
+   I, [2023-09-26T16:20:23.230942 #88920]  INFO -- : Resetting runners_token on Project, Group if they can not be read
+   I, [2023-09-26T16:20:23.230975 #88920]  INFO -- : Executing in DRY RUN mode, no records will actually be updated
+   D, [2023-09-26T16:20:30.151585 #88920] DEBUG -- : > Fix Project[1].runners_token
+   I, [2023-09-26T16:20:30.151617 #88920]  INFO -- : Checked 1/9 Projects
+   D, [2023-09-26T16:20:30.151873 #88920] DEBUG -- : > Fix Project[3].runners_token
+   D, [2023-09-26T16:20:30.152975 #88920] DEBUG -- : > Fix Project[10].runners_token
+   I, [2023-09-26T16:20:30.152992 #88920]  INFO -- : Checked 11/29 Projects
+   I, [2023-09-26T16:20:30.153230 #88920]  INFO -- : Checked 21/29 Projects
+   I, [2023-09-26T16:20:30.153882 #88920]  INFO -- : Checked 29 Projects
+   D, [2023-09-26T16:20:30.195929 #88920] DEBUG -- : > Fix Group[22].runners_token
+   I, [2023-09-26T16:20:30.196125 #88920]  INFO -- : Checked 1/19 Groups
+   D, [2023-09-26T16:20:30.196192 #88920] DEBUG -- : > Fix Group[25].runners_token
+   D, [2023-09-26T16:20:30.197557 #88920] DEBUG -- : > Fix Group[82].runners_token
+   I, [2023-09-26T16:20:30.197581 #88920]  INFO -- : Checked 11/19 Groups
+   I, [2023-09-26T16:20:30.198455 #88920]  INFO -- : Checked 19 Groups
+   I, [2023-09-26T16:20:30.198462 #88920]  INFO -- : Done!
+   ```
 
 1. If you are confident that this operation resets the correct tokens, disable dry-run mode and run the operation again:
 
-    ```shell
-    DRY_RUN=false VERBOSE=true MODEL_NAMES=Project,Group TOKEN_NAMES=runners_token bundle exec rake gitlab:doctor:reset_encrypted_tokens
-    ```
+   ```shell
+   DRY_RUN=false VERBOSE=true MODEL_NAMES=Project,Group TOKEN_NAMES=runners_token bundle exec rake gitlab:doctor:reset_encrypted_tokens
+   ```
 
 ## Troubleshooting
 
diff --git a/doc/administration/settings/scim_setup.md b/doc/administration/settings/scim_setup.md
index a68b3fb98491a4def5edb1c729c6e3cdbaf40201..89fe2ed175d47654c70510005b69d6d514a046e3 100644
--- a/doc/administration/settings/scim_setup.md
+++ b/doc/administration/settings/scim_setup.md
@@ -34,8 +34,8 @@ To configure GitLab SCIM:
 1. Select **Settings > General**.
 1. Expand the **SCIM Token** section and select **Generate a SCIM token**.
 1. For configuration of your identity provider, save the:
-    - Token from the **Your SCIM token** field.
-    - URL from the **SCIM API endpoint URL** field.
+   - Token from the **Your SCIM token** field.
+   - URL from the **SCIM API endpoint URL** field.
 
 ## Configure an identity provider
 
diff --git a/doc/administration/sidekiq/sidekiq_troubleshooting.md b/doc/administration/sidekiq/sidekiq_troubleshooting.md
index 87264649f1808482b3599bf2612dad43db3d54e8..1394202a22d71b3108fb2874dc85e72f29c7bd1f 100644
--- a/doc/administration/sidekiq/sidekiq_troubleshooting.md
+++ b/doc/administration/sidekiq/sidekiq_troubleshooting.md
@@ -601,20 +601,20 @@ but if you want to clear the idempotency key immediately, follow the following s
 
 1. Find the worker class and `args` of the job in the Sidekiq logs:
 
-  ```plaintext
-  { ... "class":"Geo::VerificationBatchWorker","args":["container_repository"] ... }
-  ```
+   ```plaintext
+   { ... "class":"Geo::VerificationBatchWorker","args":["container_repository"] ... }
+   ```
 
 1. Start a [Rails console session](../operations/rails_console.md#starting-a-rails-console-session).
 1. Run the following snippet:
 
-  ```ruby
-  worker_class = Geo::VerificationBatchWorker
-  args = ["container_repository"]
-  dj = Gitlab::SidekiqMiddleware::DuplicateJobs::DuplicateJob.new({ 'class' => worker_class.name, 'args' => args }, worker_class.queue)
-  dj.send(:idempotency_key)
-  dj.delete!
-  ```
+   ```ruby
+   worker_class = Geo::VerificationBatchWorker
+   args = ["container_repository"]
+   dj = Gitlab::SidekiqMiddleware::DuplicateJobs::DuplicateJob.new({ 'class' => worker_class.name, 'args' => args }, worker_class.queue)
+   dj.send(:idempotency_key)
+   dj.delete!
+   ```
 
 ## CPU saturation in Redis caused by Sidekiq BRPOP calls
 
diff --git a/doc/administration/whats-new.md b/doc/administration/whats-new.md
index 93bd65e33ef1312b5e76e2b84664359f3e10ff9d..93e6ac1703aff21af7f93f1296aa74ae78b3ef38 100644
--- a/doc/administration/whats-new.md
+++ b/doc/administration/whats-new.md
@@ -19,9 +19,9 @@ All users can see the feature list, but the entries might differ depending on th
 - Features only available on GitLab.com are not shown to self-managed installations.
 - Features only available to self-managed installations are not shown on GitLab.com.
 
-   NOTE:
-   For self-managed installations, the updated **What's new** is included
-   in the first patch release after a new version, such as `13.10.1`.
+  NOTE:
+  For self-managed installations, the updated **What's new** is included
+  in the first patch release after a new version, such as `13.10.1`.
 
 ## Access What's new