Add latest changes from gitlab-org/gitlab@16-1-stable-eev16.1.0-rc42

936 files changed, 24981 insertions, 13903 deletions

diff --git a/doc/.vale/gitlab/OutdatedVersions.yml b/doc/.vale/gitlab/OutdatedVersions.yml
index 10fbaa0a676..e55c3063bbb 100644
--- a/doc/.vale/gitlab/OutdatedVersions.yml
+++ b/doc/.vale/gitlab/OutdatedVersions.yml
@@ -22,3 +22,4 @@ tokens:
   - "GitLab (v)?10."
   - "GitLab (v)?11."
   - "GitLab (v)?12."
+  - "GitLab (v)?13."
diff --git a/doc/.vale/gitlab/SubstitutionWarning.yml b/doc/.vale/gitlab/SubstitutionWarning.yml
index 8f3d3330271..fa4a0960d9c 100644
--- a/doc/.vale/gitlab/SubstitutionWarning.yml
+++ b/doc/.vale/gitlab/SubstitutionWarning.yml
@@ -33,6 +33,8 @@ swap:
   n/a: "not applicable"
   navigate to: "go to"
   OAuth2: "OAuth 2.0"
+  omnibus gitlab: "Linux package"
+  'omnibus(?!\))': "Linux package"
   once that: "after that"
   once the: "after the"
   once you: "after you"
diff --git a/doc/.vale/gitlab/Substitutions.yml b/doc/.vale/gitlab/Substitutions.yml
index 225e4e74880..10369669ca5 100644
--- a/doc/.vale/gitlab/Substitutions.yml
+++ b/doc/.vale/gitlab/Substitutions.yml
@@ -18,7 +18,7 @@ swap:
   GitLabber: GitLab team member
   GitLabbers: GitLab team members
   GitLab-shell: GitLab Shell
-  gitlab omnibus: Omnibus GitLab
+  gitlab omnibus: Linux package
   param: parameter
   params: parameters
   pg: PostgreSQL
diff --git a/doc/.vale/gitlab/Uppercase.yml b/doc/.vale/gitlab/Uppercase.yml
index 1948842d026..4730184b950 100644
--- a/doc/.vale/gitlab/Uppercase.yml
+++ b/doc/.vale/gitlab/Uppercase.yml
@@ -57,6 +57,7 @@ exceptions:
   - DHCP
   - DML
   - DNS
+  - DSN
   - DOM
   - DORA
   - DSA
diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt
index 476b1eebf84..4bed441ba9d 100644
--- a/doc/.vale/gitlab/spelling-exceptions.txt
+++ b/doc/.vale/gitlab/spelling-exceptions.txt
@@ -309,6 +309,7 @@ dput
 Dreamweaver
 DRIs
 DSLs
+DSN
 Dynatrace
 Ecto
 eden
diff --git a/doc/administration/audit_event_streaming.md b/doc/administration/audit_event_streaming.md
index afc4926fec0..d6a6725210d 100644
--- a/doc/administration/audit_event_streaming.md
+++ b/doc/administration/audit_event_streaming.md
@@ -1,979 +1,11 @@
 ---
-stage: Govern
-group: Compliance
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: 'audit_event_streaming/index.md'
+remove_date: '2023-09-12'
 ---
 
-# Audit event streaming **(ULTIMATE)**
+This document was moved to [another location](audit_event_streaming/index.md).
 
-> - API [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332747) in GitLab 14.5 [with a flag](../administration/feature_flags.md) named `ff_external_audit_events_namespace`. Disabled by default.
-> - API [Enabled on GitLab.com and by default on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/338939) in GitLab 14.7.
-> - API [Feature flag `ff_external_audit_events_namespace`](https://gitlab.com/gitlab-org/gitlab/-/issues/349588) removed in GitLab 14.8.
-> - UI [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/336411) in GitLab 14.9.
-> - [Subgroup events recording](https://gitlab.com/gitlab-org/gitlab/-/issues/366878) fixed in GitLab 15.2.
-> - Custom HTTP headers API [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/361216) in GitLab 15.1 [with a flag](feature_flags.md) named `streaming_audit_event_headers`. Disabled by default.
-> - Custom HTTP headers API [enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/362941) in GitLab 15.2.
-> - Custom HTTP headers API [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/366524) in GitLab 15.3. [Feature flag `streaming_audit_event_headers`](https://gitlab.com/gitlab-org/gitlab/-/issues/362941) removed.
-> - Custom HTTP headers UI [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/361630) in GitLab 15.2 [with a flag](feature_flags.md) named `custom_headers_streaming_audit_events_ui`. Disabled by default.
-> - Custom HTTP headers UI [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/365259) in GitLab 15.3. [Feature flag `custom_headers_streaming_audit_events_ui`](https://gitlab.com/gitlab-org/gitlab/-/issues/365259) removed.
-> - [Improved user experience](https://gitlab.com/gitlab-org/gitlab/-/issues/367963) in GitLab 15.3.
-> - User-specified verification token API support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360813) in GitLab 15.4.
-> - Event type filters API [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/344845) in GitLab 15.7.
-
-Users can set a streaming destination for a top-level group to receive all audit events about the group, its subgroups, and
-projects as structured JSON.
-
-Top-level group owners can manage their audit logs in third-party systems. Any service that can receive
-structured JSON data can be used as the streaming destination.
-
-Each streaming destination can have up to 20 custom HTTP headers included with each streamed event.
-
-NOTE:
-GitLab can stream a single event more than once to the same destination. Use the `id` key in the payload to deduplicate incoming data.
-
-## Add a new streaming destination
-
-WARNING:
-Streaming destinations receive **all** audit event data, which could include sensitive information. Make sure you trust the streaming destination.
-
-### Use the GitLab UI
-
-Users with the Owner role for a group can add streaming destinations for it:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Audit events**.
-1. On the main area, select **Streams** tab.
-1. Select **Add streaming destination** to show the section for adding destinations.
-1. Enter the destination URL to add.
-1. Optional. Locate the **Custom HTTP headers** table.
-1. Ignore the **Active** checkbox because it isn't functional. To track progress on adding functionality to the
-   **Active** checkbox, see [issue 367509](https://gitlab.com/gitlab-org/gitlab/-/issues/367509).
-1. Select **Add header** to create a new name and value pair. Enter as many name and value pairs as required. You can add up to
-   20 headers per streaming destination.
-1. After all headers have been filled out, select **Add** to add the new streaming destination.
-
-### Use the API
-
-To enable streaming and add a destination, users with the Owner role for a group must use the
-`externalAuditEventDestinationCreate` mutation in the GraphQL API.
-
-```graphql
-mutation {
-  externalAuditEventDestinationCreate(input: { destinationUrl: "https://mydomain.io/endpoint/ingest", groupPath: "my-group" } ) {
-    errors
-    externalAuditEventDestination {
-      id
-      destinationUrl
-      verificationToken
-      group {
-        name
-      }
-    }
-  }
-}
-```
-
-Group owners can also optionally specify their own verification token (instead of the default GitLab-generated one) using the GraphQL `auditEventsStreamingHeadersCreate`
-mutation. Verification token length must be within 16 to 24 characters and trailing whitespace are not trimmed. GitLab recommends setting a cryptographically random and unique value. For example:
-
-```graphql
-mutation {
-  externalAuditEventDestinationCreate(input: { destinationUrl: "https://mydomain.io/endpoint/ingest", groupPath: "my-group", verificationToken: "unique-random-verification-token-here" } ) {
-    errors
-    externalAuditEventDestination {
-      id
-      destinationUrl
-      verificationToken
-      group {
-        name
-      }
-    }
-  }
-}
-```
-
-Event streaming is enabled if:
-
-- The returned `errors` object is empty.
-- The API responds with `200 OK`.
-
-Group owners can add an HTTP header using the GraphQL `auditEventsStreamingHeadersCreate` mutation. You can retrieve the destination ID
-by [listing all the streaming destinations](#use-the-api-1) for the group or from the mutation above.
-
-```graphql
-mutation {
-  auditEventsStreamingHeadersCreate(input: { destinationId: "gid://gitlab/AuditEvents::ExternalAuditEventDestination/24601", key: "foo", value: "bar" }) {
-    errors
-  }
-}
-```
-
-The header is created if the returned `errors` object is empty.
-
-## List streaming destinations
-
-Users with the Owner role for a group can list streaming destinations.
-
-### Use the GitLab UI
-
-To list the streaming destinations:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Audit events**.
-1. On the main area, select **Streams** tab.
-1. To the right of the item, select **Edit** (**{pencil}**) to see all the custom HTTP headers.
-
-### Use the API
-
-Users with the Owner role for a group can view a list of streaming destinations at any time using the
-`externalAuditEventDestinations` query type.
-
-```graphql
-query {
-  group(fullPath: "my-group") {
-    id
-    externalAuditEventDestinations {
-      nodes {
-        destinationUrl
-        verificationToken
-        id
-        headers {
-          nodes {
-            key
-            value
-            id
-          }
-        }
-        eventTypeFilters
-      }
-    }
-  }
-}
-```
-
-If the resulting list is empty, then audit streaming is not enabled for that group.
-
-You need the ID values returned by this query for the update and delete mutations.
-
-## Update streaming destinations
-
-Users with the Owner role for a group can update streaming destinations.
-
-### Use the GitLab UI
-
-To update a streaming destinations custom HTTP headers:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Audit events**.
-1. On the main area, select **Streams** tab.
-1. To the right of the item, select **Edit** (**{pencil}**).
-1. Locate the **Custom HTTP headers** table.
-1. Locate the header that you wish to update.
-1. Ignore the **Active** checkbox because it isn't functional. To track progress on adding functionality to the
-   **Active** checkbox, see [issue 367509](https://gitlab.com/gitlab-org/gitlab/-/issues/367509).
-1. Select **Add header** to create a new name and value pair. Enter as many name and value pairs as required. You can add up to
-   20 headers per streaming destination.
-1. Select **Save** to update the streaming destination.
-
-### Use the API
-
-Users with the Owner role for a group can update streaming destinations custom HTTP headers using the
-`auditEventsStreamingHeadersUpdate` mutation type. You can retrieve the custom HTTP headers ID
-by [listing all the custom HTTP headers](#use-the-api-1) for the group.
-
-```graphql
-mutation {
-  externalAuditEventDestinationDestroy(input: { id: destination }) {
-    errors
-  }
-}
-```
-
-Streaming destination is updated if:
-
-- The returned `errors` object is empty.
-- The API responds with `200 OK`.
-
-Group owners can remove an HTTP header using the GraphQL `auditEventsStreamingHeadersDestroy` mutation. You can retrieve the header ID
-by [listing all the custom HTTP headers](#use-the-api-1) for the group.
-
-```graphql
-mutation {
-  auditEventsStreamingHeadersDestroy(input: { headerId: "gid://gitlab/AuditEvents::Streaming::Header/1" }) {
-    errors
-  }
-}
-```
-
-The header is deleted if the returned `errors` object is empty.
-
-## Delete streaming destinations
-
-Users with the Owner role for a group can delete streaming destinations.
-
-When the last destination is successfully deleted, streaming is disabled for the group.
-
-### Use the GitLab UI
-
-To delete a streaming destination:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Audit events**.
-1. On the main area, select the **Streams** tab.
-1. To the right of the item, select **Delete** (**{remove}**).
-
-To delete only the custom HTTP headers for a streaming destination:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Audit events**.
-1. On the main area, select the **Streams** tab.
-1. To the right of the item, **Edit** (**{pencil}**).
-1. Locate the **Custom HTTP headers** table.
-1. Locate the header that you wish to remove.
-1. To the right of the header, select **Delete** (**{remove}**).
-1. Select **Save** to update the streaming destination.
-
-### Use the API
-
-Users with the Owner role for a group can delete streaming destinations using the
-`externalAuditEventDestinationDestroy` mutation type. You can retrieve the destinations ID
-by [listing all the streaming destinations](#use-the-api-1) for the group.
-
-```graphql
-mutation {
-  externalAuditEventDestinationDestroy(input: { id: destination }) {
-    errors
-  }
-}
-```
-
-Streaming destination is deleted if:
-
-- The returned `errors` object is empty.
-- The API responds with `200 OK`.
-
-Group owners can remove an HTTP header using the GraphQL `auditEventsStreamingHeadersDestroy` mutation. You can retrieve the header ID
-by [listing all the custom HTTP headers](#use-the-api-1) for the group.
-
-```graphql
-mutation {
-  auditEventsStreamingHeadersDestroy(input: { headerId: "gid://gitlab/AuditEvents::Streaming::Header/1" }) {
-    errors
-  }
-}
-```
-
-The header is deleted if the returned `errors` object is empty.
-
-## Verify event authenticity
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345424) in GitLab 14.8.
-
-Each streaming destination has a unique verification token (`verificationToken`) that can be used to verify the authenticity of the event. This
-token is either specified by the Owner or generated automatically when the event destination is created and cannot be changed.
-
-Each streamed event contains the verification token in the `X-Gitlab-Event-Streaming-Token` HTTP header that can be verified against
-the destination's value when [listing streaming destinations](#list-streaming-destinations).
-
-### Use the GitLab UI
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360814) in GitLab 15.2.
-
-Users with the Owner role for a group can list streaming destinations and see the verification tokens:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Audit events**.
-1. On the main area, select the **Streams**.
-1. View the verification token on the right side of each item.
-
-## Event type filters
-
-> Event type filters API [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/344845) in GitLab 15.7.
-
-When this feature is enabled for a group, you can use an API to permit users to filter streamed audit events per destination.
-If the feature is enabled with no filters, the destination receives all audit events.
-
-A streaming destination that has an event type filter set has a **filtered** (**{filter}**) label.
-
-### Use the API to add an event type filter
-
-Prerequisites:
-
-- You must have the Owner role for the group.
-
-You can add a list of event type filters using the `auditEventsStreamingDestinationEventsAdd` query type:
-
-```graphql
-mutation {
-    auditEventsStreamingDestinationEventsAdd(input: {
-        destinationId: "gid://gitlab/AuditEvents::ExternalAuditEventDestination/1",
-        eventTypeFilters: ["list of event type filters"]}){
-        errors
-        eventTypeFilters
-    }
-}
-```
-
-Event type filters are added if:
-
-- The returned `errors` object is empty.
-- The API responds with `200 OK`.
-
-### Use the API to remove an event type filter
-
-Prerequisites:
-
-- You must have the Owner role for the group.
-
-You can remove a list of event type filters using the `auditEventsStreamingDestinationEventsRemove` query type:
-
-```graphql
-mutation {
-    auditEventsStreamingDestinationEventsRemove(input: {
-    destinationId: "gid://gitlab/AuditEvents::ExternalAuditEventDestination/1",
-    eventTypeFilters: ["list of event type filters"]
-  }){
-    errors
-  }
-}
-```
-
-Event type filters are removed if:
-
-- The returned `errors` object is empty.
-- The API responds with `200 OK`.
-
-## Payload schema
-
-> Documentation for an audit event streaming schema was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/358149) in GitLab 15.3.
-
-Streamed audit events have a predictable schema in the body of the response.
-
-| Field            | Description                                                | Notes                                                                             |
-|------------------|------------------------------------------------------------|-----------------------------------------------------------------------------------|
-| `author_id`      | User ID of the user who triggered the event                |                                                                                   |
-| `author_name`    | Human-readable name of the author that triggered the event | Helpful when the author no longer exists                                          |
-| `created_at`     | Timestamp when event was triggered                         |                                                                                   |
-| `details`        | JSON object containing additional metadata                 | Has no defined schema but often contains additional information about an event    |
-| `entity_id`      | ID of the audit event's entity                             |                                                                                   |
-| `entity_path`    | Full path of the entity affected by the auditable event    |                                                                                   |
-| `entity_type`    | String representation of the type of entity                | Acceptable values include `User`, `Group`, and `Key`. This list is not exhaustive |
-| `event_type`     | String representation of the type of audit event           |                                                                                   |
-| `id`             | Unique identifier for the audit event                      | Can be used for deduplication if required                                         |
-| `ip_address`     | IP address of the host used to trigger the event           |                                                                                   |
-| `target_details` | Additional details about the target                        |                                                                                   |
-| `target_id`      | ID of the audit event's target                             |                                                                                   |
-| `target_type`    | String representation of the target's type                 |                                                                                   |
-
-### JSON payload schema
-
-```json
-{
-  "properties": {
-    "id": {
-      "type": "string"
-    },
-    "author_id": {
-      "type": "integer"
-    },
-    "author_name": {
-      "type": "string"
-    },
-    "details": {},
-    "ip_address": {
-      "type": "string"
-    },
-    "entity_id": {
-      "type": "integer"
-    },
-    "entity_path": {
-      "type": "string"
-    },
-    "entity_type": {
-      "type": "string"
-    },
-    "event_type": {
-      "type": "string"
-    },
-    "target_id": {
-      "type": "integer"
-    },
-    "target_type": {
-      "type": "string"
-    },
-    "target_details": {
-      "type": "string"
-    },
-  },
-  "type": "object"
-}
-```
-
-## Audit event streaming on Git operations
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332747) in GitLab 14.9 [with a flag](../administration/feature_flags.md) named `audit_event_streaming_git_operations`. Disabled by default.
-> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/357211) in GitLab 15.0.
-> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/357211) in GitLab 15.1 by default.
-> - [Added `details.author_class` field](https://gitlab.com/gitlab-org/gitlab/-/issues/363876) in GitLab 15.3.
-> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/101583) in GitLab 15.6. Feature flag `audit_event_streaming_git_operations` removed.
-
-Streaming audit events can be sent when authenticated users push, pull, or clone a project's remote Git repositories:
-
-- [Using SSH](../user/ssh.md).
-- Using HTTP or HTTPS.
-- Using the **Download** button (**{download}**) in GitLab UI.
-
-Audit events are not captured for users that are not signed in. For example, when downloading a public project.
-
-To configure streaming audit events for Git operations, see [Add a new streaming destination](#add-a-new-streaming-destination).
-
-### Headers
-
-> `X-Gitlab-Audit-Event-Type` [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86881) in GitLab 15.0.
-
-Headers are formatted as follows:
-
-```plaintext
-POST /logs HTTP/1.1
-Host: <DESTINATION_HOST>
-Content-Type: application/x-www-form-urlencoded
-X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
-X-Gitlab-Audit-Event-Type: repository_git_operation
-```
-
-### Example payloads for SSH events
-
-Fetch:
-
-```json
-{
-  "id": 1,
-  "author_id": 1,
-  "entity_id": 29,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "Administrator",
-    "author_class": "User",
-    "target_id": 29,
-    "target_type": "Project",
-    "target_details": "example-project",
-    "custom_message": {
-      "protocol": "ssh",
-      "action": "git-upload-pack"
-    },
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "Administrator",
-  "entity_path": "example-group/example-project",
-  "target_details": "example-project",
-  "created_at": "2022-02-23T06:21:05.283Z",
-  "target_type": "Project",
-  "target_id": 29,
-  "event_type": "repository_git_operation"
-}
-```
-
-Push:
-
-```json
-{
-  "id": 1,
-  "author_id": 1,
-  "entity_id": 29,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "Administrator",
-    "author_class": "User",
-    "target_id": 29,
-    "target_type": "Project",
-    "target_details": "example-project",
-    "custom_message": {
-      "protocol": "ssh",
-      "action": "git-receive-pack"
-    },
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "Administrator",
-  "entity_path": "example-group/example-project",
-  "target_details": "example-project",
-  "created_at": "2022-02-23T06:23:08.746Z",
-  "target_type": "Project",
-  "target_id": 29,
-  "event_type": "repository_git_operation"
-}
-```
-
-### Example payloads for SSH events with Deploy Key
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/363876) in GitLab 15.3.
-
-Fetch:
-
-```json
-{
-  "id": 1,
-  "author_id": -3,
-  "entity_id": 29,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "deploy-key-name",
-    "author_class": "DeployKey",
-    "target_id": 29,
-    "target_type": "Project",
-    "target_details": "example-project",
-    "custom_message": {
-      "protocol": "ssh",
-      "action": "git-upload-pack"
-    },
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "deploy-key-name",
-  "entity_path": "example-group/example-project",
-  "target_details": "example-project",
-  "created_at": "2022-07-26T05:43:53.662Z",
-  "target_type": "Project",
-  "target_id": 29,
-  "event_type": "repository_git_operation"
-}
-```
-
-### Example payloads for HTTP and HTTPS events
-
-Fetch:
-
-```json
-{
-  "id": 1,
-  "author_id": 1,
-  "entity_id": 29,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "Administrator",
-    "author_class": "User",
-    "target_id": 29,
-    "target_type": "Project",
-    "target_details": "example-project",
-    "custom_message": {
-      "protocol": "http",
-      "action": "git-upload-pack"
-    },
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "Administrator",
-  "entity_path": "example-group/example-project",
-  "target_details": "example-project",
-  "created_at": "2022-02-23T06:25:43.938Z",
-  "target_type": "Project",
-  "target_id": 29,
-  "event_type": "repository_git_operation"
-}
-```
-
-Push:
-
-```json
-{
-  "id": 1,
-  "author_id": 1,
-  "entity_id": 29,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "Administrator",
-    "author_class": "User",
-    "target_id": 29,
-    "target_type": "Project",
-    "target_details": "example-project",
-    "custom_message": {
-      "protocol": "http",
-      "action": "git-receive-pack"
-    },
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "Administrator",
-  "entity_path": "example-group/example-project",
-  "target_details": "example-project",
-  "created_at": "2022-02-23T06:26:29.294Z",
-  "target_type": "Project",
-  "target_id": 29,
-  "event_type": "repository_git_operation"
-}
-```
-
-### Example payloads for HTTP and HTTPS events with Deploy Token
-
-Fetch:
-
-```json
-{
-  "id": 1,
-  "author_id": -2,
-  "entity_id": 22,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "deploy-token-name",
-    "author_class": "DeployToken",
-    "target_id": 22,
-    "target_type": "Project",
-    "target_details": "example-project",
-    "custom_message": {
-      "protocol": "http",
-      "action": "git-upload-pack"
-    },
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "deploy-token-name",
-  "entity_path": "example-group/example-project",
-  "target_details": "example-project",
-  "created_at": "2022-07-26T05:46:25.850Z",
-  "target_type": "Project",
-  "target_id": 22,
-  "event_type": "repository_git_operation"
-}
-```
-
-### Example payloads for events from GitLab UI download button
-
-Fetch:
-
-```json
-{
-  "id": 1,
-  "author_id": 99,
-  "entity_id": 29,
-  "entity_type": "Project",
-  "details": {
-    "custom_message": "Repository Download Started",
-    "author_name": "example_username",
-    "author_class": "User",
-    "target_id": 29,
-    "target_type": "Project",
-    "target_details": "example-group/example-project",
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "example_username",
-  "entity_path": "example-group/example-project",
-  "target_details": "example-group/example-project",
-  "created_at": "2022-02-23T06:27:17.873Z",
-  "target_type": "Project",
-  "target_id": 29,
-  "event_type": "repository_git_operation"
-}
-```
-
-## Audit event streaming on merge request approval actions
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/271162) in GitLab 14.9.
-
-Stream audit events that relate to merge approval actions performed within a project.
-
-### Headers
-
-Headers are formatted as follows:
-
-```plaintext
-POST /logs HTTP/1.1
-Host: <DESTINATION_HOST>
-Content-Type: application/x-www-form-urlencoded
-X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
-X-Gitlab-Audit-Event-Type: audit_operation
-```
-
-### Example payload
-
-```json
-{
-  "id": 1,
-  "author_id": 1,
-  "entity_id": 6,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "example_username",
-    "target_id": 20,
-    "target_type": "MergeRequest",
-    "target_details": "merge request title",
-    "custom_message": "Approved merge request",
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "example_username",
-  "entity_path": "example-group/example-project",
-  "target_details": "merge request title",
-  "created_at": "2022-03-09T06:53:11.181Z",
-  "target_type": "MergeRequest",
-  "target_id": 20,
-  "event_type": "audit_operation"
-}
-```
-
-## Audit event streaming on merge request create actions
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90911) in GitLab 15.2.
-
-Stream audit events that relate to merge request create actions using the `/logs` endpoint.
-
-Send API requests that contain the `X-Gitlab-Audit-Event-Type` header with value `merge_request_create`. GitLab responds with JSON payloads with an
-`event_type` field set to `merge_request_create`.
-
-### Headers
-
-Headers are formatted as follows:
-
-```plaintext
-POST /logs HTTP/1.1
-Host: <DESTINATION_HOST>
-Content-Type: application/x-www-form-urlencoded
-X-Gitlab-Audit-Event-Type: merge_request_create
-X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
-```
-
-### Example payload
-
-```json
-{
-  "id": 1,
-  "author_id": 1,
-  "entity_id": 24,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "example_user",
-    "target_id": 132,
-    "target_type": "MergeRequest",
-    "target_details": "Update test.md",
-    "custom_message": "Added merge request",
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "Administrator",
-  "entity_path": "example-group/example-project",
-  "target_details": "Update test.md",
-  "created_at": "2022-07-04T00:19:22.675Z",
-  "target_type": "MergeRequest",
-  "target_id": 132,
-  "event_type": "merge_request_create"
-}
-```
-
-## Audit event streaming on project fork actions
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90916) in GitLab 15.2.
-
-Stream audit events that relate to project fork actions using the `/logs` endpoint.
-
-Send API requests that contain the `X-Gitlab-Audit-Event-Type` header with value `project_fork_operation`. GitLab responds with JSON payloads with an
-`event_type` field set to `project_fork_operation`.
-
-### Headers
-
-Headers are formatted as follows:
-
-```plaintext
-POST /logs HTTP/1.1
-Host: <DESTINATION_HOST>
-Content-Type: application/x-www-form-urlencoded
-X-Gitlab-Audit-Event-Type: project_fork_operation
-X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
-```
-
-### Example payload
-
-```json
-{
-  "id": 1,
-  "author_id": 1,
-  "entity_id": 24,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "example_username",
-    "target_id": 24,
-    "target_type": "Project",
-    "target_details": "example-project",
-    "custom_message": "Forked project to another-group/example-project-forked",
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "example_username",
-  "entity_path": "example-group/example-project",
-  "target_details": "example-project",
-  "created_at": "2022-06-30T03:43:35.384Z",
-  "target_type": "Project",
-  "target_id": 24,
-  "event_type": "project_fork_operation"
-}
-```
-
-## Audit event streaming on project group link actions
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90955) in GitLab 15.2.
-
-Stream audit events that relate to project group link creation, updates, and deletion using the `/logs` endpoint.
-
-Send API requests that contain the `X-Gitlab-Audit-Event-Type` header with value of either:
-
-- `project_group_link_create`.
-- `project_group_link_update`.
-- `project_group_link_destroy`.
-
-GitLab responds with JSON payloads with an `event_type` field set to either:
-
-- `project_group_link_create`.
-- `project_group_link_update`.
-- `project_group_link_destroy`.
-
-### Example Headers
-
-Headers are formatted as follows:
-
-```plaintext
-POST /logs HTTP/1.1
-Host: <DESTINATION_HOST>
-Content-Type: application/x-www-form-urlencoded
-X-Gitlab-Audit-Event-Type: project_group_link_create
-X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
-```
-
-### Example payload for project group link create
-
-```json
-{
-  "id": 1,
-  "author_id": 1,
-  "entity_id": 24,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "example-user",
-    "target_id": 31,
-    "target_type": "Group",
-    "target_details": "another-group",
-    "custom_message": "Added project group link",
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "example-user",
-  "entity_path": "example-group/example-project",
-  "target_details": "another-group",
-  "created_at": "2022-07-04T00:43:09.318Z",
-  "target_type": "Group",
-  "target_id": 31,
-  "event_type": "project_group_link_create"
-}
-```
-
-### Example payload for project group link update
-
-```json
-{
-  "id": 1,
-  "author_id": 1,
-  "entity_id": 24,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "example-user",
-    "target_id": 31,
-    "target_type": "Group",
-    "target_details": "another-group",
-    "custom_message": "Changed project group link profile group_access from Developer to Guest",
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "example-user",
-  "entity_path": "example-group/example-project",
-  "target_details": "another-group",
-  "created_at": "2022-07-04T00:43:28.328Z",
-  "target_type": "Group",
-  "target_id": 31,
-  "event_type": "project_group_link_update"
-}
-```
-
-### Example payload for project group link delete
-
-```json
-{
-  "id": 1,
-  "author_id": 1,
-  "entity_id": 24,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "example-user",
-    "target_id": 31,
-    "target_type": "Group",
-    "target_details": "another-group",
-    "custom_message": "Removed project group link",
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "example-user",
-  "entity_path": "example-group/example-project",
-  "target_details": "another-group",
-  "created_at": "2022-07-04T00:42:56.279Z",
-  "target_type": "Group",
-  "target_id": 31,
-  "event_type": "project_group_link_destroy"
-}
-```
-
-## Audit event streaming on invalid merge request approver state
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/374566) in GitLab 15.5.
-
-Stream audit events that relate to invalid merge request approver states within a project.
-
-### Headers
-
-Headers are formatted as follows:
-
-```plaintext
-POST /logs HTTP/1.1
-Host: <DESTINATION_HOST>
-Content-Type: application/x-www-form-urlencoded
-X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
-X-Gitlab-Audit-Event-Type: audit_operation
-```
-
-### Example payload
-
-```json
-{
-  "id": 1,
-  "author_id": 1,
-  "entity_id": 6,
-  "entity_type": "Project",
-  "details": {
-    "author_name": "example_username",
-    "target_id": 20,
-    "target_type": "MergeRequest",
-    "target_details": { title: "Merge request title", iid: "Merge request iid", id: "Merge request id" },
-    "custom_message": "Invalid merge request approver rules",
-    "ip_address": "127.0.0.1",
-    "entity_path": "example-group/example-project"
-  },
-  "ip_address": "127.0.0.1",
-  "author_name": "example_username",
-  "entity_path": "example-group/example-project",
-  "target_details": "merge request title",
-  "created_at": "2022-03-09T06:53:11.181Z",
-  "target_type": "MergeRequest",
-  "target_id": 20,
-  "event_type": "audit_operation"
-}
-```
+<!-- This redirect file can be deleted after <2023-09-12>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/administration/audit_event_streaming/examples.md b/doc/administration/audit_event_streaming/examples.md
new file mode 100644
index 00000000000..d741e5fd60d
--- /dev/null
+++ b/doc/administration/audit_event_streaming/examples.md
@@ -0,0 +1,578 @@
+---
+stage: Govern
+group: Compliance
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Audit event streaming examples
+
+The following sections provide examples of audit event streaming.
+
+## Audit event streaming on Git operations
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332747) in GitLab 14.9 [with a flag](../feature_flags.md) named `audit_event_streaming_git_operations`. Disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/357211) in GitLab 15.0.
+> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/357211) in GitLab 15.1 by default.
+> - [Added `details.author_class` field](https://gitlab.com/gitlab-org/gitlab/-/issues/363876) in GitLab 15.3.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/101583) in GitLab 15.6. Feature flag `audit_event_streaming_git_operations` removed.
+
+Streaming audit events can be sent when authenticated users push, pull, or clone a project's remote Git repositories:
+
+- [Using SSH](../../user/ssh.md).
+- Using HTTP or HTTPS.
+- Using **Download** (**{download}**) in GitLab UI.
+
+Audit events are not captured for users that are not signed in. For example, when downloading a public project.
+
+To configure streaming audit events for Git operations, see [Add a new streaming destination](index.md#add-a-new-streaming-destination).
+
+### Headers
+
+> `X-Gitlab-Audit-Event-Type` [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86881) in GitLab 15.0.
+
+Headers are formatted as follows:
+
+```plaintext
+POST /logs HTTP/1.1
+Host: <DESTINATION_HOST>
+Content-Type: application/x-www-form-urlencoded
+X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
+X-Gitlab-Audit-Event-Type: repository_git_operation
+```
+
+### Example payloads for SSH events
+
+Fetch:
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 29,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "Administrator",
+    "author_class": "User",
+    "target_id": 29,
+    "target_type": "Project",
+    "target_details": "example-project",
+    "custom_message": {
+      "protocol": "ssh",
+      "action": "git-upload-pack"
+    },
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "Administrator",
+  "entity_path": "example-group/example-project",
+  "target_details": "example-project",
+  "created_at": "2022-02-23T06:21:05.283Z",
+  "target_type": "Project",
+  "target_id": 29,
+  "event_type": "repository_git_operation"
+}
+```
+
+Push:
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 29,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "Administrator",
+    "author_class": "User",
+    "target_id": 29,
+    "target_type": "Project",
+    "target_details": "example-project",
+    "custom_message": {
+      "protocol": "ssh",
+      "action": "git-receive-pack"
+    },
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "Administrator",
+  "entity_path": "example-group/example-project",
+  "target_details": "example-project",
+  "created_at": "2022-02-23T06:23:08.746Z",
+  "target_type": "Project",
+  "target_id": 29,
+  "event_type": "repository_git_operation"
+}
+```
+
+### Example payloads for SSH events with Deploy Key
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/363876) in GitLab 15.3.
+
+Fetch:
+
+```json
+{
+  "id": 1,
+  "author_id": -3,
+  "entity_id": 29,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "deploy-key-name",
+    "author_class": "DeployKey",
+    "target_id": 29,
+    "target_type": "Project",
+    "target_details": "example-project",
+    "custom_message": {
+      "protocol": "ssh",
+      "action": "git-upload-pack"
+    },
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "deploy-key-name",
+  "entity_path": "example-group/example-project",
+  "target_details": "example-project",
+  "created_at": "2022-07-26T05:43:53.662Z",
+  "target_type": "Project",
+  "target_id": 29,
+  "event_type": "repository_git_operation"
+}
+```
+
+### Example payloads for HTTP and HTTPS events
+
+Fetch:
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 29,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "Administrator",
+    "author_class": "User",
+    "target_id": 29,
+    "target_type": "Project",
+    "target_details": "example-project",
+    "custom_message": {
+      "protocol": "http",
+      "action": "git-upload-pack"
+    },
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "Administrator",
+  "entity_path": "example-group/example-project",
+  "target_details": "example-project",
+  "created_at": "2022-02-23T06:25:43.938Z",
+  "target_type": "Project",
+  "target_id": 29,
+  "event_type": "repository_git_operation"
+}
+```
+
+Push:
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 29,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "Administrator",
+    "author_class": "User",
+    "target_id": 29,
+    "target_type": "Project",
+    "target_details": "example-project",
+    "custom_message": {
+      "protocol": "http",
+      "action": "git-receive-pack"
+    },
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "Administrator",
+  "entity_path": "example-group/example-project",
+  "target_details": "example-project",
+  "created_at": "2022-02-23T06:26:29.294Z",
+  "target_type": "Project",
+  "target_id": 29,
+  "event_type": "repository_git_operation"
+}
+```
+
+### Example payloads for HTTP and HTTPS events with Deploy Token
+
+Fetch:
+
+```json
+{
+  "id": 1,
+  "author_id": -2,
+  "entity_id": 22,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "deploy-token-name",
+    "author_class": "DeployToken",
+    "target_id": 22,
+    "target_type": "Project",
+    "target_details": "example-project",
+    "custom_message": {
+      "protocol": "http",
+      "action": "git-upload-pack"
+    },
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "deploy-token-name",
+  "entity_path": "example-group/example-project",
+  "target_details": "example-project",
+  "created_at": "2022-07-26T05:46:25.850Z",
+  "target_type": "Project",
+  "target_id": 22,
+  "event_type": "repository_git_operation"
+}
+```
+
+### Example payloads for events from GitLab UI download button
+
+Fetch:
+
+```json
+{
+  "id": 1,
+  "author_id": 99,
+  "entity_id": 29,
+  "entity_type": "Project",
+  "details": {
+    "custom_message": "Repository Download Started",
+    "author_name": "example_username",
+    "author_class": "User",
+    "target_id": 29,
+    "target_type": "Project",
+    "target_details": "example-group/example-project",
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "example_username",
+  "entity_path": "example-group/example-project",
+  "target_details": "example-group/example-project",
+  "created_at": "2022-02-23T06:27:17.873Z",
+  "target_type": "Project",
+  "target_id": 29,
+  "event_type": "repository_git_operation"
+}
+```
+
+## Audit event streaming on merge request approval actions
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/271162) in GitLab 14.9.
+
+Stream audit events that relate to merge approval actions performed in a project.
+
+### Headers
+
+Headers are formatted as follows:
+
+```plaintext
+POST /logs HTTP/1.1
+Host: <DESTINATION_HOST>
+Content-Type: application/x-www-form-urlencoded
+X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
+X-Gitlab-Audit-Event-Type: audit_operation
+```
+
+### Example payload
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 6,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "example_username",
+    "target_id": 20,
+    "target_type": "MergeRequest",
+    "target_details": "merge request title",
+    "custom_message": "Approved merge request",
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "example_username",
+  "entity_path": "example-group/example-project",
+  "target_details": "merge request title",
+  "created_at": "2022-03-09T06:53:11.181Z",
+  "target_type": "MergeRequest",
+  "target_id": 20,
+  "event_type": "audit_operation"
+}
+```
+
+## Audit event streaming on merge request create actions
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90911) in GitLab 15.2.
+
+Stream audit events that relate to merge request create actions using the `/logs` endpoint.
+
+Send API requests that contain the `X-Gitlab-Audit-Event-Type` header with value `merge_request_create`. GitLab responds with JSON payloads with an
+`event_type` field set to `merge_request_create`.
+
+### Headers
+
+Headers are formatted as follows:
+
+```plaintext
+POST /logs HTTP/1.1
+Host: <DESTINATION_HOST>
+Content-Type: application/x-www-form-urlencoded
+X-Gitlab-Audit-Event-Type: merge_request_create
+X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
+```
+
+### Example payload
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 24,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "example_user",
+    "target_id": 132,
+    "target_type": "MergeRequest",
+    "target_details": "Update test.md",
+    "custom_message": "Added merge request",
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "Administrator",
+  "entity_path": "example-group/example-project",
+  "target_details": "Update test.md",
+  "created_at": "2022-07-04T00:19:22.675Z",
+  "target_type": "MergeRequest",
+  "target_id": 132,
+  "event_type": "merge_request_create"
+}
+```
+
+## Audit event streaming on project fork actions
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90916) in GitLab 15.2.
+
+Stream audit events that relate to project fork actions using the `/logs` endpoint.
+
+Send API requests that contain the `X-Gitlab-Audit-Event-Type` header with value `project_fork_operation`. GitLab responds with JSON payloads with an
+`event_type` field set to `project_fork_operation`.
+
+### Headers
+
+Headers are formatted as follows:
+
+```plaintext
+POST /logs HTTP/1.1
+Host: <DESTINATION_HOST>
+Content-Type: application/x-www-form-urlencoded
+X-Gitlab-Audit-Event-Type: project_fork_operation
+X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
+```
+
+### Example payload
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 24,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "example_username",
+    "target_id": 24,
+    "target_type": "Project",
+    "target_details": "example-project",
+    "custom_message": "Forked project to another-group/example-project-forked",
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "example_username",
+  "entity_path": "example-group/example-project",
+  "target_details": "example-project",
+  "created_at": "2022-06-30T03:43:35.384Z",
+  "target_type": "Project",
+  "target_id": 24,
+  "event_type": "project_fork_operation"
+}
+```
+
+## Audit event streaming on project group link actions
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90955) in GitLab 15.2.
+
+Stream audit events that relate to project group link creation, updates, and deletion using the `/logs` endpoint.
+
+Send API requests that contain the `X-Gitlab-Audit-Event-Type` header with value of either:
+
+- `project_group_link_create`.
+- `project_group_link_update`.
+- `project_group_link_destroy`.
+
+GitLab responds with JSON payloads with an `event_type` field set to either:
+
+- `project_group_link_create`.
+- `project_group_link_update`.
+- `project_group_link_destroy`.
+
+### Example Headers
+
+Headers are formatted as follows:
+
+```plaintext
+POST /logs HTTP/1.1
+Host: <DESTINATION_HOST>
+Content-Type: application/x-www-form-urlencoded
+X-Gitlab-Audit-Event-Type: project_group_link_create
+X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
+```
+
+### Example payload for project group link create
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 24,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "example-user",
+    "target_id": 31,
+    "target_type": "Group",
+    "target_details": "another-group",
+    "custom_message": "Added project group link",
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "example-user",
+  "entity_path": "example-group/example-project",
+  "target_details": "another-group",
+  "created_at": "2022-07-04T00:43:09.318Z",
+  "target_type": "Group",
+  "target_id": 31,
+  "event_type": "project_group_link_create"
+}
+```
+
+### Example payload for project group link update
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 24,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "example-user",
+    "target_id": 31,
+    "target_type": "Group",
+    "target_details": "another-group",
+    "custom_message": "Changed project group link profile group_access from Developer to Guest",
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "example-user",
+  "entity_path": "example-group/example-project",
+  "target_details": "another-group",
+  "created_at": "2022-07-04T00:43:28.328Z",
+  "target_type": "Group",
+  "target_id": 31,
+  "event_type": "project_group_link_update"
+}
+```
+
+### Example payload for project group link delete
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 24,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "example-user",
+    "target_id": 31,
+    "target_type": "Group",
+    "target_details": "another-group",
+    "custom_message": "Removed project group link",
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "example-user",
+  "entity_path": "example-group/example-project",
+  "target_details": "another-group",
+  "created_at": "2022-07-04T00:42:56.279Z",
+  "target_type": "Group",
+  "target_id": 31,
+  "event_type": "project_group_link_destroy"
+}
+```
+
+## Audit event streaming on invalid merge request approver state
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/374566) in GitLab 15.5.
+
+Stream audit events that relate to invalid merge request approver states in a project.
+
+### Headers
+
+Headers are formatted as follows:
+
+```plaintext
+POST /logs HTTP/1.1
+Host: <DESTINATION_HOST>
+Content-Type: application/x-www-form-urlencoded
+X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
+X-Gitlab-Audit-Event-Type: audit_operation
+```
+
+### Example payload
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 6,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "example_username",
+    "target_id": 20,
+    "target_type": "MergeRequest",
+    "target_details": { title: "Merge request title", iid: "Merge request iid", id: "Merge request id" },
+    "custom_message": "Invalid merge request approver rules",
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "example_username",
+  "entity_path": "example-group/example-project",
+  "target_details": "merge request title",
+  "created_at": "2022-03-09T06:53:11.181Z",
+  "target_type": "MergeRequest",
+  "target_id": 20,
+  "event_type": "audit_operation"
+}
+```
diff --git a/doc/administration/audit_event_streaming/graphql_api.md b/doc/administration/audit_event_streaming/graphql_api.md
new file mode 100644
index 00000000000..f5a31f073dc
--- /dev/null
+++ b/doc/administration/audit_event_streaming/graphql_api.md
@@ -0,0 +1,442 @@
+---
+stage: Govern
+group: Compliance
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Audit event streaming GraphQL API **(ULTIMATE)**
+
+> - API [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332747) in GitLab 14.5 [with a flag](../feature_flags.md) named `ff_external_audit_events_namespace`. Disabled by default.
+> - API [Enabled on GitLab.com and by default on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/338939) in GitLab 14.7.
+> - API [Feature flag `ff_external_audit_events_namespace`](https://gitlab.com/gitlab-org/gitlab/-/issues/349588) removed in GitLab 14.8.
+> - Custom HTTP headers API [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/361216) in GitLab 15.1 [with a flag](../feature_flags.md) named `streaming_audit_event_headers`. Disabled by default.
+> - Custom HTTP headers API [enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/362941) in GitLab 15.2.
+> - Custom HTTP headers API [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/366524) in GitLab 15.3. [Feature flag `streaming_audit_event_headers`](https://gitlab.com/gitlab-org/gitlab/-/issues/362941) removed.
+> - User-specified verification token API support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360813) in GitLab 15.4.
+> - APIs for custom HTTP headers for instance level streaming destinations [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404560) in GitLab 16.1 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
+
+Audit event streaming destinations can be maintained using a GraphQL API.
+
+## Add a new streaming destination
+
+Add a new streaming destination to top-level groups or an entire instance.
+
+WARNING:
+Streaming destinations receive **all** audit event data, which could include sensitive information. Make sure you trust the streaming destination.
+
+### Top-level group streaming destinations
+
+Prerequisites:
+
+- Owner role for a top-level group.
+
+To enable streaming and add a destination to a top-level group, use the `externalAuditEventDestinationCreate` mutation.
+
+```graphql
+mutation {
+  externalAuditEventDestinationCreate(input: { destinationUrl: "https://mydomain.io/endpoint/ingest", groupPath: "my-group" } ) {
+    errors
+    externalAuditEventDestination {
+      id
+      destinationUrl
+      verificationToken
+      group {
+        name
+      }
+    }
+  }
+}
+```
+
+You can optionally specify your own verification token (instead of the default GitLab-generated one) using the GraphQL
+`externalAuditEventDestinationCreate`
+mutation. Verification token length must be within 16 to 24 characters and trailing whitespace are not trimmed. You
+should set a cryptographically random and unique value. For example:
+
+```graphql
+mutation {
+  externalAuditEventDestinationCreate(input: { destinationUrl: "https://mydomain.io/endpoint/ingest", groupPath: "my-group", verificationToken: "unique-random-verification-token-here" } ) {
+    errors
+    externalAuditEventDestination {
+      id
+      destinationUrl
+      verificationToken
+      group {
+        name
+      }
+    }
+  }
+}
+```
+
+Event streaming is enabled if:
+
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
+
+You can add an HTTP header using the GraphQL `auditEventsStreamingHeadersCreate` mutation. You can retrieve the
+destination ID by [listing all the streaming destinations](#list-streaming-destinations) for the group or from the
+mutation above.
+
+```graphql
+mutation {
+  auditEventsStreamingHeadersCreate(input: { destinationId: "gid://gitlab/AuditEvents::ExternalAuditEventDestination/24601", key: "foo", value: "bar" }) {
+    errors
+  }
+}
+```
+
+The header is created if the returned `errors` object is empty.
+
+### Instance streaming destinations
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335175) in GitLab 16.0 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../feature_flags.md) named
+`ff_external_audit_events`. On GitLab.com, this feature is not available. The feature is not ready for production use.
+
+Prerequisites:
+
+- Administrator access on the instance.
+
+To enable streaming and add a destination, use the
+`instanceExternalAuditEventDestinationCreate` mutation in the GraphQL API.
+
+```graphql
+mutation {
+  instanceExternalAuditEventDestinationCreate(input: { destinationUrl: "https://mydomain.io/endpoint/ingest"}) {
+    errors
+    instanceExternalAuditEventDestination {
+      destinationUrl
+      id
+      verificationToken
+    }
+  }
+}
+```
+
+Event streaming is enabled if:
+
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
+
+Instance administrators can add an HTTP header using the GraphQL `auditEventsStreamingInstanceHeadersCreate` mutation. You can retrieve the destination ID
+by [listing all the streaming destinations](#list-streaming-destinations) for the instance or from the mutation above.
+
+```graphql
+mutation {
+  auditEventsStreamingInstanceHeadersCreate(input:
+    {
+      destinationId: "gid://gitlab/AuditEvents::InstanceExternalAuditEventDestination/42",
+      key: "foo",
+      value: "bar"
+    }) {
+    errors
+    header {
+      id
+      key
+      value
+    }
+  }
+}
+```
+
+The header is created if the returned `errors` object is empty.
+
+## List streaming destinations
+
+List new streaming destinations for top-level groups or an entire instance.
+
+### Top-level group streaming destinations
+
+Prerequisites:
+
+- Owner role for a top-level group.
+
+You can view a list of streaming destinations for a top-level group using the `externalAuditEventDestinations` query
+type.
+
+```graphql
+query {
+  group(fullPath: "my-group") {
+    id
+    externalAuditEventDestinations {
+      nodes {
+        destinationUrl
+        verificationToken
+        id
+        headers {
+          nodes {
+            key
+            value
+            id
+          }
+        }
+        eventTypeFilters
+      }
+    }
+  }
+}
+```
+
+If the resulting list is empty, then audit streaming is not enabled for that group.
+
+### Instance streaming destinations
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335175) in GitLab 16.0 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../feature_flags.md) named
+`ff_external_audit_events`. On GitLab.com, this feature is not available. The feature is not ready for production use.
+
+Prerequisites:
+
+- Administrator access on the instance.
+
+To view a list of streaming destinations for an instance, use the
+`instanceExternalAuditEventDestinations` query type.
+
+```graphql
+query {
+  instanceExternalAuditEventDestinations {
+    nodes {
+      id
+      destinationUrl
+      verificationToken
+      headers {
+        nodes {
+          id
+          key
+          value
+        }
+      }
+    }
+  }
+}
+```
+
+If the resulting list is empty, then audit streaming is not enabled for the instance.
+
+You need the ID values returned by this query for the update and delete mutations.
+
+## Update streaming destinations
+
+Update streaming destinations for a top-level group or an entire instance.
+
+### Top-level group streaming destinations
+
+Prerequisites:
+
+- Owner role for a top-level group.
+
+Users with the Owner role for a group can update streaming destinations' custom HTTP headers using the
+`auditEventsStreamingHeadersUpdate` mutation type. You can retrieve the custom HTTP headers ID
+by [listing all the custom HTTP headers](#list-streaming-destinations) for the group.
+
+```graphql
+mutation {
+  externalAuditEventDestinationDestroy(input: { id: destination }) {
+    errors
+  }
+}
+```
+
+Streaming destination is updated if:
+
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
+
+Group owners can remove an HTTP header using the GraphQL `auditEventsStreamingHeadersDestroy` mutation. You can retrieve the header ID
+by [listing all the custom HTTP headers](#list-streaming-destinations) for the group.
+
+```graphql
+mutation {
+  auditEventsStreamingHeadersDestroy(input: { headerId: "gid://gitlab/AuditEvents::Streaming::Header/1" }) {
+    errors
+  }
+}
+```
+
+The header is deleted if the returned `errors` object is empty.
+
+### Instance streaming destinations
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335175) in GitLab 16.0 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../feature_flags.md) named
+`ff_external_audit_events`. On GitLab.com, this feature is not available. The feature is not ready for production use.
+
+Prerequisites:
+
+- Administrator access on the instance.
+
+To update streaming destinations for an instance, use the
+`instanceExternalAuditEventDestinationUpdate` mutation type. You can retrieve the destination ID
+by [listing all the external destinations](#list-streaming-destinations) for the instance.
+
+```graphql
+mutation {
+  instanceExternalAuditEventDestinationUpdate(input: { id: "gid://gitlab/AuditEvents::InstanceExternalAuditEventDestination/1", destinationUrl: "https://www.new-domain.com/webhook"}) {
+    errors
+    instanceExternalAuditEventDestination {
+      destinationUrl
+      id
+      verificationToken
+    }
+  }
+}
+```
+
+Streaming destination is updated if:
+
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
+
+Instance administrators can update streaming destinations custom HTTP headers using the
+`auditEventsStreamingInstanceHeadersUpdate` mutation type. You can retrieve the custom HTTP headers ID
+by [listing all the custom HTTP headers](#list-streaming-destinations) for the instance.
+
+```graphql
+mutation {
+  auditEventsStreamingInstanceHeadersUpdate(input: { headerId: "gid://gitlab/AuditEvents::Streaming::InstanceHeader/2", key: "new-key", value: "new-value" }) {
+    errors
+    header {
+      id
+      key
+      value
+    }
+  }
+}
+```
+
+The header is updated if the returned `errors` object is empty.
+
+## Delete streaming destinations
+
+Delete streaming destinations for a top-level group or an entire instance.
+
+When the last destination is successfully deleted, streaming is disabled for the group or the instance.
+
+### Top-level group streaming destinations
+
+Prerequisites:
+
+- Owner role for a top-level group.
+
+Users with the Owner role for a group can delete streaming destinations using the
+`externalAuditEventDestinationDestroy` mutation type. You can retrieve the destinations ID
+by [listing all the streaming destinations](#list-streaming-destinations) for the group.
+
+```graphql
+mutation {
+  externalAuditEventDestinationDestroy(input: { id: destination }) {
+    errors
+  }
+}
+```
+
+Streaming destination is deleted if:
+
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
+
+Group owners can remove an HTTP header using the GraphQL `auditEventsStreamingHeadersDestroy` mutation. You can retrieve the header ID
+by [listing all the custom HTTP headers](#list-streaming-destinations) for the group.
+
+```graphql
+mutation {
+  auditEventsStreamingHeadersDestroy(input: { headerId: "gid://gitlab/AuditEvents::Streaming::Header/1" }) {
+    errors
+  }
+}
+```
+
+The header is deleted if the returned `errors` object is empty.
+
+### Instance streaming destinations
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335175) in GitLab 16.0 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../feature_flags.md) named
+`ff_external_audit_events`. On GitLab.com, this feature is not available. The feature is not ready for production use.
+
+Prerequisites:
+
+- Administrator access on the instance.
+
+To delete streaming destinations, use the
+`instanceExternalAuditEventDestinationDestroy` mutation type. You can retrieve the destinations ID
+by [listing all the streaming destinations](#list-streaming-destinations) for the instance.
+
+```graphql
+mutation {
+  instanceExternalAuditEventDestinationDestroy(input: { id: "gid://gitlab/AuditEvents::InstanceExternalAuditEventDestination/1" }) {
+    errors
+  }
+}
+```
+
+Streaming destination is deleted if:
+
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
+
+## Event type filters
+
+> Event type filters API [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/344845) in GitLab 15.7.
+
+When this feature is enabled for a group, you can use an API to permit users to filter streamed audit events per destination.
+If the feature is enabled with no filters, the destination receives all audit events.
+
+A streaming destination that has an event type filter set has a **filtered** (**{filter}**) label.
+
+### Use the API to add an event type filter
+
+Prerequisites:
+
+- You must have the Owner role for the group.
+
+You can add a list of event type filters using the `auditEventsStreamingDestinationEventsAdd` query type:
+
+```graphql
+mutation {
+    auditEventsStreamingDestinationEventsAdd(input: {
+        destinationId: "gid://gitlab/AuditEvents::ExternalAuditEventDestination/1",
+        eventTypeFilters: ["list of event type filters"]}){
+        errors
+        eventTypeFilters
+    }
+}
+```
+
+Event type filters are added if:
+
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
+
+### Use the API to remove an event type filter
+
+Prerequisites:
+
+- You must have the Owner role for the group.
+
+You can remove a list of event type filters using the `auditEventsStreamingDestinationEventsRemove` query type:
+
+```graphql
+mutation {
+    auditEventsStreamingDestinationEventsRemove(input: {
+    destinationId: "gid://gitlab/AuditEvents::ExternalAuditEventDestination/1",
+    eventTypeFilters: ["list of event type filters"]
+  }){
+    errors
+  }
+}
+```
+
+Event type filters are removed if:
+
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
diff --git a/doc/administration/audit_event_streaming/index.md b/doc/administration/audit_event_streaming/index.md
new file mode 100644
index 00000000000..44c6cff7455
--- /dev/null
+++ b/doc/administration/audit_event_streaming/index.md
@@ -0,0 +1,302 @@
+---
+stage: Govern
+group: Compliance
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Audit event streaming **(ULTIMATE)**
+
+> - UI [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/336411) in GitLab 14.9.
+> - [Subgroup events recording](https://gitlab.com/gitlab-org/gitlab/-/issues/366878) fixed in GitLab 15.2.
+> - Custom HTTP headers UI [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/361630) in GitLab 15.2 [with a flag](../feature_flags.md) named `custom_headers_streaming_audit_events_ui`. Disabled by default.
+> - Custom HTTP headers UI [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/365259) in GitLab 15.3. [Feature flag `custom_headers_streaming_audit_events_ui`](https://gitlab.com/gitlab-org/gitlab/-/issues/365259) removed.
+> - [Improved user experience](https://gitlab.com/gitlab-org/gitlab/-/issues/367963) in GitLab 15.3.
+
+Users can set a streaming destination for a top-level group or instance to receive all audit events about the group, subgroups, and
+projects as structured JSON.
+
+Top-level group owners and instance administrators can manage their audit logs in third-party systems. Any service that can receive
+structured JSON data can be used as the streaming destination.
+
+Each streaming destination can have up to 20 custom HTTP headers included with each streamed event.
+
+NOTE:
+GitLab can stream a single event more than once to the same destination. Use the `id` key in the payload to deduplicate incoming data.
+
+## Add a new streaming destination
+
+Add a new streaming destination to top-level groups or an entire instance.
+
+WARNING:
+Streaming destinations receive **all** audit event data, which could include sensitive information. Make sure you trust the streaming destination.
+
+### Top-level group streaming destinations
+
+Prerequisites:
+
+- Owner role for a top-level group.
+
+To add streaming destinations to a top-level group:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Audit events**.
+1. On the main area, select **Streams** tab.
+1. Select **Add streaming destination** to show the section for adding destinations.
+1. Enter the destination URL to add.
+1. Optional. Locate the **Custom HTTP headers** table.
+1. Ignore the **Active** checkbox because it isn't functional. To track progress on adding functionality to the
+   **Active** checkbox, see [issue 367509](https://gitlab.com/gitlab-org/gitlab/-/issues/367509).
+1. Select **Add header** to create a new name and value pair. Enter as many name and value pairs as required. You can add up to
+   20 headers per streaming destination.
+1. After all headers have been filled out, select **Add** to add the new streaming destination.
+
+### Instance streaming destinations
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/398107) in GitLab 16.1 [with a flag](../feature_flags.md) named `instance_streaming_audit_events`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../feature_flags.md) named
+`instance_streaming_audit_events`. On GitLab.com, this feature is not available. The feature is not ready for production use.
+
+Prerequisites:
+
+- Administrator access on the instance.
+
+To add a streaming destination for an instance:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
+1. On the main area, select **Streams** tab.
+1. Select **Add streaming destination** to show the section for adding destinations.
+1. Enter the destination URL to add.
+1. Select **Add** to add the new streaming destination.
+
+## List streaming destinations
+
+List new streaming destinations for top-level groups or an entire instance.
+
+### For top-level group streaming destinations
+
+Prerequisites:
+
+- Owner role for a group.
+
+To list the streaming destinations for a top-level group:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Audit events**.
+1. On the main area, select **Streams** tab.
+1. To the right of the item, select **Edit** (**{pencil}**) to see all the custom HTTP headers.
+
+### For instance streaming destinations
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/398107) in GitLab 16.1 [with a flag](../feature_flags.md) named `instance_streaming_audit_events`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../feature_flags.md) named
+`instance_streaming_audit_events`. On GitLab.com, this feature is not available. The feature is not ready for production use.
+
+Prerequisites:
+
+- Administrator access on the instance.
+
+To list the streaming destinations for an instance:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
+1. On the main area, select **Streams** tab.
+
+## Update streaming destinations
+
+Update streaming destinations for a top-level group or an entire instance.
+
+### Top-level group streaming destinations
+
+Prerequisites:
+
+- Owner role for a group.
+
+To update a streaming destination's custom HTTP headers:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Audit events**.
+1. On the main area, select **Streams** tab.
+1. To the right of the item, select **Edit** (**{pencil}**).
+1. Locate the **Custom HTTP headers** table.
+1. Locate the header that you wish to update.
+1. Ignore the **Active** checkbox because it isn't functional. To track progress on adding functionality to the
+   **Active** checkbox, see [issue 367509](https://gitlab.com/gitlab-org/gitlab/-/issues/367509).
+1. Select **Add header** to create a new name and value pair. Enter as many name and value pairs as required. You can add up to
+   20 headers per streaming destination.
+1. Select **Save** to update the streaming destination.
+
+## Delete streaming destinations
+
+Delete streaming destinations for a top-level group or an entire instance. When the last destination is successfully
+deleted, streaming is disabled for the group or the instance.
+
+### Top-level group streaming destinations
+
+Prerequisites:
+
+- Owner role for a group.
+
+To delete a streaming destination:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Audit events**.
+1. On the main area, select the **Streams** tab.
+1. To the right of the item, select **Delete** (**{remove}**).
+
+To delete only the custom HTTP headers for a streaming destination:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Audit events**.
+1. On the main area, select the **Streams** tab.
+1. To the right of the item, **Edit** (**{pencil}**).
+1. Locate the **Custom HTTP headers** table.
+1. Locate the header that you wish to remove.
+1. To the right of the header, select **Delete** (**{remove}**).
+1. Select **Save** to update the streaming destination.
+
+### Instance streaming destinations
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/398107) in GitLab 16.1 [with a flag](../feature_flags.md) named `instance_streaming_audit_events`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../feature_flags.md) named
+`instance_streaming_audit_events`. On GitLab.com, this feature is not available. The feature is not ready for production use.
+
+Prerequisites:
+
+- Administrator access on the instance.
+
+To delete the streaming destinations for an instance:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams** tab.
+1. To the right of the item, select **Delete** (**{remove}**).
+
+## Verify event authenticity
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345424) in GitLab 14.8.
+
+Each streaming destination has a unique verification token (`verificationToken`) that can be used to verify the authenticity of the event. This
+token is either specified by the Owner or generated automatically when the event destination is created and cannot be changed.
+
+Each streamed event contains the verification token in the `X-Gitlab-Event-Streaming-Token` HTTP header that can be verified against
+the destination's value when [listing streaming destinations](#list-streaming-destinations).
+
+### Top-level group streaming destinations
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360814) in GitLab 15.2.
+
+Prerequisites:
+
+- Owner role for a group.
+
+To list streaming destinations and see the verification tokens:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Audit events**.
+1. On the main area, select the **Streams**.
+1. View the verification token on the right side of each item.
+
+### Instance streaming destinations
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/398107) in GitLab 16.1 [with a flag](../feature_flags.md) named `instance_streaming_audit_events`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../feature_flags.md) named
+`instance_streaming_audit_events`. On GitLab.com, this feature is not available. The feature is not ready for production use.
+
+Prerequisites:
+
+- Administrator access on the instance.
+
+To list streaming destinations for an instance and see the verification tokens:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams**.
+1. View the verification token on the right side of each item.
+
+## Override default content type header
+
+By default, streaming destinations use a `content-type` header of `application/x-www-form-urlencoded`. However, you
+might want to set the `content-type` header to something else. For example ,`application/json`.
+
+To override the `content-type` header default value for either a top-level group streaming destination or an instance
+streaming destination, use either the [GitLab UI](#update-streaming-destinations) or using the
+[GraphQL API](graphql_api.md#update-streaming-destinations).
+
+## Payload schema
+
+> Documentation for an audit event streaming schema was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/358149) in GitLab 15.3.
+
+Streamed audit events have a predictable schema in the body of the response.
+
+| Field            | Description                                                | Notes                                                                             |
+|------------------|------------------------------------------------------------|-----------------------------------------------------------------------------------|
+| `author_id`      | User ID of the user who triggered the event                |                                                                                   |
+| `author_name`    | Human-readable name of the author that triggered the event | Helpful when the author no longer exists                                          |
+| `created_at`     | Timestamp when event was triggered                         |                                                                                   |
+| `details`        | JSON object containing additional metadata                 | Has no defined schema but often contains additional information about an event    |
+| `entity_id`      | ID of the audit event's entity                             |                                                                                   |
+| `entity_path`    | Full path of the entity affected by the auditable event    |                                                                                   |
+| `entity_type`    | String representation of the type of entity                | Acceptable values include `User`, `Group`, and `Key`. This list is not exhaustive |
+| `event_type`     | String representation of the type of audit event           |                                                                                   |
+| `id`             | Unique identifier for the audit event                      | Can be used for deduplication if required                                         |
+| `ip_address`     | IP address of the host used to trigger the event           |                                                                                   |
+| `target_details` | Additional details about the target                        |                                                                                   |
+| `target_id`      | ID of the audit event's target                             |                                                                                   |
+| `target_type`    | String representation of the target's type                 |                                                                                   |
+
+### JSON payload schema
+
+```json
+{
+  "properties": {
+    "id": {
+      "type": "string"
+    },
+    "author_id": {
+      "type": "integer"
+    },
+    "author_name": {
+      "type": "string"
+    },
+    "details": {},
+    "ip_address": {
+      "type": "string"
+    },
+    "entity_id": {
+      "type": "integer"
+    },
+    "entity_path": {
+      "type": "string"
+    },
+    "entity_type": {
+      "type": "string"
+    },
+    "event_type": {
+      "type": "string"
+    },
+    "target_id": {
+      "type": "integer"
+    },
+    "target_type": {
+      "type": "string"
+    },
+    "target_details": {
+      "type": "string"
+    },
+  },
+  "type": "object"
+}
+```
diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index 50bd943b8e4..e924da39145 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -69,7 +69,8 @@ You can view audit events from user actions across an entire GitLab instance.
 
 To view instance audit events:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Monitoring > Audit Events**.
 
 ### Export to CSV
@@ -80,7 +81,8 @@ To view instance audit events:
 You can export the current view (including filters) of your instance audit events as a CSV file. To export the instance
 audit events to CSV:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Monitoring > Audit Events**.
 1. Select the available search [filters](#filter-audit-events).
 1. Select **Export as CSV**.
@@ -393,6 +395,8 @@ The following user actions on a GitLab instance generate instance audit events:
 - User was unblocked using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115727) in GitLab 15.11.
 - User was banned using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116103) in GitLab 15.11.
 - User was unbanned using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116221) in GitLab 15.11.
+- User was deactivated using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117776) in GitLab 16.0.
+- User was activated using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121708) in GitLab 16.1.
 
 Instance events can also be accessed using the [Instance Audit Events API](../api/audit_events.md#instance-audit-events).
 
diff --git a/doc/administration/auditor_users.md b/doc/administration/auditor_users.md
index 38c3a089756..3b6992c92e0 100644
--- a/doc/administration/auditor_users.md
+++ b/doc/administration/auditor_users.md
@@ -31,7 +31,8 @@ To create a new user account with auditor access (or change an existing user):
 
 To create a user account with auditor access:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Overview > Users**.
 1. Create a new user or edit an existing one. Set **Access Level** to **Auditor**.
 1. If you created a user, select **Create user**. For an existing user, select **Save changes**.
diff --git a/doc/administration/auth/atlassian.md b/doc/administration/auth/atlassian.md
index 45617b9965c..8525b3e9b98 100644
--- a/doc/administration/auth/atlassian.md
+++ b/doc/administration/auth/atlassian.md
@@ -29,13 +29,13 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu
 
 1. On your GitLab server, open the configuration file:
 
-   For Omnibus GitLab installations:
+   For Linux package installations:
 
    ```shell
    sudo editor /etc/gitlab/gitlab.rb
    ```
 
-   For installations from source:
+   For self-compiled installations:
 
    ```shell
    sudo -u git -H editor /home/git/gitlab/config/gitlab.yml
@@ -47,7 +47,7 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu
    GitLab account.
 1. Add the provider configuration for Atlassian:
 
-   For Omnibus GitLab installations:
+   For Linux package installations:
 
    ```ruby
    gitlab_rails['omniauth_providers'] = [
@@ -61,7 +61,7 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu
    ]
    ```
 
-   For installations from source:
+   For self-compiled installations:
 
    ```yaml
    - { name: "atlassian_oauth2",
@@ -76,8 +76,8 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu
 1. Save the configuration file.
 
 1. For the changes to take effect:
-   - If you installed via Omnibus, [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-   - If you installed from source, [restart GitLab](../restart_gitlab.md#installations-from-source).
+   - If you installed using the Linux package, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
+   - If you self-compiled your installation, [restart GitLab](../restart_gitlab.md#installations-from-source).
 
 On the sign-in page there should now be an Atlassian icon below the regular sign in form. Select the icon to begin the authentication process.
 
diff --git a/doc/administration/auth/cognito.md b/doc/administration/auth/cognito.md
index cfac958e297..8c8abf1524f 100644
--- a/doc/administration/auth/cognito.md
+++ b/doc/administration/auth/cognito.md
@@ -37,16 +37,14 @@ To enable AWS Cognito as an authentication provider, complete the following step
 
 1. Save changes for the app client settings.
 1. Under **Domain name**, include the AWS domain name for your AWS Cognito application.
-1. Under **App Clients**, find your app client ID. Select **Show details* to display the app client secret. These values correspond to the OAuth 2.0 Client ID and Client Secret. Save these values.
+1. Under **App Clients**, find your app client ID. Select **Show details** to display the app client secret. These values correspond to the OAuth 2.0 Client ID and Client Secret. Save these values.
 
 ## Configure GitLab
 
 1. Configure the [common settings](../../integration/omniauth.md#configure-common-settings)
    to add `cognito` as a single sign-on provider. This enables Just-In-Time
    account provisioning for users who do not have an existing GitLab account.
-1. On your GitLab server, open the configuration file.
-
-   **For Omnibus installations**
+1. On your GitLab server, open the configuration file. For Linux package installations:
 
    ```shell
    sudo editor /etc/gitlab/gitlab.rb
@@ -90,7 +88,7 @@ To enable AWS Cognito as an authentication provider, complete the following step
    ```
 
 1. Save the configuration file.
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation) GitLab for the changes to take effect.
 
 Your sign-in page should now display a Cognito option below the regular sign-in form.
 Select this option to begin the authentication process.
diff --git a/doc/administration/auth/crowd.md b/doc/administration/auth/crowd.md
index f89e1a00928..08c1f5e7513 100644
--- a/doc/administration/auth/crowd.md
+++ b/doc/administration/auth/crowd.md
@@ -26,19 +26,19 @@ this provider also allows Crowd authentication for Git-over-https requests.
 
 1. On your GitLab server, open the configuration file.
 
-   **Omnibus:**
+   - Linux package installations:
 
-   ```shell
-     sudo editor /etc/gitlab/gitlab.rb
-   ```
+     ```shell
+       sudo editor /etc/gitlab/gitlab.rb
+     ```
 
-   **Source:**
+   - Self-compiled installations:
 
-   ```shell
-     cd /home/git/gitlab
+     ```shell
+       cd /home/git/gitlab
 
-     sudo -u git -H editor config/gitlab.yml
-   ```
+       sudo -u git -H editor config/gitlab.yml
+     ```
 
 1. Configure the [common settings](../../integration/omniauth.md#configure-common-settings)
    to add `crowd` as a single sign-on provider. This enables Just-In-Time
@@ -46,39 +46,39 @@ this provider also allows Crowd authentication for Git-over-https requests.
 
 1. Add the provider configuration:
 
-   **Omnibus:**
-
-   ```ruby
-     gitlab_rails['omniauth_providers'] = [
-       {
-         name: "crowd",
-         # label: "Provider name", # optional label for login button, defaults to "Crowd"
-         args: {
-           crowd_server_url: "CROWD_SERVER_URL",
-           application_name: "YOUR_APP_NAME",
-           application_password: "YOUR_APP_PASSWORD"
+   - Linux package installations:
+
+     ```ruby
+       gitlab_rails['omniauth_providers'] = [
+         {
+           name: "crowd",
+           # label: "Provider name", # optional label for login button, defaults to "Crowd"
+           args: {
+             crowd_server_url: "CROWD_SERVER_URL",
+             application_name: "YOUR_APP_NAME",
+             application_password: "YOUR_APP_PASSWORD"
+           }
          }
-       }
-     ]
-   ```
+       ]
+     ```
 
-   **Source:**
+   - Self-compiled installations:
 
-   ```yaml
-      - { name: 'crowd',
-          # label: 'Provider name', # optional label for login button, defaults to "Crowd"
-          args: {
-            crowd_server_url: 'CROWD_SERVER_URL',
-            application_name: 'YOUR_APP_NAME',
-            application_password: 'YOUR_APP_PASSWORD' } }
-   ```
+     ```yaml
+        - { name: 'crowd',
+            # label: 'Provider name', # optional label for login button, defaults to "Crowd"
+            args: {
+              crowd_server_url: 'CROWD_SERVER_URL',
+              application_name: 'YOUR_APP_NAME',
+              application_password: 'YOUR_APP_PASSWORD' } }
+     ```
 
 1. Change `CROWD_SERVER_URL` to the [base URL of your Crowd server](https://confluence.atlassian.com/crowdkb/how-to-change-the-crowd-base-url-245827278.html).
 1. Change `YOUR_APP_NAME` to the application name from Crowd applications page.
 1. Change `YOUR_APP_PASSWORD` to the application password you've set.
 1. Save the configuration file.
-1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) (Omnibus GitLab) or [restart](../restart_gitlab.md#installations-from-source) (source installations) for
-   the changes to take effect.
+1. [Reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation) (Linux package installations) or
+   [restart](../restart_gitlab.md#installations-from-source) (self-compiled installations) for the changes to take effect.
 
 On the sign in page there should now be a Crowd tab in the sign in form.
 
diff --git a/doc/administration/auth/jwt.md b/doc/administration/auth/jwt.md
index 9994b374038..9a74064136a 100644
--- a/doc/administration/auth/jwt.md
+++ b/doc/administration/auth/jwt.md
@@ -12,13 +12,13 @@ JWT provides you with a secret key for you to use.
 
 1. On your GitLab server, open the configuration file.
 
-   For Omnibus GitLab:
+   For Linux package installations:
 
    ```shell
    sudo editor /etc/gitlab/gitlab.rb
    ```
 
-   For installations from source:
+   For self-compiled installations:
 
    ```shell
    cd /home/git/gitlab
@@ -30,7 +30,7 @@ JWT provides you with a secret key for you to use.
    account provisioning for users who do not have an existing GitLab account.
 1. Add the provider configuration.
 
-   For Omnibus GitLab:
+   For Linux package installations:
 
    ```ruby
    gitlab_rails['omniauth_providers'] = [
@@ -49,7 +49,7 @@ JWT provides you with a secret key for you to use.
    ]
    ```
 
-   For installation from source:
+   For self-compiled installations:
 
    ```yaml
    - { name: 'jwt',
@@ -70,11 +70,14 @@ JWT provides you with a secret key for you to use.
    For more information on each configuration option refer to
    the [OmniAuth JWT usage documentation](https://github.com/mbleigh/omniauth-jwt#usage).
 
+   WARNING:
+   Incorrectly configuring these settings can result in an insecure instance.
+
 1. Change `YOUR_APP_SECRET` to the client secret and set `auth_url` to your redirect URL.
 1. Save the configuration file.
-1. For the changes to take effect:
-   - If you installed via Omnibus, [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-   - If you installed from source, [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. For changes to take effect, if you:
+   - Used the Linux package to install GitLab, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
+   - Self-compiled your GitLab installation, [restart GitLab](../restart_gitlab.md#installations-from-source).
 
 On the sign in page there should now be a JWT icon below the regular sign in form.
 Select the icon to begin the authentication process. JWT asks the user to
diff --git a/doc/administration/auth/ldap/google_secure_ldap.md b/doc/administration/auth/ldap/google_secure_ldap.md
index 042a65be500..d484059c79f 100644
--- a/doc/administration/auth/ldap/google_secure_ldap.md
+++ b/doc/administration/auth/ldap/google_secure_ldap.md
@@ -72,7 +72,7 @@ values obtained during the LDAP client configuration earlier:
 - `cert`: The `.crt` file text from the downloaded certificate bundle
 - `key`: The `.key` file text from the downloaded certificate bundle
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -140,11 +140,9 @@ values obtained during the LDAP client configuration earlier:
    EOS
    ```
 
-1. Save the file and [reconfigure](../../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
+1. Save the file and [reconfigure](../../restart_gitlab.md#reconfigure-a-linux-package-installation) GitLab for the changes to take effect.
 
----
-
-**For installations from source**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml`:
 
diff --git a/doc/administration/auth/ldap/index.md b/doc/administration/auth/ldap/index.md
index 7687f7c9340..a4484da5940 100644
--- a/doc/administration/auth/ldap/index.md
+++ b/doc/administration/auth/ldap/index.md
@@ -233,6 +233,7 @@ These configuration settings are available:
 | `user_filter`      | Filter LDAP users. Format: [RFC 4515](https://www.rfc-editor.org/rfc/rfc4515.html) Note: GitLab does not support `omniauth-ldap`'s custom filter syntax. | **{dotted-circle}** No | Some examples of the `user_filter` field syntax:<br/><br/>- `'(employeeType=developer)'`<br/>- `'(&(objectclass=user)(|(samaccountname=momo)(samaccountname=toto)))'` |
 | `lowercase_usernames` | If enabled, GitLab converts the name to lower case. | **{dotted-circle}** No | boolean |
 | `retry_empty_result_with_codes` | An array of LDAP query response code that attempt to retry the operation if the result/content is empty. For Google Secure LDAP, set this value to `[80]`. | **{dotted-circle}** No | `[80]` |
+| `attributes` | A hash of attribute mappings to LDAP for GitLab to use ([see attributes section](#attribute-configuration-settings)). | **{dotted-circle}** No | `'attributes' => { 'username' => ['uid'], 'email' => ['mail', 'email'] },` |
 
 ### SSL configuration settings
 
@@ -256,6 +257,8 @@ attribute can be either:
 
 The user's LDAP sign in is the LDAP attribute [specified as `uid`](#basic-configuration-settings).
 
+You must define the following attributes in an `attributes` hash.
+
 | Setting      | Description | Required | Examples |
 |--------------|-------------|----------|----------|
 | `username`   | Used in paths for the user's own projects (for example, `gitlab.example.com/username/project`) and when mentioning them in issues, merge request and comments (for example, `@username`). If the attribute specified for `username` contains an email address, the GitLab username is part of the email address before the `@`. | **{dotted-circle}** No | `['uid', 'userid', 'sAMAccountName']` |
@@ -1034,8 +1037,8 @@ For more information on synchronizing users and groups between LDAP and GitLab,
 ## Move from LDAP to SAML
 
 1. [Configure SAML](../../../integration/saml.md). Add `auto_link_ldap_user` to:
-   - [`gitlab.rb` for Omnibus](../../../integration/saml.html?tab=Linux+package+%28Omnibus%29).
-   - [`values.yml` for Kubernetes](../../../integration/saml.html?tab=Helm+chart+%28Kubernetes%29).
+   - [`gitlab.rb` for Linux package installations](../../../integration/saml.html?tab=Linux+package+%28Omnibus%29).
+   - [`values.yml` for Helm chart installations](../../../integration/saml.html?tab=Helm+chart+%28Kubernetes%29).
    For more information, see the [initial settings for all providers](../../../integration/omniauth.md#configure-initial-settings).
 
 1. Optional. [Disable the LDAP auth from the sign-in page](#disable-ldap-web-sign-in).
@@ -1047,7 +1050,7 @@ For more information on synchronizing users and groups between LDAP and GitLab,
 1. In the configuration file, change:
    - `omniauth_auto_link_user` to `saml` only.
    - `omniauth_auto_link_ldap_user` to false.
-   - `ldap_enabled` to `false`. 
+   - `ldap_enabled` to `false`.
    You can also comment out the LDAP provider settings.
 
 ## Troubleshooting
diff --git a/doc/administration/auth/ldap/ldap-troubleshooting.md b/doc/administration/auth/ldap/ldap-troubleshooting.md
index 909ab5245ca..9fb3888b995 100644
--- a/doc/administration/auth/ldap/ldap-troubleshooting.md
+++ b/doc/administration/auth/ldap/ldap-troubleshooting.md
@@ -167,7 +167,8 @@ may see the following message: `Access denied for your LDAP account`.
 
 We have a workaround, based on toggling the access level of affected users:
 
-1. As an administrator, on the top bar, select **Main menu > Admin**.
+1. As an administrator, on the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Overview > Users**.
 1. Select the name of the affected user.
 1. In the upper-right corner, select **Edit**.
@@ -224,7 +225,8 @@ field contains no data:
 
 To resolve this:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, go to **Settings > General**.
 1. Expand both of the following:
    - **Account and limit**.
@@ -367,7 +369,8 @@ things to debug the situation.
 - Ensure the correct [LDAP group link is added to the GitLab group](ldap_synchronization.md#add-group-links).
 - Check that the user has an LDAP identity:
   1. Sign in to GitLab as an administrator user.
-  1. On the top bar, select **Main menu > Admin**.
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
   1. On the left sidebar, select **Overview > Users**.
   1. Search for the user.
   1. Open the user by selecting their name. Do not select **Edit**.
@@ -733,10 +736,17 @@ cause:
 To resolve this error, you must apply a new license to the GitLab instance without the web interface:
 
 1. Remove or comment out the GitLab configuration lines for all non-primary LDAP servers.
-1. [Reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so that it temporarily uses only one LDAP server.
+1. [Reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) so that it temporarily uses only one LDAP server.
 1. Enter the [Rails console and add the license key](../../../user/admin_area/license_file.md#add-a-license-through-the-console).
 1. Re-enable the additional LDAP servers in the GitLab configuration and reconfigure GitLab again.
 
+## Users are being removed from group and re-added again
+
+If a user has been added to a group during group sync, and removed at the next sync, and this has happened repeatedly, make sure that the user doesn't have
+multiple or redundant LDAP identities.
+
+If one of those identities was added for an older LDAP provider that is no longer in use, [remove the `identity` records that relate to the removed LDAP server](#remove-the-identity-records-that-relate-to-the-removed-ldap-server).
+
 ## Debugging Tools
 
 ### LDAP check
diff --git a/doc/administration/auth/ldap/ldap_synchronization.md b/doc/administration/auth/ldap/ldap_synchronization.md
index f32a4af9e27..e4b43feacc2 100644
--- a/doc/administration/auth/ldap/ldap_synchronization.md
+++ b/doc/administration/auth/ldap/ldap_synchronization.md
@@ -15,7 +15,7 @@ You can change when synchronization occurs.
 
 ## User sync
 
-> Preventing LDAP username synchronization [introduced](<https://gitlab.com/gitlab-org/gitlab/-/issues/11336>) in GitLab 15.11.
+> Preventing LDAP user's profile name synchronization [introduced](<https://gitlab.com/gitlab-org/gitlab/-/issues/11336>) in GitLab 15.11.
 
 Once per day, GitLab runs a worker to check and update GitLab
 users against LDAP.
@@ -45,9 +45,9 @@ The process also updates the following user information:
 - SSH public keys if `sync_ssh_keys` is set.
 - Kerberos identity if Kerberos is enabled.
 
-### Synchronize LDAP username
+### Synchronize LDAP user's profile name
 
-By default, GitLab synchronizes the LDAP username field.
+By default, GitLab synchronizes the LDAP user's profile name field.
 
 To prevent this synchronization, you can set `sync_name` to `false`.
 
@@ -501,7 +501,8 @@ When global group memberships lock is enabled:
 To enable global group memberships lock:
 
 1. [Configure LDAP](index.md#configure-ldap).
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. Ensure the **Lock memberships to LDAP synchronization** checkbox is selected.
@@ -513,7 +514,8 @@ By default, group members with the Owner role can manage [LDAP group synchroniza
 GitLab administrators can remove this permission from group Owners:
 
 1. [Configure LDAP](index.md#configure-ldap).
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Visibility and access controls**.
 1. Ensure the **Allow group owners to manage LDAP-related settings** checkbox is not checked.
diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index 106cc6c23eb..23d2ab512db 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -16,7 +16,7 @@ The OpenID Connect provides you with a client's details and secret for you to us
 
 1. On your GitLab server, open the configuration file.
 
-   For Omnibus GitLab:
+   For Linux package installations:
 
    ```shell
    sudo editor /etc/gitlab/gitlab.rb
@@ -35,7 +35,7 @@ The OpenID Connect provides you with a client's details and secret for you to us
 
 1. Add the provider configuration.
 
-   For Omnibus GitLab:
+   For Linux package installations:
 
    ```ruby
    gitlab_rails['omniauth_providers'] = [
@@ -63,7 +63,7 @@ The OpenID Connect provides you with a client's details and secret for you to us
    ]
    ```
 
-   For Omnibus GitLab with multiple identity providers:
+   For Linux package installations with multiple identity providers:
 
    ```ruby
    { 'name' => 'openid_connect',
@@ -108,7 +108,7 @@ The OpenID Connect provides you with a client's details and secret for you to us
    NOTE:
    For more information on using multiple identity providers with OIDC, see [issue 5992](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5992).
 
-   For installation from source:
+   For self-compiled installations:
 
    ```yaml
      - { name: 'openid_connect', # do not change this parameter
@@ -184,10 +184,10 @@ The OpenID Connect provides you with a client's details and secret for you to us
        - `jwks_uri` is the URL to the endpoint where the Token signer publishes its keys.
 
 1. Save the configuration file.
-1. For changes to take effect, if you installed GitLab:
+1. For changes to take effect, if you:
 
-   - With Omnibus, [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-   - From source, [restart GitLab](../restart_gitlab.md#installations-from-source).
+   - Used the Linux package to install GitLab, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
+   - Self-compiled your GitLab installation, [restart GitLab](../restart_gitlab.md#installations-from-source).
 
 On the sign in page, you have an OpenID Connect option below the regular sign in form.
 Select this option to begin the authentication process. The OpenID Connect provider
@@ -197,7 +197,7 @@ by the client. You are redirected to GitLab and signed in.
 ## Example configurations
 
 The following configurations illustrate how to set up OpenID with
-different providers with Omnibus GitLab.
+different providers when using the Linux package installation.
 
 ### Configure Google
 
@@ -240,7 +240,7 @@ you need the following information:
   [Microsoft Quickstart Register an Application](https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app) documentation
   to obtain the tenant ID, client ID, and client secret for your app.
 
-Example Omnibus configuration block:
+Example configuration block for Linux package installations:
 
 ```ruby
 gitlab_rails['omniauth_providers'] = [
@@ -372,7 +372,7 @@ but `LocalAccounts` authenticates against local Active Directory accounts. Befor
    ```
 
 1. Configure the issuer URL with the custom policy used for `signup_signin`. For example, this is
-   the Omnibus configuration with a custom policy for `b2c_1a_signup_signin`:
+   the configuration with a custom policy for `b2c_1a_signup_signin` for Linux package installations:
 
    ```ruby
    gitlab_rails['omniauth_providers'] = [
@@ -432,7 +432,7 @@ HS256 or HS358) to sign tokens. Public key encryption algorithms are:
 1. Select **Realm Settings > Tokens > Default Signature Algorithm**.
 1. Configure the signature algorithm.
 
-Example Omnibus configuration block:
+Example configuration block for Linux package installations:
 
 ```ruby
 gitlab_rails['omniauth_providers'] = [
@@ -556,7 +556,7 @@ For your app, complete the following steps on Casdoor:
 
 See the [Casdoor documentation](https://casdoor.org/docs/integration/ruby/gitlab) for more details.
 
-Example Omnibus GitLab configuration (file path: `/etc/gitlab/gitlab.rb`):
+Example configuration for Linux package installations (file path: `/etc/gitlab/gitlab.rb`):
 
 ```ruby
 gitlab_rails['omniauth_providers'] = [
@@ -617,7 +617,7 @@ This is not compatible with [configuring users based on OIDC group membership](#
 
 The following example configurations show how to offer different levels of authentication, one option with 2FA and one without 2FA.
 
-For Omnibus GitLab:
+For Linux package installations:
 
 ```ruby
 gitlab_rails['omniauth_providers'] = [
@@ -668,7 +668,7 @@ gitlab_rails['omniauth_providers'] = [
 ]
 ```
 
-For installation from source:
+For self-compiled installations:
 
 ```yaml
   - { name: 'openid_connect',
@@ -774,7 +774,7 @@ response to require users to be members of a certain group, configure GitLab to
 
 If you do not set `required_groups` or leave the setting empty, any user authenticated by the IdP through OIDC can use GitLab.
 
-For Omnibus GitLab:
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -805,10 +805,10 @@ For Omnibus GitLab:
    ]
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
-For installation from source:
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml`:
 
@@ -853,7 +853,7 @@ based on group membership, configure GitLab to identify:
   [external user](../../user/admin_area/external_users.md), using the
  `external_groups` setting.
 
-For Omnibus GitLab:
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -884,10 +884,10 @@ For Omnibus GitLab:
    ]
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
-For installation from source:
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml`:
 
@@ -930,7 +930,7 @@ response to assign users as administrator based on group membership, configure G
 - Which group memberships grant the user administrator access, using the
  `admin_groups` setting.
 
-For Omnibus GitLab:
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -961,10 +961,10 @@ For Omnibus GitLab:
    ]
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
-For installation from source:
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml`:
 
diff --git a/doc/administration/auth/smartcard.md b/doc/administration/auth/smartcard.md
index 5b6d299f171..9432a627ed7 100644
--- a/doc/administration/auth/smartcard.md
+++ b/doc/administration/auth/smartcard.md
@@ -115,7 +115,7 @@ more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/
 
 ## Configure GitLab for smartcard authentication
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -137,12 +137,10 @@ more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/
    `gitlab_rails['smartcard_client_certificate_required_host']` or
    `gitlab_rails['smartcard_client_certificate_required_port']`.
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    GitLab for the changes to take effect.
 
----
-
-**For installations from source**
+For self-compiled installations:
 
 1. Configure NGINX to request a client side certificate
 
@@ -237,7 +235,7 @@ more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/
 
 ### Additional steps when using SAN extensions
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Add to `/etc/gitlab/gitlab.rb`:
 
@@ -245,10 +243,10 @@ more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/
    gitlab_rails['smartcard_san_extensions'] = true
    ```
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    GitLab for the changes to take effect.
 
-**For installations from source**
+For self-compiled installations:
 
 1. Add the `san_extensions` line to `config/gitlab.yml` within the smartcard section:
 
@@ -267,7 +265,7 @@ more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/
 
 ### Additional steps when authenticating against an LDAP server
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -281,10 +279,10 @@ more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/
    EOS
    ```
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    GitLab for the changes to take effect.
 
-**For installations from source**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml`:
 
@@ -304,7 +302,7 @@ more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/
 
 ### Require browser session with smartcard sign-in for Git access
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -312,10 +310,10 @@ more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/
    gitlab_rails['smartcard_required_for_git_access'] = true
    ```
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    GitLab for the changes to take effect.
 
-**For installations from source**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml`:
 
diff --git a/doc/administration/cicd.md b/doc/administration/cicd.md
index ad0671d4c13..a3d9a853aaf 100644
--- a/doc/administration/cicd.md
+++ b/doc/administration/cicd.md
@@ -15,7 +15,7 @@ GitLab CI/CD is enabled by default in all new projects on an instance. You can s
 CI/CD to be disabled by default in new projects by modifying the settings in:
 
 - `gitlab.yml` for source installations.
-- `gitlab.rb` for Omnibus GitLab installations.
+- `gitlab.rb` for Linux package installations.
 
 Existing projects that already had CI/CD enabled are unchanged. Also, this setting only changes
 the project default, so project owners [can still enable CI/CD in the project settings](../ci/enable_or_disable_ci.md#enable-cicd-in-a-project).
@@ -42,7 +42,7 @@ For installations from source:
    sudo service gitlab restart
    ```
 
-For Omnibus GitLab installations:
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add this line:
 
@@ -88,7 +88,7 @@ is listed in the [GitLab.com settings](../user/gitlab_com/index.md#gitlab-cicd).
 To change the frequency of the pipeline schedule worker:
 
 1. Edit the `gitlab_rails['pipeline_schedule_worker_cron']` value in your instance's `gitlab.rb` file.
-1. [Reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 For example, to set the maximum frequency of pipelines to twice a day, set `pipeline_schedule_worker_cron`
 to a cron value of `0 */12 * * *` (`00:00` and `12:00` every day).
diff --git a/doc/administration/clusters/kas.md b/doc/administration/clusters/kas.md
index 6d6e8e5513c..b44c9571715 100644
--- a/doc/administration/clusters/kas.md
+++ b/doc/administration/clusters/kas.md
@@ -21,12 +21,12 @@ If you use self-managed GitLab, you must install an agent server or specify an e
 
 As a GitLab administrator, you can install the agent server:
 
-- For [Omnibus installations](#for-omnibus).
-- For [GitLab Helm Chart installations](#for-gitlab-helm-chart).
+- For [Linux package installations](#for-linux-package-installations).
+- For [GitLab Helm chart installations](#for-gitlab-helm-chart).
 
-### For Omnibus
+### For Linux package installations
 
-You can enable the agent server for [Omnibus](https://docs.gitlab.com/omnibus/) package installations on a single node, or on multiple nodes at once.
+You can enable the agent server for Linux package installations on a single node, or on multiple nodes at once.
 
 #### Enable on a single node
 
@@ -38,7 +38,7 @@ To enable the agent server on a single node:
    gitlab_kas['enable'] = true
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 For additional configuration options, see the **Enable GitLab KAS** section of the
 [`gitlab.rb.template`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/files/gitlab-config-template/gitlab.rb.template).
@@ -68,7 +68,7 @@ To configure KAS to listen on a UNIX socket:
    }
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 #### Enable on multiple nodes
 
@@ -94,7 +94,7 @@ To enable the agent server on multiple nodes:
    gitlab_rails['gitlab_kas_external_k8s_proxy_url'] = 'https://gitlab.example.com/-/kubernetes-agent/k8s-proxy/'
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ##### Agent server node settings
 
@@ -167,7 +167,7 @@ service logs by running the following command:
 kubectl logs -f -l=app=kas -n <YOUR-GITLAB-NAMESPACE>
 ```
 
-In Omnibus GitLab, find the logs in `/var/log/gitlab/gitlab-kas/`.
+In Linux package installations, find the logs in `/var/log/gitlab/gitlab-kas/`.
 
 You can also [troubleshoot issues with individual agents](../../user/clusters/agent/troubleshooting.md).
 
@@ -212,7 +212,7 @@ When the agent server tries to connect to the GitLab API, the following error mi
 {"level":"error","time":"2021-08-16T14:56:47.289Z","msg":"GetAgentInfo()","correlation_id":"01FD7QE35RXXXX8R47WZFBAXTN","grpc_service":"gitlab.agent.reverse_tunnel.rpc.ReverseTunnel","grpc_method":"Connect","error":"Get \"https://gitlab.example.com/api/v4/internal/kubernetes/agent_info\": dial tcp 172.17.0.4:443: connect: connection refused"}
 ```
 
-To fix this issue for [Omnibus](https://docs.gitlab.com/omnibus/) package installations,
+To fix this issue for Linux package installations,
 set the following parameter in `/etc/gitlab/gitlab.rb`. Replace `gitlab.example.com` with your GitLab instance's hostname:
 
 ```ruby
diff --git a/doc/administration/compliance.md b/doc/administration/compliance.md
index 9ae0e9d7790..79133d5a6c7 100644
--- a/doc/administration/compliance.md
+++ b/doc/administration/compliance.md
@@ -73,5 +73,5 @@ These features can also help with compliance requirements:
 | [Lock project membership to group](../user/group/access_and_permissions.md#prevent-members-from-being-added-to-projects-in-a-group) | **{dotted-circle}** No | **{check-circle}** Yes | **{dotted-circle}** No | Group owners can prevent new members from being added to projects in a group.                                                                                          |
 | [LDAP group sync](auth/ldap/ldap_synchronization.md#group-sync)                                                                     | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Automatically synchronize groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.          |
 | [LDAP group sync filters](auth/ldap/ldap_synchronization.md#group-sync)                                                             | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.                                  |
-| [Omnibus GitLab package supports<br/>log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)         | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Forward your logs to a central system.                                                                                                                                 |
+| [Linux package installations support<br/>log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)     | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Forward your logs to a central system.                                                                                                                                 |
 | [Restrict SSH Keys](../security/ssh_keys_restrictions.md)                                                                           | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Control the technology and key length of SSH keys used to access GitLab.                                                                                               |
diff --git a/doc/administration/consul.md b/doc/administration/consul.md
index 965231db440..5a8946dbcf7 100644
--- a/doc/administration/consul.md
+++ b/doc/administration/consul.md
@@ -49,7 +49,7 @@ On _each_ Consul server node:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. [Reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes
+1. [Reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes
    to take effect.
 1. Run the following command to ensure Consul is both configured correctly and
    to verify that all server nodes are communicating:
@@ -76,7 +76,7 @@ To upgrade your Consul nodes, upgrade the GitLab package.
 
 Nodes should be:
 
-- Members of a healthy cluster prior to upgrading the Omnibus GitLab package.
+- Members of a healthy cluster prior to upgrading the Linux package.
 - Upgraded one node at a time.
 
 Identify any existing health issues in the cluster by running the following command
diff --git a/doc/administration/docs_self_host.md b/doc/administration/docs_self_host.md
index d1ad36880dd..54f8c15a922 100644
--- a/doc/administration/docs_self_host.md
+++ b/doc/administration/docs_self_host.md
@@ -84,7 +84,7 @@ You can use GitLab Pages to host the GitLab product documentation.
 
 Prerequisite:
 
-- Ensure the Pages site URL does not use a subfolder. Because of the way the                       
+- Ensure the Pages site URL does not use a subfolder. Because of the way the
   site is pre-compiled, the CSS and JavaScript files are relative to the
   main domain or subdomain. For example, URLs like `https://example.com/docs/`
   are not supported.
@@ -179,7 +179,7 @@ documentation URL requests as needed. For example, if your GitLab version is
 
 To test the setting, in GitLab, select a **Learn more** link. For example:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Preferences**.
 1. In the **Syntax highlighting theme** section, select **Learn more**.
 
diff --git a/doc/administration/encrypted_configuration.md b/doc/administration/encrypted_configuration.md
index 1ddf2951f70..808967778fa 100644
--- a/doc/administration/encrypted_configuration.md
+++ b/doc/administration/encrypted_configuration.md
@@ -19,22 +19,14 @@ GitLab can read settings for certain features from encrypted settings files. The
 To enable the encrypted configuration settings, a new base key must be generated for
 `encrypted_settings_key_base`. The secret can be generated in the following ways:
 
-**Omnibus**
+- For Linux package installations, the new secret is automatically generated for you, but you must ensure your
+  `/etc/gitlab/gitlab-secrets.json` contains the same values on all nodes.
+- For Helm chart installations, the new secret is automatically generated if you have the `shared-secrets` chart enabled.
+  Otherwise, you need to follow the [secrets guide for adding the secret](https://docs.gitlab.com/charts/installation/secrets.html#gitlab-rails-secret).
+- For self-compiled installations, the new secret can be generated by running:
 
-Starting with 13.7 the new secret is automatically generated for you, but you must ensure your
-`/etc/gitlab/gitlab-secrets.json` contains the same values on all nodes.
+  ```shell
+  bundle exec rake gitlab:env:info RAILS_ENV=production GITLAB_GENERATE_ENCRYPTED_SETTINGS_KEY_BASE=true
+  ```
 
-**Helm chart**
-
-Starting with GitLab 13.7, the new secret is automatically generated if you have the `shared-secrets` chart enabled. Otherwise, you need
-to follow the [secrets guide for adding the secret](https://docs.gitlab.com/charts/installation/secrets.html#gitlab-rails-secret).
-
-**Source**
-
-The new secret can be generated by running:
-
-```shell
-bundle exec rake gitlab:env:info RAILS_ENV=production GITLAB_GENERATE_ENCRYPTED_SETTINGS_KEY_BASE=true
-```
-
-This prints general information on the GitLab instance, but also causes the key to be generated in `<path-to-gitlab-rails>/config/secrets.yml`.
+  This prints general information on the GitLab instance and generates the key in `<path-to-gitlab-rails>/config/secrets.yml`.
diff --git a/doc/administration/environment_variables.md b/doc/administration/environment_variables.md
index a453d703a18..260095d12ac 100644
--- a/doc/administration/environment_variables.md
+++ b/doc/administration/environment_variables.md
@@ -10,8 +10,10 @@ type: reference
 GitLab exposes certain environment variables which can be used to override
 their defaults values.
 
-People usually configure GitLab with `/etc/gitlab/gitlab.rb` for Omnibus
-installations, or `gitlab.yml` for installations from source.
+People usually configure GitLab with:
+
+- `/etc/gitlab/gitlab.rb` for Linux package installations.
+- `gitlab.yml` for self-compiled installations.
 
 You can use the following environment variables to override certain values:
 
@@ -44,11 +46,10 @@ We welcome merge requests to make more settings configurable by using variables.
 Make changes to the `config/initializers/1_settings.rb` file, and use the
 naming scheme `GITLAB_#{name in 1_settings.rb in upper case}`.
 
-## Omnibus configuration
+## Linux package installation configuration
 
 To set environment variables, follow [these instructions](https://docs.gitlab.com/omnibus/settings/environment-variables.html).
 
 It's possible to preconfigure the GitLab Docker image by adding the environment
 variable `GITLAB_OMNIBUS_CONFIG` to the `docker run` command.
-For more information, see the [Pre-configure Docker container](../install/docker.md#pre-configure-docker-container)
-section of the Omnibus GitLab documentation.
+For more information, see [Pre-configure Docker container](../install/docker.md#pre-configure-docker-container).
diff --git a/doc/administration/feature_flags.md b/doc/administration/feature_flags.md
index 26deff0ca84..ea79a2b69b4 100644
--- a/doc/administration/feature_flags.md
+++ b/doc/administration/feature_flags.md
@@ -71,7 +71,7 @@ the status of the flag and the command to enable or disable it.
 The first thing you must do to enable or disable a feature behind a flag is to
 start a session on GitLab Rails console.
 
-For Omnibus installations:
+For Linux package installations:
 
 ```shell
 sudo gitlab-rails console
diff --git a/doc/administration/file_hooks.md b/doc/administration/file_hooks.md
index dfddf38475c..904da47caff 100644
--- a/doc/administration/file_hooks.md
+++ b/doc/administration/file_hooks.md
@@ -34,13 +34,12 @@ where you can find some basic examples.
 
 Follow the steps below to set up a custom hook:
 
-1. On the GitLab server, navigate to the plugin directory.
-   For an installation from source the path is usually
-   `/home/git/gitlab/file_hooks/`. For Omnibus installs the path is
-   usually `/opt/gitlab/embedded/service/gitlab-rails/file_hooks`.
+1. On the GitLab server, locate the plugin directory. For self-compiled installations, the path is usually
+   `/home/git/gitlab/file_hooks/`. For Linux package installations, the path is usually
+   `/opt/gitlab/embedded/service/gitlab-rails/file_hooks`.
 
-    For [configurations with multiple servers](reference_architectures/index.md),
-    your hook file should exist on each application server.
+   For [configurations with multiple servers](reference_architectures/index.md), your hook file should exist on each
+   application server.
 
 1. Inside the `file_hooks` directory, create a file with a name of your choice,
    without spaces or special characters.
@@ -59,11 +58,8 @@ need to restart GitLab to apply a new file hook.
 If a file hook executes with non-zero exit code or GitLab fails to execute it, a
 message is logged to:
 
-- `gitlab-rails/file_hook.log` in an Omnibus installation.
-- `log/file_hook.log` in a source installation.
-
-NOTE:
-In GitLab 13.12 and earlier, the filename was `plugin.log`
+- `gitlab-rails/file_hook.log` in a Linux package installation.
+- `log/file_hook.log` in a self-compiled installation.
 
 ## Creating file hooks
 
diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md
index ea4523c66e6..6d7240a9f92 100644
--- a/doc/administration/geo/disaster_recovery/background_verification.md
+++ b/doc/administration/geo/disaster_recovery/background_verification.md
@@ -49,7 +49,8 @@ Feature.enable('geo_repository_verification')
 
 On the **primary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Sites**.
 1. Expand **Verification information** tab for that site to view automatic checksumming
    status for repositories and wikis. Successes are shown in green, pending work
@@ -59,7 +60,8 @@ On the **primary** site:
 
 On the **secondary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Sites**.
 1. Expand **Verification information** tab for that site to view automatic checksumming
    status for repositories and wikis. Successes are shown in green, pending work
@@ -87,7 +89,8 @@ increase load and vice versa.
 
 On the **primary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Sites**.
 1. Select **Edit** for the **primary** site to customize the minimum
    re-verification interval:
@@ -135,7 +138,8 @@ sudo gitlab-rake geo:verification:wiki:reset
 If the **primary** and **secondary** sites have a checksum verification mismatch, the cause may not be apparent. To find the cause of a checksum mismatch:
 
 1. On the **primary** site:
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
    1. On the left sidebar, select **Overview > Projects**.
    1. Find the project that you want to check the checksum differences and
       select its name.
diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md
index 24a91a7a9c5..396162fe9ef 100644
--- a/doc/administration/geo/disaster_recovery/index.md
+++ b/doc/administration/geo/disaster_recovery/index.md
@@ -236,7 +236,7 @@ do this manually.
    roles ['geo_secondary_role']
    ```
 
-   After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+   After making these changes, [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    on each machine so the changes take effect.
 
 1. Promote the **secondary** to **primary**. SSH into a single application
@@ -444,7 +444,7 @@ required:
    roles ['geo_secondary_role']
    ```
 
-   After making these changes [Reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+   After making these changes [Reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    on each node so the changes take effect.
 
 1. Promote the **secondary** to **primary**. SSH into a single secondary application
@@ -542,19 +542,19 @@ Geo on the new **primary** site.
 
 To bring a new **secondary** site online, follow the [Geo setup instructions](../index.md#setup-instructions).
 
-### Step 6. (Optional) Removing the secondary's tracking database
+### Step 6. Removing the secondary's tracking database
 
 Every **secondary** has a special tracking database that is used to save the status of the synchronization of all the items from the **primary**.
 Because the **secondary** is already promoted, that data in the tracking database is no longer required.
 
-The data can be removed with the following command:
+You can remove the data with the following command:
 
 ```shell
 sudo rm -rf /var/opt/gitlab/geo-postgresql
 ```
 
 If you have any `geo_secondary[]` configuration options enabled in your `gitlab.rb`
-file, these can be safely commented out or removed, and then [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+file, comment them out or remove them, and then [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
 for the changes to take effect.
 
 ## Promoting secondary Geo replica in multi-secondary configurations
@@ -681,7 +681,8 @@ Data that was created on the primary while the secondary was paused is lost.
 
 If you are running GitLab 14.5 and later:
 
-1. For each node outside of the **secondary** Kubernetes cluster using Omnibus such as PostgreSQL or Gitaly, SSH into the node and run one of the following commands:
+1. For each node (such as PostgreSQL or Gitaly) outside of the **secondary** Kubernetes cluster using the Linux
+   package, SSH into the node and run one of the following commands:
 
    - To promote the **secondary** site node external to the Kubernetes cluster to primary:
 
@@ -731,7 +732,7 @@ If you are running GitLab 14.4 and earlier:
    roles ['geo_secondary_role']
    ```
 
-   After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) on the database node.
+   After making these changes, [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) on the database node.
 
 1. Find the task runner pod:
 
diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md
index a52bdc759a2..13e0938fa59 100644
--- a/doc/administration/geo/disaster_recovery/planned_failover.md
+++ b/doc/administration/geo/disaster_recovery/planned_failover.md
@@ -149,7 +149,8 @@ ensure these processes are close to 100% as possible during active use.
 
 On the **secondary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Sites**.
    Replicated objects (shown in green) should be close to 100%,
    and there should be no failures (shown in red). If a large proportion of
@@ -177,7 +178,8 @@ This [content was moved to another location](background_verification.md).
 
 On the **primary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Messages**.
 1. Add a message notifying users on the maintenance window.
    You can check under **Geo > Sites** to estimate how long it
@@ -190,7 +192,8 @@ To ensure that all data is replicated to a secondary site, updates (write reques
 be disabled on the **primary** site:
 
 1. Enable [maintenance mode](../../maintenance_mode/index.md) on the **primary** site.
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Monitoring > Background Jobs**.
 1. On the Sidekiq dashboard, select **Cron**.
 1. Select `Disable All` to disable non-Geo periodic background jobs.
@@ -206,7 +209,8 @@ GitLab 13.9 through GitLab 14.3 are affected by a bug in which the Geo secondary
 1. If you are manually replicating any data not managed by Geo, trigger the
    final replication process now.
 1. On the **primary** site:
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
    1. On the left sidebar, select **Monitoring > Background Jobs**.
    1. On the Sidekiq dashboard, select **Queues**, and wait for all queues except
       those with `geo` in the name to drop to 0.
@@ -221,7 +225,8 @@ GitLab 13.9 through GitLab 14.3 are affected by a bug in which the Geo secondary
       - The Geo log cursor is up to date (0 events behind).
 
 1. On the **secondary** site:
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
    1. On the left sidebar, select **Monitoring > Background Jobs**.
    1. On the Sidekiq dashboard, select **Queues**, and wait for all the `geo`
       queues to drop to 0 queued and 0 running jobs.
diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
index feb5e030b80..a96963cfea1 100644
--- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
+++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
@@ -6,18 +6,18 @@ type: howto
 ---
 
 WARNING:
-This runbook is an [Experiment](../../../../policy/alpha-beta-support.md#experiment). For complete, production-ready documentation, see the
+This runbook is an [Experiment](../../../../policy/experiment-beta-support.md#experiment). For complete, production-ready documentation, see the
 [disaster recovery documentation](../index.md).
 
 # Disaster Recovery (Geo) promotion runbooks **(PREMIUM SELF)**
 
 ## Geo planned failover for a multi-node configuration
 
-| Component   | Configuration   |
-|-------------|-----------------|
-| PostgreSQL  | Omnibus-managed |
-| Geo site    | Multi-node      |
-| Secondaries | One             |
+| Component   | Configuration                |
+|:------------|:-----------------------------|
+| PostgreSQL  | Managed by the Linux package |
+| Geo site    | Multi-node                   |
+| Secondaries | One                          |
 
 This runbook guides you through a planned failover of a multi-node Geo site
 with one secondary. The following [2000 user reference architecture](../../../../administration/reference_architectures/2k_users.md) is assumed:
@@ -68,7 +68,8 @@ GitLab 13.9 through GitLab 14.3 are affected by a bug in which the Geo secondary
 
 On the **secondary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Sites** to see its 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
@@ -95,52 +96,8 @@ ensure these processes are close to 100% as possible during active use.
 If the **secondary** site is still replicating data from the **primary** site,
 follow these steps to avoid unnecessary data loss:
 
-1. Until a [read-only mode](https://gitlab.com/gitlab-org/gitlab/-/issues/14609)
-   is implemented, updates must be prevented from happening manually to the
-   **primary**. Your **secondary** site still needs read-only
-   access to the **primary** site during the maintenance window:
-
-   1. At the scheduled time, using your cloud provider or your site's firewall, block
-      all HTTP, HTTPS and SSH traffic to/from the **primary** site, **except** for your IP and
-      the **secondary** site's IP.
-
-      For instance, you can run the following commands on the **primary** site:
-
-      ```shell
-      sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 22 -j ACCEPT
-      sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT
-      sudo iptables -A INPUT --destination-port 22 -j REJECT
-
-      sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 80 -j ACCEPT
-      sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 80 -j ACCEPT
-      sudo iptables -A INPUT --tcp-dport 80 -j REJECT
-
-      sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 443 -j ACCEPT
-      sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 443 -j ACCEPT
-      sudo iptables -A INPUT --tcp-dport 443 -j REJECT
-      ```
-
-      From this point, users are unable to view their data or make changes on the
-      **primary** site. They are also unable to sign in to the **secondary** site.
-      However, existing sessions must work for the remainder of the maintenance period, and
-      so public data is accessible throughout.
-
-   1. Verify the **primary** site is blocked to HTTP traffic by visiting it in browser via
-      another IP. The server should refuse connection.
-
-   1. Verify the **primary** site is blocked to Git over SSH traffic by attempting to pull an
-      existing Git repository with an SSH remote URL. The server should refuse
-      connection.
-
-   1. On the **primary** site:
-      1. On the top bar, select **Main menu > Admin**.
-      1. On the left sidebar, select **Monitoring > Background Jobs**.
-      1. On the Sidekiq dashboard, select **Cron**.
-      1. Select `Disable All` to disable any non-Geo periodic background jobs.
-      1. Select `Enable` for the `geo_sidekiq_cron_config_worker` cron job.
-         This job re-enables several other cron jobs that are essential for planned
-         failover to complete successfully.
-
+1. Enable [maintenance mode](../../../maintenance_mode/index.md) on the **primary** site,
+   and make sure to stop any [background jobs](../../../maintenance_mode/index.md#background-jobs).
 1. Finish replicating and verifying all data:
 
    WARNING:
@@ -151,7 +108,8 @@ follow these steps to avoid unnecessary data loss:
       [data not managed by Geo](../../replication/datatypes.md#limitations-on-replicationverification),
       trigger the final replication process now.
    1. On the **primary** site:
-      1. On the top bar, select **Main menu > Admin**.
+      1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+      1. Select **Admin Area**.
       1. On the left sidebar, select **Monitoring > Background Jobs**.
       1. On the Sidekiq dashboard, select **Queues**, and wait for all queues except
          those with `geo` in the name to drop to 0.
@@ -166,7 +124,8 @@ follow these steps to avoid unnecessary data loss:
          - The Geo log cursor is up to date (0 events behind).
 
    1. On the **secondary** site:
-      1. On the top bar, select **Main menu > Admin**.
+      1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+      1. Select **Admin Area**.
       1. On the left sidebar, select **Monitoring > Background Jobs**.
       1. On the Sidekiq dashboard, select **Queues**, and wait for all the `geo`
          queues to drop to 0 queued and 0 running jobs.
@@ -205,7 +164,7 @@ follow these steps to avoid unnecessary data loss:
 
      NOTE:
      (**CentOS only**) In CentOS 6 or older, it is challenging to prevent GitLab from being
-     started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
+     started if the machine reboots isn't available (see [issue 3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
      It may be safest to uninstall the GitLab package completely with `sudo yum remove gitlab-ee`.
 
      NOTE:
@@ -312,7 +271,7 @@ Data that was created on the primary while the secondary was paused is lost.
    roles ['geo_secondary_role']
    ```
 
-   After making these changes [Reconfigure GitLab](../../../restart_gitlab.md#omnibus-gitlab-reconfigure) each
+   After making these changes, [reconfigure GitLab](../../../restart_gitlab.md#reconfigure-a-linux-package-installation) each
    machine so the changes take effect.
 
 1. Promote the **secondary** to **primary**. SSH into a single Rails node
diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
index 19150027cca..7f94d6e4c1a 100644
--- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
+++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
@@ -6,18 +6,18 @@ type: howto
 ---
 
 WARNING:
-This runbook is an [Experiment](../../../../policy/alpha-beta-support.md#experiment). For complete, production-ready documentation, see the
+This runbook is an [Experiment](../../../../policy/experiment-beta-support.md#experiment). For complete, production-ready documentation, see the
 [disaster recovery documentation](../index.md).
 
 # Disaster Recovery (Geo) promotion runbooks **(PREMIUM SELF)**
 
 ## Geo planned failover for a single-node configuration
 
-| Component   | Configuration   |
-|-------------|-----------------|
-| PostgreSQL  | Omnibus-managed |
-| Geo site    | Single-node     |
-| Secondaries | One             |
+| Component   | Configuration                |
+|:------------|:-----------------------------|
+| PostgreSQL  | Managed by the Linux package |
+| Geo site    | Single-node                  |
+| Secondaries | One                          |
 
 This runbook guides you through a planned failover of a single-node Geo site
 with one secondary. The following general architecture is assumed:
@@ -118,7 +118,8 @@ follow these steps to avoid unnecessary data loss:
       connection.
 
    1. On the **primary** site:
-      1. On the top bar, select **Main menu > Admin**.
+      1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+      1. Select **Admin Area**.
       1. On the left sidebar, select **Monitoring > Background Jobs**.
       1. On the Sidekiq dashboard, select **Cron**.
       1. Select `Disable All` to disable any non-Geo periodic background jobs.
@@ -136,7 +137,8 @@ follow these steps to avoid unnecessary data loss:
       [data not managed by Geo](../../replication/datatypes.md#limitations-on-replicationverification),
       trigger the final replication process now.
    1. On the **primary** site:
-      1. On the top bar, select **Main menu > Admin**.
+      1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+      1. Select **Admin Area**.
       1. On the left sidebar, select **Monitoring > Background Jobs**.
       1. On the Sidekiq dashboard, select **Queues**, and wait for all queues except
          those with `geo` in the name to drop to 0.
@@ -151,7 +153,8 @@ follow these steps to avoid unnecessary data loss:
          - The Geo log cursor is up to date (0 events behind).
 
    1. On the **secondary** site:
-      1. On the top bar, select **Main menu > Admin**.
+      1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+      1. Select **Admin Area**.
       1. On the left sidebar, select **Monitoring > Background Jobs**.
       1. On the Sidekiq dashboard, select **Queues**, and wait for all the `geo`
          queues to drop to 0 queued and 0 running jobs.
@@ -190,7 +193,7 @@ follow these steps to avoid unnecessary data loss:
 
      NOTE:
      (**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
-     started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
+     started if the machine reboots isn't available (see [issue 3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
      It may be safest to uninstall the GitLab package completely with `sudo yum remove gitlab-ee`.
 
      NOTE:
diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index 31de7f5c62f..ae2cc262160 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -160,7 +160,9 @@ public URL of the primary site is used.
 
 To update the internal URL of the primary Geo site:
 
-1. On the top bar, select **Main menu > Admin > Geo > Sites**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Geo > Sites**.
 1. Select **Edit** on the primary site.
 1. Change the **Internal URL**, then select **Save changes**.
 
@@ -199,7 +201,8 @@ This list of limitations only reflects the latest version of GitLab. If you are
 - [Pages access control](../../user/project/pages/pages_access_control.md) doesn't work on secondaries. See [GitLab issue #9336](https://gitlab.com/gitlab-org/gitlab/-/issues/9336) for details.
 - [GitLab chart with Geo](https://docs.gitlab.com/charts/advanced/geo/) does not support [Unified URLs](secondary_proxy/index.md#set-up-a-unified-url-for-geo-sites). See [GitLab issue #3522](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3522) for more details.
 - [Disaster recovery](disaster_recovery/index.md) for multi-secondary sites causes downtime due to the complete re-synchronization and re-configuration of all non-promoted secondaries.
-- For Git over SSH, secondary sites must use the same port as the primary. [GitLab issue #339262](https://gitlab.com/gitlab-org/gitlab/-/issues/339262) proposes to remove this limitation.
+- For Git over SSH, to make the project clone URL display correctly regardless of which site you are browsing, secondary sites must use the same port as the primary. [GitLab issue #339262](https://gitlab.com/gitlab-org/gitlab/-/issues/339262) proposes to remove this limitation.
+- Git push over SSH against a secondary site does not work for pushes over 1.86 GB. [GitLab issue #413109](https://gitlab.com/gitlab-org/gitlab/-/issues/413109) tracks this bug.
 
 ### Limitations on replication/verification
 
@@ -209,14 +212,11 @@ There is a complete list of all GitLab [data types](replication/datatypes.md) an
 
 If you try to view replication data on the primary site, you receive a warning that this may be inconsistent:
 
-> Viewing projects and designs data from a primary site is not possible when using a unified URL. Visit the secondary site directly.
+> Viewing projects data from a primary site is not possible when using a unified URL. Visit the secondary site directly.
 
 The only way to view projects replication data for a particular secondary site is to visit that secondary site directly. For example, `https://<IP of your secondary site>/admin/geo/replication/projects`.
 An [epic exists](https://gitlab.com/groups/gitlab-org/-/epics/4623) to fix this limitation.
 
-The only way to view designs replication data for a particular secondary site is to visit that secondary site directly. For example, `https://<IP of your secondary site>/admin/geo/replication/designs`.
-An [epic exists](https://gitlab.com/groups/gitlab-org/-/epics/4624) to fix this limitation.
-
 Keep in mind that mentioned URLs don't work when [Admin Mode](../../user/admin_area/settings/sign_in_restrictions.md#admin-mode) is enabled.
 
 When using Unified URL, visiting the secondary site directly means you must route your requests to the secondary site. Exactly how this might be done depends on your networking configuration. If using DNS to route requests to the appropriate site, then you can, for example, edit your local machine's `/etc/hosts` file to route your requests to the desired secondary site. If the Geo sites are all behind a load balancer, then depending on the load balancer, you might be able to configure all requests from your IP to go to a particular secondary site.
@@ -248,10 +248,11 @@ secondary. If the site is paused, be sure to resume before promoting. This
 issue has been fixed in GitLab 13.4 and later.
 
 WARNING:
-Pausing and resuming of replication is only supported for Geo installations using an
-Omnibus GitLab-managed database. External databases are not supported.
+Pausing and resuming of replication is only supported for Geo installations using a
+Linux package-managed database. External databases are not supported.
 
-In some circumstances, like during [upgrades](replication/upgrading_the_geo_sites.md) or a [planned failover](disaster_recovery/planned_failover.md), it is desirable to pause replication between the primary and secondary.
+In some circumstances, like during [upgrades](replication/upgrading_the_geo_sites.md) or a
+[planned failover](disaster_recovery/planned_failover.md), it is desirable to pause replication between the primary and secondary.
 
 Pausing and resuming replication is done via a command line tool from the node in the secondary site where the `postgresql` service is enabled.
 
@@ -275,7 +276,7 @@ For information on configuring Geo for multiple nodes, see [Geo for multiple ser
 
 ### Configuring Geo with Object Storage
 
-For information on configuring Geo with object storage, see [Geo with Object storage](replication/object_storage.md).
+For information on configuring Geo with Object storage, see [Geo with Object storage](replication/object_storage.md).
 
 ### Disaster Recovery
 
@@ -333,7 +334,7 @@ For answers to common questions, see the [Geo FAQ](replication/faq.md).
 
 ## Log files
 
-Geo stores structured log messages in a `geo.log` file. For Omnibus GitLab
+Geo stores structured log messages in a `geo.log` file. For Linux package
 installations, this file is at `/var/log/gitlab/gitlab-rails/geo.log`.
 
 This file contains information about when Geo attempts to sync repositories and files. Each line in the file contains a separate JSON entry that can be ingested into. For example, Elasticsearch or Splunk.
diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index 5fa6df393b9..18d0440965e 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -12,7 +12,7 @@ type: howto
 NOTE:
 This is the final step in setting up a **secondary** Geo site. Stages of the
 setup process must be completed in the documented order.
-If not, [complete all prior stages](../setup/index.md#using-omnibus-gitlab) before proceeding.
+If not, [complete all prior stages](../setup/index.md#using-linux-package-installations) before proceeding.
 
 Make sure you [set up the database replication](../setup/database.md), and [configured fast lookup of authorized SSH keys](../../operations/fast_ssh_key_lookup.md) in **both primary and secondary sites**.
 
@@ -202,7 +202,8 @@ keys must be manually replicated to the **secondary** site.
    ```
 
 1. Navigate to the Primary Node GitLab Instance:
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
    1. On the left sidebar, select **Geo > Sites**.
    1. Select **Add site**.
    ![Add secondary site](img/adding_a_secondary_v15_8.png)
@@ -311,12 +312,13 @@ method to be enabled. This is enabled by default, but if converting an existing
 
 On the **primary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Visibility and access controls**.
 1. If using Git over SSH, then:
    1. Ensure "Enabled Git access protocols" is set to "Both SSH and HTTP(S)".
-   1. Follow [Fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md) on both primary and secondary sites.
+   1. Follow [Fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md) on **all primary and secondary** sites.
 1. If not using Git over SSH, then set "Enabled Git access protocols" to "Only HTTP(S)".
 
 ### Step 6. Verify proper functioning of the **secondary** site
@@ -324,7 +326,8 @@ On the **primary** site:
 You can sign in to the **secondary** site with the same credentials you used with
 the **primary** site. After you sign in:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Sites**.
 1. Verify that it's correctly identified as a **secondary** Geo site, and that
    Geo is enabled.
diff --git a/doc/administration/geo/replication/container_registry.md b/doc/administration/geo/replication/container_registry.md
index 66c67f29c1c..6dde611a20d 100644
--- a/doc/administration/geo/replication/container_registry.md
+++ b/doc/administration/geo/replication/container_registry.md
@@ -73,12 +73,11 @@ To configure Container Registry replication:
 Make sure that you have Container Registry set up and working on
 the **primary** site before following the next steps.
 
-We need to make Container Registry send notification events to the
-**primary** site.
+To be able to replicate new container images, the Container Registry must send notification events to the
+**primary** site for every push. The token shared between the Container Registry and the web nodes on the
+**primary** is used to make communication more secure.
 
-For each application and Sidekiq node on the **primary** site:
-
-1. SSH into the node and login as the `root` user:
+1. SSH into your GitLab **primary** server and login as root (for GitLab HA, you only need a Registry node):
 
    ```shell
    sudo -i
@@ -107,15 +106,17 @@ For each application and Sidekiq node on the **primary** site:
    that starts with a letter. You can generate one with `< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32 | sed "s/^[0-9]*//"; echo`
 
    NOTE:
-   If you use an external Registry (not the one integrated with GitLab), you also have to specify
+   If you use an external Registry (not the one integrated with GitLab), you only need to specify
    the notification secret (`registry['notification_secret']`) in the
    `/etc/gitlab/gitlab.rb` file.
 
-   NOTE:
-   If you use GitLab HA, you also have to specify the notification secret (`registry['notification_secret']`) in
-   `/etc/gitlab/gitlab.rb` file for every web node.
+1. For GitLab HA only. Edit `/etc/gitlab/gitlab.rb` on every web node:
+
+   ```ruby
+   registry['notification_secret'] = '<replace_with_a_secret_token_generated_above>'
+   ```
 
-1. Reconfigure each node:
+1. Reconfigure each node you just updated:
 
    ```shell
    gitlab-ctl reconfigure
@@ -165,7 +166,8 @@ For each application and Sidekiq node on the **secondary** site:
 
 To verify Container Registry replication is working, on the **secondary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Nodes**.
    The initial replication, or "backfill", is probably still in progress.
 
diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md
index d6ce5ef5067..f038bfd705c 100644
--- a/doc/administration/geo/replication/datatypes.md
+++ b/doc/administration/geo/replication/datatypes.md
@@ -203,7 +203,7 @@ successfully, you must replicate their data using some other means.
 |[CI Secure Files](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/ci/secure_file.rb) | [**Yes** (15.3)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91430) | [**Yes** (15.3)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91430) | [**Yes** (15.3)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91430) | [No](object_storage.md#verification-of-files-in-object-storage) | Verification is behind the feature flag `geo_ci_secure_file_replication`, enabled by default in 15.3. |
 |[Container Registry](../../packages/container_registry.md)                                                     | **Yes** (12.3)<sup>1</sup>                                                         | **Yes** (15.10)                                                                         | **Yes** (12.3)<sup>1</sup>                                                             | **Yes** (15.10)                                                              | See [instructions](container_registry.md) to set up the Container Registry replication. |
 |[Terraform Module Registry](../../../user/packages/terraform_module_registry/index.md)                           | **Yes** (14.0)                                                          | **Yes** (14.0)                                                             | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [No](object_storage.md#verification-of-files-in-object-storage) | Behind feature flag `geo_package_file_replication`, enabled by default. |
-|[Project designs repository](../../../user/project/issues/design_management.md)                                | **Yes** (12.7)                                                          | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/32467)                  | N/A                                                                 | N/A                                                             | Designs also require replication of LFS objects and Uploads. |
+|[Project designs repository](../../../user/project/issues/design_management.md)                                | **Yes** (12.7)                                                          | **Yes** (16.1)                  | N/A                                                                 | N/A                                                             | Designs also require replication of LFS objects and Uploads. Replication is behind the feature flag geo_design_management_repository_replication, enabled by default.|
 |[Package Registry](../../../user/packages/package_registry/index.md)                                           | **Yes** (13.2)                                                          | **Yes** (13.10)                                                            | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [No](object_storage.md#verification-of-files-in-object-storage) | Behind feature flag `geo_package_file_replication`, enabled by default. |
 |[Versioned Terraform State](../../terraform_state.md)                                                          | **Yes** (13.5)                                                          | **Yes** (13.12)                                                            | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [No](object_storage.md#verification-of-files-in-object-storage) | Replication is behind the feature flag `geo_terraform_state_version_replication`, enabled by default. Verification was behind the feature flag `geo_terraform_state_version_verification`, which was removed in 14.0. |
 |[External merge request diffs](../../merge_request_diffs.md)                                                   | **Yes** (13.5)                                                          | **Yes** (14.6)                                                             | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [No](object_storage.md#verification-of-files-in-object-storage) | Replication is behind the feature flag `geo_merge_request_diff_replication`, enabled by default. Verification was behind the feature flag `geo_merge_request_diff_verification`, removed in 14.7.|
diff --git a/doc/administration/geo/replication/disable_geo.md b/doc/administration/geo/replication/disable_geo.md
index c42130a62a7..bedcca7e311 100644
--- a/doc/administration/geo/replication/disable_geo.md
+++ b/doc/administration/geo/replication/disable_geo.md
@@ -7,7 +7,7 @@ type: howto
 
 # Disabling Geo **(PREMIUM SELF)**
 
-If you want to revert to a regular Omnibus setup after a test, or you have encountered a Disaster Recovery
+If you want to revert to a regular Linux package installation setup after a test, or you have encountered a Disaster Recovery
 situation and you want to disable Geo momentarily, you can use these instructions to disable your
 Geo setup.
 
@@ -36,7 +36,8 @@ to do that.
 To remove the **primary** site:
 
 1. [Remove all secondary Geo sites](remove_geo_site.md)
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Nodes**.
 1. Select **Remove** for the **primary** node.
 1. Confirm by selecting **Remove** when the prompt appears.
@@ -80,7 +81,7 @@ Geo node in a PostgreSQL console (`sudo gitlab-psql`):
    roles ['geo_primary_role']
    ```
 
-1. After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. After making these changes, [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 ## (Optional) Revert PostgreSQL settings to use a password and listen on an IP
diff --git a/doc/administration/geo/replication/geo_validation_tests.md b/doc/administration/geo/replication/geo_validation_tests.md
index cad3a396bfc..7897635e78f 100644
--- a/doc/administration/geo/replication/geo_validation_tests.md
+++ b/doc/administration/geo/replication/geo_validation_tests.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 The Geo team performs manual testing and validation on common deployment configurations to ensure
 that Geo works when upgrading between minor GitLab versions and major PostgreSQL database versions.
 
-This section contains a journal of recent validation tests and links to the relevant issues.
+This section contains a journal of validation tests and links to the relevant issues.
 
 ## GitLab upgrades
 
@@ -143,7 +143,7 @@ The following are PostgreSQL upgrade validation tests we performed.
   we tested fresh installations of GitLab 13.3 with PostgreSQL 12 enabled and Geo installed.
 - Outcome: Setting up a Geo secondary required manual intervention because the `recovery.conf` file
   is no longer supported in PostgreSQL 12. We do not recommend deploying Geo with PostgreSQL 12 until
-  the appropriate changes have been made to Omnibus and verified.
+  the appropriate changes have been made to the Linux package and verified.
 - Follow up issues:
   - [Update `replicate-geo-database` to support PostgreSQL 12](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5575)
   - [Remove PostgreSQL 12 check in `replicate-geo-database` for 14.0](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5576)
@@ -184,14 +184,17 @@ The following are PostgreSQL upgrade validation tests we performed.
 
 The following are additional validation tests we performed.
 
-### May 2021
+### April 2022
 
-[Test failover with object storage replication enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/330362):
+[Validate Object storage replication using AWS based object storage](https://gitlab.com/gitlab-org/gitlab/-/issues/351463):
 
-- Description: At the time of testing, Geo's object storage replication functionality was in beta. We tested that object storage replication works as intended and that the data was present on the new primary after a failover.
-- Outcome: The test was successful. Data in object storage was replicated and present after a failover.
-- Follow up issues:
-  - [Geo: Failing to replicate initial Monitoring project](https://gitlab.com/gitlab-org/gitlab/-/issues/330485)
+- Description: Tested the average time it takes for a single image to replicate from the primary object storage location to the secondary when using AWS based object storage replication and [GitLab based object storage replication](object_storage.md#enabling-gitlab-managed-object-storage-replication). This was tested by uploading a 1 MB image to a project on the primary site every second for 60 seconds. The time was then measured until a image was available on the secondary site. This was achieved using a [Ruby Script](https://gitlab.com/gitlab-org/quality/geo-replication-tester).
+- Outcome: When using AWS managed replication the average time for an image to replicate between sites is about 49 seconds, this is true for when sites are located in the same region and when they are further apart (Europe to America). When using Geo managed replication in the same region the average time for replication took just 5 seconds, however when replicating cross region the average time rose to 33 seconds.
+
+[Validate Object storage replication using GCP based object storage](https://gitlab.com/gitlab-org/gitlab/-/issues/351464):
+
+- Description: Tested the average time it takes for a single image to replicate from the primary object storage location to the secondary when using GCP based object storage replication and [GitLab based object storage replication](object_storage.md#enabling-gitlab-managed-object-storage-replication). This was tested by uploading a 1 MB image to a project on the primary site every second for 60 seconds. The time was then measured until a image was available on the secondary site. This was achieved using a [Ruby Script](https://gitlab.com/gitlab-org/quality/geo-replication-tester).
+- Outcome: GCP handles replication differently than other Cloud Providers. In GCP, the process is to a create single bucket that is either multi, dual, or single region based. This means that the bucket automatically stores replicas in a region based on the option chosen. Even when using multi region, this only replicates in a single continent, the options being America, Europe, or Asia. At current there doesn't seem to be any way to replicate objects between continents using GCP based replication. For Geo managed replication the average time when replicating in the same region was 6 seconds, and when replicating cross region this rose to just 9 seconds.
 
 ### January 2022
 
@@ -202,17 +205,14 @@ The following are additional validation tests we performed.
 - Follow up issue:
   - [Validate Cross Region Object storage replication using Azure based object storage](https://gitlab.com/gitlab-org/gitlab/-/issues/358154)
 
-### April 2022
-
-[Validate Object storage replication using AWS based object storage](https://gitlab.com/gitlab-org/gitlab/-/issues/351463):
-
-- Description: Tested the average time it takes for a single image to replicate from the primary object storage location to the secondary when using AWS based object storage replication and [GitLab based object storage replication](object_storage.md#enabling-gitlab-managed-object-storage-replication). This was tested by uploading a 1 MB image to a project on the primary site every second for 60 seconds. The time was then measured until a image was available on the secondary site. This was achieved using a [Ruby Script](https://gitlab.com/gitlab-org/quality/geo-replication-tester).
-- Outcome: When using AWS managed replication the average time for an image to replicate between sites is about 49 seconds, this is true for when sites are located in the same region and when they are further apart (Europe to America). When using Geo managed replication in the same region the average time for replication took just 5 seconds, however when replicating cross region the average time rose to 33 seconds.
+### May 2021
 
-[Validate Object storage replication using GCP based object storage](https://gitlab.com/gitlab-org/gitlab/-/issues/351464):
+[Test failover with object storage replication enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/330362):
 
-- Description: Tested the average time it takes for a single image to replicate from the primary object storage location to the secondary when using GCP based object storage replication and [GitLab based object storage replication](object_storage.md#enabling-gitlab-managed-object-storage-replication). This was tested by uploading a 1 MB image to a project on the primary site every second for 60 seconds. The time was then measured until a image was available on the secondary site. This was achieved using a [Ruby Script](https://gitlab.com/gitlab-org/quality/geo-replication-tester).
-- Outcome: GCP handles replication differently than other Cloud Providers. In GCP, the process is to a create single bucket that is either multi, dual, or single region based. This means that the bucket automatically stores replicas in a region based on the option chosen. Even when using multi region, this only replicates in a single continent, the options being America, Europe, or Asia. At current there doesn't seem to be any way to replicate objects between continents using GCP based replication. For Geo managed replication the average time when replicating in the same region was 6 seconds, and when replicating cross region this rose to just 9 seconds.
+- Description: At the time of testing, Geo's object storage replication functionality was in beta. We tested that object storage replication works as intended and that the data was present on the new primary after a failover.
+- Outcome: The test was successful. Data in object storage was replicated and present after a failover.
+- Follow up issues:
+  - [Geo: Failing to replicate initial Monitoring project](https://gitlab.com/gitlab-org/gitlab/-/issues/330485)
 
 ## Other tests
 
diff --git a/doc/administration/geo/replication/multiple_servers.md b/doc/administration/geo/replication/multiple_servers.md
index 155fefb2dbf..4e597a21922 100644
--- a/doc/administration/geo/replication/multiple_servers.md
+++ b/doc/administration/geo/replication/multiple_servers.md
@@ -35,7 +35,7 @@ The **primary** and **secondary** Geo sites must be able to communicate to each
 Because of the additional complexity involved in setting up this configuration
 for PostgreSQL and Redis, it is not covered by this Geo multi-node documentation.
 
-For more information on setting up a multi-node PostgreSQL cluster and Redis cluster using the Omnibus GitLab package, see:
+For more information on setting up a multi-node PostgreSQL cluster and Redis cluster using the Linux package, see:
 
 - [Geo multi-node database replication](../setup/database.md#multi-node-database-replication)
 - [Redis multi-node documentation](../../redis/replication_and_failover.md)
@@ -77,7 +77,15 @@ The following steps enable a GitLab site to serve as the Geo **primary** site.
    gitlab_rails['auto_migrate'] = false
    ```
 
-After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect.
+After making these changes, [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) so the changes take effect.
+
+### Step 2: Define the site as the **primary** site
+
+1. Execute the following command on one of the frontend nodes:
+
+   ```shell
+   sudo gitlab-ctl set-geo-primary-node
+   ```
 
 NOTE:
 PostgreSQL and Redis should have already been disabled on the
@@ -171,7 +179,7 @@ the instructions below.
    gitlab_rails['auto_migrate'] = false
    ```
 
-After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect.
+After making these changes, [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) so the changes take effect.
 
 If using an external PostgreSQL instance, refer also to
 [Geo with external PostgreSQL instances](../setup/external_database.md).
@@ -252,7 +260,7 @@ then make the following modifications:
    ```
 
 NOTE:
-If you had set up PostgreSQL cluster using the omnibus package and had set
+If you had set up PostgreSQL cluster using the Linux package and had set
 `postgresql['sql_user_password'] = 'md5 digest of secret'`, keep in
 mind that `gitlab_rails['db_password']` and `geo_secondary['db_password']`
 contains the plaintext passwords. This is used to let the Rails
@@ -263,7 +271,7 @@ Make sure that current node's IP is listed in
 `postgresql['md5_auth_cidr_addresses']` setting of the read-replica database to
 allow Rails on this node to connect to PostgreSQL.
 
-After making these changes [Reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect.
+After making these changes, [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) so the changes take effect.
 
 In the [architecture overview](#architecture-overview) topology, the following GitLab
 services are enabled on the "frontend" nodes:
diff --git a/doc/administration/geo/replication/object_storage.md b/doc/administration/geo/replication/object_storage.md
index 8128eaf5310..86db8186a13 100644
--- a/doc/administration/geo/replication/object_storage.md
+++ b/doc/administration/geo/replication/object_storage.md
@@ -9,7 +9,7 @@ type: howto
 
 Geo can be used in combination with Object Storage (AWS S3, or other compatible object storage).
 
-Currently, **secondary** sites can use either:
+**Secondary** sites can use one of the following:
 
 - The same storage bucket as the **primary** site.
 - A replicated storage bucket.
@@ -41,7 +41,8 @@ whether they are stored on the local file system or in object storage.
 
 To enable GitLab replication:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Nodes**.
 1. Select **Edit** on the **secondary** site.
 1. In the **Synchronization Settings** section, find the **Allow this secondary node to replicate content on Object Storage**
diff --git a/doc/administration/geo/replication/remove_geo_site.md b/doc/administration/geo/replication/remove_geo_site.md
index 9d92652daf4..de0ad3fe2fb 100644
--- a/doc/administration/geo/replication/remove_geo_site.md
+++ b/doc/administration/geo/replication/remove_geo_site.md
@@ -9,7 +9,8 @@ type: howto
 
 **Secondary** sites can be removed from the Geo cluster using the Geo administration page of the **primary** site. To remove a **secondary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Nodes**.
 1. For the **secondary** site you want to remove, select **Remove**.
 1. Confirm by selecting **Remove** when the prompt appears.
diff --git a/doc/administration/geo/replication/security_review.md b/doc/administration/geo/replication/security_review.md
index 92eff2faf60..e099c2b2e9d 100644
--- a/doc/administration/geo/replication/security_review.md
+++ b/doc/administration/geo/replication/security_review.md
@@ -127,9 +127,9 @@ from [owasp.org](https://owasp.org/).
 
 ### What details regarding required OS components and lock‐down needs have been defined?
 
-- The supported installation method (Omnibus) packages most components itself.
+- The supported Linux package installation method packages most components itself.
 - There are significant dependencies on the system-installed OpenSSH daemon (Geo
-  requires users to set up custom authentication methods) and the omnibus or
+  requires users to set up custom authentication methods) and the Linux package-provided or
   system-provided PostgreSQL daemon (it must be configured to listen on TCP,
   additional users and replication slots must be added, etc).
 - The process for dealing with security updates (for example, if there is a
@@ -237,7 +237,7 @@ from [owasp.org](https://owasp.org/).
 - In transit, data should be encrypted, although the application does permit
   communication to proceed unencrypted. The two main transits are the **secondary** site's
   replication process for PostgreSQL, and for Git repositories/files. Both should
-  be protected using TLS, with the keys for that managed via Omnibus per existing
+  be protected using TLS, with the keys for that managed by the Linux package per existing
   configuration for end-user access to GitLab.
 
 ### What capabilities exist to detect the leakage of sensitive data?
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index a8736b3ed1d..4047167e4af 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -27,7 +27,8 @@ Before attempting more advanced troubleshooting:
 
 On the **primary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Sites**.
 
 We perform the following health checks on each **secondary** site
@@ -104,9 +105,7 @@ Checking Geo ... Finished
 You can also specify a custom NTP server using environment variables. For example:
 
 ```shell
-export NTP_HOST="ntp.ubuntu.com"
-export NTP_TIMEOUT="30"
-sudo gitlab-rake gitlab:geo:check
+sudo gitlab-rake gitlab:geo:check NTP_HOST="ntp.ubuntu.com" NTP_TIMEOUT="30"
 ```
 
 The following environment variables are supported.
@@ -120,7 +119,9 @@ The following environment variables are supported.
 #### Sync status Rake task
 
 Current sync information can be found manually by running this Rake task on any
-node running Rails (Puma, Sidekiq, or Geo Log Cursor) on the Geo **secondary** site:
+node running Rails (Puma, Sidekiq, or Geo Log Cursor) on the Geo **secondary** site.
+
+GitLab does **not** verify objects that are stored in Object Storage. If you are using Object Storage, you will see all of the "verified" checks showing 0 successes. This is expected and not a cause for concern.
 
 ```shell
 sudo gitlab-rake geo:status
@@ -208,8 +209,8 @@ Geo finds the current Puma or Sidekiq node's Geo [site](../glossary.md) name in
 
 1. Get the "Geo node name" (there is
    [an issue to rename the settings to "Geo site name"](https://gitlab.com/gitlab-org/gitlab/-/issues/335944)):
-   - Omnibus GitLab: Get the `gitlab_rails['geo_node_name']` setting.
-   - GitLab Helm Charts: Get the `global.geo.nodeName` setting (see [Charts with GitLab Geo](https://docs.gitlab.com/charts/advanced/geo/index.html)).
+   - Linux package: get the `gitlab_rails['geo_node_name']` setting.
+   - GitLab Helm charts: get the `global.geo.nodeName` setting (see [Charts with GitLab Geo](https://docs.gitlab.com/charts/advanced/geo/index.html)).
 1. If that is not defined, then get the `external_url` setting.
 
 This name is used to look up the Geo site with the same **Name** in the **Geo Sites**
@@ -598,7 +599,7 @@ To help us resolve this problem, consider commenting on
 
 ### Message: `FATAL:  could not connect to the primary server: server certificate for "PostgreSQL" does not match host name`
 
-This happens because the PostgreSQL certificate that the Omnibus GitLab package automatically creates contains
+This happens because the PostgreSQL certificate that the Linux package automatically creates contains
 the Common Name `PostgreSQL`, but the replication is connecting to a different host and GitLab attempts to use
 the `verify-full` SSL mode by default.
 
@@ -852,8 +853,11 @@ to start again from scratch, there are a few steps that can help you:
 
 ### Design repository failures on mirrored projects and project imports
 
-On the top bar, under **Main menu > Admin > Geo > Sites**,
-if the Design repositories progress bar shows
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Geo > Sites**.
+
+If the Design repositories progress bar shows
 `Synced` and `Failed` greater than 100%, and negative `Queued`, the instance
 is likely affected by
 [a bug in GitLab 13.2 and 13.3](https://gitlab.com/gitlab-org/gitlab/-/issues/241668).
@@ -1156,7 +1160,7 @@ get_ctl_options': invalid option: --force (OptionParser::InvalidOption)
 ```
 
 This can happen with XFS or file systems that list files in lexical order, because the
-load order of the Omnibus GitLab command files can be different than expected, and a global function would get redefined.
+load order of the Linux package command files can be different than expected, and a global function would get redefined.
 More details can be found in [the related issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6076).
 
 The workaround is to manually run the preflight checks and promote the database, by running
@@ -1188,7 +1192,8 @@ site's URL matches its external URL.
 
 On the **primary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Sites**.
 1. Find the affected **secondary** site and select **Edit**.
 1. Ensure the **URL** field matches the value found in `/etc/gitlab/gitlab.rb`
@@ -1206,7 +1211,7 @@ This section documents common error messages reported in the Admin Area on the w
 
 GitLab cannot find or doesn't have permission to access the `database_geo.yml` configuration file.
 
-In an Omnibus GitLab installation, the file should be in `/var/opt/gitlab/gitlab-rails/etc`.
+In a Linux package installation, the file should be in `/var/opt/gitlab/gitlab-rails/etc`.
 If it doesn't exist or inadvertent changes have been made to it, run `sudo gitlab-ctl reconfigure` to restore it to its correct state.
 
 If this path is mounted on a remote volume, ensure your volume configuration
@@ -1239,7 +1244,7 @@ This error message indicates that the replica database in the **secondary** site
 To restore the database and resume replication, you can do one of the following:
 
 - [Reset the Geo secondary site replication](#resetting-geo-secondary-site-replication).
-- [Set up a new secondary Geo Omnibus instance](../setup/index.md#using-omnibus-gitlab).
+- [Set up a new Geo secondary using the Linux package](../setup/index.md#using-linux-package-installations).
 
 If you set up a new secondary from scratch, you must also [remove the old site from the Geo cluster](remove_geo_site.md#removing-secondary-geo-sites).
 
@@ -1258,7 +1263,7 @@ Make sure you follow the [Geo database replication](../setup/database.md) instru
 
 ### Geo database version (...) does not match latest migration (...)
 
-If you are using Omnibus GitLab installation, something might have failed during upgrade. You can:
+If you are using the Linux package installation, something might have failed during upgrade. You can:
 
 - Run `sudo gitlab-ctl reconfigure`.
 - Manually trigger the database migration by running: `sudo gitlab-rake db:migrate:geo` as root on the **secondary** site.
@@ -1359,7 +1364,9 @@ If you have installed GitLab using the Linux package (Omnibus) and have configur
 - `15.6.0`-`15.6.3`
 - `15.7.0`-`15.7.1`
 
-This is due to [a bug introduced in the included version of cURL](https://github.com/curl/curl/issues/10122) shipped with Omnibus GitLab 15.4.6 and later. You are encouraged to upgrade to a later version where this has been [fixed](https://about.gitlab.com/releases/2023/01/09/security-release-gitlab-15-7-2-released/).
+This is due to [a bug introduced in the included version of cURL](https://github.com/curl/curl/issues/10122) shipped with
+the Linux package 15.4.6 and later. You should upgrade to a later version where this has been
+[fixed](https://about.gitlab.com/releases/2023/01/09/security-release-gitlab-15-7-2-released/).
 
 The bug causes all wildcard domains (`.example.com`) to be ignored except for the last on in the `no_proxy` environment variable list. Therefore, if for any reason you cannot upgrade to a newer version, you can work around the issue by moving your wildcard domain to the end of the list:
 
@@ -1392,8 +1399,9 @@ If you have updated the value of `external_url` in `/etc/gitlab/gitlab.rb` for t
 
 In this case, make sure to update the changed URL on all your sites:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Admin > Geo > Sites**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Geo > Sites**.
 1. Change the URL and save the change.
 
 ## Fixing non-PostgreSQL replication failures
@@ -1474,7 +1482,31 @@ Geo::PackageFileRegistry.where(last_sync_failure: 'The file is missing on the Ge
 This iterates over all package files on the secondary, looking at the
 `verification_checksum` stored in the database (which came from the primary)
 and then calculate this value on the secondary to check if they match. This
-does not change anything in the UI:
+does not change anything in the UI.
+
+For GitLab 14.4 and later:
+
+```ruby
+# Run on secondary
+status = {}
+
+Packages::PackageFile.find_each do |package_file|
+  primary_checksum = package_file.verification_checksum
+  secondary_checksum = Packages::PackageFile.sha256_hexdigest(package_file.file.path)
+  verification_status = (primary_checksum == secondary_checksum)
+
+  status[verification_status.to_s] ||= []
+  status[verification_status.to_s] << package_file.id
+end
+
+# Count how many of each value we get
+status.keys.each {|key| puts "#{key} count: #{status[key].count}"}
+
+# See the output in its entirety
+status
+```
+
+For GitLab 14.3 and earlier:
 
 ```ruby
 # Run on secondary
@@ -1557,7 +1589,7 @@ registry.replicator.send(:sync_repository)
 #### Find repository verification failures
 
 [Start a Rails console session](../../../administration/operations/rails_console.md#starting-a-rails-console-session)
-to gather the following, basic troubleshooting information.
+**on the secondary Geo site** to gather more information.
 
 WARNING:
 Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
@@ -1583,14 +1615,14 @@ Geo::ProjectRegistry.sync_failed('repository')
 #### Resync project and project wiki repositories
 
 [Start a Rails console session](../../../administration/operations/rails_console.md#starting-a-rails-console-session)
-to enact the following, basic troubleshooting steps.
+**on the secondary Geo site** to perform the following changes.
 
 WARNING:
 Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
 
 ##### Queue up all repositories for resync
 
-When you run this, Sidekiq handles each sync.
+When you run this, the sync is handled in the background by Sidekiq.
 
 ```ruby
 Geo::ProjectRegistry.update_all(resync_repository: true, resync_wiki: true)
@@ -1604,6 +1636,27 @@ project = Project.find_by_full_path('<group/project>')
 Geo::RepositorySyncService.new(project).execute
 ```
 
+##### Sync all failed repositories now
+
+The following script:
+
+- Loops over all currently failed repositories.
+- Displays the project details and the reasons for the last failure.
+- Attempts to resync the repository.
+- Reports back if a failure occurs, and why.
+
+```ruby
+Geo::ProjectRegistry.sync_failed('repository').find_each do |p|
+   begin
+     project = p.project
+     puts "#{project.full_path} | id: #{p.project_id} | last error: '#{p.last_repository_sync_failure}'"
+     Geo::RepositorySyncService.new(project).execute
+   rescue => e
+     puts "ID: #{p.project_id} failed: '#{e}'", e.backtrace.join("\n")
+   end
+end ; nil
+```
+
 #### Find repository check failures in a Geo secondary site
 
 When [enabled for all projects](../../repository_checks.md#enable-repository-checks-for-all-projects), [Repository checks](../../repository_checks.md) are also performed on Geo secondary sites. The metadata is stored in the Geo tracking database.
@@ -1721,7 +1774,7 @@ If the above steps are **not successful**, proceed through the next steps:
 
 If different operating systems or different operating system versions are deployed across Geo sites, you should perform a locale data compatibility check before setting up Geo.
 
-Geo uses PostgreSQL and Streaming Replication to replicate data across Geo sites. PostgreSQL uses locale data provided by the operating system's C library for sorting text. If the locale data in the C library is incompatible across Geo sites, erroneous query results that lead to [incorrect behavior on secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/360723).
+Geo uses PostgreSQL and Streaming Replication to replicate data across Geo sites. PostgreSQL uses locale data provided by the operating system's C library for sorting text. If the locale data in the C library is incompatible across Geo sites, it can cause erroneous query results that lead to [incorrect behavior on secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/360723).
 
 For example, Ubuntu 18.04 (and earlier) and RHEL/Centos7 (and earlier) are incompatible with their later releases.
 See the [PostgreSQL wiki for more details](https://wiki.postgresql.org/wiki/Locale_data_changes).
diff --git a/doc/administration/geo/replication/tuning.md b/doc/administration/geo/replication/tuning.md
index 4dc3ba93d66..9e1638643cb 100644
--- a/doc/administration/geo/replication/tuning.md
+++ b/doc/administration/geo/replication/tuning.md
@@ -14,7 +14,8 @@ in the background.
 
 On the **primary** site:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Geo > Sites**.
 1. Select **Edit** of the secondary site you want to tune.
 1. Under **Tuning settings**, there are several variables that can be tuned to
diff --git a/doc/administration/geo/replication/version_specific_upgrades.md b/doc/administration/geo/replication/version_specific_upgrades.md
index f8e013a8776..c0215c4551c 100644
--- a/doc/administration/geo/replication/version_specific_upgrades.md
+++ b/doc/administration/geo/replication/version_specific_upgrades.md
@@ -253,16 +253,16 @@ upgrade to GitLab 13.4 or later.
 ## Upgrading to GitLab 13.0
 
 Upgrading to GitLab 13.0 requires GitLab 12.10 to already be using PostgreSQL
-version 11. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+version 11. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 ## Upgrading to GitLab 12.10
 
 GitLab 12.10 doesn't attempt to upgrade the embedded PostgreSQL server when
 using Geo, because the PostgreSQL upgrade requires downtime for secondaries
 while reinitializing streaming replication. It must be upgraded manually. For
-the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 ## Upgrading to GitLab 12.9
 
@@ -273,8 +273,8 @@ The issue is fixed in GitLab 12.9.4. Upgrade to GitLab 12.9.4 or later.
 
 By default, GitLab 12.9 attempts to upgrade the embedded PostgreSQL server
 version from 9.6 to 10.12, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 You can temporarily disable this behavior by running the following before
 upgrading:
@@ -287,8 +287,8 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
 
 By default, GitLab 12.8 attempts to upgrade the embedded PostgreSQL server
 version from 9.6 to 10.12, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 You can temporarily disable this behavior by running the following before
 upgrading:
@@ -307,8 +307,8 @@ shipped in 12.7.5.
 
 By default, GitLab 12.7 attempts to upgrade the embedded PostgreSQL server
 version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 You can temporarily disable this behavior by running the following before
 upgrading:
@@ -321,8 +321,8 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
 
 By default, GitLab 12.6 attempts to upgrade the embedded PostgreSQL server
 version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 You can temporarily disable this behavior by running the following before
 upgrading:
@@ -335,8 +335,8 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
 
 By default, GitLab 12.5 attempts to upgrade the embedded PostgreSQL server
 version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 You can temporarily disable this behavior by running the following before
 upgrading:
@@ -349,8 +349,8 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
 
 By default, GitLab 12.4 attempts to upgrade the embedded PostgreSQL server
 version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 You can temporarily disable this behavior by running the following before
 upgrading:
@@ -365,13 +365,13 @@ WARNING:
 If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
 GitLab 12.4 or later. By default, GitLab 12.3 attempts to upgrade the embedded
 PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+fail. For more information, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
 requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 ## Upgrading to GitLab 12.2
 
@@ -379,13 +379,13 @@ WARNING:
 If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
 GitLab 12.4 or later. By default, GitLab 12.2 attempts to upgrade the embedded
 PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+fail. For more information, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
 requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 GitLab 12.2 includes the following minor PostgreSQL upgrades:
 
@@ -410,13 +410,13 @@ WARNING:
 If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
 GitLab 12.4 or later. By default, GitLab 12.1 attempts to upgrade the embedded
 PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+fail. For more information, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
 requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
 
 ## Upgrading to GitLab 12.0
 
diff --git a/doc/administration/geo/secondary_proxy/index.md b/doc/administration/geo/secondary_proxy/index.md
index 35ab1d8252c..3081d1c2485 100644
--- a/doc/administration/geo/secondary_proxy/index.md
+++ b/doc/administration/geo/secondary_proxy/index.md
@@ -122,7 +122,7 @@ for details.
   To use TLS certificates with Let's Encrypt, you can manually point the domain to one of the Geo sites, generate
   the certificate, then copy it to all other sites.
 
-- [Viewing projects and designs data from a primary site is not possible when using a unified URL](../index.md#view-replication-data-on-the-primary-site).
+- [Viewing projects data from a primary site is not possible when using a unified URL](../index.md#view-replication-data-on-the-primary-site).
 
 - When secondary proxying is used together with separate URLs, registering [GitLab runners](https://docs.gitlab.com/runner/) to clone from
 secondary sites is not supported. The runner registration succeeds, but the clone URL defaults to the primary site. The runner
@@ -152,6 +152,8 @@ sites for improved latency and bandwidth nearby. All write requests are proxied
 The following table details the components currently tested through the Geo secondary site Workhorse proxy.
 It does not cover all data types.
 
+In this context, accelerated reads refer to read requests served from the secondary site, provided that the data is up to date for the component on the secondary site. If the data on the secondary site is determined to be out of date, the request is forwarded to the primary site. Read requests for components not listed in the table below are always automatically forwarded to the primary site.
+
 | Feature / component                                 | Accelerated reads?     |
 |:----------------------------------------------------|:-----------------------|
 | Project, wiki, design repository (using the web UI) | **{dotted-circle}** No |
@@ -165,11 +167,12 @@ It does not cover all data types.
 | LFS objects (using Git)                             | **{check-circle}** Yes |
 | Pages                                               | **{dotted-circle}** No <sup>2</sup> |
 | Advanced search (using the web UI)                  | **{dotted-circle}** No |
-| Container registry                                  | **{dotted-circle}** No |
+| Container registry                                  | **{dotted-circle}** No <sup>3</sup>|
 
 1. Git reads are served from the local secondary while pushes get proxied to the primary.
    Selective sync or cases where repositories don't exist locally on the Geo secondary throw a "not found" error.
 1. Pages can use the same URL (without access control), but must be configured separately and are not proxied.
+1. The container registry is only recommended for Disaster Recovery scenarios. If the secondary site's container registry is not up to date, the read request is served with old data as the request is not forwarded to the primary site.
 
 ## Disable Geo proxying
 
@@ -179,7 +182,8 @@ Secondary proxying is enabled by default in GitLab 15.1 on a secondary site even
 
 Additionally, the `gitlab-workhorse` service polls `/api/v4/geo/proxy` every 10 seconds. In GitLab 15.2 and later, it is only polled once, if Geo is not enabled. Prior to GitLab 15.2, you can stop this polling by disabling secondary proxying.
 
-You can disable the secondary proxying on each Geo site, separately, by following these steps with Omnibus-based packages:
+You can disable the secondary proxying on each Geo site separately by following these steps on a Linux package
+installation:
 
 1. SSH into each application node (serving user traffic directly) on your secondary Geo site
    and add the following environment variable:
diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index cf0c40dbbc5..31d0fbdffe0 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -12,14 +12,13 @@ GitLab database to a secondary site's database. You may have to change some
 values, based on attributes including your database's setup and size.
 
 NOTE:
-If your GitLab installation uses external (not managed by Omnibus GitLab)
-PostgreSQL instances, the Omnibus roles cannot perform all necessary
-configuration steps. In this case, use the [Geo with external PostgreSQL instances](external_database.md)
-process instead.
+If your GitLab installation uses external PostgreSQL instances (not managed by a Linux package installation),
+the roles cannot perform all necessary configuration steps. In this case, use the
+[Geo with external PostgreSQL instances](external_database.md) process instead.
 
 NOTE:
 The stages of the setup process must be completed in the documented order.
-If not, [complete all prior stages](../setup/index.md#using-omnibus-gitlab) before proceeding.
+If not, [complete all prior stages](../setup/index.md#using-linux-package-installations) before proceeding.
 
 Ensure the **secondary** site is running the same version of GitLab Enterprise Edition as the **primary** site. Confirm you have added a license for a [Premium or Ultimate subscription](https://about.gitlab.com/pricing/) to your **primary** site.
 
@@ -51,10 +50,10 @@ recover. See below for more details.
 
 The following guide assumes that:
 
-- You are using Omnibus and therefore you are using PostgreSQL 12 or later,
+- You are using the Linux package (so are using PostgreSQL 12 or later),
   which includes the [`pg_basebackup` tool](https://www.postgresql.org/docs/12/app-pgbasebackup.html).
 - You have a **primary** site already set up (the GitLab server you are
-  replicating from), running Omnibus' PostgreSQL (or equivalent version), and
+  replicating from), running PostgreSQL (or equivalent version) managed by your Linux package installation, and
   you have a new **secondary** site set up with the same
   [versions of PostgreSQL](../index.md#requirements-for-running-geo),
   OS, and GitLab on all sites.
@@ -140,7 +139,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
    ```
 
-   If you are using an external database not managed by Omnibus GitLab, you need
+   If you are using an external database not managed by your Linux package installation, you need
    to create the `gitlab_replicator` user and define a password for that user manually:
 
    ```sql
@@ -205,7 +204,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    NOTE:
    If you need to use `0.0.0.0` or `*` as the `listen_address`, you also must add
    `127.0.0.1/32` to the `postgresql['md5_auth_cidr_addresses']` setting, to allow Rails to connect through
-   `127.0.0.1`. For more information, see [omnibus-5258](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5258).
+   `127.0.0.1`. For more information, see [issue 5258](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5258).
 
    Depending on your network configuration, the suggested addresses may
    be incorrect. If your **primary** site and **secondary** sites connect over a local
@@ -374,7 +373,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    to the private key, which is **only** present on the **primary** site.
 
 1. Test that the `gitlab-psql` user can connect to the **primary** site's database
-   (the default Omnibus database name is `gitlabhq_production`):
+   (the default database name is `gitlabhq_production` on a Linux package installation):
 
    ```shell
    sudo \
@@ -456,8 +455,8 @@ Below is a script that connects the database on the **secondary** site to
 the database on the **primary** site. This script replicates the database and creates the
 needed files for streaming replication.
 
-The directories used are the defaults that are set up in Omnibus. If you have
-changed any defaults, configure the script accordingly, replacing any directories and paths.
+The directories used are the defaults that are set up in a Linux package installation. If you have
+changed any defaults, configure the script accordingly (replacing any directories and paths).
 
 WARNING:
 Make sure to run this on the **secondary** site as it removes all PostgreSQL's
@@ -537,12 +536,12 @@ You should use PgBouncer if you use GitLab in a highly available
 configuration with a cluster of nodes supporting a Geo **primary** site and
 two other clusters of nodes supporting a Geo **secondary** site. You need two PgBouncer nodes: one for the
 main database and the other for the tracking database. For more information,
-see [High Availability with Omnibus GitLab](../../postgresql/replication_and_failover.md).
+see [the relevant documentation](../../postgresql/replication_and_failover.md).
 
 ### Changing the replication password
 
 To change the password for the [replication user](https://wiki.postgresql.org/wiki/Streaming_Replication)
-when using Omnibus-managed PostgreSQL instances:
+when using PostgreSQL instances managed by a Linux package installation:
 
 On the GitLab Geo **primary** site:
 
@@ -628,7 +627,7 @@ to `gitlab.rb` where `<slot_name>` is the name of the replication slot for your
 
 ### Migrating a single PostgreSQL node to Patroni
 
-Before the introduction of Patroni, Geo had no Omnibus support for HA setups on the **secondary** site.
+Before the introduction of Patroni, Geo had no support for Linux package installations for HA setups on the **secondary** site.
 
 With Patroni, this support is now possible. To migrate the existing PostgreSQL to Patroni:
 
@@ -639,7 +638,7 @@ With Patroni, this support is now possible. To migrate the existing PostgreSQL t
 1. [Configure a Standby Cluster](#step-4-configure-a-standby-cluster-on-the-secondary-site)
    on that single node machine.
 
-You end up with a “Standby Cluster” with a single node. That allows you to add additional Patroni nodes by following the same instructions above.
+You end up with a _Standby Cluster_ with a single node. That allows you to add additional Patroni nodes by following the same instructions above.
 
 ### Patroni support
 
@@ -649,7 +648,7 @@ Using Patroni on a **secondary** site is optional and you don't have to use the
 nodes on each Geo site.
 
 For instructions on how to set up Patroni on the primary site, see the
-[PostgreSQL replication and failover with Omnibus GitLab](../../postgresql/replication_and_failover.md#patroni) page.
+[relevant documentation](../../postgresql/replication_and_failover.md#patroni).
 
 #### Configuring Patroni cluster for a Geo secondary site
 
@@ -743,8 +742,8 @@ Leader is elected on the primary site, you should set up a TCP internal load
 balancer. This load balancer provides a single endpoint for connecting to the Patroni
 cluster's Leader.
 
-The Omnibus GitLab packages do not include a Load Balancer. Here's how you
-could do it with [HAProxy](https://www.haproxy.org/).
+Linux packages do not include a Load Balancer. Here's how you could do it with
+[HAProxy](https://www.haproxy.org/).
 
 The following IPs and names are used as an example:
 
@@ -787,7 +786,7 @@ three Consul nodes and a minimum of one PgBouncer node. However, it is recommend
 one PgBouncer node per database node. An internal load balancer (TCP) is required when there is
 more than one PgBouncer service node. The internal load balancer provides a single
 endpoint for connecting to the PgBouncer cluster. For more information,
-see [High Availability with Omnibus GitLab](../../postgresql/replication_and_failover.md).
+see [the relevant documentation](../../postgresql/replication_and_failover.md).
 
 On each node running a PgBouncer instance on the **secondary** site:
 
@@ -921,7 +920,7 @@ For each node running a Patroni instance on the secondary site:
 
 ### Migrating a single tracking database node to Patroni
 
-Before the introduction of Patroni, Geo provided no Omnibus support for HA setups on
+Before the introduction of Patroni, Geo provided no support for Linux package installations for HA setups on
 the secondary site.
 
 With Patroni, it's now possible to support HA setups. However, some restrictions in Patroni
@@ -935,7 +934,7 @@ synchronization is required.
 
 **Secondary** sites use a separate PostgreSQL installation as a tracking database to
 keep track of replication status and automatically recover from potential replication issues.
-Omnibus automatically configures a tracking database when `roles(['geo_secondary_role'])` is set.
+The Linux package automatically configures a tracking database when `roles(['geo_secondary_role'])` is set.
 
 If you want to run this database in a highly available configuration, don't use the `geo_secondary_role` above.
 Instead, follow the instructions below.
@@ -945,7 +944,7 @@ If you want to run the Geo tracking database on a single node, see [Configure th
 A production-ready and secure setup for the tracking PostgreSQL DB requires at least three Consul nodes: two
 Patroni nodes, and one PgBouncer node on the secondary site.
 
-Because of [omnibus-6587](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6587), Consul can't track multiple
+Because of [issue 6587](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6587), Consul can't track multiple
 services, so these must be different than the nodes used for the Standby Cluster database.
 
 Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni)
diff --git a/doc/administration/geo/setup/external_database.md b/doc/administration/geo/setup/external_database.md
index 65ea2e6e5af..81541d1cb9c 100644
--- a/doc/administration/geo/setup/external_database.md
+++ b/doc/administration/geo/setup/external_database.md
@@ -6,17 +6,17 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Geo with external PostgreSQL instances **(PREMIUM SELF)**
 
-This document is relevant if you are using a PostgreSQL instance that is *not
-managed by Omnibus*. This includes cloud-managed instances like Amazon RDS, or
+This document is relevant if you are using a PostgreSQL instance that is not
+managed by the Linux package. This includes cloud-managed instances like Amazon RDS, or
 manually installed and configured PostgreSQL instances.
 
 Ensure that you are using one of the PostgreSQL versions that
-[Omnibus ships with](../../package_information/postgresql_versions.md)
+the [Linux package ships with](../../package_information/postgresql_versions.md)
 to [avoid version mismatches](../index.md#requirements-for-running-geo)
 in case a Geo site has to be rebuilt.
 
 NOTE:
-We strongly recommend running Omnibus-managed instances as they are actively
+We strongly recommend running instances installed using the Linux package as they are actively
 developed and tested. We aim to be compatible with most external
 (not managed by Omnibus) databases but we do not guarantee compatibility.
 
@@ -62,8 +62,8 @@ developed and tested. We aim to be compatible with most external
 
 To set up an external database, you can either:
 
-- Set up [streaming replication](https://www.postgresql.org/docs/12/warm-standby.html#STREAMING-REPLICATION-SLOTS) yourself (for example Amazon RDS, or bare metal not managed by Omnibus).
-- Perform the Omnibus configuration manually as follows.
+- Set up [streaming replication](https://www.postgresql.org/docs/12/warm-standby.html#STREAMING-REPLICATION-SLOTS) yourself (for example Amazon RDS, or bare metal not managed by the Linux package).
+- Manually perform the configuration of your Linux package installations as follows.
 
 #### Leverage your cloud provider's tools to replicate the primary database
 
@@ -142,7 +142,7 @@ hot_standby = on
 
 ### Configure **secondary** site to use the external read-replica
 
-With Omnibus, the
+With Linux package installations, the
 [`geo_secondary_role`](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles)
 has three main functions:
 
@@ -179,15 +179,15 @@ To configure the connection to the external read-replica database and enable Log
    postgresql['enable'] = false
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
 
 ### Configure the tracking database
 
 **Secondary** sites use a separate PostgreSQL installation as a tracking
 database to keep track of replication status and automatically recover from
-potential replication issues. Omnibus automatically configures a tracking database
+potential replication issues. The Linux package automatically configures a tracking database
 when `roles ['geo_secondary_role']` is set.
-If you want to run this database external to Omnibus GitLab, use the following instructions.
+If you want to run this database external to your Linux package installation, use the following instructions.
 
 If you are using a cloud-managed service for the tracking database, you may need
 to grant additional roles to your tracking database user (by default, this is
@@ -244,7 +244,7 @@ the tracking database on port 5432.
    geo_postgresql['enable'] = false     # don't use internal managed instance
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
 
 1. The reconfigure should automatically create the database. If needed, you can perform this task manually. This task (whether run by itself or during reconfigure) requires the database user to be a superuser.
 
diff --git a/doc/administration/geo/setup/index.md b/doc/administration/geo/setup/index.md
index da7e55509e7..359f706a8aa 100644
--- a/doc/administration/geo/setup/index.md
+++ b/doc/administration/geo/setup/index.md
@@ -18,22 +18,41 @@ type: howto
 
 - Ensure the **primary** site has a [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/) subscription to unlock Geo. You only need one license for all the sites.
 - Confirm the [requirements for running Geo](../index.md#requirements-for-running-geo) are met by all sites. For example, sites must use the same GitLab version, and sites must be able to communicate with each other over certain ports.
+- Confirm the **primary** and **secondary** site storage configurations match. If the primary Geo site uses object storage, the secondary Geo site must use it too. For more information, see [Geo with Object storage](../replication/object_storage.md).
+- Ensure clocks are synchronized between the **primary** site and the **secondary** site. Synchronized clocks are required for Geo to function correctly. For example, if the clock drift between the **primary** and **secondary** sites exceeds 1 minute, replication fails.
 
-## Using Omnibus GitLab
+## Using Linux package installations
 
-If you installed GitLab using the Omnibus packages (highly recommended):
+If you installed GitLab using the Linux package (highly recommended), the process for setting up Geo depends on whether you need to set up
+a single-node Geo site or a multi-node Geo site.
 
-1. [Set up the database replication](database.md) (`primary (read-write) <-> secondary (read-only)` topology).
+### Single-node Geo sites
+
+If both Geo sites are based on the [1K reference architecture](../../reference_architectures/1k_users.md):
+
+1. Set up the database replication based on your choice of PostgreSQL instances (`primary (read-write) <-> secondary (read-only)` topology):
+   - [Using Linux package PostgreSQL instances](database.md) .
+   - [Using external PostgreSQL instances](external_database.md)
 1. [Configure GitLab](../replication/configuration.md) to set the **primary** and **secondary** sites.
-1. Optional: [Configure Object storage](../../object_storage.md)
+1. Recommended: [Configure unified URLs](../secondary_proxy/index.md) to use a single, unified URL for all Geo sites.
+1. Optional: [Configure Object storage replication](../../object_storage.md)
 1. Optional: [Configure a secondary LDAP server](../../auth/ldap/index.md) for the **secondary** sites. See [notes on LDAP](../index.md#ldap).
-1. Optional: [Configure Geo secondary proxying](../secondary_proxy/index.md) to use a single, unified URL for all Geo sites. This step is recommended to accelerate most read requests while transparently proxying writes to the primary Geo site.
+1. Optional: [Configure Container Registry for the secondary site](../replication/container_registry.md).
 1. Follow the [Using a Geo Site](../replication/usage.md) guide.
 
+### Multi-node Geo sites
+
+If one or more of your sites is using the [2K reference architecture](../../reference_architectures/2k_users.md) or larger, see
+[Configure Geo for multiple nodes](../replication/multiple_servers.md).
+
 ## Using GitLab Charts
 
 [Configure the GitLab chart with GitLab Geo](https://docs.gitlab.com/charts/advanced/geo/).
 
+## Geo and self-compiled installations
+
+Geo is not supported when you use a [self-compiled GitLab installation](../../../install/installation.md).
+
 ## Post-installation documentation
 
 After installing GitLab on the **secondary** sites and performing the initial configuration, see the [following documentation for post-installation information](../index.md#post-installation-documentation).
diff --git a/doc/administration/get_started.md b/doc/administration/get_started.md
index 0b5de38a78b..60291732a20 100644
--- a/doc/administration/get_started.md
+++ b/doc/administration/get_started.md
@@ -37,8 +37,8 @@ Watch an overview of [groups and projects](https://www.youtube.com/watch?v=cqb2m
 Get started:
 
 - Create a [project](../user/project/index.md#create-a-project).
-- Create a [group](../user/group/manage.md#create-a-group).
-- [Add members](../user/group/manage.md#add-users-to-a-group) to the group.
+- Create a [group](../user/group/index.md#create-a-group).
+- [Add members](../user/group/index.md#add-users-to-a-group) to the group.
 - Create a [subgroup](../user/group/subgroups/index.md#create-a-subgroup).
 - [Add members](../user/group/subgroups/index.md#subgroup-membership) to the subgroup.
 - Enable [external authorization control](../user/admin_area/settings/external_authorization.md#configuration).
@@ -126,11 +126,11 @@ GitLab provides backup methods to keep your data safe and recoverable. Whether y
 
 ### Back up a GitLab self-managed instance
 
-The routine differs, depending on whether you deployed with Omnibus or the Helm chart.
+The routine differs, depending on whether you deployed with the Linux package or the Helm chart.
 
-When you backing up an Omnibus (single node) GitLab server, you can use a single Rake task.
+When backing up (single node) GitLab server installed using the Linux package, you can use a single Rake task.
 
-Learn about [backing up Omnibus or Helm variations](../raketasks/backup_restore.md).
+Learn about [backing up Linux package or Helm variations](../raketasks/backup_restore.md).
 This process backs up your entire instance, but does not back up the configuration files. Ensure those are backed up separately.
 Keep your configuration files and backup archives in a separate location to ensure the encryption keys are not kept with the encrypted data.
 
@@ -138,7 +138,7 @@ Keep your configuration files and backup archives in a separate location to ensu
 
 You can restore a backup only to **the exact same version and type** (Community Edition/Enterprise Edition) of GitLab on which it was created.
 
-- Review the [Omnibus backup and restore documentation](https://docs.gitlab.com/omnibus/settings/backups).
+- Review the [Linux package (Omnibus) backup and restore documentation](https://docs.gitlab.com/omnibus/settings/backups).
 - Review the [Helm Chart backup and restore documentation](https://docs.gitlab.com/charts/backup-restore/).
 
 ### Back up GitLab SaaS
@@ -172,7 +172,7 @@ If your GitLab server contains a lot of Git repository data, you may find the Gi
 Slowness typically starts at a Git repository data size of around 200 GB. In this case, you might consider using file system snapshots as part of your backup strategy.
 For example, consider a GitLab server with the following components:
 
-- Using Omnibus GitLab
+- Using the Linux package.
 - Hosted on AWS with an EBS drive containing an ext4 file system mounted at `/var/opt/gitlab`.
 
 The EC2 instance meets the requirements for an application data backup by taking an EBS snapshot. The backup includes all repositories, uploads, and PostgreSQL data.
diff --git a/doc/administration/git_protocol.md b/doc/administration/git_protocol.md
index b996b9efae9..1ece7d773ee 100644
--- a/doc/administration/git_protocol.md
+++ b/doc/administration/git_protocol.md
@@ -29,7 +29,7 @@ and [All-in-one Docker image](../install/docker.md), the SSH
 service is already configured to accept the `GIT_PROTOCOL` environment. Users
 need not do anything more.
 
-For Omnibus GitLab and installations from source, update
+For installations from the Linux package or self-compiled installations, update
 the SSH configuration of your server manually by adding this line to the `/etc/ssh/sshd_config` file:
 
 ```plaintext
diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index f3eb2de3f1d..5c6fc370052 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -14,7 +14,7 @@ Configure Gitaly in one of two ways:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add or change the
    [Gitaly settings](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/1dd07197c7e5ae23626aad5a4a070a800b670380/files/gitlab-config-template/gitlab.rb.template#L1622-1676).
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 :::TabTitle Self-compiled (source)
 
@@ -40,8 +40,8 @@ By default, Gitaly is run on the same server as Gitaly clients and is
 [configured as above](#configure-gitaly). Single-server installations are best served by
 this default configuration used by:
 
-- [Omnibus GitLab](https://docs.gitlab.com/omnibus/).
-- The GitLab [source installation guide](../../install/installation.md).
+- [Linux package installations](https://docs.gitlab.com/omnibus/).
+- [Self-compiled installations](../../install/installation.md).
 
 However, Gitaly can be deployed to its own server, which can benefit GitLab installations that span
 multiple machines.
@@ -112,12 +112,11 @@ You can use as few as one server with one repository storage if desired.
 
 ### Install Gitaly
 
-Install Gitaly on each Gitaly server using either Omnibus GitLab or install it from source:
+Install Gitaly on each Gitaly server using either:
 
-- For Omnibus GitLab, [download and install](https://about.gitlab.com/install/) the Omnibus GitLab
-  package you want but **do not** provide the `EXTERNAL_URL=` value.
-- To install from source, follow the steps at
-  [Install Gitaly](../../install/installation.md#install-gitaly).
+- A Linux package installation. [Download and install](https://about.gitlab.com/install/) the Linux package you want
+  but **do not** provide the `EXTERNAL_URL=` value.
+- A self-compiled installation. Follow the steps at [Install Gitaly](../../install/installation.md#install-gitaly).
 
 ### Configure Gitaly servers
 
@@ -301,7 +300,7 @@ Configure Gitaly server in one of two ways:
    }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. Confirm that Gitaly can perform callbacks to the GitLab internal API:
    - For GitLab 15.3 and later, run `sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml`.
    - For GitLab 15.2 and earlier, run `sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml`.
@@ -424,7 +423,7 @@ Configure Gitaly clients in one of two ways:
    })
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. Run `sudo gitlab-rake gitlab:gitaly:check` on the Gitaly client (for example, the
    Rails application) to confirm it can connect to Gitaly servers.
 1. Tail the logs to see the requests:
@@ -564,7 +563,7 @@ Disable Gitaly on a GitLab server in one of two ways:
    gitaly['enable'] = false
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 :::TabTitle Self-compiled (source)
 
@@ -633,7 +632,7 @@ Configure Gitaly with TLS in one of two ways:
    })
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. On the Gitaly servers, create the `/etc/gitlab/ssl` directory and copy your key and certificate
    there:
 
@@ -668,14 +667,14 @@ Configure Gitaly with TLS in one of two ways:
    }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. Verify Gitaly traffic is being served over TLS by
    [observing the types of Gitaly connections](#observe-type-of-gitaly-connections).
 1. Optional. Improve security by:
    1. Disabling non-TLS connections by commenting out or deleting `gitaly['configuration'][:listen_addr]` in
       `/etc/gitlab/gitlab.rb`.
    1. Saving the file.
-   1. [Reconfiguring GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+   1. [Reconfiguring GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 :::TabTitle Self-compiled (source)
 
@@ -880,7 +879,7 @@ to `gitaly['configuration'][:cgroups]` in `/etc/gitlab/gitlab.rb`:
 
 - `mountpoint` is where the parent cgroup directory is mounted. Defaults to `/sys/fs/cgroup`.
 - `hierarchy_root` is the parent cgroup under which Gitaly creates groups, and
-   is expected to be owned by the user and group Gitaly runs as. Omnibus GitLab
+   is expected to be owned by the user and group Gitaly runs as. A Linux package installation
    creates the set of directories `mountpoint/<cpu|memory>/hierarchy_root`
    when Gitaly starts.
 - `memory_bytes` is the total memory limit that is imposed collectively on all
@@ -939,7 +938,7 @@ in `/etc/gitlab/gitlab.rb`:
    commands to these cgroups.
 - `cgroups_mountpoint` is where the parent cgroup directory is mounted. Defaults to `/sys/fs/cgroup`.
 - `cgroups_hierarchy_root` is the parent cgroup under which Gitaly creates groups, and
-   is expected to be owned by the user and group Gitaly runs as. Omnibus GitLab
+   is expected to be owned by the user and group Gitaly runs as. A Linux package installation
    creates the set of directories `mountpoint/<cpu|memory>/hierarchy_root`
    when Gitaly starts.
 - `cgroups_memory_enabled` enables or disables the memory limit on cgroups.
@@ -1388,7 +1387,7 @@ objects even if the project doesn't have malicious intent.
 Instance administrators can override consistency checks if they must
 process repositories that do not pass consistency checks.
 
-For Omnibus GitLab installations, edit `/etc/gitlab/gitlab.rb` and set the
+For Linux package installations, edit `/etc/gitlab/gitlab.rb` and set the
 following keys (in this example, to disable the `hasDotgit` consistency check):
 
 - In [GitLab 15.10](https://gitlab.com/gitlab-org/gitaly/-/issues/4754) and later:
@@ -1537,7 +1536,7 @@ Configure Gitaly to sign commits made with the GitLab UI in one of two ways:
    }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 :::TabTitle Self-compiled (source)
 
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index 359d4ef90dc..2a3c3da24b3 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -12,7 +12,7 @@ It is used by GitLab to read and write Git data.
 Gitaly is present in every GitLab installation and coordinates Git repository
 storage and retrieval. Gitaly can be:
 
-- A background service operating on a single instance Omnibus GitLab (all of
+- A background service operating on a single instance Linux package installation (all of
   GitLab on one machine).
 - Separated onto its own instance and configured in a full cluster configuration,
   depending on scaling and availability requirements.
@@ -164,11 +164,11 @@ E --> F
 
 ### Configure Gitaly
 
-Gitaly comes pre-configured with Omnibus GitLab, which is a configuration
+Gitaly comes pre-configured with a Linux package installation, which is a configuration
 [suitable for up to 1000 users](../reference_architectures/1k_users.md). For:
 
-- Omnibus GitLab installations for up to 2000 users, see [specific Gitaly configuration instructions](../reference_architectures/2k_users.md#configure-gitaly).
-- Source installations or custom Gitaly installations, see [Configure Gitaly](configure_gitaly.md).
+- Linux package installations for up to 2000 users, see [specific Gitaly configuration instructions](../reference_architectures/2k_users.md#configure-gitaly).
+- Self-compiled installations or custom Gitaly installations, see [Configure Gitaly](configure_gitaly.md).
 
 GitLab installations for more than 2000 active users performing daily Git write operation may be
 best suited by using Gitaly Cluster.
@@ -481,8 +481,7 @@ You can [monitor distribution of reads](monitoring.md#monitor-gitaly-cluster) us
 
 #### Strong consistency
 
-> - In GitLab 13.6 to 13.12, strong consistency must be manually configured. Refer to [the 13.12 documentation](https://docs.gitlab.com/13.12/ee/administration/gitaly/praefect.html#strong-consistency).
-> - In GitLab 14.0, strong consistency is the primary replication method.
+> In GitLab 14.0, strong consistency is the primary replication method.
 
 Gitaly Cluster provides strong consistency by writing changes synchronously to all healthy, up-to-date replicas. If a
 replica is outdated or unhealthy at the time of the transaction, the write is asynchronously replicated to it.
@@ -596,7 +595,7 @@ Direct access to Git uses code in GitLab known as the "Rugged patches".
 
 Before Gitaly existed, what are now Gitaly clients accessed Git repositories directly, either:
 
-- On a local disk in the case of a single-machine Omnibus GitLab installation.
+- On a local disk in the case of a single-machine Linux package installation.
 - Using NFS in the case of a horizontally-scaled GitLab installation.
 
 In addition to running plain `git` commands, GitLab used a Ruby library called
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 51201ec442f..f80a5192c55 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -90,7 +90,7 @@ GitLab application database.
 
 ## Setup Instructions
 
-If you [installed](https://about.gitlab.com/install/) GitLab using the Omnibus GitLab package
+If you [installed](https://about.gitlab.com/install/) GitLab using the Linux package
 (highly recommended), follow the steps below:
 
 1. [Preparation](#preparation)
@@ -107,7 +107,7 @@ Before beginning, you should already have a working GitLab instance.
 [Learn how to install GitLab](https://about.gitlab.com/install/).
 
 Provision a PostgreSQL server. You should use the PostgreSQL that is shipped
-with Omnibus GitLab and use it to configure the PostgreSQL database. You can use an
+with the Linux package and use it to configure the PostgreSQL database. You can use an
 external PostgreSQL server (version 11 or newer) but you must set it up [manually](#manual-database-setup).
 
 Prepare all your new nodes by [installing GitLab](https://about.gitlab.com/install/). You need:
@@ -159,7 +159,7 @@ with secure tokens as you complete the setup process.
 We note in the instructions below where these secrets are required.
 
 NOTE:
-Omnibus GitLab installations can use `gitlab-secrets.json` for `GITLAB_SHELL_SECRET_TOKEN`.
+Linux package installations can use `gitlab-secrets.json` for `GITLAB_SHELL_SECRET_TOKEN`.
 
 ### Customize time server setting
 
@@ -178,7 +178,7 @@ The replication state is internal to each instance of GitLab and should
 not be replicated.
 
 These instructions help set up a single PostgreSQL database, which creates a single point of failure. To avoid this, you can configure your own clustered
-PostgreSQL. Support for PostgreSQL replication and failover using Omnibus GitLab is proposed in [epic 7814](https://gitlab.com/groups/gitlab-org/-/epics/7814).
+PostgreSQL. Support for PostgreSQL replication and failover using the Linux package is proposed in [epic 7814](https://gitlab.com/groups/gitlab-org/-/epics/7814).
 Clustered database support for other databases (for example, Praefect and Geo databases) is proposed in
 [issue 7292](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7292).
 
@@ -198,7 +198,7 @@ Setting up PostgreSQL creates empty Praefect tables. For more information, see t
 #### Running GitLab and Praefect databases on the same server
 
 The GitLab application database and the Praefect database can be run on the same server. However, Praefect should have
-its own database server when using Omnibus GitLab PostgreSQL. If there is a failover, Praefect isn't aware and starts to
+its own database server when using PostgreSQL from the Linux package. If there is a failover, Praefect isn't aware and starts to
 fail as the database it's trying to use would either:
 
 - Be unavailable.
@@ -213,10 +213,10 @@ To complete this section you need:
   - A PostgreSQL user with permissions to manage the database server
 
 In this section, we configure the PostgreSQL database. This can be used for both external
-and Omnibus-provided PostgreSQL server.
+and Linux package-provided PostgreSQL server.
 
 To run the following instructions, you can use the Praefect node, where `psql` is installed
-by Omnibus GitLab (`/opt/gitlab/embedded/bin/psql`). If you are using the Omnibus-provided
+by the Linux package (`/opt/gitlab/embedded/bin/psql`). If you are using the Linux package-provided
 PostgreSQL you can use `gitlab-psql` on the PostgreSQL node instead:
 
 1. Create a new user `praefect` to be used by Praefect:
@@ -233,11 +233,11 @@ PostgreSQL you can use `gitlab-psql` on the PostgreSQL node instead:
    CREATE DATABASE praefect_production WITH OWNER praefect ENCODING UTF8;
    ```
 
-For using Omnibus-provided PgBouncer you need to take the following additional steps. We strongly
-recommend using the PostgreSQL that is shipped with Omnibus as the backend. The following
-instructions only work on Omnibus-provided PostgreSQL:
+When using the Linux package-provided PgBouncer, you need to take the following additional steps. We strongly
+recommend using the PostgreSQL that is shipped with the Linux package as the backend. The following
+instructions only work on the Linux package-provided PostgreSQL:
 
-1. For Omnibus-provided PgBouncer, you need to use the hash of `praefect` password instead the of the
+1. For the Linux package-provided PgBouncer, you need to use the hash of `praefect` password instead the of the
    actual password:
 
    ```sql
@@ -247,7 +247,7 @@ instructions only work on Omnibus-provided PostgreSQL:
    Replace `<PRAEFECT_SQL_PASSWORD_HASH>` with the hash of the password you generated in the
    preparation step. It is prefixed with `md5` literal.
 
-1. The PgBouncer that is shipped with Omnibus is configured to use [`auth_query`](https://www.pgbouncer.org/config.html#generic-settings)
+1. The PgBouncer that is shipped with the Linux package is configured to use [`auth_query`](https://www.pgbouncer.org/config.html#generic-settings)
    and uses `pg_shadow_lookup` function. You need to create this function in `praefect_production`
    database:
 
@@ -447,7 +447,7 @@ praefect['configuration'] = {
 With this configuration, Praefect uses PgBouncer for both connection types.
 
 NOTE:
-Omnibus GitLab handles the authentication requirements (using `auth_query`), but if you are preparing
+Linux package installations handle the authentication requirements (using `auth_query`), but if you are preparing
 your databases manually and configuring an external PgBouncer, you must include `praefect` user and
 its password in the file used by PgBouncer. For example, `userlist.txt` if the [`auth_file`](https://www.pgbouncer.org/config.html#auth_file)
 configuration option is set. For more details, consult the PgBouncer documentation.
@@ -670,7 +670,7 @@ Updates to example must be made at:
 1. Enable [distribution of reads](index.md#distributed-reads).
 
 1. Save the changes to `/etc/gitlab/gitlab.rb` and
-   [reconfigure Praefect](../restart_gitlab.md#omnibus-gitlab-reconfigure):
+   [reconfigure Praefect](../restart_gitlab.md#reconfigure-a-linux-package-installation):
 
    ```shell
    gitlab-ctl reconfigure
@@ -694,7 +694,7 @@ Updates to example must be made at:
      additional configuration changes can be done and then reconfigure can be run manually.
 
 1. Save the changes to `/etc/gitlab/gitlab.rb` and
-   [reconfigure Praefect](../restart_gitlab.md#omnibus-gitlab-reconfigure):
+   [reconfigure Praefect](../restart_gitlab.md#reconfigure-a-linux-package-installation):
 
    ```shell
    gitlab-ctl reconfigure
@@ -702,7 +702,7 @@ Updates to example must be made at:
 
 1. To ensure that Praefect
    [has updated its Prometheus listen address](https://gitlab.com/gitlab-org/gitaly/-/issues/2734),
-   [restart Praefect](../restart_gitlab.md#omnibus-gitlab-restart):
+   [restart Praefect](../restart_gitlab.md#reconfigure-a-linux-package-installation):
 
    ```shell
    gitlab-ctl restart praefect
@@ -758,9 +758,9 @@ Note the following:
   }
   ```
 
-To configure Praefect with TLS:
+Configure Praefect with TLS.
 
-**For Omnibus GitLab**
+For Linux package installations:
 
 1. Create certificates for Praefect servers.
 
@@ -788,7 +788,7 @@ To configure Praefect with TLS:
    }
    ```
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 1. On the Praefect clients (including each Gitaly server), copy the certificates,
    or their certificate authority, into `/etc/gitlab/trusted-certs`:
@@ -809,9 +809,9 @@ To configure Praefect with TLS:
    })
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
-**For installations from source**
+For self-compiled installations:
 
 1. Create certificates for Praefect servers.
 1. On the Praefect servers, create the `/etc/gitlab/ssl` directory and copy your key and certificate
@@ -950,7 +950,7 @@ You can also appoint an authoritative name server by setting it in this format:
    praefect['consul_service_name'] = 'praefect'
    ```
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. On the Praefect clients (except Gitaly servers), edit `git_data_dirs` in
 `/etc/gitlab/gitlab.rb` as follows. Replace `PRAEFECT_SERVICE_DISCOVERY_ADDRESS`
 with Praefect service discovery address, such as `praefect.service.consul`.
@@ -964,7 +964,7 @@ with Praefect service discovery address, such as `praefect.service.consul`.
    })
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 :::TabTitle Self-compiled (source)
 
@@ -1091,7 +1091,7 @@ For more information on Gitaly server configuration, see our
 
      1. Copy `/etc/gitlab/gitlab-secrets.json` from the Gitaly client to same path on the Gitaly
         servers and any other Gitaly clients.
-     1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on Gitaly servers.
+     1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) on Gitaly servers.
 
    - Method 2:
 
@@ -1146,7 +1146,7 @@ For more information on Gitaly server configuration, see our
    ```
 
 1. Save the changes to `/etc/gitlab/gitlab.rb` and
-   [reconfigure Gitaly](../restart_gitlab.md#omnibus-gitlab-reconfigure):
+   [reconfigure Gitaly](../restart_gitlab.md#reconfigure-a-linux-package-installation):
 
    ```shell
    gitlab-ctl reconfigure
@@ -1154,7 +1154,7 @@ For more information on Gitaly server configuration, see our
 
 1. To ensure that Gitaly
    [has updated its Prometheus listen address](https://gitlab.com/gitlab-org/gitaly/-/issues/2734),
-   [restart Gitaly](../restart_gitlab.md#omnibus-gitlab-restart):
+   [restart Gitaly](../restart_gitlab.md#reconfigure-a-linux-package-installation):
 
    ```shell
    gitlab-ctl restart gitaly
@@ -1273,7 +1273,7 @@ Particular attention should be shown to:
 
      1. Copy `/etc/gitlab/gitlab-secrets.json` from the Gitaly client to same path on the Gitaly
         servers and any other Gitaly clients.
-     1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on Gitaly servers.
+     1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) on Gitaly servers.
 
    - Method 2:
 
@@ -1317,7 +1317,7 @@ Particular attention should be shown to:
    ]
    ```
 
-1. Save the changes to `/etc/gitlab/gitlab.rb` and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure):
+1. Save the changes to `/etc/gitlab/gitlab.rb` and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation):
 
    ```shell
    gitlab-ctl reconfigure
@@ -1335,7 +1335,8 @@ Particular attention should be shown to:
 
 1. Check that the Praefect storage is configured to store new repositories:
 
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
    1. On the left sidebar, select **Settings > Repository**.
    1. Expand the **Repository storage** section.
 
@@ -1388,7 +1389,7 @@ To get started quickly:
    ```
 
 1. Save the changes to `/etc/gitlab/gitlab.rb` and
-   [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure):
+   [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation):
 
    ```shell
    gitlab-ctl reconfigure
@@ -1424,49 +1425,59 @@ Praefect does not store the actual replication factor, but assigns enough storag
 so the desired replication factor is met. If a storage node is later removed from the virtual storage,
 the replication factor of repositories assigned to the storage is decreased accordingly.
 
-You can configure:
+You can configure either:
 
-- A default replication factor for each virtual storage that is applied to newly-created repositories.
-  The configuration is added to the `/etc/gitlab/gitlab.rb` file:
+- A default replication factor for each virtual storage that is applied to newly created repositories.
+- A replication factor for an existing repository with the `set-replication-factor` subcommand.
 
-  ```ruby
-   praefect['configuration'] = {
-      # ...
-      virtual_storage: [
-         {
-            # ...
-            name: 'default',
-            default_replication_factor: 1,
-         },
-      ],
-   }
-  ```
+### Configure default replication factor
 
-- A replication factor for an existing repository using the `set-replication-factor` sub-command.
-  `set-replication-factor` automatically assigns or unassigns random storage nodes as
-  necessary to reach the desired replication factor. The repository's primary node is
-  always assigned first and is never unassigned.
+If `default_replication_factor` is unset, the repositories are always replicated on every node defined in
+`virtual_storages`. If a new node is introduced to the virtual storage, both new and existing repositories are
+replicated to the node automatically.
 
-  ```shell
-  sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml set-replication-factor -virtual-storage <virtual-storage> -repository <relative-path> -replication-factor <replication-factor>
-  ```
+For large Gitaly Cluster deployments with many Gitaly nodes, replicating a repository to every storage is often not
+sensible and can cause problems. The higher the replication factor, the higher the pressure on the primary repository.
+You should explicitly set the default replication factor for large Gitaly Cluster deployments.
+
+To configure a default replication factor, add configuration to the `/etc/gitlab/gitlab.rb` file:
+
+```ruby
+praefect['configuration'] = {
+   # ...
+   virtual_storage: [
+      {
+         # ...
+         name: 'default',
+         default_replication_factor: 1,
+      },
+   ],
+}
+```
 
-  - `-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.
+### Configure replication factor for existing repositories
 
-  On success, the assigned host storages are printed. For example:
+The `set-replication-factor` subcommand automatically assigns or unassigns random storage nodes as
+necessary to reach the desired replication factor. The repository's primary node is
+always assigned first and is never unassigned.
 
-  ```shell
-  $ sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml set-replication-factor -virtual-storage default -repository @hashed/3f/db/3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278.git -replication-factor 2
+```shell
+sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml set-replication-factor -virtual-storage <virtual-storage> -repository <relative-path> -replication-factor <replication-factor>
+```
 
-  current assignments: gitaly-1, gitaly-2
-  ```
+- `-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.
+
+On success, the assigned host storages are printed. For example:
 
-If `default_replication_factor` is unset, the repositories are always replicated on every node defined in `virtual_storages`. If a new
-node is introduced to the virtual storage, both new and existing repositories are replicated to the node automatically.
+```shell
+$ sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml set-replication-factor -virtual-storage default -repository @hashed/3f/db/3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278.git -replication-factor 2
+
+current assignments: gitaly-1, gitaly-2
+```
 
 ### Repository storage recommendations
 
diff --git a/doc/administration/gitaly/recovery.md b/doc/administration/gitaly/recovery.md
index 7d27a633512..dbbed0f60ba 100644
--- a/doc/administration/gitaly/recovery.md
+++ b/doc/administration/gitaly/recovery.md
@@ -100,7 +100,7 @@ The following parameters are available:
   some assigned copies that are not available.
 
 NOTE:
-`dataloss` is still in [Beta](../../policy/alpha-beta-support.md#beta) and the output format is subject to change.
+`dataloss` is still in [Beta](../../policy/experiment-beta-support.md#beta) and the output format is subject to change.
 
 To check for repositories with outdated primaries or for unavailable repositories, run:
 
diff --git a/doc/administration/gitaly/reference.md b/doc/administration/gitaly/reference.md
index 81b3faf859e..aa04c9a92c4 100644
--- a/doc/administration/gitaly/reference.md
+++ b/doc/administration/gitaly/reference.md
@@ -7,11 +7,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Gitaly reference **(FREE SELF)**
 
 Gitaly is configured via a [TOML](https://github.com/toml-lang/toml)
-configuration file. Unlike installations from source, in Omnibus GitLab, you
-would not edit this file directly. For Omnibus GitLab installations, the default file location is `/var/opt/gitlab/gitaly/config.toml`.
+configuration file. Unlike self-compiled installations, in Linux package installations you
+would not edit this file directly. For Linux package installations, the default file location is `/var/opt/gitlab/gitaly/config.toml`.
 
-The configuration file is passed as an argument to the `gitaly` executable, which is usually done by either Omnibus
-GitLab or your [init](https://en.wikipedia.org/wiki/Init) script.
+The configuration file is passed as an argument to the `gitaly` executable, which is usually done by either your Linux
+package installation or your [init](https://en.wikipedia.org/wiki/Init) script.
 
 An [example configuration file](https://gitlab.com/gitlab-org/gitaly/blob/master/config.toml.example)
 can be found in the Gitaly project.
diff --git a/doc/administration/gitaly/troubleshooting.md b/doc/administration/gitaly/troubleshooting.md
index dbbd348556c..afef787e9c3 100644
--- a/doc/administration/gitaly/troubleshooting.md
+++ b/doc/administration/gitaly/troubleshooting.md
@@ -20,7 +20,8 @@ and our advice on [parsing the `gitaly/current` file](../logs/log_parsing.md#par
 When using standalone Gitaly servers, you must make sure they are the same version
 as GitLab to ensure full compatibility:
 
-1. On the top bar, select **Main menu > Admin** on your GitLab instance.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Overview > Gitaly Servers**.
 1. Confirm all Gitaly servers indicate that they are up to date.
 
@@ -85,7 +86,7 @@ check for an SSL or TLS problem:
 ```
 
 Check whether `Verify return code` field indicates a
-[known Omnibus GitLab configuration problem](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
+[known Linux package installation configuration problem](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
 
 If `openssl` succeeds but `gitlab-rake gitlab:gitaly:check` fails,
 check [certificate requirements](configure_gitaly.md#certificate-requirements) for Gitaly.
@@ -93,7 +94,7 @@ check [certificate requirements](configure_gitaly.md#certificate-requirements) f
 ### Server side gRPC logs
 
 gRPC tracing can also be enabled in Gitaly itself with the `GODEBUG=http2debug`
-environment variable. To set this in an Omnibus GitLab install:
+environment variable. To set this in a Linux package installation:
 
 1. Add the following to your `gitlab.rb` file:
 
@@ -103,7 +104,7 @@ environment variable. To set this in an Omnibus GitLab install:
    }
    ```
 
-1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab.
+1. [Reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation) GitLab.
 
 ### Correlating Git processes with RPCs
 
@@ -216,7 +217,7 @@ Confirm the following are all true:
 To fix this problem, confirm that your [`gitlab-secrets.json` file](configure_gitaly.md#configure-gitaly-servers)
 on the Gitaly server matches the one on Gitaly client. If it doesn't match,
 update the secrets file on the Gitaly server to match the Gitaly client, then
-[reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+[reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 If you've confirmed that your `gitlab-secrets.json` file is the same on all Gitaly servers and clients,
 the application might be fetching this secret from a different file. Your Gitaly server's
@@ -400,6 +401,10 @@ To resolve this, remove the `noexec` option from the file system mount. An alter
 1. Add `gitaly['runtime_dir'] = '<PATH_WITH_EXEC_PERM>'` to `/etc/gitlab/gitlab.rb` and specify a location without `noexec` set.
 1. Run `sudo gitlab-ctl reconfigure`.
 
+### Commit signing fails with `invalid argument: signing key is encrypted` or `invalid data: tag byte does not have MSB set.`
+
+Because Gitaly commit signing is headless and not associated with a specific user, the GPG signing key must be created without a passphrase, or the passphrase must be removed before export.
+
 ## Troubleshoot Praefect (Gitaly Cluster)
 
 The following sections provide possible solutions to Gitaly Cluster errors.
diff --git a/doc/administration/housekeeping.md b/doc/administration/housekeeping.md
index 3a2b3657145..eed14fe1bf1 100644
--- a/doc/administration/housekeeping.md
+++ b/doc/administration/housekeeping.md
@@ -76,7 +76,8 @@ frequently.
 
 You can change how often Gitaly is asked to optimize a repository.
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Repository**.
 1. Expand **Repository maintenance**.
 1. In the **Housekeeping** section, configure the housekeeping options.
@@ -108,7 +109,7 @@ housekeeping tasks. The manual trigger can be useful when either:
 
 To trigger housekeeping tasks manually:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Advanced**.
 1. Select **Run housekeeping**.
@@ -135,7 +136,7 @@ reduce the likelihood of such race conditions.
 
 To trigger a manual prune of unreachable objects:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Advanced**.
 1. Select **Run housekeeping**.
diff --git a/doc/administration/inactive_project_deletion.md b/doc/administration/inactive_project_deletion.md
index aad6a420246..278d585f2d9 100644
--- a/doc/administration/inactive_project_deletion.md
+++ b/doc/administration/inactive_project_deletion.md
@@ -23,7 +23,8 @@ For the default setting on GitLab.com, see the [GitLab.com settings page](../use
 
 To configure deletion of inactive projects:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Repository**.
 1. Expand **Repository maintenance**.
 1. In the **Inactive project deletion** section, select **Delete inactive projects**.
diff --git a/doc/administration/incoming_email.md b/doc/administration/incoming_email.md
index 3b4eaeb161c..0024c42972b 100644
--- a/doc/administration/incoming_email.md
+++ b/doc/administration/incoming_email.md
@@ -156,7 +156,7 @@ If the sender's address is spoofed, the reject notice is delivered to the spoofe
 `FROM` address, which can cause the mail server's IP or domain to appear on a block
 list.
 
-### Omnibus package installations
+### Linux package installations
 
 1. Find the `incoming_email` section in `/etc/gitlab/gitlab.rb`, enable the feature
     and fill in the details for your specific IMAP server and email account (see [examples](#configuration-examples) below).
@@ -270,7 +270,7 @@ Reply by email should now be working.
 
 Example configuration for Postfix mail server. Assumes mailbox `incoming@gitlab.example.com`.
 
-Example for Omnibus installs:
+Example for Linux package installations:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -362,7 +362,7 @@ Example configuration for Gmail/Google Workspace. Assumes mailbox `gitlab-incomi
 NOTE:
 `incoming_email_email` cannot be a Gmail alias account.
 
-Example for Omnibus installs:
+Example for Linux package installations:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -459,7 +459,7 @@ Exchange does not support sub-addressing, only two options exist:
 
 Assumes the catch-all mailbox `incoming@exchange.example.com`.
 
-Example for Omnibus installs:
+Example for Linux package installations:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -533,7 +533,7 @@ Cannot support [Service Desk](../user/project/service_desk.md).
 
 Assumes the dedicated email address `incoming@exchange.example.com`.
 
-Example for Omnibus installs:
+Example for Linux package installations:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -617,7 +617,7 @@ To enable sub-addressing:
    Disconnect-ExchangeOnline
    ```
 
-This example for Omnibus GitLab assumes the mailbox `incoming@office365.example.com`:
+This example for Linux package installations assumes the mailbox `incoming@office365.example.com`:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -678,7 +678,7 @@ incoming_email:
 
 ##### Catch-all mailbox
 
-This example for Omnibus installs assumes the catch-all mailbox `incoming@office365.example.com`:
+This example for Linux package installations assumes the catch-all mailbox `incoming@office365.example.com`:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -743,7 +743,7 @@ NOTE:
 Supports [Reply by Email](reply_by_email.md) only.
 Cannot support [Service Desk](../user/project/service_desk.md).
 
-This example for Omnibus installs assumes the dedicated email address `incoming@office365.example.com`:
+This example for Linux package installations assumes the dedicated email address `incoming@office365.example.com`:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -821,7 +821,7 @@ To mitigate security concerns, we recommend configuring an application access
 policy which limits the mailbox access for all accounts, as described in
 [Microsoft documentation](https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access).
 
-This example for Omnibus GitLab assumes you're using the following mailbox: `incoming@example.onmicrosoft.com`:
+This example for Linux package installations assumes you're using the following mailbox: `incoming@example.onmicrosoft.com`:
 
 ##### Configure Microsoft Graph
 
diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md
index 03c7c51251b..df364a3f737 100644
--- a/doc/administration/instance_limits.md
+++ b/doc/administration/instance_limits.md
@@ -781,7 +781,7 @@ Plan.default.actual_limits.update!(dast_profile_schedules: 50)
 
 ### Maximum size and depth of CI/CD configuration YAML files
 
-The default maximum size of a CI/CD configuration YAML file is 1 megabyte and the
+The default maximum size of a single CI/CD configuration YAML file is 1 megabyte and the
 default depth is 100.
 
 You can change these limits in the [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
diff --git a/doc/administration/instance_review.md b/doc/administration/instance_review.md
index 277595190b3..6a2ead82538 100644
--- a/doc/administration/instance_review.md
+++ b/doc/administration/instance_review.md
@@ -20,7 +20,7 @@ details and contact you with suggestions to improve your use of GitLab.
 To request an instance review:
 
 1. Sign in as an administrator.
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Get a free instance review**.
 
    ![Instance review](img/instance_review_v14_7.png)
diff --git a/doc/administration/integration/diagrams_net.md b/doc/administration/integration/diagrams_net.md
new file mode 100644
index 00000000000..a4e8528fb25
--- /dev/null
+++ b/doc/administration/integration/diagrams_net.md
@@ -0,0 +1,54 @@
+---
+stage: Create
+group: Source Code
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
+type: reference, howto
+---
+
+# Diagrams.net **(FREE)**
+
+With the [diagrams.net](https://www.diagrams.net/) integration, you can create and embed SVG diagrams in wikis.
+The diagram editor is available in both the Markdown editor and the content editor.
+
+On GitLab.com, this integration is enabled for all SaaS users and does not require any additional configuration.
+
+On self-managed GitLab, you can choose to integrate with the free [diagrams.net](https://www.diagrams.net/)
+website, or use a self-managed diagrams.net site in offline environments.
+
+To set up the integration on a self-managed instance, you must:
+
+1. Choose to integrate with the free diagrams.net website or
+   [configure your diagrams.net server](#configure-your-diagramsnet-server).
+1. [Enable the integration](#enable-diagramsnet-integration).
+
+After completing the integration, the diagrams.net editor opens with the URL you provided.
+
+## Configure your diagrams.net server
+
+You can set up your own diagrams.net server to generate the diagrams.
+
+This is a required step for users on offline (or "air-gapped") self-managed GitLab installations.
+
+For example, to run a diagrams.net container in Docker, run the following command:
+
+```shell
+docker run -it --rm --name="draw" -p 8080:8080 -p 8443:8443 jgraph/drawio
+```
+
+Make note of the hostname of the server running the container, to be used as the diagrams.net URL
+when you enable the integration.
+
+For more information, see [Run your own diagrams.net server with Docker](https://www.diagrams.net/blog/diagrams-docker-app).
+
+## Enable Diagrams.net integration
+
+1. Sign in to GitLab as an [Administrator](../../user/permissions.md) user.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Diagrams.net**.
+1. Select the **Enable Diagrams.net** checkbox.
+1. Enter the Diagrams.net URL. To connect to:
+   - The free public instance: enter `https://embed.diagrams.net`.
+   - A self-managed diagrams.net instance: enter the URL you [configured earlier](#configure-your-diagramsnet-server).
+1. Select **Save changes**.
diff --git a/doc/administration/integration/kroki.md b/doc/administration/integration/kroki.md
index f90458200b3..0356212d6dd 100644
--- a/doc/administration/integration/kroki.md
+++ b/doc/administration/integration/kroki.md
@@ -61,7 +61,8 @@ read the [Kroki installation](https://docs.kroki.io/kroki/setup/install/#_images
 You need to enable Kroki integration from Settings under Admin Area.
 To do that, sign in with an administrator account and follow these steps:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. Go to **Settings > General**.
 1. Expand the **Kroki** section.
 1. Select **Enable Kroki** checkbox.
diff --git a/doc/administration/integration/mailgun.md b/doc/administration/integration/mailgun.md
index 218b2888033..87428d27c66 100644
--- a/doc/administration/integration/mailgun.md
+++ b/doc/administration/integration/mailgun.md
@@ -43,7 +43,8 @@ After configuring your Mailgun domain for the webhook endpoints,
 you're ready to enable the Mailgun integration:
 
 1. Sign in to GitLab as an [Administrator](../../user/permissions.md) user.
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, go to **Settings > General** and expand the **Mailgun** section.
 1. Select the **Enable Mailgun** checkbox.
 1. Enter the Mailgun HTTP webhook signing key as described in
diff --git a/doc/administration/integration/plantuml.md b/doc/administration/integration/plantuml.md
index fcfae6cbe70..9c5e07eedaa 100644
--- a/doc/administration/integration/plantuml.md
+++ b/doc/administration/integration/plantuml.md
@@ -10,12 +10,7 @@ type: reference, howto
 With the [PlantUML](https://plantuml.com) integration, you can create diagrams in snippets, wikis, and repositories.
 This integration is enabled on GitLab.com for all SaaS users and does not require any additional configuration.
 
-To set up the integration on a self-managed instance, you must:
-
-1. [Configure your PlantUML server](#configure-your-plantuml-server).
-1. [Configure local PlantUML access](#configure-local-plantuml-access).
-1. [Configure PlantUML security](#configure-plantuml-security).
-1. [Enable the integration](#enable-plantuml-integration).
+To set up the integration on a self-managed instance, you must [configure your PlantUML server](#configure-your-plantuml-server).
 
 After completing the integration, PlantUML converts `plantuml`
 blocks to an HTML image tag, with the source pointing to the PlantUML instance. The PlantUML
@@ -123,41 +118,7 @@ services:
     container_name: plantuml
 ```
 
-### Debian/Ubuntu
-
-You can install and configure a PlantUML server in Debian/Ubuntu distributions
-using Tomcat:
-
-1. Run these commands to create a `plantuml.war` file from the source code:
-
-   ```shell
-   sudo apt-get install graphviz openjdk-8-jdk git-core maven
-   git clone https://github.com/plantuml/plantuml-server.git
-   cd plantuml-server
-   mvn package
-   ```
-
-1. Deploy the `.war` file from the previous step with these commands:
-
-   ```shell
-   sudo apt-get install tomcat8
-   sudo cp target/plantuml.war /var/lib/tomcat8/webapps/plantuml.war
-   sudo chown tomcat8:tomcat8 /var/lib/tomcat8/webapps/plantuml.war
-   sudo service tomcat8 restart
-   ```
-
-The Tomcat service should restart. After the restart is complete, the
-PlantUML integration is ready and listening for requests on port 8080:
-`http://localhost:8080/plantuml`
-
-To change these defaults, edit the `/etc/tomcat8/server.xml` file.
-
-NOTE:
-The default URL is different when using this approach. The Docker-based image
-makes the service available at the root URL, with no relative path. Adjust
-the configuration below accordingly.
-
-## Configure local PlantUML access
+#### Configure local PlantUML access
 
 The PlantUML server runs locally on your server, so it can't be accessed
 externally by default. Your server must catch external PlantUML
@@ -180,9 +141,6 @@ To enable this redirection:
    ```ruby
    # Docker deployment
    nginx['custom_gitlab_server_config'] = "location /-/plantuml/ { \n  rewrite ^/-/plantuml/(.*) /$1 break;\n  proxy_cache off; \n    proxy_pass  http://plantuml:8080/; \n}\n"
-
-   # Built from source
-   nginx['custom_gitlab_server_config'] = "location /-/plantuml { \n rewrite ^/-/plantuml/(.*) /$1 break;\n proxy_cache off; \n proxy_pass http://localhost:8080/plantuml; \n}\n"
    ```
 
 1. To activate the changes, run the following command:
@@ -191,6 +149,146 @@ To enable this redirection:
    sudo gitlab-ctl reconfigure
    ```
 
+### Debian/Ubuntu
+
+You can install and configure a PlantUML server in Debian/Ubuntu distributions
+using Tomcat or Jetty.
+
+Prerequisites:
+
+- JRE/JDK version 11 or later.
+- Apache Maven version 3.0.2 or later.
+- (Recommended) Jetty version 11 or later.
+- (Recommended) Tomcat version 10 or later.
+
+#### Installation
+
+PlantUML recommends to install Tomcat 10 or above. The scope of this page only
+includes setting up a basic Tomcat server. For more production-ready configurations,
+see the [Tomcat Documentation](https://tomcat.apache.org/tomcat-10.1-doc/index.html).
+
+1. Install JDK/JRE 11 and Maven:
+
+   ```shell
+   sudo apt update
+   sudo apt-get install graphviz default-jdk git-core maven
+   ```
+
+1. Add a user for Tomcat:
+
+   ```shell
+   sudo useradd -m -d /opt/tomcat -U -s /bin/false tomcat
+   ```
+
+1. Install and configure Tomcat 10:
+
+   ```shell
+   cd /tmp & wget https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.9/bin/apache-tomcat-10.1.9.tar.gz
+   sudo tar xzvf apache-tomcat-10*tar.gz -C /opt/tomcat --strip-components=1
+   sudo chown -R tomcat:tomcat /opt/tomcat/
+   sudo chmod -R u+x /opt/tomcat/bin
+   ```
+
+1. Create a systemd service. Edit the `/etc/systemd/system/tomcat.service` file and add:
+
+   ```shell
+   [Unit]
+   Description=Tomcat
+   After=network.target
+
+   [Service]
+   Type=forking
+
+   User=tomcat
+   Group=tomcat
+
+   Environment="JAVA_HOME=/usr/lib/jvm/java-1.11.0-openjdk-amd64"
+   Environment="JAVA_OPTS=-Djava.security.egd=file:///dev/urandom"
+   Environment="CATALINA_BASE=/opt/tomcat"
+   Environment="CATALINA_HOME=/opt/tomcat"
+   Environment="CATALINA_PID=/opt/tomcat/temp/tomcat.pid"
+   Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC"
+
+   ExecStart=/opt/tomcat/bin/startup.sh
+   ExecStop=/opt/tomcat/bin/shutdown.sh
+
+   RestartSec=10
+   Restart=always
+
+   [Install]
+   WantedBy=multi-user.target
+   ```
+
+   `JAVA_HOME` should be the same path as seen in `sudo update-java-alternatives -l`.
+
+1. To configure ports, edit your `/opt/tomcat/conf/server.xml` and choose your
+   ports. Avoid using port `8080`, as [Puma](../operations/puma.md) listens on port `8080` for metrics.
+
+   ```shell
+   <Server port="8006" shutdown="SHUTDOWN">
+   ...
+       <Connector port="8005" protocol="HTTP/1.1"
+   ...
+   ```
+
+1. Reload and start Tomcat:
+
+   ```shell
+   sudo systemctl daemon-reload
+   sudo systemctl start tomcat
+   sudo systemctl status tomcat
+   sudo systemctl enable tomcat
+   ```
+
+   The Java process should be listening on these ports:
+
+   ```shell
+   root@gitlab-omnibus:/plantuml-server# netstat -plnt | grep java
+   tcp6       0      0 127.0.0.1:8006          :::*                    LISTEN      14935/java
+   tcp6       0      0 :::8005                 :::*                    LISTEN      14935/java
+   ```
+
+1. Modify your NGINX configuration. The `proxy_pass` port matches the Connector port in the `server.xml`:
+
+   ```shell
+   nginx['custom_gitlab_server_config'] = "location /-/plantuml {
+       rewrite ^/-/(plantuml.*) /$1 break;
+       proxy_set_header  HOST               $host;
+       proxy_set_header  X-Forwarded-Host   $host;
+       proxy_set_header  X-Forwarded-Proto  $scheme;
+       proxy_cache off;
+       proxy_pass http://localhost:8005/plantuml;
+   }"
+   ```
+
+1. Reconfigure GitLab to read the new changes:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Install PlantUML and copy the `.war` file:
+
+   ```shell
+   cd / & git clone https://github.com/plantuml/plantuml-server.git
+   cd plantuml-server
+   mvn package
+   cp /plantuml-server/target/plantuml.war  /opt/tomcat/webapps/plantuml.war
+   chown tomcat:tomcat /opt/tomcat/webapps/plantuml.war
+   systemctl restart tomcat
+   ```
+
+The Tomcat service should restart. After the restart is complete, the
+PlantUML integration is ready and listening for requests on port `8005`:
+`http://localhost:8005/plantuml`
+
+To change the Tomcat defaults, edit the `/opt/tomcat/conf/server.xml` file.
+
+NOTE:
+The default URL is different when using this approach. The Docker-based image
+makes the service available at the root URL, with no relative path. Adjust
+the configuration below accordingly.
+
 ### Configure PlantUML security
 
 PlantUML has features that allow fetching network resources. If you self-host the
@@ -210,7 +308,8 @@ stop;
 After configuring your local PlantUML server, you're ready to enable the PlantUML integration:
 
 1. Sign in to GitLab as an [Administrator](../../user/permissions.md) user.
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, go to **Settings > General** and expand the **PlantUML** section.
 1. Select the **Enable PlantUML** checkbox.
 1. Set the PlantUML instance as `https://gitlab.example.com/-/plantuml/`,
@@ -221,7 +320,7 @@ these steps:
 
 - For PlantUML servers running v1.2020.9 and above, such as [plantuml.com](https://plantuml.com),
   you must set the `PLANTUML_ENCODING` environment variable to enable the `deflate`
-  compression. In Omnibus GitLab, you can set this value in `/etc/gitlab.rb` with
+  compression. In Linux package installations, you can set this value in `/etc/gitlab.rb` with
   this command:
 
   ```ruby
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md
index df9bb6b6e17..e5920520be7 100644
--- a/doc/administration/integration/terminal.md
+++ b/doc/administration/integration/terminal.md
@@ -87,16 +87,14 @@ it's safe to enable support for these headers globally. If you prefer a
 narrower set of rules, you can restrict it to URLs ending with `/terminal.ws`.
 This approach may still result in a few false positives.
 
-If you installed from source, or have made any configuration changes to your
-Omnibus installation before upgrading to 8.15, you may need to make some changes
-to your configuration. Read
+If you self-compiled your installation, you may need to make some changes to your configuration. Read
 [Upgrading Community Edition and Enterprise Edition from source](../../update/upgrading_from_source.md#nginx-configuration)
 for more details.
 
 To disable web terminal support in GitLab, stop passing
 the `Connection` and `Upgrade` hop-by-hop headers in the *first* HTTP reverse
 proxy in the chain. For most users, this is the NGINX server bundled with
-Omnibus GitLab, in which case, you need to:
+Linux package installations. In this case, you need to:
 
 - Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file
 - Ensure the whole block is uncommented, and then comment out or remove the
@@ -114,7 +112,7 @@ they receive a `Connection failed` message.
 By default, terminal sessions do not expire. To limit the terminal session
 lifetime in your GitLab instance:
 
-1. On the top bar, select **Main menu > Admin**.
-1. Select
-   [**Settings > Web terminal**](../../user/admin_area/settings/index.md#general).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select [**Settings > Web terminal**](../../user/admin_area/settings/index.md#general).
 1. Set a `max session time`.
diff --git a/doc/administration/lfs/index.md b/doc/administration/lfs/index.md
index ee5cd04f3d6..e4475e877d8 100644
--- a/doc/administration/lfs/index.md
+++ b/doc/administration/lfs/index.md
@@ -401,7 +401,7 @@ To delete these references:
 
 If you configure GitLab to [disable TLS v1.2](https://docs.gitlab.com/omnibus/settings/nginx.html)
 and only enable TLS v1.3 connections, LFS operations require a
-[Git LFS client](https://git-lfs.github.com) version 2.11.0 or later. If you use
+[Git LFS client](https://git-lfs.com/) version 2.11.0 or later. If you use
 a Git LFS client earlier than version 2.11.0, GitLab displays an error:
 
 ```plaintext
diff --git a/doc/administration/libravatar.md b/doc/administration/libravatar.md
index 802a3be46fa..1b7406546ef 100644
--- a/doc/administration/libravatar.md
+++ b/doc/administration/libravatar.md
@@ -25,7 +25,7 @@ You can use only the MD5 hash in the URL for the Libravatar service. See [issue
 In the [`gitlab.yml` gravatar section](https://gitlab.com/gitlab-org/gitlab/-/blob/68dac188ec6b1b03d53365e7579422f44cbe7a1c/config/gitlab.yml.example#L469-476), set
 the configuration options as follows:
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -39,7 +39,7 @@ the configuration options as follows:
 
 1. To apply the changes, run `sudo gitlab-ctl reconfigure`.
 
-**For installations from source**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml`:
 
@@ -57,12 +57,12 @@ the configuration options as follows:
 
 ## Set the Libravatar service to default (Gravatar)
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Delete `gitlab_rails['gravatar_ssl_url']` or `gitlab_rails['gravatar_plain_url']` from `/etc/gitlab/gitlab.rb`.
 1. To apply the changes, run `sudo gitlab-ctl reconfigure`.
 
-**For installations from source**
+For self-compiled installations:
 
 1. Remove `gravatar:` section from `config/gitlab.yml`.
 1. Save the file, then [restart](restart_gitlab.md#installations-from-source)
@@ -72,7 +72,7 @@ the configuration options as follows:
 
 To disable Gravatar, for example, to prohibit third-party services, complete the following steps:
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -82,7 +82,7 @@ To disable Gravatar, for example, to prohibit third-party services, complete the
 
 1. To apply the changes, run `sudo gitlab-ctl reconfigure`.
 
-**For installations from source**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml`:
 
diff --git a/doc/administration/logs/index.md b/doc/administration/logs/index.md
index 7fab97f76da..8dcb25e22df 100644
--- a/doc/administration/logs/index.md
+++ b/doc/administration/logs/index.md
@@ -14,7 +14,7 @@ This guide talks about how to read and use these system log files.
 
 Read more about the log system and using the logs:
 
-- [Customize logging on Omnibus GitLab installations](https://docs.gitlab.com/omnibus/settings/logs.html)
+- [Customize logging on Linux package installations](https://docs.gitlab.com/omnibus/settings/logs.html)
 including adjusting log retention, log forwarding,
 switching logs from JSON to plain text logging, and more.
 - [How to parse and analyze JSON logs](../logs/log_parsing.md).
@@ -88,7 +88,7 @@ except those captured by `runit`.
 | [Alertmanager logs](#alertmanager-logs)         | **{dotted-circle}** No  | **{check-circle}** Yes  |
 | [crond logs](#crond-logs)                       | **{dotted-circle}** No  | **{check-circle}** Yes  |
 | [Gitaly](#gitaly-logs)                          | **{check-circle}** Yes  | **{check-circle}** Yes  |
-| [GitLab Exporter for Omnibus](#gitlab-exporter) | **{dotted-circle}** No  | **{check-circle}** Yes  |
+| [GitLab Exporter for Linux package installations](#gitlab-exporter) | **{dotted-circle}** No  | **{check-circle}** Yes  |
 | [GitLab Pages logs](#pages-logs)                | **{check-circle}** Yes  | **{check-circle}** Yes  |
 | GitLab Rails                                    | **{check-circle}** Yes  | **{dotted-circle}** No  |
 | [GitLab Shell logs](#gitlab-shelllog)           | **{check-circle}** Yes  | **{dotted-circle}** No  |
@@ -107,10 +107,10 @@ except those captured by `runit`.
 
 ## `production_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/production_json.log`
-- Installations from source: `/home/git/gitlab/log/production_json.log`
+- `/var/log/gitlab/gitlab-rails/production_json.log` on Linux package installations.
+- `/home/git/gitlab/log/production_json.log` on self-compiled installations.
 
 It contains a structured log for Rails controller requests received from
 GitLab, thanks to [Lograge](https://github.com/roidrage/lograge/).
@@ -264,10 +264,10 @@ Starting with GitLab 12.5, if an error occurs, an
 
 ## `production.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/production.log`
-- Installations from source: `/home/git/gitlab/log/production.log`
+- `/var/log/gitlab/gitlab-rails/production.log` on Linux package installations.
+- `/home/git/gitlab/log/production.log` on self-compiled installations.
 
 It contains information about all performed requests. You can see the
 URL and type of request, IP address, and what parts of code were
@@ -300,10 +300,10 @@ The request was processed by `Projects::TreeController`.
 
 ## `api_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/api_json.log`
-- Installations from source: `/home/git/gitlab/log/api_json.log`
+- `/var/log/gitlab/gitlab-rails/api_json.log` on Linux package installations.
+- `/home/git/gitlab/log/api_json.log` on self-compiled installations.
 
 It helps you see requests made directly to the API. For example:
 
@@ -354,10 +354,10 @@ process on Redis or external HTTP, not only the serialization process.
 
 > [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111046) in GitLab 15.10.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/application.log`
-- Installations from source: `/home/git/gitlab/log/application.log`
+- `/var/log/gitlab/gitlab-rails/application.log` on Linux package installations.
+- `/home/git/gitlab/log/application.log` on self-compiled installations.
 
 It contains a less structured version of the logs in
 [`application_json.log`](#application_jsonlog), like this example:
@@ -374,10 +374,10 @@ October 07, 2014 11:25: Project "project133" was removed
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22812) in GitLab 12.7.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/application_json.log`
-- Installations from source: `/home/git/gitlab/log/application_json.log`
+- `/var/log/gitlab/gitlab-rails/application_json.log` on Linux package installations.
+- `/home/git/gitlab/log/application_json.log` on self-compiled installations.
 
 It helps you discover events happening in your instance such as user creation
 and project deletion. For example:
@@ -399,10 +399,10 @@ and project deletion. For example:
 
 ## `integrations_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/integrations_json.log`
-- Installations from source: `/home/git/gitlab/log/integrations_json.log`
+- `/var/log/gitlab/gitlab-rails/integrations_json.log` on Linux package installations.
+- `/home/git/gitlab/log/integrations_json.log` on self-compiled installations.
 
 It contains information about [integration](../../user/project/integrations/index.md)
 activities, such as Jira, Asana, and irker services. It uses JSON format,
@@ -434,19 +434,19 @@ like this example:
 
 > [Deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/kubernetes.log`
-- Installations from source: `/home/git/gitlab/log/kubernetes.log`
+- `/var/log/gitlab/gitlab-rails/kubernetes.log` on Linux package installations.
+- `/home/git/gitlab/log/kubernetes.log` on self-compiled installations.
 
 It logs information related to [certificate-based clusters](../../user/project/clusters/index.md), such as connectivity errors. Each line contains JSON that can be ingested by services like Elasticsearch and Splunk.
 
 ## `git_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/git_json.log`
-- Installations from source: `/home/git/gitlab/log/git_json.log`
+- `/var/log/gitlab/gitlab-rails/git_json.log` on Linux package installations.
+- `/home/git/gitlab/log/git_json.log` on self-compiled installations.
 
 After GitLab version 12.2, this file was renamed from `githost.log` to
 `git_json.log` and stored in JSON format.
@@ -472,10 +472,10 @@ NOTE:
 GitLab Free tracks a small number of different audit events.
 GitLab Premium tracks many more.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/audit_json.log`
-- Installations from source: `/home/git/gitlab/log/audit_json.log`
+- `/var/log/gitlab/gitlab-rails/audit_json.log` on Linux package installations.
+- `/home/git/gitlab/log/audit_json.log` on self-compiled installations.
 
 Changes to group or project settings and memberships (`target_details`)
 are logged to this file. For example:
@@ -499,18 +499,15 @@ are logged to this file. For example:
 
 ## Sidekiq logs
 
-NOTE:
-In Omnibus GitLab `12.10` or earlier, the Sidekiq log is at `/var/log/gitlab/gitlab-rails/sidekiq.log`.
-
-For Omnibus GitLab installations, some Sidekiq logs are in `/var/log/gitlab/sidekiq/current`
+For Linux package installations, some Sidekiq logs are in `/var/log/gitlab/sidekiq/current`
 and as follows.
 
 ### `sidekiq.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/sidekiq/current`
-- Installations from source: `/home/git/gitlab/log/sidekiq.log`
+- `/var/log/gitlab/sidekiq/current` on Linux package installations.
+- `/home/git/gitlab/log/sidekiq.log` on self-compiled installations.
 
 GitLab uses background jobs for processing tasks which can take a long
 time. All information about processing these jobs are written down to
@@ -549,7 +546,7 @@ Sidekiq. For example:
 }
 ```
 
-For Omnibus GitLab installations, add the configuration option:
+For Linux package installations, add the configuration option:
 
 ```ruby
 sidekiq['log_format'] = 'json'
@@ -568,10 +565,10 @@ For installations from source, edit the `gitlab.yml` and set the Sidekiq
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26586) in GitLab 12.9.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/sidekiq_client.log`
-- Installations from source: `/home/git/gitlab/log/sidekiq_client.log`
+- `/var/log/gitlab/gitlab-rails/sidekiq_client.log` on Linux package installations.
+- `/home/git/gitlab/log/sidekiq_client.log` on self-compiled installations.
 
 This file contains logging information about jobs before Sidekiq starts
 processing them, such as before being enqueued.
@@ -585,8 +582,6 @@ you've configured this for Sidekiq as mentioned above.
 GitLab Shell is used by GitLab for executing Git commands and provide SSH
 access to Git repositories.
 
-### For GitLab versions 12.10 and up
-
 Information containing `git-{upload-pack,receive-pack}` requests is at
 `/var/log/gitlab/gitlab-shell/gitlab-shell.log`. Information about hooks to
 GitLab Shell from Gitaly is at `/var/log/gitlab/gitaly/current`.
@@ -640,55 +635,18 @@ Example log entries for `/var/log/gitlab/gitaly/current`:
 }
 ```
 
-### For GitLab versions 12.5 through 12.9
-
-For GitLab 12.5 to 12.9, depending on your installation method, this
-file is located at:
-
-- Omnibus GitLab: `/var/log/gitlab/gitaly/gitlab-shell.log`
-- Installation from source: `/home/git/gitaly/gitlab-shell.log`
-
-Example log entries:
-
-```json
-{
-  "method": "POST",
-  "url": "http://127.0.0.1:8080/api/v4/internal/post_receive",
-  "duration": 0.031809164,
-  "gitaly_embedded": true,
-  "pid": 27056,
-  "level": "info",
-  "msg": "finished HTTP request",
-  "time": "2020-04-17T16:24:38+00:00"
-}
-```
-
-### For GitLab 12.5 and earlier
-
-For GitLab 12.5 and earlier, the file is at `/var/log/gitlab/gitlab-shell/gitlab-shell.log`.
-
-Example log entries:
-
-```plaintext
-I, [2015-02-13T06:17:00.671315 #9291]  INFO -- : Adding project root/example.git at </var/opt/gitlab/git-data/repositories/root/dcdcdcdcd.git>.
-I, [2015-02-13T06:17:00.679433 #9291]  INFO -- : Moving existing hooks directory and symlinking global hooks directory for /var/opt/gitlab/git-data/repositories/root/example.git.
-```
-
-User clone/fetch activity using SSH transport appears in this log as
-`executing git command <gitaly-upload-pack...`.
-
 ## Gitaly logs
 
 This file is in `/var/log/gitlab/gitaly/current` and is produced by [runit](http://smarden.org/runit/).
-`runit` is packaged with Omnibus GitLab and a brief explanation of its purpose
-is available [in the Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/architecture/#runit).
+`runit` is packaged with the Linux package and a brief explanation of its purpose
+is available [in the Linux package documentation](https://docs.gitlab.com/omnibus/architecture/#runit).
 [Log files are rotated](http://smarden.org/runit/svlogd.8.html), renamed in
 Unix timestamp format, and `gzip`-compressed (like `@1584057562.s`).
 
 ### `grpc.log`
 
-This file is at `/var/log/gitlab/gitlab-rails/grpc.log` for Omnibus GitLab
-packages. Native [gRPC](https://grpc.io/) logging used by Gitaly.
+This file is at `/var/log/gitlab/gitlab-rails/grpc.log` for Linux
+package installations. Native [gRPC](https://grpc.io/) logging used by Gitaly.
 
 ### `gitaly_hooks.log`
 
@@ -700,34 +658,34 @@ failures received during processing of the responses from GitLab API.
 
 ### `puma_stdout.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/puma/puma_stdout.log`
-- Installations from source: `/home/git/gitlab/log/puma_stdout.log`
+- `/var/log/gitlab/puma/puma_stdout.log` on Linux package installations.
+- `/home/git/gitlab/log/puma_stdout.log` on self-compiled installations.
 
 ### `puma_stderr.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/puma/puma_stderr.log`
-- Installations from source: `/home/git/gitlab/log/puma_stderr.log`
+- `/var/log/gitlab/puma/puma_stderr.log` on Linux package installations.
+- `/home/git/gitlab/log/puma_stderr.log` on self-compiled installations.
 
 ## `repocheck.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/repocheck.log`
-- Installations from source: `/home/git/gitlab/log/repocheck.log`
+- `/var/log/gitlab/gitlab-rails/repocheck.log` on Linux package installations.
+- `/home/git/gitlab/log/repocheck.log` on self-compiled installations.
 
 It logs information whenever a [repository check is run](../repository_checks.md)
 on a project.
 
 ## `importer.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/importer.log`
-- Installations from source: `/home/git/gitlab/log/importer.log`
+- `/var/log/gitlab/gitlab-rails/importer.log` on Linux package installations.
+- `/home/git/gitlab/log/importer.log` on self-compiled installations.
 
 This file logs the progress of [project imports and migrations](../../user/project/import/index.md).
 
@@ -735,10 +693,10 @@ This file logs the progress of [project imports and migrations](../../user/proje
 
 > Introduced in GitLab 13.1.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/exporter.log`
-- Installations from source: `/home/git/gitlab/log/exporter.log`
+- `/var/log/gitlab/gitlab-rails/exporter.log` on Linux package installations.
+- `/home/git/gitlab/log/exporter.log` on self-compiled installations.
 
 It logs the progress of the export process.
 
@@ -746,10 +704,10 @@ It logs the progress of the export process.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/59587) in GitLab 13.7.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/features_json.log`
-- Installations from source: `/home/git/gitlab/log/features_json.log`
+- `/var/log/gitlab/gitlab-rails/features_json.log` on Linux package installations.
+- `/home/git/gitlab/log/features_json.log` on self-compiled installations.
 
 The modification events from [Feature flags in development of GitLab](../../development/feature_flags/index.md)
 are recorded in this file. For example:
@@ -771,10 +729,10 @@ are recorded in this file. For example:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/384180) in GitLab 15.9.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/ci_resource_group_json.log`
-- Installations from source: `/home/git/gitlab/log/ci_resource_group_json.log`
+- `/var/log/gitlab/gitlab-rails/ci_resource_group_json.log` on Linux package installations.
+- `/home/git/gitlab/log/ci_resource_group_json.log` on self-compiled installations.
 
 It contains information about [resource group](../../ci/resource_groups/index.md) acquisition. For example:
 
@@ -789,10 +747,10 @@ The examples show the `resource_group_id`, `processable_id`, `message`, and `suc
 
 > Introduced in GitLab 12.0.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/auth.log`
-- Installations from source: `/home/git/gitlab/log/auth.log`
+- `/var/log/gitlab/gitlab-rails/auth.log` on Linux package installations.
+- `/home/git/gitlab/log/auth.log` on self-compiled installations.
 
 This log records:
 
@@ -803,10 +761,10 @@ This log records:
 
 ## `auth_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/auth_json.log`
-- Installations from source: `/home/git/gitlab/log/auth_json.log`
+- `/var/log/gitlab/gitlab-rails/auth_json.log` on Linux package installations.
+- `/home/git/gitlab/log/auth_json.log` on self-compiled installations.
 
 This file contains the JSON version of the logs in `auth.log`, for example:
 
@@ -827,10 +785,10 @@ This file contains the JSON version of the logs in `auth.log`, for example:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/59587) in GitLab 12.0.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/graphql_json.log`
-- Installations from source: `/home/git/gitlab/log/graphql_json.log`
+- `/var/log/gitlab/gitlab-rails/graphql_json.log` on Linux package installations.
+- `/home/git/gitlab/log/graphql_json.log` on self-compiled installations.
 
 GraphQL queries are recorded in the file. For example:
 
@@ -842,10 +800,10 @@ GraphQL queries are recorded in the file. For example:
 
 > Introduced in GitLab 12.3.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/migrations.log`
-- Installations from source: `/home/git/gitlab/log/migrations.log`
+- `/var/log/gitlab/gitlab-rails/migrations.log` on Linux package installations.
+- `/home/git/gitlab/log/migrations.log` on self-compiled installations.
 
 This file logs the progress of [database migrations](../raketasks/maintenance.md#display-status-of-database-migrations).
 
@@ -853,19 +811,19 @@ This file logs the progress of [database migrations](../raketasks/maintenance.md
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/19186) in GitLab 12.6.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/mailroom/current`
-- Installations from source: `/home/git/gitlab/log/mail_room_json.log`
+- `/var/log/gitlab/mailroom/current` on Linux package installations.
+- `/home/git/gitlab/log/mail_room_json.log` on self-compiled installations.
 
 This structured log file records internal activity in the `mail_room` gem.
 Its name and path are configurable, so the name and path may not match the above.
 
 ## Reconfigure logs
 
-Reconfigure log files are in `/var/log/gitlab/reconfigure` for Omnibus GitLab
-packages. Installations from source don't have reconfigure logs. A reconfigure log
-is populated whenever `gitlab-ctl reconfigure` is run manually or as part of an upgrade.
+Reconfigure log files are in `/var/log/gitlab/reconfigure` for Linux package installations. Self-compiled installations
+don't have reconfigure logs. A reconfigure log is populated whenever `gitlab-ctl reconfigure` is run manually or as part
+of an upgrade.
 
 Reconfigure logs files are named according to the UNIX timestamp of when the reconfigure
 was initiated, such as `1509705644.log`
@@ -875,34 +833,32 @@ was initiated, such as `1509705644.log`
 If Prometheus metrics and the Sidekiq Exporter are both enabled, Sidekiq
 starts a Web server and listen to the defined port (default:
 `8082`). By default, Sidekiq Exporter access logs are disabled but can
-be enabled based on your installation method:
+be enabled:
 
-- Omnibus GitLab: Use the `sidekiq['exporter_log_enabled'] = true`
-  option in `/etc/gitlab/gitlab.rb`
-- Installations from source: Use the `sidekiq_exporter.log_enabled` option
-  in `gitlab.yml`
+- Use the `sidekiq['exporter_log_enabled'] = true` option in `/etc/gitlab/gitlab.rb` on Linux package installations.
+- Use the `sidekiq_exporter.log_enabled` option in `gitlab.yml` on self-compiled installations.
 
 When enabled, depending on your installation method, this file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/sidekiq_exporter.log`
-- Installations from source: `/home/git/gitlab/log/sidekiq_exporter.log`
+- `/var/log/gitlab/gitlab-rails/sidekiq_exporter.log` on Linux package installations.
+- `/home/git/gitlab/log/sidekiq_exporter.log` on self-compiled installations.
 
 If Prometheus metrics and the Web Exporter are both enabled, Puma
 starts a Web server and listen to the defined port (default: `8083`), and access logs
 are generated in a location based on your installation method:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/web_exporter.log`
-- Installations from source: `/home/git/gitlab/log/web_exporter.log`
+- `/var/log/gitlab/gitlab-rails/web_exporter.log` on Linux package installations.
+- `/home/git/gitlab/log/web_exporter.log` on self-compiled installations.
 
 ## `database_load_balancing.log` **(PREMIUM SELF)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/15442) in GitLab 12.3.
 
 Contains details of GitLab [Database Load Balancing](../postgresql/database_load_balancing.md).
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/database_load_balancing.log`
-- Installations from source: `/home/git/gitlab/log/database_load_balancing.log`
+- `/var/log/gitlab/gitlab-rails/database_load_balancing.log` on Linux package installations.
+- `/home/git/gitlab/log/database_load_balancing.log` on self-compiled installations.
 
 ## `zoekt.log` **(PREMIUM SELF)**
 
@@ -912,21 +868,20 @@ This file logs information related to the
 [Exact code search](../../user/search/exact_code_search.md) feature which is
 powered by Zoekt.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/zoekt.log`
-- Installations from source: `/home/git/gitlab/log/zoekt.log`
+- `/var/log/gitlab/gitlab-rails/zoekt.log` on Linux package installations.
+- `/home/git/gitlab/log/zoekt.log` on self-compiled installations.
 
 ## `elasticsearch.log` **(PREMIUM SELF)**
 
 > Introduced in GitLab 12.6.
 
 This file logs information related to the Elasticsearch Integration, including
-errors during indexing or searching Elasticsearch. Depending on your installation
-method, this file is located at:
+errors during indexing or searching Elasticsearch. This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/elasticsearch.log`
-- Installations from source: `/home/git/gitlab/log/elasticsearch.log`
+- `/var/log/gitlab/gitlab-rails/elasticsearch.log` on Linux package installations.
+- `/home/git/gitlab/log/elasticsearch.log` on self-compiled installations.
 
 Each line contains JSON that can be ingested by services like Elasticsearch and Splunk.
 Line breaks have been added to the following example line for clarity:
@@ -952,10 +907,10 @@ Line breaks have been added to the following example line for clarity:
 This file logs the information about exceptions being tracked by
 `Gitlab::ErrorTracking`, which provides a standard and consistent way of
 [processing rescued exceptions](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/logging.md#exception-handling).
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/exceptions_json.log`
-- Installations from source: `/home/git/gitlab/log/exceptions_json.log`
+- `/var/log/gitlab/gitlab-rails/exceptions_json.log` on Linux package installations.
+- `/home/git/gitlab/log/exceptions_json.log` on self-compiled installations.
 
 Each line contains JSON that can be ingested by Elasticsearch. For example:
 
@@ -980,10 +935,10 @@ Each line contains JSON that can be ingested by Elasticsearch. For example:
 
 > Introduced in GitLab 13.0.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/service_measurement.log`
-- Installations from source: `/home/git/gitlab/log/service_measurement.log`
+- `/var/log/gitlab/gitlab-rails/service_measurement.log` on Linux package installations.
+- `/home/git/gitlab/log/service_measurement.log` on self-compiled installations.
 
 It contains only a single structured log with measurements for each service execution.
 It contains measurements such as the number of SQL calls, `execution_time`, `gc_stats`, and `memory usage`.
@@ -1013,10 +968,10 @@ This message shows that Geo detected that a repository update was needed for pro
 
 ## `update_mirror_service_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/update_mirror_service_json.log`
-- Installations from source: `/home/git/gitlab/log/update_mirror_service_json.log`
+- `/var/log/gitlab/gitlab-rails/update_mirror_service_json.log` on Linux package installations.
+- `/home/git/gitlab/log/update_mirror_service_json.log` on self-compiled installations.
 
 This file contains information about LFS errors that occurred during project mirroring.
 While we work to move other project mirroring errors into this log, the [general log](#productionlog)
@@ -1034,13 +989,25 @@ can be used.
 }
 ```
 
+## `llm.log` **(ULTIMATE SAAS)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120506) in GitLab 16.0.
+
+The `llm.log` file logs information related to
+[AI features](../../user/ai_features.md).
+
+This file is located at:
+
+- `/var/log/gitlab/gitlab-rails/llm.log` on Linux package installations.
+- `/home/git/gitlab/log/llm.log` on self-compiled installations.
+
 ## Registry logs
 
-For Omnibus GitLab installations, Container Registry logs are in `/var/log/gitlab/registry/current`.
+For Linux package installations, Container Registry logs are in `/var/log/gitlab/registry/current`.
 
 ## NGINX logs
 
-For Omnibus GitLab installations, NGINX logs are in:
+For Linux package installations, NGINX logs are in:
 
 - `/var/log/gitlab/nginx/gitlab_access.log`: A log of requests made to GitLab
 - `/var/log/gitlab/nginx/gitlab_error.log`: A log of NGINX errors for GitLab
@@ -1063,7 +1030,7 @@ for sensitive query string parameters such as secret tokens.
 
 ## Pages logs
 
-For Omnibus GitLab installations, Pages logs are in `/var/log/gitlab/gitlab-pages/current`.
+For Linux package installations, Pages logs are in `/var/log/gitlab/gitlab-pages/current`.
 
 For example:
 
@@ -1092,67 +1059,67 @@ For example:
 
 ## Mattermost logs
 
-For Omnibus GitLab installations, Mattermost logs are in these locations:
+For Linux package installations, Mattermost logs are in these locations:
 
 - `/var/log/gitlab/mattermost/mattermost.log`
 - `/var/log/gitlab/mattermost/current`
 
 ## Workhorse logs
 
-For Omnibus GitLab installations, Workhorse logs are in `/var/log/gitlab/gitlab-workhorse/current`.
+For Linux package installations, Workhorse logs are in `/var/log/gitlab/gitlab-workhorse/current`.
 
 ## PgBouncer logs
 
-For Omnibus GitLab installations, PgBouncer logs are in `/var/log/gitlab/pgbouncer/current`.
+For Linux package installations, PgBouncer logs are in `/var/log/gitlab/pgbouncer/current`.
 
 ## PostgreSQL logs
 
-For Omnibus GitLab installations, PostgreSQL logs are in `/var/log/gitlab/postgresql/current`.
+For Linux package installations, PostgreSQL logs are in `/var/log/gitlab/postgresql/current`.
 
 ## Prometheus logs
 
-For Omnibus GitLab installations, Prometheus logs are in `/var/log/gitlab/prometheus/current`.
+For Linux package installations, Prometheus logs are in `/var/log/gitlab/prometheus/current`.
 
 ## Redis logs
 
-For Omnibus GitLab installations, Redis logs are in `/var/log/gitlab/redis/current`.
+For Linux package installations, Redis logs are in `/var/log/gitlab/redis/current`.
 
 ## Alertmanager logs
 
-For Omnibus GitLab installations, Alertmanager logs are in `/var/log/gitlab/alertmanager/current`.
+For Linux package installations, Alertmanager logs are in `/var/log/gitlab/alertmanager/current`.
 
 <!-- vale gitlab.Spelling = NO -->
 
 ## crond logs
 
-For Omnibus GitLab installations, crond logs are in `/var/log/gitlab/crond/`.
+For Linux package installations, crond logs are in `/var/log/gitlab/crond/`.
 
 <!-- vale gitlab.Spelling = YES -->
 
 ## Grafana logs
 
-For Omnibus GitLab installations, Grafana logs are in `/var/log/gitlab/grafana/current`.
+For Linux package installations, Grafana logs are in `/var/log/gitlab/grafana/current`.
 
 ## LogRotate logs
 
-For Omnibus GitLab installations, `logrotate` logs are in `/var/log/gitlab/logrotate/current`.
+For Linux package installations, `logrotate` logs are in `/var/log/gitlab/logrotate/current`.
 
 ## GitLab Monitor logs
 
-For Omnibus GitLab installations, GitLab Monitor logs are in `/var/log/gitlab/gitlab-monitor/`.
+For Linux package installations, GitLab Monitor logs are in `/var/log/gitlab/gitlab-monitor/`.
 
 ## GitLab Exporter
 
-For Omnibus GitLab installations, GitLab Exporter logs are in `/var/log/gitlab/gitlab-exporter/current`.
+For Linux package installations, GitLab Exporter logs are in `/var/log/gitlab/gitlab-exporter/current`.
 
 ## GitLab agent server
 
-For Omnibus GitLab installations, GitLab agent server logs are
+For Linux package installations, GitLab agent server logs are
 in `/var/log/gitlab/gitlab-kas/current`.
 
 ## Praefect logs
 
-For Omnibus GitLab installations, Praefect logs are in `/var/log/gitlab/praefect/`.
+For Linux package installations, Praefect logs are in `/var/log/gitlab/praefect/`.
 
 GitLab also tracks [Prometheus metrics for Praefect](../gitaly/monitoring.md#monitor-gitaly-cluster).
 
@@ -1168,10 +1135,10 @@ This log is populated when a [GitLab backup is created](../../raketasks/backup_r
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48149) in GitLab 13.7.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/performance_bar_json.log`
-- Installations from source: `/home/git/gitlab/log/performance_bar_json.log`
+- `/var/log/gitlab/gitlab-rails/performance_bar_json.log` on Linux package installations.
+- `/home/git/gitlab/log/performance_bar_json.log` on self-compiled installations.
 
 Performance bar statistics (currently only duration of SQL queries) are recorded
 in that file. For example:
diff --git a/doc/administration/logs/log_parsing.md b/doc/administration/logs/log_parsing.md
index d9520ea9bc0..21ce3d7f17f 100644
--- a/doc/administration/logs/log_parsing.md
+++ b/doc/administration/logs/log_parsing.md
@@ -24,7 +24,7 @@ include use cases targeted for parsing GitLab log files.
 ## Parsing Logs
 
 The examples listed below address their respective log files by
-their relative Omnibus paths and default filenames.
+their relative Linux package installation paths and default filenames.
 Find the respective full paths in the [GitLab logs sections](../logs/index.md#production_jsonlog).
 
 ### General Commands
diff --git a/doc/administration/maintenance_mode/index.md b/doc/administration/maintenance_mode/index.md
index 8347015a8a3..3bbebe7ecce 100644
--- a/doc/administration/maintenance_mode/index.md
+++ b/doc/administration/maintenance_mode/index.md
@@ -21,7 +21,8 @@ Maintenance Mode allows most external actions that do not change internal state.
 Enable Maintenance Mode as an administrator in one of these ways:
 
 - **Web UI**:
-  1. On the top bar, select **Main menu > Admin**.
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
   1. On the left sidebar, select **Settings > General**.
   1. Expand **Maintenance Mode**, and toggle **Enable Maintenance Mode**.
      You can optionally add a message for the banner as well.
@@ -45,7 +46,8 @@ Enable Maintenance Mode as an administrator in one of these ways:
 Disable Maintenance Mode in one of three ways:
 
 - **Web UI**:
-  1. On the top bar, select **Main menu > Admin**.
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
   1. On the left sidebar, select **Settings > General**.
   1. Expand **Maintenance Mode**, and toggle **Enable Maintenance Mode**.
      You can optionally add a message for the banner as well.
@@ -173,7 +175,8 @@ you should disable all cron jobs except for those related to Geo.
 
 To monitor queues and disable jobs:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Monitoring > Background Jobs**.
 
 ### Incident management
diff --git a/doc/administration/merge_request_diffs.md b/doc/administration/merge_request_diffs.md
index 3250a2339e2..00ea1e43600 100644
--- a/doc/administration/merge_request_diffs.md
+++ b/doc/administration/merge_request_diffs.md
@@ -21,7 +21,7 @@ that only [stores outdated diffs](#alternative-in-database-storage) outside of d
 
 ## Using external storage
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -38,10 +38,10 @@ that only [stores outdated diffs](#alternative-in-database-storage) outside of d
    gitlab_rails['external_diffs_storage_path'] = "/mnt/storage/external-diffs"
    ```
 
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
    GitLab then migrates your existing merge request diffs to external storage.
 
-**In installations from source:**
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
@@ -74,7 +74,7 @@ Instead of storing the external diffs on disk, we recommended the use of an obje
 store like AWS S3 instead. This configuration relies on valid AWS credentials to
 be configured already.
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -83,10 +83,10 @@ be configured already.
    ```
 
 1. Set [object storage settings](#object-storage-settings).
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
    GitLab then migrates your existing merge request diffs to external storage.
 
-**In installations from source:**
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
@@ -109,7 +109,7 @@ In GitLab 13.2 and later, you should use the
 This section describes the earlier configuration format.
 
 For source installations, these settings are nested under `external_diffs:` and
-then `object_store:`. On Omnibus installations, they are prefixed by
+then `object_store:`. On Linux package installations, they are prefixed by
 `external_diffs_object_store_`.
 
 | Setting | Description | Default |
@@ -123,7 +123,7 @@ then `object_store:`. On Omnibus installations, they are prefixed by
 
 See [the available connection settings for different providers](object_storage.md#configure-the-connection-settings).
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following lines by replacing with
    the values you want:
@@ -151,9 +151,9 @@ See [the available connection settings for different providers](object_storage.m
    }
    ```
 
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
-**In installations from source:**
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
@@ -182,7 +182,7 @@ in the database.
 
 To enable this feature, perform the following steps:
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -190,9 +190,9 @@ To enable this feature, perform the following steps:
    gitlab_rails['external_diffs_when'] = 'outdated'
    ```
 
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
-**In installations from source:**
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
@@ -236,13 +236,13 @@ Then you are affected by this issue. Because it's not possible to safely determi
 all these conditions automatically, we've provided a Rake task in GitLab v13.2.0
 that you can run manually to correct the data:
 
-**In Omnibus installations:**
+For Linux package installations:
 
 ```shell
 sudo gitlab-rake gitlab:external_diffs:force_object_storage
 ```
 
-**In installations from source:**
+For self-compiled installations:
 
 ```shell
 sudo -u git -H bundle exec rake gitlab:external_diffs:force_object_storage RAILS_ENV=production
diff --git a/doc/administration/monitoring/ip_allowlist.md b/doc/administration/monitoring/ip_allowlist.md
index 94d6876b16f..72640cd6218 100644
--- a/doc/administration/monitoring/ip_allowlist.md
+++ b/doc/administration/monitoring/ip_allowlist.md
@@ -20,7 +20,7 @@ hosts or use IP ranges:
    gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
    ```
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation) GitLab for the changes to take effect.
 
 ---
 
diff --git a/doc/administration/monitoring/performance/gitlab_configuration.md b/doc/administration/monitoring/performance/gitlab_configuration.md
index cb5852a7dac..0d2037f3a92 100644
--- a/doc/administration/monitoring/performance/gitlab_configuration.md
+++ b/doc/administration/monitoring/performance/gitlab_configuration.md
@@ -9,7 +9,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 GitLab Performance Monitoring is disabled by default. To enable it and change any of its
 settings:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Metrics and profiling**
   (`/admin/application_settings/metrics_and_profiling`).
 1. Add the necessary configuration changes.
diff --git a/doc/administration/monitoring/performance/grafana_configuration.md b/doc/administration/monitoring/performance/grafana_configuration.md
index 1113dcfef32..b448ac461c8 100644
--- a/doc/administration/monitoring/performance/grafana_configuration.md
+++ b/doc/administration/monitoring/performance/grafana_configuration.md
@@ -14,7 +14,7 @@ For more information, see [deprecation notes](#deprecation-of-bundled-grafana).
 
 [Grafana](https://grafana.com/) is a tool that enables you to visualize time
 series metrics through graphs and dashboards. GitLab writes performance data to Prometheus,
-and Grafana allows you to query the data to display useful graphs.
+and Grafana allows you to query the data to display graphs.
 
 ## Deprecation of bundled Grafana
 
@@ -30,29 +30,22 @@ To switch away from bundled Grafana to a newer version of Grafana from Grafana L
 1. Set up a version of Grafana from Grafana Labs.
 1. [Export the existing dashboards](https://grafana.com/docs/grafana/latest/dashboards/manage-dashboards/#export-a-dashboard) from bundled Grafana.
 1. [Import the existing dashboards](https://grafana.com/docs/grafana/latest/dashboards/manage-dashboards/#import-a-dashboard) in the new Grafana instance.
-1. [Configure GitLab](#integration-with-gitlab-ui) to use the new Grafana instance.
+1. [Configure GitLab](#integrate-with-gitlab-ui) to use the new Grafana instance.
 
 ### Temporary workaround
 
 In GitLab versions 16.0 to 16.2, you can still force Omnibus GitLab to enable and configure Grafana by setting the following:
 
 - `grafana['enable'] = true`.
-- `grafana['enable_deprecated_service'] = true`. 
- 
-You see a deprecation message when reconfiguring GitLab.
+- `grafana['enable_deprecated_service'] = true`.
 
-## Installation
+You see a deprecation message when reconfiguring GitLab.
 
-Omnibus GitLab can [help you install Grafana (recommended)](https://docs.gitlab.com/omnibus/settings/grafana.html)
-or Grafana supplies package repositories (Yum/Apt) for easy installation.
-See [Grafana installation documentation](https://grafana.com/docs/grafana/latest/setup-grafana/installation/)
-for detailed steps.
+## Configure Grafana
 
-Before starting Grafana for the first time, set the administration user
-and password in `/etc/grafana/grafana.ini`. If you don't, the default password
-is `admin`.
+Prerequisites:
 
-## Configuration
+- Grafana installed.
 
 1. Log in to Grafana as the administration user.
 1. Select **Data Sources** from the **Configuration** menu.
@@ -62,9 +55,9 @@ is `admin`.
 
 Grafana should indicate the data source is working.
 
-## Import Dashboards
+## Import dashboards
 
-You can now import a set of default dashboards to start displaying useful information.
+You can now import a set of default dashboards to start displaying information.
 GitLab has published a set of default
 [Grafana dashboards](https://gitlab.com/gitlab-org/grafana-dashboards) to get you started. To use
 them:
@@ -86,14 +79,15 @@ instance. For more information about this process, see the
 [README of the Grafana dashboards](https://gitlab.com/gitlab-org/grafana-dashboards)
 repository.
 
-## Integration with GitLab UI
+## Integrate with GitLab UI
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/61005) in GitLab 12.1.
 
-After setting up Grafana, you can enable a link to access it easily from the
+After setting up Grafana, you can enable a link to access it from the
 GitLab sidebar:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Metrics and profiling**
    and expand **Metrics - Grafana**.
 1. Select the **Add a link to Grafana** checkbox.
@@ -129,7 +123,7 @@ configuration screen:
 > prior to 13.10, the API scope:
 >
 > - Is required to access Grafana through the GitLab OAuth provider.
-> - Is set by enabling the Grafana application as shown in [Integration with GitLab UI](#integration-with-gitlab-ui).
+> - Is set by enabling the Grafana application as shown in [Integration with GitLab UI](#integrate-with-gitlab-ui).
 
 ## Security Update
 
diff --git a/doc/administration/monitoring/performance/performance_bar.md b/doc/administration/monitoring/performance/performance_bar.md
index fc6318922f1..3fdd4c24177 100644
--- a/doc/administration/monitoring/performance/performance_bar.md
+++ b/doc/administration/monitoring/performance/performance_bar.md
@@ -108,7 +108,8 @@ The performance bar is disabled by default for non-administrators. To enable it
 for a given group:
 
 1. Sign in as a user with administrator access.
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Metrics and profiling**
    (`admin/application_settings/metrics_and_profiling`), and expand
    **Profiling - Performance bar**.
diff --git a/doc/administration/monitoring/prometheus/gitlab_exporter.md b/doc/administration/monitoring/prometheus/gitlab_exporter.md
index 1f4156349c5..0bd13fe5a87 100644
--- a/doc/administration/monitoring/prometheus/gitlab_exporter.md
+++ b/doc/administration/monitoring/prometheus/gitlab_exporter.md
@@ -24,7 +24,7 @@ To enable the GitLab exporter in an Omnibus GitLab instance:
    gitlab_exporter['enable'] = true
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 Prometheus automatically begins collecting performance data from
@@ -49,7 +49,7 @@ To change the Rack server to Puma:
    gitlab_exporter['server_name'] = 'puma'
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 The supported Rack servers are `webrick` and `puma`.
diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md
index c0a175c76cd..5d6827b79ee 100644
--- a/doc/administration/monitoring/prometheus/gitlab_metrics.md
+++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md
@@ -9,10 +9,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 To enable the GitLab Prometheus metrics:
 
 1. Log in to GitLab as a user with administrator access.
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Metrics and profiling**.
 1. Find the **Metrics - Prometheus** section, and select **Enable GitLab Prometheus metrics endpoint**.
-1. [Restart GitLab](../../restart_gitlab.md#omnibus-gitlab-restart) for the changes to take effect.
+1. [Restart GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 For installations from source you must configure it yourself.
 
@@ -36,7 +37,7 @@ The following metrics are available:
 
 | Metric                                                           | Type        | Since   | Description                                                                                                           | Labels                                                    |
 | :--------------------------------------------------------------- | :---------- | ------: | :-------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------- |
-| `gitlab_cache_misses_total`                                      | Counter     | 10.2    | Cache read miss                                                                                                       | `controller`, `action`                                    |
+| `gitlab_cache_misses_total`                                      | Counter     | 10.2    | Cache read miss                                                                                                       | `controller`, `action`, `store`                           |
 | `gitlab_cache_operation_duration_seconds`                        | Histogram   | 10.2    | Cache access time                                                                                                     | `operation`, `store`                                      |
 | `gitlab_cache_operations_total`                                  | Counter     | 12.2    | Cache operations by controller or action                                                                              | `controller`, `action`, `operation`, `store`              |
 | `gitlab_cache_read_multikey_count`                               | Histogram   | 15.7    | Count of keys in multi-key cache read operations                                                                      | `controller`, `action`, `store`                   |
@@ -52,6 +53,7 @@ The following metrics are available:
 | `gitlab_ci_active_jobs`                                          | Histogram   | 14.2    | Count of active jobs when pipeline is created                                                                         |                                                           |
 | `gitlab_database_transaction_seconds`                            | Histogram   | 12.1    | Time spent in database transactions, in seconds                                                                       |                                                           |
 | `gitlab_method_call_duration_seconds`                            | Histogram   | 10.2    | Method calls real duration                                                                                            | `controller`, `action`, `module`, `method`                |
+| `gitlab_omniauth_login_total`                                    | Counter     | 16.1    | Total number of OmniAuth logins attempts                                                                              | `omniauth_provider`, `status`                             |
 | `gitlab_page_out_of_bounds`                                      | Counter     | 12.8    | Counter for the PageLimiter pagination limit being hit                                                                | `controller`, `action`, `bot`                             |
 | `gitlab_rails_boot_time_seconds`                                 | Gauge       | 14.8    | Time elapsed for Rails primary process to finish startup                                               |                                                           |
 | `gitlab_rails_queue_duration_seconds`                            | Histogram   | 9.4     | Measures latency between GitLab Workhorse forwarding a request to Rails                                               |                                                           |
@@ -63,8 +65,8 @@ The following metrics are available:
 | `gitlab_transaction_cache_<key>_duration_total`                  | Counter     | 10.2    | Counter for total time (seconds) spent in Rails cache calls (per key)                                                 |                                                           |
 | `gitlab_transaction_cache_count_total`                           | Counter     | 10.2    | Counter for total Rails cache calls (aggregate)                                                                       |                                                           |
 | `gitlab_transaction_cache_duration_total`                        | Counter     | 10.2    | Counter for total time (seconds) spent in Rails cache calls (aggregate)                                               |                                                           |
-| `gitlab_transaction_cache_read_hit_count_total`                  | Counter     | 10.2    | Counter for cache hits for Rails cache calls                                                                          | `controller`, `action`                                    |
-| `gitlab_transaction_cache_read_miss_count_total`                 | Counter     | 10.2    | Counter for cache misses for Rails cache calls                                                                        | `controller`, `action`                                    |
+| `gitlab_transaction_cache_read_hit_count_total`                  | Counter     | 10.2    | Counter for cache hits for Rails cache calls                                                                          | `controller`, `action`, `store`                           |
+| `gitlab_transaction_cache_read_miss_count_total`                 | Counter     | 10.2    | Counter for cache misses for Rails cache calls                                                                        | `controller`, `action`, `store`                           |
 | `gitlab_transaction_duration_seconds`                            | Histogram   | 10.2    | Duration for successful requests (`gitlab_transaction_*` metrics)                                                     | `controller`, `action`                                    |
 | `gitlab_transaction_event_build_found_total`                     | Counter     | 9.4     | Counter for build found for API /jobs/request                                                                         |                                                           |
 | `gitlab_transaction_event_build_invalid_total`                   | Counter     | 9.4     | Counter for build invalid due to concurrency conflict for API /jobs/request                                           |                                                           |
@@ -147,9 +149,9 @@ The following metrics are available:
 | `service_desk_thank_you_email`                                   | Counter     | 14.0    | Total number of email responses to new Service Desk emails                                                            |                                                           |
 | `service_desk_new_note_email`                                    | Counter     | 14.0    | Total number of email notifications on new Service Desk comment                                                       |                                                           |
 | `email_receiver_error`                                           | Counter     | 14.1    | Total number of errors when processing incoming emails                                                                |                                                           |
-| `gitlab_snowplow_events_total`                                   | Counter     | 14.1    | Total number of GitLab Snowplow product intelligence events emitted                                                   |                                                           |
-| `gitlab_snowplow_failed_events_total`                            | Counter     | 14.1    | Total number of GitLab Snowplow product intelligence events emission failures                                         |                                                           |
-| `gitlab_snowplow_successful_events_total`                        | Counter     | 14.1    | Total number of GitLab Snowplow product intelligence events emission successes                                        |                                                           |
+| `gitlab_snowplow_events_total`                                   | Counter     | 14.1    | Total number of GitLab Snowplow Analytics Instrumentation events emitted                                                   |                                                           |
+| `gitlab_snowplow_failed_events_total`                            | Counter     | 14.1    | Total number of GitLab Snowplow Analytics Instrumentation events emission failures                                         |                                                           |
+| `gitlab_snowplow_successful_events_total`                        | Counter     | 14.1    | Total number of GitLab Snowplow Analytics Instrumentation events emission successes                                        |                                                           |
 | `gitlab_ci_build_trace_errors_total`                             | Counter     | 14.4    | Total amount of different error types on a build trace                                                                | `error_reason`                                            |
 | `gitlab_presentable_object_cacheless_render_real_duration_seconds`              | Histogram   | 15.3     | Duration of real time spent caching and representing specific web request objects                                                    | `controller`, `action`                                    |
 | `cached_object_operations_total`                                      | Counter     | 15.3    | Total number of objects cached for specific web requests                                                                                                      | `controller`, `action`                                    |
@@ -204,6 +206,7 @@ configuration option in `gitlab.yml`. These metrics are served from the
 | `sidekiq_jobs_dead_total`                      | Counter   | 13.7 | Sidekiq dead jobs (jobs that have run out of retries)                                               | `queue`, `boundary`, `external_dependencies`, `feature_category`, `urgency` |
 | `sidekiq_redis_requests_total`                 | Counter   | 13.1 | Redis requests during a Sidekiq job execution                                                       | `queue`, `boundary`, `external_dependencies`, `feature_category`, `job_status`, `urgency` |
 | `sidekiq_elasticsearch_requests_total`         | Counter   | 13.1 | Elasticsearch requests during a Sidekiq job execution                                                       | `queue`, `boundary`, `external_dependencies`, `feature_category`, `job_status`, `urgency` |
+| `sidekiq_jobs_deferred_total`                  | Counter   | 16.1 | Number of jobs being deferred when `defer_sidekiq_jobs` feature flag is enabled                       | `worker`                                                                                   |
 | `sidekiq_running_jobs`                         | Gauge     | 12.2 | Number of Sidekiq jobs running                                                                      | `queue`, `boundary`, `external_dependencies`, `feature_category`, `urgency` |
 | `sidekiq_concurrency`                          | Gauge     | 12.5 | Maximum number of Sidekiq jobs                                                                      |                                                                   |
 | `sidekiq_mem_total_bytes`                      | Gauge     | 15.3 | Number of bytes allocated for both objects consuming an object slot and objects that required a malloc'|                                                                   |
@@ -221,9 +224,6 @@ configuration option in `gitlab.yml`. These metrics are served from the
 | `geo_lfs_objects_verified`                     | Gauge   | 14.6  | Number of LFS objects successfully verified on secondary | `url` |
 | `geo_lfs_objects_verification_failed`          | Gauge   | 14.6  | Number of LFS objects that failed verifications on secondary | `url` |
 | `geo_lfs_objects_verification_total`           | Gauge   | 14.6  | Number of LFS objects to attempt to verify on secondary | `url` |
-| `geo_attachments`                              | Gauge   | 10.2  | Total number of file attachments available on primary | `url` |
-| `geo_attachments_synced`                       | Gauge   | 10.2  | Number of attachments synced on secondary | `url` |
-| `geo_attachments_failed`                       | Gauge   | 10.2  | Number of attachments failed to sync on secondary | `url` |
 | `geo_last_event_id`                            | Gauge   | 10.2  | Database ID of the latest event log entry on the primary | `url` |
 | `geo_last_event_timestamp`                     | Gauge   | 10.2  | UNIX timestamp of the latest event log entry on the primary | `url` |
 | `geo_cursor_last_event_id`                     | Gauge   | 10.2  | Last database ID of the event log processed by the secondary | `url` |
@@ -375,6 +375,16 @@ configuration option in `gitlab.yml`. These metrics are served from the
 | `gitlab_memwd_violations_handled_total`              | Counter | 15.9    | Total number of times Sidekiq process memory violations were handled                                                                                       | |
 | `sidekiq_watchdog_running_jobs_total`                | Counter | 15.9    | Current running jobs when RSS limit was reached                                                                                                            | `worker_class`                                                                                          |
 | `gitlab_maintenance_mode`                            | Gauge   | 15.11   | Is GitLab Maintenance Mode enabled? | |
+| `geo_design_management_repositories`                     | Gauge   | 16.1  | Number of design repositories on primary | `url` |
+| `geo_design_management_repositories_checksum_total`      | Gauge   | 16.1 | Number of design repositories tried to checksum on primary | `url` |
+| `geo_design_management_repositories_checksummed`         | Gauge   | 16.1 | Number of design repositories successfully checksummed on primary | `url` |
+| `geo_design_management_repositories_checksum_failed`     | Gauge   | 16.1 | Number of design repositories failed to calculate the checksum on primary | `url` |
+| `geo_design_management_repositories_synced`              | Gauge   | 16.1 | Number of syncable design repositories synced on secondary | `url` |
+| `geo_design_management_repositories_failed`              | Gauge   | 16.1 | Number of syncable design repositories failed to sync on secondary | `url` |
+| `geo_design_management_repositories_registry`            | Gauge   | 16.1 | Number of design repositories in the registry | `url` |
+| `geo_design_management_repositories_verification_total`  | Gauge   | 16.1 | Number of design repositories verifications tried on secondary | `url` |
+| `geo_design_management_repositories_verified`            | Gauge   | 16.1 | Number of design repositories verified on secondary | `url` |
+| `geo_design_management_repositories_verification_failed` | Gauge   | 16.1 | Number of design repositories verifications failed on secondary | `url` |
 
 ## Database load balancing metrics **(PREMIUM SELF)**
 
diff --git a/doc/administration/monitoring/prometheus/index.md b/doc/administration/monitoring/prometheus/index.md
index 013c4515268..0e8315e528a 100644
--- a/doc/administration/monitoring/prometheus/index.md
+++ b/doc/administration/monitoring/prometheus/index.md
@@ -49,7 +49,7 @@ To disable Prometheus and all of its exporters, as well as any added in the futu
    prometheus_monitoring['enable'] = false
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to
    take effect.
 
 ### Changing the port and address Prometheus listens on
@@ -80,7 +80,7 @@ listens on:
    prometheus['listen_address'] = '0.0.0.0:9090'
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to
    take effect
 
 ### Adding custom scrape configurations
@@ -158,7 +158,7 @@ The next step is to tell all the other nodes where the monitoring node is:
 
    Where `10.0.0.1:9090` is the IP address and port of the Prometheus node.
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to
    take effect.
 
 After monitoring using Service Discovery is enabled with `consul['monitoring_service_discovery'] =  true`,
@@ -190,6 +190,7 @@ To use an external Prometheus server:
    # Rails nodes
    gitlab_exporter['listen_address'] = '0.0.0.0'
    gitlab_exporter['listen_port'] = '9168'
+   registry['debug_addr'] = '0.0.0.0:5001'
 
    # Sidekiq nodes
    sidekiq['listen_address'] = '0.0.0.0'
@@ -205,14 +206,12 @@ To use an external Prometheus server:
       # ...
       prometheus_listen_addr: '0.0.0.0:9236',
    }
+
+   # Pgbouncer nodes
+   pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'
    ```
 
 1. Install and set up a dedicated Prometheus instance, if necessary, using the [official installation instructions](https://prometheus.io/docs/prometheus/latest/installation/).
-1. Add the Prometheus server IP address to the [monitoring IP allowlist](../ip_allowlist.md). For example:
-
-   ```ruby
-   gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
-   ```
 
 1. On **all** GitLab Rails(Puma, Sidekiq) servers, set the Prometheus server IP address and listen port. For example:
 
@@ -232,7 +231,27 @@ To use an external Prometheus server:
    }
    ```
 
-1. [Reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) to apply the changes.
+   You can also specify more than one IP address if you have multiple Prometheus servers:
+
+   ```ruby
+   nginx['status']['options'] = {
+         "server_tokens" => "off",
+         "access_log" => "off",
+         "allow" => ["192.168.0.1", "192.168.0.2"]
+         "deny" => "all",
+   }
+   ```
+
+1. To allow the Prometheus server to fetch from the [GitLab metrics](#gitlab-metrics) endpoint, add the Prometheus
+server IP address to the [monitoring IP allowlist](../ip_allowlist.md):
+
+   ```ruby
+   gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
+   ```
+
+1. As we are setting each bundled service's [exporter](#bundled-software-metrics) to listen on a network address,
+update the firewall on the instance to only allow traffic from your Prometheus IP for the exporters enabled. A full reference list of exporter services and their respective ports can be found [here](../../package_information/defaults.md#ports).
+1. [Reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) to apply the changes.
 1. Edit the Prometheus server's configuration file.
 1. Add each node's exporters to the Prometheus server's
    [scrape target configuration](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cscrape_config%3E).
@@ -429,7 +448,7 @@ To disable the monitoring of Kubernetes:
    prometheus['monitor_kubernetes'] = false
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to
    take effect.
 
 ## Troubleshooting
diff --git a/doc/administration/monitoring/prometheus/node_exporter.md b/doc/administration/monitoring/prometheus/node_exporter.md
index 337ab9becaa..f4d5d9942ca 100644
--- a/doc/administration/monitoring/prometheus/node_exporter.md
+++ b/doc/administration/monitoring/prometheus/node_exporter.md
@@ -21,7 +21,7 @@ To enable the node exporter:
    node_exporter['enable'] = true
    ```
 
-1. Save the file, and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file, and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 Prometheus begins collecting performance data from the node exporter
diff --git a/doc/administration/monitoring/prometheus/pgbouncer_exporter.md b/doc/administration/monitoring/prometheus/pgbouncer_exporter.md
index f8d48832288..a95dc47dc34 100644
--- a/doc/administration/monitoring/prometheus/pgbouncer_exporter.md
+++ b/doc/administration/monitoring/prometheus/pgbouncer_exporter.md
@@ -21,7 +21,7 @@ To enable the PgBouncer exporter:
    pgbouncer_exporter['enable'] = true
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 Prometheus begins collecting performance data from the PgBouncer exporter
diff --git a/doc/administration/monitoring/prometheus/postgres_exporter.md b/doc/administration/monitoring/prometheus/postgres_exporter.md
index 1cae28a069f..39f6c81e8d0 100644
--- a/doc/administration/monitoring/prometheus/postgres_exporter.md
+++ b/doc/administration/monitoring/prometheus/postgres_exporter.md
@@ -23,7 +23,7 @@ To enable the PostgreSQL Server Exporter:
    address is [listed in `trust_auth_cidr_addresses`](../../postgresql/replication_and_failover.md#network-information) or the
    exporter can't connect to the database.
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to
    take effect.
 
 Prometheus begins collecting performance data from
@@ -70,5 +70,5 @@ use the following configuration options:
    postgres_exporter['sslrootcert'] = 'ssl-root.crt'
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
diff --git a/doc/administration/monitoring/prometheus/redis_exporter.md b/doc/administration/monitoring/prometheus/redis_exporter.md
index b17bf9787a7..5f11034dc15 100644
--- a/doc/administration/monitoring/prometheus/redis_exporter.md
+++ b/doc/administration/monitoring/prometheus/redis_exporter.md
@@ -22,7 +22,7 @@ To enable the Redis exporter:
    redis_exporter['enable'] = true
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 Prometheus begins collecting performance data from
diff --git a/doc/administration/monitoring/prometheus/registry_exporter.md b/doc/administration/monitoring/prometheus/registry_exporter.md
index 3f4d6cfb14d..1c46224f7b3 100644
--- a/doc/administration/monitoring/prometheus/registry_exporter.md
+++ b/doc/administration/monitoring/prometheus/registry_exporter.md
@@ -16,7 +16,7 @@ To enable it:
    registry['debug_addr'] = "localhost:5001"  # localhost:5001/metrics
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 Prometheus automatically begins collecting performance data from
diff --git a/doc/administration/monitoring/prometheus/web_exporter.md b/doc/administration/monitoring/prometheus/web_exporter.md
index 0212091f14c..eb6fe6d4d60 100644
--- a/doc/administration/monitoring/prometheus/web_exporter.md
+++ b/doc/administration/monitoring/prometheus/web_exporter.md
@@ -47,7 +47,7 @@ To enable the dedicated server:
    to `localhost:8083/metrics`. Refer to the [Adding custom scrape configurations](index.md#adding-custom-scrape-configurations) page
    for how to configure scraper targets. For external Prometheus setup, refer to
    [Using an external Prometheus server](index.md#using-an-external-prometheus-server) instead.
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 Metrics can now be served and scraped from `localhost:8083/metrics`.
@@ -66,7 +66,7 @@ To serve metrics via HTTPS instead of HTTP, enable TLS in the exporter settings:
    puma['exporter_tls_key_path'] = "/path/to/private-key.pem"
    ```
 
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 When TLS is enabled, the same `port` and `address` is used as described above.
diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index 1e6605e41a8..f2b966bd180 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -114,6 +114,7 @@ The following table lists the valid `objects` that can be used:
 | `dependency_proxy` | [Dependency Proxy](packages/dependency_proxy.md)                    |
 | `terraform_state`  | [Terraform state files](terraform_state.md)                                |
 | `pages`            | [Pages](pages/index.md)                                             |
+| `ci_secure_files`  | [Project-level Secure Files](secure_files.md)                              |
 
 Within each object type, three parameters can be defined:
 
@@ -161,6 +162,7 @@ supported by consolidated form, refer to the following guides:
 
 | Object storage type | Supported by consolidated form? |
 |---------------------|------------------------------------------|
+| [Project-level Secure Files](secure_files.md#using-object-storage) | **{dotted-circle}** No |
 | [Backups](../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | **{dotted-circle}** No |
 | [Container Registry](packages/container_registry.md#use-object-storage) (optional feature) | **{dotted-circle}** No |
 | [Mattermost](https://docs.mattermost.com/configure/file-storage-configuration-settings.html)| **{dotted-circle}** No |
@@ -315,8 +317,7 @@ Bucket encryption with the [Cloud Key Management Service (KMS)](https://cloud.go
 
 #### GCS example
 
-For Omnibus installations, this is an example of the `connection` setting
-in the consolidated form:
+For Linux Package installations, this is an example of the `connection` setting in the consolidated form:
 
 ```ruby
 gitlab_rails['object_store']['connection'] = {
@@ -376,8 +377,7 @@ The following are the valid connection parameters for Azure. For more informatio
 | `azure_storage_access_key`   | Storage account access key used to access the container. This is typically a secret, 512-bit encryption key encoded in base64. | `czV2OHkvQj9FKEgrTWJRZVRoV21ZcTN0Nnc5eiRDJkYpSkBOY1JmVWpYbjJy\nNHU3eCFBJUQqRy1LYVBkU2dWaw==\n` |
 | `azure_storage_domain`       | Domain name used to contact the Azure Blob Storage API (optional). Defaults to `blob.core.windows.net`. Set this if you are using Azure China, Azure Germany, Azure US Government, or some other custom Azure domain. | `blob.core.windows.net` |
 
-- For Omnibus installations, this is an example of the `connection` setting
-  in the consolidated form:
+- For Linux package installations, this is an example of the `connection` setting in the consolidated form:
 
   ```ruby
   gitlab_rails['object_store']['connection'] = {
@@ -388,8 +388,8 @@ The following are the valid connection parameters for Azure. For more informatio
   }
   ```
 
-- For source installations, Workhorse also needs to be configured with Azure
-  credentials. This isn't needed in Omnibus installs, because the Workhorse
+- For self-compiled installations, Workhorse also needs to be configured with Azure
+  credentials. This isn't needed in Linux package installations because the Workhorse
   settings are populated from the previous settings.
 
   1. Edit `/home/git/gitlab-workhorse/config.toml` and add or amend the following lines:
@@ -465,7 +465,6 @@ The following example uses AWS S3 to enable object storage for all supported ser
    gitlab_rails['object_store']['objects']['packages']['bucket'] = 'gitlab-packages'
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = 'gitlab-dependency-proxy'
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = 'gitlab-terraform-state'
-   gitlab_rails['object_store']['objects']['ci_secure_files']['bucket'] = 'gitlab-ci-secure-files'
    gitlab_rails['object_store']['objects']['pages']['bucket'] = 'gitlab-pages'
    ```
 
@@ -728,6 +727,7 @@ To migrate existing local data to object storage see the following guides:
 - [Dependency Proxy](packages/dependency_proxy.md#migrate-local-dependency-proxy-blobs-and-manifests-to-object-storage)
 - [Terraform state files](terraform_state.md#migrate-to-object-storage)
 - [Pages content](pages/index.md#migrate-pages-deployments-to-object-storage)
+- [Project-level Secure Files](secure_files.md#migrate-to-object-storage)
 
 ## Transition to consolidated form
 
@@ -738,7 +738,7 @@ Prior to GitLab 13.2:
 - Object store connection parameters such as passwords and endpoint URLs had to be
   duplicated for each type.
 
-For example, an Omnibus GitLab install might have the following configuration:
+For example, a Linux package installation might have the following configuration:
 
 ```ruby
 # Original object storage configuration
@@ -833,10 +833,9 @@ your object storage provider instead.
 
 Using separate buckets for each data type is the recommended approach for GitLab.
 This ensures there are no collisions across the various types of data GitLab stores.
-There are plans to [enable the use of a single bucket](https://gitlab.com/gitlab-org/gitlab/-/issues/292958)
-in the future.
+[Issue 292958](https://gitlab.com/gitlab-org/gitlab/-/issues/292958) proposes to enable the use of a single bucket.
 
-With Omnibus and source installations it is possible to split a single
+With Linux package and self-compiled installations, it is possible to split a single
 real bucket into multiple virtual buckets. If your object storage
 bucket is called `my-gitlab-objects` you can configure uploads to go
 into `my-gitlab-objects/uploads`, artifacts into
@@ -941,7 +940,7 @@ mismatch` error during an upload.
 
 When the consolidated form is:
 
-- Used with an S3-compatible object storage or an istance profile, Workhorse
+- Used with an S3-compatible object storage or an instance profile, Workhorse
   uses its internal S3 client which has S3 credentials so that it can compute
   the `Content-MD5` header. This eliminates the need to compare ETag headers
   returned from the S3 server.
diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md
index 1e887d8bd67..d54d286c19d 100644
--- a/doc/administration/operations/fast_ssh_key_lookup.md
+++ b/doc/administration/operations/fast_ssh_key_lookup.md
@@ -121,7 +121,8 @@ users as long as a large file exists.
 
 To disable writes to the `authorized_keys` file:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Network**.
 1. Expand **Performance optimization**.
 1. Clear the **Use authorized_keys file to authenticate SSH keys** checkbox.
@@ -140,7 +141,8 @@ This overview is brief. Refer to the above instructions for more context.
 
 1. [Rebuild the `authorized_keys` file](../raketasks/maintenance.md#rebuild-authorized_keys-file).
 1. Enable writes to the `authorized_keys` file.
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
    1. On the left sidebar, select **Settings > Network**.
    1. Expand **Performance optimization**.
    1. Select the **Use authorized_keys file to authenticate SSH keys** checkbox.
diff --git a/doc/administration/operations/gitlab_sshd.md b/doc/administration/operations/gitlab_sshd.md
index 249d6232616..5c4af32fc3d 100644
--- a/doc/administration/operations/gitlab_sshd.md
+++ b/doc/administration/operations/gitlab_sshd.md
@@ -27,9 +27,8 @@ If you are considering switching from OpenSSH to `gitlab-sshd`, consider these c
 
 - `gitlab-sshd` supports the PROXY protocol. It can run behind proxy servers that rely
   on it, such as HAProxy. The PROXY protocol is not enabled by default, but [it can be enabled](#proxy-protocol-support).
-- `gitlab-sshd` **does not** support SSH certificates. For more details, see the
-  [confidential issue](../../user/project/issues/confidential_issues.md)
-  `https://gitlab.com/gitlab-org/gitlab-shell/-/issues/495`.
+- `gitlab-sshd` does not support SSH certificates. For discussion about adding them,
+  see [issue 655](https://gitlab.com/gitlab-org/gitlab-shell/-/issues/655).
 
 ## Enable `gitlab-sshd`
 
diff --git a/doc/administration/operations/puma.md b/doc/administration/operations/puma.md
index efc55a5fbc3..d7d6f6228f9 100644
--- a/doc/administration/operations/puma.md
+++ b/doc/administration/operations/puma.md
@@ -99,7 +99,7 @@ To change the worker timeout to 600 seconds:
 ## Disable Puma clustered mode in memory-constrained environments
 
 WARNING:
-This feature is an [Experiment](../../policy/alpha-beta-support.md#experiment) and subject to change without notice. The feature
+This feature is an [Experiment](../../policy/experiment-beta-support.md#experiment) and subject to change without notice. The feature
 is not ready for production use. If you want to use this feature, you should test
 outside of production first. See the [known issues](#puma-single-mode-known-issues)
 for additional details.
@@ -211,6 +211,71 @@ make Prometheus scrape them over HTTPS, and support for it is being discussed
 Hence, it is not technically possible to turn off this HTTP listener without
 losing Prometheus metrics.
 
+### Using an encrypted SSL key
+
+> [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7799) in GitLab 16.1.
+
+Puma supports the use of an encrypted private SSL key, which can be
+decrypted at runtime. The following instructions illustrate how to
+configure this:
+
+1. Encrypt the key with a password if it is not already:
+
+   ```shell
+   openssl rsa -aes256 -in /path/to/ssl-key.pem -out /path/to/encrypted-ssl-key.pem
+   ```
+
+   Enter in a password twice to write the encrypted file. In this
+   example, we use `some-password-here`.
+
+1. Create a script or executable that prints the password. For
+   example, create a basic script in
+   `/var/opt/gitlab/gitlab-rails/etc/puma-ssl-key-password` that echoes
+   the password:
+
+   ```shell
+   #!/bin/sh
+   echo some-password-here
+   ```
+
+   Note that in production, you should avoid storing the password on
+   disk and use a secure mechanism for retrieving a password, such as
+   Vault. For example, the script might look like:
+
+   ```shell
+   #!/bin/sh
+   export VAULT_ADDR=http://vault-password-distribution-point:8200
+   export VAULT_TOKEN=<some token>
+
+   echo "$(vault kv get -mount=secret puma-ssl-password)"
+   ```
+
+1. Ensure the Puma process has sufficient permissions to execute the
+   script and to read the encrypted key:
+
+   ```shell
+   chown git:git /var/opt/gitlab/gitlab-rails/etc/puma-ssl-key-password
+   chmod 770 /var/opt/gitlab/gitlab-rails/etc/puma-ssl-key-password
+   chmod 660 /path/to/encrypted-ssl-key.pem
+   ```
+
+1. Edit `/etc/gitlab/gitlab.rb`, and replace `puma['ssl_certificate_key']` with the encrypted key and specify
+   `puma['ssl_key_password_command]`:
+
+   ```ruby
+   puma['ssl_certificate_key'] = '/path/to/encrypted-ssl-key.pem'
+   puma['ssl_key_password_command'] = '/var/opt/gitlab/gitlab-rails/etc/puma-ssl-key-password'
+   ```
+
+1. Reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. If GitLab comes up successfully, you should be able to remove the
+   unencrypted SSL key that was stored on the GitLab instance.
+
 ## Switch from Unicorn to Puma
 
 NOTE:
@@ -333,7 +398,7 @@ gitlab_rails['env'] = {
 For source installations, set the environment variable.
 Refer to [Puma Worker timeout](../operations/puma.md#change-the-worker-timeout).
 
-[Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
+[Reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation) GitLab for the changes to take effect.
 
 #### Troubleshooting without affecting other users
 
diff --git a/doc/administration/package_information/defaults.md b/doc/administration/package_information/defaults.md
index 96b56388ea9..ac183afdc2f 100644
--- a/doc/administration/package_information/defaults.md
+++ b/doc/administration/package_information/defaults.md
@@ -53,6 +53,8 @@ by default:
 |        Gitaly        |      Yes      |      Socket      | Port (8075) |                8075 or 9999 (TLS)          |
 |   Gitaly exporter    |      Yes      |       Port       |      X      |                    9236                    |
 |       Praefect       |      No       |       Port       |      X      |                2305 or 3305 (TLS)          |
+| GitLab Workhorse exporter |      Yes      |       Port       |      X      |                     9229                   |
+|  Registry exporter   |      No       |       Port       |      X      |                     5001                   |
 
 Legend:
 
diff --git a/doc/administration/package_information/postgresql_versions.md b/doc/administration/package_information/postgresql_versions.md
index c1e9f7320ea..44032883eb4 100644
--- a/doc/administration/package_information/postgresql_versions.md
+++ b/doc/administration/package_information/postgresql_versions.md
@@ -30,6 +30,7 @@ Read more about update policies and warnings in the PostgreSQL
 
 | GitLab version | PostgreSQL versions | Default version for fresh installs | Default version for upgrades | Notes |
 | -------------- | --------------------- | ---------------------------------- | ---------------------------- | ----- |
+| 16.0 | 13.11 | 13.11 | 13.11 | |
 | 15.6 | 12.12, 13.8 | 13.8 | 12.12 | For upgrades, users can manually upgrade to 13.8 following the [upgrade documentation](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-150-and-later). |
 | 15.0 | 12.10, 13.6 | 13.6 | 12.10 | For upgrades, users can manually upgrade to 13.6 following the [upgrade documentation](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-150-and-later). |
 | 14.1 | 12.7, 13.3 | 12.7 | 12.7 | PostgreSQL 13 available for fresh installations if not using [Geo](../geo/index.md#requirements-for-running-geo) or [Patroni](../postgresql/index.md#postgresql-replication-and-failover-with-omnibus-gitlab).
diff --git a/doc/administration/package_information/supported_os.md b/doc/administration/package_information/supported_os.md
index a1f589015cb..8ad3a656e05 100644
--- a/doc/administration/package_information/supported_os.md
+++ b/doc/administration/package_information/supported_os.md
@@ -28,6 +28,7 @@ architecture.
 | Debian 11                                                    | GitLab CE / GitLab EE 14.6.0   | amd64, arm64    | [Debian Install Documentation](https://about.gitlab.com/install/#debian) | 2026       | <https://wiki.debian.org/LTS>                                |
 | OpenSUSE 15.4                                                | GitLab CE / GitLab EE 15.7.0   | x86_64, aarch64 | [OpenSUSE Install Documentation](https://about.gitlab.com/install/#opensuse-leap) | Nov 2023   | <https://en.opensuse.org/Lifetime>                           |
 | RHEL 8                                                       | GitLab CE / GitLab EE 12.8.1   | x86_64, arm64   | [Use CentOS Install Documentation](https://about.gitlab.com/install/#centos-7) | May 2029   | [RHEL Details](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates) |
+| RHEL 9                                                      | GitLab CE / GitLab EE 16.0.0   | x86_64, arm64   | [Use CentOS Install Documentation](https://about.gitlab.com/install/#centos-7) | May 2032   | [RHEL Details](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates) |
 | SLES 12                                                      | GitLab EE 9.0.0                | x86_64          | [Use OpenSUSE Install Documentation](https://about.gitlab.com/install/#opensuse-leap) | Oct 2027   | <https://www.suse.com/lifecycle/>                            |
 | SLES 15                                                      | GitLab EE 14.8.0                | x86_64          | [Use OpenSUSE Install Documentation](https://about.gitlab.com/install/#opensuse-leap) | Dec 2024   | <https://www.suse.com/lifecycle/>                            |
 | Oracle Linux                                                 | GitLab CE / GitLab EE 8.14.0   | x86_64          | [Use CentOS Install Documentation](https://about.gitlab.com/install/#centos-7) | Jul 2024         | <https://www.oracle.com/a/ocom/docs/elsp-lifetime-069338.pdf>                                                           |
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index fd3cbb2ad05..e3867a25846 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -147,7 +147,7 @@ under the `registry_external_url` line, rather than the port listed under
    registry_nginx['ssl_certificate_key'] = "/path/to/certificate.key"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 1. Validate using:
@@ -226,7 +226,7 @@ Let's assume that you want the container Registry to be accessible at
 
    The `registry_external_url` is listening on HTTPS.
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 If you have a [wildcard certificate](https://en.wikipedia.org/wiki/Wildcard_certificate), you must specify the path to the
 certificate in addition to the URL, in this case `/etc/gitlab/gitlab.rb`
@@ -272,7 +272,7 @@ Registry application itself.
    registry['enable'] = false
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **Installations from source**
 
@@ -300,7 +300,7 @@ the Container Registry by themselves, follow the steps below.
    gitlab_rails['gitlab_default_projects_features_container_registry'] = false
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **Installations from source**
 
@@ -325,7 +325,8 @@ the Container Registry by themselves, follow the steps below.
 In GitLab, tokens for the Container Registry expire every five minutes.
 To increase the token duration:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > CI/CD**.
 1. Expand **Container Registry**.
 1. For the **Authorization token duration (minutes)**, update the value.
@@ -391,7 +392,7 @@ The default location where images are stored in Omnibus, is
    gitlab_rails['registry_path'] = "/path/to/registry/storage"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **Installations from source**
 
@@ -490,7 +491,7 @@ To configure the `s3` storage driver in Omnibus:
     }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **Installations from source**
 
@@ -556,7 +557,7 @@ you can pull from the Container Registry, but you cannot push.
 
 1. To perform the final data sync,
    [put the Container Registry in `read-only` mode](#performing-garbage-collection-without-downtime) and
-   [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+   [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. Sync any changes dating from after the initial data load to your S3 bucket, and delete files that exist in the destination bucket but not in the source:
 
    ```shell
@@ -586,7 +587,7 @@ you can pull from the Container Registry, but you cannot push.
    The output of these commands should match, except for the content in the
    `_uploads` directories and sub-directories.
 1. Configure your registry to [use the S3 bucket for storage](#use-object-storage).
-1. For the changes to take effect, set the Registry back to `read-write` mode and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. For the changes to take effect, set the Registry back to `read-write` mode and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 #### Moving to Azure Object Storage
 
@@ -598,7 +599,7 @@ The default configuration for the storage driver is scheduled to be [changed](ht
 <!--- end_remove -->
 
 When moving from an existing file system or another object storage provider to Azure Object Storage, you must configure the registry to use the standard root directory.
-Configure it by setting [`trimlegacyrootprefix: true]`](https://gitlab.com/gitlab-org/container-registry/-/blob/a3f64464c3ec1c5a599c0a2daa99ebcbc0100b9a/docs-gitlab/README.md#azure-storage-driver) in the Azure storage driver section of the registry configuration.
+Configure it by setting [`trimlegacyrootprefix: true`](https://gitlab.com/gitlab-org/container-registry/-/blob/a3f64464c3ec1c5a599c0a2daa99ebcbc0100b9a/docs-gitlab/README.md#azure-storage-driver) in the Azure storage driver section of the registry configuration.
 Without this configuration, the Azure storage driver uses `//` instead of `/` as the first section of the root path, rendering the migrated images inaccessible.
 
 **Omnibus GitLab installations**
@@ -654,7 +655,7 @@ However, this behavior is undesirable for registries used by internal hosts that
    }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **Installations from source**
 
@@ -705,7 +706,7 @@ For Omnibus GitLab installations:
    }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 For installations from source:
@@ -746,7 +747,7 @@ In the examples below we set the Registry's port to `5010`.
    registry['registry_http_addr'] = "localhost:5010"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **Installations from source**
 
@@ -850,7 +851,7 @@ You can use GitLab as an auth endpoint with an external container registry.
    gitlab_rails['registry_port'] = "5005"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 **Installations from source**
@@ -905,7 +906,7 @@ To configure a notification endpoint in Omnibus:
    ]
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **Installations from source**
 
@@ -1285,6 +1286,33 @@ specified in its configuration and allows the operation.
 GitLab background jobs processing (through Sidekiq) also interacts with Registry.
 These jobs talk directly to Registry to handle image deletion.
 
+## Migrate from a third-party registry
+
+Using external container registries in GitLab was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/376217)
+in GitLab 15.8 and the end of support occurred in GitLab 16.0. See the [deprecation notice](../../update/deprecations.md#use-of-third-party-container-registries-is-deprecated) for more details.
+
+The integration is not disabled in GitLab 16.0, but support for debugging and fixing issues
+is no longer provided. Additionally, the integration is no longer being developed or
+enhanced with new features. Third-party registry functionality might be completely removed
+after the new GitLab Container Registry version is available for self-managed (see epic [5521](https://gitlab.com/groups/gitlab-org/-/epics/5521)). Only the GitLab Container Registry is planned to be supported.
+
+This section has guidance for administrators migrating from third-party registries
+to the GitLab Container Registry. If the third-party container registry you are using is not listed here,
+you can describe your use cases in [the feedback issue](https://gitlab.com/gitlab-org/container-registry/-/issues/958).
+
+For all of the instructions provided below, you should try them first on a test environment.
+Make sure everything continues to work as expected before replicating it in production.
+
+### Docker Distribution Registry
+
+The [Docker Distribution Registry](https://docs.docker.com/registry/) was donated to the CNCF
+and is now known as the [Distribution Registry](https://github.com/distribution/distribution).
+This registry is the open source implementation that the GitLab Container Registry is based on.
+The GitLab Container Registry is compatible with the basic functionality provided by the Distribution Registry,
+including all the supported storage backends. To migrate to the GitLab Container Registry
+you can follow the instructions on this page, and use the same storage backend as the Distribution Registry.
+The GitLab Container Registry should accept the same configuration that you are using for the Distribution Registry.
+
 ## Troubleshooting
 
 Before diving in to the following sections, here's some basic troubleshooting:
@@ -1422,7 +1450,7 @@ Start with a value between `25000000` (25 MB) and `50000000` (50 MB).
    }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **For installations from source**
 
@@ -1456,7 +1484,7 @@ You can add a configuration option for backwards compatibility.
    registry['compatibility_schema1_enabled'] = true
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **For installations from source**
 
@@ -1504,7 +1532,7 @@ and a simple solution would be to enable relative URLs in the Registry.
    }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **For installations from source**
 
@@ -1532,7 +1560,7 @@ in your `gitlab.rb` configuration.
 registry['debug_addr'] = "localhost:5001"
 ```
 
-After adding the setting, [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) to apply the change.
+After adding the setting, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) to apply the change.
 
 Use curl to request debug output from the debug server:
 
@@ -1824,7 +1852,7 @@ In this case, follow these steps:
    gitlab_rails['registry_enabled'] = true
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 1. Try the removal again.
 
diff --git a/doc/administration/packages/dependency_proxy.md b/doc/administration/packages/dependency_proxy.md
index a29d6d93051..5e770c2464b 100644
--- a/doc/administration/packages/dependency_proxy.md
+++ b/doc/administration/packages/dependency_proxy.md
@@ -39,7 +39,7 @@ correspond to your GitLab installation:
    gitlab_rails['dependency_proxy_enabled'] = false
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 ### Helm chart installations
@@ -104,7 +104,7 @@ To change the local storage path:
    gitlab_rails['dependency_proxy_storage_path'] = "/mnt/dependency_proxy"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **Installations from source**
 
@@ -156,7 +156,7 @@ This section describes the earlier configuration format. [Migration steps still
    }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 **Installations from source**
 
@@ -266,4 +266,4 @@ The default expiration and the expiration on GitLab.com is 15 minutes.
     "https_proxy" => "http://USERNAME:PASSWORD@example.com:8080"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
diff --git a/doc/administration/packages/index.md b/doc/administration/packages/index.md
index f0f238aa5ba..b735204c323 100644
--- a/doc/administration/packages/index.md
+++ b/doc/administration/packages/index.md
@@ -57,6 +57,91 @@ When downloading packages as dependencies in downstream projects, many requests
 Packages API. You may therefore reach enforced user and IP rate limits. To address this issue, you
 can define specific rate limits for the Packages API. For more details, see [Package Registry Rate Limits](../../user/admin_area/settings/package_registry_rate_limits.md).
 
+## Enable or disable the Package Registry
+
+The Package Registry is enabled by default. To disable it:
+
+::Tabs
+
+:::TabTitle Linux package (Omnibus)
+
+1. Edit `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   # Change to true to enable packages - enabled by default if not defined
+   gitlab_rails['packages_enabled'] = false
+   ```
+
+1. Save the file and reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+:::TabTitle Helm chart (Kubernetes)
+
+1. Export the Helm values:
+
+   ```shell
+   helm get values gitlab > gitlab_values.yaml
+   ```
+
+1. Edit `gitlab_values.yaml`:
+
+   ```yaml
+   global:
+     appConfig:
+       packages:
+         enabled: false
+   ```
+
+1. Save the file and apply the new values:
+
+   ```shell
+   helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
+   ```
+
+:::TabTitle Docker
+
+1. Edit `docker-compose.yml`:
+
+   ```yaml
+   version: "3.6"
+   services:
+     gitlab:
+       environment:
+         GITLAB_OMNIBUS_CONFIG: |
+           gitlab_rails['packages_enabled'] = false
+   ```
+
+1. Save the file and restart GitLab:
+
+   ```shell
+   docker compose up -d
+   ```
+
+:::TabTitle Self-compiled (source)
+
+1. Edit `/home/git/gitlab/config/gitlab.yml`:
+
+   ```yaml
+   production: &base
+     packages:
+       enabled: false
+   ```
+
+1. Save the file and restart GitLab:
+
+   ```shell
+   # For systems running systemd
+   sudo systemctl restart gitlab.target
+
+   # For systems running SysV init
+   sudo service gitlab restart
+   ```
+
+::EndTabs
+
 ## Change the storage path
 
 By default, the packages are stored locally, but you can change the default
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index 1626a4fd41a..e86726524d0 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -146,7 +146,7 @@ The Pages daemon doesn't listen to the outside world.
    pages_external_url "http://pages.example.com" # not a subdomain of external_url
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 Watch the [video tutorial](https://youtu.be/dD8c7WNcc6s) for this configuration.
 
@@ -182,7 +182,7 @@ you must also add the full paths as shown below:
    pages_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/pages-nginx.key"
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. If you're using [Pages Access Control](#access-control), update the redirect URI in the GitLab Pages
 [System OAuth application](../../integration/oauth_provider.md#create-an-instance-wide-application)
 to use the HTTPS protocol.
@@ -221,13 +221,13 @@ This setup is primarily intended to be used when [installing a GitLab POC on Ama
    pages_nginx['redirect_http_to_https'] = true
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ### Global settings
 
 Below is a table of all configuration settings known to Pages in Omnibus GitLab,
 and what they do. These options can be adjusted in `/etc/gitlab/gitlab.rb`,
-and take effect after you [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+and take effect after you [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 Most of these settings don't have to be configured manually unless you need more granular
 control over how the Pages daemon runs and serves content in your environment.
 
@@ -343,7 +343,7 @@ world. Custom domains are supported, but no TLS.
 
    If you don't have IPv6, you can omit the IPv6 address.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ### Custom domains with TLS support
 
@@ -385,7 +385,7 @@ then you need to also add the full paths as shown below:
    gitlab_pages['cert_key'] = "/etc/gitlab/ssl/example.io.key"
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. If you're using [Pages Access Control](#access-control), update the redirect URI in the GitLab Pages
 [System OAuth application](../../integration/oauth_provider.md#create-an-instance-wide-application)
 to use the HTTPS protocol.
@@ -406,7 +406,8 @@ domain as a custom domain to their project.
 If your user base is private or otherwise trusted, you can disable the
 verification requirement:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Preferences**.
 1. Expand **Pages**.
 1. Clear the **Require users to prove ownership of custom domains** checkbox.
@@ -423,7 +424,8 @@ sites served under a custom domain.
 To enable it:
 
 1. Choose an email address on which you want to receive notifications about expiring domains.
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Preferences**.
 1. Expand **Pages**.
 1. Enter the email address for receiving notifications and accept Let's Encrypt's Terms of Service.
@@ -453,7 +455,7 @@ Pages access control is disabled by default. To enable it:
    gitlab_pages['access_control'] = true
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. Users can now configure it in their [projects' settings](../../user/project/pages/pages_access_control.md).
 
 NOTE:
@@ -476,8 +478,9 @@ pre-existing applications must modify the GitLab Pages OAuth application. Follow
 this:
 
 1. Enable [access control](#access-control).
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Applications**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Applications**.
 1. Expand **GitLab Pages**.
 1. Clear the `api` scope's checkbox and select the desired scope's checkbox (for example,
    `read_api`).
@@ -495,7 +498,8 @@ This can be helpful to restrict information published with Pages websites to the
 of your instance only.
 To do that:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Preferences**.
 1. Expand **Pages**.
 1. Select the **Disable public access to Pages sites** checkbox.
@@ -512,7 +516,7 @@ internet connectivity is gated by a proxy. To use a proxy for GitLab Pages:
    gitlab_pages['env']['http_proxy'] = 'http://example:8080'
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### Using a custom Certificate Authority (CA)
 
@@ -598,7 +602,7 @@ Follow the steps below to configure verbose logging of GitLab Pages daemon.
    gitlab_pages['log_verbose'] = true
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ## Propagating the correlation ID
 
@@ -617,7 +621,7 @@ To enable the propagation of the correlation ID:
    gitlab_pages['propagate_correlation_id'] = true
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ## Change storage path
 
@@ -632,7 +636,7 @@ are stored.
    gitlab_rails['pages_path'] = "/mnt/storage/pages"
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ## Configure listener for reverse proxy requests
 
@@ -654,7 +658,7 @@ Follow the steps below to configure the proxy listener of GitLab Pages.
    gitlab_pages['listen_proxy'] = "localhost:10080"
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ## Set global maximum size of each GitLab Pages site **(FREE SELF)**
 
@@ -664,7 +668,8 @@ Prerequisite:
 
 To set the global maximum pages size for a project:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Preferences**.
 1. Expand **Pages**.
 1. In **Maximum size of pages**, enter a value. The default is `100`.
@@ -678,7 +683,7 @@ Prerequisite:
 
 To set the maximum size of each GitLab Pages site in a group, overriding the inherited setting:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Pages**.
 1. Enter a value under **Maximum size** in MB.
@@ -692,7 +697,7 @@ Prerequisite:
 
 To set the maximum size of GitLab Pages site in a project, overriding the inherited setting:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. On the left sidebar, select **Settings > Pages**.
 
    If this path is not visible, select **Deployments > Pages**.
@@ -708,7 +713,8 @@ Prerequisite:
 
 To set the maximum number of GitLab Pages custom domains for a project:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Preferences**, and expand **Pages**.
 1. Enter a value for **Maximum number of custom domains per project**. Use `0` for unlimited domains.
 1. Select **Save changes**.
@@ -754,7 +760,7 @@ database encryption. Proceed with caution.
 
 1. Configure [the object storage and migrate pages data to it](#using-object-storage).
 
-1. [Reconfigure the **GitLab server**](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the
+1. [Reconfigure the **GitLab server**](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the
    changes to take effect. The `gitlab-secrets.json` file is now updated with the
    new configuration.
 
@@ -794,7 +800,7 @@ database encryption. Proceed with caution.
    mv /var/opt/gitlab/gitlab-rails/shared/pages/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json
    ```
 
-1. [Reconfigure the **Pages server**](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure the **Pages server**](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. On the **GitLab server**, make the following changes to `/etc/gitlab/gitlab.rb`:
 
@@ -804,7 +810,7 @@ database encryption. Proceed with caution.
    pages_nginx['enable'] = false
    ```
 
-1. [Reconfigure the **GitLab server**](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure the **GitLab server**](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 It's possible to run GitLab Pages on multiple servers if you wish to distribute
 the load. You can do this through standard load balancing practices such as
@@ -853,7 +859,7 @@ To explicitly enable API source:
    gitlab_pages['domain_config_source'] = "gitlab"
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 Or if you want to use legacy configuration source you can:
 
@@ -863,7 +869,7 @@ Or if you want to use legacy configuration source you can:
    gitlab_pages['domain_config_source'] = "disk"
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### GitLab API cache configuration
 
@@ -960,7 +966,7 @@ In Omnibus installations:
    }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 1. [Migrate existing Pages deployments to object storage.](#migrate-pages-deployments-to-object-storage)
@@ -1102,7 +1108,7 @@ If you use [object storage](#using-object-storage), you can disable local storag
    gitlab_rails['pages_local_store_enabled'] = false
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 Starting from GitLab 13.12, this setting also disables the [legacy storage](#migrate-legacy-storage-to-zip-storage), so if you were using NFS to serve Pages, you can completely disconnect from it.
 
@@ -1176,7 +1182,7 @@ TLS connection-based rate limits are enforced using the following:
    gitlab_pages['rate_limit_source_ip_burst'] = 600
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 #### Enable HTTP requests rate limits by domain
 
@@ -1189,7 +1195,7 @@ TLS connection-based rate limits are enforced using the following:
    gitlab_pages['rate_limit_domain_burst'] = 5000
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 #### Enable TLS connections rate limits by source-IP
 
@@ -1202,7 +1208,7 @@ TLS connection-based rate limits are enforced using the following:
    gitlab_pages['rate_limit_tls_source_ip_burst'] = 600
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 #### Enable TLS connections rate limits by domain
 
@@ -1215,7 +1221,7 @@ TLS connection-based rate limits are enforced using the following:
    gitlab_pages['rate_limit_tls_domain_burst'] = 5000
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ## Related topics
 
diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md
index b36b87f3b1d..2ee9dd653f0 100644
--- a/doc/administration/pages/source.md
+++ b/doc/administration/pages/source.md
@@ -483,7 +483,8 @@ The default for the maximum size of unpacked archives per project is 100 MB.
 
 To change this value:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Preferences**.
 1. Expand **Pages**.
 1. Update the value for **Maximum size of pages (MB)**.
diff --git a/doc/administration/pages/troubleshooting.md b/doc/administration/pages/troubleshooting.md
index 6f00ae074f5..e829943f270 100644
--- a/doc/administration/pages/troubleshooting.md
+++ b/doc/administration/pages/troubleshooting.md
@@ -170,7 +170,8 @@ Upgrading to an [officially supported operating system](https://about.gitlab.com
 
 This problem comes from the permissions of the GitLab Pages OAuth application. To fix it:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Applications > GitLab Pages**.
 1. Edit the application.
 1. Under **Scopes**, ensure that the `api` scope is selected.
@@ -234,7 +235,7 @@ To enable disk access:
    gitlab_pages['enable_disk'] = true
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ## `httprange: new resource 403`
 
@@ -275,7 +276,7 @@ To do that:
    gitlab_pages['use_legacy_storage'] = true
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ## GitLab Pages deploy job fails with error "is not a recognized provider"
 
@@ -292,7 +293,7 @@ To fix that:
    - Configure object storage for your Pages deployments, following the [S3-compatible connection settings](index.md#s3-compatible-connection-settings) guide.
    - Store your deployments locally, by commenting out that line.
 
-1. Save the changes you made to your `gitlab.rb` file, then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the changes you made to your `gitlab.rb` file, then [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ## 404 error `The page you're looking for could not be found`
 
diff --git a/doc/administration/polling.md b/doc/administration/polling.md
index deb6e89183d..50dbc7467d3 100644
--- a/doc/administration/polling.md
+++ b/doc/administration/polling.md
@@ -26,7 +26,8 @@ The default value (`1`) is recommended for the majority of GitLab installations.
 
 To adjust the polling interval multiplier:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Preferences**.
 1. Expand **Polling interval multiplier**.
 1. Set a value for the polling interval multiplier. This multiplier is applied to all resources at
diff --git a/doc/administration/postgresql/database_load_balancing.md b/doc/administration/postgresql/database_load_balancing.md
index d5cf93a135a..cc550dbe389 100644
--- a/doc/administration/postgresql/database_load_balancing.md
+++ b/doc/administration/postgresql/database_load_balancing.md
@@ -76,22 +76,31 @@ Database Load Balancing can be configured in one of two ways:
 
 ### Hosts
 
-To configure a list of hosts, perform these steps on all GitLab Rails (Sidekiq)
+<!-- Including the Primary host in Database Load Balancing is now recommended for improved performance - Approved by the Reference Architecture and Database groups. -->
+
+To configure a list of hosts, perform these steps on all GitLab Rails and Sidekiq
 nodes for each environment you want to balance:
 
 1. Edit the `/etc/gitlab/gitlab.rb` file.
-1. In `gitlab_rails['db_load_balancing']`, create an array of the read-only
-   replicas you want to balance. Do not add the primary host. For example, on
+1. In `gitlab_rails['db_load_balancing']`, create the array of the database
+   hosts you want to balance. For example, on
    an environment with PostgreSQL running on the hosts `primary.example.com`,
-   `host1.example.com`, `host2.example.com`, and `host3.example.com`:
+   `secondary1.example.com`, `secondary2.example.com`:
 
    ```ruby
-   gitlab_rails['db_load_balancing'] = { 'hosts' => ['host1.example.com', 'host2.example.com', `host3.example.com`] }
+   gitlab_rails['db_load_balancing'] = { 'hosts' => ['primary.example.com', 'secondary1.example.com', 'secondary2.example.com'] }
    ```
 
-   These replicas must be reachable on the same port configured with `gitlab_rails['db_port']`.
+   These hosts must be reachable on the same port configured with `gitlab_rails['db_port']`.
+
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+NOTE:
+Adding the primary to the hosts list is optional, but recommended.
+This makes the primary eligible for load-balanced read queries, improving system performance
+when the primary has capacity for these queries.
+Very high-traffic instances may not have capacity on the primary for it to serve as a read replica.
+The primary will be used for write queries whether or not it is present in this list.
 
 ### Service Discovery
 
@@ -121,7 +130,7 @@ record. For example:
   }
   ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 | Option               | Description                                                                                       | Default   |
 |----------------------|---------------------------------------------------------------------------------------------------|-----------|
@@ -173,7 +182,7 @@ To configure these options with a hosts list, use the following example:
 
 ```ruby
 gitlab_rails['db_load_balancing'] = {
-  'hosts' => ['host1.example.com', 'host2.example.com', `host3.example.com`]
+  'hosts' => ['primary.example.com', 'secondary1.example.com', 'secondary2.example.com']
   'max_replication_difference' => 16777216 # 16 MB
   'max_replication_lag_time' => 30
   'replica_check_interval' => 30
diff --git a/doc/administration/postgresql/multiple_databases.md b/doc/administration/postgresql/multiple_databases.md
index 857fd4fc9c5..f03781d0ee2 100644
--- a/doc/administration/postgresql/multiple_databases.md
+++ b/doc/administration/postgresql/multiple_databases.md
@@ -15,10 +15,10 @@ By default, GitLab uses a single application database, referred to as the `main`
 
 To scale GitLab, you can configure GitLab to use multiple application databases.
 
-Due to [known issues](#known-issues), configuring GitLab with multiple databases is an [Experiment](../../policy/alpha-beta-support.md#experiment).
+Due to [known issues](#known-issues), configuring GitLab with multiple databases is an [Experiment](../../policy/experiment-beta-support.md#experiment).
 
 After you have set up multiple databases, GitLab uses a second application database for
-[CI/CD features](../../ci/index.md), referred to as the `ci` database.
+[CI/CD features](../../ci/index.md), referred to as the `ci` database. We do not exclude hosting both databases on a single PostgreSQL instance.
 
 All tables have exactly the same structure in both the `main`, and `ci`
 databases. Some examples:
diff --git a/doc/administration/postgresql/replication_and_failover.md b/doc/administration/postgresql/replication_and_failover.md
index 8ac3ac40a75..392f9f2b89c 100644
--- a/doc/administration/postgresql/replication_and_failover.md
+++ b/doc/administration/postgresql/replication_and_failover.md
@@ -328,10 +328,10 @@ consul['configuration'] = {
 All database nodes use the same configuration. The leader node is not determined in configuration,
 and there is no additional or different configuration for either leader or replica nodes.
 
-After the configuration of a node is complete, you must [reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+After the configuration of a node is complete, you must [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
 on each node for the changes to take effect.
 
-Generally, when Consul cluster is ready, the first node that [reconfigures](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+Generally, when Consul cluster is ready, the first node that [reconfigures](../restart_gitlab.md#reconfigure-a-linux-package-installation)
 becomes the leader. You do not need to sequence the nodes reconfiguration. You can run them in parallel or in any order.
 If you choose an arbitrary order, you do not have any predetermined leader.
 
@@ -552,7 +552,7 @@ attributes set, but the following need to be set.
    gitlab_rails['db_load_balancing'] = { 'hosts' => ['POSTGRESQL_NODE_1', 'POSTGRESQL_NODE_2', 'POSTGRESQL_NODE_3'] }
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Application node post-configuration
 
@@ -625,7 +625,7 @@ consul['configuration'] = {
 consul['monitoring_service_discovery'] =  true
 ```
 
-[Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+[Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Example recommended setup for PgBouncer servers
 
@@ -654,7 +654,7 @@ consul['configuration'] = {
 consul['monitoring_service_discovery'] =  true
 ```
 
-[Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+[Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Internal load balancer setup
 
@@ -703,7 +703,7 @@ consul['configuration'] = {
 consul['monitoring_service_discovery'] =  true
 ```
 
-[Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+[Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Example recommended setup manual steps
 
@@ -979,7 +979,7 @@ You can switch an exiting database cluster to use Patroni instead of repmgr with
 
 1. On the primary node, [configure Patroni](#configuring-patroni-cluster). Remove `repmgr` and any other
    repmgr-specific configuration. Also remove any configuration that is related to PostgreSQL replication.
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on the primary node.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) on the primary node.
    It makes it the leader. You can check this with:
 
    ```shell
@@ -1076,6 +1076,10 @@ Considering these, you should carefully plan your PostgreSQL upgrade:
    sudo gitlab-ctl pg-upgrade -V 13
    ```
 
+If issues are encountered upgrading the replicas,
+[there is a troubleshooting section](#postgresql-major-version-upgrade-fails-on-a-patroni-replica)
+that might be the solution.
+
 NOTE:
 Reverting the PostgreSQL upgrade with `gitlab-ctl revert-pg-upgrade` has the same considerations as
 `gitlab-ctl pg-upgrade`. You should follow the same procedure by first stopping the replicas,
@@ -1157,7 +1161,7 @@ In addition to the common configuration, you must apply the following in `gitlab
    ```
 
 1. Make sure that Consul agents don't mix PostgreSQL services offered by the existing and the new Patroni
-   clusters. For this purpose, you must use an internal attribute that is currently undocumented:
+   clusters. For this purpose, you must use an internal attribute:
 
    ```ruby
    consul['internal']['postgresql_service_name'] = 'postgresql_new'
@@ -1301,7 +1305,7 @@ To fix the problem, add the IP address to `/etc/gitlab/gitlab.rb`.
 postgresql['trust_auth_cidr_addresses'] = %w(123.123.123.123/32 <other_cidrs>)
 ```
 
-[Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+[Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### Reinitialize a replica
 
@@ -1329,7 +1333,7 @@ If a replica cannot start or rejoin the cluster, or when it lags behind and cann
 
    This can be run on any Patroni node, but be aware that `sudo gitlab-ctl patroni
    reinitialize-replica` without `--member` restarts the server it is run on.
-   It is recommended to run it locally on the broken server to reduce the risk of
+   You should run it locally on the broken server to reduce the risk of
    unintended data loss.
 1. Monitor the logs:
 
@@ -1340,15 +1344,42 @@ If a replica cannot start or rejoin the cluster, or when it lags behind and cann
 ### Reset the Patroni state in Consul
 
 WARNING:
-This is a destructive process and may lead the cluster into a bad state. Make sure that you have a healthy backup before running this process.
+Resetting the Patroni state in Consul is a potentially destructive process. Make sure that you have a healthy database backup first.
+
+As a last resort you can reset the Patroni state in Consul completely.
+
+This may be required if your Patroni cluster is in an unknown or bad state and no node can start:
+
+```plaintext
++ Cluster: postgresql-ha (6970678148837286213) ------+---------+---------+----+-----------+
+| Member                              | Host         | Role    | State   | TL | Lag in MB |
++-------------------------------------+--------------+---------+---------+----+-----------+
+| gitlab-database-1.example.com       | 172.18.0.111 | Replica | stopped |    |   unknown |
+| gitlab-database-2.example.com       | 172.18.0.112 | Replica | stopped |    |   unknown |
+| gitlab-database-3.example.com       | 172.18.0.113 | Replica | stopped |    |   unknown |
++-------------------------------------+--------------+---------+---------+----+-----------+
+```
 
-As a last resort, if your Patroni cluster is in an unknown or bad state and no node can start, you can
-reset the Patroni state in Consul completely, resulting in a reinitialized Patroni cluster when
+**Before deleting the Patroni state in Consul**,
+[try and resolve the `gitlab-ctl` errors](#errors-running-gitlab-ctl) on the Patroni nodes.
+
+This process results in a reinitialized Patroni cluster when
 the first Patroni node starts.
 
 To reset the Patroni state in Consul:
 
-1. Take note of the Patroni node that was the leader, or that the application thinks is the current leader, if the current state shows more than one, or none. One way to do this is to look on the PgBouncer nodes in `/var/opt/gitlab/consul/databases.ini`, which contains the hostname of the current leader.
+1. Take note of the Patroni node that was the leader, or that the application thinks is the current leader,
+   if the current state shows more than one, or none:
+   - Look on the PgBouncer nodes in `/var/opt/gitlab/consul/databases.ini`,
+     which contains the hostname of the current leader.
+   - Look in the Patroni logs `/var/log/gitlab/patroni/current` (or the older rotated and
+     compressed logs `/var/log/gitlab/patroni/@40000*`) on **all** database nodes to see
+     which server was most recently identified as the leader by the cluster:
+
+     ```plaintext
+     INFO: no action. I am a secondary (database1.local) and following a leader (database2.local)
+     ```
+
 1. Stop Patroni on all nodes:
 
    ```shell
@@ -1395,7 +1426,7 @@ To fix the problem, ensure the loopback interface is included in the CIDR addres
    postgresql['trust_auth_cidr_addresses'] = %w(<other_cidrs> 127.0.0.1/32)
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Check that [all the replicas are synchronized](#check-replication-status)
 
 ### Errors in Patroni logs: the requested start point is ahead of the Write Ahead Log (WAL) flush position
@@ -1435,10 +1466,243 @@ Workarounds:
 - If set to enforcing, SELinux may also prevent these operations. Verify the issue is fixed by setting
   SELinux to permissive.
 
-Patroni has been shipping with Omnibus GitLab since 13.1, along with a build of Python 3.7.
-Workarounds should stop being required when GitLab 14.x starts shipping with
-[a later version of Python](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6164) as
-the code which causes this was removed from Python 3.8.
+Patroni first shipped in Omnibus GitLab 13.1, along with a build of Python 3.7.
+The code which causes this was removed in Python 3.8: this fix shipped in
+[Omnibus GitLab 14.3](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5547)
+and later, removing the need for a workaround.
+
+### Errors running `gitlab-ctl`
+
+Patroni nodes can get into a state where `gitlab-ctl` commands fail
+and `gitlab-ctl reconfigure` cannot fix the node.
+
+If this co-incides with a version upgrade of PostgreSQL, [follow a different procedure](#postgresql-major-version-upgrade-fails-on-a-patroni-replica)
+
+One common symptom is that `gitlab-ctl` cannot determine
+information it needs about the installation if the database server is failing to start:
+
+```plaintext
+Malformed configuration JSON file found at /opt/gitlab/embedded/nodes/<HOSTNAME>.json.
+This usually happens when your last run of `gitlab-ctl reconfigure` didn't complete successfully.
+```
+
+```plaintext
+Error while reinitializing replica on the current node: Attributes not found in
+/opt/gitlab/embedded/nodes/<HOSTNAME>.json, has reconfigure been run yet?
+```
+
+Similarly, the nodes file (`/opt/gitlab/embedded/nodes/<HOSTNAME>.json`) should contain a lot of information,
+but might get created with only:
+
+```json
+{
+  "name": "<HOSTNAME>"
+}
+```
+
+The following process for fixing this includes reinitializing this replica:
+the current state of PostgreSQL on this node is discarded:
+
+1. Shut down the Patroni and (if present) PostgreSQL services:
+
+   ```shell
+   sudo gitlab-ctl status
+   sudo gitlab-ctl stop patroni
+   sudo gitlab-ctl stop postgresql
+   ```
+
+1. Remove `/var/opt/gitlab/postgresql/data` in case its state prevents
+   PostgreSQL from starting:
+
+   ```shell
+   cd /var/opt/gitlab/postgresql
+   sudo rm -rf data
+   ```
+
+   **Take care with this step to avoid data loss**.
+   This step can be also achieved by renaming `data/`:
+   make sure there's enough free disk for a new copy of the primary database,
+   and remove the extra directory when the replica is fixed.
+
+1. With PostgreSQL not running, the nodes file now gets created successfully:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Start Patroni:
+
+   ```shell
+   sudo gitlab-ctl start patroni
+   ```
+
+1. Monitor the logs and check the cluster state:
+
+   ```shell
+   sudo gitlab-ctl tail patroni
+   sudo gitlab-ctl patroni members
+   ```
+
+1. Re-run `reconfigure` again:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Reinitialize the replica if `gitlab-ctl patroni members` indicates this is needed:
+
+   ```shell
+   sudo gitlab-ctl patroni reinitialize-replica
+   ```
+
+If this procedure doesn't work **and** if the cluster is unable to elect a leader,
+[there is a another fix](#reset-the-patroni-state-in-consul) which should only be
+used as a last resort.
+
+### PostgreSQL major version upgrade fails on a Patroni replica
+
+A Patroni **replica** can get stuck in a loop during `gitlab-ctl pg-upgrade`, and
+the upgrade fails.
+
+An example set of symptoms is as follows:
+
+1. A `postgresql` service is defined,
+   which shouldn't usually be present on a Patroni node. It is present because
+   `gitlab-ctl pg-upgrade` adds it to create a new empty database:
+
+   ```plaintext
+   run: patroni: (pid 1972) 1919s; run: log: (pid 1971) 1919s
+   down: postgresql: 1s, normally up, want up; run: log: (pid 1973) 1919s
+   ```
+
+1. PostgreSQL generates `PANIC` log entries in
+   `/var/log/gitlab/postgresql/current` as Patroni is removing
+   `/var/opt/gitlab/postgresql/data` as part of reinitializing the replica:
+
+   ```plaintext
+   DETAIL:  Could not open file "pg_xact/0000": No such file or directory.
+   WARNING:  terminating connection because of crash of another server process
+   LOG:  all server processes terminated; reinitializing
+   PANIC:  could not open file "global/pg_control": No such file or directory
+   ```
+
+1. In `/var/log/gitlab/patroni/current`, Patroni logs the following.
+   The local PostgreSQL version is different from the cluster leader:
+
+   ```plaintext
+   INFO: trying to bootstrap from leader 'HOSTNAME'
+   pg_basebackup: incompatible server version 12.6
+   pg_basebackup: removing data directory "/var/opt/gitlab/postgresql/data"
+   ERROR: Error when fetching backup: pg_basebackup exited with code=1
+   ```
+
+**Important**: This workaround applies when the Patroni cluster is in the following state:
+
+- The [leader has been successfully upgraded to the new major version](#upgrading-postgresql-major-version-in-a-patroni-cluster).
+- The step to upgrade PostgreSQL on replicas is failing.
+
+This workaround completes the PostgreSQL upgrade on a Patroni replica
+by setting the node to use the new PostgreSQL version, and then reinitializing
+it as a replica in the new cluster that was created
+when the leader was upgraded:
+
+1. Check the cluster status on all nodes to confirm which is the leader
+   and what state the replicas are in
+
+   ```shell
+   sudo gitlab-ctl patroni members
+   ```
+
+1. Replica: check which version of PostgreSQL is active:
+
+   ```shell
+   sudo ls -al /opt/gitlab/embedded/bin | grep postgres
+   ```
+
+1. Replica: ensure the nodes file is correct and `gitlab-ctl` can run. This resolves
+   the [errors running `gitlab-ctl`](#errors-running-gitlab-ctl) issue if the replica
+   has any of those errors as well:
+
+   ```shell
+   sudo gitlab-ctl stop patroni
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Replica: relink the PostgreSQL binaries to the required version
+   to fix the `incompatible server version` error:
+
+   1. Edit `/etc/gitlab/gitlab.rb` and specify the required version:
+
+      ```ruby
+      postgresql['version'] = 13
+      ```
+
+   1. Reconfigure GitLab:
+
+      ```shell
+      sudo gitlab-ctl reconfigure
+      ```
+
+   1. Check the binaries are relinked. The binaries distributed for
+      PostgreSQL vary between major releases, it's typical to
+      have a small number of incorrect symbolic links:
+
+      ```shell
+      sudo ls -al /opt/gitlab/embedded/bin | grep postgres
+      ```
+
+1. Replica: ensure PostgreSQL is fully reinitialized for the specified version:
+
+   ```shell
+   cd /var/opt/gitlab/postgresql
+   sudo rm -rf data
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Replica: optionally monitor the database in two additional terminal sessions:
+
+   - Disk use increases as `pg_basebackup` runs. Track progress of the
+     replica initialization with:
+
+     ```shell
+     cd /var/opt/gitlab/postgresql
+     watch du -sh data
+     ```
+
+   - Monitor the process in the logs:
+
+     ```shell
+     sudo gitlab-ctl tail patroni
+     ```
+
+1. Replica: Start Patroni to reinitialize the replica:
+
+   ```shell
+   sudo gitlab-ctl start patroni
+   ```
+
+1. Replica: After it completes, remove the hardcoded version from `/etc/gitlab/gitlab.rb`:
+
+   1. Edit `/etc/gitlab/gitlab.rb` and remove `postgresql['version']`.
+   1. Reconfigure GitLab:
+
+      ```shell
+      sudo gitlab-ctl reconfigure
+      ```
+
+   1. Check the correct binaries are linked:
+
+      ```shell
+      sudo ls -al /opt/gitlab/embedded/bin | grep postgres
+      ```
+
+1. Check the cluster status on all nodes:
+
+   ```shell
+   sudo gitlab-ctl patroni members
+   ```
+
+Repeat this procedure on the other replica if required.
 
 ### Issues with other components
 
diff --git a/doc/administration/postgresql/standalone.md b/doc/administration/postgresql/standalone.md
index 77ff9fd2fe1..d00310ecee0 100644
--- a/doc/administration/postgresql/standalone.md
+++ b/doc/administration/postgresql/standalone.md
@@ -57,7 +57,7 @@ together with Omnibus GitLab. This is recommended as part of our
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Note the PostgreSQL node's IP address or hostname, port, and
    plain text password. These are necessary when configuring the GitLab
    application servers later.
diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md
index 2cb664b0859..e55a0f1c8a7 100644
--- a/doc/administration/raketasks/check.md
+++ b/doc/administration/raketasks/check.md
@@ -121,12 +121,14 @@ Integrity checks are supported for the following types of file:
 
 - CI artifacts (introduced in GitLab 10.7.0)
 - LFS objects (introduced in GitLab 10.6.0)
+- Project-level Secure Files (introduced in GitLab 16.1.0)
 - User uploads (introduced in GitLab 10.6.0)
 
 **Omnibus Installation**
 
 ```shell
 sudo gitlab-rake gitlab:artifacts:check
+sudo gitlab-rake gitlab:ci_secure_files:check
 sudo gitlab-rake gitlab:lfs:check
 sudo gitlab-rake gitlab:uploads:check
 ```
@@ -135,6 +137,7 @@ sudo gitlab-rake gitlab:uploads:check
 
 ```shell
 sudo -u git -H bundle exec rake gitlab:artifacts:check RAILS_ENV=production
+sudo -u git -H bundle exec rake gitlab:ci_secure_files:check RAILS_ENV=production
 sudo -u git -H bundle exec rake gitlab:lfs:check RAILS_ENV=production
 sudo -u git -H bundle exec rake gitlab:uploads:check RAILS_ENV=production
 ```
@@ -151,6 +154,7 @@ Variable  | Type    | Description
 
 ```shell
 sudo gitlab-rake gitlab:artifacts:check BATCH=100 ID_FROM=50 ID_TO=250
+sudo gitlab-rake gitlab:ci_secure_files:check BATCH=100 ID_FROM=50 ID_TO=250
 sudo gitlab-rake gitlab:lfs:check BATCH=100 ID_FROM=50 ID_TO=250
 sudo gitlab-rake gitlab:uploads:check BATCH=100 ID_FROM=50 ID_TO=250
 ```
@@ -415,3 +419,37 @@ To update these references to point to local storage:
    ```
 
 The script to [delete references to missing artifacts](check.md#delete-references-to-missing-artifacts) now functions correctly and cleans up the database.
+
+### Delete references to missing secure files
+
+`VERBOSE=1 gitlab-rake gitlab:ci_secure_files:check` detects when secure files:
+
+- Are deleted outside of GitLab.
+- Have references still in the GitLab database.
+
+When this scenario is detected, the Rake task displays an error message. For example:
+
+```shell
+Checking integrity of CI Secure Files
+- 1..15: Failures: 2
+  - Job SecureFile: 9: #<Errno::ENOENT: No such file or directory @ rb_sysopen - /var/opt/gitlab/gitlab-rails/shared/ci_secure_files/4b/22/4b227777d4dd1fc61c6f884f48641d02b4d121d3fd328cb08b5531fcacdabf8a/2022_06_30/8/9/distribution.cer>
+  - Job SecureFile: 15: Remote object does not exist
+Done!
+
+```
+
+To delete these references to missing local or remote secure files:
+
+1. Open the [GitLab Rails Console](../operations/rails_console.md#starting-a-rails-console-session).
+1. Run the following Ruby code:
+
+   ```ruby
+   secure_files_deleted = 0
+   ::Ci::SecureFile.find_each do |secure_file|                    ### Iterate secure files
+     next if secure_file.file.file.exists?                        ### Skip if the file reference is valid
+     secure_files_deleted += 1
+     puts "#{secure_file.id}  #{secure_file.file.path} is missing."     ### Allow verification before destroy
+   #  secure_file.destroy!                                           ### Uncomment to actually destroy
+   end
+   puts "Count of identified/destroyed invalid references: #{secure_files_deleted}"
+   ```
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index 06f7203f695..50c4b004f9c 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/doc/administration/raketasks/maintenance.md
@@ -350,37 +350,54 @@ status in the output of the `sudo gitlab-rake db:migrate:status` command.
    sudo gitlab-ctl restart sidekiq
    ```
 
-## Rebuild database indexes
+## Rebuild database indexes (Experiment)
 
 WARNING:
-This is an experimental feature that isn't enabled by default. It requires PostgreSQL 12 or later.
+This feature is experimental, and isn't enabled by default. Use caution when
+running in a production environment, and run during off-peak times.
 
-Database indexes can be rebuilt regularly to reclaim space and maintain healthy levels of index bloat over time.
+Database indexes can be rebuilt regularly to reclaim space and maintain healthy
+levels of index bloat over time. Reindexing can also be run as a
+[regular cron job](https://docs.gitlab.com/omnibus/settings/database.html#automatic-database-reindexing).
+A "healthy" level of bloat is highly dependent on the specific index, but generally
+should be below 30%.
 
-To rebuild the two indexes with the highest estimated bloat, use the following Rake task:
+Prerequisites:
 
-```shell
-sudo gitlab-rake gitlab:db:reindex
-```
+- This feature requires PostgreSQL 12 or later.
+- These index types are not supported: expression indexes, partitioned indexes,
+  and indexes used for constraint exclusion.
 
-To target a specific index, use the following Rake task:
+To manually rebuild a database index:
 
-```shell
-sudo gitlab-rake gitlab:db:reindex['public.a_specific_index']
-```
+1. Optional. To send annotations to a Grafana (4.6 or later) endpoint, enable annotations
+   with these custom environment variables (see [setting custom environment variables](https://docs.gitlab.com/omnibus/settings/environment-variables.html)):
+
+   1. `GRAFANA_API_URL`: The base URL for Grafana, such as `http://some-host:3000`.
+   1. `GRAFANA_API_KEY`: A Grafana API key with at least `Editor role`.
+
+1. Run the Rake task to rebuild the two indexes with the highest estimated bloat:
+
+   ```shell
+   sudo gitlab-rake gitlab:db:reindex
+   ```
 
-The following index types are not supported:
+1. The reindexing task (`gitlab:db:reindex`) rebuilds only the two indexes in each database
+   with the highest bloat. To rebuild more than two indexes, run the task again
+   until all desired indexes have been rebuilt.
 
-1. Indexes used for constraint exclusion
-1. Partitioned indexes
-1. Expression indexes
+### Notes
 
-Optionally, this Rake task sends annotations to a Grafana (4.6 or later) endpoint. Use the following custom environment variables to enable annotations:
+- Rebuilding database indexes is a disk-intensive task, so you should perform the
+task during off-peak hours. Running the task during peak hours can lead to
+_increased_ bloat, and can also cause certain queries to perform slowly.
 
-1. `GRAFANA_API_URL` - The base URL for Grafana, for example `http://some-host:3000`.
-1. `GRAFANA_API_KEY` - Grafana API key with at least `Editor role`.
+- The task requires free disk space for the index being restored. The created
+indexes are appended with `_ccnew`. If the reindexing task fails, re-running the
+task cleans up the temporary indexes.
 
-You can also [enable reindexing as a regular cron job](https://docs.gitlab.com/omnibus/settings/database.html#automatic-database-reindexing).
+- The time it takes for database index rebuilding to complete depends on the size
+of the target database. It can take between several hours and several days.
 
 ## Import common metrics
 
diff --git a/doc/administration/raketasks/praefect.md b/doc/administration/raketasks/praefect.md
index d1dbc83ad86..1f9eb06f567 100644
--- a/doc/administration/raketasks/praefect.md
+++ b/doc/administration/raketasks/praefect.md
@@ -18,6 +18,8 @@ Rake tasks are available for projects that have been created on Praefect storage
 - The primary Gitaly node.
 - Secondary internal Gitaly nodes.
 
+Run this Rake task on the node that GitLab is installed and not on the node that Praefect is installed.
+
 **Omnibus Installation**
 
 ```shell
diff --git a/doc/administration/raketasks/storage.md b/doc/administration/raketasks/storage.md
index d740aaa9c96..3664a79bf43 100644
--- a/doc/administration/raketasks/storage.md
+++ b/doc/administration/raketasks/storage.md
@@ -109,7 +109,8 @@ sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100
 
 To monitor the progress in GitLab:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Monitoring > Background Jobs**.
 1. Watch how long the `hashed_storage:hashed_storage_project_migrate` queue
    takes to finish. After it reaches zero, you can confirm every project
diff --git a/doc/administration/redis/replication_and_failover.md b/doc/administration/redis/replication_and_failover.md
index a37794ec44b..4a6f58a8d6a 100644
--- a/doc/administration/redis/replication_and_failover.md
+++ b/doc/administration/redis/replication_and_failover.md
@@ -275,7 +275,7 @@ If you fail to replicate first, you may loose data (unprocessed background jobs)
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 NOTE:
 You can specify multiple roles like sentinel and Redis as:
@@ -332,7 +332,7 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes.
 
 NOTE:
@@ -348,11 +348,7 @@ the same Sentinels.
 ### Step 3. Configuring the Redis Sentinel instances
 
 NOTE:
-If you are using an external Redis Sentinel instance, be sure
-to exclude the `requirepass` parameter from the Sentinel
-configuration. This parameter causes clients to report `NOAUTH
-Authentication required.`.
-[Redis Sentinel 3.2.x does not support password authentication](https://github.com/antirez/redis/issues/3279).
+[Support for Sentinel password authentication](https://gitlab.com/gitlab-org/gitlab/-/issues/235938) was introduced in GitLab 16.1.
 
 Now that the Redis servers are all set up, let's configure the Sentinel
 servers.
@@ -408,6 +404,9 @@ multiple machines with the Sentinel daemon.
    ## Configure Sentinel
    sentinel['bind'] = '10.0.0.1'
 
+   ## Optional password for Sentinel authentication. Defaults to no password required.
+   # sentinel['password'] = 'sentinel-password-goes here'
+
    # Port that Sentinel listens on, uncomment to change to non default. Defaults
    # to `26379`.
    # sentinel['port'] = 26379
@@ -458,7 +457,7 @@ multiple machines with the Sentinel daemon.
 
    Only the primary GitLab application server should handle migrations.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other Sentinel nodes.
 
 ### Step 4. Configuring the GitLab application
@@ -493,9 +492,10 @@ which ideally should not have Redis or Sentinels on it for a HA setup.
      {'host' => '10.0.0.2', 'port' => 26379},
      {'host' => '10.0.0.3', 'port' => 26379}
    ]
+   # gitlab_rails['redis_sentinels_password'] = 'sentinel-password-goes-here' # uncomment and set it to the same value as in sentinel['password']
    ```
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### Step 5. Enable Monitoring
 
@@ -570,13 +570,14 @@ redis['master_password'] = 'redis-password-goes-here' # the same value defined i
 redis['master_ip'] = '10.0.0.1' # ip of the initial primary redis instance
 #redis['master_port'] = 6379 # port of the initial primary redis instance, uncomment to change to non default
 sentinel['bind'] = '10.0.0.1'
+# sentinel['password'] = 'sentinel-password-goes-here' # must be the same in every sentinel node, uncomment to set a password
 # sentinel['port'] = 26379 # uncomment to change default port
 sentinel['quorum'] = 2
 # sentinel['down_after_milliseconds'] = 10000
 # sentinel['failover_timeout'] = 60000
 ```
 
-[Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+[Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### Example configuration for Redis replica 1 and Sentinel 2
 
@@ -592,13 +593,14 @@ redis['master_ip'] = '10.0.0.1' # IP of primary Redis server
 #redis['master_port'] = 6379 # Port of primary Redis server, uncomment to change to non default
 redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node
 sentinel['bind'] = '10.0.0.2'
+# sentinel['password'] = 'sentinel-password-goes-here' # must be the same in every sentinel node, uncomment to set a password
 # sentinel['port'] = 26379 # uncomment to change default port
 sentinel['quorum'] = 2
 # sentinel['down_after_milliseconds'] = 10000
 # sentinel['failover_timeout'] = 60000
 ```
 
-[Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+[Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### Example configuration for Redis replica 2 and Sentinel 3
 
@@ -614,13 +616,14 @@ redis['master_ip'] = '10.0.0.1' # IP of primary Redis server
 #redis['master_port'] = 6379 # Port of primary Redis server, uncomment to change to non default
 redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node
 sentinel['bind'] = '10.0.0.3'
+# sentinel['password'] = 'sentinel-password-goes-here' # must be the same in every sentinel node, uncomment to set a password
 # sentinel['port'] = 26379 # uncomment to change default port
 sentinel['quorum'] = 2
 # sentinel['down_after_milliseconds'] = 10000
 # sentinel['failover_timeout'] = 60000
 ```
 
-[Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+[Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### Example configuration for the GitLab application
 
@@ -634,9 +637,10 @@ gitlab_rails['redis_sentinels'] = [
   {'host' => '10.0.0.2', 'port' => 26379},
   {'host' => '10.0.0.3', 'port' => 26379}
 ]
+# gitlab_rails['redis_sentinels_password'] = 'sentinel-password-goes-here' # uncomment and set it to the same value as in sentinel['password']
 ```
 
-[Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+[Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ## Advanced configuration
 
@@ -657,6 +661,7 @@ persistence classes.
 | `trace_chunks` | Store [CI trace chunks](../job_logs.md#enable-or-disable-incremental-logging) data. |
 | `rate_limiting` | Store [rate limiting](../../user/admin_area/settings/user_and_ip_rate_limits.md) state. |
 | `sessions` | Store [sessions](../../../ee/development/session.md#gitlabsession). |
+| `repository_cache` | Store cache data specific to repositories.   |
 
 To make this work with Sentinel:
 
@@ -671,6 +676,7 @@ To make this work with Sentinel:
    gitlab_rails['redis_trace_chunks_instance'] = REDIS_TRACE_CHUNKS_URL
    gitlab_rails['redis_rate_limiting_instance'] = REDIS_RATE_LIMITING_URL
    gitlab_rails['redis_sessions_instance'] = REDIS_SESSIONS_URL
+   gitlab_rails['redis_repository_cache_instance'] = REDIS_REPOSITORY_CACHE_URL
 
    # Configure the Sentinels
    gitlab_rails['redis_cache_sentinels'] = [
@@ -701,6 +707,19 @@ To make this work with Sentinel:
      { host: SESSIONS_SENTINEL_HOST, port: 26379 },
      { host: SESSIONS_SENTINEL_HOST2, port: 26379 }
    ]
+   gitlab_rails['redis_repository_cache_sentinels'] = [
+     { host: REPOSITORY_CACHE_SENTINEL_HOST, port: 26379 },
+     { host: REPOSITORY_CACHE_SENTINEL_HOST2, port: 26379 }
+   ]
+
+   # gitlab_rails['redis_cache_sentinels_password'] = 'sentinel-password-goes-here'
+   # gitlab_rails['redis_queues_sentinels_password'] = 'sentinel-password-goes-here'
+   # gitlab_rails['redis_shared_state_sentinels_password'] = 'sentinel-password-goes-here'
+   # gitlab_rails['redis_actioncable_sentinels_password'] = 'sentinel-password-goes-here'
+   # gitlab_rails['redis_trace_chunks_sentinels_password'] = 'sentinel-password-goes-here'
+   # gitlab_rails['redis_rate_limiting_sentinels_password'] = 'sentinel-password-goes-here'
+   # gitlab_rails['redis_sessions_sentinels_password'] = 'sentinel-password-goes-here'
+   # gitlab_rails['redis_repository_cache_sentinels_password'] = 'sentinel-password-goes-here'
    ```
 
    - Redis URLs should be in the format: `redis://:PASSWORD@SENTINEL_PRIMARY_NAME`, where:
diff --git a/doc/administration/redis/standalone.md b/doc/administration/redis/standalone.md
index c36d75a566d..703601cda42 100644
--- a/doc/administration/redis/standalone.md
+++ b/doc/administration/redis/standalone.md
@@ -42,7 +42,7 @@ Omnibus GitLab:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Note the Redis node's IP address or hostname, port, and
    Redis password. These are necessary when [configuring the GitLab application servers](#set-up-the-gitlab-rails-application-instance).
 
@@ -68,7 +68,7 @@ On the instance where GitLab is installed:
 
 1. Save your changes to `/etc/gitlab/gitlab.rb`.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ## Troubleshooting
 
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index ba4c5fd9046..c3cf7c599a3 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -38,17 +38,11 @@ full list of reference architectures, see
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+    - Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
 3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud Load Balancing](https://cloud.google.com/load-balancing) and [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) are known to work.
-4. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
+4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
 6. Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large
    repositories or monorepos that don't follow these practices can significantly impact Gitaly requirements. Refer to
@@ -387,9 +381,9 @@ backend pgbouncer
     mode tcp
     option tcp-check
 
-    server pgbouncer1 10.6.0.21:6432 check
-    server pgbouncer2 10.6.0.22:6432 check
-    server pgbouncer3 10.6.0.23:6432 check
+    server pgbouncer1 10.6.0.31:6432 check
+    server pgbouncer2 10.6.0.32:6432 check
+    server pgbouncer3 10.6.0.33:6432 check
 
 backend praefect
     mode tcp
@@ -462,7 +456,7 @@ To configure Consul:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Go through the steps again for all the other Consul nodes, and
    make sure you set up the correct IPs.
@@ -504,24 +498,21 @@ cluster to be used with GitLab.
 
 ### Provide your own PostgreSQL instance
 
-If you're hosting GitLab on a cloud provider, you can optionally use a
-managed service for PostgreSQL.
+You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
 
-A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/index.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
-If you use a cloud-managed service, or provide your own PostgreSQL:
+If you use a third party external service:
 
+1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
 1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
    needs privileges to create the `gitlabhq_production` database.
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
-1. For improved performance, configuring [Database Load Balancing](../postgresql/database_load_balancing.md)
-   with multiple read replicas is recommended.
-
-See [Configure GitLab using an external PostgreSQL service](../postgresql/external.md) for
-further configuration steps.
+1. The number of nodes required to achieve HA may differ depending on the service compared to Omnibus and doesn't need to match accordingly.
+1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
 
 ### Standalone PostgreSQL using Omnibus GitLab
 
@@ -665,7 +656,7 @@ For more information, see the various [Patroni replication methods](../postgresq
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 Advanced [configuration options](https://docs.gitlab.com/omnibus/settings/database.html)
 are supported and can be added if needed.
@@ -754,7 +745,7 @@ The following IPs will be used as an example:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
    If an error `execute[generate databases.ini]` occurs, this is due to an existing
    [known issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4713).
@@ -767,7 +758,7 @@ The following IPs will be used as an example:
    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) once again
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) once again
    to resolve any potential errors from the previous steps.
 1. Ensure each node is talking to the current primary:
 
@@ -811,6 +802,9 @@ start the failover procedure.
 NOTE:
 Redis clusters must each be deployed in an odd number of 3 nodes or more. This is to ensure Redis Sentinel can take votes as part of a quorum. This does not apply when configuring Redis externally, such as a cloud provider service.
 
+NOTE:
+Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
+
 Redis requires authentication if used with Sentinel. See
 [Redis Security](https://redis.io/docs/manual/security/) documentation for more
 information. We recommend using a combination of a Redis password and tight
@@ -840,15 +834,11 @@ to be used with GitLab. The following IPs will be used as an example:
 - `10.6.0.62`: Redis - Persistent Replica 1
 - `10.6.0.63`: Redis - Persistent Replica 2
 
-### Providing your own Redis instance
+### Provide your own Redis instance
 
-Managed Redis from cloud providers (such as AWS ElastiCache) will work. If these
-services support high availability, be sure it _isn't_ of the Redis Cluster type.
+You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
 
-Because Omnibus GitLab packages ship with Redis 6.0 or later, Redis 6.0 or later is required. Older Redis versions have reached end-of-life.
-
-Note the Redis node's IP address or hostname, port, and password (if required).
-These will be necessary later when configuring the [GitLab application servers](#configure-gitlab-rails).
+A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 ### Configure the Redis Cache cluster
 
@@ -929,7 +919,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Cache nodes
 
@@ -1002,7 +992,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
 
@@ -1055,7 +1045,7 @@ a node and change its status from primary to replica (and vice versa).
    #redis['master_port'] = 6379
 
    # Set up password authentication for Redis and replicas (use the same password in all nodes).
-   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
+   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
    redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
 
    ## Must be the same in every Redis node
@@ -1084,7 +1074,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Persistent nodes
 
@@ -1147,7 +1137,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
 
@@ -1266,7 +1256,7 @@ in the second step, do not supply the `EXTERNAL_URL` value.
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Follow the [post configuration](#praefect-postgresql-post-configuration).
 
@@ -1498,10 +1488,10 @@ Updates to example must be made at:
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
 
-   1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
+   1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect and
       to run the Praefect database migrations.
 
-1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. On all other Praefect nodes, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### Configure Gitaly
 
@@ -1669,7 +1659,7 @@ Updates to example must be made at:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ### Gitaly Cluster TLS support
 
@@ -1725,7 +1715,7 @@ To configure Praefect with TLS:
    }
    ```
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 1. On the Praefect clients (including each Gitaly server), copy the certificates,
    or their certificate authority, into `/etc/gitlab/trusted-certs`:
@@ -1746,7 +1736,7 @@ To configure Praefect with TLS:
    })
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 <div align="right">
   <a type="button" class="btn btn-default" href="#setup-components">
@@ -1903,7 +1893,7 @@ Updates to example must be made at:
    Only a single designated node should handle migrations as detailed in the
    [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 NOTE:
 If you find that the environment's Sidekiq job processing is slow with long queues,
@@ -2067,7 +2057,7 @@ On each node perform the following:
    Only a single designated node should handle migrations as detailed in the
    [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. [Enable incremental logging](#enable-incremental-logging).
 1. Confirm the node can connect to Gitaly:
 
@@ -2178,7 +2168,7 @@ To configure the Monitoring node:
    nginx['enable'] = true
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. In the GitLab UI, set `admin/application_settings/metrics_and_profiling` > Metrics - Grafana to `/-/grafana` to
 `http[s]://<MONITOR NODE>/-/grafana`
@@ -2194,7 +2184,7 @@ To configure the Monitoring node:
 GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data.
 It's recommended over [NFS](../nfs.md) for data objects and in general it's better
 in larger setups as object storage is typically much more performant, reliable,
-and scalable.
+and scalable. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 There are two ways of specifying object storage configuration in GitLab:
 
@@ -2309,17 +2299,11 @@ services where applicable):
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+    - Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
 3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud Load Balancing](https://cloud.google.com/load-balancing) and [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) are known to work.
-4. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
+4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
 6. Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large
    repositories or monorepos that don't follow these practices can significantly impact Gitaly requirements. Refer to
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index 7984b9dd6c7..37571ed5771 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -38,17 +38,11 @@ full list of reference architectures, see
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
+    - Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
 3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud Load Balancing](https://cloud.google.com/load-balancing) and [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) are known to work.
-4. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
+4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
 6. Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large
    repositories or monorepos that don't follow these practices can significantly impact Gitaly requirements. Refer to
@@ -398,9 +392,9 @@ backend pgbouncer
     mode tcp
     option tcp-check
 
-    server pgbouncer1 10.6.0.21:6432 check
-    server pgbouncer2 10.6.0.22:6432 check
-    server pgbouncer3 10.6.0.23:6432 check
+    server pgbouncer1 10.6.0.31:6432 check
+    server pgbouncer2 10.6.0.32:6432 check
+    server pgbouncer3 10.6.0.33:6432 check
 
 backend praefect
     mode tcp
@@ -479,7 +473,7 @@ To configure Consul:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Go through the steps again for all the other Consul nodes, and
    make sure you set up the correct IPs.
@@ -521,24 +515,21 @@ cluster to be used with GitLab.
 
 ### Provide your own PostgreSQL instance
 
-If you're hosting GitLab on a cloud provider, you can optionally use a
-managed service for PostgreSQL.
+You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
 
-A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/index.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
-If you use a cloud-managed service, or provide your own PostgreSQL:
+If you use a third party external service:
 
+1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
 1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
    needs privileges to create the `gitlabhq_production` database.
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
-1. For improved performance, configuring [Database Load Balancing](../postgresql/database_load_balancing.md)
-   with multiple read replicas is recommended.
-
-See [Configure GitLab using an external PostgreSQL service](../postgresql/external.md) for
-further configuration steps.
+1. The number of nodes required to achieve HA may differ depending on the service compared to Omnibus and doesn't need to match accordingly.
+1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
 
 ### Standalone PostgreSQL using Omnibus GitLab
 
@@ -682,7 +673,7 @@ For more information, see the various [Patroni replication methods](../postgresq
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 Advanced [configuration options](https://docs.gitlab.com/omnibus/settings/database.html)
 are supported and can be added if needed.
@@ -771,7 +762,7 @@ The following IPs will be used as an example:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
    If an error `execute[generate databases.ini]` occurs, this is due to an existing
    [known issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4713).
@@ -784,7 +775,7 @@ The following IPs will be used as an example:
    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) once again
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) once again
    to resolve any potential errors from the previous steps.
 1. Ensure each node is talking to the current primary:
 
@@ -828,6 +819,9 @@ start the failover procedure.
 NOTE:
 Redis clusters must each be deployed in an odd number of 3 nodes or more. This is to ensure Redis Sentinel can take votes as part of a quorum. This does not apply when configuring Redis externally, such as a cloud provider service.
 
+NOTE:
+Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
+
 Redis requires authentication if used with Sentinel. See
 [Redis Security](https://redis.io/docs/manual/security/) documentation for more
 information. We recommend using a combination of a Redis password and tight
@@ -857,15 +851,11 @@ to be used with GitLab. The following IPs will be used as an example:
 - `10.6.0.62`: Redis - Persistent Replica 1
 - `10.6.0.63`: Redis - Persistent Replica 2
 
-### Providing your own Redis instance
-
-Managed Redis from cloud providers (such as AWS ElastiCache) will work. If these
-services support high availability, be sure it _isn't_ of the Redis Cluster type.
+### Provide your own Redis instance
 
-Because Omnibus GitLab packages ship with Redis 6.0 or later, Redis 6.0 or later is required. Older Redis versions have reached end-of-life.
+You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
 
-Note the Redis node's IP address or hostname, port, and password (if required).
-These will be necessary later when configuring the [GitLab application servers](#configure-gitlab-rails).
+A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 ### Configure the Redis Cache cluster
 
@@ -945,7 +935,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Cache nodes
 
@@ -1017,7 +1007,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
@@ -1070,7 +1060,7 @@ a node and change its status from primary to replica (and vice versa).
    #redis['master_port'] = 6379
 
    # Set up password authentication for Redis and replicas (use the same password in all nodes).
-   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
+   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
    redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
 
    ## Must be the same in every Redis node
@@ -1099,7 +1089,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Persistent nodes
 
@@ -1165,7 +1155,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
@@ -1285,7 +1275,7 @@ in the second step, do not supply the `EXTERNAL_URL` value.
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Follow the [post configuration](#praefect-postgresql-post-configuration).
 
@@ -1515,10 +1505,10 @@ the file of the same name on this server. If this is the first Omnibus node you
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
 
-   1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
+   1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect and
       to run the Praefect database migrations.
 
-1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. On all other Praefect nodes, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### Configure Gitaly
 
@@ -1686,7 +1676,7 @@ Updates to example must be made at:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ### Gitaly Cluster TLS support
 
@@ -1742,7 +1732,7 @@ To configure Praefect with TLS:
    }
    ```
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 1. On the Praefect clients (including each Gitaly server), copy the certificates,
    or their certificate authority, into `/etc/gitlab/trusted-certs`:
@@ -1763,7 +1753,7 @@ To configure Praefect with TLS:
    })
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 <div align="right">
   <a type="button" class="btn btn-default" href="#setup-components">
@@ -1920,7 +1910,7 @@ Updates to example must be made at:
    Only a single designated node should handle migrations as detailed in the
    [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 NOTE:
 If you find that the environment's Sidekiq job processing is slow with long queues,
@@ -2086,7 +2076,7 @@ On each node perform the following:
    Only a single designated node should handle migrations as detailed in the
    [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. [Enable incremental logging](#enable-incremental-logging).
 1. Confirm the node can connect to Gitaly:
 
@@ -2197,7 +2187,7 @@ To configure the Monitoring node:
    nginx['enable'] = true
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. In the GitLab UI, set `admin/application_settings/metrics_and_profiling` > Metrics - Grafana to `/-/grafana` to
 `http[s]://<MONITOR NODE>/-/grafana`
 
@@ -2212,7 +2202,7 @@ To configure the Monitoring node:
 GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data.
 It's recommended over [NFS](../nfs.md) for data objects and in general it's better
 in larger setups as object storage is typically much more performant, reliable,
-and scalable.
+and scalable. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 There are two ways of specifying object storage configuration in GitLab:
 
@@ -2327,17 +2317,11 @@ services where applicable):
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
+    - Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
 3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud Load Balancing](https://cloud.google.com/load-balancing) and [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) are known to work.
-4. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
+4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
 6. Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large
    repositories or monorepos that don't follow these practices can significantly impact Gitaly requirements. Refer to
diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md
index 14dc9d26293..455b0fbafd1 100644
--- a/doc/administration/reference_architectures/2k_users.md
+++ b/doc/administration/reference_architectures/2k_users.md
@@ -31,16 +31,10 @@ For a full list of reference architectures, see
 | Object storage<sup>4</sup> | -     | -                      | -               | -            | -        |
 
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440), and [Azure Database for PostgreSQL](https://azure.microsoft.com/en-gb/products/postgresql/#overview) is **not recommended** due to [performance issues](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/61).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud Load Balancing](https://cloud.google.com/load-balancing) and [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) are known to work.
+4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 4. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
 5. Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large
    repositories or monorepos that don't follow these practices can significantly impact Gitaly requirements. Refer to
@@ -253,23 +247,20 @@ to be used with GitLab.
 
 ### Provide your own PostgreSQL instance
 
-If you're hosting GitLab on a cloud provider, you can optionally use a
-managed service for PostgreSQL.
+You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
 
-A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440), and Azure Database for PostgreSQL is **not recommended** due to [performance issues](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/61). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/index.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
-If you use a cloud-managed service, or provide your own PostgreSQL:
+If you use a third party external service:
 
+1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
-1. Create a `gitlab` username with a password of your choice. The `gitlab` user
+1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
    needs privileges to create the `gitlabhq_production` database.
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
 
-See [Configure GitLab using an external PostgreSQL service](../postgresql/external.md) for
-further configuration steps.
-
 ### Standalone PostgreSQL using Omnibus GitLab
 
 1. SSH in to the PostgreSQL server.
@@ -320,7 +311,7 @@ further configuration steps.
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Note the PostgreSQL node's IP address or hostname, port, and
    plain text password. These will be necessary when configuring the
    [GitLab application server](#configure-gitlab-rails) later.
@@ -341,14 +332,9 @@ to be used with GitLab.
 
 ### Provide your own Redis instance
 
-Because Omnibus GitLab packages ship with Redis 6.0 or later, Redis 6.0 or later is required. Older Redis versions have reached end-of-life.
-
-Managed Redis from cloud providers such as AWS ElastiCache will work. If these
-services support high availability, be sure it is not the Redis Cluster type.
+You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
 
-Note the Redis node's IP address or hostname, port, and password (if required).
-These will be necessary when configuring the
-[GitLab application servers](#configure-gitlab-rails) later.
+A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 ### Standalone Redis using Omnibus GitLab
 
@@ -384,7 +370,7 @@ Omnibus:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Note the Redis node's IP address or hostname, port, and
    Redis password. These will be necessary when
@@ -534,7 +520,7 @@ Updates to example must be made at:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Confirm that Gitaly can perform callbacks to the internal API:
    - For GitLab 15.3 and later, run `sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml`.
@@ -597,7 +583,7 @@ To configure Gitaly with TLS:
    ```
 
 1. Delete `gitaly['listen_addr']` to allow only encrypted connections.
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 <div align="right">
   <a type="button" class="btn btn-default" href="#setup-components">
@@ -743,7 +729,7 @@ On each node perform the following:
    Only a single designated node should handle migrations as detailed in the
    [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. [Enable incremental logging](#enable-incremental-logging).
 1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the node can connect to Gitaly.
 
@@ -877,7 +863,7 @@ running [Prometheus](../monitoring/prometheus/index.md) and
    ]
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. In the GitLab UI, set `admin/application_settings/metrics_and_profiling` > Metrics - Grafana to `/-/grafana` to
 `http[s]://<MONITOR NODE>/-/grafana`
 
@@ -892,7 +878,7 @@ running [Prometheus](../monitoring/prometheus/index.md) and
 GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data.
 It's recommended over [NFS](../nfs.md) for data objects and in general it's better
 in larger setups as object storage is typically much more performant, reliable,
-and scalable.
+and scalable. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 There are two ways of specifying object storage configuration in GitLab:
 
@@ -1005,15 +991,9 @@ services where applicable):
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440), and [Azure Database for PostgreSQL](https://azure.microsoft.com/en-gb/products/postgresql/#overview) is **not recommended** due to [performance issues](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/61).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
-3. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+3. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 <!-- markdownlint-enable MD029 -->
 
 NOTE:
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index 191e5218c43..6a7d9864376 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -47,17 +47,10 @@ For a full list of reference architectures, see
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
 3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud Load Balancing](https://cloud.google.com/load-balancing) and [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) are known to work.
-4. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
+4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
 6. Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large
    repositories or monorepos that don't follow these practices can significantly impact Gitaly requirements. Refer to
@@ -187,19 +180,19 @@ connect to each other freely on these addresses.
 The following list includes descriptions of each server and its assigned IP:
 
 - `10.6.0.10`: External Load Balancer
-- `10.6.0.61`: Redis Primary
-- `10.6.0.62`: Redis Replica 1
-- `10.6.0.63`: Redis Replica 2
 - `10.6.0.11`: Consul/Sentinel 1
 - `10.6.0.12`: Consul/Sentinel 2
 - `10.6.0.13`: Consul/Sentinel 3
-- `10.6.0.31`: PostgreSQL primary
-- `10.6.0.32`: PostgreSQL secondary 1
-- `10.6.0.33`: PostgreSQL secondary 2
-- `10.6.0.21`: PgBouncer 1
-- `10.6.0.22`: PgBouncer 2
-- `10.6.0.23`: PgBouncer 3
+- `10.6.0.21`: PostgreSQL primary
+- `10.6.0.22`: PostgreSQL secondary 1
+- `10.6.0.23`: PostgreSQL secondary 2
+- `10.6.0.31`: PgBouncer 1
+- `10.6.0.32`: PgBouncer 2
+- `10.6.0.33`: PgBouncer 3
 - `10.6.0.20`: Internal Load Balancer
+- `10.6.0.61`: Redis Primary
+- `10.6.0.62`: Redis Replica 1
+- `10.6.0.63`: Redis Replica 2
 - `10.6.0.51`: Gitaly 1
 - `10.6.0.52`: Gitaly 2
 - `10.6.0.93`: Gitaly 3
@@ -399,9 +392,9 @@ backend pgbouncer
     mode tcp
     option tcp-check
 
-    server pgbouncer1 10.6.0.21:6432 check
-    server pgbouncer2 10.6.0.22:6432 check
-    server pgbouncer3 10.6.0.23:6432 check
+    server pgbouncer1 10.6.0.31:6432 check
+    server pgbouncer2 10.6.0.32:6432 check
+    server pgbouncer3 10.6.0.33:6432 check
 
 backend praefect
     mode tcp
@@ -435,6 +428,9 @@ Using [Redis](https://redis.io/) in scalable environment is possible using a **P
 topology with a [Redis Sentinel](https://redis.io/docs/manual/sentinel/) service to watch and automatically
 start the failover procedure.
 
+NOTE:
+Redis clusters must each be deployed in an odd number of 3 nodes or more. This is to ensure Redis Sentinel can take votes as part of a quorum. This does not apply when configuring Redis externally, such as a cloud provider service.
+
 Redis requires authentication if used with Sentinel. See
 [Redis Security](https://redis.io/docs/manual/security/) documentation for more
 information. We recommend using a combination of a Redis password and tight
@@ -452,14 +448,9 @@ to be used with GitLab. The following IPs will be used as an example:
 
 ### Provide your own Redis instance
 
-Managed Redis from cloud providers such as AWS ElastiCache will work. If these
-services support high availability, be sure it is **not** the Redis Cluster type.
-
-Because Omnibus GitLab packages ship with Redis 6.0 or later, Redis 6.0 or later is required. Older Redis versions have reached end-of-life.
+You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
 
-Note the Redis node's IP address or hostname, port, and password (if required).
-These will be necessary when configuring the
-[GitLab application servers](#configure-gitlab-rails) later.
+A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 ### Standalone Redis using Omnibus GitLab
 
@@ -530,7 +521,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 You can specify multiple roles, like sentinel and Redis, as:
 `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
@@ -615,7 +606,7 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
 
@@ -751,7 +742,7 @@ To configure the Sentinel:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Go through the steps again for all the other Consul/Sentinel nodes, and
    make sure you set up the correct IPs.
@@ -794,24 +785,21 @@ cluster to be used with GitLab.
 
 ### Provide your own PostgreSQL instance
 
-If you're hosting GitLab on a cloud provider, you can optionally use a
-managed service for PostgreSQL.
+You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
 
-A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/index.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
-If you use a cloud-managed service, or provide your own PostgreSQL:
+If you use a third party external service:
 
+1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
 1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
    needs privileges to create the `gitlabhq_production` database.
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
-1. For improved performance, configuring [Database Load Balancing](../postgresql/database_load_balancing.md)
-   with multiple read replicas is recommended.
-
-See [Configure GitLab using an external PostgreSQL service](../postgresql/external.md) for
-further configuration steps.
+1. The number of nodes required to achieve HA may differ depending on the service compared to Omnibus and doesn't need to match accordingly.
+1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
 
 ### Standalone PostgreSQL using Omnibus GitLab
 
@@ -828,9 +816,9 @@ replication and failover requires:
 
 The following IPs will be used as an example:
 
-- `10.6.0.31`: PostgreSQL primary
-- `10.6.0.32`: PostgreSQL secondary 1
-- `10.6.0.33`: PostgreSQL secondary 2
+- `10.6.0.21`: PostgreSQL primary
+- `10.6.0.22`: PostgreSQL secondary 1
+- `10.6.0.23`: PostgreSQL secondary 2
 
 First, make sure to [install](https://about.gitlab.com/install/)
 the Linux GitLab package **on each node**. Following the steps,
@@ -955,7 +943,7 @@ For more information, see the various [Patroni replication methods](../postgresq
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 Advanced [configuration options](https://docs.gitlab.com/omnibus/settings/database.html)
 are supported and can be added if needed.
@@ -981,9 +969,9 @@ SSH in to any of the Patroni nodes on the **primary site**:
    ```plaintext
    | Cluster       | Member                            |  Host     | Role   | State   | TL  | Lag in MB | Pending restart |
    |---------------|-----------------------------------|-----------|--------|---------|-----|-----------|-----------------|
-   | postgresql-ha | <PostgreSQL primary hostname>     | 10.6.0.31 | Leader | running | 175 |           | *               |
-   | postgresql-ha | <PostgreSQL secondary 1 hostname> | 10.6.0.32 |        | running | 175 | 0         | *               |
-   | postgresql-ha | <PostgreSQL secondary 2 hostname> | 10.6.0.33 |        | running | 175 | 0         | *               |
+   | postgresql-ha | <PostgreSQL primary hostname>     | 10.6.0.21 | Leader | running | 175 |           | *               |
+   | postgresql-ha | <PostgreSQL secondary 1 hostname> | 10.6.0.22 |        | running | 175 | 0         | *               |
+   | postgresql-ha | <PostgreSQL secondary 2 hostname> | 10.6.0.23 |        | running | 175 | 0         | *               |
    ```
 
 If the 'State' column for any node doesn't say "running", check the
@@ -1003,9 +991,9 @@ for tracking and handling reads/writes to the primary database.
 
 The following IPs will be used as an example:
 
-- `10.6.0.21`: PgBouncer 1
-- `10.6.0.22`: PgBouncer 2
-- `10.6.0.23`: PgBouncer 3
+- `10.6.0.31`: PgBouncer 1
+- `10.6.0.32`: PgBouncer 2
+- `10.6.0.33`: PgBouncer 3
 
 1. On each PgBouncer node, edit `/etc/gitlab/gitlab.rb`, and replace
    `<consul_password_hash>` and `<pgbouncer_password_hash>` with the
@@ -1045,7 +1033,7 @@ The following IPs will be used as an example:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Create a `.pgpass` file so Consul is able to
    reload PgBouncer. Enter the PgBouncer password twice when asked:
@@ -1215,7 +1203,7 @@ in the second step, do not supply the `EXTERNAL_URL` value.
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Follow the [post configuration](#praefect-postgresql-post-configuration).
 
 <div align="right">
@@ -1444,10 +1432,10 @@ the file of the same name on this server. If this is the first Omnibus node you
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
 
-   1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
+   1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect and
       to run the Praefect database migrations.
 
-1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. On all other Praefect nodes, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### Configure Gitaly
 
@@ -1619,7 +1607,7 @@ Updates to example must be made at:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ### Gitaly Cluster TLS support
 
@@ -1675,7 +1663,7 @@ To configure Praefect with TLS:
    }
    ```
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 1. On the Praefect clients (including each Gitaly server), copy the certificates,
    or their certificate authority, into `/etc/gitlab/trusted-certs`:
@@ -1696,7 +1684,7 @@ To configure Praefect with TLS:
    })
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 <div align="right">
   <a type="button" class="btn btn-default" href="#setup-components">
@@ -1781,7 +1769,7 @@ Updates to example must be made at:
    gitlab_rails['db_host'] = '10.6.0.40' # internal load balancer IP
    gitlab_rails['db_port'] = 6432
    gitlab_rails['db_password'] = '<postgresql_user_password>'
-   gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.31', '10.6.0.32', '10.6.0.33'] } # PostgreSQL IPs
+   gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs
 
    ## Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -1848,7 +1836,7 @@ Updates to example must be made at:
    Only a single designated node should handle migrations as detailed in the
    [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 1. Verify the GitLab services are running:
 
@@ -1924,7 +1912,7 @@ On each node perform the following:
    gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer IP
    gitlab_rails['db_port'] = 6432
    gitlab_rails['db_password'] = '<postgresql_user_password>'
-   gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.31', '10.6.0.32', '10.6.0.33'] } # PostgreSQL IPs
+   gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -2038,7 +2026,7 @@ On each node perform the following:
    Only a single designated node should handle migrations as detailed in the
    [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. [Enable incremental logging](#enable-incremental-logging).
 1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the node can connect to Gitaly.
 1. Tail the logs to see the requests:
@@ -2127,9 +2115,9 @@ running [Prometheus](../monitoring/prometheus/index.md) and
          'job_name': 'pgbouncer',
          'static_configs' => [
             'targets' => [
-            "10.6.0.21:9188",
-            "10.6.0.22:9188",
-            "10.6.0.23:9188",
+            "10.6.0.31:9188",
+            "10.6.0.32:9188",
+            "10.6.0.33:9188",
             ],
          ],
       },
@@ -2149,7 +2137,7 @@ running [Prometheus](../monitoring/prometheus/index.md) and
    nginx['enable'] = true
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. In the GitLab UI, set `admin/application_settings/metrics_and_profiling` > Metrics - Grafana to `/-/grafana` to
    `http[s]://<MONITOR NODE>/-/grafana`.
 1. Verify the GitLab services are running:
@@ -2179,7 +2167,7 @@ running [Prometheus](../monitoring/prometheus/index.md) and
 GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data.
 It's recommended over [NFS](../nfs.md) for data objects and in general it's better
 in larger setups as object storage is typically much more performant, reliable,
-and scalable.
+and scalable. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 There are two ways of specifying object storage configuration in GitLab:
 
@@ -2317,17 +2305,10 @@ services where applicable):
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
 3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud Load Balancing](https://cloud.google.com/load-balancing) and [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) are known to work.
-4. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
+4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
 6. Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large
    repositories or monorepos that don't follow these practices can significantly impact Gitaly requirements. Refer to
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index 7d3ddf7578c..9a2c354f27c 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -38,17 +38,11 @@ full list of reference architectures, see
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
+    - Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
 3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud Load Balancing](https://cloud.google.com/load-balancing) and [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) are known to work.
-4. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
+4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
 6. Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large
    repositories or monorepos that don't follow these practices can significantly impact Gitaly requirements. Refer to
@@ -396,9 +390,9 @@ backend pgbouncer
     mode tcp
     option tcp-check
 
-    server pgbouncer1 10.6.0.21:6432 check
-    server pgbouncer2 10.6.0.22:6432 check
-    server pgbouncer3 10.6.0.23:6432 check
+    server pgbouncer1 10.6.0.31:6432 check
+    server pgbouncer2 10.6.0.32:6432 check
+    server pgbouncer3 10.6.0.33:6432 check
 
 backend praefect
     mode tcp
@@ -471,7 +465,7 @@ To configure Consul:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Go through the steps again for all the other Consul nodes, and
    make sure you set up the correct IPs.
@@ -513,24 +507,21 @@ cluster to be used with GitLab.
 
 ### Provide your own PostgreSQL instance
 
-If you're hosting GitLab on a cloud provider, you can optionally use a
-managed service for PostgreSQL.
+You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
 
-A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/index.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
-If you use a cloud-managed service, or provide your own PostgreSQL:
+If you use a third party external service:
 
+1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
 1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
    needs privileges to create the `gitlabhq_production` database.
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
-1. For improved performance, configuring [Database Load Balancing](../postgresql/database_load_balancing.md)
-   with multiple read replicas is recommended.
-
-See [Configure GitLab using an external PostgreSQL service](../postgresql/external.md) for
-further configuration steps.
+1. The number of nodes required to achieve HA may differ depending on the service compared to Omnibus and doesn't need to match accordingly.
+1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
 
 ### Standalone PostgreSQL using Omnibus GitLab
 
@@ -675,7 +666,7 @@ For more information, see the various [Patroni replication methods](../postgresq
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 Advanced [configuration options](https://docs.gitlab.com/omnibus/settings/database.html)
 are supported and can be added if needed.
@@ -764,7 +755,7 @@ The following IPs will be used as an example:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
    If an error `execute[generate databases.ini]` occurs, this is due to an existing
    [known issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4713).
@@ -777,7 +768,7 @@ The following IPs will be used as an example:
    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
    ```
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) once again
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) once again
    to resolve any potential errors from the previous steps.
 1. Ensure each node is talking to the current primary:
 
@@ -821,6 +812,9 @@ start the failover procedure.
 NOTE:
 Redis clusters must each be deployed in an odd number of 3 nodes or more. This is to ensure Redis Sentinel can take votes as part of a quorum. This does not apply when configuring Redis externally, such as a cloud provider service.
 
+NOTE:
+Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
+
 Redis requires authentication if used with Sentinel. See
 [Redis Security](https://redis.io/docs/manual/security/) documentation for more
 information. We recommend using a combination of a Redis password and tight
@@ -850,15 +844,11 @@ to be used with GitLab. The following IPs will be used as an example:
 - `10.6.0.62`: Redis - Persistent Replica 1
 - `10.6.0.63`: Redis - Persistent Replica 2
 
-### Providing your own Redis instance
+### Provide your own Redis instance
 
-Managed Redis from cloud providers (such as AWS ElastiCache) will work. If these
-services support high availability, be sure it _isn't_ of the Redis Cluster type.
+You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
 
-Because Omnibus GitLab packages ship with Redis 6.0 or later, Redis 6.0 or later is required. Older Redis versions have reached end-of-life.
-
-Note the Redis node's IP address or hostname, port, and password (if required).
-These will be necessary later when configuring the [GitLab application servers](#configure-gitlab-rails).
+A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 ### Configure the Redis Cache cluster
 
@@ -939,7 +929,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Cache nodes
 
@@ -1014,7 +1004,7 @@ a node and change its status from primary to replica (and vice versa).
       server. If this is the first Omnibus node you are configuring then you
       can skip this step.
 
-   1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes
+   1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes
       to take effect.
 
    1. Go through the steps again for all the other replica nodes, and
@@ -1068,7 +1058,7 @@ a node and change its status from primary to replica (and vice versa).
    #redis['master_port'] = 6379
 
    # Set up password authentication for Redis and replicas (use the same password in all nodes).
-   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
+   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
    redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
 
    ## Must be the same in every Redis node
@@ -1097,7 +1087,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Persistent nodes
 
@@ -1160,7 +1150,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
@@ -1279,7 +1269,7 @@ in the second step, do not supply the `EXTERNAL_URL` value.
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Follow the [post configuration](#praefect-postgresql-post-configuration).
 
@@ -1511,10 +1501,10 @@ the file of the same name on this server. If this is the first Omnibus node you
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
 
-   1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
+   1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect and
       to run the Praefect database migrations.
 
-1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. On all other Praefect nodes, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### Configure Gitaly
 
@@ -1682,7 +1672,7 @@ Updates to example must be made at:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ### Gitaly Cluster TLS support
 
@@ -1738,7 +1728,7 @@ To configure Praefect with TLS:
    }
    ```
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 1. On the Praefect clients (including each Gitaly server), copy the certificates,
    or their certificate authority, into `/etc/gitlab/trusted-certs`:
@@ -1759,7 +1749,7 @@ To configure Praefect with TLS:
    })
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 <div align="right">
   <a type="button" class="btn btn-default" href="#setup-components">
@@ -1916,7 +1906,7 @@ Updates to example must be made at:
    Only a single designated node should handle migrations as detailed in the
    [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 NOTE:
 If you find that the environment's Sidekiq job processing is slow with long queues,
@@ -2085,7 +2075,7 @@ On each node perform the following:
    Only a single designated node should handle migrations as detailed in the
    [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. [Enable incremental logging](#enable-incremental-logging).
 1. Confirm the node can connect to Gitaly:
 
@@ -2196,7 +2186,7 @@ To configure the Monitoring node:
    nginx['enable'] = true
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. In the GitLab UI, set `admin/application_settings/metrics_and_profiling` > Metrics - Grafana to `/-/grafana` to
 `http[s]://<MONITOR NODE>/-/grafana`
 
@@ -2211,7 +2201,7 @@ To configure the Monitoring node:
 GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data.
 It's recommended over [NFS](../nfs.md) for data objects and in general it's better
 in larger setups as object storage is typically much more performant, reliable,
-and scalable.
+and scalable. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 There are two ways of specifying object storage configuration in GitLab:
 
@@ -2326,17 +2316,11 @@ services where applicable):
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
+    - Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
 3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud Load Balancing](https://cloud.google.com/load-balancing) and [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) are known to work.
-4. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
+4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
 6. Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large
    repositories or monorepos that don't follow these practices can significantly impact Gitaly requirements. Refer to
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index 82087c91910..b0bc70aaf00 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -44,17 +44,10 @@ costly-to-operate environment by using the
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
 3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud Load Balancing](https://cloud.google.com/load-balancing) and [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) are known to work.
-4. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
+4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
 6. Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large
    repositories or monorepos that don't follow these practices can significantly impact Gitaly requirements. Refer to
@@ -184,19 +177,19 @@ connect to each other freely on these addresses.
 The following list includes descriptions of each server and its assigned IP:
 
 - `10.6.0.10`: External Load Balancer
-- `10.6.0.61`: Redis Primary
-- `10.6.0.62`: Redis Replica 1
-- `10.6.0.63`: Redis Replica 2
 - `10.6.0.11`: Consul/Sentinel 1
 - `10.6.0.12`: Consul/Sentinel 2
 - `10.6.0.13`: Consul/Sentinel 3
-- `10.6.0.31`: PostgreSQL primary
-- `10.6.0.32`: PostgreSQL secondary 1
-- `10.6.0.33`: PostgreSQL secondary 2
-- `10.6.0.21`: PgBouncer 1
-- `10.6.0.22`: PgBouncer 2
-- `10.6.0.23`: PgBouncer 3
+- `10.6.0.21`: PostgreSQL primary
+- `10.6.0.22`: PostgreSQL secondary 1
+- `10.6.0.23`: PostgreSQL secondary 2
+- `10.6.0.31`: PgBouncer 1
+- `10.6.0.32`: PgBouncer 2
+- `10.6.0.33`: PgBouncer 3
 - `10.6.0.20`: Internal Load Balancer
+- `10.6.0.61`: Redis Primary
+- `10.6.0.62`: Redis Replica 1
+- `10.6.0.63`: Redis Replica 2
 - `10.6.0.51`: Gitaly 1
 - `10.6.0.52`: Gitaly 2
 - `10.6.0.93`: Gitaly 3
@@ -396,9 +389,9 @@ backend pgbouncer
     mode tcp
     option tcp-check
 
-    server pgbouncer1 10.6.0.21:6432 check
-    server pgbouncer2 10.6.0.22:6432 check
-    server pgbouncer3 10.6.0.23:6432 check
+    server pgbouncer1 10.6.0.31:6432 check
+    server pgbouncer2 10.6.0.32:6432 check
+    server pgbouncer3 10.6.0.33:6432 check
 
 backend praefect
     mode tcp
@@ -449,14 +442,9 @@ to be used with GitLab. The following IPs are used as an example:
 
 ### Provide your own Redis instance
 
-Managed Redis from cloud providers such as AWS ElastiCache works. If these
-services support high availability, be sure it is **not** the Redis Cluster type.
-
-Because Omnibus GitLab packages ship with Redis 6.0 or later, Redis 6.0 or later is required. Older Redis versions have reached end-of-life.
+You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
 
-Note the Redis node's IP address or hostname, port, and password (if required).
-These are necessary when configuring the
-[GitLab application servers](#configure-gitlab-rails) later.
+A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 ### Standalone Redis using Omnibus GitLab
 
@@ -527,7 +515,7 @@ a node and change its status from primary to replica (and vice versa).
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 You can specify multiple roles, like sentinel and Redis, as:
 `roles(['redis_sentinel_role', 'redis_master_role'])`. Read more about
@@ -612,7 +600,7 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
 
@@ -748,7 +736,7 @@ To configure the Sentinel:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other Consul/Sentinel nodes, and
    make sure you set up the correct IPs.
 
@@ -790,24 +778,21 @@ cluster to be used with GitLab.
 
 ### Provide your own PostgreSQL instance
 
-If you're hosting GitLab on a cloud provider, you can optionally use a
-managed service for PostgreSQL.
+You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
 
-A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
+A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/index.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
-If you use a cloud-managed service, or provide your own PostgreSQL:
+If you use a third party external service:
 
+1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
 1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
    needs privileges to create the `gitlabhq_production` database.
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
-1. For improved performance, configuring [Database Load Balancing](../postgresql/database_load_balancing.md)
-   with multiple read replicas is recommended.
-
-See [Configure GitLab using an external PostgreSQL service](../postgresql/external.md) for
-further configuration steps.
+1. The number of nodes required to achieve HA may differ depending on the service compared to Omnibus and doesn't need to match accordingly.
+1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
 
 ### Standalone PostgreSQL using Omnibus GitLab
 
@@ -824,9 +809,9 @@ replication and failover requires:
 
 The following IPs are used as an example:
 
-- `10.6.0.31`: PostgreSQL primary
-- `10.6.0.32`: PostgreSQL secondary 1
-- `10.6.0.33`: PostgreSQL secondary 2
+- `10.6.0.21`: PostgreSQL primary
+- `10.6.0.22`: PostgreSQL secondary 1
+- `10.6.0.23`: PostgreSQL secondary 2
 
 First, make sure to [install](https://about.gitlab.com/install/)
 the Linux GitLab package **on each node**. Following the steps,
@@ -951,7 +936,7 @@ For more information, see the various [Patroni replication methods](../postgresq
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 Advanced [configuration options](https://docs.gitlab.com/omnibus/settings/database.html)
 are supported and can be added if needed.
@@ -977,9 +962,9 @@ SSH in to any of the Patroni nodes on the **primary site**:
    ```plaintext
    | Cluster       | Member                            |  Host     | Role   | State   | TL  | Lag in MB | Pending restart |
    |---------------|-----------------------------------|-----------|--------|---------|-----|-----------|-----------------|
-   | postgresql-ha | <PostgreSQL primary hostname>     | 10.6.0.31 | Leader | running | 175 |           | *               |
-   | postgresql-ha | <PostgreSQL secondary 1 hostname> | 10.6.0.32 |        | running | 175 | 0         | *               |
-   | postgresql-ha | <PostgreSQL secondary 2 hostname> | 10.6.0.33 |        | running | 175 | 0         | *               |
+   | postgresql-ha | <PostgreSQL primary hostname>     | 10.6.0.21 | Leader | running | 175 |           | *               |
+   | postgresql-ha | <PostgreSQL secondary 1 hostname> | 10.6.0.22 |        | running | 175 | 0         | *               |
+   | postgresql-ha | <PostgreSQL secondary 2 hostname> | 10.6.0.23 |        | running | 175 | 0         | *               |
    ```
 
 If the 'State' column for any node doesn't say "running", check the
@@ -999,9 +984,9 @@ for tracking and handling reads/writes to the primary database.
 
 The following IPs are used as an example:
 
-- `10.6.0.21`: PgBouncer 1
-- `10.6.0.22`: PgBouncer 2
-- `10.6.0.23`: PgBouncer 3
+- `10.6.0.31`: PgBouncer 1
+- `10.6.0.32`: PgBouncer 2
+- `10.6.0.33`: PgBouncer 3
 
 1. On each PgBouncer node, edit `/etc/gitlab/gitlab.rb`, and replace
    `<consul_password_hash>` and `<pgbouncer_password_hash>` with the
@@ -1041,7 +1026,7 @@ The following IPs are used as an example:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Create a `.pgpass` file so Consul is able to
    reload PgBouncer. Enter the PgBouncer password twice when asked:
@@ -1211,7 +1196,7 @@ in the second step, do not supply the `EXTERNAL_URL` value.
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Follow the [post configuration](#praefect-postgresql-post-configuration).
 
@@ -1441,10 +1426,10 @@ the file of the same name on this server. If this is the first Omnibus node you
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
 
-   1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
+   1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect and
       to run the Praefect database migrations.
 
-1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. On all other Praefect nodes, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 ### Configure Gitaly
 
@@ -1612,7 +1597,7 @@ Updates to example must be made at:
 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
    the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 ### Gitaly Cluster TLS support
 
@@ -1668,7 +1653,7 @@ To configure Praefect with TLS:
    }
    ```
 
-1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 1. On the Praefect clients (including each Gitaly server), copy the certificates,
    or their certificate authority, into `/etc/gitlab/trusted-certs`:
@@ -1689,7 +1674,7 @@ To configure Praefect with TLS:
    })
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 <div align="right">
   <a type="button" class="btn btn-default" href="#setup-components">
@@ -1773,7 +1758,7 @@ Updates to example must be made at:
    gitlab_rails['db_host'] = '10.6.0.40' # internal load balancer IP
    gitlab_rails['db_port'] = 6432
    gitlab_rails['db_password'] = '<postgresql_user_password>'
-   gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.31', '10.6.0.32', '10.6.0.33'] } # PostgreSQL IPs
+   gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs
 
    ## Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -1840,7 +1825,7 @@ Updates to example must be made at:
    Only a single designated node should handle migrations as detailed in the
    [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. Verify the GitLab services are running:
 
@@ -1916,7 +1901,7 @@ On each node perform the following:
    gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer IP
    gitlab_rails['db_port'] = 6432
    gitlab_rails['db_password'] = '<postgresql_user_password>'
-   gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.31', '10.6.0.32', '10.6.0.33'] } # PostgreSQL IPs
+   gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -2033,7 +2018,7 @@ On each node perform the following:
    Only a single designated node should handle migrations as detailed in the
    [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. [Enable incremental logging](#enable-incremental-logging).
 1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the node can connect to Gitaly.
 1. Tail the logs to see the requests:
@@ -2144,7 +2129,7 @@ running [Prometheus](../monitoring/prometheus/index.md) and
    nginx['enable'] = true
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 1. In the GitLab UI, set `admin/application_settings/metrics_and_profiling` > Metrics - Grafana to `/-/grafana` to
    `http[s]://<MONITOR NODE>/-/grafana`.
 1. Verify the GitLab services are running:
@@ -2174,7 +2159,7 @@ running [Prometheus](../monitoring/prometheus/index.md) and
 GitLab supports using an [object storage](../object_storage.md) service for holding numerous types of data.
 It's recommended over [NFS](../nfs.md) for data objects and in general it's better
 in larger setups as object storage is typically much more performant, reliable,
-and scalable.
+and scalable. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
 There are two ways of specifying object storage configuration in GitLab:
 
@@ -2288,17 +2273,10 @@ services where applicable):
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->
-1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work.
-    - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
-      - Note that [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
-    - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is **incompatible** with load balancing enabled by default in [14.4.0](../../update/index.md#1440).
-    - Consul is primarily used for Omnibus PostgreSQL high availability so can be ignored when using a PostgreSQL PaaS setup. However, Consul is also used optionally by Prometheus for Omnibus auto host discovery.
-2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Memorystore](https://cloud.google.com/memorystore) and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) are known to work.
+1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
+2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
 3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
-    - [Google Cloud Load Balancing](https://cloud.google.com/load-balancing) and [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) are known to work.
-4. Should be run on reputable Cloud Provider or Self Managed solutions. More information can be found in the [Configure the object storage](#configure-the-object-storage) section.
+4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
 5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
 6. Gitaly has been designed and tested with repositories of varying sizes that follow best practices. However, large
    repositories or monorepos that don't follow these practices can significantly impact Gitaly requirements. Refer to
diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md
index 4b9c26e8626..08aeb149454 100644
--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -167,7 +167,7 @@ These reference architectures were built and tested on Google Cloud Platform (GC
 [Intel Xeon E5 v3 (Haswell)](https://cloud.google.com/compute/docs/cpu-platforms)
 CPU platform as a lowest common denominator baseline ([Sysbench benchmark](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks)).
 
-Newer, similarly-sized CPUs are supported and may have improved performance as a result. For Omnibus GitLab environments,
+Newer, similarly-sized CPUs are supported and may have improved performance as a result. For Linux package environments,
 ARM-based equivalents are also supported.
 
 NOTE:
@@ -240,7 +240,7 @@ for more information and guidance.
 that to achieve full High Availability, a third-party PostgreSQL database solution is required.
 
 We hope to offer a built-in solution for these restrictions in the future. In the meantime, a non-HA PostgreSQL server
-can be set up using Omnibus GitLab as the specifications reflect. Refer to the following issues for more information:
+can be set up using the Linux package as the specifications reflect. Refer to the following issues for more information:
 
 - [`omnibus-gitlab#7292`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7292).
 - [`gitaly#3398`](https://gitlab.com/gitlab-org/gitaly/-/issues/3398).
@@ -321,18 +321,21 @@ Additionally, the following cloud provider services are validated and supported
 
 ### Recommendation notes for the database services
 
-When selecting a database service, it should run a standard, performant, and [supported version](../../install/requirements.md#postgresql-requirements) of PostgreSQL with the following features:
+[When selecting to use an external database service](../postgresql/external.md), it should run a standard, performant, and [supported version](../../install/requirements.md#postgresql-requirements).
 
-- Read Replicas for [Database Load Balancing](../postgresql/database_load_balancing.md).
-- Cross Region replication for [GitLab Geo](../geo/index.md).
+If you choose to use a third party external service:
+
+1. Note that the HA Linux package PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
+1. The number of nodes required to achieve HA may differ depending on the service compared to the Linux package and doesn't need to match accordingly.
+1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
+1. If [GitLab Geo](../geo/index.md) is to be used the service will need to support Cross Region replication
 
 #### Unsupported database services
 
 Several database cloud provider services are known not to support the above or have been found to have other issues and aren't recommended:
 
 - [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is incompatible and not supported. See [14.4.0](../../update/index.md#1440) for more details.
-- [Azure Database for PostgreSQL Single Server](https://azure.microsoft.com/en-gb/products/postgresql/#overview) (Single / Flexible) is not supported for use due to notable performance / stability issues or missing functionality. See [Recommendation Notes for Azure](#recommendation-notes-for-azure) for more details.
-- Azure Database for PostgreSQL Flexible Server uses Microsoft Azure Active Directory (Azure AD) as authentication mechanism, which is incompatible with GitLab database integration.
+- [Azure Database for PostgreSQL Single Server](https://azure.microsoft.com/en-gb/products/postgresql/#overview) is not supported for use due to notable performance / stability issues or missing functionality. See [Recommendation Notes for Azure](#recommendation-notes-for-azure) for more details.
 - [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
   - [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.
 
@@ -342,8 +345,9 @@ Due to performance issues that we found with several key Azure services, we only
 
 In addition to the above, you should be aware of the additional specific guidance for Azure:
 
-- [Azure Database for PostgreSQL Single Server](https://azure.microsoft.com/en-gb/products/postgresql/#overview) (Single / Flexible) is not supported for use due to notable performance / stability issues or missing functionality.
+- [Azure Database for PostgreSQL Single Server](https://azure.microsoft.com/en-gb/products/postgresql/#overview) is not supported for use due to notable performance / stability issues or missing functionality.
 - A new service, [Azure Database for PostgreSQL Flexible Server](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/) has been released. [Internal testing](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/91) has shown that it does look to perform as expected, but this hasn't been validated in production, so generally isn't recommended at this time. Additionally, as it's a new service, you may find that it's missing some functionality depending on your requirements.
+  - Only standard Postgres authentication is supported at this time with this service. Microsoft Azure Active Directory (Azure AD) is not compatible.
 - [Azure Blob Storage](https://azure.microsoft.com/en-gb/products/storage/blobs/) has been found to have [performance limits that can impact production use at certain times](https://gitlab.com/gitlab-org/gitlab/-/issues/344861). However, this has only been seen in our largest architectures (25k+) so far.
 
 ## Deviating from the suggested reference architectures
@@ -353,8 +357,8 @@ the harder it is to get support for it. With any deviation, you're introducing
 a layer of complexity that adds challenges to finding out where potential
 issues might lie.
 
-The reference architectures use the official GitLab Linux packages (Omnibus
-GitLab) or [Helm Charts](https://docs.gitlab.com/charts/) to install and configure the various components. The components are
+The reference architectures use the official Linux packages or [Helm Charts](https://docs.gitlab.com/charts/) to
+install and configure the various components. The components are
 installed on separate machines (virtualized or bare metal), with machine hardware
 requirements listed in the "Configuration" column and equivalent VM standard sizes listed
 in GCP/AWS/Azure columns of each [available reference architecture](#available-reference-architectures).
@@ -414,9 +418,10 @@ Testing occurs against all reference architectures and cloud providers in an aut
 
 Network latency on the test environments between components on all Cloud Providers were measured at <5 ms. This is shared as an observation and not as an implicit recommendation.
 
-We aim to have a "test smart" approach where architectures tested have a good range that can also apply to others. Testing focuses on 10k Omnibus on GCP as the testing has shown this is a good bellwether for the other architectures and cloud providers as well as Cloud Native Hybrids.
+We aim to have a "test smart" approach where architectures tested have a good range that can also apply to others. Testing focuses on a 10k Linux package
+installation on GCP as the testing has shown this is a good bellwether for the other architectures and cloud providers as well as Cloud Native Hybrids.
 
-The Standard Reference Architectures are designed to be platform-agnostic, with everything being run on VMs via [Omnibus GitLab](https://docs.gitlab.com/omnibus/). While testing occurs primarily on GCP, ad-hoc testing has shown that they perform similarly on hardware with equivalent specs on other Cloud Providers or if run on premises (bare-metal).
+The Standard Reference Architectures are designed to be platform-agnostic, with everything being run on VMs through [the Linux package](https://docs.gitlab.com/omnibus/). While testing occurs primarily on GCP, ad-hoc testing has shown that they perform similarly on hardware with equivalent specs on other Cloud Providers or if run on premises (bare-metal).
 
 Testing on these reference architectures is performed with the
 [GitLab Performance Tool](https://gitlab.com/gitlab-org/quality/performance)
@@ -468,11 +473,11 @@ table.test-coverage th {
     <th style="text-align: center" colspan="2" scope="colgroup">Azure</th>
   </tr>
   <tr>
-    <th scope="col">Omnibus</th>
+    <th scope="col">Linux package</th>
     <th scope="col">Cloud Native Hybrid</th>
-    <th scope="col">Omnibus</th>
+    <th scope="col">Linux package</th>
     <th scope="col">Cloud Native Hybrid</th>
-    <th scope="col">Omnibus</th>
+    <th scope="col">Linux package</th>
   </tr>
     <tr>
     <th scope="row">1k</th>
@@ -534,7 +539,7 @@ table.test-coverage th {
 
 ## Cost to run
 
-As a starting point, the following table details initial costs for the different reference architectures across GCP, AWS, and Azure via Omnibus.
+As a starting point, the following table details initial costs for the different reference architectures across GCP, AWS, and Azure through the Linux package.
 
 NOTE:
 Due to the nature of Cloud Native Hybrid, it's not possible to give a static cost calculation.
@@ -551,9 +556,9 @@ Bare-metal costs are also not included here as it varies widely depending on eac
     <th style="text-align: center" scope="colgroup">Azure</th>
   </tr>
   <tr>
-    <th scope="col">Omnibus</th>
-    <th scope="col">Omnibus</th>
-    <th scope="col">Omnibus</th>
+    <th scope="col">Linux package</th>
+    <th scope="col">Linux package</th>
+    <th scope="col">Linux package</th>
   </tr>
     <tr>
     <th scope="row">1k</th>
diff --git a/doc/administration/repository_checks.md b/doc/administration/repository_checks.md
index 3f715e451a8..8cc635b50fc 100644
--- a/doc/administration/repository_checks.md
+++ b/doc/administration/repository_checks.md
@@ -20,7 +20,8 @@ committed to a repository. GitLab administrators can:
 
 To check a project's repository using GitLab UI:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Overview > Projects**.
 1. Select the project to check.
 1. In the **Repository check** section, select **Trigger repository check**.
@@ -32,7 +33,8 @@ project page in the Admin Area. If the checks fail, see [what to do](#what-to-do
 
 Instead of checking repositories manually, GitLab can be configured to run the checks periodically:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Repository** (`/admin/application_settings/repository`).
 1. Expand the **Repository maintenance** section.
 1. Enable **Enable repository checks**.
@@ -41,7 +43,7 @@ When enabled, GitLab periodically runs a repository check on all project reposit
 repositories to detect possible data corruption. A project is checked no more than once per month.
 Administrators can configure the frequency of repository checks. To edit the frequency:
 
-- For Omnibus GitLab installations, edit `gitlab_rails['repository_check_worker_cron']` in
+- For Linux package installations, edit `gitlab_rails['repository_check_worker_cron']` in
   `/etc/gitlab/gitlab.rb`.
 - For source-based installations, edit `[gitlab.cron_jobs.repository_check_worker]` in
   `/home/git/gitlab/config/gitlab.yml`.
@@ -59,7 +61,7 @@ You can run [`git fsck`](https://git-scm.com/docs/git-fsck) using the command li
 [Gitaly servers](gitaly/index.md). To locate the repositories:
 
 1. Go to the storage location for repositories:
-   - For Omnibus GitLab installations, repositories are stored in the `/var/opt/gitlab/git-data/repositories` directory
+   - For Linux package installations, repositories are stored in the `/var/opt/gitlab/git-data/repositories` directory
      by default.
    - For GitLab Helm chart installations, repositories are stored in the `/home/git/repositories` directory inside the
      Gitaly pod by default.
@@ -79,13 +81,14 @@ You can run [`git fsck`](https://git-scm.com/docs/git-fsck) using the command li
 
 If a repository check fails, locate the error in the [`repocheck.log` file](logs/index.md#repochecklog) on disk at:
 
-- `/var/log/gitlab/gitlab-rails` for Omnibus GitLab installations.
-- `/home/git/gitlab/log` for installations from source.
+- `/var/log/gitlab/gitlab-rails` for Linux package installations.
+- `/home/git/gitlab/log` for self-compiled installations.
 - `/var/log/gitlab` in the Sidekiq pod for GitLab Helm chart installations.
 
 If periodic repository checks cause false alarms, you can clear all repository check states:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Repository** (`/admin/application_settings/repository`).
 1. Expand the **Repository maintenance** section.
 1. Select **Clear all repository checks**.
diff --git a/doc/administration/repository_storage_paths.md b/doc/administration/repository_storage_paths.md
index 808659132f9..1a83a05c3dd 100644
--- a/doc/administration/repository_storage_paths.md
+++ b/doc/administration/repository_storage_paths.md
@@ -18,7 +18,7 @@ storage is either:
 GitLab allows you to define multiple repository storages to distribute the storage load between
 several mount points. For example:
 
-- When using Gitaly (Omnibus GitLab-style configuration):
+- When using Gitaly (Linux package installation-style configuration):
 
   ```ruby
    git_data_dirs({
@@ -27,7 +27,7 @@ several mount points. For example:
    })
    ```
 
-- When using direct repository storage (source install-style configuration):
+- When using direct repository storage (self-compiled installation-style configuration):
 
   ```plaintext
   default:
@@ -51,8 +51,8 @@ configuration option is deprecated in favor of using [Gitaly](gitaly/index.md).
 To configure repository storage paths:
 
 1. Edit the necessary configuration files:
-   - `/etc/gitlab/gitlab.rb`, for Omnibus GitLab installations.
-   - `gitlab.yml`, for installations from source.
+   - `/etc/gitlab/gitlab.rb`, for Linux package installations.
+   - `gitlab.yml`, for self-compiled installations.
 1. Add the required repository storage paths.
 
 For repository storage paths:
@@ -78,15 +78,15 @@ For [backups](../raketasks/backup_restore.md) to work correctly:
 - The repository storage path cannot be a mount point.
 - The GitLab user must have correct permissions for the parent directory of the path.
 
-Omnibus GitLab takes care of these issues for you, but for source installations you should be extra
+The Linux package takes care of these issues for you but for self-compiled installations, you should be extra
 careful.
 
 While restoring a backup, the current contents of `/home/git/repositories` are moved to
 `/home/git/repositories.old`. If `/home/git/repositories` is a mount point, then `mv` would be
 moving things between mount points, and problems can occur.
 
-Ideally, `/home/git` is the mount point, so things remain inside the same mount point. Omnibus
-GitLab installations guarantee this because they don't specify the full repository path but instead
+Ideally, `/home/git` is the mount point, so things remain inside the same mount point. Linux package
+installations guarantee this because they don't specify the full repository path but instead
 the parent path, but source installations do not.
 
 ### Example configuration
@@ -94,14 +94,14 @@ the parent path, but source installations do not.
 In the examples below, we add two additional repository storage paths configured to two additional
 mount points.
 
-For compatibility reasons `gitlab.yml` has a different structure than Omnibus GitLab configuration:
+For compatibility reasons `gitlab.yml` has a different structure than Linux package installation configuration:
 
-- In `gitlab.yml`, you indicate the path for the repositories, for example `/home/git/repositories`
-- In Omnibus GitLab configuration you indicate `git_data_dirs`, which could be `/home/git` for
-  example. Then Omnibus GitLab creates a `repositories` directory under that path to use with
+- In `gitlab.yml`, you indicate the path for the repositories. For example, `/home/git/repositories`.
+- In Linux package installation configuration, you indicate `git_data_dirs`, which could be `/home/git` for
+  example. The Linux package installation then creates a `repositories` directory under that path to use with
   `gitlab.yml`.
 
-**For installations from source**
+For self-compiled installations:
 
 1. Edit `gitlab.yml` and add the storage paths:
 
@@ -122,7 +122,7 @@ For compatibility reasons `gitlab.yml` has a different structure than Omnibus Gi
 
 1. [Configure where new repositories are stored](#configure-where-new-repositories-are-stored).
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` by appending the rest of the paths to the default one:
 
@@ -134,19 +134,20 @@ For compatibility reasons `gitlab.yml` has a different structure than Omnibus Gi
    })
    ```
 
-1. [Restart GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Restart GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 1. [Configure where new repositories are stored](#configure-where-new-repositories-are-stored).
 
 NOTE:
-Omnibus stores the repositories in a `repositories` subdirectory of the `git-data` directory.
+Linux package installations store the repositories in a `repositories` subdirectory of the `git-data` directory.
 
 ## Configure where new repositories are stored
 
 After you [configure](#configure-repository-storage-paths) multiple repository storage paths, you
 can choose where new repositories are stored:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Repository** and expand the **Repository storage**
    section.
 1. Enter values in the **Storage nodes for new repositories** fields.
diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md
index ab95887380d..3bd73b4df94 100644
--- a/doc/administration/repository_storage_types.md
+++ b/doc/administration/repository_storage_types.md
@@ -19,9 +19,8 @@ GitLab can be configured to use one or multiple repository storages. These stora
 In GitLab:
 
 - Repository storages are configured in:
-  - `/etc/gitlab/gitlab.rb` by the `git_data_dirs({})` configuration hash for Omnibus GitLab
-    installations.
-  - `gitlab.yml` by the `repositories.storages` key for installations from source.
+  - `/etc/gitlab/gitlab.rb` by the `git_data_dirs({})` configuration hash for Linux package installations.
+  - `gitlab.yml` by the `repositories.storages` key for self-compiled installations.
 - The `default` repository storage is available in any installations that haven't customized it. By
   default, it points to a Gitaly node.
 
@@ -79,7 +78,8 @@ Administrators can look up a project's hashed path from its name or ID using:
 
 To look up a project's hash path in the Admin Area:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Overview > Projects** and select the project.
 
 The **Gitaly relative path** is displayed there and looks similar to:
@@ -115,7 +115,7 @@ To look up a project's name using the Rails console:
    ```
 
 The quoted string in that command is the directory tree you can find on your GitLab server. For
-example, on a default Omnibus installation this would be `/var/opt/gitlab/git-data/repositories/@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git`
+example, on a default Linux package installation this would be `/var/opt/gitlab/git-data/repositories/@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git`
 with `.git` from the end of the directory name removed.
 
 The output includes the project ID and the project name. For example:
@@ -126,8 +126,8 @@ The output includes the project ID and the project name. For example:
 
 To look up a project's name using the `config` file in the `*.git` directory:
 
-1. Navigate to the to the `*.git` directory. This directory is located in `/var/opt/gitlab/git-data/repositories/@hashed/`, where the first four
-   characters of the hash are the first two directories in the path under `@hashed/`. For example, on a default Omnibus GitLab installation the
+1. Locate the `*.git` directory. This directory is located in `/var/opt/gitlab/git-data/repositories/@hashed/`, where the first four
+   characters of the hash are the first two directories in the path under `@hashed/`. For example, on a default Linux package installation the
    `*.git` directory of the hash `b17eb17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9` would be
    `/var/opt/gitlab/git-data/repositories/@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git`.
 1. Open the `config` file and locate the `fullpath=` key under `[gitlab]`.
diff --git a/doc/administration/restart_gitlab.md b/doc/administration/restart_gitlab.md
index e86541b7ced..51a4fe40b16 100644
--- a/doc/administration/restart_gitlab.md
+++ b/doc/administration/restart_gitlab.md
@@ -12,12 +12,12 @@ its services.
 NOTE:
 A short downtime is expected for all methods.
 
-## Omnibus installations
+## Linux package installations
 
-If you have used the [Omnibus packages](https://about.gitlab.com/install/) to install GitLab,
+If you have used the [Linux package](https://about.gitlab.com/install/) to install GitLab,
 you should already have `gitlab-ctl` in your `PATH`.
 
-`gitlab-ctl` interacts with the Omnibus packages and can be used to restart the
+`gitlab-ctl` interacts with the Linux package installation and can be used to restart the
 GitLab Rails application (Puma) as well as the other components, like:
 
 - GitLab Workhorse
@@ -28,10 +28,10 @@ GitLab Rails application (Puma) as well as the other components, like:
 - [Mailroom](reply_by_email.md)
 - Logrotate
 
-### Omnibus GitLab restart
+### Restart a Linux package installation
 
 There may be times in the documentation where you are asked to _restart_
-GitLab. To restart, run the following command:
+GitLab. To restart a Linux package installation, run:
 
 ```shell
 sudo gitlab-ctl restart
@@ -71,15 +71,14 @@ In that case, you can use `gitlab-ctl kill <service>` to send the `SIGKILL`
 signal to the service, for example `sidekiq`. After that, a restart should
 perform fine.
 
-As a last resort, you can try to
-[reconfigure GitLab](#omnibus-gitlab-reconfigure) instead.
+As a last resort, you can try to reconfigure GitLab instead.
 
-### Omnibus GitLab reconfigure
+### Reconfigure a Linux package installation
 
 There may be times in the documentation where you are asked to _reconfigure_
-GitLab. Remember that this method applies only for the Omnibus packages.
+GitLab. Remember that this method applies only for Linux package installations.
 
-Reconfigure Omnibus GitLab with:
+To reconfigure a Linux package installation, run:
 
 ```shell
 sudo gitlab-ctl reconfigure
@@ -89,10 +88,10 @@ Reconfiguring GitLab should occur in the event that something in its
 configuration (`/etc/gitlab/gitlab.rb`) has changed.
 
 When you run `gitlab-ctl reconfigure`, [Chef](https://www.chef.io/products/chef-infra),
-the underlying configuration management application that powers Omnibus GitLab, runs some checks.
+the underlying configuration management application that powers Linux package installations, runs some checks.
 Chef ensures directories, permissions, and services are in place and working.
 
-Chef also [restarts GitLab components](#how-to-restart-gitlab) if any of their configuration files have changed.
+Chef also restarts GitLab components if any of their configuration files have changed.
 
 If you manually edit any files in `/var/opt/gitlab` that are managed by Chef,
 running `reconfigure` reverts the changes and restarts the services that
diff --git a/doc/administration/secure_files.md b/doc/administration/secure_files.md
new file mode 100644
index 00000000000..3c9d40c3e73
--- /dev/null
+++ b/doc/administration/secure_files.md
@@ -0,0 +1,201 @@
+---
+stage: Mobile
+group: Mobile DevOps
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Secure Files administration **(FREE)**
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78227) in GitLab 14.8 [with a flag](feature_flags.md) named `ci_secure_files`. Disabled by default.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/350748) in GitLab 15.7. Feature flag `ci_secure_files` removed.
+
+You can securely store up to 100 files for use in CI/CD pipelines as secure files.
+These files are stored securely outside of your project's repository and are not version controlled.
+It is safe to store sensitive information in these files. Secure files support both plain text
+and binary file types, and must be 5 MB or less.
+
+The storage location of these files can be configured using the options described below,
+but the default locations are:
+
+- `/var/opt/gitlab/gitlab-rails/shared/ci_secure_files` for installations using the Linux package.
+- `/home/git/gitlab/shared/ci_secure_files` for self-compiled installations.
+
+Use [external object storage](https://docs.gitlab.com/charts/advanced/external-object-storage/#lfs-artifacts-uploads-packages-external-diffs-terraform-state-dependency-proxy)
+configuration for [GitLab Helm chart](https://docs.gitlab.com/charts/) installations.
+
+## Disabling Secure Files
+
+You can disable Secure Files across the entire GitLab instance. You might want to disable
+Secure Files to reduce disk space, or to remove access to the feature.
+
+To disable Secure Files, follow the steps below according to your installation.
+
+Prerequisite:
+
+- You must be an administrator.
+
+**For Linux package installations**
+
+1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
+
+   ```ruby
+   gitlab_rails['ci_secure_files_enabled'] = false
+   ```
+
+1. Save the file and reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+**For self-compiled installations**
+
+1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
+
+   ```yaml
+   ci_secure_files:
+     enabled: false
+   ```
+
+1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+
+## Using local storage
+
+The default configuration uses local storage. To change the location where Secure Files
+are stored locally, follow the steps below.
+
+**For Linux package installations**
+
+1. To change the storage path for example to `/mnt/storage/ci_secure_files`, edit
+   `/etc/gitlab/gitlab.rb` and add the following line:
+
+   ```ruby
+   gitlab_rails['ci_secure_files_storage_path'] = "/mnt/storage/ci_secure_files"
+   ```
+
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation)
+1. Save the file and reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+**For self-compiled installations**
+
+1. To change the storage path for example to `/mnt/storage/ci_secure_files`, edit
+   `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
+
+   ```yaml
+   ci_secure_files:
+     enabled: true
+     storage_path: /mnt/storage/ci_secure_files
+   ```
+
+1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source)
+   for the changes to take effect.
+
+## Using object storage **(FREE SELF)**
+
+Instead of storing Secure Files on disk, you should use [one of the supported object storage options](object_storage.md#supported-object-storage-providers).
+This configuration relies on valid credentials to be configured already.
+
+[Read more about using object storage with GitLab](object_storage.md).
+
+NOTE:
+This feature is not supported by consolidated object storage configuration.
+Adding support is proposed in [issue 414673](https://gitlab.com/gitlab-org/gitlab/-/issues/414673).
+
+### Object storage settings
+
+The following settings are:
+
+- Nested under `ci_secure_files:` and then `object_store:` on source installations.
+- Prefixed by `ci_secure_files_object_store_` on Linux package installations.
+
+| Setting | Description | Default |
+|---------|-------------|---------|
+| `enabled` | Enable/disable object storage | `false` |
+| `remote_directory` | The bucket name where Secure Files are stored | |
+| `connection` | Various connection options described below | |
+
+### S3-compatible connection settings
+
+See [the available connection settings for different providers](object_storage.md#configure-the-connection-settings).
+
+**For Linux package installations:**
+
+1. Edit `/etc/gitlab/gitlab.rb` and add the following lines, but using
+   the values you want:
+
+   ```ruby
+   gitlab_rails['ci_secure_files_object_store_enabled'] = true
+   gitlab_rails['ci_secure_files_object_store_remote_directory'] = "terraform"
+   gitlab_rails['ci_secure_files_object_store_connection'] = {
+     'provider' => 'AWS',
+     'region' => 'eu-central-1',
+     'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
+     'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY'
+   }
+   ```
+
+   NOTE:
+   If you are using AWS IAM profiles, be sure to omit the AWS access key and secret access key/value pairs:
+
+   ```ruby
+   gitlab_rails['ci_secure_files_object_store_connection'] = {
+     'provider' => 'AWS',
+     'region' => 'eu-central-1',
+     'use_iam_profile' => true
+   }
+   ```
+
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation)
+1. Save the file and reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. [Migrate any existing local states to the object storage](#migrate-to-object-storage)
+
+**For self-compiled installations**
+
+1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
+
+   ```yaml
+   ci_secure_files:
+     enabled: true
+     object_store:
+       enabled: true
+       remote_directory: "ci_secure_files"  # The bucket name
+       connection:
+         provider: AWS  # Only AWS supported at the moment
+         aws_access_key_id: AWS_ACCESS_KEY_ID
+         aws_secret_access_key: AWS_SECRET_ACCESS_KEY
+         region: eu-central-1
+   ```
+
+1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. [Migrate any existing local states to the object storage](#migrate-to-object-storage)
+
+### Migrate to object storage
+
+> [Introduced](https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/readme/-/issues/125) in GitLab 16.1.
+
+WARNING:
+It's not possible to migrate Secure Files from object storage back to local storage,
+so proceed with caution.
+
+To migrate Secure Files to object storage, follow the instructions below.
+
+- For Linux package installations:
+
+  ```shell
+  sudo gitlab-rake gitlab:ci_secure_files:migrate
+  ```
+
+- For self-compiled installations:
+
+  ```shell
+  sudo -u git -H bundle exec rake gitlab:ci_secure_files:migrate RAILS_ENV=production
+  ```
diff --git a/doc/administration/server_hooks.md b/doc/administration/server_hooks.md
index b167412075b..82360581504 100644
--- a/doc/administration/server_hooks.md
+++ b/doc/administration/server_hooks.md
@@ -33,12 +33,12 @@ alternatives to server hooks include:
 
 :::TabTitle GitLab 15.11 and later
 
-> [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/4629) in GitLab 15.11, `hooks set` command replaces direct file system access.
+> [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/4629) in GitLab 15.11, `hooks set` command replaces direct file system access. Existing Git hooks don't need migrating for the `hooks set` command.
 
 Prerequisites:
 
 - The [storage name](gitaly/configure_gitaly.md#gitlab-requires-a-default-repository-storage), path to the Gitaly configuration file
-  (default is `/var/opt/gitlab/gitaly/config.toml` on Omnibus GitLab instances), and the
+  (default is `/var/opt/gitlab/gitaly/config.toml` on Linux package instances), and the
   [repository relative path](repository_storage_types.md#from-project-name-to-hashed-path) for the repository.
 
 To set server hooks for a repository:
@@ -57,11 +57,13 @@ To set server hooks for a repository:
    1. Ensure the server hook files are executable and do not match the backup file pattern (`*~`). The server hooks be
       in a `custom_hooks` directory that is at the root of the tarball.
    1. Create the custom hooks archive with the tar command. For example, `tar -cf custom_hooks.tar custom_hooks`.
-1. Run the `hooks set` command with required options to set the Git hooks for the repository. For example,
+1. Run the `hooks set` subcommand with required options to set the Git hooks for the repository. For example,
    `cat hooks.tar | gitaly hooks set --storage <storage> --repository <relative path> --config <config path>`.
 
    - A path to a valid Gitaly configuration for the node is required to connect to the node and provided to the `--config` flag.
    - Custom hooks tarball must be passed via `stdin`. For example, `cat hooks.tar | gitaly hooks set --storage <storage> --repository <relative path> --config <config path>`.
+1. If you are using Gitaly Cluster, you must run `hooks set` subcommand on all Gitaly nodes. For more information, see
+   [Server hooks on a Gitaly Cluster](#server-hooks-on-a-gitaly-cluster).
 
 If you implemented the server hook code correctly, it should execute when the Git hook is next triggered.
 
@@ -69,15 +71,16 @@ If you implemented the server hook code correctly, it should execute when the Gi
 
 To create server hooks for a repository:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. Go to **Overview > Projects** and select the project you want to add a server hook to.
 1. On the page that appears, locate the value of **Gitaly relative path**. This path is where server hooks must be located.
    - If you are using [hashed storage](repository_storage_types.md#hashed-storage), see
      [Translate hashed storage paths](repository_storage_types.md#translate-hashed-storage-paths) for information on
      interpreting the relative path.
    - If you are not using [hashed storage](repository_storage_types.md#hashed-storage):
-     - For Omnibus GitLab installations, the path is usually `/var/opt/gitlab/git-data/repositories/<group>/<project>.git`.
-     - For an installation from source, the path is usually `/home/git/repositories/<group>/<project>.git`.
+     - For Linux package installations, the path is usually `/var/opt/gitlab/git-data/repositories/<group>/<project>.git`.
+     - For self-compiled installations, the path is usually `/home/git/repositories/<group>/<project>.git`.
 1. On the file system, create a new directory in the correct location called `custom_hooks`.
 1. In the new `custom_hooks` directory:
    - To create a single server hook, create a file with a name that matches the hook type. For example, for a
@@ -90,15 +93,18 @@ To create server hooks for a repository:
    example, if the script is in Ruby the shebang is probably `#!/usr/bin/env ruby`.
 1. Ensure the hook file does not match the backup file
    pattern (`*~`).
+1. If you are using Gitaly Cluster, you must repeat this process on all Gitaly nodes. For more information, see
+   [Server hooks on a Gitaly Cluster](#server-hooks-on-a-gitaly-cluster).
 
 If the server hook code is properly implemented, it should execute when the Git hook is next triggered.
 
 ::EndTabs
 
-### Gitaly Cluster
+### Server hooks on a Gitaly Cluster
 
-If you use [Gitaly Cluster](gitaly/index.md), the scripts must be copied to every Gitaly node that has a replica of the repository. Every Gitaly node
-needs a copy because any node can be made a primary at any time. Server hooks only run on primary nodes.
+If you use [Gitaly Cluster](gitaly/index.md), an individual repository may be replicated to multiple Gitaly storages in Praefect.
+Consequentially, the hook scripts must be copied to every Gitaly node that has a replica of the repository.
+To accomplish this, follow the same steps for setting custom repository hooks for the applicable version and repeat for each storage.
 
 The location to copy the scripts to depends on where repositories are stored:
 
@@ -123,7 +129,7 @@ To create a Git hook that applies to all repositories, set a global server hook.
 
 Before creating a global server hook, you must choose a directory for it.
 
-For Omnibus GitLab installations, the directory is set in `gitlab.rb` under `gitaly['configuration'][:hooks][:custom_hooks_dir]`. You can either:
+For Linux package installations, the directory is set in `gitlab.rb` under `gitaly['configuration'][:hooks][:custom_hooks_dir]`. You can either:
 
 - Use the default suggestion of the `/var/opt/gitlab/gitaly/custom_hooks` directory by uncommenting it.
 - Add your own setting.
@@ -201,7 +207,7 @@ The following GitLab environment variables are supported for all server hooks:
 
 | Environment variable | Description                                                                                                                                                |
 |:---------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `GL_ID`              | GitLab identifier of user that initiated the push. For example, `user-2234`.                                                                               |
+| `GL_ID`              | GitLab identifier of user or SSH key that initiated the push. For example, `user-2234` or `key-4`.                                                         |
 | `GL_PROJECT_PATH`    | (GitLab 13.2 and later) GitLab project path.                                                                                                               |
 | `GL_PROTOCOL`        | (GitLab 13.2 and later) Protocol used for this change. One of: `http` (Git `push` using HTTP), `ssh` (Git `push` using SSH), or `web` (all other actions). |
 | `GL_REPOSITORY`      | `project-<id>` where `id` is the ID of the project.                                                                                                        |
diff --git a/doc/administration/sidekiq/extra_sidekiq_processes.md b/doc/administration/sidekiq/extra_sidekiq_processes.md
index 7959d1a5ce7..31e713bbf06 100644
--- a/doc/administration/sidekiq/extra_sidekiq_processes.md
+++ b/doc/administration/sidekiq/extra_sidekiq_processes.md
@@ -48,7 +48,8 @@ to all available queues:
 
 To view the Sidekiq processes in GitLab:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Monitoring > Background Jobs**.
 
 ## Concurrency
diff --git a/doc/administration/sidekiq/index.md b/doc/administration/sidekiq/index.md
index 6fb12aa6ef9..bb517e21fd0 100644
--- a/doc/administration/sidekiq/index.md
+++ b/doc/administration/sidekiq/index.md
@@ -278,7 +278,7 @@ To serve metrics via HTTPS instead of HTTP, enable TLS in the exporter settings:
    sidekiq['exporter_tls_key_path'] = "/path/to/private-key.pem"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 When TLS is enabled, the same `port` and `address` are used as described above.
diff --git a/doc/administration/sidekiq/processing_specific_job_classes.md b/doc/administration/sidekiq/processing_specific_job_classes.md
index 26c2804f130..696b0b9444c 100644
--- a/doc/administration/sidekiq/processing_specific_job_classes.md
+++ b/doc/administration/sidekiq/processing_specific_job_classes.md
@@ -25,10 +25,6 @@ Both of these use the same [worker matching query](#worker-matching-query)
 syntax. While they can technically be used together, most deployments should
 choose one or the other; there is no particular benefit in combining them.
 
-Routing rules must be the same across all GitLab nodes as they are part of the
-application configuration. Queue selectors can be different across GitLab nodes
-because they only change the arguments to the launched Sidekiq process.
-
 ## Routing rules
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59604) in GitLab 13.12.
@@ -61,6 +57,12 @@ the migration to avoid losing jobs entirely, especially in a system with long
 queues of jobs. The migration can be done by following the migration steps
 mentioned in [Sidekiq job migration](sidekiq_job_migration.md).
 
+### Routing rules in a scaled architecture
+
+Routing rules must be the same across all GitLab nodes (especially GitLab Rails and Sidekiq nodes) as they are part of the
+application configuration. Queue selectors can be different across GitLab nodes
+because they only change the arguments to the launched Sidekiq process.
+
 ### Detailed example
 
 This is a comprehensive example intended to show different possibilities. It is
diff --git a/doc/administration/sidekiq/sidekiq_job_migration.md b/doc/administration/sidekiq/sidekiq_job_migration.md
index 1332d9b35d8..89da174eb34 100644
--- a/doc/administration/sidekiq/sidekiq_job_migration.md
+++ b/doc/administration/sidekiq/sidekiq_job_migration.md
@@ -17,7 +17,7 @@ If the Sidekiq routing rules are changed, administrators need to take care with
 
 1. Listen to both the old and new queues.
 1. Update the routing rules.
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Run the [Rake tasks for migrating queued and future jobs](#migrate-queued-and-future-jobs).
 1. Stop listening to the old queues.
 
diff --git a/doc/administration/sidekiq/sidekiq_troubleshooting.md b/doc/administration/sidekiq/sidekiq_troubleshooting.md
index 8b95a9f6f0a..315714cd00b 100644
--- a/doc/administration/sidekiq/sidekiq_troubleshooting.md
+++ b/doc/administration/sidekiq/sidekiq_troubleshooting.md
@@ -494,6 +494,41 @@ has number of drawbacks, as mentioned in [Why Ruby's Timeout is dangerous (and T
 >
 > Nobody writes code to defend against an exception being raised on literally any line. That's not even possible. So Thread.raise is basically like a sneak attack on your code that could result in almost anything. It would probably be okay if it were pure-functional code that did not modify any state. But this is Ruby, so that's unlikely :)
 
+## Manually trigger a cron job
+
+By visiting `/admin/background_jobs`, you can look into what jobs are scheduled/running/pending on your instance.
+
+You can trigger a cron job from the UI by selecting the "Enqueue Now" button. To trigger a cron job programmatically first open a [Rails console](../operations/rails_console.md).
+
+To find the cron job you want to test:
+
+```irb
+job = Sidekiq::Cron::Job.find('job-name')
+
+# get status of job:
+job.status
+
+# enqueue job right now!
+job.enque!
+```
+
+For example, to trigger the `update_all_mirrors_worker` cron job that updates the repository mirrors:
+
+```irb
+irb(main):001:0> job = Sidekiq::Cron::Job.find('update_all_mirrors_worker')
+=>
+#<Sidekiq::Cron::Job:0x00007f147f84a1d0
+...
+irb(main):002:0> job.status
+=> "enabled"
+irb(main):003:0> job.enque!
+=> 257
+```
+
+The list of available jobs can be found in the [workers](https://gitlab.com/gitlab-org/gitlab/-/tree/master/app/workers) directory.
+
+For more information about Sidekiq jobs, see the [Sidekiq-cron](https://github.com/sidekiq-cron/sidekiq-cron#work-with-job) documentation.
+
 ## Omnibus GitLab 14.0 and later: remove the `sidekiq-cluster` service
 
 Omnibus GitLab instances that were configured to run `sidekiq-cluster` prior to GitLab 14.0
@@ -550,3 +585,7 @@ This change might reduce the amount of work Sidekiq can do. Symptoms like delays
 indicate that additional Sidekiq processes would be beneficial.
 Consider [adding additional Sidekiq processes](extra_sidekiq_processes.md)
 to compensate for removing the `sidekiq-cluster` service.
+
+## Related topics
+
+- [Elasticsearch workers overload Sidekiq](../../integration/advanced_search/elasticsearch_troubleshooting.md#elasticsearch-workers-overload-sidekiq).
diff --git a/doc/administration/silent_mode/index.md b/doc/administration/silent_mode/index.md
index e98aaaf4e0a..49c95d75768 100644
--- a/doc/administration/silent_mode/index.md
+++ b/doc/administration/silent_mode/index.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # GitLab Silent Mode (Experiment) **(FREE SELF)**
 
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/9826) in GitLab 15.11. This feature is an [Experiment](../../policy/alpha-beta-support.md#experiment).
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/9826) in GitLab 15.11. This feature is an [Experiment](../../policy/experiment-beta-support.md#experiment).
 
 Silent Mode allows you to suppress outbound communication, such as emails, from GitLab. Silent Mode is not intended to be used on environments which are in-use. Two use-cases are:
 
@@ -33,6 +33,8 @@ There are two ways to enable Silent Mode:
   ::Gitlab::CurrentSettings.update!(silent_mode_enabled: true)
   ```
 
+It may take up to a minute to take effect. [Issue 405433](https://gitlab.com/gitlab-org/gitlab/-/issues/405433) proposes removing this delay.
+
 ## Disable Silent Mode
 
 Prerequisites:
@@ -53,12 +55,26 @@ There are two ways to disable Silent Mode:
   ::Gitlab::CurrentSettings.update!(silent_mode_enabled: false)
   ```
 
+It may take up to a minute to take effect. [Issue 405433](https://gitlab.com/gitlab-org/gitlab/-/issues/405433) proposes removing this delay.
+
 ## Behavior of GitLab features in Silent Mode
 
+This section documents the current behavior of GitLab when Silent Mode is enabled. While Silent Mode is an Experiment, the behavior may change without notice. The work for the first iteration of Silent Mode is tracked by [Epic 9826](https://gitlab.com/groups/gitlab-org/-/epics/9826).
+
 ### Service Desk
 
 Incoming emails still raise issues, but the users who sent the emails to [Service Desk](../../user/project/service_desk.md) are not notified of issue creation or comments on their issues.
 
+### Webhooks
+
+[Project and group webhooks](../../user/project/integrations/webhooks.md), and [system hooks](../system_hooks.md) are suppressed. The relevant Sidekiq jobs fail 4 times and then disappear, while Silent Mode is enabled. [Issue 393639](https://gitlab.com/gitlab-org/gitlab/-/issues/393639) discusses preventing the Sidekiq jobs from running in the first place.
+
+Triggering webhook tests via the UI results in HTTP status 500 responses.
+
 ### Outbound emails
 
-Outbound emails are suppressed. It may take up to a minute to take effect after enabling Silent Mode. [Issue 405433](https://gitlab.com/gitlab-org/gitlab/-/issues/405433) proposes removing this delay.
+Outbound emails are suppressed.
+
+### Outbound HTTP requests
+
+Many outbound HTTP requests are suppressed. A list of unsuppressed requests does not exist at this time, since more suppression is planned.
diff --git a/doc/administration/smime_signing_email.md b/doc/administration/smime_signing_email.md
index 4e49eef44df..5748c4d32d4 100644
--- a/doc/administration/smime_signing_email.md
+++ b/doc/administration/smime_signing_email.md
@@ -30,7 +30,7 @@ WARNING:
 Be mindful of the access levels for your private keys and visibility to
 third parties.
 
-**For Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and adapt the file paths:
 
@@ -42,11 +42,11 @@ third parties.
    gitlab_rails['gitlab_email_smime_ca_certs_file'] = '/etc/gitlab/ssl/gitlab_smime_cas.crt'
    ```
 
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 The key must be readable by the GitLab system user (`git` by default).
 
-**For installations from source:**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml`:
 
diff --git a/doc/administration/static_objects_external_storage.md b/doc/administration/static_objects_external_storage.md
index 73f44ed3889..c7a22da38de 100644
--- a/doc/administration/static_objects_external_storage.md
+++ b/doc/administration/static_objects_external_storage.md
@@ -16,7 +16,8 @@ storage such as a content delivery network (CDN).
 
 To configure external storage for static objects:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Repository**.
 1. Expand the **External storage for repository static objects** section.
 1. Enter the base URL and an arbitrary token. When you [set up external storage](#set-up-external-storage),
diff --git a/doc/administration/system_hooks.md b/doc/administration/system_hooks.md
index 8d343e7c541..dcacacaf47b 100644
--- a/doc/administration/system_hooks.md
+++ b/doc/administration/system_hooks.md
@@ -54,7 +54,8 @@ for Push and Tag events, but we never display commits.
 
 To create a system hook:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **System Hooks**.
 1. Provide the **URL** and **Secret Token**.
 1. Select the checkbox next to each optional **Trigger** you want to enable.
diff --git a/doc/administration/terraform_state.md b/doc/administration/terraform_state.md
index 3ac9a5fdce8..84f596dacf2 100644
--- a/doc/administration/terraform_state.md
+++ b/doc/administration/terraform_state.md
@@ -13,7 +13,7 @@ files. The files are encrypted before being stored. This feature is enabled by d
 
 The storage location of these files defaults to:
 
-- `/var/opt/gitlab/gitlab-rails/shared/terraform_state` for Omnibus GitLab installations.
+- `/var/opt/gitlab/gitlab-rails/shared/terraform_state` for Linux package installations.
 - `/home/git/gitlab/shared/terraform_state` for source installations.
 
 These locations can be configured using the options described below.
@@ -40,7 +40,7 @@ Prerequisite:
 
 - You must be an administrator.
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -48,9 +48,9 @@ Prerequisite:
    gitlab_rails['terraform_state_enabled'] = false
    ```
 
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
-**In installations from source:**
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
 
@@ -66,7 +66,7 @@ Prerequisite:
 The default configuration uses local storage. To change the location where
 Terraform state files are stored locally, follow the steps below.
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. To change the storage path for example to `/mnt/storage/terraform_state`, edit
    `/etc/gitlab/gitlab.rb` and add the following line:
@@ -75,9 +75,9 @@ Terraform state files are stored locally, follow the steps below.
    gitlab_rails['terraform_state_storage_path'] = "/mnt/storage/terraform_state"
    ```
 
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
-**In installations from source:**
+For self-compiled installations:
 
 1. To change the storage path for example to `/mnt/storage/terraform_state`, edit
    `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
@@ -103,7 +103,7 @@ This configuration relies on valid credentials to be configured already.
 The following settings are:
 
 - Nested under `terraform_state:` and then `object_store:` on source installations.
-- Prefixed by `terraform_state_object_store_` on Omnibus GitLab installations.
+- Prefixed by `terraform_state_object_store_` on Linux package installations.
 
 | Setting | Description | Default |
 |---------|-------------|---------|
@@ -120,15 +120,15 @@ It's not possible to migrate Terraform state files from object storage back to l
 so proceed with caution. [An issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/350187)
 to change this behavior.
 
-To migrate Terraform state files to object storage, follow the instructions below.
+To migrate Terraform state files to object storage:
 
-- For Omnibus package installations:
+- For Linux package installations:
 
   ```shell
   gitlab-rake gitlab:terraform_states:migrate
   ```
 
-- For source installations:
+- For self-compiled installations:
 
   ```shell
   sudo -u git -H bundle exec rake gitlab:terraform_states:migrate RAILS_ENV=production
@@ -152,9 +152,9 @@ For GitLab 13.8 and earlier versions, you can use a workaround for the Rake task
 You can optionally track progress and verify that all Terraform state files migrated successfully using the
 [PostgreSQL console](https://docs.gitlab.com/omnibus/settings/database.html#connecting-to-the-bundled-postgresql-database):
 
-- `sudo gitlab-rails dbconsole` for Omnibus GitLab 14.1 and earlier.
-- `sudo gitlab-rails dbconsole --database main` for Omnibus GitLab 14.2 and later.
-- `sudo -u git -H psql -d gitlabhq_production` for source-installed instances.
+- `sudo gitlab-rails dbconsole` for Linux package installations running GitLab 14.1 and earlier.
+- `sudo gitlab-rails dbconsole --database main` for Linux package installations running GitLab 14.2 and later.
+- `sudo -u git -H psql -d gitlabhq_production` for self-compiled installations.
 
 Verify `objectstg` below (where `file_store=2`) has count of all states:
 
@@ -207,7 +207,7 @@ See [the available connection settings for different providers](object_storage.m
    }
    ```
 
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. [Migrate any existing local states to the object storage](#migrate-to-object-storage)
 
 **In installations from source:**
diff --git a/doc/administration/timezone.md b/doc/administration/timezone.md
index b0dc995c684..e0f70cecb43 100644
--- a/doc/administration/timezone.md
+++ b/doc/administration/timezone.md
@@ -18,12 +18,13 @@ Uncomment and customize if you want to change the default time zone of the GitLa
 
 To see all available time zones, run `bundle exec rake time:zones:all`.
 
-For Omnibus installations, run `gitlab-rake time:zones:all`.
+For Linux package installations, run `gitlab-rake time:zones:all`.
 
 NOTE:
-This Rake task does not list time zones in TZInfo format required by Omnibus GitLab during a reconfigure: [#27209](https://gitlab.com/gitlab-org/gitlab/-/issues/27209).
+This Rake task does not list time zones in TZInfo format required by a Linux package installation during a reconfigure. For more information,
+see [issue 27209](https://gitlab.com/gitlab-org/gitlab/-/issues/27209).
 
-## Changing time zone in Omnibus installations
+## Changing time zone in Linux package installations
 
 GitLab defaults its time zone to UTC. It has a global time zone configuration parameter in `/etc/gitlab/gitlab.rb`.
 
diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
index ddee79046f6..fc319fad3e8 100644
--- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
+++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
@@ -92,4 +92,4 @@ Moved to [Geo replication troubleshooting](../geo/replication/troubleshooting.md
 
 ## Generate Service Ping
 
-This content has been moved to [Service Ping Troubleshooting](../../development/service_ping/troubleshooting.md).
+This content has been moved to [Service Ping Troubleshooting](../../development/internal_analytics/service_ping/troubleshooting.md).
diff --git a/doc/administration/troubleshooting/postgresql.md b/doc/administration/troubleshooting/postgresql.md
index d5288bfead8..120d566a7e7 100644
--- a/doc/administration/troubleshooting/postgresql.md
+++ b/doc/administration/troubleshooting/postgresql.md
@@ -135,7 +135,7 @@ postgresql['statement_timeout'] = '15s'
 postgresql['idle_in_transaction_session_timeout'] = '60s'
 ```
 
-Once saved, [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+Once saved, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 NOTE:
 These are Omnibus GitLab settings. If an external database, such as a customer's PostgreSQL installation or Amazon RDS is being used, these values don't get set, and would have to be set externally.
@@ -148,7 +148,7 @@ The following advice does not apply in case
 because the changed timeout might affect more transactions than intended.
 
 In some situations, it may be desirable to set a different statement timeout
-without having to [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure),
+without having to [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation),
 which in this case would restart Puma and Sidekiq.
 
 For example, a backup may fail with the following errors in the output of the
@@ -190,6 +190,12 @@ This error likely means that `autovacuum` is failing to complete its run:
 ERROR:  database is not accepting commands to avoid wraparound data loss in database "gitlabhq_production"
 ```
 
+Or
+
+```plaintext
+ ERROR:  failed to re-find parent key in index "XXX" for deletion target page XXX
+```
+
 To resolve the error, run `VACUUM` manually:
 
 1. Stop GitLab with the command `gitlab-ctl stop`.
diff --git a/doc/administration/uploads.md b/doc/administration/uploads.md
index ab900d7ea9f..99f19821916 100644
--- a/doc/administration/uploads.md
+++ b/doc/administration/uploads.md
@@ -23,7 +23,7 @@ For historical reasons, uploads for the whole instance (for example the [favicon
 which by default is `uploads/-/system`. Changing the base
 directory on an existing GitLab installation is strongly discouraged.
 
-**In Omnibus GitLab installations:**
+For Linux package installations:
 
 _The uploads are stored by default in `/var/opt/gitlab/gitlab-rails/uploads`._
 
@@ -36,9 +36,9 @@ _The uploads are stored by default in `/var/opt/gitlab/gitlab-rails/uploads`._
 
    This setting only applies if you haven't changed the `gitlab_rails['uploads_storage_path']` directory.
 
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
-**In installations from source:**
+For self-compiled installations:
 
 _The uploads are stored by default in
 `/home/git/gitlab/public/uploads`._
@@ -68,7 +68,8 @@ In GitLab 13.2 and later, you should use the
 [consolidated object storage settings](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 This section describes the earlier configuration format.
 
-For source installations the following settings are nested under `uploads:` and then `object_store:`. On Omnibus GitLab installs they are prefixed by `uploads_object_store_`.
+For self-compiled installations, the following settings are nested under `uploads:` and then `object_store:`. On Linux
+package installations, they are prefixed by `uploads_object_store_`.
 
 | Setting | Description | Default |
 |---------|-------------|---------|
@@ -81,7 +82,7 @@ For source installations the following settings are nested under `uploads:` and
 
 See [the available connection settings for different providers](object_storage.md#configure-the-connection-settings).
 
-**In Omnibus installations:**
+For Linux package installations:
 
 _The uploads are stored by default in
 `/var/opt/gitlab/gitlab-rails/uploads`._
@@ -110,10 +111,10 @@ _The uploads are stored by default in
    }
    ```
 
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Migrate any existing local uploads to the object storage with the [`gitlab:uploads:migrate:all` Rake task](raketasks/uploads/migrate.md).
 
-**In installations from source:**
+For self-compiled installations:
 
 _The uploads are stored by default in
 `/home/git/gitlab/public/uploads`._
diff --git a/doc/administration/user_settings.md b/doc/administration/user_settings.md
index b02e1c7244b..c4b00d05f9d 100644
--- a/doc/administration/user_settings.md
+++ b/doc/administration/user_settings.md
@@ -18,9 +18,9 @@ ability to create top-level groups (does not affect existing users' setting), Gi
   - The [application setting API](../api/settings.md#change-application-settings).
 - In GitLab 15.4 and earlier, in a configuration file by following the steps in this section.
 
-To disable new users' ability to create top-level groups using the configuration file:
+To disable new users' ability to create top-level groups using the configuration file.
 
-**Omnibus GitLab installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -28,9 +28,9 @@ To disable new users' ability to create top-level groups using the configuration
    gitlab_rails['gitlab_default_can_create_group'] = false
    ```
 
-1. [Reconfigure and restart GitLab](restart_gitlab.md#omnibus-installations).
+1. [Reconfigure and restart GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation).
 
-**Source installations**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml` and uncomment the following line:
 
@@ -50,9 +50,9 @@ Administrators can:
 ## Prevent users from changing their usernames
 
 By default, new users can change their usernames. To disable your users'
-ability to change their usernames:
+ability to change their usernames.
 
-**Omnibus GitLab installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -60,9 +60,9 @@ ability to change their usernames:
    gitlab_rails['gitlab_username_changing_enabled'] = false
    ```
 
-1. [Reconfigure and restart GitLab](restart_gitlab.md#omnibus-installations).
+1. [Reconfigure and restart GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation).
 
-**Source installations**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml` and uncomment the following line:
 
diff --git a/doc/administration/whats-new.md b/doc/administration/whats-new.md
index d9c8a991577..b34b054d87c 100644
--- a/doc/administration/whats-new.md
+++ b/doc/administration/whats-new.md
@@ -23,7 +23,7 @@ All users can see the feature list, but the entries might differ depending on th
 
 To access the **What's new** feature:
 
-1. On the top bar, select the **{question}** icon.
+1. On the left sidebar, at the bottom, select **Help** (**{question}**).
 1. Select **What's new** from the menu.
 
 ## Configure What's new
@@ -31,7 +31,8 @@ To access the **What's new** feature:
 You can configure **What's new** to display features based on the tier,
 or you can hide it. To configure it:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Preferences**.
 1. Expand **What's new**, and choose one of the following options:
 
diff --git a/doc/administration/wikis/index.md b/doc/administration/wikis/index.md
index 330e41ee880..540e50d5c70 100644
--- a/doc/administration/wikis/index.md
+++ b/doc/administration/wikis/index.md
@@ -82,6 +82,51 @@ so you should keep your wiki repositories as compact as possible.
 For more information about tools to compact repositories,
 read the documentation on [reducing repository size](../../user/project/repository/reducing_the_repo_size_using_git.md).
 
+## Allow URI includes for AsciiDoc
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/348687) in GitLab 16.1.
+
+Include directives import content from separate pages or external URLs,
+and display them as part of the content of the current document. To enable
+AsciiDoc includes, enable the feature through the Rails console or the API.
+
+### Through the Rails console
+
+To configure this setting through the Rails console:
+
+1. Start the Rails console:
+
+   ```shell
+   # For Omnibus installations
+   sudo gitlab-rails console
+
+   # For installations from source
+   sudo -u git -H bundle exec rails console -e production
+   ```
+
+1. Update the wiki to allow URI includes for AsciiDoc:
+
+   ```ruby
+   ApplicationSetting.first.update!(wiki_asciidoc_allow_uri_includes: true)
+   ```
+
+To check if includes are enabled, start the Rails console and run:
+
+  ```ruby
+  Gitlab::CurrentSettings.wiki_asciidoc_allow_uri_includes
+  ```
+
+### Through the API
+
+To set the wiki to allow URI includes for AsciiDoc through the
+[Application Settings API](../../api/settings.md#change-application-settings),
+use a `curl` command:
+
+```shell
+curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" \
+  "https://gitlab.example.com/api/v4/application/settings?wiki_asciidoc_allow_uri_includes=true"
+```
+
 ## Related topics
 
 - [User documentation for wikis](../../user/project/wiki/index.md)
diff --git a/doc/api/api_resources.md b/doc/api/api_resources.md
index 4a70786b6ee..568acb76e5f 100644
--- a/doc/api/api_resources.md
+++ b/doc/api/api_resources.md
@@ -56,6 +56,7 @@ The following API resources are available in the project context:
 | [Issues Statistics](issues_statistics.md)                               | `/projects/:id/issues_statistics` (also available for groups and standalone)                                                                                                                          |
 | [Issues](issues.md)                                                     | `/projects/:id/issues` (also available for groups and standalone)                                                                                                                                     |
 | [Iterations](iterations.md) **(PREMIUM)**                               | `/projects/:id/iterations` (also available for groups)                                                                                                                                                |
+| [Project CI/CD job token scope](project_job_token_scopes.md)            | `/projects/:id/job_token_scope`                                                                                                                                              |
 | [Jobs](jobs.md)                                                         | `/projects/:id/jobs`, `/projects/:id/pipelines/.../jobs`                                                                                                                                              |
 | [Jobs Artifacts](job_artifacts.md)                                      | `/projects/:id/jobs/:job_id/artifacts`                                                                                                                                                                |
 | [Labels](labels.md)                                                     | `/projects/:id/labels`                                                                                                                                                                                |
diff --git a/doc/api/audit_events.md b/doc/api/audit_events.md
index c4b3d99c742..e4856010b6c 100644
--- a/doc/api/audit_events.md
+++ b/doc/api/audit_events.md
@@ -8,7 +8,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/121) in GitLab 12.4.
 > - [Author Email added to the response body](https://gitlab.com/gitlab-org/gitlab/-/issues/386322) in GitLab 15.9.
-> - Support for keyset pagination [added](https://gitlab.com/gitlab-org/gitlab/-/issues/367528) in GitLab 15.11.
 
 ## Instance Audit Events **(PREMIUM SELF)**
 
@@ -19,15 +18,17 @@ To retrieve audit events using the API, you must [authenticate yourself](rest/in
 
 ### Retrieve all instance audit events
 
+> Support for keyset pagination [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367528) in GitLab 15.11.
+
 ```plaintext
 GET /audit_events
 ```
 
 | Attribute | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
-| `created_after` | string | no | Return audit events created on or after the given time. Format: ISO 8601 (`YYYY-MM-DDTHH:MM:SSZ`)  |
+| `created_after` | string | no | Return audit events created on or after the given time. Format: ISO 8601 (`YYYY-MM-DDTHH:MM:SSZ`) |
 | `created_before` | string | no | Return audit events created on or before the given time. Format: ISO 8601 (`YYYY-MM-DDTHH:MM:SSZ`) |
-| `entity_type` | string | no | Return audit events for the given entity type. Valid values are: `User`, `Group`, or `Project`.  |
+| `entity_type` | string | no | Return audit events for the given entity type. Valid values are: `User`, `Group`, or `Project`. |
 | `entity_id` | integer | no | Return audit events for the given entity ID. Requires `entity_type` attribute to be present. |
 
 This endpoint supports both offset-based and [keyset-based](rest/index.md#keyset-based-pagination) pagination. You should use keyset-based
@@ -139,9 +140,14 @@ Example response:
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34078) in GitLab 12.5.
 > - Support for keyset pagination [added](https://gitlab.com/gitlab-org/gitlab/-/issues/333968) in GitLab 15.2.
+> - Also returning project audit events for projects within the given group was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/feat/337757) in GitLab 16.1 behind feature flag `audit_event_group_rollup`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default returning project audit events for projects within the given group is not available. To make it available, ask an administrator
+to [enable the feature flag](../administration/feature_flags.md) named `audit_event_group_rollup`. On GitLab.com, this feature is not available. The feature is not ready for
+production use.
 
 The Group Audit Events API allows you to retrieve [group audit events](../administration/audit_events.md#group-events).
-This API cannot retrieve project audit events.
 
 A user with:
 
@@ -153,6 +159,8 @@ pagination is recommended when requesting consecutive pages of results.
 
 ### Retrieve all group audit events
 
+> Support for keyset pagination [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/333968) in GitLab 15.2.
+
 ```plaintext
 GET /groups/:id/audit_events
 ```
@@ -254,18 +262,17 @@ Example response:
 
 ## Project Audit Events
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/219238) in GitLab 13.1.
-> - Support for keyset pagination [added](https://gitlab.com/gitlab-org/gitlab/-/issues/367528) in GitLab 15.10.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/219238) in GitLab 13.1.
 
 The Project Audit Events API allows you to retrieve [project audit events](../administration/audit_events.md#project-events).
 
 A user with a Maintainer role (or above) can retrieve project audit events of all users.
 A user with a Developer role is limited to project audit events based on their individual actions.
 
-When requesting consecutive pages of results, you should use [keyset pagination](rest/index.md#keyset-based-pagination).
-
 ### Retrieve all project audit events
 
+> Support for keyset pagination [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367528) in GitLab 15.10.
+
 ```plaintext
 GET /projects/:id/audit_events
 ```
@@ -276,8 +283,8 @@ GET /projects/:id/audit_events
 | `created_after` | string | no | Return project audit events created on or after the given time. Format: ISO 8601 (`YYYY-MM-DDTHH:MM:SSZ`)  |
 | `created_before` | string | no | Return project audit events created on or before the given time. Format: ISO 8601 (`YYYY-MM-DDTHH:MM:SSZ`) |
 
-By default, `GET` requests return 20 results at a time because the API results
-are paginated.
+By default, `GET` requests return 20 results at a time because the API results are paginated.
+When requesting consecutive pages of results, you should use [keyset pagination](rest/index.md#keyset-based-pagination).
 
 Read more on [pagination](rest/index.md#pagination).
 
diff --git a/doc/api/bulk_imports.md b/doc/api/bulk_imports.md
index 31445240e1f..65a3ff71b8e 100644
--- a/doc/api/bulk_imports.md
+++ b/doc/api/bulk_imports.md
@@ -13,7 +13,7 @@ With the group migration by direct transfer API, you can start and view the prog
 [group migration by direct transfer](../user/group/import/index.md#migrate-groups-by-direct-transfer-recommended).
 
 WARNING:
-Migrating projects with this API is in [Beta](../policy/alpha-beta-support.md#beta). This feature is not
+Migrating projects with this API is in [Beta](../policy/experiment-beta-support.md#beta). This feature is not
 ready for production use.
 
 ## Prerequisites
diff --git a/doc/api/cluster_agents.md b/doc/api/cluster_agents.md
index 4bd16b88d92..1753757e5d9 100644
--- a/doc/api/cluster_agents.md
+++ b/doc/api/cluster_agents.md
@@ -365,12 +365,15 @@ Example response:
 
 ## Create an agent token
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/347046) in GitLab 15.0.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/347046) in GitLab 15.0.
+> - Two-token limit [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/361030) in GitLab 16.1.
 
 Creates a new token for an agent.
 
 You must have at least the Maintainer role to use this endpoint.
 
+An agent can have only two active tokens at one time.
+
 ```plaintext
 POST /projects/:id/cluster_agents/:agent_id/tokens
 ```
diff --git a/doc/api/dependencies.md b/doc/api/dependencies.md
index 5ae36926868..23eed014bc0 100644
--- a/doc/api/dependencies.md
+++ b/doc/api/dependencies.md
@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Dependencies API **(ULTIMATE)**
 
 WARNING:
-This API is in an [Experiment](../policy/alpha-beta-support.md#experiment) and considered unstable.
+This API is in an [Experiment](../policy/experiment-beta-support.md#experiment) and considered unstable.
 The response payload may be subject to change or breakage
 across GitLab releases.
 
diff --git a/doc/api/deploy_keys.md b/doc/api/deploy_keys.md
index 61e93b78067..003a5963ada 100644
--- a/doc/api/deploy_keys.md
+++ b/doc/api/deploy_keys.md
@@ -13,6 +13,8 @@ The deploy keys API can return in responses fingerprints of the public key in th
 
 ## List all deploy keys **(FREE SELF)**
 
+> `projects_with_readonly_access` [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119147) in GitLab 16.0.
+
 Get a list of all deploy keys across all projects of the GitLab instance. This
 endpoint requires administrator access and is not available on GitLab.com.
 
@@ -63,7 +65,8 @@ Example response:
         "path_with_namespace": "sidney_jones/project3",
         "created_at": "2021-10-25T18:33:17.666Z"
       }
-    ]
+    ],
+    "projects_with_readonly_access": []
   },
   {
     "id": 3,
@@ -73,7 +76,18 @@ Example response:
     "fingerprint_sha256": "SHA256:lGI/Ys/Wx7PfMhUO1iuBH92JQKYN+3mhJZvWO4Q5ims",
     "created_at": "2013-10-02T11:12:29Z",
     "expires_at": null,
-    "projects_with_write_access": []
+    "projects_with_write_access": [],
+    "projects_with_readonly_access": [
+      {
+        "id": 74,
+        "description": null,
+        "name": "project3",
+        "name_with_namespace": "Sidney Jones / project3",
+        "path": "project3",
+        "path_with_namespace": "sidney_jones/project3",
+        "created_at": "2021-10-25T18:33:17.666Z"
+      }
+    ]
   }
 ]
 ```
diff --git a/doc/api/deployments.md b/doc/api/deployments.md
index cbcf06e1a11..e937a234b08 100644
--- a/doc/api/deployments.md
+++ b/doc/api/deployments.md
@@ -279,7 +279,7 @@ Example response:
 }
 ```
 
-When the [unified approval setting](../ci/environments/deployment_approvals.md#unified-approval-setting) is configured, deployments created by users on GitLab Premium or Ultimate include the `approvals` and `pending_approval_count` properties:
+When the [unified approval setting](../ci/environments/deployment_approvals.md#unified-approval-setting-deprecated) is configured, deployments created by users on GitLab Premium or Ultimate include the `approvals` and `pending_approval_count` properties:
 
 ```json
 {
diff --git a/doc/api/environments.md b/doc/api/environments.md
index 3cbb6076300..d2335149301 100644
--- a/doc/api/environments.md
+++ b/doc/api/environments.md
@@ -40,89 +40,7 @@ Example response:
     "created_at": "2019-05-25T18:55:13.252Z",
     "updated_at": "2019-05-27T18:55:13.252Z",
     "enable_advanced_logs_querying": false,
-    "logs_api_path": "/project/-/logs/k8s.json?environment_name=review%2Ffix-foo",
-    "last_deployment": {
-      "id": 100,
-      "iid": 34,
-      "ref": "fdroid",
-      "sha": "416d8ea11849050d3d1f5104cf8cf51053e790ab",
-      "created_at": "2019-03-25T18:55:13.252Z",
-      "status": "success",
-      "user": {
-        "id": 1,
-        "name": "Administrator",
-        "state": "active",
-        "username": "root",
-        "avatar_url": "http://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80&d=identicon",
-        "web_url": "http://localhost:3000/root"
-      },
-      "deployable": {
-        "id": 710,
-        "status": "success",
-        "stage": "deploy",
-        "name": "staging",
-        "ref": "fdroid",
-        "tag": false,
-        "coverage": null,
-        "created_at": "2019-03-25T18:55:13.215Z",
-        "started_at": "2019-03-25T12:54:50.082Z",
-        "finished_at": "2019-03-25T18:55:13.216Z",
-        "duration": 21623.13423,
-        "project": {
-          "ci_job_token_scope_enabled": false
-        },
-        "user": {
-          "id": 1,
-          "name": "Administrator",
-          "username": "root",
-          "state": "active",
-          "avatar_url": "http://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80&d=identicon",
-          "web_url": "http://gitlab.dev/root",
-          "created_at": "2015-12-21T13:14:24.077Z",
-          "bio": null,
-          "location": null,
-          "public_email": "",
-          "skype": "",
-          "linkedin": "",
-          "twitter": "",
-          "website_url": "",
-          "organization": null
-        },
-        "commit": {
-          "id": "416d8ea11849050d3d1f5104cf8cf51053e790ab",
-          "short_id": "416d8ea1",
-          "created_at": "2016-01-02T15:39:18.000Z",
-          "parent_ids": [
-            "e9a4449c95c64358840902508fc827f1a2eab7df"
-          ],
-          "title": "Removed fabric to fix #40",
-          "message": "Removed fabric to fix #40\n",
-          "author_name": "Administrator",
-          "author_email": "admin@example.com",
-          "authored_date": "2016-01-02T15:39:18.000Z",
-          "committer_name": "Administrator",
-          "committer_email": "admin@example.com",
-          "committed_date": "2016-01-02T15:39:18.000Z"
-        },
-        "pipeline": {
-          "id": 34,
-          "sha": "416d8ea11849050d3d1f5104cf8cf51053e790ab",
-          "ref": "fdroid",
-          "status": "success",
-          "web_url": "http://localhost:3000/Commit451/lab-coat/pipelines/34"
-        },
-        "web_url": "http://localhost:3000/Commit451/lab-coat/-/jobs/710",
-        "artifacts": [
-          {
-            "file_type": "trace",
-            "size": 1305,
-            "filename": "job.log",
-            "file_format": null
-          }
-        ],
-        "runner": null,
-        "artifacts_expire_at": null
-      }
+    "logs_api_path": "/project/-/logs/k8s.json?environment_name=review%2Ffix-foo"
   }
 ]
 ```
@@ -299,7 +217,7 @@ PUT /projects/:id/environments/:environments_id
 | `tier`           | string         | no       | The tier of the new environment. Allowed values are `production`, `staging`, `testing`, `development`, and `other`. |
 
 ```shell
-curl --request PUT --data "name=staging&external_url=https://staging.gitlab.example.com" \
+curl --request PUT --data "external_url=https://staging.gitlab.example.com" \
      --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/environments/1"
 ```
 
diff --git a/doc/api/error_tracking.md b/doc/api/error_tracking.md
index 3515b080b12..d1ab67a93ae 100644
--- a/doc/api/error_tracking.md
+++ b/doc/api/error_tracking.md
@@ -138,13 +138,13 @@ Example response:
     "id": 1,
     "active": true,
     "public_key": "glet_aa77551d849c083f76d0bc545ed053a3",
-    "sentry_dsn": "https://glet_aa77551d849c083f76d0bc545ed053a3@gitlab.example.com/api/v4/error_tracking/collector/5"
+    "sentry_dsn": "https://glet_aa77551d849c083f76d0bc545ed053a3@example.com/errortracking/api/v1/projects/5"
   },
   {
     "id": 3,
     "active": true,
     "public_key": "glet_0ff98b1d849c083f76d0bc545ed053a3",
-    "sentry_dsn": "https://glet_0ff98b1d849c083f76d0bc545ed053a3@gitlab.example.com/api/v4/error_tracking/collector/5"
+    "sentry_dsn": "https://glet_aa77551d849c083f76d0bc545ed053a3@example.com/errortracking/api/v1/projects/5"
   }
 ]
 ```
@@ -173,7 +173,7 @@ Example response:
   "id": 3,
   "active": true,
   "public_key": "glet_0ff98b1d849c083f76d0bc545ed053a3",
-  "sentry_dsn": "https://glet_0ff98b1d849c083f76d0bc545ed053a3@gitlab.example.com/api/v4/error_tracking/collector/5"
+  "sentry_dsn": "https://glet_aa77551d849c083f76d0bc545ed053a3@example.com/errortracking/api/v1/projects/5"
 }
 ```
 
diff --git a/doc/api/geo_nodes.md b/doc/api/geo_nodes.md
index 038b7d633a6..b9d4f93d841 100644
--- a/doc/api/geo_nodes.md
+++ b/doc/api/geo_nodes.md
@@ -192,8 +192,6 @@ Example response:
 
 Updates settings of an existing Geo node.
 
-_This can only be run against a primary Geo node._
-
 ```plaintext
 PUT /geo_nodes/:id
 ```
@@ -550,7 +548,19 @@ Example response:
     "dependency_proxy_manifests_verified_count": 5,
     "dependency_proxy_manifests_verification_failed_count": 5,
     "dependency_proxy_manifests_synced_in_percentage": "100.00%",
-    "dependency_proxy_manifests_verified_in_percentage": "100.00%"
+    "dependency_proxy_manifests_verified_in_percentage": "100.00%",
+    "design_management_repositories_count": 5,
+    "design_management_repositories_checksum_total_count": 5,
+    "design_management_repositories_checksummed_count": 5,
+    "design_management_repositories_checksum_failed_count": 5,
+    "design_management_repositories_synced_count": 5,
+    "design_management_repositories_failed_count": 0,
+    "design_management_repositories_registry_count": 5,
+    "design_management_repositories_verification_total_count": 5,
+    "design_management_repositories_verified_count": 5,
+    "design_management_repositories_verification_failed_count": 5,
+    "design_management_repositories_synced_in_percentage": "100.00%",
+    "design_management_repositories_verified_in_percentage": "100.00%"
   },
   {
     "geo_node_id": 2,
@@ -580,6 +590,18 @@ Example response:
     "design_repositories_synced_count": null,
     "design_repositories_failed_count": null,
     "design_repositories_synced_in_percentage": "0.00%",
+    "design_management_repositories_count": 5,
+    "design_management_repositories_synced_count": 5,
+    "design_management_repositories_failed_count": 5,
+    "design_management_repositories_synced_in_percentage": "100.00%",
+    "design_management_repositories_checksum_total_count": 5,
+    "design_management_repositories_checksummed_count": 5,
+    "design_management_repositories_checksum_failed_count": 5,
+    "design_management_repositories_registry_count": 5,
+    "design_management_repositories_verification_total_count": 5,
+    "design_management_repositories_verified_count": 5,
+    "design_management_repositories_verification_failed_count": 5,
+    "design_management_repositories_verified_in_percentage": "100.00%",
     "projects_count": 41,
     "repositories_count": 41,
     "repositories_failed_count": 1,
@@ -966,7 +988,19 @@ Example response:
   "dependency_proxy_manifests_verified_count": 5,
   "dependency_proxy_manifests_verification_failed_count": 5,
   "dependency_proxy_manifests_synced_in_percentage": "100.00%",
-  "dependency_proxy_manifests_verified_in_percentage": "100.00%"
+  "dependency_proxy_manifests_verified_in_percentage": "100.00%",
+  "design_management_repositories_count": 5,
+  "design_management_repositories_checksum_total_count": 5,
+  "design_management_repositories_checksummed_count": 5,
+  "design_management_repositories_checksum_failed_count": 5,
+  "design_management_repositories_synced_count": 5,
+  "design_management_repositories_failed_count": 0,
+  "design_management_repositories_registry_count": 5,
+  "design_management_repositories_verification_total_count": 5,
+  "design_management_repositories_verified_count": 5,
+  "design_management_repositories_verification_failed_count": 5,
+  "design_management_repositories_synced_in_percentage": "100.00%",
+  "design_management_repositories_verified_in_percentage": "100.00%"
 }
 ```
 
diff --git a/doc/api/geo_sites.md b/doc/api/geo_sites.md
index 40410cdf540..ff06f668514 100644
--- a/doc/api/geo_sites.md
+++ b/doc/api/geo_sites.md
@@ -179,9 +179,9 @@ Example response:
 }
 ```
 
-## Edit a primary Geo site
+## Edit a Geo site
 
-Updates settings of an existing primary Geo site.
+Updates settings of an existing Geo site.
 
 ```plaintext
 PUT /geo_sites/:id
diff --git a/doc/api/graphql/getting_started.md b/doc/api/graphql/getting_started.md
index 237c0cc6934..5142496753c 100644
--- a/doc/api/graphql/getting_started.md
+++ b/doc/api/graphql/getting_started.md
@@ -4,7 +4,7 @@ group: Import and Integrate
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Get started with GitLab GraphQL API **(FREE)**
+# Run GraphQL API queries and mutations **(FREE)**
 
 This guide demonstrates basic usage of the GitLab GraphQL API.
 
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 525e06eda91..95420764226 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -36,6 +36,37 @@ in [Removed Items](../removed_items.md).
 
 The `Query` type contains the API's top-level entry points for all executable queries.
 
+### `Query.aiMessages`
+
+Find AI messages.
+
+WARNING:
+**Introduced** in 16.1.
+This feature is an Experiment. It can be changed or removed at any time.
+
+Returns [`AiCachedMessageTypeConnection!`](#aicachedmessagetypeconnection).
+
+This field returns a [connection](#connections). It accepts the
+four standard [pagination arguments](#connection-pagination-arguments):
+`before: String`, `after: String`, `first: Int`, `last: Int`.
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="queryaimessagesrequestids"></a>`requestIds` | [`[ID!]`](#id) | Array of request IDs to fetch. |
+| <a id="queryaimessagesroles"></a>`roles` | [`[AiCachedMessageRole!]`](#aicachedmessagerole) | Array of roles to fetch. |
+
+### `Query.auditEventDefinitions`
+
+Definitions for all audit events available on the instance.
+
+Returns [`AuditEventDefinitionConnection!`](#auditeventdefinitionconnection).
+
+This field returns a [connection](#connections). It accepts the
+four standard [pagination arguments](#connection-pagination-arguments):
+`before: String`, `after: String`, `first: Int`, `last: Int`.
+
 ### `Query.boardList`
 
 Find an issue board list.
@@ -55,9 +86,25 @@ CI related settings that apply to the entire instance.
 
 Returns [`CiApplicationSettings`](#ciapplicationsettings).
 
+### `Query.ciCatalogResource`
+
+A single CI/CD Catalog resource visible to an authorized user.
+
+WARNING:
+**Introduced** in 16.1.
+This feature is an Experiment. It can be changed or removed at any time.
+
+Returns [`CiCatalogResource`](#cicatalogresource).
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="querycicatalogresourceid"></a>`id` | [`CiCatalogResourceID!`](#cicatalogresourceid) | CI/CD Catalog resource global ID. |
+
 ### `Query.ciCatalogResources`
 
-CI Catalog resources visible to the current user.
+All CI/CD Catalog resources under a common namespace, visible to an authorized user.
 
 WARNING:
 **Introduced** in 15.11.
@@ -74,6 +121,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="querycicatalogresourcesprojectpath"></a>`projectPath` | [`ID`](#id) | Project with the namespace catalog. |
+| <a id="querycicatalogresourcessort"></a>`sort` | [`CiCatalogResourceSort`](#cicatalogresourcesort) | Sort Catalog Resources by given criteria. |
 
 ### `Query.ciConfig`
 
@@ -93,7 +141,7 @@ Returns [`CiConfig`](#ciconfig).
 
 ### `Query.ciMinutesUsage`
 
-CI/CD minutes usage data for a namespace.
+Compute usage data for a namespace.
 
 Returns [`CiMinutesNamespaceMonthlyUsageConnection`](#ciminutesnamespacemonthlyusageconnection).
 
@@ -106,7 +154,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="queryciminutesusagedate"></a>`date` | [`Date`](#date) | Date for which to retrieve the usage data, should be the first day of a month. |
-| <a id="queryciminutesusagenamespaceid"></a>`namespaceId` | [`NamespaceID`](#namespaceid) | Global ID of the Namespace for the monthly CI/CD minutes usage. |
+| <a id="queryciminutesusagenamespaceid"></a>`namespaceId` | [`NamespaceID`](#namespaceid) | Global ID of the Namespace for the monthly compute usage. |
 
 ### `Query.ciPipelineStage`
 
@@ -1016,13 +1064,18 @@ Input type: `AiActionInput`
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
+| <a id="mutationaiactionanalyzecijobfailure"></a>`analyzeCiJobFailure` | [`AnalyzeCiJobFailureInput`](#analyzecijobfailureinput) | Input for analyze_ci_job_failure AI action. |
+| <a id="mutationaiactionchat"></a>`chat` | [`AiChatInput`](#aichatinput) | Input for chat AI action. |
 | <a id="mutationaiactionclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
 | <a id="mutationaiactionexplaincode"></a>`explainCode` | [`AiExplainCodeInput`](#aiexplaincodeinput) | Input for explain_code AI action. |
 | <a id="mutationaiactionexplainvulnerability"></a>`explainVulnerability` | [`AiExplainVulnerabilityInput`](#aiexplainvulnerabilityinput) | Input for explain_vulnerability AI action. |
+| <a id="mutationaiactionfillinmergerequesttemplate"></a>`fillInMergeRequestTemplate` | [`AiFillInMergeRequestTemplateInput`](#aifillinmergerequesttemplateinput) | Input for fill_in_merge_request_template AI action. |
+| <a id="mutationaiactiongeneratecommitmessage"></a>`generateCommitMessage` | [`AiGenerateCommitMessageInput`](#aigeneratecommitmessageinput) | Input for generate_commit_message AI action. |
 | <a id="mutationaiactiongeneratedescription"></a>`generateDescription` | [`AiGenerateDescriptionInput`](#aigeneratedescriptioninput) | Input for generate_description AI action. |
 | <a id="mutationaiactiongeneratetestfile"></a>`generateTestFile` | [`GenerateTestFileInput`](#generatetestfileinput) | Input for generate_test_file AI action. |
 | <a id="mutationaiactionmarkupformat"></a>`markupFormat` | [`MarkupFormat`](#markupformat) | Indicates the response format. |
 | <a id="mutationaiactionsummarizecomments"></a>`summarizeComments` | [`AiSummarizeCommentsInput`](#aisummarizecommentsinput) | Input for summarize_comments AI action. |
+| <a id="mutationaiactionsummarizereview"></a>`summarizeReview` | [`AiSummarizeReviewInput`](#aisummarizereviewinput) | Input for summarize_review AI action. |
 | <a id="mutationaiactiontanukibot"></a>`tanukiBot` | [`AiTanukiBotInput`](#aitanukibotinput) | Input for tanuki_bot AI action. |
 
 #### Fields
@@ -1219,6 +1272,48 @@ Input type: `AuditEventsStreamingHeadersUpdateInput`
 | <a id="mutationauditeventsstreamingheadersupdateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 | <a id="mutationauditeventsstreamingheadersupdateheader"></a>`header` | [`AuditEventStreamingHeader`](#auditeventstreamingheader) | Updates header. |
 
+### `Mutation.auditEventsStreamingInstanceHeadersCreate`
+
+Input type: `AuditEventsStreamingInstanceHeadersCreateInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationauditeventsstreaminginstanceheaderscreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationauditeventsstreaminginstanceheaderscreatedestinationid"></a>`destinationId` | [`AuditEventsInstanceExternalAuditEventDestinationID!`](#auditeventsinstanceexternalauditeventdestinationid) | Instance level external destination to associate header with. |
+| <a id="mutationauditeventsstreaminginstanceheaderscreatekey"></a>`key` | [`String!`](#string) | Header key. |
+| <a id="mutationauditeventsstreaminginstanceheaderscreatevalue"></a>`value` | [`String!`](#string) | Header value. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationauditeventsstreaminginstanceheaderscreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationauditeventsstreaminginstanceheaderscreateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+| <a id="mutationauditeventsstreaminginstanceheaderscreateheader"></a>`header` | [`AuditEventsStreamingInstanceHeader`](#auditeventsstreaminginstanceheader) | Created header. |
+
+### `Mutation.auditEventsStreamingInstanceHeadersUpdate`
+
+Input type: `AuditEventsStreamingInstanceHeadersUpdateInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationauditeventsstreaminginstanceheadersupdateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationauditeventsstreaminginstanceheadersupdateheaderid"></a>`headerId` | [`AuditEventsStreamingInstanceHeaderID!`](#auditeventsstreaminginstanceheaderid) | Header to update. |
+| <a id="mutationauditeventsstreaminginstanceheadersupdatekey"></a>`key` | [`String!`](#string) | Header key. |
+| <a id="mutationauditeventsstreaminginstanceheadersupdatevalue"></a>`value` | [`String!`](#string) | Header value. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationauditeventsstreaminginstanceheadersupdateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationauditeventsstreaminginstanceheadersupdateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+| <a id="mutationauditeventsstreaminginstanceheadersupdateheader"></a>`header` | [`AuditEventsStreamingInstanceHeader`](#auditeventsstreaminginstanceheader) | Updates header. |
+
 ### `Mutation.awardEmojiAdd`
 
 Input type: `AwardEmojiAddInput`
@@ -1348,6 +1443,31 @@ Input type: `BoardListUpdateLimitMetricsInput`
 | <a id="mutationboardlistupdatelimitmetricserrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 | <a id="mutationboardlistupdatelimitmetricslist"></a>`list` | [`BoardList`](#boardlist) | Updated list. |
 
+### `Mutation.buildForecast`
+
+WARNING:
+**Introduced** in 16.0.
+This feature is an Experiment. It can be changed or removed at any time.
+
+Input type: `BuildForecastInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationbuildforecastclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationbuildforecastcontextid"></a>`contextId` | [`GlobalID!`](#globalid) | Global ID of the context for the forecast to pick an appropriate model. |
+| <a id="mutationbuildforecasthorizon"></a>`horizon` | [`Int!`](#int) | Number of data points to forecast. |
+| <a id="mutationbuildforecasttype"></a>`type` | [`String!`](#string) | Type of the forecast. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationbuildforecastclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationbuildforecasterrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+| <a id="mutationbuildforecastforecast"></a>`forecast` | [`Forecast!`](#forecast) | Created forecast. |
+
 ### `Mutation.bulkDestroyJobArtifacts`
 
 WARNING:
@@ -1465,35 +1585,6 @@ Input type: `CiAiGenerateConfigInput`
 | <a id="mutationciaigenerateconfigerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 | <a id="mutationciaigenerateconfigusermessage"></a>`userMessage` | [`AiMessageType`](#aimessagetype) | User chat message. |
 
-### `Mutation.ciCdSettingsUpdate`
-
-WARNING:
-**Deprecated** in 15.0.
-This was renamed.
-Use: `ProjectCiCdSettingsUpdate`.
-
-Input type: `CiCdSettingsUpdateInput`
-
-#### Arguments
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationcicdsettingsupdateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationcicdsettingsupdatefullpath"></a>`fullPath` | [`ID!`](#id) | Full Path of the project the settings belong to. |
-| <a id="mutationcicdsettingsupdateinboundjobtokenscopeenabled"></a>`inboundJobTokenScopeEnabled` | [`Boolean`](#boolean) | Indicates CI/CD job tokens generated in other projects have restricted access to this project. |
-| <a id="mutationcicdsettingsupdatejobtokenscopeenabled"></a>`jobTokenScopeEnabled` **{warning-solid}** | [`Boolean`](#boolean) | **Deprecated:** Outbound job token scope is being removed. This field can now only be set to false. Deprecated in 16.0. |
-| <a id="mutationcicdsettingsupdatekeeplatestartifact"></a>`keepLatestArtifact` | [`Boolean`](#boolean) | Indicates if the latest artifact should be kept for the project. |
-| <a id="mutationcicdsettingsupdatemergepipelinesenabled"></a>`mergePipelinesEnabled` | [`Boolean`](#boolean) | Indicates if merge pipelines are enabled for the project. |
-| <a id="mutationcicdsettingsupdatemergetrainsenabled"></a>`mergeTrainsEnabled` | [`Boolean`](#boolean) | Indicates if merge trains are enabled for the project. |
-
-#### Fields
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationcicdsettingsupdatecicdsettings"></a>`ciCdSettings` | [`ProjectCiCdSetting!`](#projectcicdsetting) | CI/CD settings after mutation. |
-| <a id="mutationcicdsettingsupdateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationcicdsettingsupdateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
-
 ### `Mutation.ciJobTokenScopeAddProject`
 
 Input type: `CiJobTokenScopeAddProjectInput`
@@ -3038,6 +3129,51 @@ Input type: `EnableDevopsAdoptionNamespaceInput`
 | <a id="mutationenabledevopsadoptionnamespaceenablednamespace"></a>`enabledNamespace` | [`DevopsAdoptionEnabledNamespace`](#devopsadoptionenablednamespace) | Enabled namespace after mutation. |
 | <a id="mutationenabledevopsadoptionnamespaceerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 
+### `Mutation.environmentCreate`
+
+Create an environment.
+
+Input type: `EnvironmentCreateInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationenvironmentcreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationenvironmentcreateclusteragentid"></a>`clusterAgentId` | [`ClustersAgentID`](#clustersagentid) | Cluster agent of the environment. |
+| <a id="mutationenvironmentcreateexternalurl"></a>`externalUrl` | [`String`](#string) | External URL of the environment. |
+| <a id="mutationenvironmentcreatename"></a>`name` | [`String!`](#string) | Name of the environment. |
+| <a id="mutationenvironmentcreateprojectpath"></a>`projectPath` | [`ID!`](#id) | Full path of the project. |
+| <a id="mutationenvironmentcreatetier"></a>`tier` | [`DeploymentTier`](#deploymenttier) | Tier of the environment. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationenvironmentcreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationenvironmentcreateenvironment"></a>`environment` | [`Environment`](#environment) | Created environment. |
+| <a id="mutationenvironmentcreateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+
+### `Mutation.environmentDelete`
+
+Delete an environment.
+
+Input type: `EnvironmentDeleteInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationenvironmentdeleteclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationenvironmentdeleteid"></a>`id` | [`EnvironmentID!`](#environmentid) | Global ID of the environment to Delete. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationenvironmentdeleteclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationenvironmentdeleteerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+
 ### `Mutation.environmentStop`
 
 Stop an environment.
@@ -3060,6 +3196,30 @@ Input type: `EnvironmentStopInput`
 | <a id="mutationenvironmentstopenvironment"></a>`environment` | [`Environment`](#environment) | Environment after attempt to stop. |
 | <a id="mutationenvironmentstoperrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 
+### `Mutation.environmentUpdate`
+
+Update an environment.
+
+Input type: `EnvironmentUpdateInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationenvironmentupdateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationenvironmentupdateclusteragentid"></a>`clusterAgentId` | [`ClustersAgentID`](#clustersagentid) | Cluster agent of the environment. |
+| <a id="mutationenvironmentupdateexternalurl"></a>`externalUrl` | [`String`](#string) | External URL of the environment. |
+| <a id="mutationenvironmentupdateid"></a>`id` | [`EnvironmentID!`](#environmentid) | Global ID of the environment to update. |
+| <a id="mutationenvironmentupdatetier"></a>`tier` | [`DeploymentTier`](#deploymenttier) | Tier of the environment. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationenvironmentupdateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationenvironmentupdateenvironment"></a>`environment` | [`Environment`](#environment) | Environment after attempt to update. |
+| <a id="mutationenvironmentupdateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+
 ### `Mutation.environmentsCanaryIngressUpdate`
 
 **Deprecated** This endpoint is planned to be removed along with certificate-based clusters. [See this epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) for more information.
@@ -3453,6 +3613,70 @@ Input type: `GitlabSubscriptionActivateInput`
 | <a id="mutationgitlabsubscriptionactivatefuturesubscriptions"></a>`futureSubscriptions` | [`[SubscriptionFutureEntry!]`](#subscriptionfutureentry) | Array of future subscriptions. |
 | <a id="mutationgitlabsubscriptionactivatelicense"></a>`license` | [`CurrentLicense`](#currentlicense) | Current license. |
 
+### `Mutation.googleCloudLoggingConfigurationCreate`
+
+Input type: `GoogleCloudLoggingConfigurationCreateInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationgooglecloudloggingconfigurationcreateclientemail"></a>`clientEmail` | [`String!`](#string) | Email address associated with the service account that will be used to authenticate and interact with the Google Cloud Logging service. This is part of the IAM credentials. |
+| <a id="mutationgooglecloudloggingconfigurationcreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationgooglecloudloggingconfigurationcreategoogleprojectidname"></a>`googleProjectIdName` | [`String!`](#string) | Unique identifier of the Google Cloud project to which the logging configuration belongs. |
+| <a id="mutationgooglecloudloggingconfigurationcreategrouppath"></a>`groupPath` | [`ID!`](#id) | Group path. |
+| <a id="mutationgooglecloudloggingconfigurationcreatelogidname"></a>`logIdName` | [`String`](#string) | Unique identifier used to distinguish and manage different logs within the same Google Cloud project.(defaults to `audit_events`). |
+| <a id="mutationgooglecloudloggingconfigurationcreateprivatekey"></a>`privateKey` | [`String!`](#string) | Private Key associated with the service account. This key is used to authenticate the service account and authorize it to interact with the Google Cloud Logging service. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationgooglecloudloggingconfigurationcreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationgooglecloudloggingconfigurationcreateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+| <a id="mutationgooglecloudloggingconfigurationcreategooglecloudloggingconfiguration"></a>`googleCloudLoggingConfiguration` | [`GoogleCloudLoggingConfigurationType`](#googlecloudloggingconfigurationtype) | configuration created. |
+
+### `Mutation.googleCloudLoggingConfigurationDestroy`
+
+Input type: `GoogleCloudLoggingConfigurationDestroyInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationgooglecloudloggingconfigurationdestroyclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationgooglecloudloggingconfigurationdestroyid"></a>`id` | [`AuditEventsGoogleCloudLoggingConfigurationID!`](#auditeventsgooglecloudloggingconfigurationid) | ID of the Google Cloud logging configuration to destroy. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationgooglecloudloggingconfigurationdestroyclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationgooglecloudloggingconfigurationdestroyerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+
+### `Mutation.googleCloudLoggingConfigurationUpdate`
+
+Input type: `GoogleCloudLoggingConfigurationUpdateInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationgooglecloudloggingconfigurationupdateclientemail"></a>`clientEmail` | [`String`](#string) | Email address associated with the service account that will be used to authenticate and interact with the Google Cloud Logging service. This is part of the IAM credentials. |
+| <a id="mutationgooglecloudloggingconfigurationupdateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationgooglecloudloggingconfigurationupdategoogleprojectidname"></a>`googleProjectIdName` | [`String`](#string) | Unique identifier of the Google Cloud project to which the logging configuration belongs. |
+| <a id="mutationgooglecloudloggingconfigurationupdateid"></a>`id` | [`AuditEventsGoogleCloudLoggingConfigurationID!`](#auditeventsgooglecloudloggingconfigurationid) | ID of the google Cloud configuration to update. |
+| <a id="mutationgooglecloudloggingconfigurationupdatelogidname"></a>`logIdName` | [`String`](#string) | Unique identifier used to distinguish and manage different logs within the same Google Cloud project. |
+| <a id="mutationgooglecloudloggingconfigurationupdateprivatekey"></a>`privateKey` | [`String`](#string) | Private Key associated with the service account. This key is used to authenticate the service account and authorize it to interact with the Google Cloud Logging service. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationgooglecloudloggingconfigurationupdateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationgooglecloudloggingconfigurationupdateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+| <a id="mutationgooglecloudloggingconfigurationupdategooglecloudloggingconfiguration"></a>`googleCloudLoggingConfiguration` | [`GoogleCloudLoggingConfigurationType`](#googlecloudloggingconfigurationtype) | configuration updated. |
+
 ### `Mutation.groupMemberBulkUpdate`
 
 Input type: `GroupMemberBulkUpdateInput`
@@ -5471,8 +5695,8 @@ Input type: `RunnerUpdateInput`
 | <a id="mutationrunnerupdatemaintenancenote"></a>`maintenanceNote` | [`String`](#string) | Runner's maintenance notes. |
 | <a id="mutationrunnerupdatemaximumtimeout"></a>`maximumTimeout` | [`Int`](#int) | Maximum timeout (in seconds) for jobs processed by the runner. |
 | <a id="mutationrunnerupdatepaused"></a>`paused` | [`Boolean`](#boolean) | Indicates the runner is not allowed to receive jobs. |
-| <a id="mutationrunnerupdateprivateprojectsminutescostfactor"></a>`privateProjectsMinutesCostFactor` | [`Float`](#float) | Private projects' "minutes cost factor" associated with the runner (GitLab.com only). |
-| <a id="mutationrunnerupdatepublicprojectsminutescostfactor"></a>`publicProjectsMinutesCostFactor` | [`Float`](#float) | Public projects' "minutes cost factor" associated with the runner (GitLab.com only). |
+| <a id="mutationrunnerupdateprivateprojectsminutescostfactor"></a>`privateProjectsMinutesCostFactor` | [`Float`](#float) | Private projects' "compute cost factor" associated with the runner (GitLab.com only). |
+| <a id="mutationrunnerupdatepublicprojectsminutescostfactor"></a>`publicProjectsMinutesCostFactor` | [`Float`](#float) | Public projects' "compute cost factor" associated with the runner (GitLab.com only). |
 | <a id="mutationrunnerupdaterununtagged"></a>`runUntagged` | [`Boolean`](#boolean) | Indicates the runner is able to run untagged jobs. |
 | <a id="mutationrunnerupdatetaglist"></a>`tagList` | [`[String!]`](#string) | Tags associated with the runner. |
 
@@ -5588,6 +5812,7 @@ Input type: `ScanExecutionPolicyCommitInput`
 | <a id="mutationscanexecutionpolicycommitbranch"></a>`branch` | [`String`](#string) | Name of the branch to which the policy changes are committed. |
 | <a id="mutationscanexecutionpolicycommitclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
 | <a id="mutationscanexecutionpolicycommiterrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+| <a id="mutationscanexecutionpolicycommitvalidationerrors"></a>`validationErrors` | [`[SecurityPolicyValidationError!]`](#securitypolicyvalidationerror) | Validation errors encountered during execution of the mutation. |
 
 ### `Mutation.securityFindingCreateIssue`
 
@@ -6193,6 +6418,10 @@ Input type: `UpdateContainerExpirationPolicyInput`
 
 ### `Mutation.updateDependencyProxyImageTtlGroupPolicy`
 
+These settings can be adjusted by the group Owner or Maintainer.
+[Issue 370471](https://gitlab.com/gitlab-org/gitlab/-/issues/370471) proposes limiting
+this to Owners only to match the permissions level in the user interface.
+
 Input type: `UpdateDependencyProxyImageTtlGroupPolicyInput`
 
 #### Arguments
@@ -6214,7 +6443,9 @@ Input type: `UpdateDependencyProxyImageTtlGroupPolicyInput`
 
 ### `Mutation.updateDependencyProxySettings`
 
-These settings can be adjusted by the group Owner or Maintainer. However, in GitLab 16.0, we will be limiting this to the Owner role. [GitLab-#364441](https://gitlab.com/gitlab-org/gitlab/-/issues/364441) proposes making this change to match the permissions level in the user interface.
+These settings can be adjusted by the group Owner or Maintainer.
+[Issue 370471](https://gitlab.com/gitlab-org/gitlab/-/issues/370471) proposes limiting
+this to Owners only to match the permissions level in the user interface.
 
 Input type: `UpdateDependencyProxySettingsInput`
 
@@ -6375,6 +6606,10 @@ Input type: `UpdateIterationInput`
 
 ### `Mutation.updateNamespacePackageSettings`
 
+These settings can be adjusted by the group Owner or Maintainer.
+[Issue 370471](https://gitlab.com/gitlab-org/gitlab/-/issues/370471) proposes limiting
+this to Owners only to match the permissions level in the user interface.
+
 Input type: `UpdateNamespacePackageSettingsInput`
 
 #### Arguments
@@ -6520,6 +6755,29 @@ Input type: `UploadDeleteInput`
 | <a id="mutationuploaddeleteerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 | <a id="mutationuploaddeleteupload"></a>`upload` | [`FileUpload`](#fileupload) | Deleted upload. |
 
+### `Mutation.userAchievementsDelete`
+
+WARNING:
+**Introduced** in 16.1.
+This feature is an Experiment. It can be changed or removed at any time.
+
+Input type: `UserAchievementsDeleteInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationuserachievementsdeleteclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationuserachievementsdeleteuserachievementid"></a>`userAchievementId` | [`AchievementsUserAchievementID!`](#achievementsuserachievementid) | Global ID of the user achievement being deleted. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationuserachievementsdeleteclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationuserachievementsdeleteerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+| <a id="mutationuserachievementsdeleteuserachievement"></a>`userAchievement` | [`UserAchievement`](#userachievement) | Deleted user achievement. |
+
 ### `Mutation.userCalloutCreate`
 
 Input type: `UserCalloutCreateInput`
@@ -6559,6 +6817,26 @@ Input type: `UserPreferencesUpdateInput`
 | <a id="mutationuserpreferencesupdateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 | <a id="mutationuserpreferencesupdateuserpreferences"></a>`userPreferences` | [`UserPreferences`](#userpreferences) | User preferences after mutation. |
 
+### `Mutation.userSetNamespaceCommitEmail`
+
+Input type: `UserSetNamespaceCommitEmailInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationusersetnamespacecommitemailclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationusersetnamespacecommitemailemailid"></a>`emailId` | [`EmailID`](#emailid) | ID of the email to set. |
+| <a id="mutationusersetnamespacecommitemailnamespaceid"></a>`namespaceId` | [`NamespaceID!`](#namespaceid) | ID of the namespace to set the namespace commit email for. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationusersetnamespacecommitemailclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationusersetnamespacecommitemailerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+| <a id="mutationusersetnamespacecommitemailnamespacecommitemail"></a>`namespaceCommitEmail` | [`NamespaceCommitEmail`](#namespacecommitemail) | User namespace commit email after mutation. |
+
 ### `Mutation.vulnerabilityConfirm`
 
 Input type: `VulnerabilityConfirmInput`
@@ -6594,7 +6872,7 @@ Input type: `VulnerabilityCreateInput`
 | <a id="mutationvulnerabilitycreatedetectedat"></a>`detectedAt` | [`Time`](#time) | Timestamp of when the vulnerability was first detected (defaults to creation time). |
 | <a id="mutationvulnerabilitycreatedismissedat"></a>`dismissedAt` | [`Time`](#time) | Timestamp of when the vulnerability state changed to dismissed (defaults to creation time if status is `dismissed`). |
 | <a id="mutationvulnerabilitycreateidentifiers"></a>`identifiers` | [`[VulnerabilityIdentifierInput!]!`](#vulnerabilityidentifierinput) | Array of CVE or CWE identifiers for the vulnerability. |
-| <a id="mutationvulnerabilitycreatemessage"></a>`message` | [`String`](#string) | Short text section that describes the vulnerability. This may include the finding's specific information. |
+| <a id="mutationvulnerabilitycreatemessage"></a>`message` **{warning-solid}** | [`String`](#string) | **Deprecated:** message field has been removed from security reports schema. Deprecated in 16.1. |
 | <a id="mutationvulnerabilitycreatename"></a>`name` | [`String!`](#string) | Name of the vulnerability. |
 | <a id="mutationvulnerabilitycreateproject"></a>`project` | [`ProjectID!`](#projectid) | ID of the project to attach the vulnerability to. |
 | <a id="mutationvulnerabilitycreateresolvedat"></a>`resolvedAt` | [`Time`](#time) | Timestamp of when the vulnerability state changed to resolved (defaults to creation time if status is `resolved`). |
@@ -7106,6 +7384,29 @@ The edge type for [`AgentConfiguration`](#agentconfiguration).
 | <a id="agentconfigurationedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="agentconfigurationedgenode"></a>`node` | [`AgentConfiguration`](#agentconfiguration) | The item at the end of the edge. |
 
+#### `AiCachedMessageTypeConnection`
+
+The connection type for [`AiCachedMessageType`](#aicachedmessagetype).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="aicachedmessagetypeconnectionedges"></a>`edges` | [`[AiCachedMessageTypeEdge]`](#aicachedmessagetypeedge) | A list of edges. |
+| <a id="aicachedmessagetypeconnectionnodes"></a>`nodes` | [`[AiCachedMessageType]`](#aicachedmessagetype) | A list of nodes. |
+| <a id="aicachedmessagetypeconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `AiCachedMessageTypeEdge`
+
+The edge type for [`AiCachedMessageType`](#aicachedmessagetype).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="aicachedmessagetypeedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="aicachedmessagetypeedgenode"></a>`node` | [`AiCachedMessageType`](#aicachedmessagetype) | The item at the end of the edge. |
+
 #### `AiMessageTypeConnection`
 
 The connection type for [`AiMessageType`](#aimessagetype).
@@ -7221,6 +7522,29 @@ The edge type for [`ApprovalProjectRule`](#approvalprojectrule).
 | <a id="approvalprojectruleedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="approvalprojectruleedgenode"></a>`node` | [`ApprovalProjectRule`](#approvalprojectrule) | The item at the end of the edge. |
 
+#### `AuditEventDefinitionConnection`
+
+The connection type for [`AuditEventDefinition`](#auditeventdefinition).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="auditeventdefinitionconnectionedges"></a>`edges` | [`[AuditEventDefinitionEdge]`](#auditeventdefinitionedge) | A list of edges. |
+| <a id="auditeventdefinitionconnectionnodes"></a>`nodes` | [`[AuditEventDefinition]`](#auditeventdefinition) | A list of nodes. |
+| <a id="auditeventdefinitionconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `AuditEventDefinitionEdge`
+
+The edge type for [`AuditEventDefinition`](#auditeventdefinition).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="auditeventdefinitionedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="auditeventdefinitionedgenode"></a>`node` | [`AuditEventDefinition`](#auditeventdefinition) | The item at the end of the edge. |
+
 #### `AuditEventStreamingHeaderConnection`
 
 The connection type for [`AuditEventStreamingHeader`](#auditeventstreamingheader).
@@ -7244,6 +7568,29 @@ The edge type for [`AuditEventStreamingHeader`](#auditeventstreamingheader).
 | <a id="auditeventstreamingheaderedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="auditeventstreamingheaderedgenode"></a>`node` | [`AuditEventStreamingHeader`](#auditeventstreamingheader) | The item at the end of the edge. |
 
+#### `AuditEventsStreamingInstanceHeaderConnection`
+
+The connection type for [`AuditEventsStreamingInstanceHeader`](#auditeventsstreaminginstanceheader).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="auditeventsstreaminginstanceheaderconnectionedges"></a>`edges` | [`[AuditEventsStreamingInstanceHeaderEdge]`](#auditeventsstreaminginstanceheaderedge) | A list of edges. |
+| <a id="auditeventsstreaminginstanceheaderconnectionnodes"></a>`nodes` | [`[AuditEventsStreamingInstanceHeader]`](#auditeventsstreaminginstanceheader) | A list of nodes. |
+| <a id="auditeventsstreaminginstanceheaderconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `AuditEventsStreamingInstanceHeaderEdge`
+
+The edge type for [`AuditEventsStreamingInstanceHeader`](#auditeventsstreaminginstanceheader).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="auditeventsstreaminginstanceheaderedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="auditeventsstreaminginstanceheaderedgenode"></a>`node` | [`AuditEventsStreamingInstanceHeader`](#auditeventsstreaminginstanceheader) | The item at the end of the edge. |
+
 #### `AwardEmojiConnection`
 
 The connection type for [`AwardEmoji`](#awardemoji).
@@ -7545,6 +7892,29 @@ The edge type for [`CiGroup`](#cigroup).
 | <a id="cigroupedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="cigroupedgenode"></a>`node` | [`CiGroup`](#cigroup) | The item at the end of the edge. |
 
+#### `CiGroupEnvironmentScopeConnection`
+
+The connection type for [`CiGroupEnvironmentScope`](#cigroupenvironmentscope).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="cigroupenvironmentscopeconnectionedges"></a>`edges` | [`[CiGroupEnvironmentScopeEdge]`](#cigroupenvironmentscopeedge) | A list of edges. |
+| <a id="cigroupenvironmentscopeconnectionnodes"></a>`nodes` | [`[CiGroupEnvironmentScope]`](#cigroupenvironmentscope) | A list of nodes. |
+| <a id="cigroupenvironmentscopeconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `CiGroupEnvironmentScopeEdge`
+
+The edge type for [`CiGroupEnvironmentScope`](#cigroupenvironmentscope).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="cigroupenvironmentscopeedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="cigroupenvironmentscopeedgenode"></a>`node` | [`CiGroupEnvironmentScope`](#cigroupenvironmentscope) | The item at the end of the edge. |
+
 #### `CiGroupVariableConnection`
 
 The connection type for [`CiGroupVariable`](#cigroupvariable).
@@ -8560,6 +8930,29 @@ The edge type for [`Design`](#design).
 | <a id="designedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="designedgenode"></a>`node` | [`Design`](#design) | The item at the end of the edge. |
 
+#### `DesignManagementRepositoryRegistryConnection`
+
+The connection type for [`DesignManagementRepositoryRegistry`](#designmanagementrepositoryregistry).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="designmanagementrepositoryregistryconnectionedges"></a>`edges` | [`[DesignManagementRepositoryRegistryEdge]`](#designmanagementrepositoryregistryedge) | A list of edges. |
+| <a id="designmanagementrepositoryregistryconnectionnodes"></a>`nodes` | [`[DesignManagementRepositoryRegistry]`](#designmanagementrepositoryregistry) | A list of nodes. |
+| <a id="designmanagementrepositoryregistryconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `DesignManagementRepositoryRegistryEdge`
+
+The edge type for [`DesignManagementRepositoryRegistry`](#designmanagementrepositoryregistry).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="designmanagementrepositoryregistryedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="designmanagementrepositoryregistryedgenode"></a>`node` | [`DesignManagementRepositoryRegistry`](#designmanagementrepositoryregistry) | The item at the end of the edge. |
+
 #### `DesignVersionConnection`
 
 The connection type for [`DesignVersion`](#designversion).
@@ -8652,6 +9045,29 @@ The edge type for [`Discussion`](#discussion).
 | <a id="discussionedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="discussionedgenode"></a>`node` | [`Discussion`](#discussion) | The item at the end of the edge. |
 
+#### `DoraPerformanceScoreCountConnection`
+
+The connection type for [`DoraPerformanceScoreCount`](#doraperformancescorecount).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="doraperformancescorecountconnectionedges"></a>`edges` | [`[DoraPerformanceScoreCountEdge]`](#doraperformancescorecountedge) | A list of edges. |
+| <a id="doraperformancescorecountconnectionnodes"></a>`nodes` | [`[DoraPerformanceScoreCount]`](#doraperformancescorecount) | A list of nodes. |
+| <a id="doraperformancescorecountconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `DoraPerformanceScoreCountEdge`
+
+The edge type for [`DoraPerformanceScoreCount`](#doraperformancescorecount).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="doraperformancescorecountedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="doraperformancescorecountedgenode"></a>`node` | [`DoraPerformanceScoreCount`](#doraperformancescorecount) | The item at the end of the edge. |
+
 #### `EgressNodeConnection`
 
 The connection type for [`EgressNode`](#egressnode).
@@ -8908,6 +9324,52 @@ The edge type for [`ExternalStatusCheck`](#externalstatuscheck).
 | <a id="externalstatuscheckedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="externalstatuscheckedgenode"></a>`node` | [`ExternalStatusCheck`](#externalstatuscheck) | The item at the end of the edge. |
 
+#### `ForecastDatapointConnection`
+
+The connection type for [`ForecastDatapoint`](#forecastdatapoint).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="forecastdatapointconnectionedges"></a>`edges` | [`[ForecastDatapointEdge]`](#forecastdatapointedge) | A list of edges. |
+| <a id="forecastdatapointconnectionnodes"></a>`nodes` | [`[ForecastDatapoint]`](#forecastdatapoint) | A list of nodes. |
+| <a id="forecastdatapointconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `ForecastDatapointEdge`
+
+The edge type for [`ForecastDatapoint`](#forecastdatapoint).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="forecastdatapointedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="forecastdatapointedgenode"></a>`node` | [`ForecastDatapoint`](#forecastdatapoint) | The item at the end of the edge. |
+
+#### `GoogleCloudLoggingConfigurationTypeConnection`
+
+The connection type for [`GoogleCloudLoggingConfigurationType`](#googlecloudloggingconfigurationtype).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="googlecloudloggingconfigurationtypeconnectionedges"></a>`edges` | [`[GoogleCloudLoggingConfigurationTypeEdge]`](#googlecloudloggingconfigurationtypeedge) | A list of edges. |
+| <a id="googlecloudloggingconfigurationtypeconnectionnodes"></a>`nodes` | [`[GoogleCloudLoggingConfigurationType]`](#googlecloudloggingconfigurationtype) | A list of nodes. |
+| <a id="googlecloudloggingconfigurationtypeconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `GoogleCloudLoggingConfigurationTypeEdge`
+
+The edge type for [`GoogleCloudLoggingConfigurationType`](#googlecloudloggingconfigurationtype).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="googlecloudloggingconfigurationtypeedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="googlecloudloggingconfigurationtypeedgenode"></a>`node` | [`GoogleCloudLoggingConfigurationType`](#googlecloudloggingconfigurationtype) | The item at the end of the edge. |
+
 #### `GroupConnection`
 
 The connection type for [`Group`](#group).
@@ -9431,6 +9893,29 @@ The connection type for [`MergeRequest`](#mergerequest).
 | <a id="mergerequestconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
 | <a id="mergerequestconnectiontotaltimetomerge"></a>`totalTimeToMerge` | [`Float`](#float) | Total sum of time to merge, in seconds, for the collection of merge requests. |
 
+#### `MergeRequestDiffLlmSummaryConnection`
+
+The connection type for [`MergeRequestDiffLlmSummary`](#mergerequestdiffllmsummary).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mergerequestdiffllmsummaryconnectionedges"></a>`edges` | [`[MergeRequestDiffLlmSummaryEdge]`](#mergerequestdiffllmsummaryedge) | A list of edges. |
+| <a id="mergerequestdiffllmsummaryconnectionnodes"></a>`nodes` | [`[MergeRequestDiffLlmSummary]`](#mergerequestdiffllmsummary) | A list of nodes. |
+| <a id="mergerequestdiffllmsummaryconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `MergeRequestDiffLlmSummaryEdge`
+
+The edge type for [`MergeRequestDiffLlmSummary`](#mergerequestdiffllmsummary).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mergerequestdiffllmsummaryedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="mergerequestdiffllmsummaryedgenode"></a>`node` | [`MergeRequestDiffLlmSummary`](#mergerequestdiffllmsummary) | The item at the end of the edge. |
+
 #### `MergeRequestDiffRegistryConnection`
 
 The connection type for [`MergeRequestDiffRegistry`](#mergerequestdiffregistry).
@@ -10044,6 +10529,29 @@ The edge type for [`ProductAnalyticsDashboardPanel`](#productanalyticsdashboardp
 | <a id="productanalyticsdashboardpaneledgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="productanalyticsdashboardpaneledgenode"></a>`node` | [`ProductAnalyticsDashboardPanel`](#productanalyticsdashboardpanel) | The item at the end of the edge. |
 
+#### `ProductAnalyticsDashboardVisualizationConnection`
+
+The connection type for [`ProductAnalyticsDashboardVisualization`](#productanalyticsdashboardvisualization).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="productanalyticsdashboardvisualizationconnectionedges"></a>`edges` | [`[ProductAnalyticsDashboardVisualizationEdge]`](#productanalyticsdashboardvisualizationedge) | A list of edges. |
+| <a id="productanalyticsdashboardvisualizationconnectionnodes"></a>`nodes` | [`[ProductAnalyticsDashboardVisualization]`](#productanalyticsdashboardvisualization) | A list of nodes. |
+| <a id="productanalyticsdashboardvisualizationconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `ProductAnalyticsDashboardVisualizationEdge`
+
+The edge type for [`ProductAnalyticsDashboardVisualization`](#productanalyticsdashboardvisualization).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="productanalyticsdashboardvisualizationedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="productanalyticsdashboardvisualizationedgenode"></a>`node` | [`ProductAnalyticsDashboardVisualization`](#productanalyticsdashboardvisualization) | The item at the end of the edge. |
+
 #### `ProjectConnection`
 
 The connection type for [`Project`](#project).
@@ -11502,6 +12010,19 @@ Information about a connected Agent.
 | <a id="agentmetadatapodnamespace"></a>`podNamespace` | [`String`](#string) | Namespace of the pod running the Agent. |
 | <a id="agentmetadataversion"></a>`version` | [`String`](#string) | Agent version tag. |
 
+### `AiCachedMessageType`
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="aicachedmessagetypecontent"></a>`content` | [`String`](#string) | Content of the message. Can be null for failed responses. |
+| <a id="aicachedmessagetypeerrors"></a>`errors` | [`[String!]!`](#string) | Errors that occurred while asynchronously fetching an AI (assistant) response. |
+| <a id="aicachedmessagetypeid"></a>`id` | [`ID`](#id) | UUID of the message. |
+| <a id="aicachedmessagetyperequestid"></a>`requestId` | [`ID`](#id) | UUID of the original request message. |
+| <a id="aicachedmessagetyperole"></a>`role` | [`AiCachedMessageRole!`](#aicachedmessagerole) | Message role. |
+| <a id="aicachedmessagetypetimestamp"></a>`timestamp` | [`Time!`](#time) | Message timestamp. |
+
 ### `AiMessageType`
 
 #### Fields
@@ -11732,6 +12253,23 @@ Represents a vulnerability asset type.
 | <a id="assettypetype"></a>`type` | [`String!`](#string) | Type of the asset. |
 | <a id="assettypeurl"></a>`url` | [`String!`](#string) | URL of the asset. |
 
+### `AuditEventDefinition`
+
+Represents the YAML definitions for audit events defined in `ee/config/audit_events/types/<event-type-name>.yml` and `config/audit_events/types/<event-type-name>.yml`.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="auditeventdefinitiondescription"></a>`description` | [`String!`](#string) | Description of what action the audit event tracks. |
+| <a id="auditeventdefinitionfeaturecategory"></a>`featureCategory` | [`String!`](#string) | Feature category associated with the event. |
+| <a id="auditeventdefinitionintroducedbyissue"></a>`introducedByIssue` | [`String`](#string) | Link to the issue introducing the event. For olderaudit events, it can be a commit URL rather than amerge request URL. |
+| <a id="auditeventdefinitionintroducedbymr"></a>`introducedByMr` | [`String`](#string) | Link to the merge request introducing the event. Forolder audit events, it can be a commit URL rather thana merge request URL. |
+| <a id="auditeventdefinitionmilestone"></a>`milestone` | [`String!`](#string) | Milestone the event was introduced in. |
+| <a id="auditeventdefinitionname"></a>`name` | [`String!`](#string) | Key name of the audit event. |
+| <a id="auditeventdefinitionsavedtodatabase"></a>`savedToDatabase` | [`Boolean!`](#boolean) | Indicates if the event is saved to PostgreSQL database. |
+| <a id="auditeventdefinitionstreamed"></a>`streamed` | [`Boolean!`](#boolean) | Indicates if the event is streamed to an external destination. |
+
 ### `AuditEventStreamingHeader`
 
 Represents a HTTP header key/value that belongs to an audit streaming destination.
@@ -11744,6 +12282,18 @@ Represents a HTTP header key/value that belongs to an audit streaming destinatio
 | <a id="auditeventstreamingheaderkey"></a>`key` | [`String!`](#string) | Key of the header. |
 | <a id="auditeventstreamingheadervalue"></a>`value` | [`String!`](#string) | Value of the header. |
 
+### `AuditEventsStreamingInstanceHeader`
+
+Represents a HTTP header key/value that belongs to an instance level audit streaming destination.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="auditeventsstreaminginstanceheaderid"></a>`id` | [`ID!`](#id) | ID of the header. |
+| <a id="auditeventsstreaminginstanceheaderkey"></a>`key` | [`String!`](#string) | Key of the header. |
+| <a id="auditeventsstreaminginstanceheadervalue"></a>`value` | [`String!`](#string) | Value of the header. |
+
 ### `AwardEmoji`
 
 An emoji awarded by a user.
@@ -12159,9 +12709,38 @@ Represents the total number of issues and their weights for a particular day.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="cicatalogresourcedescription"></a>`description` **{warning-solid}** | [`String`](#string) | **Introduced** in 15.11. This feature is an Experiment. It can be changed or removed at any time. Description of the catalog resource. |
+| <a id="cicatalogresourceforkscount"></a>`forksCount` **{warning-solid}** | [`Int!`](#int) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Number of times the catalog resource has been forked. |
 | <a id="cicatalogresourceicon"></a>`icon` **{warning-solid}** | [`String`](#string) | **Introduced** in 15.11. This feature is an Experiment. It can be changed or removed at any time. Icon for the catalog resource. |
 | <a id="cicatalogresourceid"></a>`id` **{warning-solid}** | [`ID!`](#id) | **Introduced** in 15.11. This feature is an Experiment. It can be changed or removed at any time. ID of the catalog resource. |
+| <a id="cicatalogresourcelatestversion"></a>`latestVersion` **{warning-solid}** | [`Release`](#release) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Latest version of the catalog resource. |
 | <a id="cicatalogresourcename"></a>`name` **{warning-solid}** | [`String`](#string) | **Introduced** in 15.11. This feature is an Experiment. It can be changed or removed at any time. Name of the catalog resource. |
+| <a id="cicatalogresourcereadmehtml"></a>`readmeHtml` **{warning-solid}** | [`String!`](#string) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. GitLab Flavored Markdown rendering of `readme`. |
+| <a id="cicatalogresourcerootnamespace"></a>`rootNamespace` **{warning-solid}** | [`Namespace`](#namespace) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Root namespace of the catalog resource. |
+| <a id="cicatalogresourcestarcount"></a>`starCount` **{warning-solid}** | [`Int!`](#int) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Number of times the catalog resource has been starred. |
+| <a id="cicatalogresourcewebpath"></a>`webPath` **{warning-solid}** | [`String`](#string) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Web path of the catalog resource. |
+
+#### Fields with arguments
+
+##### `CiCatalogResource.versions`
+
+Versions of the catalog resource.
+
+WARNING:
+**Deprecated** in 16.1.
+Causes performance degradation.
+Use: `latest_version`.
+
+Returns [`ReleaseConnection`](#releaseconnection).
+
+This field returns a [connection](#connections). It accepts the
+four standard [pagination arguments](#connection-pagination-arguments):
+`before: String`, `after: String`, `first: Int`, `last: Int`.
+
+###### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="cicatalogresourceversionssort"></a>`sort` | [`ReleaseSort`](#releasesort) | Sort releases by given criteria. |
 
 ### `CiConfig`
 
@@ -12285,6 +12864,16 @@ Represents a deployment freeze window of a project.
 | <a id="cigroupname"></a>`name` | [`String`](#string) | Name of the job group. |
 | <a id="cigroupsize"></a>`size` | [`Int`](#int) | Size of the group. |
 
+### `CiGroupEnvironmentScope`
+
+Ci/CD environment scope for a group.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="cigroupenvironmentscopename"></a>`name` | [`String`](#string) | Scope name defininig the enviromnments that can use the variable. |
+
 ### `CiGroupVariable`
 
 CI/CD variables for a group.
@@ -12326,6 +12915,7 @@ CI/CD variables for a GitLab instance.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="cijobactive"></a>`active` | [`Boolean!`](#boolean) | Indicates the job is active. |
+| <a id="cijobaifailureanalysis"></a>`aiFailureAnalysis` **{warning-solid}** | [`String`](#string) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Ai generated analysis of the root cause of failure. |
 | <a id="cijoballowfailure"></a>`allowFailure` | [`Boolean!`](#boolean) | Whether the job is allowed to fail. |
 | <a id="cijobartifacts"></a>`artifacts` | [`CiJobArtifactConnection`](#cijobartifactconnection) | Artifacts generated by the job. (see [Connections](#connections)) |
 | <a id="cijobbrowseartifactspath"></a>`browseArtifactsPath` | [`String`](#string) | URL for browsing the artifact's archive. |
@@ -12385,7 +12975,7 @@ CI/CD variables for a GitLab instance.
 | <a id="cijobartifactfiletype"></a>`fileType` | [`JobArtifactFileType`](#jobartifactfiletype) | File type of the artifact. |
 | <a id="cijobartifactid"></a>`id` | [`CiJobArtifactID!`](#cijobartifactid) | ID of the artifact. |
 | <a id="cijobartifactname"></a>`name` | [`String`](#string) | File name of the artifact. |
-| <a id="cijobartifactsize"></a>`size` | [`Int!`](#int) | Size of the artifact in bytes. |
+| <a id="cijobartifactsize"></a>`size` | [`BigInt!`](#bigint) | Size of the artifact in bytes. |
 
 ### `CiJobTokenScopeType`
 
@@ -12450,10 +13040,10 @@ CI/CD variables given to a manual job.
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="ciminutesnamespacemonthlyusageminutes"></a>`minutes` | [`Int`](#int) | Total number of minutes used by all projects in the namespace. |
+| <a id="ciminutesnamespacemonthlyusageminutes"></a>`minutes` | [`Int`](#int) | Total number of units of compute used by all projects in the namespace. |
 | <a id="ciminutesnamespacemonthlyusagemonth"></a>`month` | [`String`](#string) | Month related to the usage data. |
 | <a id="ciminutesnamespacemonthlyusagemonthiso8601"></a>`monthIso8601` | [`ISO8601Date`](#iso8601date) | Month related to the usage data in ISO 8601 date format. |
-| <a id="ciminutesnamespacemonthlyusageprojects"></a>`projects` | [`CiMinutesProjectMonthlyUsageConnection`](#ciminutesprojectmonthlyusageconnection) | CI/CD minutes usage data for projects in the namespace. (see [Connections](#connections)) |
+| <a id="ciminutesnamespacemonthlyusageprojects"></a>`projects` | [`CiMinutesProjectMonthlyUsageConnection`](#ciminutesprojectmonthlyusageconnection) | Compute usage data for projects in the namespace. (see [Connections](#connections)) |
 | <a id="ciminutesnamespacemonthlyusagesharedrunnersduration"></a>`sharedRunnersDuration` | [`Int`](#int) | Total duration (in seconds) of shared runners use by the namespace for the month. |
 
 ### `CiMinutesProjectMonthlyUsage`
@@ -12462,7 +13052,7 @@ CI/CD variables given to a manual job.
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="ciminutesprojectmonthlyusageminutes"></a>`minutes` | [`Int`](#int) | Number of CI/CD minutes used by the project in the month. |
+| <a id="ciminutesprojectmonthlyusageminutes"></a>`minutes` | [`Int`](#int) | Number of units of compute used by the project in the month. |
 | <a id="ciminutesprojectmonthlyusagename"></a>`name` **{warning-solid}** | [`String`](#string) | **Deprecated** in 15.6. Use `project.name`. |
 | <a id="ciminutesprojectmonthlyusageproject"></a>`project` | [`Project`](#project) | Project having the recorded usage. |
 | <a id="ciminutesprojectmonthlyusagesharedrunnersduration"></a>`sharedRunnersDuration` | [`Int`](#int) | Total duration (in seconds) of shared runners use by the project for the month. |
@@ -12515,9 +13105,9 @@ CI/CD variables for a project.
 | <a id="cirunnerownerproject"></a>`ownerProject` | [`Project`](#project) | Project that owns the runner. For project runners only. |
 | <a id="cirunnerpaused"></a>`paused` | [`Boolean!`](#boolean) | Indicates the runner is paused and not available to run jobs. |
 | <a id="cirunnerplatformname"></a>`platformName` | [`String`](#string) | Platform provided by the runner. |
-| <a id="cirunnerprivateprojectsminutescostfactor"></a>`privateProjectsMinutesCostFactor` | [`Float`](#float) | Private projects' "minutes cost factor" associated with the runner (GitLab.com only). |
+| <a id="cirunnerprivateprojectsminutescostfactor"></a>`privateProjectsMinutesCostFactor` | [`Float`](#float) | Private projects' "compute cost factor" associated with the runner (GitLab.com only). |
 | <a id="cirunnerprojectcount"></a>`projectCount` | [`Int`](#int) | Number of projects that the runner is associated with. |
-| <a id="cirunnerpublicprojectsminutescostfactor"></a>`publicProjectsMinutesCostFactor` | [`Float`](#float) | Public projects' "minutes cost factor" associated with the runner (GitLab.com only). |
+| <a id="cirunnerpublicprojectsminutescostfactor"></a>`publicProjectsMinutesCostFactor` | [`Float`](#float) | Public projects' "compute cost factor" associated with the runner (GitLab.com only). |
 | <a id="cirunnerregisteradminurl"></a>`registerAdminUrl` | [`String`](#string) | URL of the temporary registration page of the runner. Only available before the runner is registered. Only available for administrators. |
 | <a id="cirunnerrevision"></a>`revision` | [`String`](#string) | Revision of the runner. |
 | <a id="cirunnerrununtagged"></a>`runUntagged` | [`Boolean!`](#boolean) | Indicates the runner is able to run untagged jobs. |
@@ -12596,6 +13186,7 @@ Returns [`CiRunnerStatus!`](#cirunnerstatus).
 | <a id="cirunnermanagerrunner"></a>`runner` | [`CiRunner`](#cirunner) | Runner configuration for the runner manager. |
 | <a id="cirunnermanagerstatus"></a>`status` | [`CiRunnerStatus!`](#cirunnerstatus) | Status of the runner manager. |
 | <a id="cirunnermanagersystemid"></a>`systemId` | [`String!`](#string) | System ID associated with the runner manager. |
+| <a id="cirunnermanagerupgradestatus"></a>`upgradeStatus` **{warning-solid}** | [`CiRunnerUpgradeStatus`](#cirunnerupgradestatus) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Availability of upgrades for the runner manager. |
 | <a id="cirunnermanagerversion"></a>`version` | [`String`](#string) | Version of the runner. |
 
 ### `CiSecureFileRegistry`
@@ -12874,6 +13465,35 @@ Returns [`CommitParentNames`](#commitparentnames).
 | ---- | ---- | ----------- |
 | <a id="commitreferencestippingtagslimit"></a>`limit` | [`Int!`](#int) | Number of ref names to return. |
 
+### `ComparedSecurityReport`
+
+Represents compared security report.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="comparedsecurityreportadded"></a>`added` **{warning-solid}** | [`[ComparedSecurityReportFinding!]`](#comparedsecurityreportfinding) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. New vulnerability findings. |
+| <a id="comparedsecurityreportbasereportcreatedat"></a>`baseReportCreatedAt` | [`Time`](#time) | Time of the base report creation. |
+| <a id="comparedsecurityreportbasereportoutofdate"></a>`baseReportOutOfDate` | [`Boolean`](#boolean) | Indicates whether the base report out of date. |
+| <a id="comparedsecurityreportfixed"></a>`fixed` **{warning-solid}** | [`[ComparedSecurityReportFinding!]`](#comparedsecurityreportfinding) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Fixed vulnerability findings. |
+| <a id="comparedsecurityreportheadreportcreatedat"></a>`headReportCreatedAt` | [`Time`](#time) | Time of the base report creation. |
+
+### `ComparedSecurityReportFinding`
+
+Represents finding.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="comparedsecurityreportfindingdescription"></a>`description` | [`String`](#string) | Description of the vulnerability finding. |
+| <a id="comparedsecurityreportfindingfoundbypipelineiid"></a>`foundByPipelineIid` | [`String`](#string) | IID of the pipeline. |
+| <a id="comparedsecurityreportfindingseverity"></a>`severity` | [`VulnerabilitySeverity`](#vulnerabilityseverity) | Severity of the vulnerability finding. |
+| <a id="comparedsecurityreportfindingstate"></a>`state` | [`VulnerabilityState`](#vulnerabilitystate) | Finding status. |
+| <a id="comparedsecurityreportfindingtitle"></a>`title` | [`String`](#string) | Title of the vulnerability finding. |
+| <a id="comparedsecurityreportfindinguuid"></a>`uuid` | [`String`](#string) | UUIDv5 digest based on the vulnerability's report type, primary identifier, location, fingerprint, project identifier. |
+
 ### `ComplianceFramework`
 
 Represents a ComplianceFramework associated with a Project.
@@ -13777,6 +14397,25 @@ Returns [`DesignVersion`](#designversion).
 | ---- | ---- | ----------- |
 | <a id="designmanagementversionid"></a>`id` | [`DesignManagementVersionID!`](#designmanagementversionid) | Global ID of the version. |
 
+### `DesignManagementRepositoryRegistry`
+
+Represents the Geo replication and verification state of a Design Management Repository.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="designmanagementrepositoryregistrycreatedat"></a>`createdAt` | [`Time`](#time) | Timestamp when the DesignManagementRepositoryRegistry was created. |
+| <a id="designmanagementrepositoryregistrydesignmanagementrepositoryid"></a>`designManagementRepositoryId` | [`ID!`](#id) | ID of the Design Management Repository. |
+| <a id="designmanagementrepositoryregistryid"></a>`id` | [`ID!`](#id) | ID of the DesignManagementRepositoryRegistry. |
+| <a id="designmanagementrepositoryregistrylastsyncfailure"></a>`lastSyncFailure` | [`String`](#string) | Error message during sync of the DesignManagementRepositoryRegistry. |
+| <a id="designmanagementrepositoryregistrylastsyncedat"></a>`lastSyncedAt` | [`Time`](#time) | Timestamp of the most recent successful sync of the DesignManagementRepositoryRegistry. |
+| <a id="designmanagementrepositoryregistryretryat"></a>`retryAt` | [`Time`](#time) | Timestamp after which the DesignManagementRepositoryRegistry is resynced. |
+| <a id="designmanagementrepositoryregistryretrycount"></a>`retryCount` | [`Int`](#int) | Number of consecutive failed sync attempts of the DesignManagementRepositoryRegistry. |
+| <a id="designmanagementrepositoryregistrystate"></a>`state` | [`RegistryState`](#registrystate) | Sync state of the DesignManagementRepositoryRegistry. |
+| <a id="designmanagementrepositoryregistryverificationretryat"></a>`verificationRetryAt` | [`Time`](#time) | Timestamp after which the DesignManagementRepositoryRegistry is reverified. |
+| <a id="designmanagementrepositoryregistryverifiedat"></a>`verifiedAt` | [`Time`](#time) | Timestamp of the most recent successful verification of the DesignManagementRepositoryRegistry. |
+
 ### `DesignVersion`
 
 A specific version in which designs were added, modified or deleted.
@@ -14002,6 +14641,20 @@ Returns [`[DoraMetric!]`](#dorametric).
 | <a id="dorametrictimetorestoreservice"></a>`timeToRestoreService` | [`Float`](#float) | Median time to close an incident. |
 | <a id="dorametricvalue"></a>`value` **{warning-solid}** | [`Float`](#float) | **Deprecated** in 15.10. Moved to corresponding metric field. |
 
+### `DoraPerformanceScoreCount`
+
+Aggregated DORA score counts for projects for the last complete month.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="doraperformancescorecounthighprojectscount"></a>`highProjectsCount` | [`Int`](#int) | Number of projects that score "high" on the metric. |
+| <a id="doraperformancescorecountlowprojectscount"></a>`lowProjectsCount` | [`Int`](#int) | Number of projects that score "low" on the metric. |
+| <a id="doraperformancescorecountmediumprojectscount"></a>`mediumProjectsCount` | [`Int`](#int) | Number of projects that score "medium" on the metric. |
+| <a id="doraperformancescorecountmetricname"></a>`metricName` | [`String!`](#string) | Name of the DORA metric. |
+| <a id="doraperformancescorecountnodataprojectscount"></a>`noDataProjectsCount` | [`Int`](#int) | Number of projects with no data. |
+
 ### `EgressNode`
 
 #### Fields
@@ -14037,6 +14690,7 @@ Describes where code is deployed for a project.
 | ---- | ---- | ----------- |
 | <a id="environmentautodeleteat"></a>`autoDeleteAt` | [`Time`](#time) | When the environment is going to be deleted automatically. |
 | <a id="environmentautostopat"></a>`autoStopAt` | [`Time`](#time) | When the environment is going to be stopped automatically. |
+| <a id="environmentclusteragent"></a>`clusterAgent` | [`ClusterAgent`](#clusteragent) | Cluster agent of the environment. |
 | <a id="environmentcreatedat"></a>`createdAt` | [`Time`](#time) | When the environment was created. |
 | <a id="environmentdeployfreezes"></a>`deployFreezes` | [`[CiFreezePeriod!]`](#cifreezeperiod) | Deployment freeze periods of the environment. |
 | <a id="environmentenvironmenttype"></a>`environmentType` | [`String`](#string) | Folder name of the environment. |
@@ -14650,6 +15304,40 @@ Describes an external status check.
 | <a id="fileuploadpath"></a>`path` | [`String!`](#string) | Path of the upload. |
 | <a id="fileuploadsize"></a>`size` | [`Int!`](#int) | Size of the upload in bytes. |
 
+### `FindingReportsComparer`
+
+Represents security reports comparison for vulnerability findings.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="findingreportscomparerreport"></a>`report` **{warning-solid}** | [`ComparedSecurityReport`](#comparedsecurityreport) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Compared security report. |
+| <a id="findingreportscomparerstatus"></a>`status` | [`FindingReportsComparerStatus`](#findingreportscomparerstatus) | Comparison status. |
+| <a id="findingreportscomparerstatusreason"></a>`statusReason` | [`String`](#string) | Text explaining the status. |
+
+### `Forecast`
+
+Information about specific forecast created.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="forecaststatus"></a>`status` | [`ForecastStatus!`](#forecaststatus) | Status of the forecast. |
+| <a id="forecastvalues"></a>`values` | [`ForecastDatapointConnection`](#forecastdatapointconnection) | Actual forecast values. (see [Connections](#connections)) |
+
+### `ForecastDatapoint`
+
+Information about specific forecast datapoint.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="forecastdatapointdatapoint"></a>`datapoint` | [`String!`](#string) | Datapoint of the forecast. Usually a date. |
+| <a id="forecastdatapointvalue"></a>`value` | [`Float`](#float) | Value of the given datapoint. |
+
 ### `ForkDetails`
 
 Details of the fork project compared to its upstream project.
@@ -14767,6 +15455,29 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="geonodedependencyproxymanifestregistriesreplicationstate"></a>`replicationState` | [`ReplicationStateEnum`](#replicationstateenum) | Filters registries by their replication state. |
 | <a id="geonodedependencyproxymanifestregistriesverificationstate"></a>`verificationState` | [`VerificationStateEnum`](#verificationstateenum) | Filters registries by their verification state. |
 
+##### `GeoNode.designManagementRepositoryRegistries`
+
+Find Design Repository registries on this Geo node. Ignored if `geo_design_management_repository_replication` feature flag is disabled.
+
+WARNING:
+**Introduced** in 16.1.
+This feature is an Experiment. It can be changed or removed at any time.
+
+Returns [`DesignManagementRepositoryRegistryConnection`](#designmanagementrepositoryregistryconnection).
+
+This field returns a [connection](#connections). It accepts the
+four standard [pagination arguments](#connection-pagination-arguments):
+`before: String`, `after: String`, `first: Int`, `last: Int`.
+
+###### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="geonodedesignmanagementrepositoryregistriesids"></a>`ids` | [`[ID!]`](#id) | Filters registries by their ID. |
+| <a id="geonodedesignmanagementrepositoryregistrieskeyword"></a>`keyword` | [`String`](#string) | Filters registries by their attributes using a keyword. |
+| <a id="geonodedesignmanagementrepositoryregistriesreplicationstate"></a>`replicationState` | [`ReplicationStateEnum`](#replicationstateenum) | Filters registries by their replication state. |
+| <a id="geonodedesignmanagementrepositoryregistriesverificationstate"></a>`verificationState` | [`VerificationStateEnum`](#verificationstateenum) | Filters registries by their verification state. |
+
 ##### `GeoNode.groupWikiRepositoryRegistries`
 
 Find group wiki repository registries on this Geo node.
@@ -14976,6 +15687,21 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="geonodeuploadregistriesreplicationstate"></a>`replicationState` | [`ReplicationStateEnum`](#replicationstateenum) | Filters registries by their replication state. |
 | <a id="geonodeuploadregistriesverificationstate"></a>`verificationState` | [`VerificationStateEnum`](#verificationstateenum) | Filters registries by their verification state. |
 
+### `GoogleCloudLoggingConfigurationType`
+
+Stores Google Cloud Logging configurations associated with IAM service accounts,used for generating access tokens.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="googlecloudloggingconfigurationtypeclientemail"></a>`clientEmail` | [`String!`](#string) | Client email. |
+| <a id="googlecloudloggingconfigurationtypegoogleprojectidname"></a>`googleProjectIdName` | [`String!`](#string) | Google project ID. |
+| <a id="googlecloudloggingconfigurationtypegroup"></a>`group` | [`Group!`](#group) | Group the configuration belongs to. |
+| <a id="googlecloudloggingconfigurationtypeid"></a>`id` | [`ID!`](#id) | ID of the configuration. |
+| <a id="googlecloudloggingconfigurationtypelogidname"></a>`logIdName` | [`String!`](#string) | Log ID. |
+| <a id="googlecloudloggingconfigurationtypeprivatekey"></a>`privateKey` | [`String!`](#string) | Private key. |
+
 ### `GpgSignature`
 
 GPG signature for a signed commit.
@@ -15027,10 +15753,12 @@ GPG signature for a signed commit.
 | <a id="groupdependencyproxymanifests"></a>`dependencyProxyManifests` | [`DependencyProxyManifestConnection`](#dependencyproxymanifestconnection) | Dependency Proxy manifests. (see [Connections](#connections)) |
 | <a id="groupdependencyproxysetting"></a>`dependencyProxySetting` | [`DependencyProxySetting`](#dependencyproxysetting) | Dependency Proxy settings for the group. |
 | <a id="groupdependencyproxytotalsize"></a>`dependencyProxyTotalSize` | [`String!`](#string) | Total size of the dependency proxy cached images. |
-| <a id="groupdependencyproxytotalsizeinbytes"></a>`dependencyProxyTotalSizeInBytes` | [`Int!`](#int) | Total size of the dependency proxy cached images in bytes. |
+| <a id="groupdependencyproxytotalsizebytes"></a>`dependencyProxyTotalSizeBytes` | [`BigInt!`](#bigint) | Total size of the dependency proxy cached images in bytes, encoded as a string. |
+| <a id="groupdependencyproxytotalsizeinbytes"></a>`dependencyProxyTotalSizeInBytes` **{warning-solid}** | [`Int!`](#int) | **Deprecated** in 16.1. Use `dependencyProxyTotalSizeBytes`. |
 | <a id="groupdescription"></a>`description` | [`String`](#string) | Description of the namespace. |
 | <a id="groupdescriptionhtml"></a>`descriptionHtml` | [`String`](#string) | GitLab Flavored Markdown rendering of `description`. |
 | <a id="groupdora"></a>`dora` | [`Dora`](#dora) | Group's DORA metrics. |
+| <a id="groupdoraperformancescorecounts"></a>`doraPerformanceScoreCounts` | [`DoraPerformanceScoreCountConnection`](#doraperformancescorecountconnection) | Group's DORA scores for all projects by DORA key metric for the last complete month. (see [Connections](#connections)) |
 | <a id="groupemailsdisabled"></a>`emailsDisabled` | [`Boolean`](#boolean) | Indicates if a group has email notifications disabled. |
 | <a id="groupenforcefreeusercap"></a>`enforceFreeUserCap` | [`Boolean`](#boolean) | Indicates whether the group has limited users for a free plan. |
 | <a id="groupepicboards"></a>`epicBoards` | [`EpicBoardConnection`](#epicboardconnection) | Find epic boards. (see [Connections](#connections)) |
@@ -15039,6 +15767,7 @@ GPG signature for a signed commit.
 | <a id="groupflowmetrics"></a>`flowMetrics` **{warning-solid}** | [`GroupValueStreamAnalyticsFlowMetrics`](#groupvaluestreamanalyticsflowmetrics) | **Introduced** in 15.10. This feature is an Experiment. It can be changed or removed at any time. Flow metrics for value stream analytics. |
 | <a id="groupfullname"></a>`fullName` | [`String!`](#string) | Full name of the namespace. |
 | <a id="groupfullpath"></a>`fullPath` | [`ID!`](#id) | Full path of the namespace. |
+| <a id="groupgooglecloudloggingconfigurations"></a>`googleCloudLoggingConfigurations` | [`GoogleCloudLoggingConfigurationTypeConnection`](#googlecloudloggingconfigurationtypeconnection) | Google Cloud logging configurations that receive audit events belonging to the group. (see [Connections](#connections)) |
 | <a id="groupid"></a>`id` | [`ID!`](#id) | ID of the namespace. |
 | <a id="groupistemporarystorageincreaseenabled"></a>`isTemporaryStorageIncreaseEnabled` | [`Boolean!`](#boolean) | Status of the temporary storage increase. |
 | <a id="grouplfsenabled"></a>`lfsEnabled` | [`Boolean`](#boolean) | Indicates if Large File Storage (LFS) is enabled for namespace. |
@@ -15292,6 +16021,23 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="groupdescendantgroupsowned"></a>`owned` | [`Boolean`](#boolean) | Limit result to groups owned by authenticated user. |
 | <a id="groupdescendantgroupssearch"></a>`search` | [`String`](#string) | Search query for group name or group full path. |
 
+##### `Group.environmentScopes`
+
+Environment scopes of the group.
+
+Returns [`CiGroupEnvironmentScopeConnection`](#cigroupenvironmentscopeconnection).
+
+This field returns a [connection](#connections). It accepts the
+four standard [pagination arguments](#connection-pagination-arguments):
+`before: String`, `after: String`, `first: Int`, `last: Int`.
+
+###### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="groupenvironmentscopesname"></a>`name` | [`String`](#string) | Name of the environment scope. |
+| <a id="groupenvironmentscopessearch"></a>`search` | [`String`](#string) | Search query for environment scope name. |
+
 ##### `Group.epic`
 
 Find a single epic.
@@ -15682,6 +16428,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="groupprojectshasvulnerabilities"></a>`hasVulnerabilities` | [`Boolean`](#boolean) | Returns only the projects which have vulnerabilities. |
 | <a id="groupprojectsids"></a>`ids` | [`[ID!]`](#id) | Filter projects by IDs. |
 | <a id="groupprojectsincludesubgroups"></a>`includeSubgroups` | [`Boolean`](#boolean) | Include also subgroup projects. |
+| <a id="groupprojectsnotaimedfordeletion"></a>`notAimedForDeletion` | [`Boolean`](#boolean) | Include projects that are not aimed for deletion. |
 | <a id="groupprojectssearch"></a>`search` | [`String`](#string) | Search project with most similar names or paths. |
 | <a id="groupprojectssort"></a>`sort` | [`NamespaceProjectSort`](#namespaceprojectsort) | Sort projects by this criteria. |
 | <a id="groupprojectswithissuesenabled"></a>`withIssuesEnabled` | [`Boolean`](#boolean) | Return only projects with issues enabled. |
@@ -16187,6 +16934,7 @@ Represents an external resource to send instance audit events to.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="instanceexternalauditeventdestinationdestinationurl"></a>`destinationUrl` | [`String!`](#string) | External destination to send audit events to. |
+| <a id="instanceexternalauditeventdestinationheaders"></a>`headers` | [`AuditEventsStreamingInstanceHeaderConnection!`](#auditeventsstreaminginstanceheaderconnection) | List of additional HTTP headers sent with each event. (see [Connections](#connections)) |
 | <a id="instanceexternalauditeventdestinationid"></a>`id` | [`ID!`](#id) | ID of the destination. |
 | <a id="instanceexternalauditeventdestinationverificationtoken"></a>`verificationToken` | [`String!`](#string) | Verification token to validate source of event. |
 
@@ -16749,6 +17497,7 @@ Defines which user roles, users, or groups can merge into a protected branch.
 | <a id="mergerequestdescriptionhtml"></a>`descriptionHtml` | [`String`](#string) | GitLab Flavored Markdown rendering of `description`. |
 | <a id="mergerequestdetailedmergestatus"></a>`detailedMergeStatus` | [`DetailedMergeStatus`](#detailedmergestatus) | Detailed merge status of the merge request. |
 | <a id="mergerequestdiffheadsha"></a>`diffHeadSha` | [`String`](#string) | Diff head SHA of the merge request. |
+| <a id="mergerequestdiffllmsummaries"></a>`diffLlmSummaries` **{warning-solid}** | [`MergeRequestDiffLlmSummaryConnection`](#mergerequestdiffllmsummaryconnection) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Diff summaries generated by AI. |
 | <a id="mergerequestdiffrefs"></a>`diffRefs` | [`DiffRefs`](#diffrefs) | References of the base SHA, the head SHA, and the start SHA for this merge request. |
 | <a id="mergerequestdiffstatssummary"></a>`diffStatsSummary` | [`DiffStatsSummary`](#diffstatssummary) | Summary of which files were changed in this merge request. |
 | <a id="mergerequestdiscussionlocked"></a>`discussionLocked` | [`Boolean!`](#boolean) | Indicates if comments on the merge request are locked to members only. |
@@ -16847,6 +17596,22 @@ Returns [`[DiffStats!]`](#diffstats).
 | ---- | ---- | ----------- |
 | <a id="mergerequestdiffstatspath"></a>`path` | [`String`](#string) | Specific file path. |
 
+##### `MergeRequest.findingReportsComparer`
+
+Vulnerability finding reports comparison reported on the merge request.
+
+WARNING:
+**Introduced** in 16.1.
+This feature is an Experiment. It can be changed or removed at any time.
+
+Returns [`FindingReportsComparer`](#findingreportscomparer).
+
+###### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mergerequestfindingreportscomparerreporttype"></a>`reportType` | [`ComparableSecurityReportType!`](#comparablesecurityreporttype) | Filter vulnerability findings by report type. |
+
 ##### `MergeRequest.pipelines`
 
 Pipelines for the merge request. Note: for performance reasons, no more than the most recent 500 pipelines will be returned.
@@ -16904,20 +17669,26 @@ A user assigned to a merge request.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="mergerequestassigneeavatarurl"></a>`avatarUrl` | [`String`](#string) | URL of the user's avatar. |
+| <a id="mergerequestassigneebio"></a>`bio` | [`String`](#string) | Bio of the user. |
 | <a id="mergerequestassigneebot"></a>`bot` | [`Boolean!`](#boolean) | Indicates if the user is a bot. |
 | <a id="mergerequestassigneecallouts"></a>`callouts` | [`UserCalloutConnection`](#usercalloutconnection) | User callouts that belong to the user. (see [Connections](#connections)) |
 | <a id="mergerequestassigneecommitemail"></a>`commitEmail` | [`String`](#string) | User's default commit email. |
+| <a id="mergerequestassigneecreatedat"></a>`createdAt` | [`Time`](#time) | Timestamp of when the user was created. |
+| <a id="mergerequestassigneediscord"></a>`discord` | [`String`](#string) | Discord ID of the user. |
 | <a id="mergerequestassigneeemail"></a>`email` **{warning-solid}** | [`String`](#string) | **Deprecated** in 13.7. This was renamed. Use: [`User.publicEmail`](#userpublicemail). |
 | <a id="mergerequestassigneeemails"></a>`emails` | [`EmailConnection`](#emailconnection) | User's email addresses. (see [Connections](#connections)) |
 | <a id="mergerequestassigneegitpodenabled"></a>`gitpodEnabled` | [`Boolean`](#boolean) | Whether Gitpod is enabled at the user level. |
 | <a id="mergerequestassigneegroupcount"></a>`groupCount` | [`Int`](#int) | Group count for the user. |
 | <a id="mergerequestassigneegroupmemberships"></a>`groupMemberships` | [`GroupMemberConnection`](#groupmemberconnection) | Group memberships of the user. (see [Connections](#connections)) |
 | <a id="mergerequestassigneeid"></a>`id` | [`ID!`](#id) | ID of the user. |
+| <a id="mergerequestassigneejobtitle"></a>`jobTitle` | [`String`](#string) | Job title of the user. |
+| <a id="mergerequestassigneelinkedin"></a>`linkedin` | [`String`](#string) | LinkedIn profile name of the user. |
 | <a id="mergerequestassigneelocation"></a>`location` | [`String`](#string) | Location of the user. |
 | <a id="mergerequestassigneemergerequestinteraction"></a>`mergeRequestInteraction` | [`UserMergeRequestInteraction`](#usermergerequestinteraction) | Details of this user's interactions with the merge request. |
 | <a id="mergerequestassigneename"></a>`name` | [`String!`](#string) | Human-readable name of the user. Returns `****` if the user is a project bot and the requester does not have permission to view the project. |
 | <a id="mergerequestassigneenamespace"></a>`namespace` | [`Namespace`](#namespace) | Personal namespace of the user. |
 | <a id="mergerequestassigneenamespacecommitemails"></a>`namespaceCommitEmails` | [`NamespaceCommitEmailConnection`](#namespacecommitemailconnection) | User's custom namespace commit emails. (see [Connections](#connections)) |
+| <a id="mergerequestassigneeorganization"></a>`organization` | [`String`](#string) | Who the user represents or works for. |
 | <a id="mergerequestassigneepreferencesgitpodpath"></a>`preferencesGitpodPath` | [`String`](#string) | Web path to the Gitpod section within user preferences. |
 | <a id="mergerequestassigneeprofileenablegitpodpath"></a>`profileEnableGitpodPath` | [`String`](#string) | Web path to enable Gitpod for the user. |
 | <a id="mergerequestassigneeprojectmemberships"></a>`projectMemberships` | [`ProjectMemberConnection`](#projectmemberconnection) | Project memberships of the user. (see [Connections](#connections)) |
@@ -16925,6 +17696,7 @@ A user assigned to a merge request.
 | <a id="mergerequestassigneesavedreplies"></a>`savedReplies` | [`SavedReplyConnection`](#savedreplyconnection) | Saved replies authored by the user. Will not return saved replies if `saved_replies` feature flag is disabled. (see [Connections](#connections)) |
 | <a id="mergerequestassigneestate"></a>`state` | [`UserState!`](#userstate) | State of the user. |
 | <a id="mergerequestassigneestatus"></a>`status` | [`UserStatus`](#userstatus) | User status. |
+| <a id="mergerequestassigneetwitter"></a>`twitter` | [`String`](#string) | Twitter username of the user. |
 | <a id="mergerequestassigneeuserachievements"></a>`userAchievements` **{warning-solid}** | [`UserAchievementConnection`](#userachievementconnection) | **Introduced** in 15.10. This feature is an Experiment. It can be changed or removed at any time. Achievements for the user. Only returns for namespaces where the `achievements` feature flag is enabled. |
 | <a id="mergerequestassigneeuserpermissions"></a>`userPermissions` | [`UserPermissions!`](#userpermissions) | Permissions for the current user on the resource. |
 | <a id="mergerequestassigneeusername"></a>`username` | [`String!`](#string) | Username of the user. Unique within this instance of GitLab. |
@@ -17170,20 +17942,26 @@ The author of the merge request.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="mergerequestauthoravatarurl"></a>`avatarUrl` | [`String`](#string) | URL of the user's avatar. |
+| <a id="mergerequestauthorbio"></a>`bio` | [`String`](#string) | Bio of the user. |
 | <a id="mergerequestauthorbot"></a>`bot` | [`Boolean!`](#boolean) | Indicates if the user is a bot. |
 | <a id="mergerequestauthorcallouts"></a>`callouts` | [`UserCalloutConnection`](#usercalloutconnection) | User callouts that belong to the user. (see [Connections](#connections)) |
 | <a id="mergerequestauthorcommitemail"></a>`commitEmail` | [`String`](#string) | User's default commit email. |
+| <a id="mergerequestauthorcreatedat"></a>`createdAt` | [`Time`](#time) | Timestamp of when the user was created. |
+| <a id="mergerequestauthordiscord"></a>`discord` | [`String`](#string) | Discord ID of the user. |
 | <a id="mergerequestauthoremail"></a>`email` **{warning-solid}** | [`String`](#string) | **Deprecated** in 13.7. This was renamed. Use: [`User.publicEmail`](#userpublicemail). |
 | <a id="mergerequestauthoremails"></a>`emails` | [`EmailConnection`](#emailconnection) | User's email addresses. (see [Connections](#connections)) |
 | <a id="mergerequestauthorgitpodenabled"></a>`gitpodEnabled` | [`Boolean`](#boolean) | Whether Gitpod is enabled at the user level. |
 | <a id="mergerequestauthorgroupcount"></a>`groupCount` | [`Int`](#int) | Group count for the user. |
 | <a id="mergerequestauthorgroupmemberships"></a>`groupMemberships` | [`GroupMemberConnection`](#groupmemberconnection) | Group memberships of the user. (see [Connections](#connections)) |
 | <a id="mergerequestauthorid"></a>`id` | [`ID!`](#id) | ID of the user. |
+| <a id="mergerequestauthorjobtitle"></a>`jobTitle` | [`String`](#string) | Job title of the user. |
+| <a id="mergerequestauthorlinkedin"></a>`linkedin` | [`String`](#string) | LinkedIn profile name of the user. |
 | <a id="mergerequestauthorlocation"></a>`location` | [`String`](#string) | Location of the user. |
 | <a id="mergerequestauthormergerequestinteraction"></a>`mergeRequestInteraction` | [`UserMergeRequestInteraction`](#usermergerequestinteraction) | Details of this user's interactions with the merge request. |
 | <a id="mergerequestauthorname"></a>`name` | [`String!`](#string) | Human-readable name of the user. Returns `****` if the user is a project bot and the requester does not have permission to view the project. |
 | <a id="mergerequestauthornamespace"></a>`namespace` | [`Namespace`](#namespace) | Personal namespace of the user. |
 | <a id="mergerequestauthornamespacecommitemails"></a>`namespaceCommitEmails` | [`NamespaceCommitEmailConnection`](#namespacecommitemailconnection) | User's custom namespace commit emails. (see [Connections](#connections)) |
+| <a id="mergerequestauthororganization"></a>`organization` | [`String`](#string) | Who the user represents or works for. |
 | <a id="mergerequestauthorpreferencesgitpodpath"></a>`preferencesGitpodPath` | [`String`](#string) | Web path to the Gitpod section within user preferences. |
 | <a id="mergerequestauthorprofileenablegitpodpath"></a>`profileEnableGitpodPath` | [`String`](#string) | Web path to enable Gitpod for the user. |
 | <a id="mergerequestauthorprojectmemberships"></a>`projectMemberships` | [`ProjectMemberConnection`](#projectmemberconnection) | Project memberships of the user. (see [Connections](#connections)) |
@@ -17191,6 +17969,7 @@ The author of the merge request.
 | <a id="mergerequestauthorsavedreplies"></a>`savedReplies` | [`SavedReplyConnection`](#savedreplyconnection) | Saved replies authored by the user. Will not return saved replies if `saved_replies` feature flag is disabled. (see [Connections](#connections)) |
 | <a id="mergerequestauthorstate"></a>`state` | [`UserState!`](#userstate) | State of the user. |
 | <a id="mergerequestauthorstatus"></a>`status` | [`UserStatus`](#userstatus) | User status. |
+| <a id="mergerequestauthortwitter"></a>`twitter` | [`String`](#string) | Twitter username of the user. |
 | <a id="mergerequestauthoruserachievements"></a>`userAchievements` **{warning-solid}** | [`UserAchievementConnection`](#userachievementconnection) | **Introduced** in 15.10. This feature is an Experiment. It can be changed or removed at any time. Achievements for the user. Only returns for namespaces where the `achievements` feature flag is enabled. |
 | <a id="mergerequestauthoruserpermissions"></a>`userPermissions` | [`UserPermissions!`](#userpermissions) | Permissions for the current user on the resource. |
 | <a id="mergerequestauthorusername"></a>`username` | [`String!`](#string) | Username of the user. Unique within this instance of GitLab. |
@@ -17427,6 +18206,21 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | ---- | ---- | ----------- |
 | <a id="mergerequestauthorworkspacesids"></a>`ids` | [`[RemoteDevelopmentWorkspaceID!]`](#remotedevelopmentworkspaceid) | Array of global workspace IDs. For example, `["gid://gitlab/RemoteDevelopment::Workspace/1"]`. |
 
+### `MergeRequestDiffLlmSummary`
+
+A diff summary generated by AI.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mergerequestdiffllmsummarycontent"></a>`content` | [`String!`](#string) | Content of the diff summary. |
+| <a id="mergerequestdiffllmsummarycreatedat"></a>`createdAt` | [`Time!`](#time) | Timestamp of when the diff summary was created. |
+| <a id="mergerequestdiffllmsummarymergerequestdiffid"></a>`mergeRequestDiffId` | [`ID!`](#id) | ID of the Merge Request diff associated with the diff summary. |
+| <a id="mergerequestdiffllmsummaryprovider"></a>`provider` | [`String!`](#string) | AI provider that generated the summary. |
+| <a id="mergerequestdiffllmsummaryupdatedat"></a>`updatedAt` | [`Time!`](#time) | Timestamp of when the diff summary was updated. |
+| <a id="mergerequestdiffllmsummaryuser"></a>`user` | [`UserCore`](#usercore) | User associated with the diff summary. |
+
 ### `MergeRequestDiffRegistry`
 
 Represents the Geo sync and verification state of a Merge Request diff.
@@ -17455,20 +18249,26 @@ A user participating in a merge request.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="mergerequestparticipantavatarurl"></a>`avatarUrl` | [`String`](#string) | URL of the user's avatar. |
+| <a id="mergerequestparticipantbio"></a>`bio` | [`String`](#string) | Bio of the user. |
 | <a id="mergerequestparticipantbot"></a>`bot` | [`Boolean!`](#boolean) | Indicates if the user is a bot. |
 | <a id="mergerequestparticipantcallouts"></a>`callouts` | [`UserCalloutConnection`](#usercalloutconnection) | User callouts that belong to the user. (see [Connections](#connections)) |
 | <a id="mergerequestparticipantcommitemail"></a>`commitEmail` | [`String`](#string) | User's default commit email. |
+| <a id="mergerequestparticipantcreatedat"></a>`createdAt` | [`Time`](#time) | Timestamp of when the user was created. |
+| <a id="mergerequestparticipantdiscord"></a>`discord` | [`String`](#string) | Discord ID of the user. |
 | <a id="mergerequestparticipantemail"></a>`email` **{warning-solid}** | [`String`](#string) | **Deprecated** in 13.7. This was renamed. Use: [`User.publicEmail`](#userpublicemail). |
 | <a id="mergerequestparticipantemails"></a>`emails` | [`EmailConnection`](#emailconnection) | User's email addresses. (see [Connections](#connections)) |
 | <a id="mergerequestparticipantgitpodenabled"></a>`gitpodEnabled` | [`Boolean`](#boolean) | Whether Gitpod is enabled at the user level. |
 | <a id="mergerequestparticipantgroupcount"></a>`groupCount` | [`Int`](#int) | Group count for the user. |
 | <a id="mergerequestparticipantgroupmemberships"></a>`groupMemberships` | [`GroupMemberConnection`](#groupmemberconnection) | Group memberships of the user. (see [Connections](#connections)) |
 | <a id="mergerequestparticipantid"></a>`id` | [`ID!`](#id) | ID of the user. |
+| <a id="mergerequestparticipantjobtitle"></a>`jobTitle` | [`String`](#string) | Job title of the user. |
+| <a id="mergerequestparticipantlinkedin"></a>`linkedin` | [`String`](#string) | LinkedIn profile name of the user. |
 | <a id="mergerequestparticipantlocation"></a>`location` | [`String`](#string) | Location of the user. |
 | <a id="mergerequestparticipantmergerequestinteraction"></a>`mergeRequestInteraction` | [`UserMergeRequestInteraction`](#usermergerequestinteraction) | Details of this user's interactions with the merge request. |
 | <a id="mergerequestparticipantname"></a>`name` | [`String!`](#string) | Human-readable name of the user. Returns `****` if the user is a project bot and the requester does not have permission to view the project. |
 | <a id="mergerequestparticipantnamespace"></a>`namespace` | [`Namespace`](#namespace) | Personal namespace of the user. |
 | <a id="mergerequestparticipantnamespacecommitemails"></a>`namespaceCommitEmails` | [`NamespaceCommitEmailConnection`](#namespacecommitemailconnection) | User's custom namespace commit emails. (see [Connections](#connections)) |
+| <a id="mergerequestparticipantorganization"></a>`organization` | [`String`](#string) | Who the user represents or works for. |
 | <a id="mergerequestparticipantpreferencesgitpodpath"></a>`preferencesGitpodPath` | [`String`](#string) | Web path to the Gitpod section within user preferences. |
 | <a id="mergerequestparticipantprofileenablegitpodpath"></a>`profileEnableGitpodPath` | [`String`](#string) | Web path to enable Gitpod for the user. |
 | <a id="mergerequestparticipantprojectmemberships"></a>`projectMemberships` | [`ProjectMemberConnection`](#projectmemberconnection) | Project memberships of the user. (see [Connections](#connections)) |
@@ -17476,6 +18276,7 @@ A user participating in a merge request.
 | <a id="mergerequestparticipantsavedreplies"></a>`savedReplies` | [`SavedReplyConnection`](#savedreplyconnection) | Saved replies authored by the user. Will not return saved replies if `saved_replies` feature flag is disabled. (see [Connections](#connections)) |
 | <a id="mergerequestparticipantstate"></a>`state` | [`UserState!`](#userstate) | State of the user. |
 | <a id="mergerequestparticipantstatus"></a>`status` | [`UserStatus`](#userstatus) | User status. |
+| <a id="mergerequestparticipanttwitter"></a>`twitter` | [`String`](#string) | Twitter username of the user. |
 | <a id="mergerequestparticipantuserachievements"></a>`userAchievements` **{warning-solid}** | [`UserAchievementConnection`](#userachievementconnection) | **Introduced** in 15.10. This feature is an Experiment. It can be changed or removed at any time. Achievements for the user. Only returns for namespaces where the `achievements` feature flag is enabled. |
 | <a id="mergerequestparticipantuserpermissions"></a>`userPermissions` | [`UserPermissions!`](#userpermissions) | Permissions for the current user on the resource. |
 | <a id="mergerequestparticipantusername"></a>`username` | [`String!`](#string) | Username of the user. Unique within this instance of GitLab. |
@@ -17740,20 +18541,26 @@ A user assigned to a merge request as a reviewer.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="mergerequestrevieweravatarurl"></a>`avatarUrl` | [`String`](#string) | URL of the user's avatar. |
+| <a id="mergerequestreviewerbio"></a>`bio` | [`String`](#string) | Bio of the user. |
 | <a id="mergerequestreviewerbot"></a>`bot` | [`Boolean!`](#boolean) | Indicates if the user is a bot. |
 | <a id="mergerequestreviewercallouts"></a>`callouts` | [`UserCalloutConnection`](#usercalloutconnection) | User callouts that belong to the user. (see [Connections](#connections)) |
 | <a id="mergerequestreviewercommitemail"></a>`commitEmail` | [`String`](#string) | User's default commit email. |
+| <a id="mergerequestreviewercreatedat"></a>`createdAt` | [`Time`](#time) | Timestamp of when the user was created. |
+| <a id="mergerequestreviewerdiscord"></a>`discord` | [`String`](#string) | Discord ID of the user. |
 | <a id="mergerequestrevieweremail"></a>`email` **{warning-solid}** | [`String`](#string) | **Deprecated** in 13.7. This was renamed. Use: [`User.publicEmail`](#userpublicemail). |
 | <a id="mergerequestrevieweremails"></a>`emails` | [`EmailConnection`](#emailconnection) | User's email addresses. (see [Connections](#connections)) |
 | <a id="mergerequestreviewergitpodenabled"></a>`gitpodEnabled` | [`Boolean`](#boolean) | Whether Gitpod is enabled at the user level. |
 | <a id="mergerequestreviewergroupcount"></a>`groupCount` | [`Int`](#int) | Group count for the user. |
 | <a id="mergerequestreviewergroupmemberships"></a>`groupMemberships` | [`GroupMemberConnection`](#groupmemberconnection) | Group memberships of the user. (see [Connections](#connections)) |
 | <a id="mergerequestreviewerid"></a>`id` | [`ID!`](#id) | ID of the user. |
+| <a id="mergerequestreviewerjobtitle"></a>`jobTitle` | [`String`](#string) | Job title of the user. |
+| <a id="mergerequestreviewerlinkedin"></a>`linkedin` | [`String`](#string) | LinkedIn profile name of the user. |
 | <a id="mergerequestreviewerlocation"></a>`location` | [`String`](#string) | Location of the user. |
 | <a id="mergerequestreviewermergerequestinteraction"></a>`mergeRequestInteraction` | [`UserMergeRequestInteraction`](#usermergerequestinteraction) | Details of this user's interactions with the merge request. |
 | <a id="mergerequestreviewername"></a>`name` | [`String!`](#string) | Human-readable name of the user. Returns `****` if the user is a project bot and the requester does not have permission to view the project. |
 | <a id="mergerequestreviewernamespace"></a>`namespace` | [`Namespace`](#namespace) | Personal namespace of the user. |
 | <a id="mergerequestreviewernamespacecommitemails"></a>`namespaceCommitEmails` | [`NamespaceCommitEmailConnection`](#namespacecommitemailconnection) | User's custom namespace commit emails. (see [Connections](#connections)) |
+| <a id="mergerequestreviewerorganization"></a>`organization` | [`String`](#string) | Who the user represents or works for. |
 | <a id="mergerequestreviewerpreferencesgitpodpath"></a>`preferencesGitpodPath` | [`String`](#string) | Web path to the Gitpod section within user preferences. |
 | <a id="mergerequestreviewerprofileenablegitpodpath"></a>`profileEnableGitpodPath` | [`String`](#string) | Web path to enable Gitpod for the user. |
 | <a id="mergerequestreviewerprojectmemberships"></a>`projectMemberships` | [`ProjectMemberConnection`](#projectmemberconnection) | Project memberships of the user. (see [Connections](#connections)) |
@@ -17761,6 +18568,7 @@ A user assigned to a merge request as a reviewer.
 | <a id="mergerequestreviewersavedreplies"></a>`savedReplies` | [`SavedReplyConnection`](#savedreplyconnection) | Saved replies authored by the user. Will not return saved replies if `saved_replies` feature flag is disabled. (see [Connections](#connections)) |
 | <a id="mergerequestreviewerstate"></a>`state` | [`UserState!`](#userstate) | State of the user. |
 | <a id="mergerequestreviewerstatus"></a>`status` | [`UserStatus`](#userstatus) | User status. |
+| <a id="mergerequestreviewertwitter"></a>`twitter` | [`String`](#string) | Twitter username of the user. |
 | <a id="mergerequestrevieweruserachievements"></a>`userAchievements` **{warning-solid}** | [`UserAchievementConnection`](#userachievementconnection) | **Introduced** in 15.10. This feature is an Experiment. It can be changed or removed at any time. Achievements for the user. Only returns for namespaces where the `achievements` feature flag is enabled. |
 | <a id="mergerequestrevieweruserpermissions"></a>`userPermissions` | [`UserPermissions!`](#userpermissions) | Permissions for the current user on the resource. |
 | <a id="mergerequestreviewerusername"></a>`username` | [`String!`](#string) | Username of the user. Unique within this instance of GitLab. |
@@ -18200,6 +19008,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="namespaceprojectshasvulnerabilities"></a>`hasVulnerabilities` | [`Boolean`](#boolean) | Returns only the projects which have vulnerabilities. |
 | <a id="namespaceprojectsids"></a>`ids` | [`[ID!]`](#id) | Filter projects by IDs. |
 | <a id="namespaceprojectsincludesubgroups"></a>`includeSubgroups` | [`Boolean`](#boolean) | Include also subgroup projects. |
+| <a id="namespaceprojectsnotaimedfordeletion"></a>`notAimedForDeletion` | [`Boolean`](#boolean) | Include projects that are not aimed for deletion. |
 | <a id="namespaceprojectssearch"></a>`search` | [`String`](#string) | Search project with most similar names or paths. |
 | <a id="namespaceprojectssort"></a>`sort` | [`NamespaceProjectSort`](#namespaceprojectsort) | Sort projects by this criteria. |
 | <a id="namespaceprojectswithissuesenabled"></a>`withIssuesEnabled` | [`Boolean`](#boolean) | Return only projects with issues enabled. |
@@ -18305,6 +19114,8 @@ Represents the network policy.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="noteauthor"></a>`author` | [`UserCore!`](#usercore) | User who wrote this note. |
+| <a id="noteauthoriscontributor"></a>`authorIsContributor` | [`Boolean`](#boolean) | Indicates whether the note author is a contributor. |
+| <a id="noteawardemoji"></a>`awardEmoji` | [`AwardEmojiConnection`](#awardemojiconnection) | List of award emojis associated with the note. (see [Connections](#connections)) |
 | <a id="notebody"></a>`body` | [`String!`](#string) | Content of the note. |
 | <a id="notebodyhtml"></a>`bodyHtml` | [`String`](#string) | GitLab Flavored Markdown rendering of `note`. |
 | <a id="noteconfidential"></a>`confidential` **{warning-solid}** | [`Boolean`](#boolean) | **Deprecated** in 15.5. This was renamed. Use: `internal`. |
@@ -18314,6 +19125,7 @@ Represents the network policy.
 | <a id="noteinternal"></a>`internal` | [`Boolean`](#boolean) | Indicates if this note is internal. |
 | <a id="notelasteditedat"></a>`lastEditedAt` | [`Time`](#time) | Timestamp when note was last edited. |
 | <a id="notelasteditedby"></a>`lastEditedBy` | [`UserCore`](#usercore) | User who last edited the note. |
+| <a id="notemaxaccesslevelofauthor"></a>`maxAccessLevelOfAuthor` | [`String`](#string) | Max access level of the note author in the project. |
 | <a id="noteposition"></a>`position` | [`DiffPosition`](#diffposition) | Position of this note on a diff. |
 | <a id="noteproject"></a>`project` | [`Project`](#project) | Project associated with the note. |
 | <a id="noteresolvable"></a>`resolvable` | [`Boolean!`](#boolean) | Indicates if the object can be resolved. |
@@ -18989,7 +19801,7 @@ Represents vulnerability finding of a security report on the pipeline.
 | <a id="pipelinesecurityreportfindinglocation"></a>`location` | [`VulnerabilityLocation`](#vulnerabilitylocation) | Location metadata for the vulnerability. Its fields depend on the type of security scan that found the vulnerability. |
 | <a id="pipelinesecurityreportfindingmergerequest"></a>`mergeRequest` | [`MergeRequest`](#mergerequest) | Merge request that fixes the vulnerability. |
 | <a id="pipelinesecurityreportfindingproject"></a>`project` | [`Project`](#project) | Project on which the vulnerability finding was found. |
-| <a id="pipelinesecurityreportfindingprojectfingerprint"></a>`projectFingerprint` **{warning-solid}** | [`String`](#string) | **Introduced** in 16.0. This feature is an Experiment. It can be changed or removed at any time. Fingerprint of the vulnerability finding. |
+| <a id="pipelinesecurityreportfindingprojectfingerprint"></a>`projectFingerprint` **{warning-solid}** | [`String`](#string) | **Deprecated** in 16.1. Use uuid instead. |
 | <a id="pipelinesecurityreportfindingremediations"></a>`remediations` | [`[VulnerabilityRemediationType!]`](#vulnerabilityremediationtype) | Remediations of the security report finding. |
 | <a id="pipelinesecurityreportfindingreporttype"></a>`reportType` | [`VulnerabilityReportType`](#vulnerabilityreporttype) | Type of the security report that found the vulnerability finding. |
 | <a id="pipelinesecurityreportfindingscanner"></a>`scanner` | [`VulnerabilityScanner`](#vulnerabilityscanner) | Scanner metadata for the vulnerability. |
@@ -19023,6 +19835,7 @@ Represents a product analytics dashboard.
 | <a id="productanalyticsdashboardpanels"></a>`panels` | [`ProductAnalyticsDashboardPanelConnection!`](#productanalyticsdashboardpanelconnection) | Panels shown on the dashboard. (see [Connections](#connections)) |
 | <a id="productanalyticsdashboardslug"></a>`slug` | [`String!`](#string) | Slug of the dashboard. |
 | <a id="productanalyticsdashboardtitle"></a>`title` | [`String!`](#string) | Title of the dashboard. |
+| <a id="productanalyticsdashboarduserdefined"></a>`userDefined` | [`Boolean!`](#boolean) | Indicates whether the dashboard is user-defined or provided by GitLab. |
 
 ### `ProductAnalyticsDashboardPanel`
 
@@ -19046,6 +19859,7 @@ Represents a product analytics dashboard visualization.
 | ---- | ---- | ----------- |
 | <a id="productanalyticsdashboardvisualizationdata"></a>`data` | [`JSON!`](#json) | Data of the visualization. |
 | <a id="productanalyticsdashboardvisualizationoptions"></a>`options` | [`JSON!`](#json) | Options of the visualization. |
+| <a id="productanalyticsdashboardvisualizationslug"></a>`slug` | [`String!`](#string) | Slug of the visualization. |
 | <a id="productanalyticsdashboardvisualizationtype"></a>`type` | [`String!`](#string) | Type of the visualization. |
 
 ### `Project`
@@ -19474,6 +20288,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
+| <a id="projectdependenciescomponentnames"></a>`componentNames` | [`[String!]`](#string) | Filter dependencies by component names. |
 | <a id="projectdependenciespackagemanagers"></a>`packageManagers` | [`[PackageManager!]`](#packagemanager) | Filter dependencies by package managers. |
 | <a id="projectdependenciessort"></a>`sort` | [`DependencySort`](#dependencysort) | Sort dependencies by given criteria. |
 
@@ -20102,6 +20917,26 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | ---- | ---- | ----------- |
 | <a id="projectproductanalyticsdashboardsslug"></a>`slug` | [`String`](#string) | Find by dashboard slug. |
 
+##### `Project.productAnalyticsVisualizations`
+
+Visualizations of the project or associated configuration project.
+
+WARNING:
+**Introduced** in 16.1.
+This feature is an Experiment. It can be changed or removed at any time.
+
+Returns [`ProductAnalyticsDashboardVisualizationConnection`](#productanalyticsdashboardvisualizationconnection).
+
+This field returns a [connection](#connections). It accepts the
+four standard [pagination arguments](#connection-pagination-arguments):
+`before: String`, `after: String`, `first: Int`, `last: Int`.
+
+###### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="projectproductanalyticsvisualizationsslug"></a>`slug` | [`String`](#string) | Slug of the visualization to return. |
+
 ##### `Project.projectMembers`
 
 Members of the project.
@@ -21003,6 +21838,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | ---- | ---- | ----------- |
 | <a id="repositoryblobspaths"></a>`paths` | [`[String!]!`](#string) | Array of desired blob paths. |
 | <a id="repositoryblobsref"></a>`ref` | [`String`](#string) | Commit ref to get the blobs from. Default value is HEAD. |
+| <a id="repositoryblobsreftype"></a>`refType` | [`RefType`](#reftype) | Type of ref. |
 
 ##### `Repository.branchNames`
 
@@ -21047,6 +21883,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="repositorypaginatedtreepath"></a>`path` | [`String`](#string) | Path to get the tree for. Default value is the root of the repository. |
 | <a id="repositorypaginatedtreerecursive"></a>`recursive` | [`Boolean`](#boolean) | Used to get a recursive tree. Default is false. |
 | <a id="repositorypaginatedtreeref"></a>`ref` | [`String`](#string) | Commit ref to get the tree for. Default value is HEAD. |
+| <a id="repositorypaginatedtreereftype"></a>`refType` | [`RefType`](#reftype) | Type of ref. |
 
 ##### `Repository.tree`
 
@@ -21061,6 +21898,7 @@ Returns [`Tree`](#tree).
 | <a id="repositorytreepath"></a>`path` | [`String`](#string) | Path to get the tree for. Default value is the root of the repository. |
 | <a id="repositorytreerecursive"></a>`recursive` | [`Boolean`](#boolean) | Used to get a recursive tree. Default is false. |
 | <a id="repositorytreeref"></a>`ref` | [`String`](#string) | Commit ref to get the tree for. Default value is HEAD. |
+| <a id="repositorytreereftype"></a>`refType` | [`RefType`](#reftype) | Type of ref. |
 
 ### `RepositoryBlob`
 
@@ -21365,6 +22203,19 @@ Represents a resource scanned by a security scan.
 | <a id="scannedresourcerequestmethod"></a>`requestMethod` | [`String`](#string) | HTTP request method used to access the URL. |
 | <a id="scannedresourceurl"></a>`url` | [`String`](#string) | URL scanned by the scanner. |
 
+### `SecurityPolicyValidationError`
+
+Security policy validation error.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="securitypolicyvalidationerrorfield"></a>`field` | [`String!`](#string) | Error field. |
+| <a id="securitypolicyvalidationerrorlevel"></a>`level` | [`String!`](#string) | Error level. |
+| <a id="securitypolicyvalidationerrormessage"></a>`message` | [`String!`](#string) | Error message. |
+| <a id="securitypolicyvalidationerrortitle"></a>`title` | [`String`](#string) | Error title. |
+
 ### `SecurityReportSummary`
 
 Represents summary of a security report.
@@ -22205,19 +23056,25 @@ Core represention of a GitLab user.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="usercoreavatarurl"></a>`avatarUrl` | [`String`](#string) | URL of the user's avatar. |
+| <a id="usercorebio"></a>`bio` | [`String`](#string) | Bio of the user. |
 | <a id="usercorebot"></a>`bot` | [`Boolean!`](#boolean) | Indicates if the user is a bot. |
 | <a id="usercorecallouts"></a>`callouts` | [`UserCalloutConnection`](#usercalloutconnection) | User callouts that belong to the user. (see [Connections](#connections)) |
 | <a id="usercorecommitemail"></a>`commitEmail` | [`String`](#string) | User's default commit email. |
+| <a id="usercorecreatedat"></a>`createdAt` | [`Time`](#time) | Timestamp of when the user was created. |
+| <a id="usercorediscord"></a>`discord` | [`String`](#string) | Discord ID of the user. |
 | <a id="usercoreemail"></a>`email` **{warning-solid}** | [`String`](#string) | **Deprecated** in 13.7. This was renamed. Use: [`User.publicEmail`](#userpublicemail). |
 | <a id="usercoreemails"></a>`emails` | [`EmailConnection`](#emailconnection) | User's email addresses. (see [Connections](#connections)) |
 | <a id="usercoregitpodenabled"></a>`gitpodEnabled` | [`Boolean`](#boolean) | Whether Gitpod is enabled at the user level. |
 | <a id="usercoregroupcount"></a>`groupCount` | [`Int`](#int) | Group count for the user. |
 | <a id="usercoregroupmemberships"></a>`groupMemberships` | [`GroupMemberConnection`](#groupmemberconnection) | Group memberships of the user. (see [Connections](#connections)) |
 | <a id="usercoreid"></a>`id` | [`ID!`](#id) | ID of the user. |
+| <a id="usercorejobtitle"></a>`jobTitle` | [`String`](#string) | Job title of the user. |
+| <a id="usercorelinkedin"></a>`linkedin` | [`String`](#string) | LinkedIn profile name of the user. |
 | <a id="usercorelocation"></a>`location` | [`String`](#string) | Location of the user. |
 | <a id="usercorename"></a>`name` | [`String!`](#string) | Human-readable name of the user. Returns `****` if the user is a project bot and the requester does not have permission to view the project. |
 | <a id="usercorenamespace"></a>`namespace` | [`Namespace`](#namespace) | Personal namespace of the user. |
 | <a id="usercorenamespacecommitemails"></a>`namespaceCommitEmails` | [`NamespaceCommitEmailConnection`](#namespacecommitemailconnection) | User's custom namespace commit emails. (see [Connections](#connections)) |
+| <a id="usercoreorganization"></a>`organization` | [`String`](#string) | Who the user represents or works for. |
 | <a id="usercorepreferencesgitpodpath"></a>`preferencesGitpodPath` | [`String`](#string) | Web path to the Gitpod section within user preferences. |
 | <a id="usercoreprofileenablegitpodpath"></a>`profileEnableGitpodPath` | [`String`](#string) | Web path to enable Gitpod for the user. |
 | <a id="usercoreprojectmemberships"></a>`projectMemberships` | [`ProjectMemberConnection`](#projectmemberconnection) | Project memberships of the user. (see [Connections](#connections)) |
@@ -22225,6 +23082,7 @@ Core represention of a GitLab user.
 | <a id="usercoresavedreplies"></a>`savedReplies` | [`SavedReplyConnection`](#savedreplyconnection) | Saved replies authored by the user. Will not return saved replies if `saved_replies` feature flag is disabled. (see [Connections](#connections)) |
 | <a id="usercorestate"></a>`state` | [`UserState!`](#userstate) | State of the user. |
 | <a id="usercorestatus"></a>`status` | [`UserStatus`](#userstatus) | User status. |
+| <a id="usercoretwitter"></a>`twitter` | [`String`](#string) | Twitter username of the user. |
 | <a id="usercoreuserachievements"></a>`userAchievements` **{warning-solid}** | [`UserAchievementConnection`](#userachievementconnection) | **Introduced** in 15.10. This feature is an Experiment. It can be changed or removed at any time. Achievements for the user. Only returns for namespaces where the `achievements` feature flag is enabled. |
 | <a id="usercoreuserpermissions"></a>`userPermissions` | [`UserPermissions!`](#userpermissions) | Permissions for the current user on the resource. |
 | <a id="usercoreusername"></a>`username` | [`String!`](#string) | Username of the user. Unique within this instance of GitLab. |
@@ -22573,7 +23431,7 @@ Represents a vulnerability.
 | <a id="vulnerabilitylinks"></a>`links` | [`[VulnerabilityLink!]!`](#vulnerabilitylink) | List of links associated with the vulnerability. |
 | <a id="vulnerabilitylocation"></a>`location` | [`VulnerabilityLocation`](#vulnerabilitylocation) | Location metadata for the vulnerability. Its fields depend on the type of security scan that found the vulnerability. |
 | <a id="vulnerabilitymergerequest"></a>`mergeRequest` | [`MergeRequest`](#mergerequest) | Merge request that fixes the vulnerability. |
-| <a id="vulnerabilitymessage"></a>`message` | [`String`](#string) | Short text description of the vulnerability. This may include the finding's specific information. |
+| <a id="vulnerabilitymessage"></a>`message` **{warning-solid}** | [`String`](#string) | **Deprecated** in 16.1. message field has been removed from security reports schema. |
 | <a id="vulnerabilitynotes"></a>`notes` | [`NoteConnection!`](#noteconnection) | All notes on this noteable. (see [Connections](#connections)) |
 | <a id="vulnerabilityprimaryidentifier"></a>`primaryIdentifier` | [`VulnerabilityIdentifier`](#vulnerabilityidentifier) | Primary identifier of the vulnerability. |
 | <a id="vulnerabilityproject"></a>`project` | [`Project`](#project) | Project on which the vulnerability was found. |
@@ -22755,6 +23613,32 @@ Represents the vulnerability details location within a file in the project.
 | <a id="vulnerabilitydetailmodulelocationname"></a>`name` | [`String`](#string) | Name of the field. |
 | <a id="vulnerabilitydetailmodulelocationoffset"></a>`offset` | [`Int!`](#int) | Offset of the module location. |
 
+### `VulnerabilityDetailNamedList`
+
+Represents the vulnerability details named list.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="vulnerabilitydetailnamedlistdescription"></a>`description` | [`String`](#string) | Description of the field. |
+| <a id="vulnerabilitydetailnamedlistfieldname"></a>`fieldName` | [`String`](#string) | Name of the field. |
+| <a id="vulnerabilitydetailnamedlistitems"></a>`items` **{warning-solid}** | [`[VulnerabilityDetailNamedListItem!]!`](#vulnerabilitydetailnamedlistitem) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Named list of details. |
+| <a id="vulnerabilitydetailnamedlistname"></a>`name` | [`String`](#string) | Name of the field. |
+
+### `VulnerabilityDetailNamedListItem`
+
+Represents the vulnerability details named list item.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="vulnerabilitydetailnamedlistitemdescription"></a>`description` | [`String`](#string) | Description of the field. |
+| <a id="vulnerabilitydetailnamedlistitemfieldname"></a>`fieldName` | [`String`](#string) | Name of the field. |
+| <a id="vulnerabilitydetailnamedlistitemname"></a>`name` | [`String`](#string) | Name of the field. |
+| <a id="vulnerabilitydetailnamedlistitemvalue"></a>`value` **{warning-solid}** | [`VulnerabilityDetail!`](#vulnerabilitydetail) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Value of the field. |
+
 ### `VulnerabilityDetailRow`
 
 Represents an individual row in a table.
@@ -23107,7 +23991,7 @@ Represents a state transition of a vulnerability.
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="vulnerabilitystatetransitiontypeauthor"></a>`author` | [`UserCore!`](#usercore) | User who changed the state of the vulnerability. |
+| <a id="vulnerabilitystatetransitiontypeauthor"></a>`author` | [`UserCore`](#usercore) | User who changed the state of the vulnerability. |
 | <a id="vulnerabilitystatetransitiontypecomment"></a>`comment` | [`String`](#string) | Comment for the state change. |
 | <a id="vulnerabilitystatetransitiontypecreatedat"></a>`createdAt` | [`Time!`](#time) | Time of the state change of the vulnerability. |
 | <a id="vulnerabilitystatetransitiontypedismissalreason"></a>`dismissalReason` | [`VulnerabilityDismissalReason`](#vulnerabilitydismissalreason) | Reason for the dismissal. |
@@ -23213,6 +24097,7 @@ Check permissions for the current user on a work item.
 | ---- | ---- | ----------- |
 | <a id="workitempermissionsadminparentlink"></a>`adminParentLink` | [`Boolean!`](#boolean) | Indicates the user can perform `admin_parent_link` on this resource. |
 | <a id="workitempermissionsadminworkitem"></a>`adminWorkItem` | [`Boolean!`](#boolean) | Indicates the user can perform `admin_work_item` on this resource. |
+| <a id="workitempermissionscreatenote"></a>`createNote` | [`Boolean!`](#boolean) | Indicates the user can perform `create_note` on this resource. |
 | <a id="workitempermissionsdeleteworkitem"></a>`deleteWorkItem` | [`Boolean!`](#boolean) | Indicates the user can perform `delete_work_item` on this resource. |
 | <a id="workitempermissionsreadworkitem"></a>`readWorkItem` | [`Boolean!`](#boolean) | Indicates the user can perform `read_work_item` on this resource. |
 | <a id="workitempermissionssetworkitemmetadata"></a>`setWorkItemMetadata` | [`Boolean!`](#boolean) | Indicates the user can perform `set_work_item_metadata` on this resource. |
@@ -23570,6 +24455,15 @@ Agent token statuses.
 | <a id="agenttokenstatusactive"></a>`ACTIVE` | Active agent token. |
 | <a id="agenttokenstatusrevoked"></a>`REVOKED` | Revoked agent token. |
 
+### `AiCachedMessageRole`
+
+Roles to filter in chat message.
+
+| Value | Description |
+| ----- | ----------- |
+| <a id="aicachedmessageroleassistant"></a>`ASSISTANT` | Filter only assistant messages. |
+| <a id="aicachedmessageroleuser"></a>`USER` | Filter only user messages. |
+
 ### `AlertManagementAlertSort`
 
 Values for sorting alerts.
@@ -23731,6 +24625,23 @@ Types of blob viewers.
 | <a id="blobviewerstyperich"></a>`rich` | Rich blob viewers type. |
 | <a id="blobviewerstypesimple"></a>`simple` | Simple blob viewers type. |
 
+### `CiCatalogResourceSort`
+
+Values for sorting catalog resources.
+
+| Value | Description |
+| ----- | ----------- |
+| <a id="cicatalogresourcesortcreated_asc"></a>`CREATED_ASC` | Created at ascending order. |
+| <a id="cicatalogresourcesortcreated_desc"></a>`CREATED_DESC` | Created at descending order. |
+| <a id="cicatalogresourcesortname_asc"></a>`NAME_ASC` | Name by ascending order. |
+| <a id="cicatalogresourcesortname_desc"></a>`NAME_DESC` | Name by descending order. |
+| <a id="cicatalogresourcesortupdated_asc"></a>`UPDATED_ASC` | Updated at ascending order. |
+| <a id="cicatalogresourcesortupdated_desc"></a>`UPDATED_DESC` | Updated at descending order. |
+| <a id="cicatalogresourcesortcreated_asc"></a>`created_asc` **{warning-solid}** | **Deprecated** in 13.5. This was renamed. Use: `CREATED_ASC`. |
+| <a id="cicatalogresourcesortcreated_desc"></a>`created_desc` **{warning-solid}** | **Deprecated** in 13.5. This was renamed. Use: `CREATED_DESC`. |
+| <a id="cicatalogresourcesortupdated_asc"></a>`updated_asc` **{warning-solid}** | **Deprecated** in 13.5. This was renamed. Use: `UPDATED_ASC`. |
+| <a id="cicatalogresourcesortupdated_desc"></a>`updated_desc` **{warning-solid}** | **Deprecated** in 13.5. This was renamed. Use: `UPDATED_DESC`. |
+
 ### `CiConfigIncludeType`
 
 Include type.
@@ -23904,6 +24815,20 @@ Mode of a commit action.
 | <a id="commitencodingbase64"></a>`BASE64` | Base64 encoding. |
 | <a id="commitencodingtext"></a>`TEXT` | Text encoding. |
 
+### `ComparableSecurityReportType`
+
+Comparable security report type.
+
+| Value | Description |
+| ----- | ----------- |
+| <a id="comparablesecurityreporttypeapi_fuzzing"></a>`API_FUZZING` | API Fuzzing report. |
+| <a id="comparablesecurityreporttypecontainer_scanning"></a>`CONTAINER_SCANNING` | Container Scanning report. |
+| <a id="comparablesecurityreporttypecoverage_fuzzing"></a>`COVERAGE_FUZZING` | Coverage Fuzzing report. |
+| <a id="comparablesecurityreporttypedast"></a>`DAST` | DAST report. |
+| <a id="comparablesecurityreporttypedependency_scanning"></a>`DEPENDENCY_SCANNING` | Dependency Scanning report. |
+| <a id="comparablesecurityreporttypesast"></a>`SAST` | SAST report. |
+| <a id="comparablesecurityreporttypesecret_detection"></a>`SECRET_DETECTION` | Secret Detection report. |
+
 ### `ComplianceFrameworkPresenceFilter`
 
 ComplianceFramework of a project for filtering.
@@ -24419,6 +25344,25 @@ Event action.
 | <a id="eventactionreopened"></a>`REOPENED` | Reopened action. |
 | <a id="eventactionupdated"></a>`UPDATED` | Updated action. |
 
+### `FindingReportsComparerStatus`
+
+Report comparison status.
+
+| Value | Description |
+| ----- | ----------- |
+| <a id="findingreportscomparerstatuserror"></a>`ERROR` | An error happened while generating the report. |
+| <a id="findingreportscomparerstatusparsed"></a>`PARSED` | Report was generated. |
+| <a id="findingreportscomparerstatusparsing"></a>`PARSING` | Report is being generated. |
+
+### `ForecastStatus`
+
+List of statuses for forecasting model.
+
+| Value | Description |
+| ----- | ----------- |
+| <a id="forecaststatusready"></a>`READY` | Forecast is ready. |
+| <a id="forecaststatusunavailable"></a>`UNAVAILABLE` | Forecast is unavailable. |
+
 ### `GeoRegistryAction`
 
 Action to trigger on one or more Geo registries.
@@ -24438,6 +25382,7 @@ Geo registry class.
 | <a id="georegistryclasscontainer_repository_registry"></a>`CONTAINER_REPOSITORY_REGISTRY` | Geo::ContainerRepositoryRegistry registry class. |
 | <a id="georegistryclassdependency_proxy_blob_registry"></a>`DEPENDENCY_PROXY_BLOB_REGISTRY` | Geo::DependencyProxyBlobRegistry registry class. |
 | <a id="georegistryclassdependency_proxy_manifest_registry"></a>`DEPENDENCY_PROXY_MANIFEST_REGISTRY` | Geo::DependencyProxyManifestRegistry registry class. |
+| <a id="georegistryclassdesign_management_repository_registry"></a>`DESIGN_MANAGEMENT_REPOSITORY_REGISTRY` | Geo::DesignManagementRepositoryRegistry registry class. |
 | <a id="georegistryclassjob_artifact_registry"></a>`JOB_ARTIFACT_REGISTRY` | Geo::JobArtifactRegistry registry class. |
 | <a id="georegistryclasslfs_object_registry"></a>`LFS_OBJECT_REGISTRY` | Geo::LfsObjectRegistry registry class. |
 | <a id="georegistryclassmerge_request_diff_registry"></a>`MERGE_REQUEST_DIFF_REGISTRY` | Geo::MergeRequestDiffRegistry registry class. |
@@ -25114,6 +26059,7 @@ Values for sorting package.
 | <a id="packagetypeenumgolang"></a>`GOLANG` | Packages from the Golang package manager. |
 | <a id="packagetypeenumhelm"></a>`HELM` | Packages from the Helm package manager. |
 | <a id="packagetypeenummaven"></a>`MAVEN` | Packages from the Maven package manager. |
+| <a id="packagetypeenumml_model"></a>`ML_MODEL` | Packages from the Ml_model package manager. |
 | <a id="packagetypeenumnpm"></a>`NPM` | Packages from the npm package manager. |
 | <a id="packagetypeenumnuget"></a>`NUGET` | Packages from the Nuget package manager. |
 | <a id="packagetypeenumpypi"></a>`PYPI` | Packages from the PyPI package manager. |
@@ -25213,6 +26159,15 @@ Project member relation.
 | <a id="projectmemberrelationinvited_groups"></a>`INVITED_GROUPS` | Invited Groups members. |
 | <a id="projectmemberrelationshared_into_ancestors"></a>`SHARED_INTO_ANCESTORS` | Shared Into Ancestors members. |
 
+### `RefType`
+
+Type of ref.
+
+| Value | Description |
+| ----- | ----------- |
+| <a id="reftypeheads"></a>`HEADS` | Ref type for branches. |
+| <a id="reftypetags"></a>`TAGS` | Ref type for tags. |
+
 ### `RegistryState`
 
 State of a Geo registry.
@@ -25378,6 +26333,7 @@ State of a Sentry error.
 | <a id="servicetypebugzilla_service"></a>`BUGZILLA_SERVICE` | BugzillaService type. |
 | <a id="servicetypebuildkite_service"></a>`BUILDKITE_SERVICE` | BuildkiteService type. |
 | <a id="servicetypecampfire_service"></a>`CAMPFIRE_SERVICE` | CampfireService type. |
+| <a id="servicetypeclickup_service"></a>`CLICKUP_SERVICE` | ClickupService type. |
 | <a id="servicetypeconfluence_service"></a>`CONFLUENCE_SERVICE` | ConfluenceService type. |
 | <a id="servicetypecustom_issue_tracker_service"></a>`CUSTOM_ISSUE_TRACKER_SERVICE` | CustomIssueTrackerService type. |
 | <a id="servicetypedatadog_service"></a>`DATADOG_SERVICE` | DatadogService type. |
@@ -25387,7 +26343,7 @@ State of a Sentry error.
 | <a id="servicetypeewm_service"></a>`EWM_SERVICE` | EwmService type. |
 | <a id="servicetypeexternal_wiki_service"></a>`EXTERNAL_WIKI_SERVICE` | ExternalWikiService type. |
 | <a id="servicetypegithub_service"></a>`GITHUB_SERVICE` | GithubService type. |
-| <a id="servicetypegitlab_slack_application_service"></a>`GITLAB_SLACK_APPLICATION_SERVICE` | GitlabSlackApplicationService type (Gitlab.com only). |
+| <a id="servicetypegitlab_slack_application_service"></a>`GITLAB_SLACK_APPLICATION_SERVICE` | GitlabSlackApplicationService type. |
 | <a id="servicetypegoogle_play_service"></a>`GOOGLE_PLAY_SERVICE` | GooglePlayService type. |
 | <a id="servicetypehangouts_chat_service"></a>`HANGOUTS_CHAT_SERVICE` | HangoutsChatService type. |
 | <a id="servicetypeharbor_service"></a>`HARBOR_SERVICE` | HarborService type. |
@@ -25409,6 +26365,7 @@ State of a Sentry error.
 | <a id="servicetypeslack_slash_commands_service"></a>`SLACK_SLASH_COMMANDS_SERVICE` | SlackSlashCommandsService type. |
 | <a id="servicetypesquash_tm_service"></a>`SQUASH_TM_SERVICE` | SquashTmService type. |
 | <a id="servicetypeteamcity_service"></a>`TEAMCITY_SERVICE` | TeamcityService type. |
+| <a id="servicetypetelegram_service"></a>`TELEGRAM_SERVICE` | TelegramService type. |
 | <a id="servicetypeunify_circuit_service"></a>`UNIFY_CIRCUIT_SERVICE` | UnifyCircuitService type. |
 | <a id="servicetypewebex_teams_service"></a>`WEBEX_TEAMS_SERVICE` | WebexTeamsService type. |
 | <a id="servicetypeyoutrack_service"></a>`YOUTRACK_SERVICE` | YoutrackService type. |
@@ -25517,10 +26474,10 @@ Values for sorting timelogs.
 | ----- | ----------- |
 | <a id="timelogsortcreated_asc"></a>`CREATED_ASC` | Created at ascending order. |
 | <a id="timelogsortcreated_desc"></a>`CREATED_DESC` | Created at descending order. |
-| <a id="timelogsortspent_at_asc"></a>`SPENT_AT_ASC` | Spent at by ascending order. |
-| <a id="timelogsortspent_at_desc"></a>`SPENT_AT_DESC` | Spent at by descending order. |
-| <a id="timelogsorttime_spent_asc"></a>`TIME_SPENT_ASC` | Time spent by ascending order. |
-| <a id="timelogsorttime_spent_desc"></a>`TIME_SPENT_DESC` | Time spent by descending order. |
+| <a id="timelogsortspent_at_asc"></a>`SPENT_AT_ASC` | Spent at ascending order. |
+| <a id="timelogsortspent_at_desc"></a>`SPENT_AT_DESC` | Spent at descending order. |
+| <a id="timelogsorttime_spent_asc"></a>`TIME_SPENT_ASC` | Time spent ascending order. |
+| <a id="timelogsorttime_spent_desc"></a>`TIME_SPENT_DESC` | Time spent descending order. |
 | <a id="timelogsortupdated_asc"></a>`UPDATED_ASC` | Updated at ascending order. |
 | <a id="timelogsortupdated_desc"></a>`UPDATED_DESC` | Updated at descending order. |
 | <a id="timelogsortcreated_asc"></a>`created_asc` **{warning-solid}** | **Deprecated** in 13.5. This was renamed. Use: `CREATED_ASC`. |
@@ -25592,6 +26549,7 @@ Name of the feature that the callout is for.
 | <a id="usercalloutfeaturenameenumci_deprecation_warning_for_types_keyword"></a>`CI_DEPRECATION_WARNING_FOR_TYPES_KEYWORD` | Callout feature name for ci_deprecation_warning_for_types_keyword. |
 | <a id="usercalloutfeaturenameenumcloud_licensing_subscription_activation_banner"></a>`CLOUD_LICENSING_SUBSCRIPTION_ACTIVATION_BANNER` | Callout feature name for cloud_licensing_subscription_activation_banner. |
 | <a id="usercalloutfeaturenameenumcluster_security_warning"></a>`CLUSTER_SECURITY_WARNING` | Callout feature name for cluster_security_warning. |
+| <a id="usercalloutfeaturenameenumcode_suggestions_third_party_callout"></a>`CODE_SUGGESTIONS_THIRD_PARTY_CALLOUT` | Callout feature name for code_suggestions_third_party_callout. |
 | <a id="usercalloutfeaturenameenumcreate_runner_workflow_banner"></a>`CREATE_RUNNER_WORKFLOW_BANNER` | Callout feature name for create_runner_workflow_banner. |
 | <a id="usercalloutfeaturenameenumeoa_bronze_plan_banner"></a>`EOA_BRONZE_PLAN_BANNER` | Callout feature name for eoa_bronze_plan_banner. |
 | <a id="usercalloutfeaturenameenumfeature_flags_new_version"></a>`FEATURE_FLAGS_NEW_VERSION` | Callout feature name for feature_flags_new_version. |
@@ -25602,11 +26560,13 @@ Name of the feature that the callout is for.
 | <a id="usercalloutfeaturenameenumgold_trial_billings"></a>`GOLD_TRIAL_BILLINGS` | Callout feature name for gold_trial_billings. |
 | <a id="usercalloutfeaturenameenummerge_request_settings_moved_callout"></a>`MERGE_REQUEST_SETTINGS_MOVED_CALLOUT` | Callout feature name for merge_request_settings_moved_callout. |
 | <a id="usercalloutfeaturenameenummr_experience_survey"></a>`MR_EXPERIENCE_SURVEY` | Callout feature name for mr_experience_survey. |
+| <a id="usercalloutfeaturenameenumnamespace_over_storage_users_combined_alert"></a>`NAMESPACE_OVER_STORAGE_USERS_COMBINED_ALERT` | Callout feature name for namespace_over_storage_users_combined_alert. |
 | <a id="usercalloutfeaturenameenumnamespace_storage_limit_banner_alert_threshold"></a>`NAMESPACE_STORAGE_LIMIT_BANNER_ALERT_THRESHOLD` | Callout feature name for namespace_storage_limit_banner_alert_threshold. |
 | <a id="usercalloutfeaturenameenumnamespace_storage_limit_banner_error_threshold"></a>`NAMESPACE_STORAGE_LIMIT_BANNER_ERROR_THRESHOLD` | Callout feature name for namespace_storage_limit_banner_error_threshold. |
 | <a id="usercalloutfeaturenameenumnamespace_storage_limit_banner_info_threshold"></a>`NAMESPACE_STORAGE_LIMIT_BANNER_INFO_THRESHOLD` | Callout feature name for namespace_storage_limit_banner_info_threshold. |
 | <a id="usercalloutfeaturenameenumnamespace_storage_limit_banner_warning_threshold"></a>`NAMESPACE_STORAGE_LIMIT_BANNER_WARNING_THRESHOLD` | Callout feature name for namespace_storage_limit_banner_warning_threshold. |
 | <a id="usercalloutfeaturenameenumnamespace_storage_pre_enforcement_banner"></a>`NAMESPACE_STORAGE_PRE_ENFORCEMENT_BANNER` | Callout feature name for namespace_storage_pre_enforcement_banner. |
+| <a id="usercalloutfeaturenameenumnew_navigation_callout"></a>`NEW_NAVIGATION_CALLOUT` | Callout feature name for new_navigation_callout. |
 | <a id="usercalloutfeaturenameenumnew_top_level_group_alert"></a>`NEW_TOP_LEVEL_GROUP_ALERT` | Callout feature name for new_top_level_group_alert. |
 | <a id="usercalloutfeaturenameenumnew_user_signups_cap_reached"></a>`NEW_USER_SIGNUPS_CAP_REACHED` | Callout feature name for new_user_signups_cap_reached. |
 | <a id="usercalloutfeaturenameenumpersonal_access_token_expiry"></a>`PERSONAL_ACCESS_TOKEN_EXPIRY` | Callout feature name for personal_access_token_expiry. |
@@ -25617,6 +26577,10 @@ Name of the feature that the callout is for.
 | <a id="usercalloutfeaturenameenumprofile_personal_access_token_expiry"></a>`PROFILE_PERSONAL_ACCESS_TOKEN_EXPIRY` | Callout feature name for profile_personal_access_token_expiry. |
 | <a id="usercalloutfeaturenameenumproject_quality_summary_feedback"></a>`PROJECT_QUALITY_SUMMARY_FEEDBACK` | Callout feature name for project_quality_summary_feedback. |
 | <a id="usercalloutfeaturenameenumregistration_enabled_callout"></a>`REGISTRATION_ENABLED_CALLOUT` | Callout feature name for registration_enabled_callout. |
+| <a id="usercalloutfeaturenameenumrepository_storage_limit_banner_alert_threshold"></a>`REPOSITORY_STORAGE_LIMIT_BANNER_ALERT_THRESHOLD` | Callout feature name for repository_storage_limit_banner_alert_threshold. |
+| <a id="usercalloutfeaturenameenumrepository_storage_limit_banner_error_threshold"></a>`REPOSITORY_STORAGE_LIMIT_BANNER_ERROR_THRESHOLD` | Callout feature name for repository_storage_limit_banner_error_threshold. |
+| <a id="usercalloutfeaturenameenumrepository_storage_limit_banner_info_threshold"></a>`REPOSITORY_STORAGE_LIMIT_BANNER_INFO_THRESHOLD` | Callout feature name for repository_storage_limit_banner_info_threshold. |
+| <a id="usercalloutfeaturenameenumrepository_storage_limit_banner_warning_threshold"></a>`REPOSITORY_STORAGE_LIMIT_BANNER_WARNING_THRESHOLD` | Callout feature name for repository_storage_limit_banner_warning_threshold. |
 | <a id="usercalloutfeaturenameenumsecurity_configuration_devops_alert"></a>`SECURITY_CONFIGURATION_DEVOPS_ALERT` | Callout feature name for security_configuration_devops_alert. |
 | <a id="usercalloutfeaturenameenumsecurity_configuration_upgrade_banner"></a>`SECURITY_CONFIGURATION_UPGRADE_BANNER` | Callout feature name for security_configuration_upgrade_banner. |
 | <a id="usercalloutfeaturenameenumsecurity_newsletter_callout"></a>`SECURITY_NEWSLETTER_CALLOUT` | Callout feature name for security_newsletter_callout. |
@@ -25956,6 +26920,12 @@ A `AuditEventsExternalAuditEventDestinationID` is a global ID. It is encoded as
 
 An example `AuditEventsExternalAuditEventDestinationID` is: `"gid://gitlab/AuditEvents::ExternalAuditEventDestination/1"`.
 
+### `AuditEventsGoogleCloudLoggingConfigurationID`
+
+A `AuditEventsGoogleCloudLoggingConfigurationID` is a global ID. It is encoded as a string.
+
+An example `AuditEventsGoogleCloudLoggingConfigurationID` is: `"gid://gitlab/AuditEvents::GoogleCloudLoggingConfiguration/1"`.
+
 ### `AuditEventsInstanceExternalAuditEventDestinationID`
 
 A `AuditEventsInstanceExternalAuditEventDestinationID` is a global ID. It is encoded as a string.
@@ -25968,6 +26938,12 @@ A `AuditEventsStreamingHeaderID` is a global ID. It is encoded as a string.
 
 An example `AuditEventsStreamingHeaderID` is: `"gid://gitlab/AuditEvents::Streaming::Header/1"`.
 
+### `AuditEventsStreamingInstanceHeaderID`
+
+A `AuditEventsStreamingInstanceHeaderID` is a global ID. It is encoded as a string.
+
+An example `AuditEventsStreamingInstanceHeaderID` is: `"gid://gitlab/AuditEvents::Streaming::InstanceHeader/1"`.
+
 ### `AwardableID`
 
 A `AwardableID` is a global ID. It is encoded as a string.
@@ -26006,6 +26982,12 @@ A `CiBuildID` is a global ID. It is encoded as a string.
 
 An example `CiBuildID` is: `"gid://gitlab/Ci::Build/1"`.
 
+### `CiCatalogResourceID`
+
+A `CiCatalogResourceID` is a global ID. It is encoded as a string.
+
+An example `CiCatalogResourceID` is: `"gid://gitlab/Ci::Catalog::Resource/1"`.
+
 ### `CiJobArtifactID`
 
 A `CiJobArtifactID` is a global ID. It is encoded as a string.
@@ -26190,6 +27172,12 @@ Duration between two instants, represented as a fractional number of seconds.
 
 For example: 12.3334.
 
+### `EmailID`
+
+A `EmailID` is a global ID. It is encoded as a string.
+
+An example `EmailID` is: `"gid://gitlab/Email/1"`.
+
 ### `EnvironmentID`
 
 A `EnvironmentID` is a global ID. It is encoded as a string.
@@ -26229,7 +27217,11 @@ An example `GitlabErrorTrackingDetailedErrorID` is: `"gid://gitlab/Gitlab::Error
 A global identifier.
 
 A global identifier represents an object uniquely across the application.
-An example of such an identifier is `"gid://gitlab/User/1"`.
+An example of a global identifier is `"gid://gitlab/User/1"`.
+
+`gid://gitlab` stands for the root name.
+`User` is the name of the ActiveRecord class of the record.
+`1` is the record id as per the id in the db table.
 
 Global identifiers are encoded as strings.
 
@@ -26677,6 +27669,7 @@ One of:
 - [`ContainerRepositoryRegistry`](#containerrepositoryregistry)
 - [`DependencyProxyBlobRegistry`](#dependencyproxyblobregistry)
 - [`DependencyProxyManifestRegistry`](#dependencyproxymanifestregistry)
+- [`DesignManagementRepositoryRegistry`](#designmanagementrepositoryregistry)
 - [`JobArtifactRegistry`](#jobartifactregistry)
 - [`LfsObjectRegistry`](#lfsobjectregistry)
 - [`MergeRequestDiffRegistry`](#mergerequestdiffregistry)
@@ -26713,6 +27706,7 @@ One of:
 - [`VulnerabilityDetailList`](#vulnerabilitydetaillist)
 - [`VulnerabilityDetailMarkdown`](#vulnerabilitydetailmarkdown)
 - [`VulnerabilityDetailModuleLocation`](#vulnerabilitydetailmodulelocation)
+- [`VulnerabilityDetailNamedList`](#vulnerabilitydetailnamedlist)
 - [`VulnerabilityDetailTable`](#vulnerabilitydetailtable)
 - [`VulnerabilityDetailText`](#vulnerabilitydetailtext)
 - [`VulnerabilityDetailUrl`](#vulnerabilitydetailurl)
@@ -26753,6 +27747,21 @@ Implementations:
 | <a id="alertmanagementintegrationtype"></a>`type` | [`AlertManagementIntegrationType!`](#alertmanagementintegrationtype) | Type of integration. |
 | <a id="alertmanagementintegrationurl"></a>`url` | [`String`](#string) | Endpoint which accepts alert notifications. |
 
+#### `BaseHeaderInterface`
+
+Implementations:
+
+- [`AuditEventStreamingHeader`](#auditeventstreamingheader)
+- [`AuditEventsStreamingInstanceHeader`](#auditeventsstreaminginstanceheader)
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="baseheaderinterfaceid"></a>`id` | [`ID!`](#id) | ID of the header. |
+| <a id="baseheaderinterfacekey"></a>`key` | [`String!`](#string) | Key of the header. |
+| <a id="baseheaderinterfacevalue"></a>`value` | [`String!`](#string) | Value of the header. |
+
 #### `CiVariable`
 
 Implementations:
@@ -27067,19 +28076,25 @@ Implementations:
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="useravatarurl"></a>`avatarUrl` | [`String`](#string) | URL of the user's avatar. |
+| <a id="userbio"></a>`bio` | [`String`](#string) | Bio of the user. |
 | <a id="userbot"></a>`bot` | [`Boolean!`](#boolean) | Indicates if the user is a bot. |
 | <a id="usercallouts"></a>`callouts` | [`UserCalloutConnection`](#usercalloutconnection) | User callouts that belong to the user. (see [Connections](#connections)) |
 | <a id="usercommitemail"></a>`commitEmail` | [`String`](#string) | User's default commit email. |
+| <a id="usercreatedat"></a>`createdAt` | [`Time`](#time) | Timestamp of when the user was created. |
+| <a id="userdiscord"></a>`discord` | [`String`](#string) | Discord ID of the user. |
 | <a id="useremail"></a>`email` **{warning-solid}** | [`String`](#string) | **Deprecated** in 13.7. This was renamed. Use: [`User.publicEmail`](#userpublicemail). |
 | <a id="useremails"></a>`emails` | [`EmailConnection`](#emailconnection) | User's email addresses. (see [Connections](#connections)) |
 | <a id="usergitpodenabled"></a>`gitpodEnabled` | [`Boolean`](#boolean) | Whether Gitpod is enabled at the user level. |
 | <a id="usergroupcount"></a>`groupCount` | [`Int`](#int) | Group count for the user. |
 | <a id="usergroupmemberships"></a>`groupMemberships` | [`GroupMemberConnection`](#groupmemberconnection) | Group memberships of the user. (see [Connections](#connections)) |
 | <a id="userid"></a>`id` | [`ID!`](#id) | ID of the user. |
+| <a id="userjobtitle"></a>`jobTitle` | [`String`](#string) | Job title of the user. |
+| <a id="userlinkedin"></a>`linkedin` | [`String`](#string) | LinkedIn profile name of the user. |
 | <a id="userlocation"></a>`location` | [`String`](#string) | Location of the user. |
 | <a id="username"></a>`name` | [`String!`](#string) | Human-readable name of the user. Returns `****` if the user is a project bot and the requester does not have permission to view the project. |
 | <a id="usernamespace"></a>`namespace` | [`Namespace`](#namespace) | Personal namespace of the user. |
 | <a id="usernamespacecommitemails"></a>`namespaceCommitEmails` | [`NamespaceCommitEmailConnection`](#namespacecommitemailconnection) | User's custom namespace commit emails. (see [Connections](#connections)) |
+| <a id="userorganization"></a>`organization` | [`String`](#string) | Who the user represents or works for. |
 | <a id="userpreferencesgitpodpath"></a>`preferencesGitpodPath` | [`String`](#string) | Web path to the Gitpod section within user preferences. |
 | <a id="userprofileenablegitpodpath"></a>`profileEnableGitpodPath` | [`String`](#string) | Web path to enable Gitpod for the user. |
 | <a id="userprojectmemberships"></a>`projectMemberships` | [`ProjectMemberConnection`](#projectmemberconnection) | Project memberships of the user. (see [Connections](#connections)) |
@@ -27087,6 +28102,7 @@ Implementations:
 | <a id="usersavedreplies"></a>`savedReplies` | [`SavedReplyConnection`](#savedreplyconnection) | Saved replies authored by the user. Will not return saved replies if `saved_replies` feature flag is disabled. (see [Connections](#connections)) |
 | <a id="userstate"></a>`state` | [`UserState!`](#userstate) | State of the user. |
 | <a id="userstatus"></a>`status` | [`UserStatus`](#userstatus) | User status. |
+| <a id="usertwitter"></a>`twitter` | [`String`](#string) | Twitter username of the user. |
 | <a id="useruserachievements"></a>`userAchievements` **{warning-solid}** | [`UserAchievementConnection`](#userachievementconnection) | **Introduced** in 15.10. This feature is an Experiment. It can be changed or removed at any time. Achievements for the user. Only returns for namespaces where the `achievements` feature flag is enabled. |
 | <a id="useruserpermissions"></a>`userPermissions` | [`UserPermissions!`](#userpermissions) | Permissions for the current user on the resource. |
 | <a id="userusername"></a>`username` | [`String!`](#string) | Username of the user. Unique within this instance of GitLab. |
@@ -27359,6 +28375,15 @@ be used as arguments).
 Only general use input types are listed here. For mutation input types,
 see the associated mutation type above.
 
+### `AiChatInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="aichatinputcontent"></a>`content` | [`String!`](#string) | Content of the message. |
+| <a id="aichatinputresourceid"></a>`resourceId` | [`AiModelID!`](#aimodelid) | Global ID of the resource to mutate. |
+
 ### `AiExplainCodeInput`
 
 #### Arguments
@@ -27385,6 +28410,27 @@ see the associated mutation type above.
 | ---- | ---- | ----------- |
 | <a id="aiexplainvulnerabilityinputresourceid"></a>`resourceId` | [`AiModelID!`](#aimodelid) | Global ID of the resource to mutate. |
 
+### `AiFillInMergeRequestTemplateInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="aifillinmergerequesttemplateinputcontent"></a>`content` | [`String!`](#string) | Template content to fill in. |
+| <a id="aifillinmergerequesttemplateinputresourceid"></a>`resourceId` | [`AiModelID!`](#aimodelid) | Global ID of the resource to mutate. |
+| <a id="aifillinmergerequesttemplateinputsourcebranch"></a>`sourceBranch` | [`String!`](#string) | Source branch of the changes. |
+| <a id="aifillinmergerequesttemplateinputsourceprojectid"></a>`sourceProjectId` | [`ID`](#id) | ID of the project where the changes are from. |
+| <a id="aifillinmergerequesttemplateinputtargetbranch"></a>`targetBranch` | [`String!`](#string) | Target branch of where the changes will be merged into. |
+| <a id="aifillinmergerequesttemplateinputtitle"></a>`title` | [`String!`](#string) | Title of the merge request to be created. |
+
+### `AiGenerateCommitMessageInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="aigeneratecommitmessageinputresourceid"></a>`resourceId` | [`AiModelID!`](#aimodelid) | Global ID of the resource to mutate. |
+
 ### `AiGenerateDescriptionInput`
 
 #### Arguments
@@ -27403,6 +28449,14 @@ see the associated mutation type above.
 | ---- | ---- | ----------- |
 | <a id="aisummarizecommentsinputresourceid"></a>`resourceId` | [`AiModelID!`](#aimodelid) | Global ID of the resource to mutate. |
 
+### `AiSummarizeReviewInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="aisummarizereviewinputresourceid"></a>`resourceId` | [`AiModelID!`](#aimodelid) | Global ID of the resource to mutate. |
+
 ### `AiTanukiBotInput`
 
 #### Arguments
@@ -27425,6 +28479,14 @@ Field that are available while modifying the custom mapping attributes for an HT
 | <a id="alertmanagementpayloadalertfieldinputpath"></a>`path` | [`[PayloadAlertFieldPathSegment!]!`](#payloadalertfieldpathsegment) | Path to value inside payload JSON. |
 | <a id="alertmanagementpayloadalertfieldinputtype"></a>`type` | [`AlertManagementPayloadAlertFieldType!`](#alertmanagementpayloadalertfieldtype) | Type of the parsed value. |
 
+### `AnalyzeCiJobFailureInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="analyzecijobfailureinputresourceid"></a>`resourceId` | [`AiModelID!`](#aimodelid) | Global ID of the resource to mutate. |
+
 ### `BoardIssueInput`
 
 #### Arguments
diff --git a/doc/api/group_import_export.md b/doc/api/group_import_export.md
index c78f0ecb781..a409b2e3a11 100644
--- a/doc/api/group_import_export.md
+++ b/doc/api/group_import_export.md
@@ -17,20 +17,22 @@ Group exports include the following:
 - Group labels
 - Group badges
 - Group members
-- Subgroups. Each subgroup includes all data above
 - Group wikis **(PREMIUM SELF)**
+- Subgroups. Each subgroup includes all data above
 
-To preserve group-level relationships from imported projects, you should run group import and export first. This way, you can import project exports into the desired group structure.
+To preserve group-level relationships from imported projects, you should run group export and import first. This way,
+you can import project exports into the desired group structure.
 
-Imported groups have a `private` visibility level unless you import them into a parent group.
-If you import groups into a parent group, the subgroups inherit by default a similar level of visibility.
+Because of a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/405168), imported groups have a `private`
+visibility level unless you import them into a parent group. By default, if you import groups into a parent group,
+the subgroups inherit the same level of visibility as the parent.
 
 To preserve the member list and their respective permissions on imported groups, review the users in these groups. Make sure these users exist before importing the desired groups.
 
 ## Prerequisites
 
-For information on prerequisites for group import and export API, see prerequisites for
-[migrating groups by uploading an export file](../user/group/import/index.md#preparation).
+- For information on prerequisites for group import and export API, see prerequisites for
+  [migrating groups by uploading an export file](../user/group/import/index.md#preparation).
 
 ## Schedule new export
 
@@ -88,6 +90,15 @@ returns either:
 
 ## Import a file
 
+The maximum import file size can be set by the Administrator on self-managed instances (default is `0` (unlimited)).
+As an administrator, you can modify the maximum import file size either:
+
+- The admin [Admin Area](../user/admin_area/settings/account_and_limit_settings.md).
+- The `max_import_size` option in the [Application settings API](settings.md#change-application-settings).
+
+For information on the maximum import file size on GitLab.com, see
+[Account and limit settings](../user/gitlab_com/index.md#account-and-limit-settings).
+
 ```plaintext
 POST /groups/import
 ```
@@ -110,6 +121,6 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
      --form "file=@/path/to/file" "https://gitlab.example.com/api/v4/groups/import"
 ```
 
-NOTE:
-The maximum import file size can be set by the Administrator, default is `0` (unlimited).
-As an administrator, you can modify the maximum import file size. To do so, use the `max_import_size` option in the [Application settings API](settings.md#change-application-settings) or the [Admin Area](../user/admin_area/settings/account_and_limit_settings.md). Default [modified](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50 MB to 0 in GitLab 13.8.
+## Related topics
+
+- [Project import and export API](project_import_export.md)
diff --git a/doc/api/group_relations_export.md b/doc/api/group_relations_export.md
index 5118b2f00f5..3721e712dd9 100644
--- a/doc/api/group_relations_export.md
+++ b/doc/api/group_relations_export.md
@@ -4,14 +4,16 @@ group: Import and Integrate
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Group Relations Export API **(FREE)**
+# Group relations export API **(FREE)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59978) in GitLab 13.12.
 
-With the Group Relations Export API, you can partially export group structure. This API is similar
-to [group export](group_import_export.md),
-but it exports each top-level relation (for example, milestones/boards/labels) as a separate file
-instead of one archive. The group relations export API is primarily used in [group migration](../user/group/import/index.md).
+The group relations export API partially exports a group's structure as separate files for each top-level
+relation (for example, milestones, boards, and labels).
+
+The group relations export API is primarily used in
+[group migration by direct transfer](../user/group/import/index.md#migrate-groups-by-direct-transfer-recommended) and
+can't be used with the [group import and export API](group_import_export.md).
 
 ## Schedule new export
 
@@ -101,3 +103,7 @@ curl --header "PRIVATE-TOKEN: <your_access_token>" --remote-header-name \
 ls labels.ndjson.gz
 labels.ndjson.gz
 ```
+
+## Related topics
+
+- [Project relations export API](project_relations_export.md)
diff --git a/doc/api/groups.md b/doc/api/groups.md
index 6d295b50a01..7b73fe9066e 100644
--- a/doc/api/groups.md
+++ b/doc/api/groups.md
@@ -12,6 +12,8 @@ The fields returned in responses vary based on the [permissions](../user/permiss
 
 ## List groups
 
+> Support for keyset pagination introduced in GitLab 14.3.
+
 Get a list of visible groups for the authenticated user. When accessed without
 authentication, only public groups are returned.
 
@@ -19,7 +21,7 @@ By default, this request returns 20 results at a time because the API results [a
 
 When accessed without authentication, this endpoint also supports [keyset pagination](rest/index.md#keyset-based-pagination):
 
-- When requesting consecutive pages of results, we recommend you use keyset pagination.
+- When requesting consecutive pages of results, you should use keyset pagination.
 - Beyond a specific offset limit (specified by [max offset allowed by the REST API for offset-based pagination](../administration/instance_limits.md#max-offset-allowed-by-the-rest-api-for-offset-based-pagination)), offset pagination is unavailable.
 
 Parameters:
@@ -820,9 +822,9 @@ Parameters:
 | `two_factor_grace_period`                               | integer | no       | Time before Two-factor authentication is enforced (in hours). |
 | `visibility`                                            | string  | no       | The group's visibility. Can be `private`, `internal`, or `public`. |
 | `membership_lock` **(PREMIUM)**                         | boolean | no       | Users cannot be added to projects in this group. |
-| `extra_shared_runners_minutes_limit` **(PREMIUM SELF)**      | integer | no       | Can be set by administrators only. Additional CI/CD minutes for this group. |
-| `shared_runners_minutes_limit` **(PREMIUM SELF)**            | integer | no       | Can be set by administrators only. Maximum number of monthly CI/CD minutes for this group. Can be `nil` (default; inherit system default), `0` (unlimited), or `> 0`. |
-| `wiki_access_level` **(PREMIUM)**                            | string  | no       | The wiki access level. Can be `disabled`, `private`, or `enabled`. |
+| `extra_shared_runners_minutes_limit` **(PREMIUM SELF)** | integer | no       | Can be set by administrators only. Additional units of compute for this group. |
+| `shared_runners_minutes_limit` **(PREMIUM SELF)**       | integer | no       | Can be set by administrators only. Maximum number of monthly units of compute for this group. Can be `nil` (default; inherit system default), `0` (unlimited), or `> 0`. |
+| `wiki_access_level` **(PREMIUM)**                       | string  | no       | The wiki access level. Can be `disabled`, `private`, or `enabled`. |
 
 ### Options for `default_branch_protection`
 
@@ -834,6 +836,7 @@ The `default_branch_protection` attribute determines whether users with the Deve
 | `1`   | Partial protection. Users with the Developer or Maintainer role can:  <br>- Push new commits |
 | `2`   | Full protection. Only users with the Maintainer role can:  <br>- Push new commits |
 | `3`   | Protected against pushes. Users with the Maintainer role can: <br>- Push new commits<br>- Force push changes<br>- Accept merge requests<br>Users with the Developer role can:<br>- Accept merge requests|
+| `4`   | Protected against pushes except initial push. User with the Developer rope can: <br>- Push commit to empty repository.<br> Users with the Maintainer role can: <br>- Push new commits<br>- Force push changes<br>- Accept merge requests<br>Users with the Developer role can:<br>- Accept merge requests|
 
 ## New Subgroup
 
@@ -976,11 +979,11 @@ PUT /groups/:id
 | `subgroup_creation_level`                               | string  | no       | Allowed to [create subgroups](../user/group/subgroups/index.md#create-a-subgroup). Can be `owner` (Owners), or `maintainer` (users with the Maintainer role). |
 | `two_factor_grace_period`                               | integer | no       | Time before Two-factor authentication is enforced (in hours). |
 | `visibility`                                            | string  | no       | The visibility level of the group. Can be `private`, `internal`, or `public`. |
-| `extra_shared_runners_minutes_limit` **(PREMIUM SELF)**      | integer | no       | Can be set by administrators only. Additional CI/CD minutes for this group. |
+| `extra_shared_runners_minutes_limit` **(PREMIUM SELF)** | integer | no       | Can be set by administrators only. Additional units of compute for this group. |
 | `file_template_project_id` **(PREMIUM)**                | integer | no       | The ID of a project to load custom file templates from. |
 | `membership_lock` **(PREMIUM)**                         | boolean | no       | Users cannot be added to projects in this group. |
 | `prevent_forking_outside_group` **(PREMIUM)**           | boolean | no       | When enabled, users can **not** fork projects from this group to external namespaces. |
-| `shared_runners_minutes_limit` **(PREMIUM SELF)**            | integer | no       | Can be set by administrators only. Maximum number of monthly CI/CD minutes for this group. Can be `nil` (default; inherit system default), `0` (unlimited), or `> 0`. |
+| `shared_runners_minutes_limit` **(PREMIUM SELF)**       | integer | no       | Can be set by administrators only. Maximum number of monthly units of compute for this group. Can be `nil` (default; inherit system default), `0` (unlimited), or `> 0`. |
 | `unique_project_download_limit` **(ULTIMATE)** | integer | no | Maximum number of unique projects a user can download in the specified time period before they are banned. Available only on top-level groups. Default: 0, Maximum: 10,000. |
 | `unique_project_download_limit_interval_in_seconds` **(ULTIMATE)** | integer | no | Time period during which a user can download a maximum amount of projects before they are banned. Available only on top-level groups. Default: 0, Maximum: 864,000 seconds (10 days). |
 | `unique_project_download_limit_allowlist` **(ULTIMATE)** | array of strings | no | List of usernames excluded from the unique project download limit. Available only on top-level groups. Default: `[]`, Maximum: 100 usernames. |
@@ -1222,50 +1225,134 @@ Example response:
 ```json
 [
   {
-    id: 66,
-    username: "user22",
-    name: "John Doe22",
-    state: "active",
-    avatar_url: "https://www.gravatar.com/avatar/xxx?s=80&d=identicon",
-    web_url: "http://my.gitlab.com/user22",
-    created_at: "2021-09-10T12:48:22.381Z",
-    bio: "",
-    location: null,
-    public_email: "",
-    skype: "",
-    linkedin: "",
-    twitter: "",
-    website_url: "",
-    organization: null,
-    job_title: "",
-    pronouns: null,
-    bot: false,
-    work_information: null,
-    followers: 0,
-    following: 0,
-    local_time: null,
-    last_sign_in_at: null,
-    confirmed_at: "2021-09-10T12:48:22.330Z",
-    last_activity_on: null,
-    email: "user22@example.org",
-    theme_id: 1,
-    color_scheme_id: 1,
-    projects_limit: 100000,
-    current_sign_in_at: null,
-    identities: [ ],
-    can_create_group: true,
-    can_create_project: true,
-    two_factor_enabled: false,
-    external: false,
-    private_profile: false,
-    commit_email: "user22@example.org",
-    shared_runners_minutes_limit: null,
-    extra_shared_runners_minutes_limit: null
+    "id": 66,
+    "username": "user22",
+    "name": "John Doe22",
+    "state": "active",
+    "avatar_url": "https://www.gravatar.com/avatar/xxx?s=80&d=identicon",
+    "web_url": "http://my.gitlab.com/user22",
+    "created_at": "2021-09-10T12:48:22.381Z",
+    "bio": "",
+    "location": null,
+    "public_email": "",
+    "skype": "",
+    "linkedin": "",
+    "twitter": "",
+    "website_url": "",
+    "organization": null,
+    "job_title": "",
+    "pronouns": null,
+    "bot": false,
+    "work_information": null,
+    "followers": 0,
+    "following": 0,
+    "local_time": null,
+    "last_sign_in_at": null,
+    "confirmed_at": "2021-09-10T12:48:22.330Z",
+    "last_activity_on": null,
+    "email": "user22@example.org",
+    "theme_id": 1,
+    "color_scheme_id": 1,
+    "projects_limit": 100000,
+    "current_sign_in_at": null,
+    "identities": [ ],
+    "can_create_group": true,
+    "can_create_project": true,
+    "two_factor_enabled": false,
+    "external": false,
+    "private_profile": false,
+    "commit_email": "user22@example.org",
+    "shared_runners_minutes_limit": null,
+    "extra_shared_runners_minutes_limit": null
   },
   ...
 ]
 ```
 
+## Service Accounts **(PREMIUM)**
+
+### Create Service Account User
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/407775) in GitLab 16.1.
+
+Creates a service account user with an auto-generated email address and username.
+
+```plaintext
+POST /groups/:id/service_accounts
+```
+
+```shell
+curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/345/service_accounts"
+```
+
+Example response:
+
+```json
+{
+  "id": 57,
+  "username": "service_account_group_345_6018816a18e515214e0c34c2b33523fc",
+  "name": "Service account user"
+}
+```
+
+### Create Personal Access Token for Service Account User
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/406781) in GitLab 16.1.
+
+```plaintext
+POST /groups/:id/service_accounts/:user_id/personal_access_tokens
+```
+
+```shell
+curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gdk.test:3443/api/v4/groups/35/service_accounts/71/personal_access_tokens" --data "scopes[]=api" --data "name=service_accounts_token"
+```
+
+Example response:
+
+```json
+{
+  "id":6,
+  "name":"service_accounts_token",
+  "revoked":false,
+  "created_at":"2023-06-13T07:47:13.900Z",
+  "scopes":["api"],
+  "user_id":71,
+  "last_used_at":null,
+  "active":true,
+  "expires_at":"2024-06-12",
+  "token":"<token_value>"
+}
+```
+
+### Rotate a Personal Access Token for Service Account User
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/406781) in GitLab 16.1.
+
+```plaintext
+POST /groups/:id/service_accounts/:user_id/personal_access_tokens/:token_id/rotate
+```
+
+```shell
+curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gdk.test:3443/api/v4/groups/35/service_accounts/71/personal_access_tokens/6/rotate"
+```
+
+Example response:
+
+```json
+{
+  "id":7,
+  "name":"service_accounts_token",
+  "revoked":false,
+  "created_at":"2023-06-13T07:54:49.962Z",
+  "scopes":["api"],
+  "user_id":71,
+  "last_used_at":null,
+  "active":true,
+  "expires_at":"2023-06-20",
+  "token":"<token_value>"
+}
+```
+
 ## Hooks **(PREMIUM)**
 
 Also called Group Hooks and Webhooks.
diff --git a/doc/api/integrations.md b/doc/api/integrations.md
index 5b6c4d17915..b1cb6ed6560 100644
--- a/doc/api/integrations.md
+++ b/doc/api/integrations.md
@@ -39,9 +39,11 @@ Example response:
     "commit_events": true,
     "push_events": true,
     "issues_events": true,
+    "alert_events": true,
     "confidential_issues_events": true,
     "merge_requests_events": true,
     "tag_push_events": false,
+    "deployment_events": false,
     "note_events": true,
     "confidential_note_events": true,
     "pipeline_events": true,
@@ -59,9 +61,11 @@ Example response:
     "commit_events": true,
     "push_events": true,
     "issues_events": true,
+    "alert_events": true,
     "confidential_issues_events": true,
     "merge_requests_events": true,
     "tag_push_events": true,
+    "deployment_events": false,
     "note_events": true,
     "confidential_note_events": true,
     "pipeline_events": true,
@@ -93,6 +97,7 @@ Parameters:
 | `app_store_issuer_id` | string | true | The Apple App Store Connect Issuer ID. |
 | `app_store_key_id` | string | true | The Apple App Store Connect Key ID. |
 | `app_store_private_key` | string | true | The Apple App Store Connect Private Key. |
+| `app_store_protected_refs` | boolean | false | Set variables only on protected branches and tags. Defaults to `true` (enabled). |
 
 ### Disable Apple App Store integration
 
@@ -334,6 +339,43 @@ Get Campfire integration settings for a project.
 GET /projects/:id/integrations/campfire
 ```
 
+## ClickUp
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120732) in GitLab 16.1.
+
+ClickUp issue tracker.
+
+### Create or edit ClickUp integration
+
+Set up ClickUp integration for a project.
+
+```plaintext
+PUT /projects/:id/integrations/clickup
+```
+
+Parameters:
+
+| Parameter | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `issues_url` | string | true | Issue URL |
+| `project_url` | string | true | Project URL |
+
+### Disable ClickUp integration
+
+Disable the ClickUp integration for a project. Integration settings are reset.
+
+```plaintext
+DELETE /projects/:id/integrations/clickup
+```
+
+### Get ClickUp integration settings
+
+Get ClickUp integration settings for a project.
+
+```plaintext
+GET /projects/:id/integrations/clickup
+```
+
 ## Datadog
 
 Datadog system monitoring.
@@ -374,6 +416,50 @@ Get Datadog integration settings for a project.
 GET /projects/:id/integrations/datadog
 ```
 
+## Telegram
+
+Telegram chat tool.
+
+### Create/Edit Telegram integration
+
+Set the Telegram integration for a project.
+
+```plaintext
+PUT /projects/:id/integrations/telegram
+```
+
+Parameters:
+
+| Parameter | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `token`   | string | true | The Telegram bot token. For example, `123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11`. |
+| `room` | string | true | Unique identifier for the target chat or the username of the target channel (in the format `@channelusername`) |
+| `push_events` | boolean | true | Enable notifications for push events |
+| `issues_events` | boolean | true | Enable notifications for issue events |
+| `confidential_issues_events` | boolean | true | Enable notifications for confidential issue events |
+| `merge_requests_events` | boolean | true | Enable notifications for merge request events |
+| `tag_push_events` | boolean | true | Enable notifications for tag push events |
+| `note_events` | boolean | true | Enable notifications for note events |
+| `confidential_note_events` | boolean | true | Enable notifications for confidential note events |
+| `pipeline_events` | boolean | true | Enable notifications for pipeline events |
+| `wiki_page_events` | boolean | true | Enable notifications for wiki page events |
+
+### Disable Telegram integration
+
+Disable the Telegram integration for a project. Integration settings are reset.
+
+```plaintext
+DELETE /projects/:id/integrations/telegram
+```
+
+### Get Telegram integration settings
+
+Get Telegram integration settings for a project.
+
+```plaintext
+GET /projects/:id/integrations/telegram
+```
+
 ## Unify Circuit
 
 Unify Circuit RTC and collaboration tool.
@@ -562,6 +648,17 @@ Parameters:
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
 | `webhook` | string | true | Discord webhook. For example, `https://discord.com/api/webhooks/…` |
+| `branches_to_be_notified` | string | false | Branches to send notifications for. Valid options are `all`, `default`, `protected`, and `default_and_protected`. The default value is "default" |
+| `confidential_issues_events` | boolean | false | Enable notifications for confidential issue events |
+| `confidential_note_events` | boolean | false | Enable notifications for confidential note events |
+| `issues_events` | boolean | false | Enable notifications for issue events |
+| `merge_requests_events` | boolean | false | Enable notifications for merge request events |
+| `note_events` | boolean | false | Enable notifications for note events |
+| `notify_only_broken_pipelines` | boolean | false | Send notifications for broken pipelines |
+| `pipeline_events` | boolean | false | Enable notifications for pipeline events |
+| `push_events` | boolean | false | Enable notifications for push events |
+| `tag_push_events` | boolean | false | Enable notifications for tag push events |
+| `wiki_page_events` | boolean | false | Enable notifications for wiki page events |
 
 ### Disable Discord integration
 
@@ -1300,6 +1397,8 @@ Parameters:
 | `notify_only_broken_pipelines` | boolean | false | Send notifications for broken pipelines |
 | `notify_only_default_branch` | boolean | false | DEPRECATED: This parameter has been replaced with `branches_to_be_notified` |
 | `branches_to_be_notified` | string | false | Branches to send notifications for. Valid options are `all`, `default`, `protected`, and `default_and_protected`. The default value is "default" |
+| `alert_channel` | string | false | The name of the channel to receive alert events notifications |
+| `alert_events` | boolean | false | Enable notifications for alert events |
 | `commit_events` | boolean | false | Enable notifications for commit events |
 | `confidential_issue_channel` | string | false | The name of the channel to receive confidential issues events notifications |
 | `confidential_issues_events` | boolean | false | Enable notifications for confidential issue events |
@@ -1307,6 +1406,8 @@ Parameters:
 | `confidential_note_events` | boolean | false | Enable notifications for confidential note events |
 | `deployment_channel` | string | false | The name of the channel to receive deployment events notifications |
 | `deployment_events` | boolean | false | Enable notifications for deployment events |
+| `incident_channel` | string | false | The name of the channel to receive incidents events notifications |
+| `incidents_events` | boolean | false | Enable notifications for incident events |
 | `issue_channel` | string | false | The name of the channel to receive issues events notifications |
 | `issues_events` | boolean | false | Enable notifications for issue events |
 | `job_events` | boolean | false | Enable notifications for job events |
diff --git a/doc/api/job_artifacts.md b/doc/api/job_artifacts.md
index 3b6eaf9b670..afb8f294a18 100644
--- a/doc/api/job_artifacts.md
+++ b/doc/api/job_artifacts.md
@@ -18,7 +18,7 @@ GET /projects/:id/jobs/:job_id/artifacts
 
 | Attribute                 | Type           | Required | Description |
 |---------------------------|----------------|----------|-------------|
-| `id`                      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) owned by the authenticated user. |
+| `id`                      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding). |
 | `job_id`                  | integer        | yes      | ID of a job. |
 | `job_token` **(PREMIUM)** | string         | no       | To be used with [triggers](../ci/jobs/ci_job_token.md#download-an-artifact-from-a-different-pipeline) for multi-project pipelines. It should be invoked only in a CI/CD job defined in the `.gitlab-ci.yml` file. The value is always `$CI_JOB_TOKEN`. The job associated with the `$CI_JOB_TOKEN` must be running when this token is used. |
 
@@ -82,7 +82,7 @@ Parameters
 
 | Attribute                 | Type           | Required | Description |
 |---------------------------|----------------|----------|-------------|
-| `id`                      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) owned by the authenticated user. |
+| `id`                      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding). |
 | `ref_name`                | string         | yes      | Branch or tag name in repository. HEAD or SHA references are not supported. |
 | `job`                     | string         | yes      | The name of the job. |
 | `job_token` **(PREMIUM)** | string         | no       | To be used with [triggers](../ci/jobs/ci_job_token.md#download-an-artifact-from-a-different-pipeline) for multi-project pipelines. It should be invoked only in a CI/CD job defined in the `.gitlab-ci.yml` file. The value is always `$CI_JOB_TOKEN`. The job associated with the `$CI_JOB_TOKEN` must be running when this token is used. |
@@ -143,7 +143,7 @@ Parameters
 
 | Attribute                 | Type           | Required | Description |
 |---------------------------|----------------|----------|-------------|
-| `id`                      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) owned by the authenticated user. |
+| `id`                      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding). |
 | `job_id`                  | integer        | yes      | The unique job identifier. |
 | `artifact_path`           | string         | yes      | Path to a file inside the artifacts archive. |
 | `job_token` **(PREMIUM)** | string         | no       | To be used with [triggers](../ci/jobs/ci_job_token.md#download-an-artifact-from-a-different-pipeline) for multi-project pipelines. It should be invoked only in a CI/CD job defined in the `.gitlab-ci.yml` file. The value is always `$CI_JOB_TOKEN`. The job associated with the `$CI_JOB_TOKEN` must be running when this token is used. |
@@ -187,7 +187,7 @@ Parameters:
 
 | Attribute                 | Type           | Required | Description |
 |---------------------------|----------------|----------|-------------|
-| `id`                      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) owned by the authenticated user. |
+| `id`                      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding). |
 | `ref_name`                | string         | yes      | Branch or tag name in repository. `HEAD` or `SHA` references are not supported. |
 | `artifact_path`           | string         | yes      | Path to a file inside the artifacts archive. |
 | `job`                     | string         | yes      | The name of the job. |
@@ -268,13 +268,17 @@ Example response:
 
 Delete artifacts of a job.
 
+Prerequisites:
+
+- Must have at least the maintainer role in the project.
+
 ```plaintext
 DELETE /projects/:id/jobs/:job_id/artifacts
 ```
 
 | Attribute | Type           | Required | Description                                                                 |
 |-----------|----------------|----------|-----------------------------------------------------------------------------|
-| `id`      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) |
+| `id`      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding). |
 | `job_id`  | integer        | yes      | ID of a job.                                                                |
 
 Example request:
@@ -303,7 +307,7 @@ DELETE /projects/:id/artifacts
 
 | Attribute | Type           | Required | Description                                                                 |
 |-----------|----------------|----------|-----------------------------------------------------------------------------|
-| `id`      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) |
+| `id`      | integer/string | yes      | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding). |
 
 Example request:
 
diff --git a/doc/api/jobs.md b/doc/api/jobs.md
index f060d86c335..a28acfbd1a1 100644
--- a/doc/api/jobs.md
+++ b/doc/api/jobs.md
@@ -8,6 +8,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 ## List project jobs
 
+> Support for keyset pagination [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/362172) in GitLab 15.9.
+
 Get a list of jobs in a project. Jobs are sorted in descending order of their IDs.
 
 By default, this request returns 20 results at a time because the API results [are paginated](rest/index.md#pagination)
diff --git a/doc/api/merge_request_approvals.md b/doc/api/merge_request_approvals.md
index ccd79c697a0..19179bddb00 100644
--- a/doc/api/merge_request_approvals.md
+++ b/doc/api/merge_request_approvals.md
@@ -596,6 +596,20 @@ Supported attributes:
 }
 ```
 
+<!--- start_remove The following content will be removed on remove_date: '2023-08-17' -->
+
+### Change approval configuration (removed)
+
+> - Endpoint `/approvals` [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/11132) in GitLab 12.3.
+> - Endpoint `approvals` [disabled](https://gitlab.com/gitlab-org/gitlab/-/issues/353097) in GitLab 16.0 [with a flag](../administration/feature_flags.md) named `remove_deprecated_approvals`. Disabled by default.
+
+The endpoint `POST /projects/:id/merge_requests/:merge_request_iid/approvals` was
+deprecated in GitLab 12.3, and removed in GitLab 16.0. To change the approvals
+required for a merge request, use the `/approval_rules` endpoint described in
+[Create merge request level rule](#create-merge-request-level-rule) on this page.
+
+<!--- end_remove -->
+
 ### Get the approval state of merge requests
 
 > Moved to GitLab Premium in 13.9.
diff --git a/doc/api/merge_requests.md b/doc/api/merge_requests.md
index 1be5f6204a1..d6360552baf 100644
--- a/doc/api/merge_requests.md
+++ b/doc/api/merge_requests.md
@@ -13,8 +13,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - `merge_status` was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/3169#note_1162532204) in favor of `detailed_merge_status` in GitLab 15.6.
 > - `with_merge_status_recheck` [changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115948) in GitLab 15.11  [with a flag](../administration/feature_flags.md) named `restrict_merge_status_recheck` to be ignored for requests from users insufficient permissions. Disabled by default.
 > - `approvals_before_merge` was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119503) in GitLab 16.0.
+> - `prepared_at` was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122001) in GitLab 16.1.
 
-Every API call to merge requests must be authenticated.
+Authentication is required for API calls to non-public information.
 
 ## Removals in API v5
 
@@ -108,6 +109,7 @@ Supported attributes:
       "web_url": "https://gitlab.com/DouweM"
     },
     "merged_at": "2018-09-07T11:16:17.520Z",
+    "prepared_at": "2018-09-04T11:16:17.520Z",
     "closed_by": null,
     "closed_at": null,
     "created_at": "2017-04-29T08:46:00Z",
@@ -296,6 +298,7 @@ Supported attributes:
       "web_url": "https://gitlab.com/DouweM"
     },
     "merged_at": "2018-09-07T11:16:17.520Z",
+    "prepared_at": "2018-09-04T11:16:17.520Z",
     "closed_by": null,
     "closed_at": null,
     "created_at": "2017-04-29T08:46:00Z",
@@ -471,6 +474,7 @@ Supported attributes:
       "web_url": "https://gitlab.com/DouweM"
     },
     "merged_at": "2018-09-07T11:16:17.520Z",
+    "prepared_at": "2018-09-04T11:16:17.520Z",
     "closed_by": null,
     "closed_at": null,
     "created_at": "2017-04-29T08:46:00Z",
@@ -621,13 +625,14 @@ Supported attributes:
 | `latest_build_started_at` | datetime | Timestamp of when the latest build for the merge request started. |
 | `merge_commit_sha` | string | SHA of the merge request commit. Returns `null` until merged. |
 | `merge_error` | string | Error message shown when a merge has failed. To check mergeability, use `detailed_merge_status` instead  |
-| `merge_user` | object | The user who merged this merge request, the user who set it to merge when pipeline succeeds, or `null`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/349031) in GitLab 14.7. |
+| `merge_user` | object | The user who merged this merge request, the user who set it to auto-merge, or `null`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/349031) in GitLab 14.7. |
 | `merge_status` | string | Status of the merge request. Can be `unchecked`, `checking`, `can_be_merged`, `cannot_be_merged`, or `cannot_be_merged_recheck`. Affects the `has_conflicts` property. For important notes on response data, read [Single merge request response notes](#single-merge-request-response-notes). [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/3169#note_1162532204) in GitLab 15.6. Use `detailed_merge_status` instead. |
 | `merge_when_pipeline_succeeds` | boolean | Indicates if the merge has been set to be merged when its pipeline succeeds. |
 | `merged_at` | datetime | Timestamp of when the merge request was merged. |
-| `merged_by` | object | User who merged this merge request or set it to merge when pipeline succeeds. [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/350534) in GitLab 14.7, and scheduled for removal in [API version 5](https://gitlab.com/groups/gitlab-org/-/epics/8115). Use `merge_user` instead. |
+| `merged_by` | object | User who merged this merge request or set it to auto-merge. [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/350534) in GitLab 14.7, and scheduled for removal in [API version 5](https://gitlab.com/groups/gitlab-org/-/epics/8115). Use `merge_user` instead. |
 | `milestone` | object | Milestone of the merge request. |
 | `pipeline` | object | Pipeline running on the branch HEAD of the merge request. Consider using `head_pipeline` instead, as it contains more information. |
+| `prepared_at` | datetime | Timestamp of when the merge request was prepared. This field is populated one time, only after all the [preparation steps](#preparation-steps) are completed, and is not updated if more changes are added. |
 | `project_id` | integer | ID of the merge request project. |
 | `reference` | string | Internal reference of the merge request. Returned in shortened format by default. [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20354) in GitLab 12.7, and scheduled for removal in [API version 5](https://gitlab.com/groups/gitlab-org/-/epics/8115). Use `references` instead. |
 | `references` | object | Internal references of the merge request. Includes `short`, `relative`, and `full` references. `references.relative` is relative to the merge request's group or project. When fetched from the merge request's project, `relative` and `short` formats are identical. When requested across groups or projects, `relative` and `full` formats are identical.|
@@ -664,6 +669,7 @@ Supported attributes:
   "merged_by": null, // Deprecated and will be removed in API v5. Use `merge_user` instead.
   "merge_user": null,
   "merged_at": null,
+  "prepared_at": "2018-09-04T11:16:17.520Z",
   "closed_by": null,
   "closed_at": null,
   "target_branch": "master",
@@ -822,6 +828,18 @@ Use `detailed_merge_status` instead of `merge_status` to account for all potenti
   - `not_open`: The merge request must be open before merge.
   - `policies_denied`: The merge request contains denied policies.
 
+### Preparation steps
+
+The `prepared_at` field is populated one time, only after all of the preparation steps
+are completed. It is not updated if more changes are added to the merge request:
+
+- The diff is created.
+- Web hooks are executed.
+- Pipelines are created.
+- Mergeability is checked.
+- Git LFS objects are linked.
+- Notifications are sent.
+
 ## Get single merge request participants
 
 Get a list of merge request participants.
@@ -1102,7 +1120,7 @@ following response attributes:
 | `new_path` | string | New path of the file. |
 | `a_mode` | string | Old file mode of the file. |
 | `b_mode` | string | New file mode of the file. |
-| `diff` | string | Diff representation of the changes made on the file. |
+| `diff` | string | Diff representation of the changes made to the file. |
 | `new_file` | boolean | Indicates if the file has just been added. |
 | `renamed_file` | boolean | Indicates if the file has been renamed. |
 | `deleted_file` | boolean | Indicates if the file has been removed. |
@@ -1353,6 +1371,7 @@ POST /projects/:id/merge_requests
     "web_url": "https://gitlab.com/DouweM"
   },
   "merged_at": "2018-09-07T11:16:17.520Z",
+  "prepared_at": "2018-09-04T11:16:17.520Z",
   "closed_by": null,
   "closed_at": null,
   "latest_build_started_at": "2018-09-07T07:27:38.472Z",
@@ -1524,6 +1543,7 @@ Must include at least one non-required attribute from above.
     "web_url": "https://gitlab.com/DouweM"
   },
   "merged_at": "2018-09-07T11:16:17.520Z",
+  "prepared_at": "2018-09-04T11:16:17.520Z",
   "closed_by": null,
   "closed_at": null,
   "latest_build_started_at": "2018-09-07T07:27:38.472Z",
@@ -1701,6 +1721,7 @@ Supported attributes:
     "web_url": "https://gitlab.com/DouweM"
   },
   "merged_at": "2018-09-07T11:16:17.520Z",
+  "prepared_at": "2018-09-04T11:16:17.520Z",
   "closed_by": null,
   "closed_at": null,
   "latest_build_started_at": "2018-09-07T07:27:38.472Z",
@@ -1902,6 +1923,7 @@ Supported attributes:
     "web_url": "https://gitlab.com/DouweM"
   },
   "merged_at": "2018-09-07T11:16:17.520Z",
+  "prepared_at": "2018-09-04T11:16:17.520Z",
   "closed_by": null,
   "closed_at": null,
   "latest_build_started_at": "2018-09-07T07:27:38.472Z",
@@ -2202,6 +2224,7 @@ Example response:
     "web_url": "https://gitlab.com/DouweM"
   },
   "merged_at": "2018-09-07T11:16:17.520Z",
+  "prepared_at": "2018-09-04T11:16:17.520Z",
   "closed_by": null,
   "closed_at": null,
   "latest_build_started_at": "2018-09-07T07:27:38.472Z",
@@ -2361,6 +2384,7 @@ Example response:
     "web_url": "https://gitlab.com/DouweM"
   },
   "merged_at": "2018-09-07T11:16:17.520Z",
+  "prepared_at": "2018-09-04T11:16:17.520Z",
   "closed_by": null,
   "closed_at": null,
   "latest_build_started_at": "2018-09-07T07:27:38.472Z",
diff --git a/doc/api/namespaces.md b/doc/api/namespaces.md
index 15ce73fdbc3..ddf56209be2 100644
--- a/doc/api/namespaces.md
+++ b/doc/api/namespaces.md
@@ -54,7 +54,8 @@ Example response:
     "billable_members_count": 1,
     "plan": "default",
     "trial_ends_on": null,
-    "trial": false
+    "trial": false,
+    "root_repository_size": 100
   },
   {
     "id": 2,
@@ -69,7 +70,8 @@ Example response:
     "billable_members_count": 2,
     "plan": "default",
     "trial_ends_on": null,
-    "trial": false
+    "trial": false,
+    "root_repository_size": 100
   },
   {
     "id": 3,
@@ -84,7 +86,8 @@ Example response:
     "billable_members_count": 5,
     "plan": "default",
     "trial_ends_on": null,
-    "trial": false
+    "trial": false,
+    "root_repository_size": 100
   }
 ]
 ```
@@ -124,7 +127,7 @@ once a day.
 ```
 
 NOTE:
-Only group owners are presented with `members_count_with_descendants` and `plan`.
+Only group owners are presented with `members_count_with_descendants`, `root_repository_size` and `plan`.
 
 ## Get namespace by ID
 
@@ -162,7 +165,8 @@ Example response:
   "seats_in_use": 0,
   "plan": "default",
   "trial_ends_on": null,
-  "trial": false
+  "trial": false,
+  "root_repository_size": 100
 }
 ```
 
@@ -190,7 +194,8 @@ Example response:
   "seats_in_use": 0,
   "plan": "default",
   "trial_ends_on": null,
-  "trial": false
+  "trial": false,
+  "root_repository_size": 100
 }
 ```
 
diff --git a/doc/api/openapi/openapi_interactive.md b/doc/api/openapi/openapi_interactive.md
index c3e3f5f372b..2185f5b493e 100644
--- a/doc/api/openapi/openapi_interactive.md
+++ b/doc/api/openapi/openapi_interactive.md
@@ -48,3 +48,13 @@ by the server responses that are returned. You can create new responses by editi
 and then select **Execute** once again.
 
 ![API viewer screenshot](img/apiviewer03-fs8.png)
+
+## Vision
+
+The API code is the single source of truth, and the API documentation should be tightly coupled to its implementation. The OpenAPI specification provides a standardized and comprehensive way to document APIs. It should be the go-to format for documenting the GitLab REST API. This will result in more accurate, reliable, and user-friendly documentation that enhances the overall experience of using the GitLab REST API.
+
+To achieve this it should be a requirement to update the OpenAPI specification with every API code change. By doing so, we ensure that the documentation is always up-to-date and accurate, reducing the risk of confusion as well as errors for our users.
+
+The OpenAPI documentation should be autogenerated from the API code, so that it is easy to keep it up to date and accurate. This will save time and effort for our documentation team.
+
+You can follow the current progress of this vision in the [Document the REST API in OpenAPI V2 epic](https://gitlab.com/groups/gitlab-org/-/epics/8926).
diff --git a/doc/api/openapi/openapi_v2.yaml b/doc/api/openapi/openapi_v2.yaml
index 5a99f6c8793..65cc7a20456 100644
--- a/doc/api/openapi/openapi_v2.yaml
+++ b/doc/api/openapi/openapi_v2.yaml
@@ -376,8 +376,6 @@ definitions:
         "$ref": "#/definitions/API_Entities_CustomAttribute"
       web_url:
         type: string
-      is_gitlab_employee:
-        type: string
       email:
         type: string
       requested_at:
diff --git a/doc/api/packages.md b/doc/api/packages.md
index 86eaf3028cf..efb27a29e0f 100644
--- a/doc/api/packages.md
+++ b/doc/api/packages.md
@@ -330,6 +330,74 @@ Example response:
 
 By default, the `GET` request returns 20 results, because the API is [paginated](rest/index.md#pagination).
 
+## List package pipelines
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/341950) in GitLab 16.1.
+
+Get a list of pipelines for a single package. The results are sorted by `id` in descending order.
+
+The results are [paginated](rest/index.md#keyset-based-pagination) and return up to 20 records per page.
+
+```plaintext
+GET /projects/:id/packages/:package_id/pipelines
+```
+
+| Attribute | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `id`      | integer/string | yes | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) |
+| `package_id`      | integer | yes | ID of a package. |
+
+```shell
+curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/:id/packages/:package_id/pipelines"
+```
+
+Example response:
+
+```json
+[
+  {
+    "id": 1,
+    "iid": 1,
+    "project_id": 9,
+    "sha": "2b6127f6bb6f475c4e81afcc2251e3f941e554f9",
+    "ref": "mytag",
+    "status": "failed",
+    "source": "push",
+    "created_at": "2023-02-01T12:19:21.895Z",
+    "updated_at": "2023-02-01T14:00:05.922Z",
+    "web_url": "http://gdk.test:3001/feature-testing/composer-repository/-/pipelines/1",
+    "user": {
+      "id": 1,
+      "username": "root",
+      "name": "Administrator",
+      "state": "active",
+      "avatar_url": "https://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80\u0026d=identicon",
+      "web_url": "http://gdk.test:3001/root"
+    }
+  },
+  {
+    "id": 2,
+    "iid": 2,
+    "project_id": 9,
+    "sha": "e564015ac6cb3d8617647802c875b27d392f72a6",
+    "ref": "master",
+    "status": "canceled",
+    "source": "push",
+    "created_at": "2023-02-01T12:23:23.694Z",
+    "updated_at": "2023-02-01T12:26:28.635Z",
+    "web_url": "http://gdk.test:3001/feature-testing/composer-repository/-/pipelines/2",
+    "user": {
+      "id": 1,
+      "username": "root",
+      "name": "Administrator",
+      "state": "active",
+      "avatar_url": "https://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80\u0026d=identicon",
+      "web_url": "http://gdk.test:3001/root"
+    }
+  }
+]
+```
+
 ## Delete a project package
 
 Deletes a project package.
diff --git a/doc/api/packages/npm.md b/doc/api/packages/npm.md
index bf48fbc8f65..6f4d8446dbf 100644
--- a/doc/api/packages/npm.md
+++ b/doc/api/packages/npm.md
@@ -124,6 +124,7 @@ different scopes:
 
 - Use the instance-level prefix to make requests in the scope of the entire instance.
 - Use the project-level prefix to make requests in a single project's scope.
+- Use the group-level prefix to make requests in a group’s scope.
 
 The examples in this document all use the project-level prefix.
 
@@ -147,6 +148,19 @@ The examples in this document all use the project-level prefix.
 | --------- | ------ | -------- | ----------- |
 | `id`      | string | yes      | The project ID or full project path. |
 
+### Group-level
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/299834) in GitLab 16.0 [with a flag](../../administration/feature_flags.md) named `npm_group_level_endpoints`. Disabled by default.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121837) in GitLab 16.1. Feature flag `npm_group_level_endpoints` removed.
+
+```plaintext
+ /groups/:id/-/packages/npm`
+```
+
+| Attribute | Type   | Required | Description |
+| --------- | ------ | -------- | ----------- |
+| `id`      | string | yes      | The group ID or full group path. |
+
 ## Metadata
 
 Returns the metadata for a given package.
diff --git a/doc/api/packages/nuget.md b/doc/api/packages/nuget.md
index a0761b56645..afe384b5a29 100644
--- a/doc/api/packages/nuget.md
+++ b/doc/api/packages/nuget.md
@@ -158,9 +158,11 @@ The examples in this document all use the project-level prefix.
 
 ## Service Index
 
-> Introduced in GitLab 12.6.
+> - Introduced in GitLab 12.6.
+> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/214674) to be public in GitLab 16.1.
 
-Returns a list of available API resources:
+Returns a list of available API resources.
+Authentication is not required:
 
 ```plaintext
 GET <route-prefix>/index
@@ -169,7 +171,7 @@ GET <route-prefix>/index
 Example Request:
 
 ```shell
-curl --user <username>:<personal_access_token> "https://gitlab.example.com/api/v4/projects/1/packages/nuget/index"
+curl "https://gitlab.example.com/api/v4/projects/1/packages/nuget/index"
 ```
 
 Example response:
@@ -265,13 +267,14 @@ Example response:
           "packageContent": "https://gitlab.example.com/api/v4/projects/1/packages/nuget/download/MyNuGetPkg/1.3.0.17/helloworld.1.3.0.17.nupkg",
           "catalogEntry": {
             "@id": "https://gitlab.example.com/api/v4/projects/1/packages/nuget/metadata/MyNuGetPkg/1.3.0.17.json",
-            "authors": "",
+            "authors": "Author1, Author2",
             "dependencyGroups": [],
             "id": "MyNuGetPkg",
             "version": "1.3.0.17",
             "tags": "",
             "packageContent": "https://gitlab.example.com/api/v4/projects/1/packages/nuget/download/MyNuGetPkg/1.3.0.17/helloworld.1.3.0.17.nupkg",
-            "summary": ""
+            "summary": "Summary of the package",
+            "published": "2023-05-08T17:23:25Z",
           }
         }
       ]
@@ -307,13 +310,14 @@ Example response:
   "packageContent": "https://gitlab.example.com/api/v4/projects/1/packages/nuget/download/MyNuGetPkg/1.3.0.17/helloworld.1.3.0.17.nupkg",
   "catalogEntry": {
     "@id": "https://gitlab.example.com/api/v4/projects/1/packages/nuget/metadata/MyNuGetPkg/1.3.0.17.json",
-    "authors": "",
+    "authors": "Author1, Author2",
     "dependencyGroups": [],
     "id": "MyNuGetPkg",
     "version": "1.3.0.17",
     "tags": "",
     "packageContent": "https://gitlab.example.com/api/v4/projects/1/packages/nuget/download/MyNuGetPkg/1.3.0.17/helloworld.1.3.0.17.nupkg",
-    "summary": ""
+    "summary": "Summary of the package",
+    "published": "2023-05-08T17:23:25Z",
   }
 }
 ```
@@ -347,10 +351,10 @@ Example response:
   "data": [
     {
       "@type": "Package",
-      "authors": "",
+      "authors": "Author1, Author2",
       "id": "MyNuGetPkg",
       "title": "MyNuGetPkg",
-      "summary": "",
+      "summary": "Summary of the package",
       "totalDownloads": 0,
       "verified": true,
       "version": "1.3.0.17",
diff --git a/doc/api/plan_limits.md b/doc/api/plan_limits.md
index f93f246c3f0..53dedca3312 100644
--- a/doc/api/plan_limits.md
+++ b/doc/api/plan_limits.md
@@ -43,8 +43,10 @@ Example response:
   "ci_registered_group_runners": 1000,
   "ci_registered_project_runners": 1000,
   "conan_max_file_size": 3221225472,
+  "enforcement_limit": 10000,
   "generic_packages_max_file_size": 5368709120,
   "helm_max_file_size": 5242880,
+  "notification_limit": 10000,
   "maven_max_file_size": 3221225472,
   "npm_max_file_size": 524288000,
   "nuget_max_file_size": 524288000,
@@ -73,14 +75,16 @@ PUT /application/plan_limits
 | `ci_registered_group_runners`     | integer | no       | Maximum number of runners registered per group. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85895) in GitLab 15.0. |
 | `ci_registered_project_runners`   | integer | no       | Maximum number of runners registered per project. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85895) in GitLab 15.0. |
 | `conan_max_file_size`             | integer | no       | Maximum Conan package file size in bytes. |
+| `enforcement_limit`               | integer | no       | Maximum storage size for root namespace limit enforcement in MiB. |
 | `generic_packages_max_file_size`  | integer | no       | Maximum generic package file size in bytes. |
 | `helm_max_file_size`              | integer | no       | Maximum Helm chart file size in bytes. |
 | `maven_max_file_size`             | integer | no       | Maximum Maven package file size in bytes. |
+| `notification_limit`              | integer | no       | Maximum storage size for root namespace limit notifications in MiB. |
 | `npm_max_file_size`               | integer | no       | Maximum NPM package file size in bytes. |
 | `nuget_max_file_size`             | integer | no       | Maximum NuGet package file size in bytes. |
 | `pypi_max_file_size`              | integer | no       | Maximum PyPI package file size in bytes. |
 | `terraform_module_max_file_size`  | integer | no       | Maximum Terraform Module package file size in bytes. |
-| `storage_size_limit`              | integer | no       | Maximum storage size for the root namespace in megabytes. |
+| `storage_size_limit`              | integer | no       | Maximum storage size for the root namespace in MiB. |
 
 ```shell
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/application/plan_limits?plan_name=default&conan_max_file_size=3221225472"
diff --git a/doc/api/project_import_export.md b/doc/api/project_import_export.md
index a162bc3e5af..fbbefe95cd8 100644
--- a/doc/api/project_import_export.md
+++ b/doc/api/project_import_export.md
@@ -1,6 +1,6 @@
 ---
-stage: Create
-group: Source Code
+stage: Manage
+group: Import and Integrate
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
@@ -13,7 +13,7 @@ Before using the project import and export API, you might want to use the
 
 ## Prerequisites
 
-For information on prerequisites for project import and export API, see:
+For prerequisites for project import and export API, see:
 
 - Prerequisites for [project export](../user/project/settings/import_export.md#export-a-project-and-its-data).
 - Prerequisites for [project import](../user/project/settings/import_export.md#import-a-project-and-its-data).
@@ -32,8 +32,10 @@ project to a web server or to any S3-compatible platform. For exports, GitLab:
   time and is available throughout the export process.
 - Administrators can modify the maximum export file size. By default, the maximum is unlimited (`0`). To change this,
   edit `max_export_size` using either:
-  - [Application settings API](settings.md#change-application-settings)
   - [GitLab UI](../user/admin_area/settings/account_and_limit_settings.md).
+  - [Application settings API](settings.md#change-application-settings)
+- Has a fixed limit for the maximum import file size on GitLab.com. For more information, see
+  [Account and limit settings](../user/gitlab_com/index.md#account-and-limit-settings).
 
 The `upload[url]` parameter is required if the `upload` parameter is present.
 
@@ -205,7 +207,7 @@ As an administrator, you can modify the maximum import file size. To do so, use
 
 ## Import a file from a remote object storage (Beta)
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/282503) in GitLab 13.12 in [Beta](../policy/alpha-beta-support.md#beta) [with a flag](../administration/feature_flags.md) named `import_project_from_remote_file`. Enabled by default.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/282503) in GitLab 13.12 in [Beta](../policy/experiment-beta-support.md#beta) [with a flag](../administration/feature_flags.md) named `import_project_from_remote_file`. Enabled by default.
 
 FLAG:
 On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../administration/feature_flags.md) named `import_project_from_remote_file`.
@@ -446,3 +448,4 @@ GitHub and how many were already imported:
 
 - [Migrating projects using file exports](../user/project/settings/import_export.md).
 - [Project import and export Rake tasks](../administration/raketasks/project_import_export.md).
+- [Group import and export API](group_import_export.md)
diff --git a/doc/api/project_job_token_scopes.md b/doc/api/project_job_token_scopes.md
new file mode 100644
index 00000000000..c73e6ea203e
--- /dev/null
+++ b/doc/api/project_job_token_scopes.md
@@ -0,0 +1,211 @@
+---
+stage: Verify
+group: Pipeline Security
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
+---
+
+# Project CI/CD job token scope API **(FREE)**
+
+You can read more about the [CI/CD job token](../ci/jobs/ci_job_token.md)
+
+NOTE:
+All requests to the CI/CD job token scope API endpoint must be [authenticated](rest/index.md#authentication).
+The authenticated user must have at least the Maintainer role for the project.
+
+## Get a project's CI/CD job token access settings
+
+Fetch the [CI/CD job token access settings](../ci/jobs/ci_job_token.md#configure-cicd-job-token-access) (job token scope) of a project.
+
+```plaintext
+GET /projects/:id/job_token_scope
+```
+
+Supported attributes:
+
+| Attribute | Type           | Required               | Description |
+|-----------|----------------|------------------------|-------------|
+| `id`      | integer/string | **{check-circle}** Yes | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) owned by the authenticated user. |
+
+If successful, returns [`200`](rest/index.md#status-codes) and the following response attributes:
+
+| Attribute          | Type    | Description           |
+|:-------------------|:--------|:----------------------|
+| `inbound_enabled`  | boolean | Indicates if the CI/CD job token generated in other projects has access to this project. |
+| `outbound_enabled` | boolean | Indicates if the CI/CD job token generated in this project has access to other projects. [Deprecated and planned for removal in GitLab 17.0 .](../update/removals.md#limit-ci_job_token-scope-is-disabled) |
+
+Example request:
+
+```shell
+curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/job_token_scope"
+```
+
+Example response:
+
+```json
+{
+  "inbound_enabled": true,
+  "outbound_enabled": false
+}
+```
+
+## Patch a project's CI/CD job token access settings
+
+Patch the [**Allow access to this project with a CI_JOB_TOKEN** setting](../ci/jobs/ci_job_token.md#disable-the-job-token-scope-allowlist) (job token scope) of a project.
+
+```plaintext
+PATCH /projects/:id/job_token_scope
+```
+
+Supported attributes:
+
+| Attribute | Type           | Required               | Description |
+|-----------|----------------|------------------------|-------------|
+| `id`      | integer/string | **{check-circle}** Yes | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) owned by the authenticated user. |
+| `enabled` | boolean        | **{check-circle}** Yes | Indicates CI/CD job tokens generated in other projects have restricted access to this project. |
+
+If successful, returns [`204`](rest/index.md#status-codes) and no response body.
+
+Example request:
+
+```shell
+curl --request PATCH \
+  --url "https://gitlab.example.com/api/v4/projects/1/job_token_scope" \
+  --header 'PRIVATE-TOKEN: <your_access_token>' \
+  --header 'Content-Type: application/json' \
+  --data '{ "enabled": false }'
+```
+
+## Get a project's CI/CD job token inbound allowlist
+
+Fetch the [CI/CD job token inbound allowlist](../ci/jobs/ci_job_token.md#allow-access-to-your-project-with-a-job-token) (job token scope) of a project.
+
+```plaintext
+GET /projects/:id/job_token_scope/allowlist
+```
+
+Supported attributes:
+
+| Attribute | Type           | Required               | Description |
+|-----------|----------------|------------------------|-------------|
+| `id`      | integer/string | **{check-circle}** Yes | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) owned by the authenticated user. |
+
+This endpoint supports [offset-based pagination](rest/index.md#offset-based-pagination).
+
+If successful, returns [`200`](rest/index.md#status-codes) and a list of project with limited fields for each project.
+
+Example request:
+
+```shell
+curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/job_token_scope/allowlist"
+```
+
+Example response:
+
+```json
+[
+  {
+    "id": 4,
+    "description": null,
+    "name": "Diaspora Client",
+    "name_with_namespace": "Diaspora / Diaspora Client",
+    "path": "diaspora-client",
+    "path_with_namespace": "diaspora/diaspora-client",
+    "created_at": "2013-09-30T13:46:02Z",
+    "default_branch": "main",
+    "tag_list": [
+      "example",
+      "disapora client"
+    ],
+    "topics": [
+      "example",
+      "disapora client"
+    ],
+    "ssh_url_to_repo": "git@gitlab.example.com:diaspora/diaspora-client.git",
+    "http_url_to_repo": "https://gitlab.example.com/diaspora/diaspora-client.git",
+    "web_url": "https://gitlab.example.com/diaspora/diaspora-client",
+    "avatar_url": "https://gitlab.example.com/uploads/project/avatar/4/uploads/avatar.png",
+    "star_count": 0,
+    "last_activity_at": "2013-09-30T13:46:02Z",
+    "namespace": {
+      "id": 2,
+      "name": "Diaspora",
+      "path": "diaspora",
+      "kind": "group",
+      "full_path": "diaspora",
+      "parent_id": null,
+      "avatar_url": null,
+      "web_url": "https://gitlab.example.com/diaspora"
+    }
+  },
+  {
+    ...
+  }
+```
+
+## Create a new project to a project's CI/CD job token inbound allowlist
+
+Add a project to the [CI/CD job token inbound allowlist](../ci/jobs/ci_job_token.md#allow-access-to-your-project-with-a-job-token) of a project.
+
+```plaintext
+POST /projects/:id/job_token_scope/allowlist
+```
+
+Supported attributes:
+
+| Attribute           | Type           | Required               | Description |
+|---------------------|----------------|------------------------|-------------|
+| `id`                | integer/string | **{check-circle}** Yes | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) owned by the authenticated user. |
+| `target_project_id` | integer        | **{check-circle}** Yes | The ID of the project added to the CI/CD job token inbound allowlist. |
+
+If successful, returns [`201`](rest/index.md#status-codes) and the following response attributes:
+
+| Attribute           | Type    | Description           |
+|:--------------------|:--------|:----------------------|
+| `source_project_id` | integer | The ID of the project whose CI/CD job token inbound allowlist is added to. |
+| `target_project_id` | integer | The ID of the project that is added to the inbound allowlist of the source project. |
+
+Example request:
+
+```shell
+curl --request PATCH \
+  --url "https://gitlab.example.com/api/v4/projects/1/job_token_scope" \
+  --header 'PRIVATE-TOKEN: <your_access_token>' \
+  --header 'Content-Type: application/json' \
+  --data '{ "target_project_id": 2 }'
+```
+
+Example response:
+
+```json
+{
+  "source_project_id": 1,
+  "target_project_id": 2
+}
+```
+
+## Remove a project from a project's CI/CD job token inbound allowlist
+
+Remove a project from the [CI/CD job token inbound allowlist](../ci/jobs/ci_job_token.md#allow-access-to-your-project-with-a-job-token) of a project.
+
+```plaintext
+DELETE /projects/:id/job_token_scope/allowlist/:target_project_id
+```
+
+Supported attributes:
+
+| Attribute           | Type           | Required               | Description |
+|---------------------|----------------|------------------------|-------------|
+| `id`                | integer/string | **{check-circle}** Yes | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding) owned by the authenticated user. |
+| `target_project_id` | integer        | **{check-circle}** Yes | The ID of the project that is removed from the CI/CD job token inbound allowlist. |
+
+If successful, returns [`204`](rest/index.md#status-codes) and no response body.
+
+Example request:
+
+```shell
+
+curl --request DELETE \
+  --url "https://gitlab.example.com/api/v4/projects/1/job_token_scope/allowlist/2" \
+  --header 'PRIVATE-TOKEN: <your_access_token>' \
+  --header 'Content-Type: application/json'
+```
diff --git a/doc/api/project_relations_export.md b/doc/api/project_relations_export.md
index 835a53c7ecc..1fef2722bb8 100644
--- a/doc/api/project_relations_export.md
+++ b/doc/api/project_relations_export.md
@@ -4,22 +4,17 @@ group: Import and Integrate
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Project Relations Export API **(FREE)**
+# Project relations export API **(FREE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/70330) in GitLab 14.4 behind the `bulk_import` [feature flag](../administration/feature_flags.md), disabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/70330) in GitLab 14.4 behind the `bulk_import` [feature flag](../administration/feature_flags.md), disabled by default.
+> - New application setting `bulk_import_enabled` introduced in GitLab 15.8. `bulk_import` feature flag removed.
 
-FLAG:
-On GitLab.com, this feature is available.
-On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to
-[disable the `bulk_import` flag](../administration/feature_flags.md).
-The feature is not ready for production use. It is still in experimental stage and might change in the future.
+The project relations export API partially exports a project's structure as separate files for each top-level
+relation (for example, milestones, issues, and labels).
 
-With the Project Relations Export API, you can partially export project structure. This API is
-similar to [project export](project_import_export.md),
-but it exports each top-level relation (for example, milestones/boards/labels) as a separate file
-instead of one archive. The project relations export API is primarily used in
-[group migration](../user/group/import/index.md)
-to support group project import.
+The project relations export API is primarily used in
+[group migration](../user/group/import/index.md#migrate-groups-by-direct-transfer-recommended) can't be used with the
+[project import and export API](project_import_export.md).
 
 ## Schedule new export
 
@@ -109,3 +104,7 @@ curl --header "PRIVATE-TOKEN: <your_access_token>" --remote-header-name \
 ls labels.ndjson.gz
 labels.ndjson.gz
 ```
+
+## Related topics
+
+- [Group relations export API](group_relations_export.md)
diff --git a/doc/api/projects.md b/doc/api/projects.md
index e0f49c26e69..5547546e6cc 100644
--- a/doc/api/projects.md
+++ b/doc/api/projects.md
@@ -695,7 +695,7 @@ Example response:
       "storage_size": 1038090,
       "repository_size": 1038090,
       "lfs_objects_size": 0,
-      "job_artifacts_size": 0
+      "job_artifacts_size": 0,
       "pipeline_artifacts_size": 0,
       "packages_size": 0,
       "snippets_size": 0,
@@ -815,7 +815,7 @@ Example response:
       "storage_size": 2066080,
       "repository_size": 2066080,
       "lfs_objects_size": 0,
-      "job_artifacts_size": 0
+      "job_artifacts_size": 0,
       "pipeline_artifacts_size": 0,
       "packages_size": 0,
       "snippets_size": 0,
@@ -2207,6 +2207,8 @@ Example response:
 
 ## Delete project
 
+> The default behavior of [Delayed project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6 was changed to [Immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2.
+
 This endpoint:
 
 - Deletes a project including all associated resources (including issues and
@@ -2215,20 +2217,16 @@ This endpoint:
   [Premium or Ultimate](https://about.gitlab.com/pricing/) tiers,
   [delayed project deletion](../user/project/settings/index.md#delayed-project-deletion)
   is applied if enabled.
-- From [GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) on
-  [Premium or Ultimate](https://about.gitlab.com/pricing/) tiers, group
-  administrators can [configure](../user/group/manage.md#enable-delayed-project-deletion)
-  projects within a group to be deleted after a delayed period. When enabled,
-  actual deletion happens after the number of days specified in the
-  [default deletion delay](../user/admin_area/settings/visibility_and_access_controls.md#deletion-protection).
 - From [GitLab 15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/396500) on
   [Premium or Ultimate](https://about.gitlab.com/pricing/) tiers, deletes a project immediately if the project is already
   marked for deletion, and the `permanently_remove` and `full_path` parameters are passed.
+- From [GitLab 16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) on
+  [Premium or Ultimate](https://about.gitlab.com/pricing/) tiers, delayed project deletion is enabled by default.
+  The deletion happens after the number of days specified in the
+  [default deletion delay](../user/admin_area/settings/visibility_and_access_controls.md#deletion-protection).
 
 WARNING:
-The default behavior of [Delayed Project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935)
-in GitLab 12.6 was changed to [Immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382)
-in GitLab 13.2, as discussed in [Enable delayed project deletion](../user/group/manage.md#enable-delayed-project-deletion).
+The option to delete projects immediately from deletion protection settings in the Admin Area was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/389557) in GitLab 15.9 and removed in GitLab 16.0.
 
 ```plaintext
 DELETE /projects/:id
diff --git a/doc/api/protected_branches.md b/doc/api/protected_branches.md
index d3091cb1e15..4a82fab125d 100644
--- a/doc/api/protected_branches.md
+++ b/doc/api/protected_branches.md
@@ -21,7 +21,9 @@ The access levels are defined in the `ProtectedRefAccess.allowed_access_levels`
 
 > Deploy key information [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116846) in GitLab 16.0.
 
-Gets a list of protected branches from a project as they are defined [in the UI](../user/project/protected_branches.md#configure-a-protected-branch). If a wildcard is set, it is returned instead of the exact name of the branches that match that wildcard.
+Gets a list of [protected branches](../user/project/protected_branches.md) from a project
+as they are defined in the UI. If a wildcard is set, it is returned instead of the exact name
+of the branches that match that wildcard.
 
 ```plaintext
 GET /projects/:id/protected_branches
diff --git a/doc/api/rest/deprecations.md b/doc/api/rest/deprecations.md
index db9b590606f..20fa999516e 100644
--- a/doc/api/rest/deprecations.md
+++ b/doc/api/rest/deprecations.md
@@ -26,7 +26,7 @@ Breaking change. [Related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/3
 
 The `merged_by` field in the [merge request API](../merge_requests.md#list-merge-requests)
 has been deprecated in favor of the `merge_user` field which more correctly identifies who merged a merge request when
-performing actions (merge when pipeline succeeds, add to merge train) other than a simple merge.
+performing actions (set to auto-merge, add to merge train) other than a simple merge.
 
 API users are encouraged to use the new `merge_user` field instead. The `merged_by` field will be removed in v5 of the GitLab REST API.
 
diff --git a/doc/api/rest/index.md b/doc/api/rest/index.md
index 0bee7168cfb..947142e3a50 100644
--- a/doc/api/rest/index.md
+++ b/doc/api/rest/index.md
@@ -208,7 +208,7 @@ By default, impersonation is enabled. To disable impersonation:
    gitlab_rails['impersonation_enabled'] = false
    ```
 
-1. Save the file, and then [reconfigure](../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file, and then [reconfigure](../../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
    GitLab for the changes to take effect.
 
 To re-enable impersonation, remove this configuration, and then reconfigure
@@ -325,6 +325,7 @@ The following table shows the possible return codes for API requests.
 | `422 Unprocessable`       | The entity couldn't be processed.                                                                                                                        |
 | `429 Too Many Requests`   | The user exceeded the [application rate limits](../../administration/instance_limits.md#rate-limits).                                                    |
 | `500 Server Error`        | While handling the request, something went wrong on the server.                                                                                          |
+| `503 Service Unavailable` | The server cannot handle the request because the server is temporarily overloaded.                                                                               |
 
 ## Pagination
 
@@ -485,14 +486,15 @@ pagination headers.
 Keyset-based pagination is supported only for selected resources and ordering
 options:
 
-| Resource                                                          | Options                          | Availability                                                                                                  |
-|:------------------------------------------------------------------|:---------------------------------|:--------------------------------------------------------------------------------------------------------------|
-| [Group audit events](../audit_events.md#group-audit-events)       | `order_by=id`, `sort=desc` only  | Authenticated users only ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/333968) in GitLab 15.2)  |
-| [Groups](../groups.md)                                            | `order_by=name`, `sort=asc` only | Unauthenticated users only                                                                                    |
-| [Instance audit events](../audit_events.md#instance-audit-events) | `order_by=id`, `sort=desc` only  | Authenticated users only ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367528) in GitLab 15.11) |
-| [Jobs](../jobs.md)                                                | `order_by=id`, `sort=desc` only  | Authenticated users only ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/362172) in GitLab 15.9)  |
-| [Project audit events](../audit_events.md#project-audit-events)   | `order_by=id`, `sort=desc` only  | Authenticated users only ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367528) in GitLab 15.10) |
-| [Projects](../projects.md)                                        | `order_by=id` only               | Authenticated and unauthenticated users                                                                       |
+| Resource                                                                       | Options                          | Availability                             |
+|:-------------------------------------------------------------------------------|:---------------------------------|:-----------------------------------------|
+| [Group audit events](../audit_events.md#retrieve-all-group-audit-events)       | `order_by=id`, `sort=desc` only  | Authenticated users only.                |
+| [Groups](../groups.md#list-groups)                                             | `order_by=name`, `sort=asc` only | Unauthenticated users only.              |
+| [Instance audit events](../audit_events.md#retrieve-all-instance-audit-events) | `order_by=id`, `sort=desc` only  | Authenticated users only.                |
+| [Package pipelines](../packages.md#list-package-pipelines)                     | `order_by=id`, `sort=desc` only  | Authenticated users only.                |
+| [Project jobs](../jobs.md#list-project-jobs)                                   | `order_by=id`, `sort=desc` only  | Authenticated users only.                |
+| [Project audit events](../audit_events.md#retrieve-all-project-audit-events)   | `order_by=id`, `sort=desc` only  | Authenticated users only.                |
+| [Projects](../projects.md)                                                     | `order_by=id` only               | Authenticated and unauthenticated users. |
 
 ### Pagination response headers
 
diff --git a/doc/api/runners.md b/doc/api/runners.md
index a2614b95bb9..574bce82793 100644
--- a/doc/api/runners.md
+++ b/doc/api/runners.md
@@ -23,7 +23,7 @@ There are two tokens to take into account when connecting a runner with GitLab.
 | Token | Description |
 | ----- | ----------- |
 | Registration token | Token used to [register the runner](https://docs.gitlab.com/runner/register/). It can be [obtained through GitLab](../ci/runners/index.md). |
-| Authentication token | Token used to authenticate the runner with the GitLab instance. It is obtained automatically when you [register a runner](https://docs.gitlab.com/runner/register/) or by the Runner API when you manually [register a runner](#register-a-new-runner) or [reset the authentication token](#reset-runners-authentication-token-by-using-the-runner-id). |
+| Authentication token | Token used to authenticate the runner with the GitLab instance. It is obtained automatically when you [register a runner](https://docs.gitlab.com/runner/register/) or by the Runner API when you manually [register a runner](#register-a-new-runner) or [reset the authentication token](#reset-runners-authentication-token-by-using-the-runner-id). You can also obtain the authentication token using [Create a runner](users.md#create-a-runner) API method. |
 
 Here's an example of how the two tokens are used in runner registration:
 
diff --git a/doc/api/saml.md b/doc/api/saml.md
index 6b2e7cffaab..b1d7692fbaf 100644
--- a/doc/api/saml.md
+++ b/doc/api/saml.md
@@ -22,7 +22,7 @@ Supported attributes:
 
 | Attribute         | Type    | Required | Description           |
 |:------------------|:--------|:---------|:----------------------|
-| `id`              | integer | Yes      | Group ID for the group to return SAML identities. |
+| `id`              | integer/string | yes      | The ID or [URL-encoded path of the group](rest/index.md#namespaced-path-encoding) |
 
 If successful, returns [`200`](rest/index.md#status-codes) and the following
 response attributes:
@@ -49,6 +49,36 @@ Example response:
 ]
 ```
 
+## Get a single SAML identity
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123591) in GitLab 16.1.
+
+```plaintext
+GET /groups/:id/saml/:uid
+```
+
+Supported attributes:
+
+| Attribute | Type           | Required | Description               |
+| --------- | -------------- | -------- | ------------------------- |
+| `id`      | integer/string | yes      | The ID or [URL-encoded path of the group](rest/index.md#namespaced-path-encoding) |
+| `uid`     | string         | yes      | External UID of the user. |
+
+Example request:
+
+```shell
+curl --location --request GET "https://gitlab.example.com/api/v4/groups/33/saml/sydney_jones" --header "<PRIVATE TOKEN>"
+```
+
+Example response:
+
+```json
+{
+    "extern_uid": "4",
+    "user_id": 48
+}
+```
+
 ## Update `extern_uid` field for a SAML identity
 
 Update `extern_uid` field for a SAML identity:
@@ -58,13 +88,14 @@ Update `extern_uid` field for a SAML identity:
 | `id/externalId`    | `extern_uid` |
 
 ```plaintext
-PATCH groups/:groups_id/saml/:uid
+PATCH /groups/:id/saml/:uid
 ```
 
-Parameters:
+Supported attributes:
 
 | Attribute | Type   | Required | Description               |
 | --------- | ------ | -------- | ------------------------- |
+| `id`      | integer/string | yes      | The ID or [URL-encoded path of the group](rest/index.md#namespaced-path-encoding) |
 | `uid`     | string | yes      | External UID of the user. |
 
 Example request:
diff --git a/doc/api/scim.md b/doc/api/scim.md
index 6e022afb2f5..df0d90756d2 100644
--- a/doc/api/scim.md
+++ b/doc/api/scim.md
@@ -28,7 +28,7 @@ Supported attributes:
 
 | Attribute         | Type    | Required | Description           |
 |:------------------|:--------|:---------|:----------------------|
-| `id`              | integer | Yes      | Return SCIM identities for the given group ID. |
+| `id`      | integer/string | Yes      | The ID or [URL-encoded path of the group](rest/index.md#namespaced-path-encoding) |
 
 If successful, returns [`200`](rest/index.md#status-codes) and the following
 response attributes:
@@ -58,6 +58,37 @@ curl --location --request GET "https://gitlab.example.com/api/v4/groups/33/scim/
 --header "PRIVATE-TOKEN: <PRIVATE-TOKEN>"
 ```
 
+## Get a single SCIM identity
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123591) in GitLab 16.1.
+
+```plaintext
+GET /groups/:id/scim/:uid
+```
+
+Supported attributes:
+
+| Attribute | Type    | Required | Description               |
+| --------- | ------- | -------- | ------------------------- |
+| `id`      | integer | yes      | The ID or [URL-encoded path of the group](rest/index.md#namespaced-path-encoding) |
+| `uid`     | string  | yes      | External UID of the user. |
+
+Example request:
+
+```shell
+curl --location --request GET "https://gitlab.example.com/api/v4/groups/33/scim/sydney_jones" --header "<PRIVATE TOKEN>"
+```
+
+Example response:
+
+```json
+{
+    "extern_uid": "4",
+    "user_id": 48,
+    "active": true
+}
+```
+
 ## Update `extern_uid` field for a SCIM identity
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/227841) in GitLab 15.5.
@@ -76,6 +107,7 @@ Parameters:
 
 | Attribute | Type   | Required | Description               |
 | --------- | ------ | -------- | ------------------------- |
+| `id`      | integer/string | yes      | The ID or [URL-encoded path of the group](rest/index.md#namespaced-path-encoding) |
 | `uid`     | string | yes      | External UID of the user. |
 
 Example request:
diff --git a/doc/api/search_admin.md b/doc/api/search_admin.md
new file mode 100644
index 00000000000..9e1aa1a4439
--- /dev/null
+++ b/doc/api/search_admin.md
@@ -0,0 +1,125 @@
+---
+stage: Data Stores
+group: Global Search
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Search admin API **(PREMIUM SELF)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120751) in GitLab 16.1
+
+The search admin API returns information about [advanced search migrations](../integration/advanced_search/elasticsearch.md#advanced-search-migrations).
+
+You must have administrator access to use this API.
+
+## List all advanced search migrations
+
+Get a list of all advanced search migrations for the GitLab instance.
+
+```plaintext
+GET /admin/search/migrations
+```
+
+Example request:
+
+```shell
+curl --header "PRIVATE-TOKEN: <your_access_token>" "https://primary.example.com/api/v4/admin/search/migrations"
+```
+
+Example response:
+
+```json
+[
+  {
+    "version": 20230427555555,
+    "name": "BackfillHiddenOnMergeRequests",
+    "started_at": "2023-05-12T01:35:05.469+00:00",
+    "completed_at": "2023-05-12T01:36:06.432+00:00",
+    "completed": true,
+    "obsolete": false,
+    "migration_state": {}
+  },
+  {
+    "version": 20230428500000,
+    "name": "AddSuffixProjectInWikiRid",
+    "started_at": "2023-05-04T18:59:43.542+00:00",
+    "completed_at": "2023-05-04T18:59:43.542+00:00",
+    "completed": false,
+    "obsolete": false,
+    "migration_state": {
+      "pause_indexing": true,
+      "slice": 1,
+      "task_id": null,
+      "max_slices": 5,
+      "retry_attempt": 0
+    }
+  },
+  {
+    "version": 20230503064300,
+    "name": "BackfillProjectPermissionsInBlobsUsingPermutations",
+    "started_at": "2023-05-03T16:04:44.074+00:00",
+    "completed_at": "2023-05-03T16:04:44.074+00:00",
+    "completed": true,
+    "obsolete": false,
+    "migration_state": {
+      "permutation_idx": 8,
+      "documents_remaining": 5,
+      "task_id": "I2_LXc-xQlOeu-KmjYpM8g:172820",
+      "documents_remaining_for_permutation": 0
+    }
+  }
+]
+```
+
+## Get an advanced search migration
+
+Get a single advanced search migration by providing the migration version or name.
+
+```plaintext
+GET /admin/search/mirations/:version_or_name
+```
+
+Parameters:
+
+| Attribute         | Type           | Required | Description                          |
+|-------------------|----------------|----------|--------------------------------------|
+| `version_or_name` | integer/string | Yes      | The version or name of the migration. |
+
+Example request:
+
+```shell
+curl --header "PRIVATE-TOKEN: <your_access_token>" "https://primary.example.com/api/v4/admin/search/mirations/20230503064300"
+curl --header "PRIVATE-TOKEN: <your_access_token>" "https://primary.example.com/api/v4/admin/search/mirations/BackfillProjectPermissionsInBlobsUsingPermutations"
+```
+
+If successful, returns [`200`](rest/index.md#status-codes) and the following
+response attributes:
+
+| Attribute         | Type     | Description                                           |
+|:------------------|:---------|:------------------------------------------------------|
+| `version`         | integer  | Version of the migration.                             |
+| `name`            | string   | Name of the migration.                                |
+| `started_at`      | datetime | Start date for the migration.                         |
+| `completed_at`    | datetime | Completion date for the migration.                    |
+| `completed`       | boolean  | If `true`, the migration is completed.                |
+| `obsolete`        | boolean  | If `true`, the migration has been marked as obsolete. |
+| `migration_state` | object   | Stored migration state.                               |
+
+Example response:
+
+```json
+{
+  "version": 20230503064300,
+  "name": "BackfillProjectPermissionsInBlobsUsingPermutations",
+  "started_at": "2023-05-03T16:04:44.074+00:00",
+  "completed_at": "2023-05-03T16:04:44.074+00:00",
+  "completed": true,
+  "obsolete": false,
+  "migration_state": {
+    "permutation_idx": 8,
+    "documents_remaining": 5,
+    "task_id": "I2_LXc-xQlOeu-KmjYpM8g:172820",
+    "documents_remaining_for_permutation": 0
+  }
+}
+```
diff --git a/doc/api/settings.md b/doc/api/settings.md
index c7ba93d310e..ab78b9b7c74 100644
--- a/doc/api/settings.md
+++ b/doc/api/settings.md
@@ -67,6 +67,8 @@ Example response:
   "repository_storages_weighted": {"default": 100},
   "plantuml_enabled": false,
   "plantuml_url": null,
+  "diagramsnet_enabled": true,
+  "diagramsnet_url": "https://embed.diagrams.net",
   "kroki_enabled": false,
   "kroki_url": null,
   "terminal_max_session_time": 0,
@@ -193,6 +195,8 @@ Example response:
   "repository_storages": ["default"],
   "plantuml_enabled": false,
   "plantuml_url": null,
+  "diagramsnet_enabled": true,
+  "diagramsnet_url": "https://embed.diagrams.net",
   "terminal_max_session_time": 0,
   "polling_interval_multiplier": 1.0,
   "rsa_key_restriction": 0,
@@ -325,6 +329,8 @@ listed in the descriptions of the relevant settings.
 | `delayed_group_deletion` **(PREMIUM SELF)**   | boolean     | no                                   | Enable delayed group deletion. Default is `true`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/352959) in GitLab 15.0. [From GitLab 15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/352960), disables and locks the group-level setting for delayed protect deletion when set to `false`. From [GitLab 15.11](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113332), with the `always_perform_delayed_deletion` feature flag enabled, this attribute has been removed. This attribute will be completely removed in GitLab 16.0. |
 | `default_project_deletion_protection` **(PREMIUM SELF)** | boolean | no                            | Enable default project deletion protection so only administrators can delete projects. Default is `false`. |
 | `deletion_adjourned_period` **(PREMIUM SELF)** | integer    | no                                   | The number of days to wait before deleting a project or group that is marked for deletion. Value must be between `1` and `90`. Defaults to `7`. [From GitLab 15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/352960), a hook on `deletion_adjourned_period` sets the period to `1` on every update, and sets both `delayed_project_deletion` and `delayed_group_deletion` to `false` if the period is `0`. |
+| `diagramsnet_enabled`                       | boolean          | no                                   | (If enabled, requires `diagramsnet_url`) Enable [Diagrams.net integration](../administration/integration/diagrams_net.md). Default is `true`. |
+| `diagramsnet_url`                           | string           | required by: `diagramsnet_enabled`      | The Diagrams.net instance URL for integration. |
 | `diff_max_patch_bytes`                   | integer          | no                                   | Maximum [diff patch size](../user/admin_area/diff_limits.md), in bytes. |
 | `diff_max_files`                         | integer          | no                                   | Maximum [files in a diff](../user/admin_area/diff_limits.md). |
 | `diff_max_lines`                         | integer          | no                                   | Maximum [lines in a diff](../user/admin_area/diff_limits.md). |
@@ -419,7 +425,7 @@ listed in the descriptions of the relevant settings.
 | `max_export_size`                        | integer          | no                                   | Maximum export size in MB. 0 for unlimited. Default = 0 (unlimited). |
 | `max_import_size`                        | integer          | no                                   | Maximum import size in MB. 0 for unlimited. Default = 0 (unlimited). [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50 MB to 0 in GitLab 13.8. |
 | `max_pages_size`                         | integer          | no                                   | Maximum size of pages repositories in MB. |
-| `max_personal_access_token_lifetime` **(ULTIMATE SELF)** | integer | no                                   | Maximum allowable lifetime for access tokens in days. |
+| `max_personal_access_token_lifetime` **(ULTIMATE SELF)** | integer | no                                   | Maximum allowable lifetime for access tokens in days. When left blank, default value of 365 is applied. When set, value must be 365 or less. When changed, existing access tokens with an expiration date beyond the maximum allowable lifetime are revoked.|
 | `max_ssh_key_lifetime` **(ULTIMATE SELF)** | integer        | no                                   | Maximum allowable lifetime for SSH keys in days. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1007) in GitLab 14.6. |
 | `max_terraform_state_size_bytes`         | integer | no                                         | Maximum size in bytes of the [Terraform state](../administration/terraform_state.md) files. Set this to 0 for unlimited file size. |
 | `metrics_method_call_threshold`          | integer          | no                                   | A method call is only tracked when it takes longer than the given amount of milliseconds. |
@@ -455,10 +461,10 @@ listed in the descriptions of the relevant settings.
 | `projects_api_rate_limit_unauthenticated`      | integer          | no                                   | [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112283) in GitLab 15.10. Max number of requests per 10 minutes per IP address for unauthenticated requests to the [list all projects API](projects.md#list-all-projects). Default: 400. To disable throttling set to 0.|
 | `prometheus_metrics_enabled`             | boolean          | no                                   | Enable Prometheus metrics. |
 | `protected_ci_variables`                 | boolean          | no                                   | CI/CD variables are protected by default. |
-| `push_event_activities_limit`            | integer          | no                                   | Number of changes (branches or tags) in a single push to determine whether individual push events or bulk push events are created. [Bulk push events are created](../user/admin_area/settings/push_event_activities_limit.md) if it surpasses that value. |
-| `push_event_hooks_limit`                 | integer          | no                                   | Number of changes (branches or tags) in a single push to determine whether webhooks and services fire or not. Webhooks and services aren't submitted if it surpasses that value. |
+| `push_event_activities_limit`            | integer          | no                                   | Maximum number of changes (branches or tags) in a single push above which a [bulk push event is created](../user/admin_area/settings/push_event_activities_limit.md). Setting to `0` does not disable throttling. |
+| `push_event_hooks_limit`                 | integer          | no                                   | Maximum number of changes (branches or tags) in a single push above which webhooks and integrations are not triggered. Setting to `0` does not disable throttling. |
 | `rate_limiting_response_text`            | string           | no                                   | When rate limiting is enabled via the `throttle_*` settings, send this plain text response when a rate limit is exceeded. 'Retry later' is sent if this is blank. |
-| `raw_blob_request_limit`                 | integer          | no                                   | Max number of requests per minute for each raw path. Default: 300. To disable throttling set to 0.|
+| `raw_blob_request_limit`                 | integer          | no                                   | Maximum number of requests per minute for each raw path (default is `300`). Set to `0` to disable throttling.|
 | `user_email_lookup_limit`                | integer          | no                                   | **{warning}** **[Deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80631/)** in GitLab 14.9 will be removed in 15.0. Replaced by `search_rate_limit`. Max number of requests per minute for email lookup. Default: 60. To disable throttling set to 0.|
 | `search_rate_limit`                      | integer          | no                                   | Max number of requests per minute for performing a search while authenticated. Default: 30. To disable throttling set to 0.|
 | `search_rate_limit_unauthenticated`      | integer          | no                                   | Max number of requests per minute for performing a search while unauthenticated. Default: 10. To disable throttling set to 0.|
@@ -477,7 +483,7 @@ listed in the descriptions of the relevant settings.
 | `session_expire_delay`                   | integer          | no                                   | Session duration in minutes. GitLab restart is required to apply changes. |
 | `security_policy_global_group_approvers_enabled` | boolean  | no                                   | Whether to look up scan result policy approval groups globally or within project hierarchies. |
 | `shared_runners_enabled`                 | boolean          | no                                   | (**If enabled, requires:** `shared_runners_text` and `shared_runners_minutes`) Enable shared runners for new projects. |
-| `shared_runners_minutes` **(PREMIUM)**   | integer          | required by: `shared_runners_enabled` | Set the maximum number of CI/CD minutes that a group can use on shared runners per month. |
+| `shared_runners_minutes` **(PREMIUM)**   | integer          | required by: `shared_runners_enabled` | Set the maximum number of units of compute that a group can use on shared runners per month. |
 | `shared_runners_text`                    | string           | required by: `shared_runners_enabled` | Shared runners text. |
 | `sidekiq_job_limiter_mode` | string | no | `track` or `compress`. Sets the behavior for [Sidekiq job size limits](../user/admin_area/settings/sidekiq_job_limits.md). Default: 'compress'. |
 | `sidekiq_job_limiter_compression_threshold_bytes` | integer | no | The threshold in bytes at which Sidekiq jobs are compressed before being stored in Redis. Default: 100,000 bytes (100 KB). |
diff --git a/doc/api/system_hooks.md b/doc/api/system_hooks.md
index 720ae457f37..14a078ff68d 100644
--- a/doc/api/system_hooks.md
+++ b/doc/api/system_hooks.md
@@ -10,7 +10,8 @@ All methods require administrator authorization.
 
 You can configure the URL endpoint of the system hooks from the GitLab user interface:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. Select **System Hooks** (`/admin/hooks`).
 
 Read more about [system hooks](../administration/system_hooks.md).
diff --git a/doc/api/usage_data.md b/doc/api/usage_data.md
index bf8924c1578..1a2c3e95002 100644
--- a/doc/api/usage_data.md
+++ b/doc/api/usage_data.md
@@ -7,7 +7,7 @@ type: reference, api
 
 # Service Data API **(FREE SELF)**
 
-The Service Data API is associated with [Service Ping](../development/service_ping/index.md).
+The Service Data API is associated with [Service Ping](../development/internal_analytics/service_ping/index.md).
 
 ## Export metric definitions as a single YAML file
 
diff --git a/doc/api/users.md b/doc/api/users.md
index a2293090209..7b418e7a08b 100644
--- a/doc/api/users.md
+++ b/doc/api/users.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Users API **(FREE)**
 
-This documentation has information on API calls, parameters and responses for the Users API. 
+This documentation has information on API calls, parameters and responses for the Users API.
 
 For information on user activities that update the user event timestamps, see [get user activities](#get-user-activities).
 
@@ -115,6 +115,7 @@ GET /users?without_project_bots=true
 
 > - The `namespace_id` field in the response was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82045) in GitLab 14.10.
 > - The `created_by` field in the response was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/93092) in GitLab 15.6.
+> - The `scim_identities` field in the response [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/324247) in GitLab 16.1.
 
 ```plaintext
 GET /users
@@ -128,6 +129,7 @@ GET /users
 | `without_projects` | boolean | no       | Filter users without projects. Default is `false`, which means that all users are returned, with and without projects. |
 | `admins`           | boolean | no       | Return only administrators. Default is `false`                                 |
 | `saml_provider_id` **(PREMIUM)** | number | no     | Return only users created by the specified SAML provider ID. If not included, it returns all users. |
+| `skip_ldap` **(PREMIUM)** | boolean | no     | Skip LDAP users. |
 
 ```json
 [
@@ -447,6 +449,21 @@ see the `group_saml` option and `provisioned_by_group_id` parameter:
 }
 ```
 
+Users on [GitLab.com Premium or Ultimate](https://about.gitlab.com/pricing/) also
+see the `scim_identities` parameter:
+
+```json
+{
+  ...
+  "extra_shared_runners_minutes_limit": null,
+  "scim_identities": [
+      {"extern_uid": "2435223452345", "group_id": "3", "active": true},
+      {"extern_uid": "john.smith", "group_id": "42", "active": false}
+    ]
+  ...
+}
+```
+
 Administrators can use the `created_by` parameter to see if a user account was created:
 
 - [Manually by an administrator](../user/profile/account/create_accounts.md#create-users-in-admin-area).
@@ -498,7 +515,7 @@ Parameters:
 | `email`                              | Yes      | Email                                                                                                                                                   |
 | `extern_uid`                         | No       | External UID                                                                                                                                            |
 | `external`                           | No       | Flags the user as external - true or false (default)                                                                                                    |
-| `extra_shared_runners_minutes_limit` **(PREMIUM)** | No       | Can be set by administrators only. Additional CI/CD minutes for this user.                                                                                                 |
+| `extra_shared_runners_minutes_limit` **(PREMIUM)** | No       | Can be set by administrators only. Additional units of compute for this user.                                                                                                 |
 | `force_random_password`              | No       | Set user password to a random value - true or false (default)                                                                                           |
 | `group_id_for_saml`                  | No       | ID of group where SAML has been configured                                                                                                              |
 | `linkedin`                           | No       | LinkedIn                                                                                                                                                |
@@ -511,7 +528,7 @@ Parameters:
 | `projects_limit`                     | No       | Number of projects user can create                                                                                                                      |
 | `provider`                           | No       | External provider name                                                                                                                                  |
 | `reset_password`                     | No       | Send user password reset link - true or false(default)                                                                                                  |
-| `shared_runners_minutes_limit` **(PREMIUM)**  | No       | Can be set by administrators only. Maximum number of monthly CI/CD minutes for this user. Can be `nil` (default; inherit system default), `0` (unlimited), or `> 0`.                                                                                                      |
+| `shared_runners_minutes_limit` **(PREMIUM)**  | No       | Can be set by administrators only. Maximum number of monthly units of compute for this user. Can be `nil` (default; inherit system default), `0` (unlimited), or `> 0`.                                                                                                      |
 | `skip_confirmation`                  | No       | Skip confirmation - true or false (default)                                                                                                             |
 | `skype`                              | No       | Skype ID                                                                                                                                                |
 | `theme_id`                           | No       | GitLab theme for the user (for more information, see the [user preference documentation](../user/profile/preferences.md#navigation-theme) for more information)                    |
@@ -548,7 +565,7 @@ Parameters:
 | `email`                              | No       | Email                                                                                                                                                   |
 | `extern_uid`                         | No       | External UID                                                                                                                                            |
 | `external`                           | No       | Flags the user as external - true or false (default)                                                                                                    |
-| `extra_shared_runners_minutes_limit` **(PREMIUM)** | No       | Can be set by administrators only. Additional CI/CD minutes for this user.                                                                                                 |
+| `extra_shared_runners_minutes_limit` **(PREMIUM)** | No       | Can be set by administrators only. Additional units of compute for this user.                                                                                                 |
 | `group_id_for_saml`                  | No       | ID of group where SAML has been configured                                                                                                              |
 | `id`                                 | Yes      | ID of the user                                                                                                                                      |
 | `linkedin`                           | No       | LinkedIn                                                                                                                                                |
@@ -562,7 +579,7 @@ Parameters:
 | `pronouns`                           | No       | Pronouns                                                                                                                                                |
 | `provider`                           | No       | External provider name                                                                                                                                  |
 | `public_email`                       | No       | Public email of the user (must be already verified)                                                                                                                            |
-| `shared_runners_minutes_limit` **(PREMIUM)** | No       | Can be set by administrators only. Maximum number of monthly CI/CD minutes for this user. Can be `nil` (default; inherit system default), `0` (unlimited) or `> 0`.                                                                                                      |
+| `shared_runners_minutes_limit` **(PREMIUM)** | No       | Can be set by administrators only. Maximum number of monthly units of compute for this user. Can be `nil` (default; inherit system default), `0` (unlimited) or `> 0`.                                                                                                      |
 | `skip_reconfirmation`                | No       | Skip reconfirmation - true or false (default)                                                                                                           |
 | `skype`                              | No       | Skype ID                                                                                                                                                |
 | `theme_id`                           | No       | GitLab theme for the user (for more information, see the [user preference documentation](../user/profile/preferences.md#navigation-theme) for more information)                    |
@@ -875,7 +892,7 @@ Parameters:
 | :------------------------------- | :------- | :--------------------------------------------------------------------------- |
 | `view_diffs_file_by_file`        | Yes      | Flag indicating the user sees only one file diff per page.                   |
 | `show_whitespace_in_diffs`       | Yes      | Flag indicating the user sees whitespace changes in diffs.                   |
-| `pass_user_identities_to_ci_jwt` | Yes      | Flag indicating the user passes their external identities as CI information. This attribute does not contain enough information to identify or authorize the user in an external system. The attribute is internal to GitLab, and must not be passed to third-party services. |
+| `pass_user_identities_to_ci_jwt` | Yes      | Flag indicating the user passes their external identities as CI information. This attribute does not contain enough information to identify or authorize the user in an external system. The attribute is internal to GitLab, and must not be passed to third-party services. For more information and examples, see [Token Payload](../ci/secrets/id_token_authentication.md#token-payload). |
 
 ## User follow
 
@@ -991,6 +1008,20 @@ Example response:
 }
 ```
 
+## Create Service Account User **(PREMIUM)**
+
+> Ability to create a service account user was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/406782) in GitLab 16.1
+
+Creates a service account user with an auto-generated email address and username.
+
+```plaintext
+POST /service_accounts
+```
+
+```shell
+curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/service_accounts"
+```
+
 ## List user projects
 
 See the [list of user projects](projects.md#list-user-projects).
@@ -2204,12 +2235,16 @@ Returns:
 - `403 Forbidden` if not authenticated as an administrator.
 - `404 User Not Found` if user cannot be found.
 
-## Create a CI runner **(FREE SELF)**
+## Create a runner **(FREE)**
 
-It creates a new runner, linked to the current user.
+Creates a runner linked to the current user.
 
-Requires administrator access or ownership of the target namespace or project. Token values are returned once. Make sure you save it because you can't access
-it again.
+Prerequisites:
+
+- You must be an administrator or have the Owner role of the target namespace or project.
+- For `instance_type`, you must be an administrator of the GitLab instance.
+
+Be sure to copy or save the `token` in the response, the value cannot be retrieved again.
 
 ```plaintext
 POST /user/runners
diff --git a/doc/architecture/blueprints/cells/cells-feature-ci-runners.md b/doc/architecture/blueprints/cells/cells-feature-ci-runners.md
index e352be17dd3..8a6790ae49f 100644
--- a/doc/architecture/blueprints/cells/cells-feature-ci-runners.md
+++ b/doc/architecture/blueprints/cells/cells-feature-ci-runners.md
@@ -39,6 +39,7 @@ GitLab Runners use a set of globally scoped endpoints to:
 
 - registration of a new runner via registration token `https://gitlab.com/api/v4/runners`
   ([subject for removal](../runner_tokens/index.md)) (`registration token`)
+- creation of a new runner in the context of a user `https://gitlab.com/api/v4/user/runners` (`runner token`)
 - requests jobs via an authenticated `https://gitlab.com/api/v4/jobs/request` endpoint (`runner token`)
 - upload job status via `https://gitlab.com/api/v4/jobs/:job_id` (`build token`)
 - upload trace via `https://gitlab.com/api/v4/jobs/:job_id/trace` (`build token`)
diff --git a/doc/architecture/blueprints/cells/index.md b/doc/architecture/blueprints/cells/index.md
index 9938875adb6..6da99e0aa6a 100644
--- a/doc/architecture/blueprints/cells/index.md
+++ b/doc/architecture/blueprints/cells/index.md
@@ -1,9 +1,9 @@
 ---
 status: accepted
 creation-date: "2022-09-07"
-authors: [ "@ayufan", "@fzimmer", "@DylanGriffith" ]
+authors: [ "@ayufan", "@fzimmer", "@DylanGriffith", "@lohrc" ]
 coach: "@ayufan"
-approvers: [ "@fzimmer" ]
+approvers: [ "@lohrc" ]
 owning-stage: "~devops::enablement"
 participating-stages: []
 ---
@@ -119,7 +119,7 @@ would be required to define a general split of data and build required tooling.
 
 1. **User can push to Git repository.**
 
-    The purpose is to ensure that essential joins from the projects table are properly attributed to be 
+    The purpose is to ensure that essential joins from the projects table are properly attributed to be
     Cell-local, and as a result the essential Git workflow is supported.
 
 1. **User can run CI pipeline.**
@@ -159,7 +159,7 @@ This list is not exhaustive of work needed to be done.
 ### 4. Routing layer
 
 The routing layer is meant to offer a consistent user experience where all Cells are presented
-under a single domain (for example, `gitlab.com`), instead of 
+under a single domain (for example, `gitlab.com`), instead of
 having to navigate to separate domains.
 
 The user will able to use `https://gitlab.com` to access Cell-enabled GitLab. Depending
@@ -231,7 +231,7 @@ to be able to divide big Cells into many smaller ones.
 
 ## Availability of the feature
 
-We are following the [Support for Experiment, Beta, and Generally Available features](../../../policy/alpha-beta-support.md).
+We are following the [Support for Experiment, Beta, and Generally Available features](../../../policy/experiment-beta-support.md).
 
 ### 1. Experiment
 
@@ -346,6 +346,33 @@ This is the list of known affected features with the proposed solutions.
 - [Cells: GitLab Pages](cells-feature-gitlab-pages.md)
 - [Cells: Agent for Kubernetes](cells-feature-agent-for-kubernetes.md)
 
+## Frequently Asked Questions
+
+### What's the difference between Cells architecture and GitLab Dedicated?
+
+The new Cells architecture is meant to scale GitLab.com. And the way to achieve this is by moving
+organizations into cells, but different organizations can still share each other server resources, even
+if the application provides isolation from other organizations. But all of them still operate under the
+existing GitLab SaaS domain name `gitlab.com`. Also, cells still share some common data, like `users`, and
+routing information of groups and projects. For example, no two users can have the same username
+even if they belong to different organizations that exist on different cells.
+
+With the aforementioned differences, GitLab Dedicated is still offered at higher costs due to the fact
+that it's provisioned via dedicated server resources for each customer, while Cells use shared resources. Which
+makes GitLab Dedicated more suited for bigger customers, and GitLab Cells more suitable for small to mid size
+companies that are starting on GitLab.com.
+
+On the other hand, [GitLab Dedicated](https://about.gitlab.com/dedicated/) is meant to provide completely
+isolated GitLab instance for any organization. Where this instance is running on its own custom domain name, and
+totally isolated from any other GitLab instance, including GitLab SaaS. For example, users on GitLab dedicated
+don't have to have a different and unique username that was already taken on GitLab.com.
+
+### Can different cells communicate with each other?
+
+Up until iteration 3, cells communicate with each other only via a shared database that contains common
+data. In iteration 4 we are going to evaluate the option of cells calling each other via API to provide more
+isolation and reliability.
+
 ## Decision log
 
 - 2022-03-15: Google Cloud as the cloud service. For details, see [issue 396641](https://gitlab.com/gitlab-org/gitlab/-/issues/396641#note_1314932272).
diff --git a/doc/architecture/blueprints/ci_pipeline_components/img/catalogs.png b/doc/architecture/blueprints/ci_pipeline_components/img/catalogs.png
new file mode 100644
index 00000000000..8c83aede186
--- /dev/null
+++ b/doc/architecture/blueprints/ci_pipeline_components/img/catalogs.png
diff --git a/doc/architecture/blueprints/ci_pipeline_components/index.md b/doc/architecture/blueprints/ci_pipeline_components/index.md
index ff4604b61bf..667c8d225db 100644
--- a/doc/architecture/blueprints/ci_pipeline_components/index.md
+++ b/doc/architecture/blueprints/ci_pipeline_components/index.md
@@ -106,7 +106,7 @@ identifying abstract concepts and are subject to changes as we refine the design
 
 A pipeline component is a reusable single-purpose building block that abstracts away a single pipeline configuration unit.
 Components are used to compose a part or entire pipeline configuration.
-It can optionally take input parameters and set output data to be adaptable and reusable in different pipeline contexts,
+It can optionally take input parameters to be adaptable and reusable in different pipeline contexts,
 while encapsulating and isolating implementation details.
 
 Components allow a pipeline to be assembled by using abstractions instead of having all the details defined in one place.
@@ -204,7 +204,6 @@ A component YAML file:
 - Must specify its **type** in the filename, which defines how it can be used (raw configuration to be `include`d, child pipeline workflow, job step).
 - Must define its **content** based on the type.
 - Must specify **input parameters** that it accepts. Components should depend on input parameters for dynamic values and not environment variables.
-- Can optionally define **output data** that it returns.
 - Should be **validated statically** (for example: using JSON schema validators).
 
 ```yaml
@@ -597,6 +596,29 @@ For example: index the content of `spec:` section for CI components.
 
 See an [example of development workflow](dev_workflow.md) for a components repository.
 
+## Availability of CI catalog as a feature
+
+We plan to introduce 2 features of CI catalog as separate views:
+
+1. **Namespace Catalog (GitLab Ultimate):** allows organizations to share and discover catalog resources
+   created inside the top-level namespace.
+   Users will be able to access the Namespace Catalog from a project or subgroup inside the top-level
+   namespace.
+1. **Community Catalog (GitLab free):** allows anyone in a GitLab instance to share and discover catalog
+   resources. The Community Catalog presents only resources/projects that are public.
+
+If a resource in a Namespace Catalog is made public (changing the project's visibility) the resource is
+available in both Namespace Catalog (because it comes from there) as well as the Community Catalog
+(because it's public).
+
+![Namespace and Community Catalogs](img/catalogs.png)
+
+There is only 1 CI catalog. The Namespace and Community Catalogs are different views of the CI catalog.
+
+Project admins are responsible for setting the project private or public.
+The CI Catalog should not provide security functionalities like prevent projects from appearing in the Community Catalog.
+If the project is public it's visible to the world anyway.
+
 ## Note about future resource types
 
 In the future, to support multiple types of resources in the Catalog we could
diff --git a/doc/architecture/blueprints/clickhouse_ingestion_pipeline/index.md b/doc/architecture/blueprints/clickhouse_ingestion_pipeline/index.md
index 94714e7b245..6645f390fd1 100644
--- a/doc/architecture/blueprints/clickhouse_ingestion_pipeline/index.md
+++ b/doc/architecture/blueprints/clickhouse_ingestion_pipeline/index.md
@@ -95,9 +95,9 @@ The following case-studies describe how each group intends to solve the underlyi
 
   - In addition, [ClickHouse: Investigate client-side buffering to batch writes into ClickHouse](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/2044) talks about their experimentation with using application-local queueing/batching to work around the problems mentioned above.
 
-- ~"group::product intelligence" has been working on building our analytics offering and recently looking at building and/or improving parts of the system.
+- ~"group::analytics instrumentation" has been working on building our analytics offering and recently looking at building and/or improving parts of the system.
 
-  - [Product Analytics Collector Component](https://gitlab.com/groups/gitlab-org/-/epics/9346) talks about replacing Jitsu with Snowplow for collecting and processing tracking events. For more details of the proposal, see [Jitsu replacement](https://gitlab.com/gitlab-org/analytics-section/product-intelligence/proposals/-/blob/62d332baf5701810d9e7a0b2c00df18431e82f22/doc/jitsu_replacement.md).
+  - [Product Analytics Collector Component](https://gitlab.com/groups/gitlab-org/-/epics/9346) talks about replacing Jitsu with Snowplow for collecting and processing tracking events. For more details of the proposal, see [Jitsu replacement](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/proposals/-/blob/62d332baf5701810d9e7a0b2c00df18431e82f22/doc/jitsu_replacement.md).
 
   - The initial design was prototyped with [Snowplow as Jitsu Replacement PoC](https://gitlab.com/gitlab-org/analytics-section/product-analytics/devkit/-/merge_requests/37).
 
diff --git a/doc/architecture/blueprints/code_search_with_zoekt/index.md b/doc/architecture/blueprints/code_search_with_zoekt/index.md
index db608b763b8..681782609ba 100644
--- a/doc/architecture/blueprints/code_search_with_zoekt/index.md
+++ b/doc/architecture/blueprints/code_search_with_zoekt/index.md
@@ -111,34 +111,30 @@ Elasticsearch option if we find Zoekt is a suitable long term option.
 ### Indexing
 
 Similar to our Elasticsearch integration, GitLab will notify Zoekt every time
-there are updates to a repository. Zoekt, unlike Elasticsearch, is designed to
-clone and index Git repositories so we will simply notify Zoekt of the URL of
-the repository that has changed and it will update its local copy of the Git
-repo and then update its local index files. The Zoekt side of this logic will
-be implemented in a new server-side indexing endpoint we add to Zoekt which is
-currently in
-[an open Pull request](https://github.com/sourcegraph/zoekt/pull/496).
-While the details of
-this pull request are still being debated, we may choose to deploy a fork with
-the functionality we need, but our strongest intention is not to maintain a
-fork of Zoekt and the maintainers have already expressed they are open to this
-new functionality.
+there are updates to a repository. We've introduced a new indexer called
+[`gitlab-zoekt-indexer`](https://gitlab.com/gitlab-org/gitlab-zoekt-indexer) and
+we are going to replace the legacy indexer that needs to clone repositories with it.
+The new indexer expects a payload with all required information to connect to
+Gitaly in order to index the repository.
 
 The rails side of the integration will be a Sidekiq worker that is scheduled
 every time there is an update to a repository and it will simply call this
-`/index` endpoint in Zoekt. This will also need to generate a one-time token
-that can allow Zoekt to clone a private repository.
+`/indexer/index` endpoint in Zoekt. This will also need to send a Gitaly token
+that can allow Zoekt to connect to Gitaly.
+
+We're going to encrypt the connection with SSL and add basic auth in [Add authentication for GitLab -> Zoekt HTTP calls](https://gitlab.com/gitlab-org/gitlab/-/issues/389749)
+before enabling the new indexer since it receives Gitaly secrets from GitLab.
 
 ```mermaid
 sequenceDiagram
    participant user as User
-   participant gitlab_git as GitLab Git
+   participant gitaly as Gitaly
    participant gitlab_sidekiq as GitLab Sidekiq
    participant zoekt as Zoekt
    user->>gitlab_git: git push git@gitlab.com:gitlab-org/gitlab.git
    gitlab_git->>gitlab_sidekiq: ZoektIndexerWorker.perform_async(278964)
-   gitlab_sidekiq->>zoekt: POST /index {"RepoUrl":"https://zoekt:SECRET_TOKEN@gitlab.com/gitlab-org/gitlab.git","RepoId":278964}'
-   zoekt->>gitlab_git: git clone https://zoekt:SECRET_TOKEN@gitlab.com/gitlab-org/gitlab.git
+   gitlab_sidekiq->>zoekt: POST /indexer/index {"GitalyConnectionInfo": {"Address": "tcp://gitaly:2305", "Storage": "default", "Token": "secret_token", "Path": "@hashed/a/b/c.git"}, "RepoId":7}
+   zoekt->>gitaly: go gitaly client
 ```
 
 The Sidekiq worker can leverage de-duplication based on the `project_id`.
@@ -169,19 +165,15 @@ matches all the searched repositories.
 ### Zoekt infrastructure
 
 Each Zoekt node will need to run a
-[zoekt-dynamic-indexserver](https://github.com/sourcegraph/zoekt/pull/496) and
-a
-[zoekt-webserver](https://github.com/sourcegraph/zoekt/blob/main/cmd/zoekt-webserver/main.go).
-These are both webservers with different responsibilities. Considering that the
-Zoekt indexing process needs to keep a full clone of the bare repo
-([unless we come up with a better option](https://gitlab.com/gitlab-org/gitlab/-/issues/384722))
-these bare repos will be stored on spinning disks to save space. These are only
-used as an intermediate step to generate the actual `.zoekt` index files which
-will be stored on an SSD for fast searches. These web servers need to run on
-the same node as they access the same files. The `zoekt-dynamic-indexserver` is
-responsible for writing the `.zoekt` index files. The `zoekt-webserver` is
-responsible for responding to searches that it performs by reading these
-`.zoekt` index files.
+[`gitlab-zoekt-indexer`](https://gitlab.com/gitlab-org/gitlab-zoekt-indexer/-/blob/main/cmd/gitlab-zoekt-indexer/main.go)
+and a
+[`zoekt-webserver`](https://github.com/sourcegraph/zoekt/blob/main/cmd/zoekt-webserver/main.go).
+These are both webservers with different responsibilities.
+The actual `.zoekt` index files will be stored on an SSD for fast searches.
+These web servers need to run on the same node as they access the same files.
+The `gitlab-zoekt-indexer` is responsible for writing the `.zoekt` index files.
+The `zoekt-webserver` is responsible for responding to searches that it performs
+by reading these `.zoekt` index files.
 
 ### Rollout strategy
 
diff --git a/doc/architecture/blueprints/database/automated_query_analysis/index.md b/doc/architecture/blueprints/database/automated_query_analysis/index.md
new file mode 100644
index 00000000000..c08784dab48
--- /dev/null
+++ b/doc/architecture/blueprints/database/automated_query_analysis/index.md
@@ -0,0 +1,226 @@
+---
+status: proposed
+creation-date: "2023-02-08"
+authors: [ "@mattkasa", "@jon_jenkins" ]
+coach: "@DylanGriffith"
+approvers: [ "@rogerwoo", "@alexives" ]
+owning-stage: "~devops::data_stores"
+participating-stages: []
+---
+
+# Automated Query Analysis
+
+## Problem Summary
+
+Our overarching goal is to improve the reliability and throughput of GitLab’s
+database review process. The current process requires merge request authors to
+manually provide query plans and raw SQL when introducing new queries or
+updating existing queries. This is both time consuming and error prone.
+
+We believe we can improve operational efficiency by automatically identifying
+and analyzing newly introduced SQL queries. This will reduce the risk of human
+error, leading to improved system stability and an overall reduction in
+performance regressions.
+
+Our key success metric is a reduction in the number of manual actions required
+by both code contributors and database reviewers, while maintaining a consistent
+standard for database related code contributions.
+
+## Goals
+
+1. Replace the current process of the author manually obtaining SQL and query
+   plans with an automated process.
+1. Decrease the incidence of performance regressions when poorly performing
+   queries are missed by a manual process.
+1. Increase contributor and reviewer efficiency by automating the query testing
+   portion of database review.
+
+## Challenges
+
+- Capturing the number of SQL queries generated by an application the size of
+  `gitlab-org/gitlab` without causing an increase in CI time and/or resources
+  may present a challenge.
+- Storing the number of SQL queries generated by an application the size of
+  `gitlab-org/gitlab` may consume large amounts of database storage.
+
+## Opportunity
+
+- Automated test suites already generate a large number of SQL queries, for
+  instance  `rspec` test suites, that can be captured and used to perform
+  automated analysis.
+- We already utilize `postgres.ai` to analyze query performance, and it has an
+  API that will allow us to automate the creation of database clones with
+  realistic production-like data in order to perform automated analysis.
+- For customers who do not use something like `postgres.ai`, but who are
+  connecting to a test database in CI, we would use this connection to generate
+  query plans. The accuracy of these query plans will be affected by how
+  realistic the test data is, and can be improved by seeding the test database
+  with production-like data.
+- By storing queries and their query plans, we can tokenize the query plan into
+  plan components, assign a cost and weight, then match those against a machine
+  learning model. We can build this model by generating query plans for queries
+  in our slow query logs, and assign actual cost and weight to their plan
+  components. This will allow us to leverage our corpus of queries and slow
+  query logs to predict the performance of arbitrary query text for other
+  applications and our customers.
+
+## Proposal
+
+We plan to automate the process of identifying new and changed database queries,
+so that contributors and reviewers can more accurately and efficiently assess
+the database performance impact of a code change.
+
+We will capture queries generated as a side effect of running tests in CI,
+normalize them, deduplicate them, analyze them using one or more analyzers, and
+store them with their analyses and other metadata for future retrieval and
+comparison.
+
+We will post a comment to the originating merge request, containing a summary of
+the new and changed queries, with links to their analyses, and highlighting any
+queries that exceed established timing or other performance guidelines.
+
+## Design and implementation details
+
+### Iteration 1
+
+In the first iteration we will focus on how we capture queries, including
+normalization, deduplication, and storage. We must consider the performance and
+resource impacts on CI pipelines during capture, and include things like
+partitioning and time decay for the information we are storing.
+
+#### Capturing queries
+
+We will strive to limit the time and resource impacts on our CI pipelines as
+much as possible. These are some of the options we will consider for capturing
+queries:
+
+- **Instrumenting `ActiveRecord` in `ruby`**
+  - Challenges:
+    - Only applies to `ruby` projects so it would not be applicable to projects
+      like `container-registry`.
+    - Has a non-zero impact on time and resources in CI pipelines (these impacts
+      can be observed in
+      [!111638](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111638))
+  - Opportunities:
+    - Simple and straightforward to implement.
+    - Allows access to more information (eg. stacktrace and calling locations).
+- **Connection proxy with logging**
+  - Challenges:
+    - Adds complexity and possible performance overhead.
+    - Requires maintaining the code for the proxy.
+  - Opportunities:
+    - Allows us to customize the capture.
+    - Allows us to perform normalization/deduplication at capture time.
+- **Built-in logging in `postgresql`**
+  - Challenges:
+    - Require adding a configuration to enable logging.
+    - May be difficult to obtain the resulting logs.
+  - Opportunities:
+    - Doesn't require maintaining any code.
+    - Light weight in terms of performance impact.
+- **Capture from `pg_stat_statements`**
+  - Challenges:
+    - Requires creating the extension in the test database.
+    - Requires adding a configuration to set `pg_stat_statements.max` to a value
+      high enough to capture all queries.
+    - Consumes shared memory proportional to `pg_stat_statements.max`.
+  - Opportunities:
+    - Requires minimal code.
+    - Simple to obtain the data.
+    - Data is already normalized.
+
+We have already built a proof of concept for instrumenting `ActiveRecord` in
+`ruby` in
+[!111638](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111638), so as a
+first step we will benchmark the other capture methods against it and select the
+best option.
+
+#### Storing queries
+
+For the next step of the first iteration we will use the proof of concept in
+[!111638](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111638) as well
+as any data gathered from testing other capture methods to estimate the number
+of rows per project, and use the pipeline execution statistics for
+`gitlab-org/gitlab` to estimate throughput. These estimates will allow us to
+evaluate storage mechanisms that are suitable for our purpose.
+
+Some of the storage mechanisms we plan to evaluate are:
+
+- **In the `ci` database in the GitLab database instance**
+  - Challenges:
+    - Places additional strain on this resource for `GitLab.com`.
+  - Opportunities:
+    - Allows us to utilize existing authentication and access control in the form of `CI_JOB_TOKEN`.
+    - Allows us to leverage associations with `ci_builds` and `ci_pipelines`.
+    - Simplifies deployment for self-managed.
+- **In a new decomposed database in the GitLab database instance**
+  - Challenges:
+    - Adds to required development and testing effort.
+    - Adds to deployment effort for `GitLab.com`.
+  - Opportunities:
+    - Isolates database performance impacts from the existing `main` and `ci` database instances.
+- **In a new external service**
+  - Challenges:
+    - Adds to required development and testing effort.
+    - Adds to deployment effort for `GitLab.com` and for self-managed.
+  - Opportunities:
+    - Isolates performance impacts from `gitlab-org/gitlab`.
+    - Allows us to iterate faster without impacting the main application.
+- **In ClickHouse**
+  - Challenges:
+    - Not yet available for self-managed.
+  - Opportunities:
+    - Isolates database performance impacts from the existing `main` and `ci` database instances.
+
+An example database schema for storing queries:
+
+```sql
+CREATE TABLE queries (
+    created_at timestamp with time zone NOT NULL,
+    updated_at timestamp with time zone NOT NULL,
+    id bigint NOT NULL,
+    project_id bigint NOT NULL,
+    analysis_id bigint,
+    hash text,
+    sql text
+);
+CREATE TABLE pipeline_queries (
+    id bigint NOT NULL,
+    project_id bigint NOT NULL,
+    pipeline_id bigint NOT NULL,
+    query_id bigint NOT NULL
+);
+CREATE TABLE analyses (
+    created_at timestamp with time zone NOT NULL,
+    updated_at timestamp with time zone NOT NULL,
+    id bigint NOT NULL,
+    project_id bigint NOT NULL,
+    query_id bigint NOT NULL,
+    buffers int,
+    walltime int,
+    explain text,
+    analysis_url text
+);
+```
+
+One possible method of partitioning a schema like the above example would be to
+utilize
+[sub-partitioning](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#sub-partitioning).
+If we partition by `project_id` then by some interval of `updated_at`, and touch
+the row when we see a query, we can store only queries that the codebase is
+still executing, and prune partitions that only contain queries the code is no
+longer generating.
+
+### Iteration 2
+
+In the second iteration we plan to identify new and changed queries, and post MR
+comments containing a summary. We will begin soliciting feedback on the accuracy
+and utility of the information, and improve or filter it to maximize it's
+usefulness.
+
+### Iteration 3+
+
+In the third and following iterations we plan to automate query analysis using
+one or more analyzers, store these analyses, and add them to the MR comments. We
+also intend to re-evaluate our use of the database to store query information,
+and the API to retrieve it, and potentially move this to an external service.
diff --git a/doc/architecture/blueprints/object_pools/index.md b/doc/architecture/blueprints/object_pools/index.md
index 3f3a0341e4a..d14e11b8d36 100644
--- a/doc/architecture/blueprints/object_pools/index.md
+++ b/doc/architecture/blueprints/object_pools/index.md
@@ -311,13 +311,428 @@ growth of references in object pools.
 
 ## Design and implementation details
 
-<!--
-
-This section intentionally left blank. I first want to reach consensus on the
-bigger picture I'm proposing in this blueprint before I iterate and fill in the
-lower-level design and implementation details.
-
--->
+### Moving lifecycle management of object pools into Gitaly
+
+As stated, the goal is to move the ownership of object pools into Gitaly.
+Ideally, the concept of object pools should not be exposed to callers at all
+anymore. Instead, we want to only expose the higher-level concept of networks of
+repositories that share objects with each other in order to deduplicate them.
+
+The following subsections review the current object pool-based architecture and
+then propose the new object deduplication network-based architecture.
+
+#### Object pool-based architecture
+
+Managing the object pool lifecycle in the current architecture requires a
+plethora of RPC calls and requires a lot of knowledge from the calling side. The
+following sequence diagram shows a simplified version of the lifecycle of an
+object pool. It is simplified insofar as we only consider there to be a single
+object pool member.
+
+```mermaid
+sequenceDiagram
+    Rails->>+Gitaly: CreateObjectPool
+    Gitaly->>+Object Pool: Create
+    activate Object Pool
+    Object Pool-->>-Gitaly: Success
+    Gitaly-->>-Rails: Success
+
+    Rails->>+Gitaly: LinkRepositoryToObjectPool
+    Gitaly->>+Upstream: Link
+    Upstream-->>-Gitaly: Success
+    Gitaly-->-Rails: Success
+
+    Rails->>+Gitaly: OptimizeRepository
+    Gitaly->>+Upstream: Optimize
+    Upstream-->-Gitaly: Success
+    Gitaly-->-Rails: Success
+
+    Rails->>+Gitaly: CreateFork
+    Gitaly->>+Fork: Create
+    activate Fork
+    Fork-->>-Gitaly: Success
+    Gitaly-->>-Rails: CreateFork
+
+    note over Rails, Fork: Fork exists but is not connected to the object pool.
+
+    Rails->>+Gitaly: LinkRepositoryToObjectPool
+    Gitaly->>+Fork: Link
+    Fork-->>-Gitaly: Success
+    Gitaly-->-Rails: Success
+
+    note over Rails, Fork: Fork is connected to object pool, but objects are duplicated.
+
+    Rails->>+Gitaly: OptimizeRepository
+    Gitaly->>+Fork: Optimize
+    Fork-->-Gitaly: Success
+    Gitaly-->-Rails: Success
+
+    loop Regularly
+        note over Rails, Fork: Rails needs to ensure that the object pool is regularly updated.
+
+        Rails->>+Gitaly: FetchIntoObjectPool
+        Gitaly->>+Object Pool: Fetch
+        Object Pool-->>-Gitaly: Success
+        Gitaly-->>-Rails: Success
+    end
+
+    alt Disconnect Fork
+        note over Rails, Fork: Forks can be disconnected to stop deduplicating objects.
+
+        Rails->>+Gitaly: DisconnectGitAlternates
+        Gitaly->>+Fork: Disconnect
+        Fork-->>-Gitaly: Success
+        Gitaly-->>-Rails: Success
+    else Delete Fork
+        note over Rails, Fork: Or the fork is deleted eventually.
+
+        Rails->>+Gitaly: RemoveRepository
+        Gitaly->>+Fork: Remove
+        Fork-->>-Gitaly: Success
+        deactivate Fork
+        Gitaly-->>-Rails: Success
+    end
+
+    Rails->>+Gitaly: DisconnectGitAlternates
+    Gitaly->>+Upstream: Disconnect
+    Upstream-->>-Gitaly: Success
+    Gitaly-->>-Rails: Success
+
+    Rails->>+Gitaly: DeleteObjectPool
+    Gitaly->>+Object Pool: Remove
+    Object Pool-->>-Gitaly: Success
+    deactivate Object Pool
+    Gitaly-->>-Rails: Success
+```
+
+The following steps are involved in creating the object pool:
+
+1. The object pool is created from its upstream repository by calling
+   `CreateObjectPool()`. It contains all the objects that the upstream
+   repository contains at the time of creation.
+1. The upstream repository is linked to the object pool by calling
+   `LinkRepositoryToObjectPool()`. Its objects are not automatically
+   deduplicated.
+1. Objects in the upstream repository get deduplicated by calling
+   `OptimizeRepository()`.
+1. The fork is created by calling `CreateFork()`. This RPC call only takes the
+   upstream repository as input and does not know about the already-created
+   object pool. It thus performs a second full copy of objects.
+1. Fork and object pool are linked by calling `LinkRepositoryToObjectPool()`.
+   This writes the `info/alternates` file in the fork so that it becomes
+   aware of the additional object database, but doesn't cause the objects to
+   become deduplicated.
+1. Objects in the fork get deduplicated by calling `OptimizeRepository()`.
+1. The calling side is now expected to regularly call `FetchIntoObjectPool()` to
+   fetch new objects from the upstream repository into the object pool. Fetched
+   objects are not automatically deduplicated in the upstream repository.
+1. The fork can be detached from the object pool in two ways:
+   - Explicitly by calling `DisconnectGitAlternates()`, which removes the
+     `info/alternates` file and reduplicates all objects.
+   - By calling `RemoveRepository()` to delete the fork altogether.
+1. When the object pool is empty, it must be removed by calling
+   `DeleteObjectPool()`.
+
+It is clear that the whole lifecycle management is not well-abstracted and that
+the clients need to be aware of many of its intricacies. Furthermore, we have
+multiple sources of truth for object pool memberships that can (and in practice
+do) diverge.
+
+#### Object deduplication network-based architecture
+
+The proposed new architecture simplifies this process by completely removing the
+notion of object pools from the public interface. Instead, Gitaly exposes the
+high-level notion of "object deduplication networks". Repositories can join
+these networks with one of two roles:
+
+- Read-write object deduplication network members regularly update the set of
+  objects that are part of the object deduplication network.
+- Read-only object deduplication network members are passive members and never
+  update the set of objects that are part of the object deduplication network.
+
+The set of objects that can be deduplicated across members of the object
+deduplication network thus consists only of objects fetched from the read-write
+members. All members benefit from the deduplication regardless of their role.
+Typically:
+
+- The original upstream repository is designated as the read-write member of
+  the object deduplication network.
+- Forks are read-only object deduplication network members.
+
+It is valid for object deduplication networks to only have read-only members.
+In that case the network is not updated with new shared objects, but the
+existing shared objects remain in use.
+
+Though object pools continue to be the underlying mechanism, the higher level of
+abstraction would allow us to swap out the mechanism if we ever decide to do so.
+
+While clients of Gitaly need to perform fine-grained lifecycle management of
+object pools in the object pool-based architecture, the object deduplication
+network-based architecture only requires them to manage memberships of object
+deduplication networks. The following diagram shows the equivalent flow to the
+object pool-based architecture in the object deduplication network-based
+architecture:
+
+```mermaid
+sequenceDiagram
+    Rails->>+Gitaly: CreateFork
+    Gitaly->>+Object Pool: Create
+    activate Object Pool
+    Object Pool -->>-Gitaly: Success
+    Gitaly->>+Fork: Create
+    Fork->>+Object Pool: Join
+    Object Pool-->>-Fork: Success
+    Fork-->>-Gitaly: Success
+    activate Fork
+    Gitaly-->>-Rails: CreateFork
+
+    loop Regularly
+        Rails->>+Gitaly: OptimizeRepository
+        Gitaly->>+Fork: Optimize
+        Gitaly->>+Object Pool: Optimize
+        Object Pool-->>-Gitaly: Success
+        Fork-->>-Gitaly: Success
+        Gitaly-->>-Rails: Success
+    end
+
+    alt Disconnect Fork
+        Rails->>+Gitaly: RemoveRepositoryFromObjectDeduplicationNetwork
+        Gitaly->>+Fork: Disconnect
+
+        alt Last member
+            Gitaly->>+Object Pool: Remove
+            Object Pool-->>-Gitaly: Success
+        end
+
+        Fork-->>-Gitaly: Success
+        Gitaly-->>-Rails: Success
+    else Delete Fork
+        Rails->>+Gitaly: RemoveRepository
+        Gitaly->>+Fork: Remove
+
+        alt Last member
+            Gitaly->>+Object Pool: Remove
+            Object Pool-->>-Gitaly: Success
+        end
+
+        Fork-->>-Gitaly: Success
+        deactivate Fork
+        Gitaly-->>-Rails: Success
+    end
+```
+
+The following major steps are involved:
+
+1. The fork is created, where the request instructs Gitaly to have both
+   upstream and fork repository join an object deduplication network. If the
+   upstream project is part of an object deduplication network already, then
+   the fork joins that object deduplication network. If it isn't, Gitaly
+   creates an object pool and joins the upstream repository as a read-write
+   member and the fork as a read-only member. Objects of the fork are
+   immediately deduplicated. Gitaly records the membership of both repositories
+   in the object pool.
+1. The client regularly calls `OptimizeRepository()` on either the upstream or
+   the fork project, which is something that clients already know to do. The
+   behavior changes depending on the role of the object deduplication network
+   member:
+   - When executed on a read-write object deduplication network member, the
+     object pool may be updated based on a set of heuristics. This will pull
+     objects which have been newly created in the read-write object
+     deduplication network member into the object pool so that they are
+     available for all members in the object deduplication network.
+   - When executed on a read-only object deduplication network member, the
+     object pool will not be updated so that objects which are only part of the
+     read-only object deduplication network member will not get shared across
+     members. The object pool may still be optimized though as required, for
+     example by repacking objects.
+1. Both the upstream and the fork project can leave the object deduplication
+   network by calling `RemoveRepositoryFromObjectNetwork()`. This reduplicates
+   all objects and disconnects the repositories from the object pool.
+   Furthermore, if the repository was a read-write object deduplication network
+   member, Gitaly will stop using it as a source to update the pool.
+
+   Alternatively, the fork can be deleted with a call to `RemoveRepository()`.
+
+   Both calls update the memberships of the object pool to reflect that
+   repositories have left it. Gitaly deletes the object pool if it has no
+   members left.
+
+With this proposed flow the creation, maintenance, and removal of object pools
+is handled opaquely inside of Gitaly. In addition to the above, two more
+supporting RPCs may be provided:
+
+- `AddRepositoryToObjectDeduplicationNetwork()` to let a preexisting repository
+  join into an object deduplication network with a specified role.
+- `ListObjectDeduplicationNetworkMembers()` to list all members and their roles
+  of the object deduplication network that a repository is a member of.
+
+#### Migration to the object deduplication network-based architecture
+
+Migration towards the object deduplication network-based architecture involves
+a lot of small steps:
+
+1. `CreateFork()` starts automatically linking against preexisting object
+   pools. This allows fast forking and removes the notion of object pools for
+   callers when creating a fork.
+1. Introduce `AddRepositoryToObjectDeduplicationNetwork()` and
+   `RemoveRepositoryFromObjectDeduplicationNetwork()`. Deprecate
+   `AddRepositoryToObjectPool()` and `DisconnectGitAlternates()` and migrate
+   Rails to use the new RPCs. The object deduplication network is identified
+   via a repository, so this drops the notion of object pools when handling
+   memberships.
+1. Start recording object deduplication network memberships in `CreateFork()`,
+   `AddRepositoryToObjectDeduplicationNetwork()`,
+   `RemoveRepositoryFromObjectDeduplicationNetwork()` and `RemoveRepository()`.
+   This information empowers Gitaly to take control over the object pool
+   lifecycle.
+1. Implement a migration so that we can be sure that Gitaly has an up-to-date
+   view of all members of object pools. A migration is required so that Gitaly
+   can automatically handle the lifecycle of on object pool, which:
+   - Enables `OptimizeRepository()` to automatically fetch objects from
+     read-write object pool members.
+   - Allows Gitaly to automatically remove empty object pools.
+1. Change `OptimizeRepository()` so that it also optimizes object pools
+   connected to the repository, which allows us to deprecate and eventually
+   remove `FetchIntoObjectPool()`.
+1. Adapt `RemoveRepositoryFromObjectDeduplicationNetwork()` and
+   `RemoveRepository()` to remove empty object pools.
+1. Adapt `CreateFork()` to automatically create object pools, which allows us
+   to remove the `CreateObjectPool()` RPC.
+1. Remove the `ObjectPoolService` and the notion of object pools from the Gitaly
+   public API.
+
+This plan is of course subject to change.
+
+### Gitaly Cluster concerns
+
+#### Repository creation
+
+When a repository is forked for the first time, Rails creates an object pool via
+the `CreateObjectPool()` RPC. This means object pool creation is handled outside
+of Gitaly. Subsequently, the object pool is linked to upstream and fork
+repositories. When a repository has its Git `alternates` file configured to link
+to another repository, these two repositories must exist on the same physical
+storage.
+
+The repository and its object pool existing on the same physical storage is
+particularly important for Praefect because it is dependent of the repository's
+replication factor. A replication factor is a configuration that controls how
+many storages the repository is replicated to in the Praefect virtual storage.
+By default, the replication factor is equal to the number of storages in
+Praefect. This means that when using the default replication factor, a
+repository is available on all storages in the cluster. When a custom
+replication factor is used, the number of replicas can be reduced so that a
+repository only exists on a subset of storages in Praefect.
+
+Gitaly Cluster persists repositories and their assigned storages in the Praefect
+PostgreSQL database. The database is updated when new repositories are created
+on the virtual storage. When a new repository is created, the replication factor
+specifies how many storages are randomly assigned to the repository. The
+following scenario outlines how a custom replication factor can be problematic
+for object pools:
+
+1. A new repository is created in a Gitaly Cluster that has five storage nodes.
+   The replication factor is set to three. Therefore, three storages are
+   randomly selected and assigned for this new repository in Praefect. For
+   example, the assignments are storages 1, 2, and 3. Storages 4 and 5 do not
+   have a copy of this repository.
+1. The repository gets forked for the first time thus requiring an object pool
+   repository be created with the `CreateObjectPool()` RPC. Because the
+   replication factor is set to three, another randomly selected set of three
+   storages are assigned in Praefect for the new object pool repository. For
+   example, the object pool repository is assigned to storages 3, 4, and 5. Note
+   that these assignments do not entirely match the upstream repository's.
+1. The forked copy of the repository gets created with the `CreateFork()` RPC
+   and is also assigned to three randomly-selected storages. For example, the
+   fork repository gets assigned storages 1, 3, and 5. These assignments also do
+   not entirely match the upstream and object pool repository's storage
+   assignments.
+1. Both the upstream and fork repositories are linked to the object pool via
+   separate invocations of `LinkRepositoryToObjectPool()`. For this RPC to
+   succeed the object pool must exist on the same storage as the repository
+   that is linking to it. The upstream repository fails to link on storages 1
+   and 2. The fork repository fails to link on storage 2. The
+   `LinkRepositoryToObjectPool()` RPC is not transactional so a single failure
+   of the RPC on any of the storages results in an error being proxied back to
+   the client. Therefore, in this scenario `LinkRepositoryToObjectPool()` on
+   both the upstream and fork repository always result in an error response.
+
+To fix this problem, we must ensure Praefect always routes `CreateObjectPool()`
+and `CreateFork()` RPC requests to the same set of storages as the upstream
+repository. This ensures that these repositories always have the required object
+pool repository available so that linking to them can succeed.
+
+The main downside of this is that repositories in an object deduplication
+network are pinned to the same set of storages. This could unevenly stress
+individual storages as an object deduplication network grows larger. In the
+future this can be avoided altogether when Praefect has the ability to create
+object pools on a storage where it is required but not already present.
+
+#### Repository replication
+
+The `ReplicateRepository()` RPC is not aware of object pools and only replicates
+from the source repository. This means that replication of a source repository
+linked to an object pool repository results in a target repository with no Git
+`alternates` file and consequently no deduplication of objects.
+
+The `ReplicateRepository()` RPC has two main uses:
+
+- Storage moves performed in the GitLab API rely on the `ReplicateRepository()`
+  RPC to replicate repositories from one storage to another. Since this RPC is
+  currently not object pool aware, the resulting replica on the target storage
+  does not replicate the Git `alternates` file from the source repository or
+  recreate any object pools. Instead, the replica is always a complete
+  self-contained copy of the source repository. Consequently, the object pool
+  relationship for the repository project in Rails is also removed. When moving
+  repositories in an object deduplication network from one storage to another,
+  the replicated repositories can result in increased storage usage because
+  there is no longer any deduplication of objects on the target storage.
+- When a repository replica becomes outdated in Praefect, the
+  `ReplicateRepository()` RPC is internally used by Praefect replication jobs to
+  replicate over the out-of-date replica from an up-to-date replica. Replication
+  jobs are queued by the Praefect replication manager when replicas become
+  outdated. Though the `ReplicateRepository()` RPC is not aware of object pools,
+  the replication job checks if the source repository is linked to an object
+  pool. If the source repository is linked, the job recreates the corresponding
+  Git `alternates` file on the target repository. However, it is currently
+  possible for an object pool to not exist on the same storage as the replica.
+  When this happens, replication always fails because the replica is unable to
+  link to the non-existent object pool. This means it is possible for replicas
+  to remain outdated permanently.
+
+Object pools required by the source repository should be replicated to the
+target storage along with the repository during the `ReplicateRepository()` RPC.
+This preserves object deduplication for repositories in an object deduplication
+network. Because storage moves performed in the GitLab API remove any object
+pool relationships, recreating object pools on the target storage results in
+orphaned object pools. This new object pool replication behavior of the
+`ReplicateRepository()` RPC should be controlled by the client to prevent
+breaking changes. Object pool replication for storage moves can be enabled once
+either:
+
+- The Rails side is updated to preserve the object pool relationship.
+- The object pool lifecycle is managed within Gitaly.
+
+When it comes to replication of object pools, there are scenarios Praefect needs
+to be capable of handling. Special consideration must be made in these cases so
+Praefect can keep track of all the repositories it manages in its PostgreSQL
+database to ensure they stay up to date.
+
+- Replication of an external source repository that is linked to an object pool
+  to Gitaly Cluster can result in the target virtual storage's Praefect needing
+  to create a new object pool repository. To handle this, it needs to be known
+  if the source repository is using an object pool. From there it can be checked
+  if Praefect has an entry for the object pool repository in its `repositories`
+  database table, and if not, create one. Next, Praefect storage assignments for
+  the object pool need to be generated and persisted in the
+  `repository_assignments` database table.
+- It can not be guaranteed that the target repository storage in Praefect
+  already contains the required object pool. Thus an individual storage may need
+  to have an object pool assigned to it. This new assignment must also be
+  tracked by the object pool repository in Praefect. To handle this, Praefect
+  has to detect when a target storage does not contain the required object pool
+  and persist the new storage assignment in the `repository_assignments`
+  database table.
 
 ## Problems with the design
 
diff --git a/doc/architecture/blueprints/organization/index.md b/doc/architecture/blueprints/organization/index.md
index bd8d085413c..be99211754d 100644
--- a/doc/architecture/blueprints/organization/index.md
+++ b/doc/architecture/blueprints/organization/index.md
@@ -1,7 +1,7 @@
 ---
 status: ongoing
 creation-date: "2023-04-05"
-authors: [ "@lohrc" ]
+authors: [ "@lohrc", "alexpooley" ]
 coach: "@ayufan"
 approvers: [ "@lohrc" ]
 owning-stage: "~devops::data stores"
@@ -47,6 +47,7 @@ The Organization focuses on creating a better experience for Organizations to ma
 - Aggregation: Data from all groups and projects in an Organization can be aggregated.
 - An Organization includes settings, data, and features from all groups and projects under the same owner (including personal namespaces).
 - Cascading behavior: Organization cascades behavior to all the projects and groups that are owned by the same Organization. It can be decided at the Organization level whether a setting can be overridden or not on the levels beneath.
+- Minimal burden on customers: The addition of Organizations should not change existing group and project paths to minimize the impact of URL changes.
 
 ### Non-Goals
 
@@ -86,14 +87,14 @@ Self-managed instances would set a default Organization.
 
 The Organization MVC will contain the following functionality:
 
-- Instance setting to allow the creation of multiple Organizations. This will be enabled by default on GitLab.com, and disabled for self-managed GitLab. 
+- Instance setting to allow the creation of multiple Organizations. This will be enabled by default on GitLab.com, and disabled for self-managed GitLab.
 - Every instance will have a default organization. Initially, all users will be managed by this default Organization.
 - Organization Owner. The creation of an Organization appoints that user as the Organization Owner. Once established, the Organization Owner can appoint other Organization Owners.
-- Organization users. A user is managed by one Organization, but can be part of multiple Organizations.
+- Organization users. A user is managed by one Organization, but can be part of multiple Organizations. Users are able to navigate between the different Organizations they are part of.
 - Setup settings. Containing the Organization name, ID, description, README, and avatar. Settings are editable by the Organization Owner.
 - Setup flow. Users are able to build an Organization on top of an existing top-level group. New users are able to create an Organization from scratch and to start building top-level groups from there.
 - Visibility. Options will be `public` and `private`. A nonuser of a specific Organization will not see private Organizations in the explore section. Visibility is editable by the Organization Owner.
-- Organization settings page with the added ability to remove an Organization. Deletion of the default Organization is prevented. 
+- Organization settings page with the added ability to remove an Organization. Deletion of the default Organization is prevented.
 - Groups. This includes the ability to create, edit, and delete groups, as well as a Groups overview that can be accessed by the Organization Owner.
 - Projects. This includes the ability to create, edit, and delete projects, as well as a Projects overview that can be accessed by the Organization Owner.
 
@@ -107,10 +108,10 @@ Organization Users can get access to groups and projects as:
 - A project member: this grants access to the project, and limited access to parent groups, regardless of their visibility.
 - A non-member: this grants access to public and internal groups and projects of that Organization. To access a private group or project in an Organization, a user must become a member.
 
-Organization Users can be managed by the Organization as:
+Organization Users can be managed in the following ways:
 
-- Enterprise Users, managed by the Organization. This includes control over their user account and the ability to block the user.
-- Non-Enterprise Users, managed by the User. Non-Enterprise Users can be removed from an Organization, but their user account remains in their control.
+- As [Enterprise Users](../../../user/enterprise_user/index.md), managed by the Organization. This includes control over their user account and the ability to block the user.
+- As Non-Enterprise Users, managed by the Default Organization. Non-Enterprise Users can be removed from an Organization, but the user keeps ownership of their user account.
 
 Enterprise Users are only available to Organizations with a Premium or Ultimate subscription. Organizations on the free tier will only be able to host Non-Enterprise Users.
 
@@ -118,9 +119,13 @@ Enterprise Users are only available to Organizations with a Premium or Ultimate
 
 Non-users are external to the Organization and can only access the public resources of an Organization, such as public projects.
 
+### Routing
+
+Today only users, projects, namespaces and container images are considered routable entities which require global uniqueness on `https://gitlab.com/<path>/-/`. Initially, Organization routes will be [unscoped](../../../development/routing.md). Organizations will follow the path `https://gitlab.com/-/organizations/org-name/` as one of the design goals is that the addition of Organizations should not change existing group and project paths.
+
 ## Iteration Plan
 
-The following iteration plan outlines how we intend to arrive at the Organization MVC. We are following the guidelines for [Experiment, Beta, and Generally Available features](../../../policy/alpha-beta-support.md).
+The following iteration plan outlines how we intend to arrive at the Organization MVC. We are following the guidelines for [Experiment, Beta, and Generally Available features](../../../policy/experiment-beta-support.md).
 
 ### Iteration 1: Organization Prototype (FY24Q2)
 
@@ -141,9 +146,9 @@ In iteration 2, an Organization MVC Experiment will be released. We will test th
 
 ### Iteration 3: Organization MVC Beta (FY24Q4)
 
-In iteration 3, the Organization MVC Beta will be released. 
+In iteration 3, the Organization MVC Beta will be released.
 
-- Multiple Organization Owners can be assigned. 
+- Multiple Organization Owners can be assigned.
 - Enterprise users can be added to an Organization.
 
 ### Iteration 4: Organization MVC GA (FY25Q1)
@@ -155,12 +160,13 @@ After the initial rollout of Organizations, the following functionality will be
 1. Internal visibility will be made available on Organizations that are part of GitLab.com.
 1. Move billing from top-level group to Organization.
 1. Audit events at the Organization level.
-1. Set merge request approval rules at the Organization level and cascade to all groups and projects. 
+1. Set merge request approval rules at the Organization level and cascade to all groups and projects.
 1. Security policies at the Organization level.
 1. Vulnerability reports at the Organization level.
 1. Cascading Organization setting to enforce security scans.
 1. Scan result policies at the Organization level.
 1. Compliance frameworks.
+1. [Support the agent for Kubernetes sharing at the Organization level](https://gitlab.com/gitlab-org/gitlab/-/issues/382731).
 
 ## Alternative Solutions
 
@@ -169,7 +175,10 @@ An alternative approach to building Organizations is to convert top-level groups
 ## Decision Log
 
 - 2023-05-10: [Billing is not part of the Organization MVC](https://gitlab.com/gitlab-org/gitlab/-/issues/406614#note_1384055365)
+- 2023-05-15: [Organization route setup](https://gitlab.com/gitlab-org/gitlab/-/issues/409913#note_1388679761)
 
 ## Links
 
 - [Organization epic](https://gitlab.com/groups/gitlab-org/-/epics/9265)
+- [Enterprise Users](../../../user/enterprise_user/index.md)
+- [Cells blueprint](../cells/index.md)
diff --git a/doc/architecture/blueprints/permissions/index.md b/doc/architecture/blueprints/permissions/index.md
new file mode 100644
index 00000000000..ab66733803d
--- /dev/null
+++ b/doc/architecture/blueprints/permissions/index.md
@@ -0,0 +1,184 @@
+---
+status: proposed
+creation-date: "2023-03-10"
+authors: [ "@jessieay", "@jarka" ]
+coach: "@grzesiek"
+approvers: [ "@hsutor", "@adil.farrukh" ]
+owning-stage: "~devops::manage"
+participating-stages: []
+---
+
+# Permissions Changes required to enable Custom Roles
+
+## Summary
+
+Today, the GitLab permissions system is a backend implementation detail of our
+static [role-based access control system](../../../user/permissions.md#roles).
+
+In %15.9, we [announced](https://about.gitlab.com/blog/2023/03/08/expanding-guest-capabilities-in-gitlab-ultimate/)
+a customer MVC of the custom roles feature. The MVC introduced the ability to
+add one single permission (`read_code`) to a custom role based on a standard
+GitLab Guest role. The MVC was [implemented](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106256) by
+taking an existing permission from the GitLab authorization framework and
+enabling it if a custom role has it set to `true`.
+
+Post-MVC, the Auth group has started work on making more permissions
+customizable, with the ultimate goal of making *all* permissions customizable.
+
+As we've started planning this work, there are two large challenges:
+
+1. The GitLab permissions system is not a stable, backwards-compatible API.
+    But [the custom roles feature is built on top of the current permissions system](https://gitlab.com/gitlab-org/gitlab/-/issues/352891#note_993031741).
+    Which means that custom roles relies on permissions being a stable,
+    backwards-compatible API. So we must change how we approach our permissions
+    system if we plan to continue on with the current architecture.
+1. Refactoring our permissions system is difficult due to the sheer number of
+   permissions (over 700), duplication of permissions checks throughout the
+   codebase, and the importance of permissions for security (cost
+   of errors is very high).
+
+This blueprint goes into further detail on each of these challenges and suggests
+a path for addressing them.
+
+## What are custom roles?
+
+Our permissions system supports 6 pre-defined roles (Guest, Reporter, Developer, Maintainer, Owner) and users are assigned to per project or group, they can't be modified. Custom roles should solve the problem that our current system is static.
+
+With custom roles, customers can define their own roles and give them permissions they want to. For every role they create they can assign set of permissions. For example, a newly created role "Engineer" could have `read code` and `admin merge requests` enabled but abilities such as `admin issues` disabled.
+
+## Motivation
+
+This plan is important to define because the [custom roles project](https://gitlab.com/groups/gitlab-org/-/epics/4035)'s
+current architecture is built off of our current permissions system, [Declarative Policy](https://gitlab.com/gitlab-org/ruby/gems/declarative-policy).
+Declarative Policy makes it inexpensive to add new permissions, which has
+resulted in our current state of having [over 700 permissions](https://gitlab.com/gitlab-org/gitlab/-/issues/393454#more-context)
+in the `gitlab-org/gitlab` codebase. Even our [permissions documentation](../../../user/permissions.md)
+contains a table with over 200 rows, each row representing a unique
+"permission." Up until now, the proliferation of permissions in the code has
+been manageable because these checks are not part of a public API. With custom
+roles, however, that is changing.
+
+Our current authorization checks are [often duplicated and sprinkled throughout application code](https://gitlab.com/gitlab-org/gitlab/-/issues/352891#note_958192650). For a single web request, there might be several different
+permissions checked in the UI to determine if a user can see those page
+elements, another few permissions checks in the Rails controller to determine if
+the user can access the route at all, and maybe a few more permissions checks
+sprinkled into other Ruby service classes that run as part of the page load.
+This approach is [recommended in the GitLab developer documentation](../../../development/permissions/authorizations.md#where-should-permissions-be-checked)
+as a "defense-in-depth" measure.
+
+In the context of custom roles, however, this approach will not work. When a
+group admin wants to enable a user to take a single action via a custom role,
+that group admin should be able to toggle a single, well-named permission to
+enable the user with the custom role to view or update a resource. This means
+that, for a single web request, we must ensure that only one well-named
+permission is checked. And, the access granted for that permission must be
+relatively stable so that the admin is not giving users more access than they
+think they are. Otherwise, creating and managing custom roles will be overly
+complex and a security nightmare.
+
+While the Auth group owns permissions as a feature, each team owns a set of permissions related to their domain area.
+corner of the `gitlab-org/gitlab` codebase. As a result, all engineering teams that
+are contributing to the `gitlab-org/gitlab` codebase touch permissions. This
+means that it is even more important to provide clear guidelines on the future
+of permissions and automate the enforcement of these guidelines.
+
+### Goals
+
+- Make it possible to customize all permissions via custom roles.
+- Make the GitLab permissions system worthy of being a public API.
+- Improve the naming and consistency of permissions.
+- Reduce the overall number of permissions from 700+ to < 100.
+- Reduce risk of refactors related to permissions.
+- Make refactoring permissions easier by having a way to evaluate behavior other than unit tests and documentation.
+- Track ownership of individual permissions so that DRIs can be consulted on any changes related to a permission that they own
+- Create a SSoT for permissions behavior.
+- Automate generation of permissions documentation.
+
+### Non-Goals
+
+- Pause custom roles project indefinitely while we refactor our existing permissions system (there is high demand for this as an Ultimate feature).
+- Perform a total re-write or re-build of our permissions system (too much upfront investment without providing customer value).
+- Iteratively work on custom roles without ever getting to feature complete ("iterate to nowhere").
+
+## Proposal
+
+1. Introduce a linter that ensures all new permissions adhere to naming
+   conventions.
+1. Reduce the overall number of permissions from 700+ to < 100 by consolidating
+   our existing permissions.
+1. Introduce ownership tags for each permission that requires owning group to
+   review any MRs that update that permission.
+1. Create a Rake task for generating permissions documentation from code so that
+   we have a Single Source of Truth for permissions.
+
+## Alternative Solutions
+
+### Do nothing
+
+Pros:
+
+- No need to lengthy architecture conversation or plan
+- May discover methods for improving permissions system organically as we move
+  forward.
+
+Cons:
+
+- Slow progress in building custom role feature without blueprint for how to
+  think about permissions system as a whole
+- Permissions system can spiral into an unmaintainable code if we iterate on it without a strategically important vision.
+
+### Leave the current permissions system as-is and build a parallel Declarative Policy-based system alongside it to be used for custom roles
+
+Pros:
+
+- Faster to design and build a new system than to do a large-scale refactor of the existing system.
+- Auth team can own this new system entirely.
+
+Cons:
+
+- Maintaining 2 systems
+- Each new "regular" permission added needs a parallel addition to the
+  custom roles system. This makes it difficult to have feature parity between
+  custom roles and static roles.
+- Replacing our existing RBAC system with custom roles (an eventual goal of the
+  custom roles feature) is more difficult with this approach because it requires
+  retiring the legacy permissions system.
+
+### Bundle existing permissions into custom permissions; use "custom permissions" for the custom roles API
+
+Pros:
+
+- Faster to design and build a new system than to do a large-scale refactor of the existing system.
+- Auth team can own these new bundled permissions
+
+Cons:
+
+- Bundling permissions is less granular; the goal of custom permissions is to
+  enable granular access.
+- Each new "regular" permission added needs a parallel addition to the
+  bundled permissions for custom roles. This makes it difficult to have feature
+  parity between custom roles and static roles.
+
+## Glossary
+
+- **RBAC**: Role-based access control; "a method of restricting network access based
+  on the roles of individual users." RBAC is the method of access control that
+  GitLab uses.
+- **Static roles**: the 5 categories that GitLab users can be grouped into: Guest,
+  Reporter, Developer, Maintainer, Owner ([documentation](../../../user/permissions.md#roles)).
+  A static role can be thought of as a group of permissions.
+- **Declarative Policy**: [code library](https://gitlab.com/gitlab-org/ruby/gems/declarative-policy/)
+  used by GitLab to define our authorization logic.
+- **Permissions**: a specific ability that a user with a Role has. For example, a
+  Developer can create merge requests but a Guest cannot. Each row listed in
+  [the permissions documentation](../../../user/permissions.md#project-members-permissions)
+  represents a "permission" but these may not have a 1:1 mapping with a Declarative Policy
+  [ability](https://gitlab.com/gitlab-org/ruby/gems/declarative-policy/-/blob/main/doc/defining-policies.md#invocation).
+  An ability is how permissions are represented in the GitLab codebase.
+- **Access level**: integer value representing a static role, used for determining access and calculating inherited user access in group hierarchies ([documentation](../../../api/access_requests.md#valid-access-levels)).
+
+## Resources
+
+- [Custom Roles MVC announcement](https://github.blog/changelog/2021-10-27-enterprise-organizations-can-now-create-custom-repository-roles)
+- [Custom Roles lunch and learn notes](https://docs.google.com/document/d/1x2ExhGJl2-nEibTaQE_7e5w2sDCRRHiakrBYDspPRqw/edit#)
+- [Discovery on auto-generating documentation for permissions](https://gitlab.com/gitlab-org/gitlab/-/issues/352891#note_989392294).
diff --git a/doc/architecture/blueprints/pods/index.md b/doc/architecture/blueprints/pods/index.md
deleted file mode 100644
index 5c15f880a54..00000000000
--- a/doc/architecture/blueprints/pods/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/index.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/index.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-admin-area.md b/doc/architecture/blueprints/pods/pods-feature-admin-area.md
deleted file mode 100644
index 0f02a4a88ba..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-admin-area.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-admin-area.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-admin-area.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-agent-for-kubernetes.md b/doc/architecture/blueprints/pods/pods-feature-agent-for-kubernetes.md
deleted file mode 100644
index f28cc447e0a..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-agent-for-kubernetes.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-agent-for-kubernetes.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-agent-for-kubernetes.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-backups.md b/doc/architecture/blueprints/pods/pods-feature-backups.md
deleted file mode 100644
index db22317cf75..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-backups.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-backups.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-backups.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-ci-runners.md b/doc/architecture/blueprints/pods/pods-feature-ci-runners.md
deleted file mode 100644
index 1985bb21884..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-ci-runners.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-ci-runners.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-ci-runners.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-container-registry.md b/doc/architecture/blueprints/pods/pods-feature-container-registry.md
deleted file mode 100644
index 9d2bbb3febe..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-container-registry.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-container-registry.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-container-registry.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-contributions-forks.md b/doc/architecture/blueprints/pods/pods-feature-contributions-forks.md
deleted file mode 100644
index 38bdef35329..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-contributions-forks.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-contributions-forks.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-contributions-forks.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-dashboard.md b/doc/architecture/blueprints/pods/pods-feature-dashboard.md
deleted file mode 100644
index 1d92b891aff..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-dashboard.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-dashboard.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-dashboard.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-data-migration.md b/doc/architecture/blueprints/pods/pods-feature-data-migration.md
deleted file mode 100644
index c06006a86dc..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-data-migration.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-data-migration.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-data-migration.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-database-sequences.md b/doc/architecture/blueprints/pods/pods-feature-database-sequences.md
deleted file mode 100644
index 9c4d6c5e290..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-database-sequences.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-database-sequences.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-database-sequences.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-git-access.md b/doc/architecture/blueprints/pods/pods-feature-git-access.md
deleted file mode 100644
index 1a0df0f9569..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-git-access.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-git-access.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-git-access.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-gitlab-pages.md b/doc/architecture/blueprints/pods/pods-feature-gitlab-pages.md
deleted file mode 100644
index 4c7f162434e..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-gitlab-pages.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-gitlab-pages.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-gitlab-pages.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-global-search.md b/doc/architecture/blueprints/pods/pods-feature-global-search.md
deleted file mode 100644
index 035e95219e4..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-global-search.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-global-search.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-global-search.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-graphql.md b/doc/architecture/blueprints/pods/pods-feature-graphql.md
deleted file mode 100644
index f0f01a2b120..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-graphql.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-graphql.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-graphql.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-organizations.md b/doc/architecture/blueprints/pods/pods-feature-organizations.md
deleted file mode 100644
index f801f739374..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-organizations.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-organizations.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-organizations.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-personal-namespaces.md b/doc/architecture/blueprints/pods/pods-feature-personal-namespaces.md
deleted file mode 100644
index 237eb5f9d64..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-personal-namespaces.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-personal-namespaces.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-personal-namespaces.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-router-endpoints-classification.md b/doc/architecture/blueprints/pods/pods-feature-router-endpoints-classification.md
deleted file mode 100644
index b9e85c29481..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-router-endpoints-classification.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-router-endpoints-classification.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-router-endpoints-classification.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-schema-changes.md b/doc/architecture/blueprints/pods/pods-feature-schema-changes.md
deleted file mode 100644
index a57f76ad9d4..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-schema-changes.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-schema-changes.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-schema-changes.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-secrets.md b/doc/architecture/blueprints/pods/pods-feature-secrets.md
deleted file mode 100644
index f33b98add21..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-secrets.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-secrets.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-secrets.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-snippets.md b/doc/architecture/blueprints/pods/pods-feature-snippets.md
deleted file mode 100644
index 42d3c401dba..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-snippets.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-snippets.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-snippets.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-template.md b/doc/architecture/blueprints/pods/pods-feature-template.md
deleted file mode 100644
index acc8e329725..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-template.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-template.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-template.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/pods-feature-uploads.md b/doc/architecture/blueprints/pods/pods-feature-uploads.md
deleted file mode 100644
index 1de4c138843..00000000000
--- a/doc/architecture/blueprints/pods/pods-feature-uploads.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/cells-feature-uploads.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/cells-feature-uploads.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/proposal-stateless-router-with-buffering-requests.md b/doc/architecture/blueprints/pods/proposal-stateless-router-with-buffering-requests.md
deleted file mode 100644
index 4c135c5dbc3..00000000000
--- a/doc/architecture/blueprints/pods/proposal-stateless-router-with-buffering-requests.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/proposal-stateless-router-with-buffering-requests.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/proposal-stateless-router-with-buffering-requests.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/pods/proposal-stateless-router-with-routes-learning.md b/doc/architecture/blueprints/pods/proposal-stateless-router-with-routes-learning.md
deleted file mode 100644
index 093d5d7acc6..00000000000
--- a/doc/architecture/blueprints/pods/proposal-stateless-router-with-routes-learning.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../cells/proposal-stateless-router-with-routes-learning.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../cells/proposal-stateless-router-with-routes-learning.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/rate_limiting/index.md b/doc/architecture/blueprints/rate_limiting/index.md
index 17808267032..db6bb85d839 100644
--- a/doc/architecture/blueprints/rate_limiting/index.md
+++ b/doc/architecture/blueprints/rate_limiting/index.md
@@ -108,7 +108,7 @@ quota and by a policy.
   - _Example:_ maximum artifact upload size of 1 GB
 - **Quota:** A global constraint in application usage that is aggregated across an
   entire namespace over the duration of their billing cycle.
-  - _Example:_ 400 CI/CD minutes per namespace per month
+  - _Example:_ 400 units of compute per namespace per month
   - _Example:_ 10 GB transfer per namespace per month
 - **Policy:** A representation of business logic that is decoupled from application
   code. Decoupled policy definitions allow logic to be shared across multiple services
diff --git a/doc/architecture/blueprints/remote_development/img/remote_dev_15_7.png b/doc/architecture/blueprints/remote_development/img/remote_dev_15_7.png
deleted file mode 100644
index f36bfa24998..00000000000
--- a/doc/architecture/blueprints/remote_development/img/remote_dev_15_7.png
+++ /dev/null
diff --git a/doc/architecture/blueprints/remote_development/img/remote_dev_15_7_1.png b/doc/architecture/blueprints/remote_development/img/remote_dev_15_7_1.png
deleted file mode 100644
index aab946923e2..00000000000
--- a/doc/architecture/blueprints/remote_development/img/remote_dev_15_7_1.png
+++ /dev/null
diff --git a/doc/architecture/blueprints/remote_development/index.md b/doc/architecture/blueprints/remote_development/index.md
index e2647551a95..16b71840f9e 100644
--- a/doc/architecture/blueprints/remote_development/index.md
+++ b/doc/architecture/blueprints/remote_development/index.md
@@ -10,27 +10,25 @@ participating-stages: []
 
 <!-- vale gitlab.FutureTense = NO -->
 
-# Remote Development
+# Remote development
 
 ## Summary
 
-Remote Development is a new architecture for our software-as-a-service platform that provides a more consistent user experience writing code hosted in GitLab. It may also provide additional features in the future, such as a purely browser-based workspace and the ability to connect to an already running VM/Container or to use a GitLab-hosted VM/Container.
+Remote development is a new architecture for our software-as-a-service platform that provides a more consistent user experience writing code hosted in GitLab. It may also provide additional features in the future, such as a purely browser-based workspace and the ability to connect to an already running VM/Container or to use a GitLab-hosted VM/Container.
 
-## Web IDE and Remote Development
+## Web IDE and remote development
 
-It is important to note that `Remote Development !== Web IDE`, and this is something we want to be explicit about in this document as the terms can become conflated when they shouldn't. Our new Web IDE is a separate ongoing effort that is running in parallel to Remote Development.
+It is important to note that `remote development !== Web IDE`, and this is something we want to be explicit about in this document as the terms can become conflated when they shouldn't. Our new Web IDE is a separate ongoing effort that is running in parallel to remote development.
 
 These two separate categories do have some overlap as it is a goal to allow a user to connect a running workspace to the Web IDE, **but** this does not mean the two are dependent on one another.
 
-You can use the [Web IDE](../../../user/project/web_ide/index.md) to commit changes to a project directly from your web browser without installing any dependencies or cloning any repositories. The Web IDE, however, lacks a native runtime environment on which you would compile code, run tests, or generate real-time feedback in the IDE. For a more complete IDE experience, you can pair the Web IDE with a Remote Development workspace that has been properly configured to run as a host.
-
-![WebIDERD](img/remote_dev_15_7_1.png)
+You can use the [Web IDE](../../../user/project/web_ide/index.md) to commit changes to a project directly from your web browser without installing any dependencies or cloning any repositories. The Web IDE, however, lacks a native runtime environment on which you would compile code, run tests, or generate real-time feedback in the IDE. For a more complete IDE experience, you can pair the Web IDE with a remote development workspace that has been properly configured to run as a host.
 
 ## Long-term vision
 
 As a [new Software Developer to a team such as Sasha](https://about.gitlab.com/handbook/product/personas/#sasha-software-developer) with no local development environment, I should be able to:
 
-- Navigate to a repository on GitLab.com or self-managed.
+- Go to a repository on GitLab.com or self-managed.
 - Click a button that will provide a list of current workspaces for this repository.
 - Click a button that will create a new workspace or select an existing workspace from a list.
 - Go through a configuration wizard that will let me select various options for my workspace (memory/CPU).
@@ -38,14 +36,137 @@ As a [new Software Developer to a team such as Sasha](https://about.gitlab.com/h
 - Make code changes, run tests, troubleshoot based on the terminal output, and commit new changes.
 - Submit MRs of any kind without having to clone the repository locally or to manually update a local development environment.
 
-## User Flow Diagram
+## Terminology
+
+We use the following terms to describe components and properties of the remote development architecture.
+
+### Remote development
+
+Remote development allows you to use a secure development environment in the cloud that you can connect to from your local machine through a web browser or a client-based solution with the purpose of developing a software product there.
+
+#### Remote development properties
+
+- Separate your development environment to avoid impacting your local machine configuration.
+- Make it easy for new contributors to get started and keep everyone on a consistent environment.
+- Use tools or runtimes not available on your local OS or manage multiple versions of them.
+- Access an existing development environment from multiple machines or locations.
+
+Discouraged synonyms: VS Code for web, remote development Extension, browser-only WebIDE, Client only WebIDE
+
+### Workspace
+
+Container/VM-based developer machines providing all the tools and dependencies needed to code, build, test, run, and debug applications.
+
+#### Workspace properties
+
+- Workspaces should be isolated from each other by default and are responsible for managing the lifecycle of their components. This isolation can be multi-layered: namespace isolation, network isolation, resources isolation, node isolation, sandboxing containers, etc. ([reference](https://kubernetes.io/docs/concepts/security/multi-tenancy/)).
+- A workspace should contain project components as well as editor components.
+- A workspace should be a combination of resources that support cloud-based development environment.
+- Workspaces are constrained by the amount of resources provided to them.
+
+### Web IDE
+
+VS Code for web - replacement of our current legacy Web IDE.
+
+#### Web IDE properties
+
+A package for bootstrapping GitLab context-aware Web IDE that:
+
+- Is built on top of Microsoft's VS Code. We customize and add VS Code features in the [GitLab fork of the VS Code project](https://gitlab.com/gitlab-org/gitlab-web-ide-vscode-fork).
+- Can be configured in a way that it connects to the workspace rather than only using the browser. When connected to a workspace, a user should be able to do the following from the Web IDE:
+  - Edit, build, or debug on a different OS than they are running locally.
+  - Make use of larger or more specialized hardware than their local machine for development.
+  - Separate developer environments to avoid conflicts, improve security, and speed up onboarding.
+
+### Remote development extension for desktop
+
+Something that plugs into the desktop IDE and connects you to the workspace.
+
+#### Remote development extension for desktop properties
+
+- Allows you to open any folder in a workspace.
+- Should be desktop IDE agnostic.
+- Should have access to local files or APIs.
+
+## Goals
+
+### A consistent experience
+
+Organizations should have the same user experience on our SaaS platform as they do on a self-managed GitLab instance. We want to abstract away the user's development environment to avoid impacting their local machine configuration. We also want to provide support for developing on the same operating system you deploy to or use larger or more specialized hardware.
+
+A major goal is that each member of a development team should have the same development experience minus any specialized local configuration. This will also make it easy for new contributors to get started and keep everyone on a consistent environment.
+
+### Increased availability
+
+A workspace should allow access to an existing development environment from multiple machines and locations across a single or multiple teams. It should also allow a user to make use of tools or runtimes not available on their local OS or manage multiple versions of them.
+
+Additionally, remote development workspaces could provide a way to implement disaster recovery if we are able to leverage the capabilities of [Cells](../../../architecture/blueprints/cells/index.md).
+
+### Scalability
+
+As an organization begins to scale, they quickly realize the need to support additional types of projects that might require extensive workflows. Remote development workspaces aim to solve that issue by abstracting away the burden of complex machine configuration, dependency management, and possible data-seeding issues.
+
+To facilitate working on different features across different projects, remote development should allow each user to provision multiple workspaces to enable quick context switching.
+
+Eventually, we should be able to allow users to vertically scale their workspaces with more compute cores, memory, and other resources. If a user is currently working against a 2 CPU and 4 GB RAM workspace but comes to find they need more CPU, they should be able to upgrade their compute layer to something more suitable with a click or CLI command in the workspace.
+
+### Built-in security and enterprise readiness
+
+As remote development becomes a viable replacement for virtual desktop infrastructure solutions, it must be secure and support enterprise requirements. These include role-based access control and the ability to remove all source code from developer machines.
+
+### Faster project and developer onboarding
+
+As a zero-install development environment that runs in your browser, remote development makes it easy for anyone to join your team and contribute to a project.
+
+### Regions
+
+GitLab.com is only hosted in the United States of America. Organizations located in other regions have voiced demand for local SaaS offerings. BYO infrastructure helps work in conjunction with [GitLab Regions](https://gitlab.com/groups/gitlab-org/-/epics/6037) because a user's workspace may be deployed in different geographies. The ability to deploy workspaces to different geographies might also help to solve data residency and compliance problems.
+
+## Market analysis
+
+We have conducted a market analysis to understand the broader market and what others can offer us by way of open-source libraries, integrations, or partnership opportunities. We have broken down the effort into a set of issues where we investigate each potential competitor/pathway/partnership as a spike.
+
+- [Market analysis](https://gitlab.com/groups/gitlab-org/-/epics/8131)
+- [YouTube results](https://www.youtube.com/playlist?list=PL05JrBw4t0KrRQhnSYRNh1s1mEUypx67-)
+
+## Che vs DevWorkspace Operator vs custom-built solution
+
+After an investigation into using [Che](https://gitlab.com/gitlab-org/gitlab/-/issues/366052) as our backend to accelerate remote development, we ultimately opted to [write our own custom-built solution using DevWorkspace Operator](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/97449#note_1131215629).
+
+Some advantages of us opting to write our own custom-built solution are:
+
+- We can still use the core DevWorkspace Operator and build on top of it.
+- It is easier to add support for other configurations apart from `devfile` in the future if the need arises.
+- We have the ability to choose which tech stack to use (for example, instead of using `traefik`, which is used in Che, explore NGINX itself or use the GitLab Agent for Kubernetes).
+
+After writing our own custom-built solution using DevWorkspace Operator,
+we decided to [remove the dependency on DevWorkspace Operator](https://gitlab.com/groups/gitlab-org/-/epics/9895)
+and thus the transitive dependency of Cert Manager.
+
+## Architecture details
+
+Remote development is delivered as a module in the
+[GitLab Agent for Kubernetes](../../../user/clusters/agent/index.md) project.
+The overall goal of this architecture is to ensure that the **actual state** of all
+remote development workspaces running in the Kubernetes clusters is reconciled with the **desired state** of the
+workspaces as set by the user.
+
+This is accomplished as follows:
 
-![User Flow](img/remote_dev_15_7.png)
+1. The desired state of the workspaces is obtained from user actions in the GitLab UI or API and persisted in the Rails database.
+1. There is a reconciliation loop between the agent and Rails, which:
+   - Retrieves the actual state of the workspaces from the Kubernetes clusters through the agent and sends it to Rails to be persisted.
+   - Rails compares the actual state with the desired state and responds with actions to bring the actual state in line with the desired state for all workspaces.
 
-## Architecture
+### System design
 
 ```plantuml
 @startuml
+
+title
+  System design for Remote Development
+end title
+
 node "Kubernetes" {
   [Ingress Controller] --> [GitLab Workspaces Proxy] : Decrypt Traffic
 
@@ -64,11 +185,11 @@ node "Kubernetes" {
   [GitLab Workspaces Proxy] ..> [Workspace 2] : Forward traffic\nfor workspace 2
   [GitLab Workspaces Proxy] --> [Workspace 1] : Forward traffic\nfor workspace 1
 
-  [Agentk] .up.> [Workspace n] : Applies kubernetes resources\nfor workspace n
-  [Agentk] .up.> [Workspace 2] : Applies kubernetes resources\nfor workspace 2
-  [Agentk] .up.> [Workspace 1] : Applies kubernetes resources\nfor workspace 1
+  [Agent] .up.> [Workspace n] : Applies kubernetes resources\nfor workspace n
+  [Agent] .up.> [Workspace 2] : Applies kubernetes resources\nfor workspace 2
+  [Agent] .up.> [Workspace 1] : Applies kubernetes resources\nfor workspace 1
 
-  [Agentk] --> [Kubernetes API Server] : Interact and get/apply\nKubernetes resources
+  [Agent] --> [Kubernetes API Server] : Interact and get/apply\nKubernetes resources
 }
 
 node "GitLab" {
@@ -78,12 +199,12 @@ node "GitLab" {
   [KAS] -up-> [GitLab Rails] : Proxy
 }
 
-[Agentk] -up-> [KAS] : Initiate reconciliation loop
+[Agent] -up-> [KAS] : Initiate reconciliation loop
 "Load Balancer IP" --> [Ingress Controller]
 [Browser] --> [Nginx] : Browse GitLab
 [Browser] -right-> "Domain IP" : Browse workspace URL
 "Domain IP" .right.> "Load Balancer IP"
-[GitLab Workspaces Proxy] ..> [GitLab Rails] : Authenticate and authorize\nthe user accessing the workspace.
+[GitLab Workspaces Proxy] ..> [GitLab Rails] : Authenticate and authorize\nthe user accessing the workspace
 
 note top of "Domain IP"
   For local development, workspace URL
@@ -100,132 +221,495 @@ end note
 @enduml
 ```
 
-## Terminology
+### Remote development with the GitLab Agent for Kubernetes topology
 
-We use the following terms to describe components and properties of the Remote Development architecture.
+- The Kubernetes API is not shown in this diagram, but it is assumed that it is managing the workspaces through the agent.
+- The numbers of components in each Kubernetes cluster are arbitrary.
 
-### Remote Development
+```plantuml
+@startuml
 
-Remote Development allows you to use a secure development environment in the cloud that you can connect to from your local machine through a web browser or a client-based solution with the purpose of developing a software product there.
+title
+  Remote Development with GitLab Agent for Kubernetes topology
+end title
 
-#### Remote Development properties
+node "GitLab Monolith" as gitlab {
+  rectangle "kas deployment" as kas_deployment {
+      collections kas1..kas8
+  }
+  rectangle rails
+  database postgres
 
-- Separate your development environment to avoid impacting your local machine configuration.
-- Make it easy for new contributors to get started and keep everyone on a consistent environment.
-- Use tools or runtimes not available on your local OS or manage multiple versions of them.
-- Access an existing development environment from multiple machines or locations.
+  kas_deployment - rails
+  rails -left- postgres
+}
 
-Discouraged synonyms: VS Code for web, Remote Development Extension, browser-only WebIDE, Client only WebIDE
+node "kubernetes cluster 1" as kubernetes1 {
+  rectangle "agent A workspaces" as agent_a_workspaces {
+    collections workspace2..workspace8
+    rectangle workspace1
+  }
 
-### Workspace
+  rectangle "agent B workspaces" as agent_b..agent_b_8_workspaces {
+    collections workspace10..workspace16
+    rectangle workspace9
+  }
 
-Container/VM-based developer machines providing all the tools and dependencies needed to code, build, test, run, and debug applications.
+  rectangle "agent A deployment" as agent_a_deployment {
+    rectangle agent_a_1
+  }
 
-#### Workspace properties
+  rectangle "agent B deployment" as agent_b_deployment {
+    collections agent_b_1..agent_b_8
+  }
 
-- Workspaces should be isolated from each other by default and are responsible for managing the lifecycle of their components. This isolation can be multi-layered: namespace isolation, network isolation, resources isolation, node isolation, sandboxing containers, etc. ([reference](https://kubernetes.io/docs/concepts/security/multi-tenancy/)).
-- A workspace should contain project components as well as editor components.
-- A workspace should be a combination of resources that support cloud-based development environment.
-- Workspaces are constrained by the amount of resources provided to them.
+  agent_a_1 - agent_a_workspaces
+  agent_b_1..agent_b_8 - agent_b..agent_b_8_workspaces
+}
 
-### Web IDE
+node "kubernetes cluster 2" as kubernetes2 {
+  rectangle "agent C workspaces" as agent_c_workspaces {
+    collections workspace18..workspace24
+    rectangle workspace17
+  }
 
-VS Code for web - replacement of our current legacy Web IDE.
+  rectangle "agent C deployment" as agent_c_deployment {
+    rectangle agent_c_1
+  }
 
-#### Web IDE properties
+  agent_c_1 -down- agent_c_workspaces
+}
 
-A package for bootstrapping GitLab context-aware Web IDE that:
 
-- Is built on top of Microsoft's VS Code. We customize and add VS Code features in the [GitLab fork of the VS Code project](https://gitlab.com/gitlab-org/gitlab-web-ide-vscode-fork).
-- Can be configured in a way that it connects to the workspace rather than only using the browser. When connected to a workspace, a user should be able to do the following from the Web IDE:
-  - Edit, build, or debug on a different OS than they are running locally.
-  - Make use of larger or more specialized hardware than their local machine for development.
-  - Separate developer environments to avoid conflicts, improve security, and speed up onboarding.
+cloud cloud
 
-### Remote Development Extension for Desktop
+cloud - kas1..kas8
+cloud - agent_a_1
+cloud - agent_b_1..agent_b_8
+cloud - agent_c_1
 
-Something that plugs into the desktop IDE and connects you to the workspace.
 
-#### Remote Development Extension for Desktop properties
+'the following hidden line is a hack to get the diagram to render correctly
+agent_a_1 -[hidden]- agent_b_1..agent_b_8
+gitlab -[hidden]d- kubernetes2
 
-- Allows you to open any folder in a workspace.
-- Should be desktop IDE agnostic.
-- Should have access to local files or APIs.
+@enduml
+```
 
-## Goals
+### High-level overview of the communication between Rails and the agent
 
-### A consistent experience
+```plantuml
+@startuml
+!pragma teoz true
+
+title
+  High level overview of the communication between rails and agent
+end title
+
+box gitlab monolith #Beige
+participant rails order 20
+box kas #Bisque
+participant "kas" as kas order 40
+end box
+end box
+
+box Kubernetes cluster #Beige
+box agent #Bisque
+participant "agent remote_development\nmodule" as agent_rd_mod order 50
+end box
+participant kubernetes order 60
+end box
+
+loop forever
+  agent_rd_mod -> kubernetes: Subscribe to Kubernetes for\nworkspace changes associated with the agent
+  activate agent_rd_mod
+
+  autoactivate on
+  agent_rd_mod -> kas: POST request with\nupdated workspace information
+  note right
+    Any updated workspace information from
+    Kubernetes is pushed with next reconciliation.
+  end note
+  kas -> rails: proxy POST request from agent to rails
 
-Organizations should have the same user experience on our SaaS platform as they do on a self-managed GitLab instance. We want to abstract away the user's development environment to avoid impacting their local machine configuration. We also want to provide support for developing on the same operating system you deploy to or use larger or more specialized hardware.
+  return Respond with all workspaces to be created/updated/terminated\nalong with an acknowledgement that all information sent by\nagent have been persisted into the database successfully
+  return proxy workspace information to agent
+  autoactivate off
 
-A major goal is that each member of a development team should have the same development experience minus any specialized local configuration. This will also make it easy for new contributors to get started and keep everyone on a consistent environment.
+  agent_rd_mod -> kubernetes: Apply any received workspace information to kubernetes
+  deactivate agent_rd_mod
+end loop
 
-### Increased availability
+@enduml
+```
 
-A workspace should allow access to an existing development environment from multiple machines and locations across a single or multiple teams. It should also allow a user to make use of tools or runtimes not available on their local OS or manage multiple versions of them.
+### Types of messages between Rails and the agent
+
+The agent can send different types of messages to Rails to capture different information. Depending on what type of message the agent sends, Rails will respond accordingly.
+
+Different types of messages are:
+
+- `prerequisites` (yet to be implemented) - This is the first message the agent sends to Rails after the agent starts or restarts or after a leader-election.
+  - Actions performed by the agent:
+    - Fetch Kubernetes resources that are required to be available in the Kubernetes cluster
+  - Actions performed by Rails:
+    - Send the Kubernetes manifests for `gitlab-workspaces-proxy` that need to be available in the Kubernetes cluster.
+- `reconcile` - Messages sent to Rails to persist the current state of the workspaces. There are two types of updates specified by the `update_type` field with the following possible values: `full` and `partial`. The payload schema remains the same for both update types.
+  - `full`
+    - Actions performed by the agent:
+      - Send the current state of all the workspaces in the Kubernetes cluster managed by the agent.
+      - To keep things consistent between the agent and Rails, the agent will send this message every time agent undergoes a full reconciliation cycle that occurs
+        - when an agent starts or restarts
+        - after a leader-election
+        - periodically, as set using the `full_sync_interval` configuration (default: once every hour)
+        - whenever the agent configuration is updated
+    - Actions performed by Rails:
+      - Update Postgres with the current state and respond with all the workspaces managed by the agent and their last resource version that Rails has persisted in Postgres.
+      - Returning the persisted resource version back to the agent gives it a confirmation that the updates for that workspace have been successfully processed on the Rails end.
+      - This persisted resource version will also help with sending only the latest workspaces changes from the agent to Rails for `reconcile` message with `partial` update type.
+  - `partial`
+    - Actions performed by the agent:
+      - Send the latest workspace changes to Rails that are not yet persisted in Postgres. This persisted resource version will help with sending only the latest workspaces changes from the agent to Rails.
+    - Actions performed by Rails:
+      - Update Postgres with the current state and respond with the workspaces to be created/updated/deleted in the Kubernetes cluster and their last resource version that Rails has persisted in Postgres.
+      - The workspaces to be created/updated/deleted are calculated by using the filter `desired state updated at >= agent info reported at`.
+      - Returning the persisted resource version back to the agent gives it a confirmation that the updates for that workspace have been successfully processed on the Rails end.
+
+### Event-driven polling vs full or partial reconciliation
+
+It was initially considered desirable to be able to tell the agent to not wait for the next reconciliation loop but instead poll immediately. This would grant the following benefits:
+
+1. This would grant the ability to trigger a full reconciliation on demand that would allow on-demand recovery/resetting of module state in the agent.
+1. Apart from making the architecture more event-driven and real-time it would also help to increase the interval between reconciliation polls, thus reducing the load on the infrastructure.
+
+However, as the prospective solutions were evaluated, it was concluded that there are very few/rare cases that would merit this capability, especially given the complexity of the viable options. An eventual reconciliation of state would suffice for most cases and it could be simply achieved through full reconciliation that is carried out periodically (with a longer interval as compared to partial reconciliation).
+
+You can read more in this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/387090) and [conclusion comment](https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/merge_requests/13#note_1282495106)
+
+## Workspace states
+
+- `CreationRequested` - Initial state of a Workspace; Creation requested by user but hasn't yet been acted on
+- `Starting` - In the process of being ready for use
+- `Running` - Ready for use
+- `Stopping` - In the process of scaling down
+- `Stopped` - Persistent storage is still available but workspace has been scaled down
+- `Failed` - Kubernetes resources have been applied by `agentk` but are not ready due to various reasons (for example, crashing container)
+- `Error` - Kubernetes resources failed to get applied by `agentk`
+- `RestartRequested` - User has requested a restart of the workspace but the restart has not yet successfully happened
+- `Terminating` - User has requested the termination of the workspace and the action has been initiated but not yet completed.
+- `Terminated` - Persistent storage has been deleted and the workspace has been scaled down
+- `Unknown` - Not able to understand the actual state of the workspace
+
+### Possible `actual_state` values
+
+The `actual_state` values are determined from the `status` attribute in the Kubernetes deployment changes, which the agent listens to and sends to Rails.
+
+The following diagram represents the typical flow of the `actual_state` values for a `Workspace` record based on the
+`status` values received from the agent. The `status` is parsed to derive the `actual_state` of the workspace based on different conditions.
+
+However, any of these states can be skipped if there have been any
+transitional `status` updates that were not received from the agent for some reason (a quick transition, a
+failure to send the event, etc).
 
-Additionally, Remote Development workspaces could provide a way to implement disaster recovery if we are able to leverage the capabilities of [Pods](../../../architecture/blueprints/pods/index.md).
+```plantuml
+[*] --> CreationRequested
+CreationRequested : Initial state before\nworkspace creation\nrequest is sent\nto kubernetes
+CreationRequested -right-> Starting : status=Starting
+CreationRequested -right-> Error : Could not create\nworkspace
+
+Starting : Workspace config is being\napplied to kubernetes
+Starting -right-> Running : status=Running
+Starting -down-> Failed : status=Failed\n(container crashing)
+
+Running : Workspace is running
+Running -down-> Stopping : status=Stopping
+Running -down-> Failed : status=Failed\n(container crashing)
+Running -down-> Terminated : status=Terminated
+Running -right-> Error : Could not\nstop/terminate\nworkspace
+
+Stopping : Workspace is stopping
+Stopping -down-> Stopped : status=Stopped
+Stopping -left-> Failed : status=Failed\n(could not\nunmount volume\nand stop workspace)
+
+Stopped : Workspace is Stopped\nby user request
+Stopped -left-> Failed : status=Failed\n(could not\nunmount volume\nterminate workspace)
+Stopped -right-> Error : Could not\nstart/terminate\nworkspace
+Stopped -down-> Terminated : status=Terminated
+Stopped -up-> Starting : status=Starting
+
+Terminated: Workspace has been deleted
+
+Failed: Workspace is not ready due to\nvarious reasons(e.g. crashing container)
+Failed -up-> Starting : status=Starting\n(container\nnot crashing)
+Failed -right-> Stopped : status=Stopped
+Failed -down-> Terminated : status=Terminated
+Failed -down-> Error : Could not\nstop/terminate\nworkspace
+
+Error: Kubernetes resources failed to get applied
+Error -up-> Terminated : status=Terminated
+
+Unknown: Unable to understand the actual state of the workspace
+```
 
-### Scalability
+### Possible `desired_state` values
 
-As an organization begins to scale, they quickly realize the need to support additional types of projects that might require extensive workflows. Remote Development workspaces aim to solve that issue by abstracting away the burden of complex machine configuration, dependency management, and possible data-seeding issues.
+The `desired_state` values are determined from the user's request to Rails and are sent to the agent by Rails.
 
-To facilitate working on different features across different projects, Remote Development should allow each user to provision multiple workspaces to enable quick context switching.
+`desired_state` is a subset of the `actual_state` with only `Running`, `Stopped`, `Terminated` and `RestartRequested` values.
+The state reconciliation logic in Rails will
+continually attempt to transition the `actual_state` to the `desired_state` value, unless the workspace is in an unrecoverable state.
 
-Eventually, we should be able to allow users to vertically scale their workspaces with more compute cores, memory, and other resources. If a user is currently working against a 2 CPU and 4 GB RAM workspace but comes to find they need more CPU, they should be able to upgrade their compute layer to something more suitable with a click or CLI command within the workspace.
+There is also an additional supported state of `RestartRequested` which is only valid for `desired_state`.
+This value is not a valid value for `actual_state`. It is required in order for Rails to
+initiate a restart of a started workspace. It will only persist until a `status` of `Stopped` is received
+from the agent, indicating that the restart request was successful and in progress or completed.
+At this point, the `desired_state` will be automatically changed to `Running` to trigger the workspace to restart again.
+If there is a failure to restart the workspace, and a `Stopped` status is never received, the
+`desired_state` will remain `RestartRequested` until a new `desired_state` is specified.
 
-### Provide built-in security and enterprise readiness
+```plantuml
+[*] --> Running
+Running : Workspace is running
+Running -down-> Stopped : status=Stopped
+Running -left-> Terminated : status=Terminated
 
-As Remote Development becomes a viable replacement for Virtual Desktop Infrastructure solutions, they must be secure and support enterprise requirements, such as role-based access control and the ability to remove all source code from developer machines.
+Stopped : Workspace is Stopped\nby user request
+Stopped -up-> Running : status=Running
+Stopped -down-> Terminated : status=Terminated
 
-### Accelerate project and developer onboarding
+Terminated: Workspace has been deleted
 
-As a zero-install development environment that runs in your browser, Remote Development makes it easy for anyone to join your team and contribute to a project.
+RestartRequested : User has requested a workspace restart.\n**desired_state** will automatically change\nto **'Running'** if actual state\nof **'Stopped'** is received.
+RestartRequested -left-> Running : status=Running
+```
 
-### Regions
+## Workspace user traffic authentication and authorization
+
+We need to only allow certain users to access workspaces. Currently, we are restricting this to the creator/owner of the workspace. After the workspace is created, it needs to be exposed to the network so that the user can connect to it.
+Thus, any traffic incoming to the workspace needs to be authenticated and authorized.
+[`gitlab-workspaces-proxy`](https://gitlab.com/gitlab-org/remote-development/gitlab-workspaces-proxy) handles discovery, authentication and authorization of the workspaces running in a Kubernetes cluster.
+
+It will proxy all HTTP and WebSocket calls to the correct workspace. It will perform the following tasks:
+
+1. Workspace discovery - The proxy will auto discover workspaces based on labels of Kubernetes service resources. The proxy will watch the Kubernetes API for the creation/updation/deletion of Kubernetes service resources. When an service resource is created, the proxy will automatically configure itself to use corresponding service as an upstream. Thus it will require a Kubernetes service account and a role that allows it to watch, list and get service resources.
+1. Authentication - It will use the [OAuth 2.0 flow](../../../api/oauth2.md) with GitLab to authenticate the user. GitLab will act as the identity provider. If the customer uses a third party SSO service to log into GitLab, the flow would automatically delegate authentication to that provider. One of the complexities with authentication is the fact that each workspace is served on its own domain, and therefore we can't set the redirect URI on the GitLab app to a specific workspace. We need to set a state in the OAuth 2.0 flow to redirect to the correct workspace.
+1. Authorization - The proxy will make a call to a GitLab GraphQL endpoint with the user's credentials obtained in the authentication phase. The endpoint will validate if the user has access to the workspace and accordingly return either a 404 or a 200.
+1. Session Management - The proxy will be stateless and be deployed without additional third party software such as a cache or database, and therefore will be using a signed JWT to manage sessions. The JWT is signed using a key provided to the proxy during startup.
+
+All traffic incoming to the Kubernetes cluster on a given domain is forwarded to `gitlab-workspaces-proxy`, which then decides how to serve that traffic.
+
+```mermaid
+flowchart TB
+  UserWorkspaceTraffic[User Workspace Traffic] --> Ingress
+  subgraph WorkspaceCluster[Workspace Cluster]
+  Ingress --> GitLabWorkspacesProxy[GitLab Workspaces Proxy]
+  GitLabWorkspacesProxy --Proxy--> Workspace1[Workspace 1]
+  GitLabWorkspacesProxy --Proxy--> Workspace2[Workspace 2]
+  GitLabWorkspacesProxy --Proxy--> Workspace3[Workspace 3]
+  end
+  GitLabWorkspacesProxy --OAuth 2--> GitLab
+  GitLab --Redirect--> GitLabWorkspacesProxy
+  GitLabWorkspacesProxy --Authz API--> GitLab
+```
 
-GitLab.com is only hosted within the United States of America. Organizations located in other regions have voiced demand for local SaaS offerings. BYO infrastructure helps work in conjunction with [GitLab Regions](https://gitlab.com/groups/gitlab-org/-/epics/6037) because a user's workspace may be deployed within different geographies. The ability to deploy workspaces to different geographies might also help to solve data residency and compliance problems.
+- Advantages
+  - Single instance of proxy, and therefore it is easy to manage and get metrics from.
+  - Easy to upgrade as a single instance exists - workspaces do not need to be restarted.
+- Disadvantages
+  - Single point of failure
+  - It will have to scale with traffic
+  - New component (other than the GitLab Agent) that would have to be deployed in the Kubernetes cluster by the customer
+  - Does need Kubernetes privileges to list service resources.
+
+### Other options considered
+
+#### Sidecar proxy
+
+A sidecar will be injected into each workspace and all traffic to the workspace will flow through the sidecar. The sidecar will only handle the traffic for a single workspace. The sidecar can communicate with the workspace over the loopback interface (localhost) because the two share a network namespace.
+
+```mermaid
+flowchart TB
+  UserWorkspaceTraffic[User Workspace Traffic] --> Ingress
+  subgraph WorkspaceCluster[Workspace Cluster]
+    Ingress --> Workspace1Proxy
+    Ingress --> Workspace2Proxy
+    Ingress --> Workspace3Proxy
+    subgraph workspace1[Workspace 1]
+      Workspace1Proxy[Workspace Sidecar Proxy] --Proxy--> Workspace1[Workspace 1]
+    end
+    subgraph workspace2[Workspace 2]
+      Workspace2Proxy[Workspace Sidecar Proxy] --Proxy--> Workspace2[Workspace 2]
+    end
+    subgraph workspace3[Workspace 3]
+      Workspace3Proxy[Workspace Sidecar Proxy] --Proxy--> Workspace3[Workspace 3]
+    end
+  end
+
+  Workspace3Proxy --OAuth 2--> GitLab
+  GitLab --Redirect--> Workspace3Proxy
+  Workspace3Proxy --Authz API--> GitLab
+```
 
-## Market analysis
+- Advantages
+  - Does not need to handle a large volume of traffic
+  - If a sidecar stops working it does not hamper the working of other workspaces
+- Disadvantages
+  - Inefficient usage of resources as a sidecar will have to be deployed for every workspace
+  - Workspace might take slightly longer to come up because of the additional proxy element
+
+#### Auth annotations on the Ingress resource
+
+Use auth annotations on the Ingress resource to allow Ingress controllers(for example, `ingress-nginx`) to delegate authentication and authorization to a separate process. The challenge is that these annotations are not standardized (that is, not part of the [Ingress specification](https://kubernetes.io/docs/concepts/services-networking/ingress/)) and may not be supported across different Ingress controllers. We would need to document the process to setup our Auth provider for each of the Ingress controllers. However, if they do become a part of the new [Gateway API](https://gateway-api.sigs.k8s.io/concepts/security-model/), we will reconsider this decision.
+
+For `ingress-nginx`, the auth annotations would be:
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  annotations:
+    nginx.ingress.kubernetes.io/auth-url: "https://$host/oauth2/auth"
+    nginx.ingress.kubernetes.io/auth-signin: "https://$host/oauth2/start?rd=$escaped_request_uri"
+  name: example-ingress
+  namespace: example-namespace
+spec:
+  ingressClassName: nginx
+  rules:
+  - host: "*.workspaces.example.dev"
+    http:
+      paths:
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: example-workspace
+            port:
+              number: 80
+```
 
-We have conducted a market analysis to understand the broader market and what others can offer us by way of open-source libraries, integrations, or partnership opportunities. We have broken down the effort into a set of issues where we investigate each potential competitor/pathway/partnership as a spike.
+For `traefik`, the auth annotations would be:
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: example-ingress
+  namespace: example-namespace
+  annotations:
+    kubernetes.io/ingress.class: traefik
+    ingress.kubernetes.io/auth-type: forward
+    ingress.kubernetes.io/auth-url: http://traefik-forward-auth:4181
+    ingress.kubernetes.io/auth-response-headers: X-Forwarded-User
+spec:
+  ingressClassName: traefik
+  rules:
+  - host: "*.workspaces.example.dev"
+    http:
+      paths:
+      - backend:
+          name: example-workspace
+          servicePort: http
+```
 
-- [Market analysis](https://gitlab.com/groups/gitlab-org/-/epics/8131)
-- [YouTube results](https://www.youtube.com/playlist?list=PL05JrBw4t0KrRQhnSYRNh1s1mEUypx67-)
+For `Google Cloud Load Balancer using IAP`, the auth annotations would be:
+
+```yaml
+apiVersion: cloud.google.com/v1
+kind: BackendConfig
+metadata:
+  name: example-backend-config
+  namespace: example-namespace
+spec:
+  iap:
+    enabled: true
+    oauthclientCredentials:
+      secretName: example-secret
+```
 
-### Implementation
+## Accessing the Web IDE from the workspace
 
-- [Viable Maturity Epic](https://gitlab.com/groups/gitlab-org/-/epics/9190) to track progress.
-- [Documentation](https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs)
-explaining the architecture and implementation details.
+Currently, we only support GitLab fork of VS Code as the editor that is injected inside a workspace during runtime.
+The [editor injector](https://gitlab.com/gitlab-org/gitlab-web-ide-vscode-fork/-/tree/main/scripts/gl/editor-injector) is a container image that contains GitLab fork of VS Code server.
+The editor injector contains scripts for copying this server into a workspace and starting the server.
 
-## Che vs. DevWorkspace Operatoor vs. Custom-Built Solution
+The editor injector packages both the WebUI and the Extension Host (VS Code backend). [Currently](https://gitlab.com/gitlab-org/gitlab/-/issues/393006), we also package the WebUI in the workspace. That means that the GitLab fork of VS Code editor can be used two ways:
 
-After an investigation into using [Che](https://gitlab.com/gitlab-org/gitlab/-/issues/366052) as our backend to accelerate Remote Development, we ultimately opted to [write our own custom-built solution using DevWorkspace Operator](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/97449#note_1131215629).
+- Access the Workspace URL **directly** and use the bundled WebUI
+- Access the Workspace through **WebIDE** (ignore the bundled WebUI)
 
-Some advantages of us opting to write our own custom-built solution are:
+```plantuml
+@startuml
 
-- We can still use the core DevWorkspace Operator and build on top of it.
-- It is easier to add support for other configurations apart from `devfile` in the future if the need arises.
-- We have the ability to choose which tech stack to use (for example, instead of using Traefik which is used in Che, explore NGINX itself or use GitLab Agent for Kubernetes).
+title
+  Accessing the editor inside a workspace
+end title
 
-After writing our own custom-built solution using DevWorkspace Operator,
-we decided to [remove the dependency on DevWorkspace Operator](https://gitlab.com/groups/gitlab-org/-/epics/9895)
-and thus the transitive dependency of Cert Manager.
+node "Workspace" {
+  node "GitLab fork of VS Code" {
+    [HTTP Server] .[#blue]up.> [Static assets of the WebUI]
+    [HTTP Server] -[#blue]-> [Extension Server (VS Code backend)]
+    [HTTP Server] -[#green]-> [Extension Server (VS Code backend)]
+  }
+}
+
+[Workspace URL in browser] -[#blue]right-> [HTTP Server]
+[Workspace URL in browser] .[#blue]right.> [HTTP Server]
+[WebIDE URL in browser] -[#green]left-> [HTTP Server]
+
+note right of "Static assets of the WebUI"
+  We build WebIDE on top of these assets
+end note
+
+note bottom of "Workspace URL in browser"
+  Accessing the workspace directly
+  uses the packaged WebUI
+end note
+
+note bottom of "WebIDE URL in browser"
+  Accessing the workspace through WebIDE
+  ignores the web assets in the workspace
+  and only uses the WebSocket connection
+end note
+
+@enduml
+```
+
+## Building container images for workspaces
+
+We rely on file group permissions to be able to modify and run any file in a container.
+Thus, while creating the workspace, we use an arbitrary Linux user to run the container.
+If the container image you want to use does not support arbitrary user IDs, you can build you own by using the snippet below. This snippet is provided only for reference. If there are other locations in the container that should have write access to the Linux user running the container, make sure those files and folders have the desired root Linux group permissions that we rely on.
+
+```dockerfile
+FROM IMAGE_OF_YOUR_CHOICE
+
+RUN useradd -l -u 33333 -G sudo -md /home/gitlab-workspaces -s /bin/bash -p gitlab-workspaces gitlab-workspaces
+
+ENV HOME=/home/gitlab-workspaces
+
+WORKDIR $HOME
+
+RUN mkdir -p /home/gitlab-workspaces && chgrp -R 0 /home && chmod -R g=u /etc/passwd /etc/group /home
+
+USER gitlab-workspaces
+```
+
+You can read more about this decision in this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/396300#note_1375061754).
 
 ## Links
 
+- [Remote Development direction](https://about.gitlab.com/direction/create/editor/remote_development)
 - [Remote Development presentation](https://docs.google.com/presentation/d/1XHH_ZilZPufQoWVWViv3evipI-BnAvRQrdvzlhBuumw/edit#slide=id.g131f2bb72e4_0_8)
 - [Category Strategy epic](https://gitlab.com/groups/gitlab-org/-/epics/7419)
 - [Minimal Maturity epic](https://gitlab.com/groups/gitlab-org/-/epics/9189)
 - [Viable Maturity epic](https://gitlab.com/groups/gitlab-org/-/epics/9190)
 - [Complete Maturity epic](https://gitlab.com/groups/gitlab-org/-/epics/9191)
-- [Remote Development sync](https://docs.google.com/document/d/1hWVvksIc7VzZjG-0iSlzBnLpyr-OjwBVCYMxsBB3h_E/edit#)
+- [Remote Development Engineering Sync](https://docs.google.com/document/d/1hWVvksIc7VzZjG-0iSlzBnLpyr-OjwBVCYMxsBB3h_E/edit#)
 - [Market analysis and architecture](https://gitlab.com/groups/gitlab-org/-/epics/8131)
-- [GA4K Architecture](https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/blob/main/doc/architecture.md)
+- [Developer Documentation](https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/)
 - [BYO infrastructure](https://gitlab.com/groups/gitlab-org/-/epics/8290)
 - [Browser runtime](https://gitlab.com/groups/gitlab-org/-/epics/8291)
 - [GitLab-hosted infrastructure](https://gitlab.com/groups/gitlab-org/-/epics/8292)
-- [Browser runtime spike](https://gitlab.com/gitlab-org/gitlab-web-ide/-/merge_requests/58).
-- [Remote Development direction](https://about.gitlab.com/direction/create/editor/remote_development)
+- [Browser runtime spike](https://gitlab.com/gitlab-org/gitlab-web-ide/-/merge_requests/58)
 - [Ideal user journey](https://about.gitlab.com/direction/create/editor/remote_development/#ideal-user-journey)
+- [Building container images for workspaces](https://gitlab.com/gitlab-org/gitlab/-/issues/396300#note_1375061754)
diff --git a/doc/architecture/blueprints/runner_tokens/index.md b/doc/architecture/blueprints/runner_tokens/index.md
index 0d3cc9c3e17..c83586f851a 100644
--- a/doc/architecture/blueprints/runner_tokens/index.md
+++ b/doc/architecture/blueprints/runner_tokens/index.md
@@ -54,13 +54,13 @@ The remaining concerns become non-issues due to the elimination of the registrat
 graph TD
     subgraph new[<b>New registration flow</b>]
     A[<b>GitLab</b>: User creates a runner in GitLab UI and adds the runner configuration] -->|<b>GitLab</b>: creates ci_runners record and returns<br/>new 'glrt-' prefixed authentication token| B
-    B(<b>Runner</b>: User runs 'gitlab-runner register' command with</br>authentication token to register new runner machine with<br/>the GitLab instance) --> C{<b>Runner</b>: Does a .runner_system_id file exist in<br/>the gitlab-runner configuration directory?}
+    B(<b>Runner</b>: User runs 'gitlab-runner register' command with</br>authentication token to register new runner manager with<br/>the GitLab instance) --> C{<b>Runner</b>: Does a .runner_system_id file exist in<br/>the gitlab-runner configuration directory?}
     C -->|Yes| D[<b>Runner</b>: Reads existing system ID] --> F
     C -->|No| E[<b>Runner</b>: Generates and persists unique system ID] --> F
     F[<b>Runner</b>: Issues 'POST /runner/verify' request<br/>to verify authentication token validity] --> G{<b>GitLab</b>: Is the authentication token valid?}
     G -->|Yes| H[<b>GitLab</b>: Creates ci_runner_machine database record if missing] --> J[<b>Runner</b>: Store authentication token in .config.toml]
     G -->|No| I(<b>GitLab</b>: Returns '403 Forbidden' error) --> K(gitlab-runner register command fails)
-    J --> Z(Runner and runner machine are ready for use)
+    J --> Z(Runner and runner manager are ready for use)
     end
 
     subgraph current[<b>Current registration flow</b>]
@@ -158,7 +158,7 @@ wherever it publishes the short token SHA.
 Given that the runner can potentially be reused with different unique system identifiers,
 we should store the unique system ID in the database.
 This ensures the unique system ID maps to a GitLab Runner's `system_id` value with the runner token.
-A new `ci_runner_machines` table holds information about each unique runner machine,
+A new `ci_runner_machines` table holds information about each unique runner manager,
 with information regarding when the runner last connected, and what type of runner it was.
 
 In the long term, the relevant fields are to be moved from the `ci_runners` into
@@ -398,7 +398,7 @@ scope.
 | GitLab Runner    | `%15.10` | Make the `gitlab-runner register` command happen in a single operation. |
 | GitLab Rails app | `%15.10` | Define feature flag and policies for "New Runner creation workflow" for groups and projects. |
 | GitLab Rails app | `%15.10` | Only update runner `contacted_at` and `status` when polled for jobs. |
-| GitLab Rails app | `%15.10` | Add GraphQL type to represent runner machines under `CiRunner`. |
+| GitLab Rails app | `%15.10` | Add GraphQL type to represent runner managers under `CiRunner`. |
 | GitLab Rails app | `%15.11` | Implement UI to create new instance runner. |
 | GitLab Rails app | `%15.11` | Update service and mutation to accept groups and projects. |
 | GitLab Rails app | `%15.11` | Implement UI to create new group/project runners. |
@@ -411,117 +411,37 @@ scope.
 
 ### Stage 5 - Optional disabling of registration token
 
-| Component        | Milestone | Changes |
-|------------------|----------:|---------|
-| GitLab Rails app | `%16.0` | Adapt `register_{group|project}_runner` permissions to take [application setting](https://gitlab.com/gitlab-org/gitlab/-/issues/386712) in consideration. |
-| GitLab Rails app | | Add UI to allow disabling use of registration tokens at project or group level. |
-| GitLab Rails app | | Introduce `:enforce_create_runner_workflow` feature flag (disabled by default) to control whether use of registration tokens is allowed. |
-| GitLab Rails app | | Make [`POST /api/v4/runners` endpoint](../../../api/runners.md#register-a-new-runner) permanently return `HTTP 410 Gone` if either `allow_runner_registration_token` setting or `:enforce_create_runner_workflow` feature flag disables registration tokens.<br/>A future v5 version of the API should return `HTTP 404 Not Found`. |
-| GitLab Rails app | | Start refusing job requests that don't include a unique ID, if either `allow_runner_registration_token` setting or `:enforce_create_runner_workflow` feature flag disables registration tokens. |
-| GitLab Rails app | | Hide legacy UI showing registration with a registration token, if `:enforce_create_runner_workflow` feature flag disables registration tokens. |
+| Component        | Milestone | Changes                                                                                                                                                                                                                                                                                                                            |
+|------------------|----------:|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| GitLab Rails app | `%16.0`   | Adapt `register_{group|project}_runner` permissions to take [application setting](https://gitlab.com/gitlab-org/gitlab/-/issues/386712) in consideration. |
+| GitLab Rails app | `%16.1`   | Make [`POST /api/v4/runners` endpoint](../../../api/runners.md#register-a-new-runner) permanently return `HTTP 410 Gone` if either `allow_runner_registration_token` setting disables registration tokens.<br/>A future v5 version of the API should return `HTTP 404 Not Found`. |
+| GitLab Rails app | `%16.1`   | Add runner group metadata to the runner list. |
+| GitLab Rails app |           | Add UI to allow disabling use of registration tokens in top-level group settings.                                                                                                                                                                                                                                                               |
+| GitLab Rails app |           | Hide legacy UI showing registration with a registration token, if it disabled on in top-level group settings or by admins.                                                                                                                                                                                                         |
 
 ### Stage 6 - Enforcement
 
-| Component        | Milestone | Changes |
-|------------------|----------:|---------|
-| GitLab Rails app | `%16.6`   | Enable `:enforce_create_runner_workflow` feature flag by default. |
-| GitLab Rails app | `%16.6`   | Start reject job requests that don't include `system_id` value. |
+| Component        | Milestone | Changes                                                                                                                                                                  |
+|------------------|----------:|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| GitLab Rails app |   `%16.6` | Disable registration tokens for all groups by running database migration (only on GitLab.com)                                                                            |                                                                                                   |
+| GitLab Rails app |   `%16.6` | Disable registration tokens on the instance level by running database migration (except GitLab.com)                                                                      |                                                                                                   |
+| GitLab Rails app |   `%16.8` | Disable registration tokens on the instance level for GitLab.com                                                                                                         |                                                                                                   |
+| GitLab Rails app |   `%16.3` | Implement new `:create_runner` PPGAT scope so that we don't require a full `api` scope.                                                                                  |
+| GitLab Rails app |           | Document gotchas when [automatically rotating runner tokens](../../../ci/runners/configure_runners.md#automatically-rotate-authentication-tokens) with multiple machines. |
 
 ### Stage 7 - Removals
 
-| Component        | Milestone | Changes |
-|------------------|----------:|---------|
-| GitLab Rails app | `17.0` | Remove legacy UI showing registration with a registration token. |
-| GitLab Runner    | `17.0` | Remove runner model arguments from `register` command (for example `--run-untagged`, `--tag-list`, etc.) |
-| GitLab Rails app | `17.0` | Create database migrations to drop `allow_runner_registration_token` setting columns from `application_settings` and `namespace_settings` tables. |
-| GitLab Rails app | `17.0` | Create database migrations to drop:<br/>- `runners_registration_token`/`runners_registration_token_encrypted` columns from `application_settings`;<br/>- `runners_token`/`runners_token_encrypted` from `namespaces` table;<br/>- `runners_token`/`runners_token_encrypted` from `projects` table. |
-| GitLab Rails app | `17.0` | Remove `:enforce_create_runner_workflow` feature flag. |
+| Component        | Milestone | Changes                                                                                                                                                                                                                                                                                            |
+|------------------|----------:|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| GitLab Rails app | `17.0`    | Remove UI enabling registration tokens on the group and instance levels.                                                                                                                                                                                                                           |
+| GitLab Rails app | `17.0`    | Remove legacy UI showing registration with a registration token.                                                                                                                                                                                                                                   |
+| GitLab Runner    | `17.0`    | Remove runner model arguments from `register` command (for example `--run-untagged`, `--tag-list`, etc.)                                                                                                                                                                                           |
+| GitLab Rails app | `17.0`    | Create database migrations to drop `allow_runner_registration_token` setting columns from `application_settings` and `namespace_settings` tables.                                                                                                                                                  |
+| GitLab Rails app | `17.0`    | Create database migrations to drop:<br/>- `runners_registration_token`/`runners_registration_token_encrypted` columns from `application_settings`;<br/>- `runners_token`/`runners_token_encrypted` from `namespaces` table;<br/>- `runners_token`/`runners_token_encrypted` from `projects` table. |
 
 ## FAQ
 
-### Will my runner registration workflow break?
-
-If no action is taken before your GitLab instance is upgraded to 16.6, then your runner registration
-worflow will break.
-For self-managed instances, to continue using the previous runner registration process,
-you can disable the `enforce_create_runner_workflow` feature flag until GitLab 17.0.
-
-To avoid a broken workflow, you need to first create a runner in the GitLab runners admin page.
-After that, you'll need to replace the registration token you're using in your runner registration
-workflow with the obtained runner authentication token.
-
-### What is the new runner registration process?
-
-When the new runner registration process is introduced, you will:
-
-1. Create a runner directly in the GitLab UI.
-1. Receive an authentication token in return.
-1. Use the authentication token instead of the registration token.
-
-This has added benefits such as preserved ownership records for runners, and minimizes
-impact on users.
-The addition of a unique system ID ensures that you can reuse the same authentication token across
-multiple runners.
-For example, in an auto-scaling scenario where a runner manager spawns a runner process with a
-fixed authentication token.
-This ID generates once at the runner's startup, persists in a sidecar file, and is sent to the
-GitLab instance when requesting jobs.
-This allows the GitLab instance to display which system executed a given job.
-
-### What is the estimated timeframe for the planned changes?
-
-- In GitLab 15.10, we plan to implement runner creation directly in the runners administration page,
-  and prepare the runner to follow the new workflow.
-- In GitLab 16.6, we plan to disable registration tokens.
-  For self-managed instances, to continue using
-  registration tokens, you can disable the `enforce_create_runner_workflow` feature flag until
-  GitLab 17.0.
-
-  Previous `gitlab-runner` versions (that don't include the new `system_id` value) will start to be
-  rejected by the GitLab instance;
-- In GitLab 17.0, we plan to completely remove support for runner registration tokens.
-
-### How will the `gitlab-runner register` command syntax change?
-
-The `gitlab-runner register` command will stop accepting registration tokens and instead accept new
-authentication tokens generated in the GitLab runners administration page.
-These authentication tokens are recognizable by their `glrt-` prefix.
-
-Example command for GitLab 15.9:
-
-```shell
-gitlab-runner register
-    --executor "shell" \
-    --url "https://gitlab.com/" \
-    --tag-list "shell,mac,gdk,test" \
-    --run-untagged="false" \
-    --locked="false" \
-    --access-level="not_protected" \
-    --non-interactive \
-    --registration-token="GR1348941C6YcZVddc8kjtdU-yWYD"
-```
-
-In GitLab 16.0, the runner will be created in the UI where some of its attributes can be
-pre-configured by the creator.
-Examples are the tag list, locked status, or access level. These are no longer accepted as arguments
-to `register`. The following example shows the new command:
-
-```shell
-gitlab-runner register
-    --executor "shell" \
-    --url "https://gitlab.com/" \
-    --non-interactive \
-    --registration-token="glrt-2CR8_eVxiioB1QmzPZwa"
-```
-
-### How does this change impact auto-scaling scenarios?
-
-In auto-scaling scenarios such as GitLab Runner Operator or GitLab Runner Helm Chart, the
-registration token is replaced with the authentication token generated from the UI.
-This means that the same runner configuration is reused across jobs, instead of creating a runner
-for each job.
-The specific runner can be identified by the unique system ID that is generated when the runner
-process is started.
+Please follow [the user documentation](../../../ci/runners/new_creation_workflow.md).
 
 ## Status
 
@@ -537,7 +457,7 @@ Proposal:
 |------------------------------|--------------------------------------------------|
 | Authors                      | Kamil Trzciński, Tomasz Maczukin, Pedro Pombeiro |
 | Architecture Evolution Coach | Kamil Trzciński                                  |
-| Engineering Leader           | Elliot Rushton, Cheryl Li                        |
+| Engineering Leader           | Nicole Williams, Cheryl Li                       |
 | Product Manager              | Darren Eastman, Jackie Porter                    |
 | Domain Expert / Runner       | Tomasz Maczukin                                  |
 
@@ -545,7 +465,7 @@ DRIs:
 
 | Role                         | Who                             |
 |------------------------------|---------------------------------|
-| Leadership                   | Elliot Rushton                  |
+| Leadership                   | Nicole Williams                 |
 | Product                      | Darren Eastman                  |
 | Engineering                  | Tomasz Maczukin, Pedro Pombeiro |
 
diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md
index e9d3dae3837..1822e610dad 100644
--- a/doc/ci/caching/index.md
+++ b/doc/ci/caching/index.md
@@ -99,7 +99,10 @@ the global fallback cache is fetched every time a cache is not found.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110467) in GitLab 16.0
 
-Each cache entry supports up-to 5 fallback keys:
+Each cache entry supports up to five fallback keys with the [`fallback_keys` keyword](../yaml/index.md#cachefallback_keys).
+When a job does not find a cache key, the job attempts to retrieve a fallback cache instead.
+Fallback keys are searched in order until a cache is found. If no cache is found,
+the job runs without using a cache. For example:
 
 ```yaml
 test-job:
@@ -114,11 +117,25 @@ test-job:
   script:
     - bundle config set --local path 'vendor/ruby'
     - bundle install
-    - yarn install --cache-folder .yarn-cache
     - echo Run tests...
 ```
 
-Fallback keys follows the same processing logic as `cache:key`, meaning that the fullname may include a `-$index` (based on cache clearance) and `-protected`/`-non_protected` (if cache separation enabled on protected branches) suffixes.
+In this example:
+
+1. The job looks for the `cache-$CI_COMMIT_REF_SLUG` cache.
+1. If `cache-$CI_COMMIT_REF_SLUG` is not found, the job looks for `cache-$CI_DEFAULT_BRANCH`
+   as a fallback option.
+1. If `cache-$CI_DEFAULT_BRANCH` is also not found, the job looks for `cache-default`
+   as a second fallback option.
+1. If none are found, the job downloads all the Ruby dependencies without using a cache,
+   but creates a new cache for `cache-$CI_COMMIT_REF_SLUG` when the job completes.
+
+Fallback keys follow the same processing logic as `cache:key`:
+
+- If you [clear caches manually](#clear-the-cache-manually), per-cache fallback keys are appended
+  with an index like other cache keys.
+- If the [**Use separate caches for protected branches** setting](#cache-key-names) is enabled,
+  per-cache fallback keys are appended with `-protected` or `-non_protected`.
 
 ### Global fallback key
 
@@ -244,6 +261,39 @@ cache:
   key: $CI_JOB_NAME
 ```
 
+### Use a variable to control a job's cache policy
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/371480) in GitLab 16.1.
+
+To reduce duplication of jobs where the only difference is the pull policy, you can use a [CI/CD variable](../variables/index.md).
+
+For example:
+
+```yaml
+conditional-policy:
+  rules:
+    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
+      variables:
+        POLICY: pull-push
+    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
+      variables:
+        POLICY: pull
+  stage: build
+  cache:
+    key: gems
+    policy: $POLICY
+    paths:
+      - vendor/bundle
+  script:
+    - echo "This job pulls and pushes the cache depending on the branch"
+    - echo "Downloading dependencies..."
+```
+
+In this example, the job's cache policy is:
+
+- `pull-push` for changes to the default branch.
+- `pull` for changes to other branches.
+
 ### Cache Node.js dependencies
 
 If your project uses [npm](https://www.npmjs.com/) to install Node.js
@@ -352,7 +402,7 @@ variables:
   PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
 
 # Pip's cache doesn't store the python packages
-# https://pip.pypa.io/en/stable/reference/pip_install/#caching
+# https://pip.pypa.io/en/stable/topics/caching/
 cache:
   paths:
     - .cache/pip
@@ -485,7 +535,7 @@ be overwritten because caches are restored before artifacts.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330047) in GitLab 15.0.
 
-A suffix is added to the cache key, with the exception of the [fallback cache key](#use-a-fallback-cache-key).
+A suffix is added to the cache key, with the exception of the [global fallback cache key](#global-fallback-key).
 
 As an example, assuming that `cache.key` is set to `$CI_COMMIT_REF_SLUG`, and that we have two branches `main`
 and `feature`, then the following table represents the resulting cache keys:
@@ -507,8 +557,8 @@ and should only be disabled in an environment where all users with Developer rol
 
 To use the same cache for all branches:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 1. Clear the **Use separate caches for protected branches** checkbox.
 1. Select **Save changes**.
@@ -604,8 +654,8 @@ The next time the pipeline runs, the cache is stored in a different location.
 
 You can clear the cache in the GitLab UI:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **CI/CD > Pipelines**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Build > Pipelines**.
 1. In the upper-right corner, select **Clear runner caches**.
 
 On the next commit, your CI/CD jobs use a new cache.
diff --git a/doc/ci/chatops/index.md b/doc/ci/chatops/index.md
index 6dff87ed1c5..7be12d0c0fd 100644
--- a/doc/ci/chatops/index.md
+++ b/doc/ci/chatops/index.md
@@ -1,6 +1,6 @@
 ---
-stage: Manage
-group: Import and Integrate
+stage: Deploy
+group: Environments
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 type: index, concepts, howto
 ---
diff --git a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
index ceb56b01dcd..5494e5fad1c 100644
--- a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
+++ b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
@@ -15,7 +15,8 @@ GitLab CI/CD can be used with Bitbucket Cloud by:
 To use GitLab CI/CD with a Bitbucket Cloud repository:
 
 1. In GitLab, create a project:
-   1. In GitLab, on the top bar, select **Main menu > Projects > View all projects**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **View all your projects**.
    1. On the right of the page, select **New project**.
    1. Select **Run CI/CD for external repository**.
    1. Select **Repository by URL**.
diff --git a/doc/ci/ci_cd_for_external_repos/github_integration.md b/doc/ci/ci_cd_for_external_repos/github_integration.md
index 9933fafcb69..feb01a0fc4a 100644
--- a/doc/ci/ci_cd_for_external_repos/github_integration.md
+++ b/doc/ci/ci_cd_for_external_repos/github_integration.md
@@ -34,7 +34,8 @@ repositories:
       `repo` and `admin:repo_hook` so that GitLab can access your project,
       update commit statuses, and create a web hook to notify GitLab of new commits.
 1. In GitLab, create a project:
-   1. In GitLab, on the top bar, select **Main menu > Projects > View all projects**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **View all your projects**.
    1. On the right of the page, select **New project**.
    1. Select **Run CI/CD for external repository**.
    1. Select **GitHub**.
@@ -62,8 +63,9 @@ To manually enable GitLab CI/CD for your repository:
    1. Enter a **Token description** and update the scope to allow
       `repo` so that GitLab can access your project and update commit statuses.
 1. In GitLab, create a project:
-   1. In GitLab, on the top bar, select **Main menu > Projects > View all projects**.
-   1. On the right of the page, select **New project**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **View all your projects**.
+   1. Select **New project**.
    1. Select **Run CI/CD for external repository** and **Repository by URL**.
    1. In the **Git repository URL** field, enter the HTTPS URL for your GitHub repository.
       If your project is private, use the personal access token you just created for authentication.
diff --git a/doc/ci/ci_cd_for_external_repos/index.md b/doc/ci/ci_cd_for_external_repos/index.md
index 7b9145050bf..6d14928389d 100644
--- a/doc/ci/ci_cd_for_external_repos/index.md
+++ b/doc/ci/ci_cd_for_external_repos/index.md
@@ -24,12 +24,17 @@ snippets disabled. These features
 
 To connect to an external repository:
 
-1. In GitLab, on the top bar, select **Main menu > Projects > View all projects**.
-1. On the right of the page, select **New project**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your projects**.
+1. Select **New project**.
 1. Select **Run CI/CD for external repository**.
 1. Select **GitHub** or **Repository by URL**.
 1. Complete the fields.
 
+If the **Run CI/CD for external repository** option is not available, the GitLab instance
+might not have any import sources configured. Ask an administrator for your instance to check
+the [import sources configuration](../../user/admin_area/settings/visibility_and_access_controls.md#configure-allowed-import-sources).
+
 ## Pipelines for external pull requests
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/65139) in GitLab 12.3.
diff --git a/doc/ci/cloud_services/azure/index.md b/doc/ci/cloud_services/azure/index.md
index 912e6597985..29d27e440ec 100644
--- a/doc/ci/cloud_services/azure/index.md
+++ b/doc/ci/cloud_services/azure/index.md
@@ -34,7 +34,7 @@ To complete this tutorial:
 1. [Grant permissions for the service principal](#grant-permissions-for-the-service-principal).
 1. [Retrieve a temporary credential](#retrieve-a-temporary-credential).
 
-For more information, review Azure's documentation on [Workload identity federation](https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation).
+For more information, review Azure's documentation on [Workload identity federation](https://learn.microsoft.com/en-us/azure/active-directory/workload-identities/workload-identity-federation).
 
 ## Create Azure AD application and service principal
 
diff --git a/doc/ci/cloud_services/google_cloud/index.md b/doc/ci/cloud_services/google_cloud/index.md
index 5ed22883518..d99b50b5013 100644
--- a/doc/ci/cloud_services/google_cloud/index.md
+++ b/doc/ci/cloud_services/google_cloud/index.md
@@ -114,6 +114,17 @@ the assertion in the previous section.
 After you configure the OIDC and role, the GitLab CI/CD job can retrieve a temporary credential from the
 [Google Cloud Security Token Service (STS)](https://cloud.google.com/iam/docs/reference/sts/rest).
 
+Add `id_tokens` to your CI/CD job:
+
+```yaml
+job:
+  id_tokens:
+    GITLAB_OIDC_TOKEN:
+      aud: https://gitlab.example.com
+```
+
+Get temporary credentials using the ID token:
+
 ```shell
 PAYLOAD="$(cat <<EOF
 {
@@ -122,7 +133,7 @@ PAYLOAD="$(cat <<EOF
   "requestedTokenType": "urn:ietf:params:oauth:token-type:access_token",
   "scope": "https://www.googleapis.com/auth/cloud-platform",
   "subjectTokenType": "urn:ietf:params:oauth:token-type:jwt",
-  "subjectToken": "${CI_JOB_JWT_V2}"
+  "subjectToken": "${GITLAB_OIDC_TOKEN}"
 }
 EOF
 )"
@@ -142,8 +153,7 @@ Where:
 - `PROJECT_NUMBER` is your Google Cloud project number (not name).
 - `POOL_ID` is the ID of the Workload Identity Pool created in the first section.
 - `PROVIDER_ID` is the ID of the Workload Identity Provider created in the second section.
-- `CI_JOB_JWT_V2` is injected into the CI/CD job by GitLab. For more information about
-  this variable, read [Connect to cloud services](../index.md).
+- `GITLAB_OIDC_TOKEN` is an OIDC [ID token](../../yaml/index.md#id_tokens).
 
 You can then use the resulting federated token to impersonate the service account created
 in the previous section:
diff --git a/doc/ci/cloud_services/index.md b/doc/ci/cloud_services/index.md
index 54cadc9e1b6..eadf0656d48 100644
--- a/doc/ci/cloud_services/index.md
+++ b/doc/ci/cloud_services/index.md
@@ -38,8 +38,7 @@ ID tokens support cloud providers with OIDC, including:
 NOTE:
 Configuring OIDC enables JWT token access to the target environments for all pipelines.
 When you configure OIDC for a pipeline, you should complete a software supply chain security
-review for the pipeline, focusing on the additional access. You can use the [software supply chain security awareness assessment](https://about.gitlab.com/quiz/software-supply-chain-security/)
-as a starting point, and for more information about supply chain attacks, see
+review for the pipeline, focusing on the additional access. For more information about supply chain attacks, see
 [How a DevOps Platform helps protect against supply chain attacks](https://about.gitlab.com/blog/2021/04/28/devops-platform-supply-chain-attacks/).
 
 ## Use cases
diff --git a/doc/ci/components/index.md b/doc/ci/components/index.md
index 95a513220a2..999c9b0c0fb 100644
--- a/doc/ci/components/index.md
+++ b/doc/ci/components/index.md
@@ -7,7 +7,7 @@ type: reference
 
 # CI/CD Components (Experimental)
 
-> Introduced in GitLab 16.0 as an [experimental feature](../../policy/alpha-beta-support.md).
+> Introduced in GitLab 16.0 as an [experimental feature](../../policy/experiment-beta-support.md).
 
 FLAG:
 On self-managed GitLab, by default this feature is not available.
@@ -173,6 +173,7 @@ For example, for a component repository located at `gitlab-org/dast` on `gitlab.
 
 **Additional notes:**
 
+- You can only reference components in the same GitLab instance as your project.
 - If a tag and branch exist with the same name, the tag takes precedence over the branch.
 - If a tag is named the same as a commit SHA that exists, like `e3262fdd0914fa823210cdb79a8c421e2cef79d8`,
   the commit SHA takes precedence over the tag.
@@ -189,13 +190,12 @@ After components are added to a components repository, they can immediately be [
 However, this repository is not discoverable. You must mark this project as a catalog resource to allow it to be visible in the CI Catalog
 so other users can discover it.
 
-To mark a project as a catalog resource, run the following [graphQL](../../api/graphql/index.md)
-mutation:
+To mark a project as a catalog resource:
 
-```graphql
-mutation {
-    catalogResourcesCreate(input: { projectPath: "path-to-project"}) {
-      errors
-  }
-}
-```
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Visibility, project features, permissions**.
+1. Scroll down to **CI/CD Catalog resource** and select the toggle to mark the project as a catalog resource.
+
+NOTE:
+This action is not reversible.
diff --git a/doc/ci/directed_acyclic_graph/index.md b/doc/ci/directed_acyclic_graph/index.md
index f0384fb29c7..e3bbe5b66c7 100644
--- a/doc/ci/directed_acyclic_graph/index.md
+++ b/doc/ci/directed_acyclic_graph/index.md
@@ -81,7 +81,7 @@ are certain use cases that you may need to work around. For more information, ch
 
 ## Needs Visualization
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215517) in GitLab 13.1 as a [Beta feature](../../policy/alpha-beta-support.md#beta).
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215517) in GitLab 13.1 as a [Beta feature](../../policy/experiment-beta-support.md#beta).
 > - It became a [standard feature](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38517) in 13.3.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52208) in GitLab 13.9.
 
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index fe57b451146..004da63476e 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -352,11 +352,9 @@ Docker-in-Docker is the recommended configuration, but you should be aware of th
 To use Docker commands in your CI/CD jobs, you can bind-mount `/var/run/docker.sock` into the
 container. Docker is then available in the context of the image.
 
-NOTE:
-If you bind the Docker socket and you are
-[using GitLab Runner 11.11 or later](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1261),
-you can no longer use `docker:20.10.16-dind` as a service. Volume bindings
-also affect services, making them incompatible.
+> If you bind the Docker socket and you are [using GitLab Runner 11.11 or later](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1261),
+> you can no longer use `docker:20.10.16-dind` as a service.
+> Volume bindings also affect services, making them incompatible.
 
 To make Docker available in the context of the image, you need to mount
 `/var/run/docker.sock` into the launched containers. To do this with the Docker
@@ -392,6 +390,12 @@ sudo gitlab-runner register -n \
   --docker-volumes /var/run/docker.sock:/var/run/docker.sock
 ```
 
+> If you want to use more complex Docker-in-Docker configurations, like it is necessary to run Code Quality checks with
+> Code Climate, you need to ensure that the paths to the build directory are the same on the host as well as inside the
+> Docker container.
+> See section "[Improve Code Quality performance with private runners](../testing/code_quality.md#improve-code-quality-performance-with-private-runners)"
+> in the Code Quality documentation.
+
 #### Enable registry mirror for `docker:dind` service
 
 When the Docker daemon starts inside the service container, it uses
diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md
index 32f95052980..b7affe28984 100644
--- a/doc/ci/docker/using_kaniko.md
+++ b/doc/ci/docker/using_kaniko.md
@@ -134,7 +134,7 @@ before_script:
   - |
     echo "-----BEGIN CERTIFICATE-----
     ...
-    -----END CERTIFICATE-----" >> /kaniko/ssl/certs/additional-ca-cert-bundle.crt
+    -----END CERTIFICATE-----" >> /kaniko/ssl/certs/ca-certificates.crt
 ```
 
 ## Video walkthrough of a working example
diff --git a/doc/ci/enable_or_disable_ci.md b/doc/ci/enable_or_disable_ci.md
index e75f902c153..e332b040fbc 100644
--- a/doc/ci/enable_or_disable_ci.md
+++ b/doc/ci/enable_or_disable_ci.md
@@ -30,8 +30,8 @@ When you disable GitLab CI/CD:
 
 To disable GitLab CI/CD in your project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. In the **Repository** section, turn off **CI/CD**.
 1. Select **Save changes**.
@@ -40,8 +40,8 @@ To disable GitLab CI/CD in your project:
 
 To enable GitLab CI/CD in your project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. In the **Repository** section, turn on **CI/CD**.
 1. Select **Save changes**.
diff --git a/doc/ci/environments/configure_kubernetes_deployments.md b/doc/ci/environments/configure_kubernetes_deployments.md
new file mode 100644
index 00000000000..e618aae7cae
--- /dev/null
+++ b/doc/ci/environments/configure_kubernetes_deployments.md
@@ -0,0 +1,58 @@
+---
+stage: Deploy
+group: Environments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+type: reference
+---
+
+# Configure Kubernetes deployments (deprecated)
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) in GitLab 12.6.
+> - [Deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
+
+WARNING:
+This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
+
+If you are deploying to a [Kubernetes cluster](../../user/infrastructure/clusters/index.md)
+associated with your project, you can configure these deployments from your
+`.gitlab-ci.yml` file.
+
+NOTE:
+Kubernetes configuration isn't supported for Kubernetes clusters
+[managed by GitLab](../../user/project/clusters/gitlab_managed_clusters.md).
+
+The following configuration options are supported:
+
+- [`namespace`](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
+
+In the following example, the job deploys your application to the
+`production` Kubernetes namespace.
+
+```yaml
+deploy:
+  stage: deploy
+  script:
+    - echo "Deploy to production server"
+  environment:
+    name: production
+    url: https://example.com
+    kubernetes:
+      namespace: production
+  rules:
+    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
+```
+
+When you use the GitLab Kubernetes integration to deploy to a Kubernetes cluster,
+you can view cluster and namespace information. On the deployment
+job page, it's displayed above the job trace:
+
+![Deployment cluster information](../img/environments_deployment_cluster_v12_8.png)
+
+## Configure incremental rollouts
+
+Learn how to release production changes to only a portion of your Kubernetes pods with
+[incremental rollouts](../environments/incremental_rollouts.md).
+
+## Related topics
+
+- [Deploy boards (deprecated)](../../user/project/deploy_boards.md)
diff --git a/doc/ci/environments/deployment_approvals.md b/doc/ci/environments/deployment_approvals.md
index 96011d5ddff..0ef37452cbb 100644
--- a/doc/ci/environments/deployment_approvals.md
+++ b/doc/ci/environments/deployment_approvals.md
@@ -51,7 +51,7 @@ Example:
 
 There are two ways to configure the approval requirements:
 
-- [Unified approval setting](#unified-approval-setting) ... You can define who can execute **and** approve deployments.
+- [Unified approval setting](#unified-approval-setting-deprecated) ... You can define who can execute **and** approve deployments.
   This is useful when there is no separation of duties between executors and approvers in your organization.
 - [Multiple approval rules](#multiple-approval-rules) ... You can define who can execute **or** approve deployments.
   This is useful when there is a separation of duties between executors and approvers in your organization.
@@ -60,11 +60,18 @@ NOTE:
 Multiple approval rules is a more flexible option than the unified approval setting, thus both configurations shouldn't
 co-exist and multiple approval rules takes the precedence over the unified approval setting if it happens.
 
-#### Unified approval setting
+<!--- start_remove The following content will be removed on remove_date: '2024-05-22' -->
+
+#### Unified approval setting (deprecated)
 
 > - UI configuration [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/378447) in GitLab
 >   15.11.
 
+WARNING:
+This feature was [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/9662) in GitLab 16.1 and is planned for removal
+in 17.0. Use [multiple approval rules](https://gitlab.com/gitlab-org/gitlab/-/issues/404579) instead. This change
+is a breaking change.
+
 To configure approvals for a protected environment:
 
 - Using the [REST API](../../api/protected_environments.md#protect-a-single-environment),
@@ -85,6 +92,8 @@ NOTE:
 To protect, update, or unprotect an environment, you must have at least the
 Maintainer role.
 
+<!--- end_remove -->
+
 #### Multiple approval rules
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345678) in GitLab 14.10 with a flag named `deployment_approval_rules`. Disabled by default.
@@ -119,6 +128,41 @@ NOTE:
 To protect, update, or unprotect an environment, you must have at least the
 Maintainer role.
 
+#### Migrate to multiple approval rules
+
+You can migrate a protected environment from unified approval rules to multiple
+approval rules. Unified approval rules allow all entities that can deploy to an
+environment to approve deployment jobs. To migrate to multiple approval rules,
+create a new approval rule for each entity allowed to deploy to the environment.
+
+To migrate with the UI:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
+1. Expand **Protected environments**.
+1. From the **Environment** list, select your environment.
+1. For each entity allowed to deploy to the environment:
+   1. Select **Add approval rules**.
+   1. In the modal window, select which entity is allowed to approve the
+      deployment job.
+   1. Enter the number of required approvals.
+   1. Select **Save**.
+
+Each deployment requires the specified number of approvals from each entity.
+
+For example, the `Production` environment below requires five total approvals,
+and allows deployments from only the group `Very Important Group` and the user
+`Administrator`:
+
+![unified approval rules](img/unified_approval_rules_v16_0.png)
+
+To migrate, create rules for the `Very Important Group` and `Administrator`. To
+preserve the number of required approvals, set the number of required approvals
+for `Very Important Group` to four and `Administrator` to one. The new rules
+require `Administrator` to approve every deployment job in `Production`.
+
+![multiple approval rules](img/multiple_approval_rules_v16_0.png)
+
 ### Allow self-approval **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/381418) in GitLab 15.8.
@@ -126,8 +170,8 @@ Maintainer role.
 By default, the user who triggers a deployment pipeline can't also approve the deployment job.
 To allow self-approval of a deployment job:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Protected environments**.
 1. From the **Approval options**, select the **Allow pipeline triggerer to approve deployment** checkbox.
 
@@ -154,8 +198,8 @@ Prerequisites:
 
 To approve or reject a deployment to a protected environment using the UI:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Environments**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
 1. Select the environment's name.
 1. In the deployment's row, select **Approval options** (**{thumb-up}**).
    Before approving or rejecting the deployment, you can view the number of approvals granted and
@@ -191,8 +235,8 @@ granted.
 
 To view the approval details of a deployment:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Environments**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
 1. Select the environment's name.
 1. In the deployment's row, select **Approval options** (**{thumb-up}**).
 
@@ -207,8 +251,8 @@ The approval status details are shown:
 
 ### Using the UI
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Environments**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
 1. Select the environment being deployed to.
 1. Look for the `blocked` label.
 
@@ -217,7 +261,7 @@ The approval status details are shown:
 Use the [Deployments API](../../api/deployments.md#get-a-specific-deployment) to see deployments.
 
 - The `status` field indicates if a deployment is blocked.
-- When the [unified approval setting](#unified-approval-setting) is configured:
+- When the [unified approval setting](#unified-approval-setting-deprecated) is configured:
   - The `pending_approval_count` field indicates how many approvals are remaining to run a deployment.
   - The `approvals` field contains the deployment's approvals.
 - When the [multiple approval rules](#multiple-approval-rules) is configured:
diff --git a/doc/ci/environments/environments_dashboard.md b/doc/ci/environments/environments_dashboard.md
index fd2c85819fe..ce219e5d746 100644
--- a/doc/ci/environments/environments_dashboard.md
+++ b/doc/ci/environments/environments_dashboard.md
@@ -20,8 +20,9 @@ see which pipelines are green and which are red allowing you to
 diagnose if there is a block at a particular point, or if there's
 a more systemic problem you need to investigate.
 
-You can access the dashboard on the top bar by selecting
-**Main menu > Environments**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Your work**.
+1. Select **Environments**.
 
 ![Environments Dashboard with projects](img/environments_dashboard_v12_5.png)
 
diff --git a/doc/ci/environments/img/multiple_approval_rules_v16_0.png b/doc/ci/environments/img/multiple_approval_rules_v16_0.png
new file mode 100644
index 00000000000..2385bea6956
--- /dev/null
+++ b/doc/ci/environments/img/multiple_approval_rules_v16_0.png
diff --git a/doc/ci/environments/img/unified_approval_rules_v16_0.png b/doc/ci/environments/img/unified_approval_rules_v16_0.png
new file mode 100644
index 00000000000..7f822aedff8
--- /dev/null
+++ b/doc/ci/environments/img/unified_approval_rules_v16_0.png
diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md
index f4d155369e9..f2fb8eaa27e 100644
--- a/doc/ci/environments/index.md
+++ b/doc/ci/environments/index.md
@@ -51,8 +51,8 @@ Deployments show up in this list only after a deployment job has created them.
 
 To search environments by name:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Environments**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
 1. In the search bar, enter your search term.
    - The length of your **search term should be 3 or more characters**.
    - Matching applies from the beginning of the environment name.
@@ -61,6 +61,12 @@ To search environments by name:
      - For example when the name is `review/test-app`, search term `test` matches `review/test-app`.
      - Also searching with the folder name prefixed like `review/test` matches `review/test-app`.
 
+## CI/CD variables
+
+To customize your environments and deployments, you can use any of the
+[predefined CI/CD variables](../../ci/variables/predefined_variables.md),
+and define custom CI/CD variables.
+
 ## Types of environments
 
 An environment is either static or dynamic:
@@ -87,9 +93,9 @@ Prerequisites:
 
 To create a static environment in the UI:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Environments**.
-1. Select **New environment**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
+1. Select **Create an environment**.
 1. Complete the fields.
 1. Select **Save**.
 
@@ -123,7 +129,8 @@ deploy_staging:
 
 ### Create a dynamic environment
 
-To create a dynamic environment, you use [CI/CD variables](../variables/index.md) that are unique to each pipeline.
+To create a dynamic environment, you use [CI/CD variables](#cicd-variables) that are
+unique to each pipeline.
 
 Prerequisites:
 
@@ -158,6 +165,79 @@ deploy_review_app:
     - main
 ```
 
+#### Set a dynamic environment URL
+
+Some external hosting platforms generate a random URL for each deployment, for example:
+`https://94dd65b.amazonaws.com/qa-lambda-1234567`. That makes it difficult to reference the URL in
+the `.gitlab-ci.yml` file.
+
+To address this problem, you can configure a deployment job to report back a set of
+variables. These variables include the URL that was dynamically generated by the external service.
+GitLab supports the [dotenv (`.env`)](https://github.com/bkeepers/dotenv) file format,
+and expands the `environment:url` value with variables defined in the `.env` file.
+
+To use this feature, specify the
+[`artifacts:reports:dotenv`](../yaml/artifacts_reports.md#artifactsreportsdotenv) keyword in `.gitlab-ci.yml`.
+
+You can also specify a static part of the URL at `environment:url`, such as
+`https://$DYNAMIC_ENVIRONMENT_URL`. If the value of `DYNAMIC_ENVIRONMENT_URL` is `example.com`, the
+final result is `https://example.com`.
+
+The assigned URL for the `review/your-branch-name` environment is visible in the UI.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For an overview, see [Set dynamic URLs after a job finished](https://youtu.be/70jDXtOf4Ig).
+
+In the following example a review app creates a new environment for each merge request:
+
+- The `review` job is triggered by every push, and creates or updates an environment named
+  `review/your-branch-name`. The environment URL is set to `$DYNAMIC_ENVIRONMENT_URL`.
+- When the `review` job finishes, GitLab updates the `review/your-branch-name` environment's URL.
+  It parses the `deploy.env` report artifact, registers a list of variables as runtime-created,
+  expands the `environment:url: $DYNAMIC_ENVIRONMENT_URL` and sets it to the environment
+  URL.
+
+```yaml
+review:
+  script:
+    - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                 # In script, get the environment URL.
+    - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # Add the value to a dotenv file.
+  artifacts:
+    reports:
+      dotenv: deploy.env                                                       # Report back dotenv file to rails.
+  environment:
+    name: review/$CI_COMMIT_REF_SLUG
+    url: $DYNAMIC_ENVIRONMENT_URL                                              # and set the variable produced in script to `environment:url`
+    on_stop: stop_review
+
+stop_review:
+  script:
+    - ./teardown-environment
+  when: manual
+  environment:
+    name: review/$CI_COMMIT_REF_SLUG
+    action: stop
+```
+
+Note the following:
+
+- `stop_review` doesn't generate a dotenv report artifact, so it doesn't recognize the
+  `DYNAMIC_ENVIRONMENT_URL` environment variable. Therefore you shouldn't set `environment:url` in the
+  `stop_review` job.
+- If the environment URL isn't valid (for example, the URL is malformed), the system doesn't update
+  the environment URL.
+- If the script that runs in `stop_review` exists only in your repository and therefore can't use
+  `GIT_STRATEGY: none`, configure [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md)
+  for these jobs. This ensures that runners can fetch the repository even after a feature branch is
+  deleted. For more information, see [Ref Specs for Runners](../pipelines/index.md#ref-specs-for-runners).
+
+NOTE:
+For Windows runners, you should use the PowerShell `Add-Content` command to write to `.env` files.
+
+```powershell
+Add-Content -Path deploy.env -Value "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL"
+```
+
 ### Rename an environment
 
 > - Renaming an environment by using the UI was [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68550) in GitLab 14.3.
@@ -220,153 +300,6 @@ The `when: manual` action:
 
 You can find the play button in the pipelines, environments, deployments, and jobs views.
 
-## Configure Kubernetes deployments (deprecated)
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) in GitLab 12.6.
-> - [Deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
-
-WARNING:
-This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
-
-If you are deploying to a [Kubernetes cluster](../../user/infrastructure/clusters/index.md)
-associated with your project, you can configure these deployments from your
-`.gitlab-ci.yml` file.
-
-NOTE:
-Kubernetes configuration isn't supported for Kubernetes clusters
-[managed by GitLab](../../user/project/clusters/gitlab_managed_clusters.md).
-
-The following configuration options are supported:
-
-- [`namespace`](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
-
-In the following example, the job deploys your application to the
-`production` Kubernetes namespace.
-
-```yaml
-deploy:
-  stage: deploy
-  script:
-    - echo "Deploy to production server"
-  environment:
-    name: production
-    url: https://example.com
-    kubernetes:
-      namespace: production
-  rules:
-    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
-```
-
-When you use the GitLab Kubernetes integration to deploy to a Kubernetes cluster,
-you can view cluster and namespace information. On the deployment
-job page, it's displayed above the job trace:
-
-![Deployment cluster information](../img/environments_deployment_cluster_v12_8.png)
-
-### Configure incremental rollouts
-
-Learn how to release production changes to only a portion of your Kubernetes pods with
-[incremental rollouts](../environments/incremental_rollouts.md).
-
-## CI/CD variables for environments and deployments
-
-When you create an environment, you specify the name and URL.
-
-If you want to use the name or URL in another job, you can use:
-
-- `$CI_ENVIRONMENT_NAME`. The name defined in the `.gitlab-ci.yml` file.
-- `$CI_ENVIRONMENT_SLUG`. A "cleaned-up" version of the name, suitable for use in URL and DNS, for example.
-  This variable is guaranteed to be unique.
-- `$CI_ENVIRONMENT_URL`. The environment's URL, which was specified in the
-  `.gitlab-ci.yml` file or automatically assigned.
-
-If you change the name of an existing environment, the:
-
-- `$CI_ENVIRONMENT_NAME` variable is updated with the new environment name.
-- `$CI_ENVIRONMENT_SLUG` variable remains unchanged to prevent unintended side
-  effects.
-
-## Set dynamic environment URLs after a job finishes
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/17066) in GitLab 12.9.
-
-In a job script, you can specify a static environment URL.
-However, there may be times when you want a dynamic URL. For example,
-if you deploy a Review App to an external hosting
-service that generates a random URL per deployment, like `https://94dd65b.amazonaws.com/qa-lambda-1234567`.
-In this case, you don't know the URL before the deployment script finishes.
-If you want to use the environment URL in GitLab, you would have to update it manually.
-
-To address this problem, you can configure a deployment job to report back a set of
-variables. These variables include the URL that was dynamically-generated by the external service.
-GitLab supports the [dotenv (`.env`)](https://github.com/bkeepers/dotenv) file format,
-and expands the `environment:url` value with variables defined in the `.env` file.
-
-To use this feature, specify the
-[`artifacts:reports:dotenv`](../yaml/artifacts_reports.md#artifactsreportsdotenv) keyword in `.gitlab-ci.yml`.
-
-<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For an overview, see [Set dynamic URLs after a job finished](https://youtu.be/70jDXtOf4Ig).
-
-### Example of setting dynamic environment URLs
-
-The following example shows a Review App that creates a new environment
-for each merge request. The `review` job is triggered by every push, and
-creates or updates an environment named `review/your-branch-name`.
-The environment URL is set to `$DYNAMIC_ENVIRONMENT_URL`:
-
-```yaml
-review:
-  script:
-    - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                 # In script, get the environment URL.
-    - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # Add the value to a dotenv file.
-  artifacts:
-    reports:
-      dotenv: deploy.env                                                       # Report back dotenv file to rails.
-  environment:
-    name: review/$CI_COMMIT_REF_SLUG
-    url: $DYNAMIC_ENVIRONMENT_URL                                              # and set the variable produced in script to `environment:url`
-    on_stop: stop_review
-
-stop_review:
-  script:
-    - ./teardown-environment
-  when: manual
-  environment:
-    name: review/$CI_COMMIT_REF_SLUG
-    action: stop
-```
-
-As soon as the `review` job finishes, GitLab updates the `review/your-branch-name`
-environment's URL.
-It parses the `deploy.env` report artifact, registers a list of variables as runtime-created,
-uses it for expanding `environment:url: $DYNAMIC_ENVIRONMENT_URL` and sets it to the environment URL.
-You can also specify a static part of the URL at `environment:url`, such as
-`https://$DYNAMIC_ENVIRONMENT_URL`. If the value of `DYNAMIC_ENVIRONMENT_URL` is
-`example.com`, the final result is `https://example.com`.
-
-The assigned URL for the `review/your-branch-name` environment is visible in the UI.
-
-Note the following:
-
-- `stop_review` doesn't generate a dotenv report artifact, so it doesn't recognize the
-  `DYNAMIC_ENVIRONMENT_URL` environment variable. Therefore you shouldn't set `environment:url` in the
-  `stop_review` job.
-- If the environment URL isn't valid (for example, the URL is malformed), the system doesn't update
-  the environment URL.
-- If the script that runs in `stop_review` exists only in your repository and therefore can't use
-  `GIT_STRATEGY: none`, configure [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md)
-  for these jobs. This ensures that runners can fetch the repository even after a feature branch is
-  deleted. For more information, see [Ref Specs for Runners](../pipelines/index.md#ref-specs-for-runners).
-
-NOTE:
-For Windows runners, using `echo` to write to `.env` files may fail. Using the PowerShell `Add-Content`command
-helps in such cases. For example:
-
-```powershell
-Add-Content -Path deploy.env -Value "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL"
-```
-
 ## Track newly included merge requests per deployment
 
 GitLab can track newly included merge requests per deployment.
@@ -412,8 +345,8 @@ If there is a problem with a deployment, you can retry it or roll it back.
 
 To retry or rollback a deployment:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Environments**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
 1. Select the environment.
 1. To the right of the deployment name:
    - To retry a deployment, select **Re-deploy to environment**.
@@ -627,8 +560,8 @@ you can view its expiration date and time.
 
 To view an environment's expiration date and time:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Environments**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
 1. Select the name of the environment.
 
 The expiration date and time is displayed in the upper-left corner, next to the environment's name.
@@ -640,8 +573,8 @@ you can override its expiration.
 
 To override an environment's expiration:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Environments**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
 1. Select the deployment name.
 1. in the upper-right corner, select the thumbtack (**{thumbtack}**).
 
@@ -652,7 +585,7 @@ manually.
 
 There may be times when you want to stop an environment without running the defined
 [`on_stop`](../yaml/index.md#environmenton_stop) action. For example, you want to delete many
-environments without using CI/CD minutes.
+environments without using [compute quota](../pipelines/cicd_minutes.md).
 
 To stop an environment without running the defined `on_stop` action, execute the
 [Stop an environment API](../../api/environments.md#stop-an-environment) with the parameter
@@ -667,8 +600,8 @@ Environments view, the stop and deploy jobs must be in the same
 
 To stop an environment in the GitLab UI:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Environments**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
 1. Next to the environment you want to stop, select **Stop**.
 1. On the confirmation dialog box, select **Stop environment**.
 
@@ -731,8 +664,8 @@ Prerequisites:
 
 To delete an environment:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Environments**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
 1. Select the **Stopped** tab.
 1. Next to the environment you want to delete, select **Delete environment**.
 1. On the confirmation dialog box, select **Delete environment**.
@@ -800,7 +733,7 @@ to get alerts when there are critical issues that need immediate attention.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214634) in GitLab 13.4.
 
-If you [set up alerts for Prometheus metrics](../../operations/metrics/alerts.md),
+If you [set up alerts for Prometheus metrics](../../operations/incident_management/integrations.md#configuration),
 alerts for environments are shown on the environments page. The alert with the highest
 severity is shown, so you can identify which environments need immediate attention.
 
@@ -834,34 +767,20 @@ Limitations of GitLab Auto Rollback:
 
 GitLab Auto Rollback is turned off by default. To turn it on:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Automatic deployment rollbacks**.
 1. Select the checkbox for **Enable automatic rollbacks**.
 1. Select **Save changes**.
 
-### Monitor environments
-
-To monitor the behavior of your app as it runs in each environment,
-enable [Prometheus for monitoring system and response metrics](../../user/project/integrations/prometheus.md).
-For the monitoring dashboard to appear, configure Prometheus to collect at least one
-[supported metric](../../user/project/integrations/prometheus_library/index.md).
-
-All deployments to an environment are shown on the monitoring dashboard.
-You can view changes in performance for each version of your application.
-
-GitLab attempts to retrieve [supported performance metrics](../../user/project/integrations/prometheus_library/index.md)
-for any environment that has had a successful deployment. If monitoring data was
-successfully retrieved, a **Monitoring** button appears for each environment.
-
-To view the last eight hours of performance data, select the **Monitoring** button.
-It may take a minute or two for data to appear after initial deployment.
+<!--- start_remove The following content will be removed on remove_date: '2023-09-22' -->
 
-![Monitoring dashboard](../img/environments_monitoring.png)
+### Monitor environments (removed)
 
-#### Embed metrics in GitLab Flavored Markdown
+This feature was [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/10107) in GitLab 14.7
+and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/399231) in 16.0.
 
-Metric charts can be embedded in GitLab Flavored Markdown. See [Embedding Metrics in GitLab Flavored Markdown](../../operations/metrics/embed.md) for more details.
+<!--- end_remove -->
 
 ### Web terminals (deprecated)
 
@@ -990,14 +909,14 @@ the `review/feature-1` spec takes precedence over `review/*` and `*` specs.
 
 ## Related topics
 
-- [Use GitLab CI to deploy to multiple environments (blog post)](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/)
-- [Review Apps](../review_apps/index.md): Use dynamic environments to deploy your code for every branch.
-- [Deploy boards](../../user/project/deploy_boards.md): View the status of your applications running on Kubernetes.
-- [Protected environments](protected_environments.md): Determine who can deploy code to your environments.
-- [Environments Dashboard](../environments/environments_dashboard.md): View a summary of each
-  environment's operational health. **(PREMIUM)**
-- [Deployment safety](deployment_safety.md#restrict-write-access-to-a-critical-environment): Secure your deployments.
-- [Track deployments of an external deployment tool](external_deployment_tools.md): Use an external deployment tool instead of built-in deployment solution.
+- [Dashboard for Kubernetes](kubernetes_dashboard.md)
+- [Deploy to multiple environments with GitLab CI/CD (blog post)](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/)
+- [Review Apps](../review_apps/index.md)
+- [Protected environments](protected_environments.md)
+- [Environments Dashboard](../environments/environments_dashboard.md)
+- [Deployment safety](deployment_safety.md#restrict-write-access-to-a-critical-environment)
+- [Track deployments of an external deployment tool](external_deployment_tools.md)
+- [Configure Kubernetes deployments (deprecated)](configure_kubernetes_deployments.md)
 
 ## Troubleshooting
 
diff --git a/doc/ci/environments/kubernetes_dashboard.md b/doc/ci/environments/kubernetes_dashboard.md
new file mode 100644
index 00000000000..7da48bed5d7
--- /dev/null
+++ b/doc/ci/environments/kubernetes_dashboard.md
@@ -0,0 +1,66 @@
+---
+stage: Deploy
+group: Environments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+type: reference
+---
+
+# Dashboard for Kubernetes (Beta) **(FREE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/390769) in GitLab 16.1, with [flags](../../administration/feature_flags.md) named `environment_settings_to_graphql`, `kas_user_access`, `kas_user_access_project`, and `expose_authorized_cluster_agents`. This feature is in [Beta](../../policy/experiment-beta-support.md#beta).
+
+Use the Dashboard for Kubernetes to understand the status of your clusters with an intuitive visual interface.
+The dashboard works with every connected Kubernetes cluster, whether you deployed them
+with CI/CD or GitOps.
+
+For Flux users, the synchronization status of a given environment is not displayed in the dashboard.
+[Issue 391581](https://gitlab.com/gitlab-org/gitlab/-/issues/391581) proposes to add this functionality.
+
+## Configure a dashboard
+
+Configure a dashboard to use it for a given environment.
+You can configure dashboard for an environment that already exists, or
+add one when you create an environment.
+
+Prerequisite:
+
+- The agent for Kubernetes must be shared with the environment's project, or its parent group, using the [`user_access`](../../user/clusters/agent/user_access.md) keyword.
+
+### The environment already exists
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
+1. Select the environment to be associated with the Kubernetes.
+1. Select **Edit**.
+1. Select a GitLab agent for Kubernetes.
+1. Select **Save**.
+
+### The environment doesn't exist
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
+1. Select **New environment**.
+1. Complete the **Name** field.
+1. Select a GitLab agent for Kubernetes.
+1. Select **Save**.
+
+## View a dashboard
+
+To view a configured dashboard:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Environments**.
+1. Expand the environment associated with GitLab agent for Kubernetes.
+1. Expand **Kubernetes overview**.
+
+## Troubleshooting
+
+When working with the Dashboard for Kubernetes, you might encounter the following issues.
+
+### User cannot list resource in API group
+
+You might get an error that states `Error: services is forbidden: User "gitlab:user:<user-name>" cannot list resource "<resource-name>" in API group "" at the cluster scope`.
+
+This error happens when a user is not allowed to do the specified operation in the [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).
+
+To resolve, check your [RBAC configuration](../../user/clusters/agent/user_access.md#configure-kubernetes-access). If the RBAC is properly configured, contact your Kubernetes administrator.
diff --git a/doc/ci/environments/protected_environments.md b/doc/ci/environments/protected_environments.md
index f752e2179df..61b59ceedb2 100644
--- a/doc/ci/environments/protected_environments.md
+++ b/doc/ci/environments/protected_environments.md
@@ -30,8 +30,8 @@ Prerequisites:
 
 To protect an environment:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Protected environments**.
 1. From the **Environment** list, select the environment you want to protect.
 1. In the **Allowed to deploy** list, select the role, users, or groups you
@@ -87,7 +87,7 @@ Alternatively, you can use the API to protect an environment:
        name: ${CI_JOB_NAME}
    ```
 
-1. Use the UI to [create a new group](../../user/group/manage.md#create-a-group).
+1. Use the UI to [create a new group](../../user/group/index.md#create-a-group).
    For example, this group is called `protected-access-group` and has the group ID `9899826`. Note
    that the rest of the examples in these steps use this group.
 
@@ -255,8 +255,8 @@ To protect a group-level environment, make sure your environments have the corre
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/325249) in GitLab 15.1.
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > CI/CD**.
 1. Expand **Protected environments**.
 1. From the **Environment** list, select the [deployment tier of environments](index.md#deployment-tier-of-environments) you want to protect.
 1. In the **Allowed to deploy** list, select the [subgroups](../../user/group/subgroups/index.md) you want to give deploy access to.
diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-production.png b/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-production.png
deleted file mode 100644
index 16c15071dd7..00000000000
--- a/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-production.png
+++ /dev/null
diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-staging.png b/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-staging.png
deleted file mode 100644
index 7a92a3c2d50..00000000000
--- a/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-staging.png
+++ /dev/null
diff --git a/doc/ci/examples/deployment/index.md b/doc/ci/examples/deployment/index.md
index 664ce84c488..a156cf1acb0 100644
--- a/doc/ci/examples/deployment/index.md
+++ b/doc/ci/examples/deployment/index.md
@@ -121,8 +121,8 @@ We also use two secure variables:
 
 To store API keys as secure variables:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Variables**.
 
 The variables defined in the project settings are sent along with the build script to the runner.
diff --git a/doc/ci/examples/index.md b/doc/ci/examples/index.md
index f2871e50617..a020f673fd7 100644
--- a/doc/ci/examples/index.md
+++ b/doc/ci/examples/index.md
@@ -23,11 +23,9 @@ The following table lists examples with step-by-step tutorials that are containe
 
 | Use case                      | Resource |
 |-------------------------------|----------|
-| Browser performance testing   | [Browser Performance Testing with the Sitespeed.io container](../testing/browser_performance_testing.md). |
 | Deployment with Dpl           | [Using `dpl` as deployment tool](deployment/index.md). |
 | GitLab Pages                  | See the [GitLab Pages](../../user/project/pages/index.md) documentation for a complete example of deploying a static site. |
 | End-to-end testing            | [End-to-end testing with GitLab CI/CD and WebdriverIO](end_to_end_testing_webdriverio/index.md). |
-| Load performance testing      | [Load Performance Testing with the k6 container](../testing/load_performance_testing.md). |
 | Multi project pipeline        | [Build, test deploy using multi project pipeline](https://gitlab.com/gitlab-examples/upstream-project). |
 | npm with semantic-release     | [Publish npm packages to the GitLab Package Registry using semantic-release](semantic-release.md). |
 | PHP with Laravel, Envoy       | [Test and deploy Laravel applications with GitLab CI/CD and Envoy](laravel_with_gitlab_and_envoy/index.md). |
diff --git a/doc/ci/examples/semantic-release.md b/doc/ci/examples/semantic-release.md
index 2146d76e4d6..00260199179 100644
--- a/doc/ci/examples/semantic-release.md
+++ b/doc/ci/examples/semantic-release.md
@@ -90,14 +90,14 @@ As part of publishing a package, semantic-release increases the version number i
 
 <!-- markdownlint-disable MD044 -->
 
-1. On the top bar, in the upper-right corner, select your avatar.
-1. On the left sidebar, select **Access Tokens**.
+1. On the left sidebar, select your avatar.
+1. Select **Preferences > Access Tokens**.
 1. In the **Token name** box, enter a token name.
 1. Under **select scopes**, select the **api** checkbox.
 1. Select **Create project access token**.
 1. Copy the value.
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Variables**.
 1. Select **Add variable**.
 1. In the **Key** box, enter `GITLAB_TOKEN`.
diff --git a/doc/ci/img/environments_monitoring.png b/doc/ci/img/environments_monitoring.png
deleted file mode 100644
index 63d272ae42a..00000000000
--- a/doc/ci/img/environments_monitoring.png
+++ /dev/null
diff --git a/doc/ci/index.md b/doc/ci/index.md
index 65e6394b439..75e668290c8 100644
--- a/doc/ci/index.md
+++ b/doc/ci/index.md
@@ -82,8 +82,6 @@ GitLab CI/CD features, grouped by DevOps stage, include:
 | [ChatOps](chatops/index.md)                                                                  | Trigger CI jobs from chat, with results sent back to the channel. |
 | [Connect to cloud services](cloud_services/index.md)                                         | Connect to cloud providers using OpenID Connect (OIDC) to retrieve temporary credentials to access services or secrets. |
 | **Verify**                                                                                   |             |
-| [Browser Performance Testing](testing/browser_performance_testing.md)                        | Quickly determine the browser performance impact of pending code changes. |
-| [Load Performance Testing](testing/load_performance_testing.md)                              | Quickly determine the server performance impact of pending code changes. |
 | [CI services](services/index.md)                                                             | Link Docker containers with your base image. |
 | [GitLab CI/CD for external repositories](ci_cd_for_external_repos/index.md)                  | Get the benefits of GitLab CI/CD combined with repositories in GitHub and Bitbucket Cloud. |
 | [Interactive Web Terminals](interactive_web_terminal/index.md)                               | Open an interactive web terminal to debug the running jobs. |
diff --git a/doc/ci/introduction/index.md b/doc/ci/introduction/index.md
index bf07af5e761..895aa8551d7 100644
--- a/doc/ci/introduction/index.md
+++ b/doc/ci/introduction/index.md
@@ -61,8 +61,7 @@ of the changes.
 
 ## Continuous Deployment
 
-[Continuous Deployment](https://www.airpair.com/continuous-deployment/posts/continuous-deployment-for-practical-people)
-is another step beyond Continuous Integration, similar to
+Continuous Deployment is another step beyond Continuous Integration, similar to
 Continuous Delivery. The difference is that instead of deploying your
 application manually, you set it to be deployed automatically.
 Human intervention is not required.
diff --git a/doc/ci/jobs/ci_job_token.md b/doc/ci/jobs/ci_job_token.md
index 9cbf45a16e7..a60aaa04ea1 100644
--- a/doc/ci/jobs/ci_job_token.md
+++ b/doc/ci/jobs/ci_job_token.md
@@ -44,6 +44,8 @@ in a CI/CD job:
 git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/<namespace>/<project>
 ```
 
+You can't use a job token to push to a repository, but [issue 389060](https://gitlab.com/gitlab-org/gitlab/-/issues/389060) proposes to change this behavior.
+
 ## GitLab CI/CD job token security
 
 To make sure that this token doesn't leak, GitLab:
@@ -115,8 +117,8 @@ Prerequisite:
 
 To disable the job token scope allowlist:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Token Access**.
 1. Toggle **Allow access to this project with a CI_JOB_TOKEN** to disabled.
    Enabled by default in new projects.
@@ -136,8 +138,8 @@ Prerequisite:
 
 To add a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Token Access**.
 1. Verify **Allow access to this project with a CI_JOB_TOKEN** is enabled.
 1. Under **Allow CI job tokens from the following projects to access this project**,
@@ -178,8 +180,8 @@ Prerequisite:
 
 To configure the job token scope:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Token Access**.
 1. Toggle **Limit CI_JOB_TOKEN access** to enabled.
 1. Optional. Add existing projects to the token's access scope. The user adding a
diff --git a/doc/ci/jobs/index.md b/doc/ci/jobs/index.md
index b9c2ee409b8..a0c0fc43502 100644
--- a/doc/ci/jobs/index.md
+++ b/doc/ci/jobs/index.md
@@ -48,8 +48,8 @@ Selecting an individual job shows you its job log, and allows you to:
 
 To view the full list of jobs that ran in a project:
 
-1. On the top bar, select **Main menu > Projects** and find the project.
-1. On the left sidebar, select **CI/CD > Jobs**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Build > Jobs**.
 
 You can filter the list by [job status](#the-order-of-jobs-in-a-pipeline).
 
@@ -342,7 +342,7 @@ In the example above:
   job log, but they are displayed in the raw job log. To see them, in the upper-right corner
   of the job log, select **Show complete raw** (**{doc-text}**).
   - `\r`: carriage return.
-  - `\e[0K`: clear line ANSI escape code.
+  - `\e[0K`: clear line ANSI escape sequence (`\e[K` does not work, the `0` must be included).
 
 Sample raw job log:
 
diff --git a/doc/ci/jobs/job_artifacts.md b/doc/ci/jobs/job_artifacts.md
index 0c9dd658ce2..95d939c7027 100644
--- a/doc/ci/jobs/job_artifacts.md
+++ b/doc/ci/jobs/job_artifacts.md
@@ -294,17 +294,13 @@ You can also delete individual artifacts from the [**Artifacts** page](#bulk-del
 
 ### Bulk delete artifacts
 
-- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33348) in GitLab 15.10 [with a flag](../../administration/feature_flags.md) named `ci_job_artifact_bulk_destroy`. Disabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available,
-ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `ci_job_artifact_bulk_destroy`.
-The feature is not ready for production use.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33348) in GitLab 15.10 [with a flag](../../administration/feature_flags.md) named `ci_job_artifact_bulk_destroy`. Disabled by default.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/398581) in GitLab 16.1.
 
 You can delete multiple artifacts at the same time:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **CI/CD > Artifacts**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Build > Artifacts**.
 1. Select the checkboxes next to the artifacts you want to delete. You can select up to 50 artifacts.
 1. Select **Delete selected**.
 
@@ -334,7 +330,7 @@ With this configuration, GitLab adds **artifact 1** as a link to `file.txt` to t
 
 By default artifacts are always kept for successful pipelines for the most recent commit on
 each ref. This means that the latest artifacts do not immediately expire according
-to the `expire_in` specification.
+to the `expire_in` configuration.
 
 If a pipeline for a new commit on the same ref completes successfully, the previous pipeline's
 artifacts are deleted according to the `expire_in` configuration. The artifacts
@@ -345,11 +341,15 @@ Keeping the latest artifacts can use a large amount of storage space in projects
 with a lot of jobs or large artifacts. If the latest artifacts are not needed in
 a project, you can disable this behavior to save space:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Artifacts**.
 1. Clear the **Keep artifacts from most recent successful jobs** checkbox.
 
+After disabling this setting, all new artifacts expire according to the `expire_in` configuration.
+Artifacts in old pipelines continue to be kept until a new pipeline runs for the same ref.
+Then the artifacts in the earlier pipeline for that ref are allowed to expire too.
+
 You can disable this behavior for all projects on a self-managed instance in the
 [instance's CI/CD settings](../../user/admin_area/settings/continuous_integration.md#keep-the-latest-artifacts-for-all-jobs-in-the-latest-successful-pipelines).
 
diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md
index fa045a898fa..b17db47eef2 100644
--- a/doc/ci/jobs/job_control.md
+++ b/doc/ci/jobs/job_control.md
@@ -586,7 +586,7 @@ In blocking manual jobs:
   defined inside [`rules`](../yaml/index.md#rules).
 - The pipeline stops at the stage where the job is defined. To let the pipeline
   continue running, [run the manual job](#run-a-manual-job).
-- Merge requests in projects with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
+- Merge requests in projects with [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge)
   enabled can't be merged with a blocked pipeline.
 - The pipeline shows a status of **blocked**.
 
diff --git a/doc/ci/large_repositories/index.md b/doc/ci/large_repositories/index.md
index f728e9b9e17..4b17f3354aa 100644
--- a/doc/ci/large_repositories/index.md
+++ b/doc/ci/large_repositories/index.md
@@ -245,19 +245,11 @@ concurrent = 4
 This makes the cloning configuration to be part of the given runner
 and does not require us to update each `.gitlab-ci.yml`.
 
-## Git fetch caching or pre-clone step
-
-For very active repositories with a large number of references and files, you can either (or both):
-
-- Consider using the [Gitaly pack-objects cache](../../administration/gitaly/configure_gitaly.md#pack-objects-cache) instead of a
-  pre-clone step. This is easier to set up and it benefits all repositories on your GitLab server, unlike the pre-clone step that
-  must be configured per-repository. The pack-objects cache also automatically works for forks. On GitLab.com, where the pack-objects cache is
-  enabled on all Gitaly servers, we found that we no longer need a pre-clone step for `gitlab-org/gitlab` development.
-- Optimize your CI/CD jobs by seeding repository data in a pre-clone step with the
-  [`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) of GitLab Runner. See
-  [SaaS runners on Linux](../runners/saas/linux_saas_runner.md#pre-clone-script-deprecated) for details.
-  Besides speeding up pipelines in large and active projects,
-  seeding the repository data also helps avoid
-  `429 Too many requests` errors from Cloudflare.
-  This error can occur if you have many runners behind a single,
-  IP address using NAT, that pulls from GitLab.com.
+## Git fetch caching step
+
+For very active repositories with a large number of references and files, consider using the
+[Gitaly pack-objects cache](../../administration/gitaly/configure_gitaly.md#pack-objects-cache).
+The pack-objects cache:
+
+- Benefits all repositories on your GitLab server.
+- Automatically works for forks.
diff --git a/doc/ci/lint.md b/doc/ci/lint.md
index 119a0e5853e..f4c8a377c31 100644
--- a/doc/ci/lint.md
+++ b/doc/ci/lint.md
@@ -24,8 +24,8 @@ configuration added with the [`includes` keyword](yaml/index.md#include).
 
 To check CI/CD configuration with the CI lint tool:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **CI/CD > Pipelines**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Build > Pipelines**.
 1. In the upper-right corner, select **CI lint**.
 1. Paste a copy of the CI/CD configuration you want to check into the text box.
 1. Select **Validate**.
@@ -45,8 +45,8 @@ Prerequisites:
 
 To simulate a pipeline:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **CI/CD > Pipelines**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Build > Pipelines**.
 1. In the upper-right corner, select **CI lint**.
 1. Paste a copy of the CI/CD configuration you want to check into the text box.
 1. Select **Simulate pipeline creation for the default branch**.
diff --git a/doc/ci/migration/circleci.md b/doc/ci/migration/circleci.md
index b50695e8e50..17cdb4f7e3e 100644
--- a/doc/ci/migration/circleci.md
+++ b/doc/ci/migration/circleci.md
@@ -291,8 +291,8 @@ Self-managed runners:
 GitLab.com shared runners:
 
 - Linux
-- [Windows](../runners/saas/windows_saas_runner.md) ([Beta](../../policy/alpha-beta-support.md#beta)).
-- [macOS](../runners/saas/macos_saas_runner.md) ([Beta](../../policy/alpha-beta-support.md#beta)).
+- [Windows](../runners/saas/windows_saas_runner.md) ([Beta](../../policy/experiment-beta-support.md#beta)).
+- [macOS](../runners/saas/macos_saas_runner.md) ([Beta](../../policy/experiment-beta-support.md#beta)).
 
 ### Machine and specific build environments
 
diff --git a/doc/ci/mobile_devops.md b/doc/ci/mobile_devops.md
index 175a63dc3b9..a85de5e2a51 100644
--- a/doc/ci/mobile_devops.md
+++ b/doc/ci/mobile_devops.md
@@ -41,10 +41,9 @@ test:
 
 ### iOS build environments
 
-GitLab SaaS runners on macOS are currently available in beta. Follow the [instructions to request access](../ci/runners/saas/macos_saas_runner.md#access-request-process)
-for your project.
+[GitLab SaaS runners on macOS](../ci/runners/saas/macos_saas_runner.md) are currently available in beta.
 
-After you are granted access to the beta macOS runners, [choose an image](../ci/runners/saas/macos/environment.md#available-images)
+After you are granted access to the beta macOS runners, [choose an image](../ci/runners/saas/macos_saas_runner.md#supported-macos-images)
 and add it to your `.gitlab-ci.yml` file.
 
 For example:
@@ -271,7 +270,7 @@ For example:
     script:
       - fastlane build
     tags:
-      - shared-macos-amd64
+      - saas-macos-medium-m1
   ```
 
 ## Distribution
@@ -297,8 +296,8 @@ Use the [Google Play integration](../user/project/integrations/google_play.md),
 to configure your CI/CD pipelines to connect to the [Google Play Console](https://play.google.com/console)
 to build and release Android apps. To enable the integration:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Google Play**.
 1. In **Enable integration**, select the **Active** checkbox.
 1. In **Package name**, enter the package name of the app. For example, `com.gitlab.app_name`.
@@ -354,8 +353,8 @@ Use the [Apple App Store integration](../user/project/integrations/apple_app_sto
 to configure your CI/CD pipelines to connect to [App Store Connect](https://appstoreconnect.apple.com/)
 to build and release apps for iOS, iPadOS, macOS, tvOS, and watchOS. To enable the integration:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Apple App Store**.
 1. Turn on the **Active** toggle under **Enable Integration**.
 1. Provide the Apple App Store Connect configuration information:
diff --git a/doc/ci/pipeline_editor/index.md b/doc/ci/pipeline_editor/index.md
index d920c34d90a..fcacc3b5d97 100644
--- a/doc/ci/pipeline_editor/index.md
+++ b/doc/ci/pipeline_editor/index.md
@@ -113,7 +113,7 @@ where:
   with the linked configuration.
 
 Using `!reference` tags can cause nested configuration that display with
-multiple hyphens (`-`) in the expanded view. This behavior is expected, and the extra
+multiple hyphens (`-`) at the start of the line in the expanded view. This behavior is expected, and the extra
 hyphens do not affect the job's execution. For example, this configuration and
 fully expanded version are both valid:
 
@@ -124,11 +124,27 @@ fully expanded version are both valid:
     script:
       - pip install pyflakes
 
+  .rule-01:
+    rules:
+      - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/
+        when: manual
+        allow_failure: true
+      - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
+
+  .rule-02:
+    rules:
+      - if: $CI_COMMIT_BRANCH == "main"
+        when: manual
+        allow_failure: true
+
   lint-python:
     image: python:latest
     script:
       - !reference [.python-req, script]
       - pyflakes python/
+    rules:
+      - !reference [.rule-01, rules]
+      - !reference [.rule-02, rules]
   ```
 
 - Expanded configuration in **Full configuration** tab:
@@ -137,11 +153,30 @@ fully expanded version are both valid:
   ".python-req":
     script:
     - pip install pyflakes
+  ".rule-01":
+    rules:
+    - if: "$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/"
+      when: manual
+      allow_failure: true
+    - if: "$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME"
+  ".rule-02":
+    rules:
+    - if: $CI_COMMIT_BRANCH == "main"
+      when: manual
+      allow_failure: true
   lint-python:
+    image: python:latest
     script:
-    - - pip install pyflakes  # <- The extra hyphens do not affect the job's execution.
+    - - pip install pyflakes                                     # <- The extra hyphens do not affect the job's execution.
     - pyflakes python/
-    image: python:latest
+    rules:
+    - - if: "$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/" # <- The extra hyphens do not affect the job's execution.
+        when: manual
+        allow_failure: true
+      - if: "$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME"               # <- No extra hyphen but aligned with previous rule
+    - - if: $CI_COMMIT_BRANCH == "main"                          # <- The extra hyphens do not affect the job's execution.
+        when: manual
+        allow_failure: true
   ```
 
 ## Commit changes to CI configuration
diff --git a/doc/ci/pipelines/cicd_minutes.md b/doc/ci/pipelines/cicd_minutes.md
index ee3f0d8c539..c29d23cfff7 100644
--- a/doc/ci/pipelines/cicd_minutes.md
+++ b/doc/ci/pipelines/cicd_minutes.md
@@ -5,45 +5,47 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# CI/CD minutes quota **(PREMIUM)**
+# Compute quota **(PREMIUM)**
+
+> [Renamed](https://gitlab.com/groups/gitlab-com/-/epics/2150) from "CI/CD minutes" to "compute quota" or "units of compute" in GitLab 16.1.
 
 NOTE:
 The term `CI/CD minutes` is being renamed to `units of compute`. During this transition, you might see references in the UI and documentation to `CI/CD minutes`, `CI minutes`, `pipeline minutes`, `CI pipeline minutes`, `pipeline minutes quota`, and `units of compute`. For more information, see [epic 2150](https://gitlab.com/groups/gitlab-com/-/epics/2150).
 
 Administrators can limit the amount of time that projects can use to run jobs on
 [shared runners](../runners/runners_scope.md#shared-runners) each month. This limit
-is tracked with a quota of CI/CD minutes.
+is tracked with a compute quota.
 
 By default, one minute of execution time by a single job uses
-one CI/CD minute. The total amount of CI/CD minutes used by a pipeline is
-[the sum of all its jobs' durations](#how-cicd-minute-usage-is-calculated).
-Jobs can run concurrently, so the total CI/CD minute usage can be higher than the
+one unit of compute. The total execution time for a pipeline is
+[the sum of all its jobs' durations](#how-compute-usage-is-calculated).
+Jobs can run concurrently, so the total usage can be higher than the
 end-to-end duration of a pipeline.
 
 On GitLab.com:
 
-- CI/CD minutes quotas are enabled for all projects, but certain
-  projects [consume CI/CD minutes at a slower rate](#cost-factor).
-- The base monthly CI/CD minutes quota for a GitLab.com [namespace](../../user/namespace/index.md)
+- Compute quotas are enabled for all projects, but certain
+  projects [consume units of compute at a slower rate](#cost-factor).
+- The base monthly compute quota for a GitLab.com [namespace](../../user/namespace/index.md)
   is determined by its [license tier](https://about.gitlab.com/pricing/).
-- You can [purchase additional CI/CD minutes](#purchase-additional-cicd-minutes)
-  if you need more than the number of CI/CD minutes in your monthly quota.
+- You can [purchase additional units of compute](#purchase-additional-units-of-compute)
+  if you need more than the amount of compute in your monthly quota.
 
 On self-managed GitLab instances:
 
-- CI/CD minutes quotas are disabled by default.
-- When enabled, CI/CD minutes quotas apply to private projects only.
-- Administrators can [assign more CI/CD minutes](#set-the-quota-of-cicd-minutes-for-a-specific-namespace)
-  if a namespace uses all the CI/CD minutes in its monthly quota.
+- Compute quotas are disabled by default.
+- When enabled, compute quotas apply to private projects only.
+- Administrators can [assign more units of compute](#set-the-compute-quota-for-a-specific-namespace)
+  if a namespace uses all its monthly quota.
 
-[Project runners](../runners/runners_scope.md#project-runners) are not subject to a quota of CI/CD minutes.
+[Project runners](../runners/runners_scope.md#project-runners) are not subject to a compute quota.
 
-## Set the quota of CI/CD minutes for all namespaces
+## Set the compute quota for all namespaces
 
 > [Moved](https://about.gitlab.com/blog/2021/01/26/new-gitlab-product-subscription-model/) to GitLab Premium in 13.9.
 
-By default, GitLab instances do not have a quota of CI/CD minutes.
-The default value for the quota is `0`, which grants unlimited CI/CD minutes.
+By default, GitLab instances do not have a compute quota.
+The default value for the quota is `0`, which is unlimited.
 However, you can change this default value.
 
 Prerequisite:
@@ -52,41 +54,43 @@ Prerequisite:
 
 To change the default quota that applies to all namespaces:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > CI/CD**.
 1. Expand **Continuous Integration and Deployment**.
-1. In the **Quota of CI/CD minutes** box, enter the maximum number of CI/CD minutes.
+1. In the **Compute quota** box, enter a limit.
 1. Select **Save changes**.
 
 If a quota is already defined for a specific namespace, this value does not change that quota.
 
-## Set the quota of CI/CD minutes for a specific namespace
+## Set the compute quota for a specific namespace
 
 > [Moved](https://about.gitlab.com/blog/2021/01/26/new-gitlab-product-subscription-model/) to GitLab Premium in 13.9.
 
-You can override the global value and set a quota of CI/CD minutes
+You can override the global value and set a compute quota
 for a specific namespace.
 
 Prerequisite:
 
 - You must be a GitLab administrator.
 
-To set a quota of CI/CD minutes for a namespace:
+To set a compute quota for a namespace:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Overview > Groups**.
 1. For the group you want to update, select **Edit**.
-1. In the **Quota of CI/CD minutes** box, enter the maximum number of CI/CD minutes.
+1. In the **Compute quota** box, enter the maximum number of units of compute.
 1. Select **Save changes**.
 
 You can also use the [update group API](../../api/groups.md#update-group) or the
 [update user API](../../api/users.md#user-modification) instead.
 
 NOTE:
-You can set a quota of CI/CD minutes for only top-level groups or user namespaces.
+You can set a compute quota for only top-level groups or user namespaces.
 If you set a quota for a subgroup, it is not used.
 
-## View CI/CD minutes
+## View compute usage
 
 Prerequisite:
 
@@ -101,17 +105,16 @@ Prerequisite:
 
 - You must have the Owner role for the group.
 
-To view CI/CD minutes being used for your group:
+To view compute usage for your group:
 
-1. On the top bar, select **Main menu > Groups** and find your group. The group must not be a subgroup.
-1. On the left sidebar, select **Settings > Usage Quotas**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to
+   find your group. The group must not be a subgroup.
+1. Select **Settings > Usage Quotas**.
 1. Select the **Pipelines** tab.
 
-![Group CI/CD minutes quota](img/group_cicd_minutes_quota.png)
-
-The projects list shows projects with CI/CD minute usage or shared runners usage
+The projects list shows projects with compute usage or shared runners usage
 in the current month only. The list includes all projects in the namespace and its
-subgroups, sorted in descending order of CI/CD minute usage.
+subgroups, sorted in descending order of compute usage.
 
 ### View Usage Quota reports for a personal namespace
 
@@ -121,79 +124,79 @@ Prerequisite:
 
 - The namespace must be your personal namespace.
 
-You can view the number of CI/CD minutes being used by a personal namespace:
+You can view the compute usage for a personal namespace:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Usage Quotas**.
 
 The projects list shows [personal projects](../../user/project/working_with_projects.md#view-personal-projects)
-with CI/CD minutes usage or shared runners usage in the current month only. The list
-is sorted in descending order of CI/CD minute usage.
+with compute usage or shared runners usage in the current month only. The list
+is sorted in descending order of compute usage.
 
-## Purchase additional CI/CD minutes **(FREE SAAS)**
+## Purchase additional units of compute **(FREE SAAS)**
 
-If you're using GitLab SaaS, you can purchase additional packs of CI/CD minutes.
-These additional CI/CD minutes:
+If you're using GitLab SaaS, you can purchase additional packs of units of compute.
+These additional units of compute:
 
 - Are used only after the monthly quota included in your subscription runs out.
 - Are carried over to the next month, if any remain at the end of the month.
-- Are valid for 12 months from date of purchase or until all minutes are consumed, whichever comes first. Expiry of minutes is not enforced.
+- Are valid for 12 months from date of purchase or until all units of compute are consumed, whichever comes first. Expiry of units of compute is not enforced.
 
 For example, with a GitLab SaaS Premium license:
 
-- You have `10,000` monthly minutes.
-- You purchase an additional `5,000` minutes.
-- Your total limit is `15,000` minutes.
+- You have `10,000` monthly units of compute.
+- You purchase an additional `5,000` units of compute.
+- Your total limit is `15,000` units of compute.
 
-If you use `13,000` minutes during the month, the next month your additional minutes become
-`2,000`. If you use `9,000` minutes during the month, your additional minutes remain the same.
+If you use `13,000` units of compute during the month, the next month your additional units of compute become
+`2,000`. If you use `9,000` units of compute during the month, your additional units of compute remain the same.
 
-If you bought additional CI/CD minutes while on a trial subscription, those minutes are available after the trial ends or you upgrade to a paid plan.
+If you bought additional units of compute while on a trial subscription, those units of compute are available after the trial ends or you upgrade to a paid plan.
 
-You can find pricing for additional CI/CD minutes on the
+You can find pricing for additional units of compute on the
 [GitLab Pricing page](https://about.gitlab.com/pricing/).
 
-### Purchase CI/CD minutes for a group **(FREE SAAS)**
+### Purchase units of compute for a group **(FREE SAAS)**
 
 Prerequisite:
 
 - You must have the Owner role for the group.
 
-You can purchase additional CI/CD minutes for your group.
-You cannot transfer purchased CI/CD minutes from one group to another,
+You can purchase additional units of compute for your group.
+You cannot transfer purchased units of compute from one group to another,
 so be sure to select the correct group.
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Usage Quotas**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Usage Quotas**.
 1. Select **Pipelines**.
-1. Select **Buy additional minutes**.
+1. Select **Buy additional units of compute**.
 1. Complete the details of the transaction.
 
-After your payment is processed, the additional CI/CD minutes are added to your group
+After your payment is processed, the additional units of compute are added to your group
 namespace.
 
-### Purchase CI/CD minutes for a personal namespace **(FREE SAAS)**
+### Purchase units of compute for a personal namespace **(FREE SAAS)**
 
 Prerequisite:
 
 - The namespace must be your personal namespace.
 
-To purchase additional minutes for your personal namespace:
+To purchase additional units of compute for your personal namespace:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Usage Quotas**.
-1. Select **Buy additional minutes**. GitLab redirects you to the Customers Portal.
-1. Locate the subscription card that's linked to your personal namespace on GitLab SaaS, select **Buy more CI minutes**,
+1. Select **Buy additional units of compute**. GitLab redirects you to the Customers Portal.
+1. Locate the subscription card that's linked to your personal namespace on GitLab SaaS, select **Buy more units of compute**,
    and complete the details of the transaction.
 
-After your payment is processed, the additional CI/CD minutes are added to your personal
+After your payment is processed, the additional units of compute are added to your personal
 namespace.
 
-## How CI/CD minute usage is calculated
+## How compute usage is calculated
 
-GitLab uses this formula to calculate the CI/CD minute usage of a job:
+GitLab uses this formula to calculate the compute usage of a job:
 
 ```plaintext
 Job duration * Cost factor
@@ -203,18 +206,18 @@ Job duration * Cost factor
   not including time spent in the `created` or `pending` statuses.
 - [**Cost factor**](#cost-factor): A number based on project visibility.
 
-The value is transformed into minutes and added to the count of used CI/CD minutes
+The value is transformed into units of compute and added to the count of used units
 in the job's top-level namespace.
 
 For example, if a user `alice` runs a pipeline:
 
-- Under the `gitlab-org` namespace, the CI/CD minutes used by each job in the pipeline are
+- Under the `gitlab-org` namespace, the units of compute used by each job in the pipeline are
   added to the overall consumption for the `gitlab-org` namespace, not the `alice` namespace.
-- For one of the personal projects in their namespace, the CI/CD minutes are added
+- For one of the personal projects in their namespace, the units of compute are added
   to the overall consumption for the `alice` namespace.
 
-The CI/CD minutes used by one pipeline is the total CI/CD minutes used by all the jobs
-that ran in the pipeline. Jobs can run concurrently, so the total CI/CD minutes usage
+The compute used by one pipeline is the total units of compute used by all the jobs
+that ran in the pipeline. Jobs can run concurrently, so the total compute usage
 can be higher than the end-to-end duration of a pipeline.
 
 ### Cost factor
@@ -225,24 +228,24 @@ The cost factors for jobs running on shared runners on GitLab.com are:
 - Exceptions for public projects:
   - `0.5` for projects in the [GitLab for Open Source program](../../subscriptions/community_programs.md#gitlab-for-open-source).
   - `0.008` for forks of projects in the [GitLab for Open Source program](../../subscriptions/community_programs.md#gitlab-for-open-source). For every 125 minutes of job execution time,
-  you use 1 CI/CD minute.
+  you use 1 unit of compute.
 - Discounted dynamically for [community contributions to GitLab projects](#cost-factor-for-community-contributions-to-gitlab-projects).
 
 The cost factors on self-managed instances are:
 
-- `0` for public projects, so they do not consume CI/CD minutes.
+- `0` for public projects, so they do not consume units of compute.
 - `1` for internal and private projects.
 
 #### Cost factor for community contributions to GitLab projects
 
 Community contributors can use up to 300,000 minutes on shared runners when contributing to open source projects
 maintained by GitLab. The maximum of 300,000 minutes would only be possible if contributing exclusively to projects [part of the GitLab product](https://about.gitlab.com/handbook/engineering/metrics/#projects-that-are-part-of-the-product). The total number of minutes available on shared runners
-is reduced by the CI/CD minutes used by pipelines from other projects.
+is reduced by the units of compute used by pipelines from other projects.
 The 300,000 minutes applies to all SaaS tiers, and the cost factor calculation is:
 
-- `Monthly minute quota / 300,000 job duration minutes = Cost factor`
+- `Monthly compute quota / 300,000 job duration minutes = Cost factor`
 
-For example, with the 10,000 CI/CD minutes per month in the Premium tier:
+For example, with a monthly compute quota of 10,000 in the Premium tier:
 
 - 10,000 / 300,000 = 0.03333333333 cost factor.
 
@@ -261,44 +264,46 @@ GitLab administrators can add a namespace to the reduced cost factor
 
 GitLab SaaS runners have different cost factors, depending on the runner type (Linux, Windows, macOS) and the virtual machine configuration.
 
-| GitLab SaaS runner type  | Machine Type   | CI/CD minutes cost factor  |
-| :--------- | :------------------- | :--------- |
-| Linux OS | Small  |1|
-| Linux OS | Medium  |2|
-| Linux OS | Large |3|
-| Linux OS + GPU-enabled | Medium, GPU Standard |7|
+| GitLab SaaS runner type      | Machine Size         | Cost factor |
+|:-----------------------------|:---------------------|:------------|
+| Linux OS amd64               | small                | 1           |
+| Linux OS amd64               | medium               | 2           |
+| Linux OS amd64               | large                | 3           |
+| Linux OS amd64 + GPU-enabled | medium, GPU standard | 7           |
+| macOS M1                     | Medium               | 6           |
+| Windows Server               | -                    | 1 (Beta)    |
 
-### Monthly reset of CI/CD minutes
+### Monthly reset of compute usage
 
-On the first day of each calendar month, the accumulated usage of CI/CD minutes is reset to `0`
+On the first day of each calendar month, the accumulated compute usage is reset to `0`
 for all namespaces that use shared runners. This means your full quota is available, and
 calculations start again from `0`.
 
-For example, if you have a monthly quota of `10,000` CI/CD minutes:
+For example, if you have a monthly quota of `10,000` units of compute:
 
-- On **April 1**, you have `10,000` minutes.
-- During April, you use only `6,000` of the `10,000` minutes.
-- On **May 1**, the accumulated usage of minutes resets to `0`, and you have `10,000` minutes to use again
+- On **April 1**, you have `10,000` units of compute.
+- During April, you use only `6,000` of the `10,000` units of compute.
+- On **May 1**, the accumulated compute usage resets to `0`, and you have `10,000` units of compute to use again
   during May.
 
 Usage data for the previous month is kept to show historical view of the consumption over time.
 
-### Monthly rollover of purchased CI/CD minutes
+### Monthly rollover of purchased units of compute
 
-If you purchase additional CI/CD minutes and don't use the full amount, the remaining amount rolls over to
+If you purchase additional units of compute and don't use the full amount, the remaining amount rolls over to
 the next month.
 
 For example:
 
-- On **April 1**, you purchase `5,000` additional CI/CD minutes.
-- During April, you use only `3,000` of the `5,000` additional minutes.
-- On **May 1**, the unused minute roll over, so you have `2,000` additional minutes available for May.
+- On **April 1**, you purchase `5,000` additional units of compute.
+- During April, you use only `3,000` of the `5,000` additional units of compute.
+- On **May 1**, the unused units of compute roll over, so you have `2,000` additional units of compute available for May.
 
-Additional CI/CD minutes are a one-time purchase and do not renew or refresh each month.
+Additional units of compute are a one-time purchase and do not renew or refresh each month.
 
 ## What happens when you exceed the quota
 
-When the quota of CI/CD minutes is used for the current month, GitLab stops
+When the compute quota is used for the current month, GitLab stops
 processing new jobs.
 
 - Any non-running job that should be picked by shared runners is automatically dropped.
@@ -306,29 +311,29 @@ processing new jobs.
 - Any running job can be dropped at any point if the overall namespace usage goes over-quota
   by a grace period.
 
-The grace period for running jobs is `1,000` CI/CD minutes.
+The grace period for running jobs is `1,000` units of compute.
 
-Jobs on project runners are not affected by the quota of CI/CD minutes.
+Jobs on project runners are not affected by the compute quota.
 
 ### GitLab SaaS usage notifications
 
 On GitLab SaaS an email notification is sent to the namespace owners when:
 
-- The available CI/CD minutes are below 30% of the quota.
-- The available CI/CD minutes are below 5% of the quota.
-- All CI/CD minutes have been used.
+- The remaining units of compute is below 30% of the quota.
+- The remaining units of compute is below 5% of the quota.
+- All the compute quota has been used.
 
 ### Special quota limits
 
 In some cases, the quota limit is replaced by one of the following labels:
 
-- **Unlimited minutes**: For namespaces with unlimited CI/CD minutes
-- **Not supported minutes**: For namespaces where active shared runners are not enabled
+- **Unlimited**: For namespaces with unlimited compute quota.
+- **Not supported**: For namespaces where active shared runners are not enabled.
 
-## Reduce consumption of CI/CD minutes
+## Reduce compute quota usage
 
-If your project consumes too many CI/CD minutes, there are some strategies you can
-use to reduce your CI/CD minutes usage:
+If your project consumes too much compute quota, there are some strategies you can
+use to reduce your usage:
 
 - If you are using project mirrors, ensure that [pipelines for mirror updates](../../user/project/repository/mirror/pull.md#trigger-pipelines-for-mirror-updates)
   is disabled.
@@ -342,23 +347,23 @@ use to reduce your CI/CD minutes usage:
 - If you are working from a fork and you submit a merge request to the parent project,
   you can ask a maintainer to run a pipeline [in the parent project](merge_request_pipelines.md#run-pipelines-in-the-parent-project).
 
-If you manage an open source project, these improvements can also reduce CI/CD minutes
+If you manage an open source project, these improvements can also reduce compute quota
 consumption for contributor fork projects, enabling more contributions.
 
 See our [pipeline efficiency guide](pipeline_efficiency.md) for more details.
 
-## Reset CI/CD minutes used **(PREMIUM SELF)**
+## Reset compute usage **(PREMIUM SELF)**
 
-An administrator can reset the number of minutes used by a namespace for the current month.
+An administrator can reset the compute usage for a namespace for the current month.
 
-### Reset minutes for a personal namespace
+### Reset usage for a personal namespace
 
 1. Find the [user in the admin area](../../user/admin_area/index.md#administering-users).
 1. Select **Edit**.
-1. In **Limits**, select **Reset pipeline minutes**.
+1. In **Limits**, select **Reset compute usage**.
 
-### Reset minutes for a group namespace
+### Reset usage for a group namespace
 
 1. Find the [group in the admin area](../../user/admin_area/index.md#administering-groups).
 1. Select **Edit**.
-1. In **Permissions and group features**, select **Reset pipeline minutes**.
+1. In **Permissions and group features**, select **Reset compute usage**.
diff --git a/doc/ci/pipelines/downstream_pipelines.md b/doc/ci/pipelines/downstream_pipelines.md
index ffcfee98f05..fdc03daf7ad 100644
--- a/doc/ci/pipelines/downstream_pipelines.md
+++ b/doc/ci/pipelines/downstream_pipelines.md
@@ -389,7 +389,7 @@ to the right of the [pipeline graph](index.md#visualize-pipelines).
 In [pipeline mini graphs](index.md#pipeline-mini-graphs), the downstream pipeline
 displays to the right of the mini graph.
 
-## Fetch artifacts from an upstream pipeline
+## Fetch artifacts from an upstream pipeline **(PREMIUM)**
 
 Use [`needs:project`](../yaml/index.md#needsproject) to fetch artifacts from an
 upstream pipeline:
@@ -661,6 +661,12 @@ For example, in a [multi-project pipeline](#multi-project-pipelines):
          artifacts: true
    ```
 
+### Control what type of variables to forward to downstream pipelines
+
+Use the [`trigger:forward` keyword](../yaml/index.md#triggerforward) to specify
+what type of variables to forward to the downstream pipeline. Forwarded variables
+are considered trigger variables, which have the [highest precedence](../variables/index.md#cicd-variable-precedence).
+
 ## Troubleshooting
 
 ### Trigger job fails and does not create multi-project pipeline
diff --git a/doc/ci/pipelines/img/group_cicd_minutes_quota.png b/doc/ci/pipelines/img/group_cicd_minutes_quota.png
deleted file mode 100644
index 318527426bd..00000000000
--- a/doc/ci/pipelines/img/group_cicd_minutes_quota.png
+++ /dev/null
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index b0c5f3a6a69..c99df5b15e6 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -109,10 +109,9 @@ Select a pipeline to open the **Pipeline Details** page and show
 the jobs that were run for that pipeline. From here you can cancel a running pipeline,
 retry jobs on a failed pipeline, or [delete a pipeline](#delete-a-pipeline).
 
-[Starting in GitLab 12.3](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/50499), a link to the
-latest pipeline for the last commit of a given branch is available at `/project/pipelines/[branch]/latest`.
-Also, `/project/pipelines/latest` redirects you to the latest pipeline for the last commit
-on the project's default branch.
+A link to the latest pipeline for the last commit of a given branch is available at
+`/project/-/pipelines/[branch]/latest`. Also, `/project/-/pipelines/latest` redirects
+you to the latest pipeline for the last commit on the project's default branch.
 
 [Starting in GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/215367),
 you can filter the pipeline list by:
@@ -140,8 +139,8 @@ operation of the pipeline.
 
 To execute a pipeline manually:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **CI/CD > Pipelines**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Build > Pipelines**.
 1. Select **Run pipeline**.
 1. In the **Run for branch name or tag** field, select the branch or tag to run the pipeline for.
 1. Enter any [CI/CD variables](../variables/index.md) required for the pipeline to run.
@@ -189,6 +188,11 @@ In this example:
 - `DEPLOY_ENVIRONMENT` is pre-filled in the **Run pipeline** page with `canary` as the default value,
   and the message explains the other options.
 
+NOTE:
+Because of a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/382857), projects that use [compliance pipelines](../../user/group/compliance_frameworks.md#compliance-pipelines) can have prefilled variables not appear
+when running a pipeline manually. To workaround this issue,
+[change the compliance pipeline configuration](../../user/group/compliance_frameworks.md#prefilled-variables-are-not-shown).
+
 #### Configure a list of selectable prefilled variable values
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/363660) in GitLab 15.5 [with a flag](../../administration/feature_flags.md) named `run_pipeline_graphql`. Disabled by default.
@@ -345,8 +349,8 @@ Prerequisites:
 
 To trigger the pipeline when the upstream project is rebuilt:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Pipeline subscriptions**.
 1. Enter the project you want to subscribe to, in the format `<namespace>/<project>`.
    For example, if the project is `https://gitlab.com/gitlab-org/gitlab`, use `gitlab-org/gitlab`.
diff --git a/doc/ci/pipelines/merge_request_pipelines.md b/doc/ci/pipelines/merge_request_pipelines.md
index d42f35627a2..045fa8dc16c 100644
--- a/doc/ci/pipelines/merge_request_pipelines.md
+++ b/doc/ci/pipelines/merge_request_pipelines.md
@@ -168,9 +168,7 @@ When you use merge request pipelines, you can use:
 - All the same [predefined variables](../variables/predefined_variables.md) that are
   available in branch pipelines.
 - [Additional predefined variables](../variables/predefined_variables.md#predefined-variables-for-merge-request-pipelines)
-  available only to jobs in merge request pipelines. These variables contain
-  information from the associated merge request, which can be when calling the
-  [GitLab Merge Request API endpoint](../../api/merge_requests.md) from a job.
+  available only to jobs in merge request pipelines.
 
 ## Troubleshooting
 
@@ -202,8 +200,8 @@ It's possible to have both branch pipelines and merge request pipelines in the
 **Pipelines** tab of a single merge request. This might be [by configuration](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines),
 or [by accident](#two-pipelines-when-pushing-to-a-branch).
 
-When using the [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
-feature and both pipelines types are present, the merge request pipelines are checked,
+When the project has [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge) enabled
+and both pipelines types are present, the merge request pipelines are checked,
 not the branch pipelines.
 
 Therefore, the MR pipeline result is marked as unsuccessful if the
diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md
index af29c8105ee..7bff13aa390 100644
--- a/doc/ci/pipelines/merge_trains.md
+++ b/doc/ci/pipelines/merge_trains.md
@@ -6,9 +6,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Merge trains **(PREMIUM)**
 
-FLAG:
-In GitLab 15.11 and later, the **Start merge train** button is **Set to auto-merge** and the **Add to merge train** button is **Merge**. On self-managed GitLab, by default these changes are not available. To make them available,
-ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `auto_merge_labels_mr_widget`. On GitLab.com, this feature is not available.
+NOTE:
+[In GitLab 16.0 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/359057), the **Start merge train**
+and **Start merge train when pipeline succeeds** buttons became **Set to auto-merge**.
+**Remove from merge train** became **Cancel auto-merge**.
 
 Use merge trains to queue merge requests and verify their changes work together before
 they are merged to the target branch.
@@ -29,14 +30,14 @@ For more information about:
 ## Merge train workflow
 
 A merge train starts when there are no merge requests waiting to merge and you
-select [**Start merge train**](#start-a-merge-train). GitLab starts a merge train pipeline
+select [**Merge**](#start-a-merge-train). GitLab starts a merge train pipeline
 that verifies that the changes can merge into the default branch. This first pipeline
 is the same as a [merged results pipeline](merged_results_pipelines.md), which runs on
 the changes of the source and target branches combined together. The author of the
 internal merged result commit is the user that initiated the merge.
 
 To queue a second merge request to merge immediately after the first pipeline completes, select
-[**Add to merge train**](#add-a-merge-request-to-a-merge-train) and add it to the train.
+[**Set to auto-merge**](#add-a-merge-request-to-a-merge-train) to add it to the train.
 This second merge train pipeline runs on the changes of _both_ merge requests combined with the
 target branch. Similarly, if you add a third merge request, that pipeline runs on the changes
 of all three merge requests merged with the target branch. The pipelines all run in parallel.
@@ -100,8 +101,8 @@ Prerequisites:
 
 To enable merge trains:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. In the **Merge method** section, verify that **Merge commit** is selected.
 1. In the **Merge options** section:
    - In GitLab 13.6 and later, select **Enable merged results pipelines** and **Enable merge trains**.
@@ -120,8 +121,8 @@ To start a merge train:
 
 1. Visit a merge request.
 1. Select:
-   - When no pipeline is running, **Start merge train**.
-   - When a pipeline is running, **Start merge train when pipeline succeeds**.
+   - When no pipeline is running, **Merge**.
+   - When a pipeline is running, **Set to auto-merge**.
 
 The merge request's merge train status displays under the pipeline widget with a
 message similar to `A new merge train has started and this merge request is the first of the queue.`
@@ -138,8 +139,8 @@ To add a merge request to a merge train:
 
 1. Visit a merge request.
 1. Select:
-   - When no pipeline is running, **Add to merge train**.
-   - When a pipeline is running, **Add to merge train when pipeline succeeds**.
+   - When no pipeline is running, **Merge**.
+   - When a pipeline is running, **Set to auto-merge**.
 
 The merge request's merge train status displays under the pipeline widget with a
 message similar to `Added to the merge train. There are 2 merge requests waiting to be merged.`
@@ -151,7 +152,7 @@ waiting to join the merge train.
 
 ## Remove a merge request from a merge train
 
-To remove a merge request from a merge train, select **Remove from merge train**.
+To remove a merge request from a merge train, select **Cancel auto-merge**.
 You can add the merge request to a merge train again later.
 
 When you remove a merge request from a merge train:
@@ -191,8 +192,7 @@ can enable the feature flag to disable merge trains:
 Feature.enable(:disable_merge_trains)
 ```
 
-After you enable this feature flag, GitLab cancels existing merge trains and removes
-the **Start/Add to merge train** option from merge requests.
+After you enable this feature flag, GitLab cancels existing merge trains.
 
 To disable the feature flag, which enables merge trains again:
 
@@ -209,18 +209,18 @@ the merge train drops your merge request automatically. For example, this could
 
 - Changing the merge request to a [draft](../../user/project/merge_requests/drafts.md).
 - A merge conflict.
-- A new conversation thread that is unresolved, when [all threads must be resolved](../../user/discussions/index.md#prevent-merge-unless-all-threads-are-resolved)
+- A new conversation thread that is unresolved, when [all threads must be resolved](../../user/project/merge_requests/index.md#prevent-merge-unless-all-threads-are-resolved)
   is enabled.
 
 You can find reason the merge request was dropped from the merge train in the system
 notes. Check the **Activity** section in the **Overview** tab for a message similar to:
 `User removed this merge request from the merge train because ...`
 
-### Cannot use merge when pipeline succeeds
+### Cannot use auto-merge
 
-You cannot use [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
-when merge trains are enabled. See [the related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/12267)
-for more information.
+You cannot use [auto-merge](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
+(formerly **Merge when pipeline succeeds**) to skip the merge train, when merge trains are enabled.
+See [issue 12267](https://gitlab.com/gitlab-org/gitlab/-/issues/12267) for more information.
 
 ### Cannot retry merge train pipeline cannot
 
@@ -241,7 +241,7 @@ You can:
 When [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge)
 is enabled, but the latest pipeline failed:
 
-- The **Start/Add to merge train** option is not available.
+- The **Set to auto-merge** or **Merge** options are not available.
 - The merge request displays `The pipeline for this merge request failed. Please retry the job or push a new commit to fix the failure.`
 
 Before you can re-add a merge request to a merge train, you can try to:
diff --git a/doc/ci/pipelines/merged_results_pipelines.md b/doc/ci/pipelines/merged_results_pipelines.md
index 316d7819f55..16120924f37 100644
--- a/doc/ci/pipelines/merged_results_pipelines.md
+++ b/doc/ci/pipelines/merged_results_pipelines.md
@@ -41,8 +41,8 @@ To use merged results pipelines:
 To enable merged results pipelines in a project, you must have at least the
 Maintainer role:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. In the **Merge options** section, select **Enable merged results pipelines**.
 1. Select **Save changes**.
 
diff --git a/doc/ci/pipelines/pipeline_artifacts.md b/doc/ci/pipelines/pipeline_artifacts.md
index d8db79a54dc..79435c0276d 100644
--- a/doc/ci/pipelines/pipeline_artifacts.md
+++ b/doc/ci/pipelines/pipeline_artifacts.md
@@ -2,28 +2,13 @@
 stage: Verify
 group: Pipeline Security
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../testing/test_coverage_visualization.md'
+remove_date: '2023-08-31'
 ---
 
-# Pipeline artifacts **(FREE)**
+This document was moved to [another location](../testing/test_coverage_visualization.md).
 
-Pipeline artifacts are files created by GitLab after a pipeline finishes. Pipeline artifacts are
-different to [job artifacts](../jobs/job_artifacts.md) because they are not explicitly managed by
-`.gitlab-ci.yml` definitions.
-
-Pipeline artifacts are used by the [test coverage visualization feature](../testing/test_coverage_visualization.md)
-to collect coverage information.
-
-## Storage
-
-Pipeline artifacts are saved to disk or object storage. They count towards a project's [storage usage quota](../../user/usage_quotas.md#storage-usage-quota).
-The **Artifacts** on the Usage Quotas page is the sum of all job artifacts and pipeline artifacts.
-
-## When pipeline artifacts are deleted
-
-Pipeline artifacts from:
-
-- The latest pipeline are kept forever.
-- Pipelines superseded by a newer pipeline are deleted seven days after their creation date.
-
-It can take up to two days for GitLab to delete pipeline artifacts from when they are due to be
-deleted.
+<!-- This redirect file can be deleted after <2023-08-31>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/ci/pipelines/pipeline_security.md b/doc/ci/pipelines/pipeline_security.md
new file mode 100644
index 00000000000..f035779e665
--- /dev/null
+++ b/doc/ci/pipelines/pipeline_security.md
@@ -0,0 +1,48 @@
+---
+stage: Verify
+group: Pipeline Security
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+type: reference
+---
+
+# Pipeline security
+
+## Secrets Management
+
+Secrets management is the systems that developers use to securely store sensitive data
+in a secure environment with strict access controls. A **secret** is a sensitive credential
+that should be kept confidential, and includes:
+
+- Passwords
+- SSH keys
+- Access tokens
+- Other types of credentials
+
+## Secrets storage
+
+### Secrets management providers
+
+Secrets that are the most sensitive and under the strictest policies should be stored
+in a separate secrets management provider such as [Vault](https://www.vaultproject.io).
+The secrets are stored outside of the GitLab instance, which is the safest option.
+
+You can use the GitLab [Vault integration](../secrets/index.md#use-vault-secrets-in-a-ci-job)
+to retrieve those secrets in CI/CD pipelines when they are needed.
+
+### CI/CD variables
+
+[CI/CD Variables](../variables/index.md) are a convenient way to store and use data
+in a CI/CD pipeline, but variables are less secure than secrets management providers.
+Variable values:
+
+- Are stored in the GitLab project, group, or instance settings. Users with access
+  to the settings have access to the variables.
+- Can be [overridden](../variables/index.md#override-a-defined-cicd-variable),
+  making it hard to determine which value was used.
+- Are more easily exposed by accidental pipeline misconfiguration.
+
+Sensitive data should be stored in a secrets management solution. If there is low
+sensitivity data that you want to store in a CI/CD variable, be sure to always:
+
+- [Mask the variables](../variables/index.md#mask-a-cicd-variable).
+- [Protect the variables](../variables/index.md#protect-a-cicd-variable) when possible.
diff --git a/doc/ci/pipelines/schedules.md b/doc/ci/pipelines/schedules.md
index 3ff748644cf..49b129f11aa 100644
--- a/doc/ci/pipelines/schedules.md
+++ b/doc/ci/pipelines/schedules.md
@@ -14,7 +14,7 @@ Use scheduled pipelines to run GitLab CI/CD [pipelines](index.md) at regular int
 For a scheduled pipeline to run:
 
 - The schedule owner must have the Developer role. For pipelines on protected branches,
-  the schedule owner must be [allowed to merge](../../user/project/protected_branches.md#configure-a-protected-branch)
+  the schedule owner must be [allowed to merge](../../user/project/protected_branches.md#add-protection-to-existing-branches)
   to the branch.
 - The [CI/CD configuration](../yaml/index.md) must be valid.
 
@@ -26,8 +26,8 @@ Otherwise, the pipeline is not created. No error message is displayed.
 
 To add a pipeline schedule:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **CI/CD > Schedules**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Build > Pipeline schedules**.
 1. Select **New schedule** and fill in the form.
    - **Interval Pattern**: Select one of the preconfigured intervals, or enter a custom
      interval in [cron notation](../../topics/cron/index.md). You can use any cron value,
@@ -47,8 +47,8 @@ you must delete unused schedules before you can add another.
 
 The owner of a pipeline schedule can edit it:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. In the left sidebar, select **CI/CD > Schedules**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Build > Pipeline schedules**.
 1. Next to the schedule, select **Edit** (**{pencil}**) and fill in the form.
 
 The user must have the Developer role or above for the project. If the user is
@@ -60,8 +60,8 @@ of the schedule.
 To trigger a pipeline schedule manually, so that it runs immediately instead of
 the next scheduled time:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **CI/CD > Schedules**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Build > Pipeline schedules**.
 1. On the right of the list, for
    the pipeline you want to run, select **Play** (**{play}**).
 
@@ -76,11 +76,13 @@ including [protected environments](../environments/protected_environments.md) an
 
 To take ownership of a pipeline created by a different user:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **CI/CD > Schedules**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Build > Pipeline schedules**.
 1. On the right of the list, for
    the pipeline you want to become owner of, select **Take ownership**.
 
+You need at least the Maintainer role to take ownership of a pipeline created by a different user.
+
 ## Related topics
 
 - [Pipeline schedules API](../../api/pipeline_schedules.md)
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 3e9e6c50f64..38cdc5ed578 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -24,8 +24,8 @@ For public and internal projects, you can change who can see your:
 
 To change the visibility of your pipelines and related features:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 1. Select or clear the **Public pipelines** checkbox.
    When it is selected, pipelines and related features are visible:
@@ -56,8 +56,8 @@ This setting has no effect when:
 
 To change the pipeline visibility for non-project members:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. For **CI/CD**, choose:
    - **Only project members**: Only project members can view pipelines.
@@ -72,8 +72,8 @@ is selected.
 
 You can set pending or running pipelines to cancel automatically when a pipeline for new changes runs on the same branch. You can enable this in the project settings:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **General Pipelines**.
 1. Select the **Auto-cancel redundant pipelines** checkbox.
 1. Select **Save changes**.
@@ -94,8 +94,8 @@ newer one, which may not be what you want.
 
 To avoid this scenario:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 1. Select the **Prevent outdated deployment jobs** checkbox.
 1. Select **Save changes**.
@@ -111,8 +111,8 @@ directory. However, you can specify an alternate filename path, including locati
 
 To customize the path:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 1. In the **CI/CD configuration file** field, enter the filename. If the file:
    - Is not in the root directory, include the path.
@@ -160,8 +160,8 @@ able to edit it.
 
 You can choose how your repository is fetched from GitLab when a job runs.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 1. Under **Git strategy**, select an option:
    - `git clone` is slower because it clones the repository from scratch
@@ -181,8 +181,8 @@ in the `.gitlab-ci.yml` file.
 You can limit the number of changes that GitLab CI/CD fetches when it clones
 a repository.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 1. Under **Git strategy**, under **Git shallow clone**, enter a value.
    The maximum value is `1000`. To disable shallow clone and make GitLab CI/CD
@@ -198,8 +198,8 @@ in the `.gitlab-ci.yml` file.
 
 You can define how long a job can run before it times out.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 1. In the **Timeout** field, enter the number of minutes, or a human-readable value like `2 hours`.
    Must be 10 minutes or more, and less than one month. Default is 60 minutes.
diff --git a/doc/ci/quick_start/tutorial.md b/doc/ci/quick_start/tutorial.md
index 88d35bf56b0..acc47a07a02 100644
--- a/doc/ci/quick_start/tutorial.md
+++ b/doc/ci/quick_start/tutorial.md
@@ -36,7 +36,8 @@ Before adding the pipeline configuration, you must first set up a Docusaurus pro
 on GitLab.com:
 
 1. Create a new project under your username (not a group):
-   1. On the top bar, select **Main menu > Projects > View all projects**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **View all your projects**.
    1. On the right of the page, select **New project**.
    1. Select **Create blank project**.
    1. Enter the project details:
diff --git a/doc/ci/resource_groups/index.md b/doc/ci/resource_groups/index.md
index bae1bd9712b..74e3e493adb 100644
--- a/doc/ci/resource_groups/index.md
+++ b/doc/ci/resource_groups/index.md
@@ -75,7 +75,7 @@ The following modes are supported:
 
 - **Unordered:** This is the default process mode that limits the concurrency on running jobs.
   It's the easiest option to use when you don't care about the execution order
-  of the jobs. It starts processing the jobs whenever a job ready to run.
+  of the jobs. It starts processing the jobs whenever a job is ready to run.
 - **Oldest first:** This process mode limits the concurrency of the jobs. When a resource is free,
   it picks the first job from the list of upcoming jobs (`created`, `scheduled`, or `waiting_for_resource` state)
   that are sorted by pipeline ID in ascending order.
diff --git a/doc/ci/review_apps/img/review_apps_preview_in_mr.png b/doc/ci/review_apps/img/review_apps_preview_in_mr.png
deleted file mode 100644
index 3e6506a6a3a..00000000000
--- a/doc/ci/review_apps/img/review_apps_preview_in_mr.png
+++ /dev/null
diff --git a/doc/ci/review_apps/img/review_apps_preview_in_mr_v16_0.png b/doc/ci/review_apps/img/review_apps_preview_in_mr_v16_0.png
new file mode 100644
index 00000000000..40345b9987f
--- /dev/null
+++ b/doc/ci/review_apps/img/review_apps_preview_in_mr_v16_0.png
diff --git a/doc/ci/review_apps/img/view_on_env_blob.png b/doc/ci/review_apps/img/view_on_env_blob.png
deleted file mode 100644
index acc457fbb38..00000000000
--- a/doc/ci/review_apps/img/view_on_env_blob.png
+++ /dev/null
diff --git a/doc/ci/review_apps/img/view_on_env_mr.png b/doc/ci/review_apps/img/view_on_env_mr.png
deleted file mode 100644
index 0e61814a65d..00000000000
--- a/doc/ci/review_apps/img/view_on_env_mr.png
+++ /dev/null
diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md
index 004bd9dfc5f..ddb8f0aaa61 100644
--- a/doc/ci/review_apps/index.md
+++ b/doc/ci/review_apps/index.md
@@ -16,7 +16,7 @@ Review apps:
 
 - Provide an automatic live preview of changes made in a feature branch by spinning up a dynamic environment for your merge requests.
 - Allow designers and product managers to see your changes without needing to check out your branch and run your changes in a sandbox environment.
-- Are fully integrated with the [GitLab DevOps LifeCycle](../../index.md#the-entire-devops-lifecycle).
+- Are fully integrated with the [GitLab DevOps LifeCycle](https://about.gitlab.com/stages-devops-lifecycle/).
 - Allow you to deploy your changes wherever you want.
 
 ![review apps workflow](img/continuous-delivery-review-apps.svg)
@@ -35,7 +35,7 @@ Access to the review app is made available as a link on the [merge request](../.
 
 The following is an example of a merge request with an environment set dynamically.
 
-![review app in merge request](img/review_apps_preview_in_mr.png)
+![review app in merge request](img/review_apps_preview_in_mr_v16_0.png)
 
 In this example, a branch was:
 
@@ -76,8 +76,9 @@ Prerequisite:
 
 To use the review apps template:
 
-1. On the top bar, select **Main menu > Projects** and find the project you want to create a review app job for.
-1. On the left sidebar, select **Deployments > Environments**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to
+   find the project you want to create a review app job for.
+1. Select **Build > Environments**.
 1. Select **Enable review apps**.
 1. Copy the provided code snippet and paste it into your
    `.gitlab-ci.yml` file:
@@ -185,13 +186,9 @@ After you have the route mapping set up, it takes effect in the following locati
 
     ![View app file list in merge request widget](img/view_on_mr_widget.png)
 
-- In the diff for a comparison or commit.
+- In the diff for a comparison or commit, by selecting **View** (**{external-link}**) next to the file.
 
-  ![View on environment button in merge request diff](img/view_on_env_mr.png)
-
-- In the blob file view.
-
-  ![View on environment button in file view](img/view_on_env_blob.png)
+- In the blob file view, by selecting **View** (**{external-link}**) next to the file.
 
 <!--- start_remove The following content will be removed on remove_date: '2024-05-22' -->
 ## Visual Reviews (deprecated) **(PREMIUM)**
diff --git a/doc/ci/runners/configure_runners.md b/doc/ci/runners/configure_runners.md
index cf4b95f511d..c365cc934db 100644
--- a/doc/ci/runners/configure_runners.md
+++ b/doc/ci/runners/configure_runners.md
@@ -161,7 +161,8 @@ Prerequisite:
 
 To determine the IP address of a shared runner:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **CI/CD > Runners**.
 1. Find the runner in the table and view the **IP Address** column.
 
@@ -955,8 +956,8 @@ You can clean up group runners that have been inactive for more than three month
 
 Group runners are those that were created at the group level.
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 1. Turn on the **Enable stale runner cleanup** toggle.
 
@@ -999,8 +1000,13 @@ The version of GitLab Runner used by your runners should be
 To determine which runners need to be upgraded:
 
 1. View the list of runners:
-   - For a group, on the top bar, select **Main menu > Groups**, find your group, and on the left sidebar select **CI/CD > Runners**.
-   - For the instance, select **Main menu > Admin** and on the left sidebar, select **Runners**.
+   - For a group:
+     1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+     1. Select **Build > Runners**.
+   - For the instance:
+     1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+     1. Select **Admin Area**.
+     1. Select **CI/CD > Runners**.
 
 1. Above the list of runners, view the status:
    - **Outdated - recommended**: The runner does not have the latest `PATCH` version, which may make it vulnerable
@@ -1055,7 +1061,8 @@ Prerequisites:
 
 To automatically rotate runner authentication tokens:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**..
 1. On the left sidebar, select **Settings > CI/CD**.
 1. Expand **Continuous Integration and Deployment**
 1. Set a **Runners expiration** time for runners, leave empty for no expiration.
diff --git a/doc/ci/runners/img/build_isolation.png b/doc/ci/runners/img/build_isolation.png
index a363ef4709b..ca920999bbf 100644
--- a/doc/ci/runners/img/build_isolation.png
+++ b/doc/ci/runners/img/build_isolation.png
diff --git a/doc/ci/runners/index.md b/doc/ci/runners/index.md
index 6883f0727dd..19c5be88c1b 100644
--- a/doc/ci/runners/index.md
+++ b/doc/ci/runners/index.md
@@ -7,34 +7,63 @@ type: reference
 
 # Runner SaaS **(FREE SAAS)**
 
-If you use GitLab SaaS (GitLab.com), your [untagged](../../ci/runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run) CI jobs automatically run in containers on the Linux Runners.
-As long as shared runners are enabled for your project, no configuration is required. Your jobs can run on:
+You can run your CI/CD jobs on GitLab.com using SaaS runners hosted by GitLab to seamlessly build, test and deploy
+your application on different environments.
+These runners fully integrated with GitLab.com and are enabled by default for all projects, with no configuration required.
+Your jobs can run on:
 
-- [Linux runners](saas/linux_saas_runner.md).
-- [Windows runners](saas/windows_saas_runner.md) ([Beta](../../policy/alpha-beta-support.md#beta)).
-- [macOS runners](saas/macos_saas_runner.md) ([Beta](../../policy/alpha-beta-support.md#beta)).
+- [Linux runners](saas/linux_saas_runner.md)
+- [GPU runners](saas/gpu_saas_runner.md)
+- [Windows runners](saas/windows_saas_runner.md) ([Beta](../../policy/experiment-beta-support.md#beta))
+- [macOS runners](saas/macos_saas_runner.md) ([Beta](../../policy/experiment-beta-support.md#beta))
 
-The number of minutes you can use on these runners depends on the
-[maximum number of CI/CD minutes](../pipelines/cicd_minutes.md)
+Refer to the Compute [cost factor](../../ci/pipelines/cicd_minutes.md#cost-factor) for the cost factor applied to the machine type based on size.
+The number of minutes you can use on these runners depends on the [maximum number of units of compute](../pipelines/cicd_minutes.md)
 in your [subscription plan](https://about.gitlab.com/pricing/).
 
-## Security for GitLab SaaS runners
+[Untagged](../../ci/runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run) jobs automatically run in containers
+on the `small` Linux runners.
 
-GitLab SaaS runners on Linux and Windows run on Google Compute Platform. The [Google Infrastructure Security Design Overview whitepaper](https://cloud.google.com/docs/security/infrastructure/design/resources/google_infrastructure_whitepaper_fa.pdf) provides an overview of how Google designs security into its technical infrastructure. The GitLab [Trust Center](https://about.gitlab.com/security/) and [GitLab Security Compliance Controls](https://about.staging.gitlab.com/handbook/engineering/security/security-assurance/security-compliance/sec-controls.html) pages provide an overview of the security and compliance controls that govern the GitLab SaaS runners.
+The objective is to make 90% of CI jobs start executing in 120 seconds or less. The error rate should be less than 0.5%.
 
-The runner that serves as a runner manager automatically initiates the creation and deletion of the virtual machines (VMs) used for CI jobs. When the runner manager picks up a GitLab SaaS CI job, it automatically executes that job on a new VM. There is no human or manual intervention in this process. The following section provides an overview of the additional built-in layers that harden the security of the GitLab Runner SaaS CI build environment.
+## How SaaS runners work
 
-### Security of CI job execution on GitLab Runner SaaS (Linux, Windows)
+When you use SaaS runners:
+
+- Each of your jobs runs in a newly provisioned VM, which is dedicated to the specific job.
+- The VM is active only for the duration of the job and immediately deleted. This means that any changes that your job makes to the virtual machine will not be available to a subsequent job.
+- The virtual machine where your job runs has `sudo` access with no password.
+- The storage is shared by the operating system, the image with pre-installed software, and a copy of your cloned repository.
+This means that the available free disk space for your jobs to use is reduced.
+
+NOTE:
+Jobs handled by SaaS runners on GitLab.com **time out after 3 hours**, regardless of the timeout configured in a project.
+
+## Security for SaaS runners
+
+GitLab SaaS runners on Linux and Windows run on Google Compute Platform.
+The [Google Infrastructure Security Design Overview whitepaper](https://cloud.google.com/docs/security/infrastructure/design/resources/google_infrastructure_whitepaper_fa.pdf)
+provides an overview of how Google designs security into its technical infrastructure.
+The GitLab [Trust Center](https://about.gitlab.com/security/) and
+[GitLab Security Compliance Controls](https://about.staging.gitlab.com/handbook/engineering/security/security-assurance/security-compliance/sec-controls.html)
+pages provide an overview of the security and compliance controls that govern the GitLab SaaS runners.
+
+The following section provides an overview of the additional built-in layers that harden the security of the GitLab Runner SaaS CI build environment.
+
+### Security of CI job execution
 
 A dedicated temporary runner VM hosts and runs each CI job. On GitLab SaaS, two CI jobs never run on the same VM.
 
+In this example, there are three jobs in the project's pipeline. Therefore, there are three temporary VMs used to run that pipeline, or one VM per job.
+
 ![Job isolation](img/build_isolation.png)
 
-In this example, there are three jobs in the project's pipeline. Therefore, there are three temporary VMs used to run that pipeline, or one VM per job.
+The build job ran on `runner-ns46nmmj-project-43717858`, test job on `f131a6a2runner-new2m-od-project-43717858` and deploy job on `runner-tmand5m-project-43717858`.
 
-GitLab sends the command to remove the temporary runner VM to the Google Compute API immediately after the CI job completes. The [Google Compute Engine hypervisor](https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext) takes over the task of securely deleting the virtual machine and associated data.
+GitLab sends the command to remove the temporary runner VM to the Google Compute API immediately after the CI job completes. The [Google Compute Engine hypervisor](https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext)
+takes over the task of securely deleting the virtual machine and associated data.
 
-### Network security of CI job virtual machines on GitLab Runner SaaS (Linux, Windows)
+### Network security of CI job VMs
 
 - Firewall rules only allow outbound communication from the temporary VM to the public internet.
 - Inbound communication from the public internet to the temporary VM is not allowed.
diff --git a/doc/ci/runners/new_creation_workflow.md b/doc/ci/runners/new_creation_workflow.md
new file mode 100644
index 00000000000..0c43fd21d1d
--- /dev/null
+++ b/doc/ci/runners/new_creation_workflow.md
@@ -0,0 +1,199 @@
+---
+stage: Verify
+group: Runner
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Migrating to the new runner registration workflow **(FREE)**
+
+DISCLAIMER:
+This page contains information related to upcoming products, features, and functionality.
+It is important to note that the information presented is for informational purposes only.
+Please do not rely on this information for purchasing or planning purposes.
+As with all projects, the items mentioned on this page are subject to change or delay.
+The development, release, and timing of any products, features, or functionality remain at the
+sole discretion of GitLab Inc.
+
+In GitLab 16.0, we introduced a new runner creation workflow that uses authentication tokens to register
+runners. The legacy workflow that uses registration tokens is deprecated and will be removed in GitLab 17.0.
+
+For information about the current development status of the new workflow, see [epic 7663](https://gitlab.com/groups/gitlab-org/-/epics/7663).
+
+For information about the technical design and reasons for the new architecture, see [Next GitLab Runner Token Architecture](../../architecture/blueprints/runner_tokens/index.md).
+
+## Feedback
+
+If you experience problems or have concerns about the new runner registration workflow,
+or if the following information is not sufficient,
+you can let us know in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/387993).
+
+## The new runner registration workflow
+
+For the new runner registration workflow, you:
+
+1. [Create a runner](register_runner.md) directly in the GitLab UI.
+1. Receive an authentication token.
+1. Use the authentication token instead of the registration token when you register
+   a runner with this configuration. Runner managers registered in multiple hosts appear
+   under the same runner in the GitLab UI, but with an identifying system ID.
+
+The new runner registration workflow has the following benefits:
+
+- Preserved ownership records for runners, and minimized impact on users.
+- The addition of a unique system ID ensures that you can reuse the same authentication token across
+multiple runners. For more information, see [Reusing a GitLab Runner configuration](https://docs.gitlab.com/runner/fleet_scaling/#reusing-a-gitlab-runner-configuration).
+
+## Estimated time frame for planned changes
+
+- In GitLab 15.10 and later, you can use the new runner registration workflow.
+- In GitLab 16.6, we plan to disable registration tokens.
+- In GitLab 17.0, we plan to completely remove support for runner registration tokens.
+
+## Prevent your runner registration workflow from breaking
+
+Until GitLab 16.6, you can still use the legacy runner registration workflow.
+
+In GitLab 16.6, the legacy runner registration workflow will be disabled automatically. You will be able to manually re-enable the legacy runner registration workflow for a limited time. For more information, see
+[Using registration tokens after GitLab 16.6](#using-registration-tokens-after-gitlab-166).
+
+If no action is taken before your GitLab instance is upgraded to GitLab 16.6, then your runner registration
+workflow will break.
+
+To avoid a broken workflow, you must:
+
+1. [Create a shared runner](register_runner.md#for-a-shared-runner) and obtain the authentication token.
+1. Replace the registration token in your runner registration workflow with the
+authentication token.
+
+## Using registration tokens after GitLab 16.6
+
+To continue using registration tokens after GitLab 16.6:
+
+- On GitLab.com, you can manually re-enable the legacy runner registration process in the top-level group settings until GitLab 16.8.
+- On GitLab self-managed, you can manually re-enable the legacy runner registration process in the Admin Area settings until GitLab 17.0.
+
+Plans to implement a UI setting to re-enable registration tokens are proposed in [issue 411923](https://gitlab.com/gitlab-org/gitlab/-/issues/411923)
+
+## Changes to the `gitlab-runner register` command syntax
+
+The `gitlab-runner register` command will stop accepting registration tokens and instead accept new
+authentication tokens generated in the GitLab runners administration page.
+These authentication tokens are recognizable by their `glrt-` prefix.
+
+Example command for GitLab 15.9:
+
+```shell
+gitlab-runner register
+    --non-interactive \
+    --executor "shell" \
+    --url "https://gitlab.com/" \
+    --tag-list "shell,mac,gdk,test" \
+    --run-untagged "false" \
+    --locked "false" \
+    --access-level "not_protected" \
+    --registration-token "GR1348941C6YcZVddc8kjtdU-yWYD"
+```
+
+In GitLab 15.10 and later, you create the runner and some of the attributes in the UI, like the
+tag list, locked status, and access level.
+In GitLab 15.11 and later, these attributes are no longer accepted as arguments to `register`.
+
+The following example shows the new command:
+
+```shell
+gitlab-runner register
+    --non-interactive \
+    --executor "shell" \
+    --url "https://gitlab.com/" \
+    --token "glrt-2CR8_eVxiioB1QmzPZwa"
+```
+
+## Impact on autoscaling
+
+In autoscaling scenarios such as GitLab Runner Operator or GitLab Runner Helm Chart, the
+registration token is replaced with the authentication token generated from the UI.
+This means that the same runner configuration is reused across jobs, instead of creating a runner
+for each job.
+The specific runner can be identified by the unique system ID that is generated when the runner
+process is started.
+
+## Impact on existing runners
+
+Existing runners will continue to work as usual. This change only affects registration of new runners.
+
+## Creating runners programmatically
+
+A new [POST /user/runners REST API](../../api/users.md#create-a-runner) was introduced in
+GitLab 15.11, which allows a runner to be created in the context of an authenticated user. This should only be used in
+scenarios where the runner configuration is dynamic, or not reusable. If the runner configuration is static, it is
+preferable to reuse the authentication token of an existing runner.
+
+The following snippet shows how a group runner could be created and registered with a
+[Group Access Token](../../user/group/settings/group_access_tokens.md) using the new creation flow.
+The process is very similar when using [Project Access Tokens](../../user/project/settings/project_access_tokens.md)
+or [Personal Access Tokens](../../user/profile/personal_access_tokens.md):
+
+```shell
+# `GROUP_ID` contains the numerical ID of the group where the runner will be created
+# `GITLAB_TOKEN` can be a Personal Access Token for a group owner, or a Group Access Token on the respective group
+#   created with `owner` access and `api` scope.
+#
+# The output will be parsed by `jq` to extract the token of the newly created runner
+RUNNER_TOKEN=$(curl --silent --request POST "https://gitlab.com/api/v4/user/runners" \
+    --header "private-token: $GITLAB_TOKEN" \
+    --data runner_type=group_type --data group_id=$GROUP_ID --data 'description=My runner' --data 'tag_list=java,linux' \
+  | jq -r '.token')
+
+gitlab-runner register \
+    --non-interactive \
+    --executor "shell" \
+    --url "https://gitlab.com/" \
+    --token "$RUNNER_TOKEN"
+```
+
+## Installing GitLab Runner with Helm chart
+
+Several runner configuration options cannot be set during runner registration. These options can only be configured:
+
+- When you create a runner in the UI.
+- With the `user/runners` REST API endpoint.
+
+The following configuration options are no longer supported in [`values.yaml`](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/main/values.yaml):
+
+```yaml
+## All these fields are DEPRECATED and the runner WILL FAIL TO START if you specify them
+runnerRegistrationToken: ""
+locked: true
+tags: ""
+maximumTimeout: ""
+runUntagged: true
+protected: true
+```
+
+If you store the runner token in `secrets`, you must also modify them.
+
+In the legacy runner registration workflow, fields were specified with:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: gitlab-runner-secret
+type: Opaque
+data:
+  runner-registration-token: "REDACTED" # DEPRECATED, set to ""
+  runner-token: ""
+```
+
+In the new runner registration workflow, you must use `runner-token` instead:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: gitlab-runner-secret
+type: Opaque
+data:
+  runner-registration-token: "" # need to leave as an empty string for compatibility reasons
+  runner-token: "REDACTED"
+```
diff --git a/doc/ci/runners/register_runner.md b/doc/ci/runners/register_runner.md
index f53297099d7..9c63850e38a 100644
--- a/doc/ci/runners/register_runner.md
+++ b/doc/ci/runners/register_runner.md
@@ -33,7 +33,8 @@ Prerequisites:
 
 To generate an authentication token for a shared runner:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **CI/CD > Runners**.
 1. Select **New instance runner**.
 1. Select a platform.
@@ -41,6 +42,8 @@ To generate an authentication token for a shared runner:
 1. Select **Submit**.
 1. Follow the instructions to register the runner from the command line.
 
+You can also [create a runner](../../api/users.md#create-a-runner) with the API to generate an authentication token.
+
 ### For a group runner
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/383143) in GitLab 15.10. Deployed behind the `create_runner_workflow_for_namespace` [flag](../../administration/feature_flags.md). Disabled by default.
@@ -56,14 +59,16 @@ Prerequisites:
 
 To generate an authentication token for a group runner:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **CI/CD > Runners**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Build > Runners**.
 1. Select **New group runner**.
 1. Select a platform.
 1. Optional. Enter configurations for the runner.
 1. Select **Submit**.
 1. Follow the instructions to register the runner from the command line.
 
+You can also [create a runner](../../api/users.md#create-a-runner) with the API to generate an authentication token.
+
 ### For a project runner
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/383143) in GitLab 15.10. Deployed behind the `create_runner_workflow_for_namespace` [flag](../../administration/feature_flags.md). Disabled by default.
@@ -79,39 +84,45 @@ Prerequisites:
 
 To generate an authentication token for a project runner:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
+1. Expand the **Runners** section.
 1. Select **New project runner**.
 1. Select a platform.
 1. Optional. Enter configurations for the runner.
 1. Select **Submit**.
 1. Follow the instructions to register the runner from the command line.
 
+You can also [create a runner](../../api/users.md#create-a-runner) with the API to generate an authentication token.
+
 ## Generate a registration token (deprecated)
 
 WARNING:
 The ability to pass a runner registration token, and support for certain configuration arguments was
 [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/380872) in GitLab 15.6. Authentication tokens
-should be used instead to register runners. Registration tokens, and support for certain configuration arguments
-will be disabled behind a feature flag in GitLab 16.6 and removed in GitLab 17.0. The configuration arguments disabled for `glrt-` tokens are `--locked`, `--access-level`, `--run-untagged`, `--maximum-timeout`, `--paused`, `--tag-list`, and `--maintenance-note`. This change is a breaking
+should be used instead to register runners. Registration tokens, and support for certain configuration
+arguments, will be removed in GitLab 17.0. For more information, see [Migrating to the new runner registration workflow](new_creation_workflow.md).
+The configuration arguments disabled for `glrt-` tokens will be `--locked`, `--access-level`,
+`--run-untagged`, `--maximum-timeout`, `--paused`, `--tag-list`, and `--maintenance-note`. This change is a breaking
 change.
 
 ### For a shared runner
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **CI/CD > Runners**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **CI/CD > Runners**.
 1. Select **Register an instance runner**.
 1. Copy the registration token.
 
 ### For a group runner
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **CI/CD > Runners**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Build > Runners**.
 1. Copy the registration token.
 
 ### For a project runner
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand the **Runners** section.
 1. Copy the registration token.
diff --git a/doc/ci/runners/runners_scope.md b/doc/ci/runners/runners_scope.md
index 43204b463b3..e7b764025c9 100644
--- a/doc/ci/runners/runners_scope.md
+++ b/doc/ci/runners/runners_scope.md
@@ -29,12 +29,12 @@ If you are using a self-managed instance of GitLab:
   and selecting **Show runner installation instructions**.
   These instructions are also available [in the documentation](https://docs.gitlab.com/runner/install/index.html).
 - The administrator can also configure a maximum number of shared runner
-  [CI/CD minutes for each group](../pipelines/cicd_minutes.md#set-the-quota-of-cicd-minutes-for-a-specific-namespace).
+  [units of compute for each group](../pipelines/cicd_minutes.md#set-the-compute-quota-for-a-specific-namespace).
 
 If you are using GitLab.com:
 
 - You can select from a list of [shared runners that GitLab maintains](index.md).
-- The shared runners consume the [CI/CD minutes](../pipelines/cicd_minutes.md)
+- The shared runners consume the [units of compute](../pipelines/cicd_minutes.md)
   included with your account.
 
 ### Enable shared runners for a project
@@ -51,8 +51,8 @@ For existing projects, an administrator must
 
 To enable shared runners for a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 1. Turn on the **Enable shared runners for this project** toggle.
 
@@ -60,8 +60,8 @@ To enable shared runners for a project:
 
 To enable shared runners for a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 1. Turn on the **Enable shared runners for this group** toggle.
 
@@ -73,8 +73,8 @@ or group.
 
 To disable shared runners for a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 1. In the **Shared runners** area, turn off the **Enable shared runners for this project** toggle.
 
@@ -87,15 +87,15 @@ Shared runners are automatically disabled for a project:
 
 To disable shared runners for a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 1. Turn off the **Enable shared runners for this group** toggle.
 1. Optional. To allow shared runners to be enabled for individual projects or subgroups,
    select **Allow projects and subgroups to override the group setting**.
 
 NOTE:
-If you re-enable the shared runners for a group after you disable them, a user with the 
+If you re-enable the shared runners for a group after you disable them, a user with the
 Owner or Maintainer role must manually change this setting for each project subgroup or project.
 
 ### How shared runners pick jobs
@@ -153,8 +153,8 @@ You must have the Owner role for the group.
 To create a group runner:
 
 1. [Install GitLab Runner](https://docs.gitlab.com/runner/install/).
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **CI/CD > Runners**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Build > Runners**.
 1. In the upper-right corner, select **Register a group runner**.
 1. Select **Show runner installation and registration instructions**.
    These instructions include the token, URL, and a command to register a runner.
@@ -170,8 +170,8 @@ You can view and manage all runners for a group, its subgroups, and projects.
 You can do this for your self-managed GitLab instance or for GitLab.com.
 You must have the Owner role for the group.
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **CI/CD > Runners**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Build > Runners**.
 
 From this page, you can edit, pause, and remove runners from the group, its subgroups, and projects.
 
@@ -187,8 +187,8 @@ Prerequisites:
 
 To delete multiple runners in a single action in the group list:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **CI/CD > Runners**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Build > Runners**.
 1. To delete multiple runners, you can either:
    - Select the checkbox next to the runner.
    - Select the checkbox at the top of the runner list to select all runners in the list.
@@ -207,8 +207,8 @@ By default, only those that are inherited are shown.
 To show all runners available in the instance, including shared runners and
 those in other groups:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **CI/CD > Runners**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Build > Runners**.
 1. Above the list, turn off the **Show only inherited** toggle.
 
 ### Pause or remove a group runner
@@ -216,8 +216,8 @@ those in other groups:
 You can pause or remove a group runner for your self-managed GitLab instance or for GitLab.com.
 You must have the Owner role for the group.
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **CI/CD > Runners**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Build > Runners**.
 1. Select **Pause** or **Remove runner**.
    - If you pause a group runner that is used by multiple projects, the runner pauses for all projects.
    - From the group view, you cannot remove a runner that is assigned to more than one project.
@@ -252,8 +252,9 @@ Prerequisite:
 To create a project runner:
 
 1. [Install GitLab Runner](https://docs.gitlab.com/runner/install/).
-1. On the top bar, select **Main menu > Projects** and find the project where you want to use the runner.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to
+   find the project where you want to use the runner.
+1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 1. In the **Project runners** section, note the URL and token.
 1. [Register the runner](https://docs.gitlab.com/runner/register/).
@@ -273,8 +274,9 @@ You must have at least the Maintainer role for:
 
 To enable a project runner for a project:
 
-1. On the top bar, select **Main menu > Projects** and find the project where you want to enable the runner.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to
+   find the project where you want to enable the runner.
+1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 1. In the **Project runners** area, by the runner you want, select **Enable for this project**.
 
@@ -292,8 +294,9 @@ but can also be changed later.
 
 To lock or unlock a project runner:
 
-1. On the top bar, select **Main menu > Projects** and find the project where you want to enable the runner.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to
+   find the project where you want to enable the runner.
+1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 1. Find the project runner you want to lock or unlock. Make sure it's enabled. You cannot lock shared or group runners.
 1. Select **Edit** (**{pencil}**).
diff --git a/doc/ci/runners/saas/gpu_saas_runner.md b/doc/ci/runners/saas/gpu_saas_runner.md
new file mode 100644
index 00000000000..7b83f6593a0
--- /dev/null
+++ b/doc/ci/runners/saas/gpu_saas_runner.md
@@ -0,0 +1,46 @@
+---
+stage: Verify
+group: Runner
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# GPU-enabled SaaS runners **(PREMIUM SAAS)**
+
+GitLab provides GPU-enabled SaaS runners to accelerate heavy compute workloads for ModelOps
+or HPC such as the training or deployment of Large Language Models (LLMs) as part of ModelOps workloads.
+
+GitLab provides GPU-enabled runners only on Linux. For more information about how these runners work, see [SaaS runners on Linux](../saas/linux_saas_runner.md)
+
+## Machine types available for GPU-enabled runners
+
+The following machine types are available for GPU-enabled runners on Linux x86-64.
+
+| Runner Tag                             | vCPUs | Memory | Storage | GPU                                |
+|----------------------------------------|-------|--------|---------|------------------------------------|
+| `saas-linux-medium-amd64-gpu-standard` | 4     | 16 GB  | 50 GB   | 1 Nvidia Tesla T4 GPU (or similar) |
+
+## Container images with GPU drivers
+
+As with GitLab SaaS runners on Linux, your job runs in an isolated virtual machine (VM)
+with a bring-your-own-image policy. GitLab mounts the GPU from the host VM into
+your isolated environment. To use the GPU, you must use a Docker image with the
+GPU driver installed. For Nvidia GPUs, you can use their [CUDA Toolkit](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda).
+
+## Example `.gitlab-ci.yml` file
+
+In the following example of the `.gitlab-ci.yml` file, the Nvidia CUDA base Ubuntu image is used.
+In the `script:` section, you install Python.
+
+```yaml
+gpu-job:
+  stage: build
+  tags:
+    - saas-linux-medium-amd64-gpu-standard
+  image: nvcr.io/nvidia/cuda:12.1.1-base-ubuntu22.04
+  script:
+    - apt-get update
+    - apt-get install -y python3.10
+    - python3.10 --version
+```
+
+If you don't want to install larger libraries such as Tensorflow or XGBoost each time you run a job, you can create your own image with all the required components pre-installed.
diff --git a/doc/ci/runners/saas/linux_saas_runner.md b/doc/ci/runners/saas/linux_saas_runner.md
index 3a45e056643..d95fc701056 100644
--- a/doc/ci/runners/saas/linux_saas_runner.md
+++ b/doc/ci/runners/saas/linux_saas_runner.md
@@ -4,252 +4,93 @@ group: Runner
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# SaaS runners on Linux
+# SaaS runners on Linux **(FREE SAAS)**
 
 When you run jobs on SaaS runners on Linux, the runners are on auto-scaled ephemeral virtual machine (VM) instances.
-Each VM uses the Google Container-Optimized OS (COS) and the latest version of Docker Engine.
 The default region for the VMs is `us-east1`.
 
-## Machine types available for private projects (x86-64)
+Each VM uses the Google Container-Optimized OS (COS) and the latest version of Docker Engine running the `docker+machine`
+[executor](https://docs.gitlab.com/runner/executors/#docker-machine-executor).
 
-For the SaaS runners on Linux, GitLab offers a range of machine types for use in private projects.
-For Free, Premium, and Ultimate plan customers, jobs on these instances consume the CI/CD minutes allocated to your namespace.
+## Machine types available for Linux (x86-64)
 
-|                   | Small                     | Medium                    | Large                    |
-|-------------------|---------------------------|---------------------------|--------------------------|
-| Specs             | 1 vCPU, 3.75 GB RAM        | 2 vCPUs, 8 GB RAM          | 4 vCPUs, 16 GB RAM        |
-| GitLab CI/CD tags | `saas-linux-small-amd64` | `saas-linux-medium-amd64` | `saas-linux-large-amd64` |
-| Subscription      | Free, Premium, Ultimate   | Free, Premium, Ultimate   | Premium, Ultimate        |
+For the SaaS runners on Linux, GitLab offers a range of machine types for use.
+For Free, Premium, and Ultimate plan customers, jobs on these instances consume the compute quota allocated to your namespace.
 
-The `small` machine type is the default. Your job runs on this machine type if you don't specify
-a [tags:](../../yaml/index.md#tags) keyword in your `.gitlab-ci.yml` file.
+| Runner Tag                                    | vCPUs | Memory | Storage |
+|-----------------------------------------------|-------|--------|---------|
+| `saas-linux-small-amd64`                      | 2     | 8 GB   | 25 GB   |
+| `saas-linux-medium-amd64` **(PREMIUM SAAS)**  | 4     | 16 GB  | 50 GB   |
+| `saas-linux-large-amd64`  **(PREMIUM SAAS)**  | 8     | 32 GB  | 100 GB  |
 
-CI/CD jobs that run on `medium` and `large` machine types consumes CI minutes at a different rate than CI/CD jobs on the `small` machine type.
+The `small` machine type is set as default. If no [tag](../../yaml/index.md#tags) keyword in your `.gitlab-ci.yml` file is specified,
+the jobs will run on this default runner.
 
-Refer to the CI/CD minutes [cost factor](../../../ci/pipelines/cicd_minutes.md#cost-factor) for the cost factor applied to the machine type based on size.
+All SaaS runners on Linux currently run on
+[`n2d-standard`](https://cloud.google.com/compute/docs/general-purpose-machines#n2d_machines) gerneral-purpose compute from GCP.
+The machine type and underlying processor type can change. Jobs optimized for a specific processor design could behave inconsistently.
 
-## GPU-enabled SaaS runners on Linux **(PREMIUM SAAS)**
+## Container images
 
-We offer GPU-enabled SaaS runners for heavy compute including ModelOps or HPC workloads. Available to Premium and Ultimate plan customers, jobs on these instances consume the CI/CD minutes allocated to your namespace.
+As runners on Linux are using the `docker+machine` [executor](https://docs.gitlab.com/runner/executors/#docker-machine-executor),
+you can choose any container image by defining the [`image`](../../../ci/yaml/index.md#image) in your `.gitlab-ci.yml` file.
 
-|                   | Standard                   |
-|-------------------|---------------------------|
-| Specs             | 4 vCPU, 16 GB RAM, 1 Nvidia Tesla T4 GPU (or similar) |
-| GitLab CI/CD tags | `saas-linux-medium-gpu-standard` |
+If no image is set, the default is `ruby:3.1`.
 
-## Example of how to tag a job
+## Docker in Docker support
+
+The runners are configured to run in `privileged` mode to support
+[Docker in Docker](../../../ci/docker/using_docker_build.md#use-docker-in-docker)
+to build Docker images natively or run multiple containers within your isolated job.
+
+## Caching on SaaS runners
+
+The SaaS runners share a [distributed cache](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching)
+stored in a Google Cloud Storage (GCS) bucket. Cache contents not updated in the last 14 days are automatically
+removed, based on the [object lifecycle management policy](https://cloud.google.com/storage/docs/lifecycle).
+The maximum size of an uploaded cache artifact can be 5 GB after the cache becomes a compressed archive.
+
+For more information about how caching works, see [Caching in GitLab CI/CD](../../caching/index.md).
+
+## Example `.gitlab-ci.yml` file
 
 To use a machine type other than `small`, add a `tags:` keyword to your job.
 For example:
 
 ```yaml
-stages:
-  - Prebuild
-  - Build
-  - Unit Test
-
-job_001:
- stage: Prebuild
+job_small:
  script:
-  - echo "this job runs on the default (small) instance"
+  - echo "this job runs on the default (small) Linux instance"
 
-job_002:
- tags: [ saas-linux-medium-amd64 ]
- stage: Build
+job_medium:
+ tags:
+  - saas-linux-medium-amd64
  script:
-  - echo "this job runs on the medium instance"
-
+  - echo "this job runs on the medium Linux instance"
 
-job_003:
- tags: [ saas-linux-large-amd64 ]
- stage: Unit Test
+job_large:
+ tags:
+  - saas-linux-large-amd64
  script:
-  - echo "this job runs on the large instance"
-
+  - echo "this job runs on the large Linux instance"
 ```
 
-## SaaS runners for GitLab projects
-
-The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for
-GitLab projects and related community forks. These runners are backed by a Google Compute
-`n1-standard-2` machine type and do not run untagged jobs. Unlike the machine types used
-for private projects, each virtual machine is re-used up to 40 times.
+## SaaS runners for GitLab community contributions
 
-## SaaS runners on Linux settings
+If you want to [contribute to GitLab](https://about.gitlab.com/community/contribute/), jobs will be picked up by the
+`gitlab-shared-runners-manager-X.gitlab.com` fleet of runners, dedicated for GitLab projects and related community forks.
 
-Below are the settings for SaaS runners on Linux.
+These runners are backed by the same machine type as our `small` runners.
+Unlike the normal SaaS runners on Linux, each virtual machine is re-used up to 40 times.
 
-| Setting                                                                 | GitLab.com       | Default |
-|-------------------------------------------------------------------------|------------------|---------|
-| Executor                                                                | `docker+machine` | -       |
-| Default Docker image                                                    | `ruby:3.1`       | -       |
-| `privileged` (run [Docker in Docker](https://hub.docker.com/_/docker/)) | `true`           | `false` |
+As we want to encourage people to contribute, these runners are free of charge.
 
-- **Cache**: These runners share a
-  [distributed cache](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching)
-  that's stored in a Google Cloud Storage (GCS) bucket. Cache contents not updated in
-  the last 14 days are automatically removed, based on the
-  [object lifecycle management policy](https://cloud.google.com/storage/docs/lifecycle).
+<!--- start_remove The following content will be removed on remove_date: '2023-08-22' -->
 
-- **Timeout settings**: Jobs handled by the SaaS Runners on Linux
-  **time out after 3 hours**, regardless of the timeout configured in a
-  project. For details, see issues [#4010](https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/4010)
-  and [#4070](https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/4070).
+## Pre-clone script (removed)
 
-NOTE:
-SaaS runner instances are provisioned with a 25 GB storage volume. The underlying disk space of the storage volume
-is shared by the operating system, the Docker image, and a copy of your cloned repository.
-This means that the available free disk space that your jobs can use is **less than 25 GB**.
-
-## Pre-clone script (deprecated)
-
-WARNING:
 This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/391896) in GitLab 15.9
-and is planned for removal in 16.0. Use [`pre_get_sources_script`](../../../ci/yaml/index.md#hookspre_get_sources_script) instead. This change is a breaking change.
-With SaaS runners on Linux, you can run commands in a CI/CD
-job before the runner attempts to run `git init` and `git fetch` to
-download a GitLab repository. The
-[`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
-can be used for:
-
-- Seeding the build directory with repository data
-- Sending a request to a server
-- Downloading assets from a CDN
-- Any other commands that must run before the `git init`
-
-To use this feature, define a [CI/CD variable](../../../ci/variables/index.md) called
-`CI_PRE_CLONE_SCRIPT` that contains a bash script.
-
-NOTE:
-The `CI_PRE_CLONE_SCRIPT` variable does not work on GitLab SaaS Windows or macOS runners.
-
-### Pre-clone script example
-
-This example was used in the `gitlab-org/gitlab` project until November 2021.
-The project no longer uses this optimization because the
-[pack-objects cache](../../../administration/gitaly/configure_gitaly.md#pack-objects-cache)
-lets Gitaly serve the full CI/CD fetch traffic. See [Git fetch caching](../../../development/pipelines/performance.md#git-fetch-caching).
-
-The `CI_PRE_CLONE_SCRIPT` was defined as a project CI/CD variable:
-
-```shell
-(
-  echo "Downloading archived master..."
-  wget -O /tmp/gitlab.tar.gz https://storage.googleapis.com/gitlab-ci-git-repo-cache/project-278964/gitlab-master-shallow.tar.gz
-
-  if [ ! -f /tmp/gitlab.tar.gz ]; then
-      echo "Repository cache not available, cloning a new directory..."
-      exit
-  fi
-
-  rm -rf $CI_PROJECT_DIR
-  echo "Extracting tarball into $CI_PROJECT_DIR..."
-  mkdir -p $CI_PROJECT_DIR
-  cd $CI_PROJECT_DIR
-  tar xzf /tmp/gitlab.tar.gz
-  rm -f /tmp/gitlab.tar.gz
-  chmod a+w $CI_PROJECT_DIR
-)
-```
-
-The first step of the script downloads `gitlab-master.tar.gz` from Google Cloud Storage.
-There was a [GitLab CI/CD job named `cache-repo`](https://gitlab.com/gitlab-org/gitlab/-/blob/5fb40526c8c8aaafc5f92eab36d5bbddaca3893d/.gitlab/ci/cache-repo.gitlab-ci.yml)
-that was responsible for keeping that archive up-to-date. Every two hours on a scheduled pipeline,
-it did the following:
-
-1. Create a fresh clone of the `gitlab-org/gitlab` repository on GitLab.com.
-1. Save the data as a `.tar.gz`.
-1. Upload it into the Google Cloud Storage bucket.
+and [removed](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29405) in 16.0.
+Use [`pre_get_sources_script`](../../../ci/yaml/index.md#hookspre_get_sources_script) instead.
 
-When a job ran with this configuration, the output looked similar to:
-
-```shell
-$ eval "$CI_PRE_CLONE_SCRIPT"
-Downloading archived master...
-Extracting tarball into /builds/gitlab-org/gitlab...
-Fetching changes...
-Reinitialized existing Git repository in /builds/gitlab-org/gitlab/.git/
-```
-
-The `Reinitialized existing Git repository` message shows that
-the pre-clone step worked. The runner runs `git init`, which
-overwrites the Git configuration with the appropriate settings to fetch
-from the GitLab repository.
-
-`CI_REPO_CACHE_CREDENTIALS` must contain the Google Cloud service account
-JSON for uploading to the `gitlab-ci-git-repo-cache` bucket.
-
-This bucket should be located in the same continent as the
-runner, or [you can incur network egress charges](https://cloud.google.com/storage/pricing).
-
-## `config.toml`
-
-The full contents of our `config.toml` are:
-
-NOTE:
-Settings that are not public are shown as `X`.
-
-**Google Cloud Platform**
-
-```toml
-concurrent = X
-check_interval = 1
-metrics_server = "X"
-sentry_dsn = "X"
-
-[[runners]]
-  name = "docker-auto-scale"
-  request_concurrency = X
-  url = "https://gitlab.com/"
-  token = "SHARED_RUNNER_TOKEN"
-  pre_clone_script = "eval \"$CI_PRE_CLONE_SCRIPT\""
-  executor = "docker+machine"
-  environment = [
-    "DOCKER_DRIVER=overlay2",
-    "DOCKER_TLS_CERTDIR="
-  ]
-  limit = X
-  [runners.docker]
-    image = "ruby:3.1"
-    privileged = true
-    volumes = [
-      "/certs/client",
-      "/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro" # Make kaniko builds work on GCP.
-    ]
-  [runners.machine]
-    IdleCount = 50
-    IdleTime = 3600
-    MaxBuilds = 1 # For security reasons we delete the VM after job has finished so it's not reused.
-    MachineName = "srm-%s"
-    MachineDriver = "google"
-    MachineOptions = [
-      "google-project=PROJECT",
-      "google-disk-size=25",
-      "google-machine-type=n1-standard-1",
-      "google-username=core",
-      "google-tags=gitlab-com,srm",
-      "google-use-internal-ip",
-      "google-zone=us-east1-d",
-      "engine-opt=mtu=1460", # Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
-      "google-machine-image=PROJECT/global/images/IMAGE",
-      "engine-opt=ipv6", # This will create IPv6 interfaces in the containers.
-      "engine-opt=fixed-cidr-v6=fc00::/7",
-      "google-operation-backoff-initial-interval=2" # Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
-    ]
-    [[runners.machine.autoscaling]]
-      Periods = ["* * * * * sat,sun *"]
-      Timezone = "UTC"
-      IdleCount = 70
-      IdleTime = 3600
-    [[runners.machine.autoscaling]]
-      Periods = ["* 30-59 3 * * * *", "* 0-30 4 * * * *"]
-      Timezone = "UTC"
-      IdleCount = 700
-      IdleTime = 3600
-  [runners.cache]
-    Type = "gcs"
-    Shared = true
-    [runners.cache.gcs]
-      CredentialsFile = "/path/to/file"
-      BucketName = "bucket-name"
-```
+<!--- end_remove -->
diff --git a/doc/ci/runners/saas/macos/codesigning.md b/doc/ci/runners/saas/macos/codesigning.md
index 809b8faf9df..7e70e984c7c 100644
--- a/doc/ci/runners/saas/macos/codesigning.md
+++ b/doc/ci/runners/saas/macos/codesigning.md
@@ -1,28 +1,11 @@
 ---
-stage: Verify
-group: Runner
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../macos_saas_runner.md'
+remove_date: '2023-09-05'
 ---
 
-# Code signing for SaaS runners on macOS
+This document was moved to [another location](../macos_saas_runner.md).
 
-Before you can integrate GitLab with Apple services, install to a device, or deploy to the Apple App Store, you must [code sign](https://developer.apple.com/support/code-signing/) your application.
-
-## Code signing iOS Projects with fastlane
-
-When you use SaaS runners on macOS, each job runs on a VM. Included in each VM is [fastlane](https://fastlane.tools/),
-an open-source solution aimed at simplifying mobile app deployment.
-
-For information about how to set up code signing for your application, see the instructions in the [Mobile DevOps documentation](../../../../ci/mobile_devops.md#code-sign-ios-projects-with-fastlane).
-
-These instructions provide the minimal setup to use fastlane to code sign your application. For more information about using fastlane to handle code signing, see the following resources:
-
-- [fastlane getting started guide](https://docs.fastlane.tools/)
-- [Best practices for integrating with GitLab CI](https://docs.fastlane.tools/best-practices/continuous-integration/gitlab/)
-- [fastlane code signing getting started guide](https://docs.fastlane.tools/codesigning/getting-started/)
-
-## Related topics
-
-- [Apple Developer Support - Code Signing](https://developer.apple.com/support/code-signing/)
-- [Code Signing Best Practice Guide](https://codesigning.guide/)
-- [fastlane authentication with Apple Services guide](https://docs.fastlane.tools/getting-started/ios/authentication/)
+<!-- This redirect file can be deleted after <2023-09-05>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
\ No newline at end of file
diff --git a/doc/ci/runners/saas/macos/environment.md b/doc/ci/runners/saas/macos/environment.md
index 7aa0f33fc59..7e70e984c7c 100644
--- a/doc/ci/runners/saas/macos/environment.md
+++ b/doc/ci/runners/saas/macos/environment.md
@@ -1,62 +1,11 @@
 ---
-stage: Verify
-group: Runner
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../macos_saas_runner.md'
+remove_date: '2023-09-05'
 ---
 
-# VM instances and images for SaaS runners on macOS **(PREMIUM SAAS)**
+This document was moved to [another location](../macos_saas_runner.md).
 
-When you use SaaS runners on macOS:
-
-- Each of your jobs runs in a newly provisioned VM, which is dedicated to the specific job.
-- The VM is active only for the duration of the job and immediately deleted. This means that any changes that your job makes to the virtual machine will not be available to a subsequent job.
-- The virtual machine where your job runs has `sudo` access with no password.
-
-NOTE:
-Each time you run a job that requires tooling or dependencies not available in the base image, those items must be added to the newly provisioned build VM. That process will likely increase the total job duration.
-
-## VM types
-
-GitLab SaaS provides macOS build machines on Apple servers with Intel x86-64 processors.
-The expectation is that virtual machines running on the Apple M1 chip will be available in the second half of 2022.
-
-At this time there is only one available machine type offered, `shared-macos-amd64`.
-
-| Instance type | vCPUS | Memory (GB) |
-| --------- | --- | ------- |
-|  `shared-macos-amd64` | 4 | 10 |
-
-## VM images
-
-### Image update policy
-
-GitLab expects to release new images based on this cadence:
-
-macOS updates:
-
-- **For new OS versions:** When Apple releases a new macOS version to developers (like macOS `12`), GitLab will plan to release an image based on the OS within the next 30 business days. The image is considered `beta` and the contents of the image (including tool versions) are subject to change until the first patch release (`12.1`). The long-term name will not include `beta` (for example, `macos-12-xcode-13`), so customers are moved automatically out of beta over time. GitLab will try to minimize breaking changes between the first two minor versions but makes no guarantees. Tooling often gets critical bug fixes after the first public release of an OS version.
-
-- **After the first patch release (`12.1`):**
-  - The image moves to `maintenance` mode. The tools GitLab builds into the image with Homebrew and asdf are frozen. GitLab continues making Xcode updates, security updates, and any non-breaking changes deemed necessary.
-  - The image for the previous OS version (`11`) moves to `frozen` mode. GitLab then does only unavoidable changes: security updates, runner version upgrades, and setting the production password.
-
-Both macOS and Xcode follow a yearly release cadence. As time goes on, GitLab increments their versions synchronously (meaning we build macOS 11 with Xcode 12, macOS 12 with Xcode 13, and so on).
-
-### Available images
-
-You can execute your build on one of the following images.
-You specify this image in your `.gitlab-ci.yml` file.
-
-Each image is running a specific version of macOS and Xcode.
-
-| VM image                  | Status | Included software  |
-|---------------------------|--------|--------------------|
-| `macos-10.13-xcode-7`       | `frozen` | <https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/macstadium/orka/-/blob/main/toolchain/high-sierra.yml>  |
-| `macos-10.13-xcode-8`       | `frozen` | <https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/macstadium/orka/-/blob/main/toolchain/high-sierra.yml>  |
-| `macos-10.13-xcode-9`       | `frozen` | <https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/macstadium/orka/-/blob/main/toolchain/high-sierra.yml>  |
-| `macos-10.14-xcode-10`      | `frozen` | <https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/macstadium/orka/-/blob/main/toolchain/mojave.yml>       |
-| `macos-10.15-xcode-11`      | `frozen` | <https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/macstadium/orka/-/blob/main/toolchain/catalina.yml>     |
-| `macos-11-xcode-12`         | `frozen` | <https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/macstadium/orka/-/blob/main/toolchain/big-sur.yml>      |
-| `macos-12-xcode-13`         | `maintenance` | <https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/macstadium/orka/-/blob/main/toolchain/monterey.yml> |
-| `macos-12-xcode-14`         | `maintenance` | <https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/macstadium/orka/-/blob/main/toolchain/monterey.yml> |
-| (none, awaiting macOS 13)        | `beta` |       |
+<!-- This redirect file can be deleted after <2023-09-05>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
\ No newline at end of file
diff --git a/doc/ci/runners/saas/macos_saas_runner.md b/doc/ci/runners/saas/macos_saas_runner.md
index 20be2f2a147..836a14d7521 100644
--- a/doc/ci/runners/saas/macos_saas_runner.md
+++ b/doc/ci/runners/saas/macos_saas_runner.md
@@ -6,57 +6,72 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # SaaS runners on macOS (Beta) **(PREMIUM SAAS)**
 
-SaaS runners on macOS are in [Beta](../../../policy/alpha-beta-support.md#beta) for approved open source programs and customers in Premium and Ultimate plans.
+SaaS runners on macOS are in [Beta](../../../policy/experiment-beta-support.md#beta) for open source programs and customers in Premium and Ultimate plans.
 
 SaaS runners on macOS provide an on-demand macOS build environment integrated with
 GitLab SaaS [CI/CD](../../../ci/index.md).
-Use these runners to build, test, and deploy apps for the Apple ecosystem (macOS, iOS, tvOS). You can take advantage
+Use these runners to build, test, and deploy apps for the Apple ecosystem (macOS, iOS, watchOS, tvOS). You can take advantage
 of all the capabilities of the GitLab single DevOps platform and not have to manage or operate a
-build environment.
+build environment. Our [Mobile DevOps solution](../../../ci/mobile_devops.md#ios-build-environments) provides features, documentation, and guidance on building and deploying mobile applications for iOS.
 
-Jobs handled by macOS shared runners on GitLab.com **time out after 3 hours**, regardless of the timeout configured in a project.
+We want to keep iterating to get SaaS runners on macOS
+[generally available](../../../policy/experiment-beta-support.md#generally-available-ga).
+You can follow our work towards this goal in the
+[related epic](https://gitlab.com/groups/gitlab-org/-/epics/8267).
 
-## Access request process
+## Machine types available for macOS
 
-While in beta, to run CI jobs on the macOS runners, you must specify the GitLab SaaS customer personal or group [namespaces](../../../user/namespace/index.md) in the macOS `allow-list`. These are the namespaces that use the macOS runners.
+GitLab SaaS provides macOS build machines on Apple silicon (M1) chips.
+Intel x86-64 runners were deprecated in favor of Apple silicon. To build for an x86-64 target, use Rosetta 2 to emulate an Intel x86-64 build environment.
 
-When you specify a personal or group namespace, the top level group is not added unless you specify it.
+| Runner Tag             | vCPUS | Memory | Storage |
+| ---------------------- | ----- | ------ | ------- |
+| `saas-macos-medium-m1` | 4     | 8 GB   | 25 GB   |
 
-After you add your namespace, you can use the macOS runners for any projects under the namespace you included.
+## Supported macOS images
 
-To request access, open an [access request](https://gitlab.com/gitlab-com/runner-saas-macos-limited-availability/-/issues/new).
-The expected turnaround for activation is two business days.
+In comparison to our SaaS runners on Linux, where you can run any Docker image,
+GitLab SaaS provides a set of VM images for macOS.
 
-## Quickstart
+You can execute your build in one of the following images, which you specify
+in your `.gitlab-ci.yml` file.
 
-To start using SaaS runners on macOS, you must be an active GitLab SaaS Premium or Ultimate customer. Participants in the GitLab Open Source program are also eligible to use the service.
+Each image runs a specific version of macOS and Xcode.
 
-### Configuring your pipeline
+| VM image                  | Status        |
+|---------------------------|---------------|
+| `macos-12-xcode-13`       | `maintenance` |
+| `macos-12-xcode-14`       | `maintenance` |
+| (none, awaiting macOS 13) | `beta`        |
 
-To start using the SaaS runners on macOS to run your CI jobs, you must configure your `.gitlab-ci.yml` file:
+NOTE:
+Each time you run a job that requires tooling or dependencies not available in the base image, those items must be added to the newly provisioned build VM increasing the total job duration.
+
+## Image update policy
+
+GitLab expects to release new images based on this cadence:
+
+macOS updates:
+
+- **For new OS versions:** When Apple releases a new macOS version to developers (like macOS `12`), GitLab will plan to release an image based on the OS within the next 30 business days. The image is considered `beta` and the contents of the image (including tool versions) are subject to change until the first patch release (`12.1`). The long-term name will not include `beta` (for example, `macos-12-xcode-13`), so customers are moved automatically out of beta over time. GitLab will try to minimize breaking changes between the first two minor versions but makes no guarantees. Tooling often gets critical bug fixes after the first public release of an OS version.
 
-1. Add a `.gitlab-ci.yml` file to your project repository.
-1. Specify the [image](macos/environment.md#vm-images) you want to use.
-1. Commit a change to your repository.
+- **After the first patch release (`12.1`):**
+  - The image moves to `maintenance` mode. The tools GitLab builds into the image with Homebrew and asdf are frozen. GitLab continues making Xcode updates, security updates, and any non-breaking changes deemed necessary.
+  - The image for the previous OS version (`11`) moves to `frozen` mode. GitLab then does only unavoidable changes: security updates, runner version upgrades, and setting the production password.
 
-The runners automatically run your build.
+Both macOS and Xcode follow a yearly release cadence. As time goes on, GitLab increments their versions synchronously (meaning we build macOS 11 with Xcode 12, macOS 12 with Xcode 13, and so on).
 
-### Example `.gitlab-ci.yml` file
+## Example `.gitlab-ci.yml` file
 
 The following sample `.gitlab-ci.yml` file shows how to start using the SaaS runners on macOS:
 
 ```yaml
 .macos_saas_runners:
   tags:
-    - shared-macos-amd64
-  image: macos-11-xcode-12
-
-stages:
-  - build
-  - test
-
-before_script:
-  - echo "started by ${GITLAB_USER_NAME}"
+    - saas-macos-medium-m1
+  image: macos-12-xcode-14
+  before_script:
+    - echo "started by ${GITLAB_USER_NAME}"
 
 build:
   extends:
@@ -74,14 +89,39 @@ test:
 ```
 
 NOTE:
-You can specify a different Xcode image to run a job. To do so, replace the value for the `image` keyword with the value of the [virtual machine image name](macos/environment.md#vm-images) from the list of available images.
+You can specify a different Xcode image to run a job. To do so, replace the value for the `image` keyword with the value of the [virtual machine image name](#supported-macos-images) from the list of available images. The default value is our latest image.
+
+## Code signing iOS Projects with fastlane
+
+Before you can integrate GitLab with Apple services, install to a device, or deploy to the Apple App Store, you must [code sign](https://developer.apple.com/support/code-signing/) your application.
 
-## SaaS runners on macOS service level objective
+Included in each runner on macOS VM image is [fastlane](https://fastlane.tools/),
+an open-source solution aimed at simplifying mobile app deployment.
 
-In SaaS runners on macOS, the objective is to make 90% of CI jobs start executing in 120 seconds or less. The error rate should be less than 0.5%.
+For information about how to set up code signing for your application, see the instructions in the [Mobile DevOps documentation](../../../ci/mobile_devops.md#code-sign-ios-projects-with-fastlane).
+
+Related topics:
+
+- [Apple Developer Support - Code Signing](https://developer.apple.com/support/code-signing/)
+- [Code Signing Best Practice Guide](https://codesigning.guide/)
+- [fastlane authentication with Apple Services guide](https://docs.fastlane.tools/getting-started/ios/authentication/)
 
 ## Known Limitations and Usage Constraints
 
 - If the VM image does not include the specific software version you need for your job, then the job execution time will increase as the required software needs to be fetched and installed.
 - At this time, it is not possible to bring your own OS image.
 - The keychain for user `gitlab` is not publicly available. You must create a keychain instead.
+
+## Optimizing Homebrew
+
+By default, Homebrew checks for updates at the start of any operation. Homebrew has a
+release cycle that may be more frequent than the GitLab MacOS image release cycle. This
+difference in release cycles may cause steps that call `brew` to take extra time to complete
+while Homebrew makes updates.
+
+To reduce build time due to unintended Homebrew updates, set the `HOMEBREW_NO_AUTO_UPDATE` variable in  `.gitlab-ci.yml` :
+
+```yaml
+variables:
+  HOMEBREW_NO_AUTO_UPDATE: 1
+```
diff --git a/doc/ci/runners/saas/windows_saas_runner.md b/doc/ci/runners/saas/windows_saas_runner.md
index 6e4ffc036b0..fa981bddff3 100644
--- a/doc/ci/runners/saas/windows_saas_runner.md
+++ b/doc/ci/runners/saas/windows_saas_runner.md
@@ -6,88 +6,47 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # SaaS runners on Windows (Beta) **(FREE SAAS)**
 
-SaaS runners on Windows are in [Beta](../../../policy/alpha-beta-support.md#beta)
-and shouldn't be used for production workloads.
-
-During this beta period, the [shared runner quota for CI/CD minutes](../../pipelines/cicd_minutes.md)
-applies for groups and projects in the same manner as Linux runners. This may
-change when the beta period ends, as discussed in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).
-
-Windows runners on GitLab.com autoscale by launching virtual machines on
+SaaS runner on Windows autoscale by launching virtual machines on
 the Google Cloud Platform. This solution uses an
 [autoscaling driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/blob/main/docs/README.md)
 developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
-Windows runners execute your CI/CD jobs on `n1-standard-2` instances with
-2 vCPUs and 7.5 GB RAM. You can find a full list of available Windows packages in
-the [package documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/main/cookbooks/preinstalled-software/README.md).
+
+These SaaS runners are in [Beta](../../../policy/experiment-beta-support.md#beta)
+and aren't recomended for production workloads.
 
 We want to keep iterating to get Windows runners in a stable state and
-[generally available](../../../policy/alpha-beta-support.md#generally-available-ga).
+[generally available](../../../policy/experiment-beta-support.md#generally-available-ga).
 You can follow our work towards this goal in the
 [related epic](https://gitlab.com/groups/gitlab-org/-/epics/2162).
 
-## Configuration
+## Machine types available for Windows
+
+| Runner Tag             | vCPUs | Memory | Storage |
+| ---------------------- | ----- | ------ | ------- |
+| `shared-windows`       | 2     | 7.5 GB | 75 GB   |
+
+## Supported Windows versions
+
+The Windows runner virtual machine instances do not use the GitLab Docker executor. This means that you can't specify
+[`image`](../../../ci/yaml/index.md#image) or [`services`](../../../ci/yaml/index.md#services) in your pipeline configuration.
+Instead you have to select the [`tags`](../../../ci/yaml/index.md#tags) for the desired Windows version.
 
-The full contents of our `config.toml` are:
+You can execute your job in one of the following Windows versions:
+
+| Version tag    | Status        |
+|----------------|---------------|
+| `windows-1809` | `maintenance` |
+
+You can find a full list of available pre-installed software in
+the [pre-installed software documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/main/cookbooks/preinstalled-software/README.md).
 
 NOTE:
-Settings that aren't public are shown as `X`.
-
-```toml
-concurrent = X
-check_interval = 3
-
-[[runners]]
-  name = "windows-runner"
-  url = "https://gitlab.com/"
-  token = "TOKEN"
-  executor = "custom"
-  builds_dir = "C:\\GitLab-Runner\\builds"
-  cache_dir = "C:\\GitLab-Runner\\cache"
-  shell  = "powershell"
-  [runners.custom]
-    config_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    config_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "config"]
-    prepare_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    prepare_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "prepare"]
-    run_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    run_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "run"]
-    cleanup_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    cleanup_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "cleanup"]
-```
+Each time you run a job that requires tooling or dependencies not available in the base image, those components must be installed to the newly provisioned VM increasing the total job duration.
 
-The full contents of our `autoscaler/config.toml` are:
-
-```toml
-Provider = "gcp"
-Executor = "winrm"
-OS = "windows"
-LogLevel = "info"
-LogFormat = "text"
-LogFile = "C:\\GitLab-Runner\\autoscaler\\autoscaler.log"
-VMTag = "windows"
-
-[GCP]
-  ServiceAccountFile = "PATH"
-  Project = "some-project-df9323"
-  Zone = "us-east1-c"
-  MachineType = "n1-standard-2"
-  Image = "IMAGE"
-  DiskSize = 50
-  DiskType = "pd-standard"
-  Subnetwork = "default"
-  Network = "default"
-  Tags = ["TAGS"]
-  Username = "gitlab_runner"
-
-[WinRM]
-  MaximumTimeout = 3600
-  ExecutionMaxRetries = 0
-
-[ProviderCache]
-  Enabled = true
-  Directory = "C:\\GitLab-Runner\\autoscaler\\machines"
-```
+## Supported shell
+
+SaaS runners on Windows have PowerShell configured as the shell.
+The `script` section of your `.gitlab-ci.yml` file therefore requires PowerShell commands.
 
 ## Example `.gitlab-ci.yml` file
 
@@ -97,7 +56,6 @@ Below is a sample `.gitlab-ci.yml` file that shows how to start using the runner
 .shared_windows_runners:
   tags:
     - shared-windows
-    - windows
     - windows-1809
 
 stages:
@@ -126,7 +84,7 @@ test:
 
 ## Limitations and known issues
 
-- All the limitations mentioned in our [Beta definition](../../../policy/alpha-beta-support.md#beta).
+- All the limitations mentioned in our [Beta definition](../../../policy/experiment-beta-support.md#beta).
 - The average provisioning time for a new Windows VM is 5 minutes.
   This means that you may notice slower build start times
   on the Windows runner fleet during the beta. In a future
@@ -136,17 +94,6 @@ test:
   follow along in the [related issue](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/issues/32).
 - The Windows runner fleet may be unavailable occasionally
   for maintenance or updates.
-- The Windows runner virtual machine instances do not use the
-  GitLab Docker executor. This means that you can't specify
-  [`image`](../../../ci/yaml/index.md#image) or [`services`](../../../ci/yaml/index.md#services) in
-  your pipeline configuration.
-- For the beta release, we have included a set of software packages in
-  the base VM image. If your CI job requires additional software that's
-  not included in this list, then you must add installation
-  commands to [`before_script`](../../../ci/yaml/index.md#before_script) or [`script`](../../../ci/yaml/index.md#script) to install the required
-  software. Note that each job runs on a new VM instance, so the
-  installation of additional software packages needs to be repeated for
-  each job in your pipeline.
 - The job may stay in a pending state for longer than the
   Linux runners.
 - There is the possibility that we introduce breaking changes which will
diff --git a/doc/ci/secrets/id_token_authentication.md b/doc/ci/secrets/id_token_authentication.md
index 1ff2a6efbcf..16b94fed4d3 100644
--- a/doc/ci/secrets/id_token_authentication.md
+++ b/doc/ci/secrets/id_token_authentication.md
@@ -60,6 +60,7 @@ The token also includes custom claims provided by GitLab:
 | `user_id`               | Always                       | ID of the user executing the job. |
 | `user_login`            | Always                       | Username of the user executing the job. |
 | `user_email`            | Always                       | Email of the user executing the job. |
+| `user_identities`       | User Preference setting      | List of the user's external identities ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/387537) in GitLab 16.0). |
 | `pipeline_id`           | Always                       | ID of the pipeline. |
 | `pipeline_source`       | Always                       | [Pipeline source](../jobs/job_control.md#common-if-clauses-for-rules). |
 | `job_id`                | Always                       | ID of the job. |
@@ -73,6 +74,7 @@ The token also includes custom claims provided by GitLab:
 | `runner_id`             | Always                       | ID of the runner executing the job. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404722) in GitLab 16.0. |
 | `runner_environment`    | Always                       | The type of runner used by the job. Can be either `gitlab-hosted` or `self-hosted`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404722) in GitLab 16.0. |
 | `sha`                   | Always                       | The commit SHA for the job. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404722) in GitLab 16.0. |
+| `ci_config_ref_uri`     | Always                       | The ref path to the top-level pipeline definition, for example, `gitlab.example.com/my-group/my-project//.gitlab-ci.yml@refs/heads/main`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404722) in GitLab 16.1 behind the `ci_jwt_v2_ref_uri_claim` feature flag. This claim is `null` unless the pipeline definition is located in the same project. |
 
 ```json
 {
@@ -83,6 +85,10 @@ The token also includes custom claims provided by GitLab:
   "user_id": "1",
   "user_login": "sample-user",
   "user_email": "sample-user@example.com",
+  "user_identities": [
+      {"provider": "github", "extern_uid": "2435223452345"},
+      {"provider": "bitbucket", "extern_uid": "john.smith"},
+  ],
   "pipeline_id": "574",
   "pipeline_source": "push",
   "job_id": "302",
@@ -96,6 +102,7 @@ The token also includes custom claims provided by GitLab:
   "runner_id": 1,
   "runner_environment": "self-hosted",
   "sha": "714a629c0b401fdce83e847fc9589983fc6f46bc",
+  "ci_config_ref_uri": "gitlab.example.com/my-group/my-project//.gitlab-ci.yml@refs/heads/main",
   "jti": "235b3a54-b797-45c7-ae9a-f72d7bc6ef5b",
   "iss": "https://gitlab.example.com",
   "iat": 1681395193,
@@ -179,9 +186,40 @@ ID token authentication is now always available, and JSON Web Token access is al
 
 To enable automatic ID token authentication:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Token Access**.
-1. Toggle **Limit JSON Web Token (JWT) access** to enabled.
+1. Turn on the **Limit JSON Web Token (JWT) access** toggle.
 
 <!--- end_remove -->
+
+## Troubleshooting
+
+### `400: missing token` status code
+
+This error indicates that one or more basic components necessary for ID tokens are
+either missing or not configured as expect.
+
+To find the problem, an administrator can look for more details in the instance's
+`exceptions_json.log` for the specific method that failed.
+
+#### `GitLab::Ci::Jwt::NoSigningKeyError`
+
+This error in the `exceptions_json.log` file is likely because the signing key is
+missing from the database and the token could not be generated. To verify this is the issue,
+run the following query on the instance's PostgreSQL terminal:
+
+```sql
+SELECT encrypted_ci_jwt_signing_key FROM application_settings;
+```
+
+If the returned value is empty, use the Rails snippet below to generate a new key
+and replace it internally:
+
+```ruby
+  key = OpenSSL::PKey::RSA.new(2048).to_pem
+
+  ApplicationSetting.find_each do |application_setting|
+    application_setting.update(ci_jwt_signing_key: key)
+  end
+```
diff --git a/doc/ci/secure_files/index.md b/doc/ci/secure_files/index.md
index 41e6fe06f84..b3ccf071996 100644
--- a/doc/ci/secure_files/index.md
+++ b/doc/ci/secure_files/index.md
@@ -29,9 +29,9 @@ tool.
 
 To add a secure file to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
-1. In the **Secure Files** section, select **Expand**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
+1. Expand the **Secure Files** section.
 1. Select **Upload File**.
 1. Find the file to upload, select **Open**, and the file upload begins immediately.
    The file shows up in the list when the upload is complete.
diff --git a/doc/ci/testing/code_coverage.md b/doc/ci/testing/code_coverage.md
index bd1246d2f78..8ffd2cfb727 100644
--- a/doc/ci/testing/code_coverage.md
+++ b/doc/ci/testing/code_coverage.md
@@ -72,8 +72,8 @@ Use this regex for commonly used test tools.
 To see the evolution of your project code coverage over time,
 you can view a graph or download a CSV file with this data.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Analyze > Repository analytics**.
 
 The historic data for each job is listed in the dropdown list above the graph.
 
diff --git a/doc/ci/testing/code_quality.md b/doc/ci/testing/code_quality.md
index 367777960b5..5f6af4cb8a9 100644
--- a/doc/ci/testing/code_quality.md
+++ b/doc/ci/testing/code_quality.md
@@ -227,7 +227,7 @@ Code Quality can be customized by defining available CI/CD variables:
 | CI/CD variable              | Description |
 | --------------------------- | ----------- |
 | `SOURCE_CODE`               | Path to the source code to scan. |
-| `TIMEOUT_SECONDS`           | Custom timeout for the `codeclimate analyze` command. |
+| `TIMEOUT_SECONDS`           | Custom timeout per engine container for the `codeclimate analyze` command, default is 900 seconds (15 minutes). |
 | `CODECLIMATE_DEBUG`         | Set to enable [Code Climate debug mode](https://github.com/codeclimate/codeclimate#environment-variables) |
 | `CODECLIMATE_DEV`           | Set to enable `--dev` mode which lets you run engines not known to the CLI. |
 | `REPORT_STDOUT`             | Set to print the report to `STDOUT` instead of generating the usual report file. |
@@ -492,6 +492,23 @@ Example:
 ]
 ```
 
+## Integrate multiple tools
+
+Code Quality combines the results from all jobs in a pipeline into a single `gl-code-quality-report.json` file. As a result, multiple individual tools can be used in a pipeline, either alongside, or in place of, the supported `Code-Quality.gitlab-ci.yml` template.
+
+Here is an example that returns ESLint output in the necessary format:
+
+```yaml
+eslint:
+  image: node:18-alpine
+  script:
+    - npm ci
+    - npx eslint --format gitlab .
+  artifacts:
+    reports:
+      codequality: gl-code-quality-report.json
+```
+
 ## Using Analysis Plugins
 
 Code Quality functionality can be extended by using Code Climate
@@ -521,6 +538,12 @@ for more details.
 
 ## Troubleshooting
 
+### The code cannot be found and the pipeline runs always with default configuration
+
+You are probably using a private runner with the Docker-in-Docker socket-binding configuration.
+You should configure Code Quality checks to run on your worker as documented in section
+"[Improve Code Quality performance with private runners](#improve-code-quality-performance-with-private-runners)".
+
 ### Changing the default configuration has no effect
 
 A common issue is that the terms `Code Quality` (GitLab specific) and `Code Climate`
@@ -549,12 +572,9 @@ This can be due to multiple reasons:
 
 ### Only a single Code Quality report is displayed, but more are defined
 
-Starting [in GitLab 15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/340525), Code Quality combines the results from all jobs in a pipeline.
-
-In previous versions, GitLab only uses the Code Quality artifact from the latest created job (with the largest job ID).
-If multiple jobs in a pipeline generate a code quality artifact, those of earlier jobs are ignored.
+Code Quality automatically [combines multiple reports](#integrate-multiple-tools).
 
-To avoid confusion, configure only one job to generate a `gl-code-quality-report.json` file.
+In GitLab 15.6 and earlier, Code Quality used only the artifact from the latest created job (with the largest job ID). Code Quality artifacts from earlier jobs were ignored.
 
 ### RuboCop errors
 
diff --git a/doc/ci/testing/test_coverage_visualization.md b/doc/ci/testing/test_coverage_visualization.md
index 31d1b7f3337..669157daa21 100644
--- a/doc/ci/testing/test_coverage_visualization.md
+++ b/doc/ci/testing/test_coverage_visualization.md
@@ -73,10 +73,11 @@ a [blocking manual job](../jobs/job_control.md#types-of-manual-jobs), the
 pipeline waits for the manual job before continuing and is not considered complete.
 The visualization cannot be displayed if the blocking manual job did not run.
 
-### Artifact expiration
+### Data expiration
 
-By default, the [pipeline artifact](../pipelines/pipeline_artifacts.md#storage) used
-to draw the visualization on the merge request expires **one week** after creation.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321323) in GitLab 13.12, the latest data is kept regardless of expiry time.
+
+By default, the data used to draw the visualization on the merge request expires **one week** after creation.
 
 ### Coverage report from child pipeline
 
@@ -296,7 +297,7 @@ run tests:
 The following [`.gitlab-ci.yml`](../yaml/index.md) example for PHP uses [PHPUnit](https://phpunit.readthedocs.io/)
 to collect test coverage data and generate the report.
 
-With a minimal [`phpunit.xml`](https://phpunit.readthedocs.io/en/9.5/configuration.html) file (you may reference
+With a minimal [`phpunit.xml`](https://docs.phpunit.de/en/10.2/configuration.html) file (you may reference
 [this example repository](https://gitlab.com/yookoala/code-coverage-visualization-with-php/)), you can run the test and
 generate the `coverage.xml`:
 
@@ -428,6 +429,8 @@ the coverage report itself and verify that:
 - The file you are viewing in the diff view is mentioned in the coverage report.
 - The `source` and `filename` nodes in the report follows the [expected structure](#automatic-class-path-correction)
   to match the files in your repository.
+- The pipeline has completed. If the pipeline is [blocked on a manual job](../jobs/job_control.md#types-of-manual-jobs),
+  the pipeline is not considered complete.
 
 Report artifacts are not downloadable by default. If you want the report to be downloadable
 from the job details page, add your coverage report to the artifact `paths`:
diff --git a/doc/ci/testing/unit_test_report_examples.md b/doc/ci/testing/unit_test_report_examples.md
index c63e225a2a7..1b1600b3d99 100644
--- a/doc/ci/testing/unit_test_report_examples.md
+++ b/doc/ci/testing/unit_test_report_examples.md
@@ -260,7 +260,7 @@ test:
 
 This example uses [PHPUnit](https://phpunit.de/) with the `--log-junit` flag.
 You can also add this option using
-[XML](https://phpunit.readthedocs.io/en/9.5/configuration.html#the-junit-element)
+[XML](https://docs.phpunit.de/en/10.2/configuration.html#the-junit-element)
 in the `phpunit.xml` configuration file.
 
 ```yaml
diff --git a/doc/ci/triggers/index.md b/doc/ci/triggers/index.md
index b9e5dd87b24..412394a24e7 100644
--- a/doc/ci/triggers/index.md
+++ b/doc/ci/triggers/index.md
@@ -26,8 +26,8 @@ Prerequisite:
 
 To create a trigger token:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Pipeline triggers**.
 1. Enter a description and select **Add trigger**.
    - You can view and copy the full token for all triggers you have created.
@@ -153,8 +153,8 @@ users with the Owner and Maintainer role can view the values.
 
 To revoke a trigger token:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Pipeline triggers**.
 1. To the left of the trigger token you want to revoke, select **Revoke** (**{remove}**).
 
diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md
index 973c6b90fc5..e94ccfa6b2b 100644
--- a/doc/ci/troubleshooting.md
+++ b/doc/ci/troubleshooting.md
@@ -246,15 +246,10 @@ After the pipeline is created, the message updates with the pipeline status.
 
 ### Merge request status messages
 
-The merge request status widget shows the **Merge** button and whether or not a merge
-request is ready to merge. If the merge request can't be merged, the reason for this
-is displayed.
+The merge request status widget shows:
 
-If the pipeline is still running, **Merge** is replaced with the
-**Merge when pipeline succeeds** button.
-
-If [**Merge Trains**](pipelines/merge_trains.md)
-are enabled, the button is either **Add to merge train** or **Add to merge train when pipeline succeeds**. **(PREMIUM)**
+- If the merge request is ready to merge. If the merge request can't be merged, the reason is displayed.
+- **Merge**, if the pipeline is complete, or **Set to auto-merge** if the pipeline is still running.
 
 #### "A CI/CD pipeline must run and be successful before merge" message
 
@@ -333,6 +328,23 @@ When you rerun a job, uses the same configuration each time. If you update confi
 including separate files added with [`include`](yaml/index.md#include), you must
 start a new pipeline to use the new configuration.
 
+### Unable to pull image from another project
+
+When a runner tries to pull an image from a private project, the job could fail with the following error:
+
+```shell
+WARNING: Failed to pull image with policy "always": Error response from daemon: pull access denied for registry.example.com/path/to/project, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
+```
+
+This error can happen if the following are both true:
+
+- The **Allow access to this project with a CI_JOB_TOKEN** option is enabled in the private project
+  hosting the image.
+- The job attempting to fetch the image is running for a project that is not listed in
+  the private project's allowlist.
+
+The recommended solution is to [add your project to the private project's job token scope allowlist](jobs/ci_job_token.md#add-a-project-to-the-job-token-scope-allowlist).
+
 ## Pipeline warnings
 
 Pipeline configuration warnings are shown when you:
@@ -387,9 +399,9 @@ on shared runners, which reduces system resource usage on the `jobs/request` end
 When enabled, jobs are processed in the order they were put in the system, instead of
 balanced across many projects.
 
-### Disable CI/CD minutes quota enforcement
+### Disable compute quota enforcement
 
-To disable the enforcement of CI/CD minutes quotas on shared runners, you can temporarily
+To disable the enforcement of [compute quotas](pipelines/cicd_minutes.md) on shared runners, you can temporarily
 enable the `ci_queueing_disaster_recovery_disable_quota` [feature flag](../administration/feature_flags.md).
 This flag reduces system resource usage on the `jobs/request` endpoint.
 
@@ -401,7 +413,7 @@ Earlier jobs are already canceled by a periodic background worker (`StuckCiJobsW
 The following commands are run in the [rails console](../administration/operations/rails_console.md#starting-a-rails-console-session).
 
 WARNING:
-Any command that changes data directly could be damaging if not run correctly, or under the right conditions.  
+Any command that changes data directly could be damaging if not run correctly, or under the right conditions.
 We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.
 
 ### Cancel stuck pending pipelines
diff --git a/doc/ci/variables/index.md b/doc/ci/variables/index.md
index 64a0f1038ad..7b6ba36e35d 100644
--- a/doc/ci/variables/index.md
+++ b/doc/ci/variables/index.md
@@ -194,8 +194,9 @@ Prerequisite:
 
 To add an instance variable:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD** and expand the **Variables** section.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD** and expand the **Variables** section.
 1. Select **Add variable** and fill in the details:
    - **Key**: Must be one line, with no spaces, using only letters, numbers, or `_`.
    - **Value**: In [GitLab 13.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/220028),
@@ -353,9 +354,9 @@ kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$KU
 ```
 
 WARNING:
-Be careful when assigning the value of a file variable to another variable. The other
-variable takes the content of the file as its value, **not** the path to the file.
-[Issue 29407](https://gitlab.com/gitlab-org/gitlab/-/issues/29407) proposes to change this behavior.
+Be careful when assigning the value of a file variable to another variable in GitLab 15.6 or older.
+The other variable takes the content of the file as its value, **not** the path to the file.
+In GitLab 15.7 and newer, this behavior [was fixed](https://gitlab.com/gitlab-org/gitlab/-/issues/29407) and the other variable now takes the path to the file as the value.
 
 #### Use a `.gitlab-ci.yml` variable as a file type variable
 
@@ -718,6 +719,10 @@ use this setting for control over the environment the pipeline runs in.
   The example can be copied to your own group or instance for testing. More details
   on what other GitLab CI patterns are demonstrated are available at the project page.
 
+- You can [pass CI/CD variables to downstream pipelines](../pipelines/downstream_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline).
+  Use [`trigger:forward` keyword](../yaml/index.md#triggerforward) to specify what type of variables
+  to pass to the downstream pipeline.
+
 ## Troubleshooting
 
 ### List all variables
diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md
index 001a599776a..1656b2147d5 100644
--- a/doc/ci/variables/predefined_variables.md
+++ b/doc/ci/variables/predefined_variables.md
@@ -35,7 +35,7 @@ as it can cause the pipeline to behave unexpectedly.
 | `CI_COMMIT_DESCRIPTION`                  | 10.8   | all    | The description of the commit. If the title is shorter than 100 characters, the message without the first line. |
 | `CI_COMMIT_MESSAGE`                      | 10.8   | all    | The full commit message. |
 | `CI_COMMIT_REF_NAME`                     | 9.0    | all    | The branch or tag name for which project is built. |
-| `CI_COMMIT_REF_PROTECTED`                | 11.11  | all    | `true` if the job is running for a protected reference. |
+| `CI_COMMIT_REF_PROTECTED`                | 11.11  | all    | `true` if the job is running for a protected reference, `false` otherwise. |
 | `CI_COMMIT_REF_SLUG`                     | 9.0    | all    | `CI_COMMIT_REF_NAME` in lowercase, shortened to 63 bytes, and with everything except `0-9` and `a-z` replaced with `-`. No leading / trailing `-`. Use in URLs, host names and domain names. |
 | `CI_COMMIT_SHA`                          | 9.0    | all    | The commit revision the project is built for. |
 | `CI_COMMIT_SHORT_SHA`                    | 11.7   | all    | The first eight characters of `CI_COMMIT_SHA`. |
@@ -110,7 +110,7 @@ as it can cause the pipeline to behave unexpectedly.
 | `CI_REGISTRY_PASSWORD`                   | 9.0    | all    | The password to push containers to the project's GitLab Container Registry. Only available if the Container Registry is enabled for the project. This password value is the same as the `CI_JOB_TOKEN` and is valid only as long as the job is running. Use the `CI_DEPLOY_PASSWORD` for long-lived access to the registry |
 | `CI_REGISTRY_USER`                       | 9.0    | all    | The username to push containers to the project's GitLab Container Registry. Only available if the Container Registry is enabled for the project. |
 | `CI_REGISTRY`                            | 8.10   | 0.5    | The address of the GitLab Container Registry. Only available if the Container Registry is enabled for the project. This variable includes a `:port` value if one is specified in the registry configuration. |
-| `CI_REPOSITORY_URL`                      | 9.0    | all    | The URL to clone the Git repository. |
+| `CI_REPOSITORY_URL`                      | 9.0    | all    | The full path to Git clone (HTTP) the repository with a [CI/CD job token](../jobs/ci_job_token.md), in the format `https://gitlab-ci-token:$CI_JOB_TOKEN@gitlab.example.com/my-group/my-project.git`. |
 | `CI_RUNNER_DESCRIPTION`                  | 8.10   | 0.5    | The description of the runner. |
 | `CI_RUNNER_EXECUTABLE_ARCH`              | all    | 10.6   | The OS/architecture of the GitLab Runner executable. Might not be the same as the environment of the executor. |
 | `CI_RUNNER_ID`                           | 8.10   | 0.5    | The unique ID of the runner being used. |
diff --git a/doc/ci/variables/where_variables_can_be_used.md b/doc/ci/variables/where_variables_can_be_used.md
index c20d9be51e7..14dfc5dd551 100644
--- a/doc/ci/variables/where_variables_can_be_used.md
+++ b/doc/ci/variables/where_variables_can_be_used.md
@@ -28,10 +28,12 @@ There are two places defined variables can be used. On the:
 | [`artifacts:name`](../yaml/index.md#artifactsname)                    | yes              | Runner                 | The variable expansion is made by GitLab Runner's shell environment. |
 | [`before_script`](../yaml/index.md#before_script)                     | yes              | Script execution shell | The variable expansion is made by the [execution shell environment](#execution-shell-environment) |
 | [`cache:key`](../yaml/index.md#cachekey)                              | yes              | Runner                 | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
+| [`cache:policy`](../yaml/index.md#cachepolicy)                        | yes              | Runner                 | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
 | [`environment:name`](../yaml/index.md#environmentname)                | yes              | GitLab                 | Similar to `environment:url`, but the variables expansion doesn't support the following:<br/><br/>- `CI_ENVIRONMENT_*` variables.<br/>- [Persisted variables](#persisted-variables). |
 | [`environment:url`](../yaml/index.md#environmenturl)                  | yes              | GitLab                 | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab.<br/><br/>Supported are all variables defined for a job (project/group variables, variables from `.gitlab-ci.yml`, variables from triggers, variables from pipeline schedules).<br/><br/>Not supported are variables defined in the GitLab Runner `config.toml` and variables created in the job's `script`. |
 | [`environment:auto_stop_in`](../yaml/index.md#environmentauto_stop_in)| yes              | GitLab                 | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab.<br/><br/> The value of the variable being substituted should be a period of time in a human readable natural language form. See [possible inputs](../yaml/index.md#environmentauto_stop_in) for more information.|
 | [`except:variables`](../yaml/index.md#onlyvariables--exceptvariables) | no               | Not applicable         | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- `CI_ENVIRONMENT_*` variables, except `CI_ENVIRONMENT_NAME` which is supported.<br/>- [Persisted variables](#persisted-variables). |
+| [`id_tokens:aud`](../yaml/index.md#id_tokens)                         | yes              | GitLab                 | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. Variable expansion [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/414293) in GitLab 16.1. |
 | [`image`](../yaml/index.md#image)                                     | yes              | Runner                 | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
 | [`include`](../yaml/index.md#include)                                 | yes              | GitLab                 | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. <br/><br/>See [Use variables with include](../yaml/includes.md#use-variables-with-include) for more information on supported variables. |
 | [`only:variables`](../yaml/index.md#onlyvariables--exceptvariables)   | no               | Not applicable         | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- `CI_ENVIRONMENT_*` variables, except `CI_ENVIRONMENT_NAME` which is supported.<br/>- [Persisted variables](#persisted-variables). |
diff --git a/doc/ci/yaml/artifacts_reports.md b/doc/ci/yaml/artifacts_reports.md
index 78c9e98c33f..37cb7efdf94 100644
--- a/doc/ci/yaml/artifacts_reports.md
+++ b/doc/ci/yaml/artifacts_reports.md
@@ -189,7 +189,7 @@ GitLab can display the results of one or more reports in:
 The `dotenv` report collects a set of environment variables as artifacts.
 
 The collected variables are registered as runtime-created variables of the job,
-which you can use to [set dynamic environment URLs after a job finishes](../environments/index.md#set-dynamic-environment-urls-after-a-job-finishes).
+which you can use to [set dynamic environment URLs after a job finishes](../environments/index.md#set-a-dynamic-environment-url).
 
 If duplicate environment variables are present in a `dotenv` report:
 
diff --git a/doc/ci/yaml/includes.md b/doc/ci/yaml/includes.md
index 35b302d0373..69595b62de2 100644
--- a/doc/ci/yaml/includes.md
+++ b/doc/ci/yaml/includes.md
@@ -418,6 +418,8 @@ these keywords:
 
 ### `include` with `rules:if`
 
+> Support for `when: never` and `when:always` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/348146) in GitLab 16.1 [with a flag](../../administration/feature_flags.md) named `ci_support_include_rules_when_never`. Disabled by default.
+
 Use [`rules:if`](index.md#rulesif) to conditionally include other configuration files
 based on the status of CI/CD variables. For example:
 
@@ -425,6 +427,14 @@ based on the status of CI/CD variables. For example:
 include:
   - local: builds.yml
     rules:
+      - if: $DONT_INCLUDE_BUILDS == "true"
+        when: never
+  - local: builds.yml
+    rules:
+      - if: $ALWAYS_INCLUDE_BUILDS == "true"
+        when: always
+  - local: builds.yml
+    rules:
       - if: $INCLUDE_BUILDS == "true"
   - local: deploys.yml
     rules:
@@ -437,6 +447,8 @@ test:
 
 ### `include` with `rules:exists`
 
+> Support for `when: never` and `when:always` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/348146) in GitLab 16.1 [with a flag](../../administration/feature_flags.md) named `ci_support_include_rules_when_never`. Disabled by default.
+
 Use [`rules:exists`](index.md#rulesexists) to conditionally include other configuration files
 based on the existence of files. For example:
 
@@ -445,6 +457,16 @@ include:
   - local: builds.yml
     rules:
       - exists:
+          - exception-file.md
+        when: never
+  - local: builds.yml
+    rules:
+      - exists:
+          - important-file.md
+        when: always
+  - local: builds.yml
+    rules:
+      - exists:
           - file.md
 
 test:
@@ -508,7 +530,7 @@ When the pipeline runs, GitLab:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/391331) in GitLab 15.11 as a Beta feature.
 
 FLAG:
-`spec` and `with` are experimental [Open Beta features](../../policy/alpha-beta-support.md#beta)
+`spec` and `with` are experimental [Open Beta features](../../policy/experiment-beta-support.md#beta)
 and subject to change without notice.
 
 ### Define input parameters with `spec:inputs`
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index ab5226c1c30..3dfc98c043a 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -739,7 +739,7 @@ attached to the job when it [succeeds, fails, or always](#artifactswhen).
 
 The artifacts are sent to GitLab after the job finishes. They are
 available for download in the GitLab UI if the size is smaller than the
-the [maximum artifact size](../../user/gitlab_com/index.md#gitlab-cicd).
+[maximum artifact size](../../user/gitlab_com/index.md#gitlab-cicd).
 
 By default, jobs in later stages automatically download all the artifacts created
 by jobs in earlier stages. You can control artifact download behavior in jobs with
@@ -837,7 +837,6 @@ subdirectories of `binaries/`.
 > - [Made default behavior](https://gitlab.com/gitlab-org/gitlab/-/issues/229936) in GitLab 13.4.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/241026) in GitLab 13.8, keeping latest job artifacts can be disabled at the project level.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276583) in GitLab 13.9, keeping latest job artifacts can be disabled instance-wide.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321323) in GitLab 13.12, the latest pipeline artifacts are kept regardless of expiry time.
 
 Use `expire_in` to specify how long [job artifacts](../jobs/job_artifacts.md) are stored before
 they expire and are deleted. The `expire_in` setting does not affect:
@@ -845,9 +844,6 @@ they expire and are deleted. The `expire_in` setting does not affect:
 - Artifacts from the latest job, unless keeping the latest job artifacts is disabled
   [at the project level](../jobs/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs).
   or [instance-wide](../../user/admin_area/settings/continuous_integration.md#keep-the-latest-artifacts-for-all-jobs-in-the-latest-successful-pipelines).
-- [Pipeline artifacts](../pipelines/pipeline_artifacts.md). You can't specify an expiration date for
-  pipeline artifacts. See [When pipeline artifacts are deleted](../pipelines/pipeline_artifacts.md#when-pipeline-artifacts-are-deleted)
-  for more information.
 
 After their expiry, artifacts are deleted hourly by default (using a cron job), and are not
 accessible anymore.
@@ -965,10 +961,13 @@ job:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223273) in GitLab 13.8 [with a flag](../../user/feature_flags.md) named `non_public_artifacts`, disabled by default.
 > - [Updated](https://gitlab.com/gitlab-org/gitlab/-/issues/322454) in GitLab 15.10. Artifacts created with `artifacts:public` before 15.10 are not guaranteed to remain private after this update.
 
-FLAG:
+WARNING:
 On self-managed GitLab, by default this feature is not available. To make it available,
 ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `non_public_artifacts`. On
-GitLab.com, this feature is not available.
+GitLab.com, this feature is not available. Due to [issue 413822](https://gitlab.com/gitlab-org/gitlab/-/issues/413822),
+the keyword can be used when the feature flag is disabled, but the feature does not work.
+Do not attempt to use this feature when the feature flag is disabled, and always test
+with non-production data first.
 
 Use `artifacts:public` to determine whether the job artifacts should be
 publicly available.
@@ -1453,6 +1452,7 @@ Must be used with `cache: paths`, or nothing is cached.
 - `pull`
 - `push`
 - `pull-push` (default)
+- [CI/CD variables](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
 
 **Example of `cache:policy`**:
 
@@ -1480,6 +1480,10 @@ faster-test-job:
     - echo "Running tests..."
 ```
 
+**Related topics**:
+
+- You can [use a variable to control a job's cache policy](../caching/index.md#use-a-variable-to-control-a-jobs-cache-policy).
+
 #### `cache:fallback_keys`
 
 Use `cache:fallback_keys` to specify a list of keys to try to restore cache from
@@ -1846,7 +1850,7 @@ environment, using the `production`
 
 **Related topics**:
 
-- [Available settings for `kubernetes`](../environments/index.md#configure-kubernetes-deployments-deprecated).
+- [Available settings for `kubernetes`](../environments/configure_kubernetes_deployments.md).
 
 #### `environment:deployment_tier`
 
@@ -2019,7 +2023,10 @@ JWTs created this way support OIDC authentication. The required `aud` sub-keywor
 
 **Possible inputs**:
 
-- Token names with their `aud` claims. `aud` can be a single string or as an array of strings.
+- Token names with their `aud` claims. `aud` supports:
+  - A single string.
+  - An array of strings.
+  - [CI/CD variables](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
 
 **Example of `id_tokens`**:
 
@@ -4265,7 +4272,7 @@ The keywords available for use in trigger jobs are:
 
 - For multi-project pipelines, the path to the downstream project. CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
   in GitLab 15.3 and later, but not [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables).
-  Alternatively, use [`trigger:project](#triggerproject).
+  Alternatively, use [`trigger:project`](#triggerproject).
 - For child pipelines, use [`trigger:include`](#triggerinclude).
 
 **Example of `trigger`**:
diff --git a/doc/ci/yaml/workflow.md b/doc/ci/yaml/workflow.md
index 82144e55216..e88a96ae1f5 100644
--- a/doc/ci/yaml/workflow.md
+++ b/doc/ci/yaml/workflow.md
@@ -129,7 +129,7 @@ workflow:
   rules:
     - if: $CI_PIPELINE_SOURCE == "merge_request_event"
     - if: $CI_COMMIT_TAG
-    - if: $CI_COMMIT_REF_PROTECTED
+    - if: $CI_COMMIT_REF_PROTECTED == "true"
 ```
 
 This example assumes that your long-lived branches are [protected](../../user/project/protected_branches.md).
diff --git a/doc/development/ai_architecture.md b/doc/development/ai_architecture.md
index e9994c8a6f4..ac62f50baf5 100644
--- a/doc/development/ai_architecture.md
+++ b/doc/development/ai_architecture.md
@@ -84,7 +84,7 @@ Web --> AIF
 
 GitLab currently operates a cloud-hosted AI architecture. We are exploring how self-managed instances integrate with it.
 
-There are two primary reasons for this: the best AI models are cloud-based as they often depend on specialized hardware designed for this purpose, and operating self-managed infrastructure capable of AI at-scale and with appropriate performance is a significant undertaking. We are actively [tracking self-managed customers interested in AI](https://gitlab.com/gitlab-org/gitlab/-/issues/409183). 
+There are two primary reasons for this: the best AI models are cloud-based as they often depend on specialized hardware designed for this purpose, and operating self-managed infrastructure capable of AI at-scale and with appropriate performance is a significant undertaking. We are actively [tracking self-managed customers interested in AI](https://gitlab.com/gitlab-org/gitlab/-/issues/409183).
 
 ## Supported technologies
 
diff --git a/doc/development/ai_features.md b/doc/development/ai_features.md
index 6ed1d59c3e0..c46117c4afd 100644
--- a/doc/development/ai_features.md
+++ b/doc/development/ai_features.md
@@ -66,7 +66,9 @@ All AI features are experimental.
    1. Enable **Experiment features**
    1. Enable **Third-party AI services**
 1. Enable the specific feature flag for the feature you want to test
-1. Set either the required access token `OpenAi` or `Vertex`. Ask in [`#ai_enablement_team`](https://gitlab.slack.com/archives/C051K31F30R) to receive an access token.
+1. Set the required access token. To receive an access token:
+   1. For Vertex, follow the [instructions below](#configure-gcp-vertex-access).
+   1. For all other providers, like Anthropic or OpenAI, create an access request where `@m_gill`, `@wayne`, and `@timzallmann` are the tech stack owners.
 
 ### Set up the embedding database
 
@@ -82,28 +84,38 @@ For features that use the embedding database, additional setup is needed.
 1. Run `gdk reconfigure`
 1. Run database migrations to create the embedding database
 
-### Setup for GitLab chat
+### Setup for GitLab documentation chat (legacy chat)
 
 To populate the embedding database for GitLab chat:
 
 1. Open a rails console
 1. Run [this script](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/10588#note_1373586079) to populate the embedding database
 
+### Debugging
+
+To gather more insights about the full request, use the `Gitlab::Llm::Logger` file to debug logs.
+To follow the debugging messages related to the AI requests on the abstraction layer, you can use:
+
+```shell
+tail -f log/llm.log
+```
+
 ### Configure GCP Vertex access
 
 In order to obtain a GCP service key for local development, please follow the steps below:
 
-- Create a sandbox GCP environment by visiting [this page](https://about.gitlab.com/handbook/infrastructure-standards/#individual-environment) and following the instructions
+- Create a sandbox GCP environment by visiting [this page](https://about.gitlab.com/handbook/infrastructure-standards/#individual-environment) and following the instructions, or by requesting access to our existing group environment by using [this template](https://gitlab.com/gitlab-com/it/infra/issue-tracker/-/issues/new?issuable_template=gcp_group_account_iam_update_request). At this time, access to any endpoints outside of `text-bison` or `chat-bison` must be made through the group environment.
 - In the GCP console, go to `IAM & Admin` > `Service Accounts` and click on the "Create new service account" button
 - Name the service account something specific to what you're using it for. Select Create and Continue. Under `Grant this service account access to project`, select the role `Vertex AI User`. Select `Continue` then `Done`
-- Select your new service account and `Manage keys` > `Add Key` > `Create new key`. This will download the **private** JSON credentials for your service account. Your full settings should then be:
+- Select your new service account and `Manage keys` > `Add Key` > `Create new key`. This will download the **private** JSON credentials for your service account.
+- Open the Rails console. Update the settings to:
 
 ```ruby
-Gitlab::CurrentSettings.update(tofa_credentials: File.read('/YOUR_FILE.json'))
+Gitlab::CurrentSettings.update(vertex_ai_credentials: File.read('/YOUR_FILE.json'))
 
 # Note: These credential examples will not work locally for all models
-Gitlab::CurrentSettings.update(tofa_host: "<root-domain>") # Example: us-central1-aiplatform.googleapis.com
-Gitlab::CurrentSettings.update(tofa_url: "<full-api-endpoint>") # Example: https://ROOT-DOMAIN/v1/projects/MY-COOL-PROJECT/locations/us-central1/publishers/google/models/MY-SPECIAL-MODEL:predict
+Gitlab::CurrentSettings.update(vertex_ai_host: "<root-domain>") # Example: us-central1-aiplatform.googleapis.com
+Gitlab::CurrentSettings.update(vertex_ai_project: "<project-id>") # Example: cloud-large-language-models
 ```
 
 Internal team members can [use this snippet](https://gitlab.com/gitlab-com/gl-infra/production/-/snippets/2541742) for help configuring these endpoints.
@@ -308,7 +320,6 @@ We recommend to use [policies](policies.md) to deal with authorization for a fea
 1. Feature specific feature flag is enabled
 1. The namespace has the required license for the feature
 1. User is a member of the group/project
-1. Resource is allowed to be sent (see `send_to_ai?` method)
 1. `experiment_features_enabled` and `third_party_ai_features_enabled` flags are set on the `Namespace`
 
 For our example, we need to implement the `allowed?(:amazing_new_ai_feature)` call. As an example, you can look at the [Issue Policy for the summarize comments feature](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/policies/ee/issue_policy.rb). In our example case, we want to implement the feature for Issues as well:
@@ -322,8 +333,7 @@ module EE
     prepended do
       with_scope :subject
       condition(:ai_available) do
-        ::Feature.enabled?(:openai_experimentation) &&
-          @subject.send_to_ai?
+        ::Feature.enabled?(:openai_experimentation)
       end
 
       with_scope :subject
@@ -340,19 +350,6 @@ module EE
 end
 ```
 
-### Implement `send_to_ai?`
-
-To make sure we only send data that is allowed to be sent, we have the `send_to_ai?` method. It checks if the resource is not confidential and public data.
-Some resources already implement `send_to_ai?`. Make sure yours does as well. In our case, `Issue` is already covered with the `Issuable` concern. This is an example how it could look like:
-
-```ruby
-# ee/app/models/concerns/ee
-
-def send_to_ai?
-  !try(:confidential) && resource_parent.public?
-end
-```
-
 ### Check if feature is allowed for this resource based on namespace settings
 
 There are two settings allowed on root namespace level that restrict the use of AI features:
@@ -444,6 +441,13 @@ module Gitlab
 end
 ```
 
+Because we support multiple AI providers, you may also use those providers for the same example:
+
+```ruby
+Gitlab::Llm::VertexAi::Client.new(user)
+Gitlab::Llm::Anthropic::Client.new(user)
+```
+
 ### Add Ai Action to GraphQL
 
 TODO
diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index 15b587e3b1e..d6492b7814e 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -792,7 +792,7 @@ The documentation mentions that the old Global ID style is now deprecated.
 ## Mark schema items as Alpha
 
 You can mark GraphQL schema items (fields, arguments, enum values, and mutations) as
-[Alpha](../policy/alpha-beta-support.md#experiment).
+[Alpha](../policy/experiment-beta-support.md#experiment).
 
 An item marked as Alpha is [exempt from the deprecation process](#breaking-change-exemptions) and can be removed
 at any time without notice. Mark an item as Alpha when it is
diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md
index 0652b88617b..566267b97f1 100644
--- a/doc/development/api_styleguide.md
+++ b/doc/development/api_styleguide.md
@@ -303,7 +303,7 @@ from the server to the platform if we identify invalid parameters at the beginni
 If you need to add a custom validator, it would be added to
 it's own file in the [`validators`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/api/validations/validators) directory.
 Since we use [Grape](https://github.com/ruby-grape/grape) to add our API
-we inherit from the `Grape::Validations::Base` class in our validator class.
+we inherit from the `Grape::Validations::Validators::Base` class in our validator class.
 Now, all you have to do is define the `validate_param!` method which takes
 in two parameters: the `params` hash and the `param` name to validate.
 
diff --git a/doc/development/bulk_import.md b/doc/development/bulk_import.md
index b1fa4726b65..304aab9e3b3 100644
--- a/doc/development/bulk_import.md
+++ b/doc/development/bulk_import.md
@@ -8,9 +8,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2771) in GitLab 13.7.
 
-WARNING:
-This feature is [under construction](https://gitlab.com/groups/gitlab-org/-/epics/2771) and its API/Architecture might change in the future.
-
 [Group migration by direct transfer](../user/group/import/index.md#migrate-groups-by-direct-transfer-recommended) is the
 evolution of migrating groups and projects using file exports. The goal is to have an easier way for the user to migrate a whole group,
 including projects, from one GitLab instance to another.
diff --git a/doc/development/caching.md b/doc/development/caching.md
index dff94b68ca0..c3385c8499d 100644
--- a/doc/development/caching.md
+++ b/doc/development/caching.md
@@ -267,7 +267,7 @@ All the time!
 
 #### Possible downsides
 
-- Adding new attributes to a cached object using `Gitlab::JsonCache`
+- Adding new attributes to a cached object using `Gitlab::Cache::JsonCache`
   and `Gitlab::SafeRequestStore`, for example, can lead to stale data issues
   where the cache data doesn't have the appropriate value for the new attribute
   (see this past [incident](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6372)).
diff --git a/doc/development/chatops_on_gitlabcom.md b/doc/development/chatops_on_gitlabcom.md
index 22f57e8ba43..002470f7325 100644
--- a/doc/development/chatops_on_gitlabcom.md
+++ b/doc/development/chatops_on_gitlabcom.md
@@ -1,6 +1,6 @@
 ---
-stage: Manage
-group: Import and Integrate
+stage: Deploy
+group: Environments
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/cicd/cicd_tables.md b/doc/development/cicd/cicd_tables.md
index b246328a817..8cfb0faca00 100644
--- a/doc/development/cicd/cicd_tables.md
+++ b/doc/development/cicd/cicd_tables.md
@@ -29,7 +29,7 @@ Here is an example on how to use database helpers to create a new table and fore
     end
 
     add_concurrent_partitioned_foreign_key(
-      :p_ci_examples, :ci_builds,
+      :p_ci_examples, :p_ci_builds,
       column: [:partition_id, :build_id],
       target_column: [:partition_id, :id],
       on_update: :cascade,
@@ -51,7 +51,7 @@ When creating the routing table:
 - The table name must start with the `p_` prefix. There are analyzers in place to ensure that all queries go
   through the routing tables and do not access the partitions directly.
 - Each new table needs a `partition_id` column and its value must equal
-  the value from the related association. In this example, that is `ci_builds`. All resources
+  the value from the related association. In this example, that is `p_ci_builds`. All resources
   belonging to a pipeline share the same `partition_id` value.
 - The primary key must have the columns ordered this way to allow efficient
   search only by `id`.
@@ -74,7 +74,7 @@ the application runs:
   def up
     with_lock_retries do
       connection.execute(<<~SQL)
-        LOCK TABLE ci_builds IN SHARE UPDATE EXCLUSIVE MODE;
+        LOCK TABLE p_ci_builds IN SHARE ROW EXCLUSIVE MODE;
         LOCK TABLE ONLY p_ci_examples IN ACCESS EXCLUSIVE MODE;
       SQL
 
@@ -92,7 +92,7 @@ Partitions are created in `gitlab_partitions_dynamic` schema.
 When creating a partition, remember:
 
 - Partition names do not use the `p_` prefix.
-- The default value for `partition_id` is `100`.
+- The starting value for `partition_id` is `100`.
 
 ## Cascade the partition value
 
diff --git a/doc/development/cicd/index.md b/doc/development/cicd/index.md
index 2cc8fca02dd..b186c37f933 100644
--- a/doc/development/cicd/index.md
+++ b/doc/development/cicd/index.md
@@ -185,12 +185,14 @@ We have a few inconsistencies in our codebase that should be refactored.
 For example, `CommitStatus` should be `Ci::Job` and `Ci::JobArtifact` should be `Ci::BuildArtifact`.
 See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/16111) for the full refactoring plan.
 
-## CI/CD Minutes
+## Compute quota
 
-This diagram shows how the [CI/CD minutes](../../ci/pipelines/cicd_minutes.md)
+> [Renamed](https://gitlab.com/groups/gitlab-com/-/epics/2150) from "CI/CD minutes" to "compute quota" and "units of compute" in GitLab 16.1.
+
+This diagram shows how the [Compute quota](../../ci/pipelines/cicd_minutes.md)
 feature and its components work.
 
-![CI/CD minutes architecture](img/ci_minutes.png)
+![compute quota architecture](img/ci_minutes.png)
 <!-- Editable diagram available at https://app.diagrams.net/?libs=general;flowchart#G1XjLPvJXbzMofrC3eKRyDEk95clV6ypOb -->
 
 Watch a walkthrough of this feature in details in the video below.
diff --git a/doc/development/cicd/templates.md b/doc/development/cicd/templates.md
index 1bf4a780e26..77e529867af 100644
--- a/doc/development/cicd/templates.md
+++ b/doc/development/cicd/templates.md
@@ -424,7 +424,7 @@ To add a metric definition for a new template:
 
 1. Install and start the [GitLab GDK](https://gitlab.com/gitlab-org/gitlab-development-kit#installation).
 1. In the `gitlab` directory in your GDK, check out the branch that contains the new template.
-1. [Add the template inclusion event](../service_ping/implement.md#add-new-events)
+1. [Add the template inclusion event](../internal_analytics/service_ping/implement.md#add-new-events)
    with this Rake task:
 
    ```shell
@@ -445,7 +445,7 @@ To add a metric definition for a new template:
    - [`config/metrics/counts_28d/20210216184559_ci_templates_total_unique_counts_monthly.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/counts_28d/20210216184559_ci_templates_total_unique_counts_monthly.yml)
 
 1. Use the same `name` as above as the last argument in the following command to
-  [add new metric definitions](../service_ping/metrics_dictionary.md#metrics-added-dynamic-to-service-ping-payload):
+  [add new metric definitions](../internal_analytics/service_ping/metrics_dictionary.md#metrics-added-dynamic-to-service-ping-payload):
 
    ```shell
    bundle exec rails generate gitlab:usage_metric_definition:redis_hll ci_templates <template_metric_event_name>
@@ -466,7 +466,7 @@ To add a metric definition for a new template:
    - `data_source:`: Set to `redis_hll`.
    - `description`: Add a short description of what this metric counts, for example: `Count of pipelines using the latest Auto Deploy template`
    - `product_*`: Set to [section, stage, group, and feature category](https://about.gitlab.com/handbook/product/categories/#devops-stages)
-     as per the [metrics dictionary guide](../service_ping/metrics_dictionary.md#metrics-definition-and-validation).
+     as per the [metrics dictionary guide](../internal_analytics/service_ping/metrics_dictionary.md#metrics-definition-and-validation).
      If you are unsure what to use for these keywords, you can ask for help in the merge request.
    - Add the following to the end of each file:
 
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index f2edc882d91..e9f00b640d9 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -28,12 +28,23 @@ The reviewer can:
 - Give you a second opinion on the chosen solution and implementation.
 - Help look for bugs, logic problems, or uncovered edge cases.
 
-If the merge request is trivial to review (for example, fixing a typo or a tiny refactor that doesn't change the behavior or any data),
-you can skip the reviewer step and directly ask a [maintainer](https://about.gitlab.com/handbook/engineering/workflow/code-review/#maintainer).
-Otherwise, a merge request should always be first reviewed by a reviewer in each
-[category (e.g. backend, database)](#approval-guidelines)
-the MR touches, as maintainers may not have the relevant domain knowledge, and
-also to spread the workload.
+If the merge request is small and straightforward to review, you can skip the reviewer step and
+directly ask a
+[maintainer](https://about.gitlab.com/handbook/engineering/workflow/code-review/#maintainer).
+
+What constitutes "small and straightforward" is a gray area. Here are
+some examples of small and straightforward changes:
+
+- Fixing a typo or making small copy changes ([example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121337#note_1399406719)).
+- A tiny refactor that doesn't change any behavior or data.
+- Removing references to a feature flag that has been default enabled for > 1 month.
+- Removing unused methods or classes.
+- A well-understood logic change that requires changes to < 5 lines of code.
+
+Otherwise, a merge request should be first reviewed by a reviewer in each
+[category (for example: backend, database)](#approval-guidelines)
+the MR touches, as maintainers may not have the relevant domain knowledge. This
+also helps to spread the workload.
 
 For assistance with security scans or comments, include the Application Security Team (`@gitlab-com/gl-security/appsec`).
 
@@ -47,6 +58,14 @@ The **Approved** button is in the merge request widget.
 Getting your merge request **merged** also requires a maintainer. If it requires
 more than one approval, the last maintainer to review and approve merges it.
 
+Some domain areas (like `Verify`) require an approval from a domain expert, based on
+CODEOWNERS rules. Because CODEOWNERS sections are independent approval rules, we could have certain
+rules (for example `Verify`) that may be a subset of other more generic approval rules (for example `backend`).
+For a more efficient process, authors should look for domain-specific approvals before generic approvals.
+Domain-specific approvers may also be maintainers, and if so they should review
+the domain specifics and broader change at the same time and approve once for
+both roles.
+
 Read more about [author responsibilities](#the-responsibility-of-the-merge-request-author) below.
 
 ### Domain experts
@@ -150,35 +169,38 @@ please use in your personal YAML file entry: `- reviewer database local` instead
 
 As described in the section on the responsibility of the maintainer below, you
 are recommended to get your merge request approved and merged by maintainers
-with [domain expertise](#domain-experts).
+with [domain expertise](#domain-experts). The optional approval of the first
+reviewer is not covered here. However, your merge request should be reviewed
+by a reviewer before passing it to a maintainer as described in the
+[overview](#getting-your-merge-request-reviewed-approved-and-merged) section.
 
 | If your merge request includes  | It must be approved by a |
 | ------------------------------- | ------------------------ |
-| `~backend` changes (*1*)        | [Backend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_backend). |
-| `~database` migrations or changes to expensive queries (*2*) | [Database maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_database). Refer to the [database review guidelines](database_review.md) for more details. |
+| `~backend` changes <sup>1</sup>        | [Backend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_backend). |
+| `~database` migrations or changes to expensive queries <sup>2</sup> | [Database maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_database). Refer to the [database review guidelines](database_review.md) for more details. |
 | `~workhorse` changes | [Workhorse maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_workhorse). |
-| `~frontend` changes (*1*)       | [Frontend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_frontend). |
-| `~UX` user-facing changes (*3*) | [Product Designer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_reviewers_UX). Refer to the [design and user interface guidelines](contributing/design.md) for details. |
-| Adding a new JavaScript library (*1*) | - [Frontend foundations member](https://about.gitlab.com/direction/manage/foundations/) if the library significantly increases the [bundle size](https://gitlab.com/gitlab-org/frontend/playground/webpack-memory-metrics/-/blob/master/doc/report.md).<br/>- A [legal department member](https://about.gitlab.com/handbook/legal/) if the license used by the new library hasn't been approved for use in GitLab.<br/><br/>More information about license compatibility can be found in our [GitLab Licensing and Compatibility documentation](licensing.md). |
+| `~frontend` changes <sup>1</sup>       | [Frontend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_frontend). |
+| `~UX` user-facing changes <sup>3</sup> | [Product Designer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_reviewers_UX). Refer to the [design and user interface guidelines](contributing/design.md) for details. |
+| Adding a new JavaScript library <sup>1</sup> | - [Frontend foundations member](https://about.gitlab.com/direction/manage/foundations/) if the library significantly increases the [bundle size](https://gitlab.com/gitlab-org/frontend/playground/webpack-memory-metrics/-/blob/master/doc/report.md).<br/>- A [legal department member](https://about.gitlab.com/handbook/legal/) if the license used by the new library hasn't been approved for use in GitLab.<br/><br/>More information about license compatibility can be found in our [GitLab Licensing and Compatibility documentation](licensing.md). |
 | A new dependency or a file system change | - [Distribution team member](https://about.gitlab.com/company/team/). See how to work with the [Distribution team](https://about.gitlab.com/handbook/engineering/development/enablement/systems/distribution/#how-to-work-with-distribution) for more details.<br/>- For RubyGems, request an [AppSec review](gemfile.md#request-an-appsec-review). |
 | `~documentation` or `~UI text` changes | [Technical writer](https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments) based on assignments in the appropriate [DevOps stage group](https://about.gitlab.com/handbook/product/categories/#devops-stages). |
 | Changes to development guidelines | Follow the [review process](development_processes.md#development-guidelines-review) and get the approvals accordingly. |
-| End-to-end **and** non-end-to-end changes (*4*) | [Software Engineer in Test](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors). |
-| Only End-to-end changes (*4*) **or** if the MR author is a [Software Engineer in Test](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors) | [Quality maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa). |
+| End-to-end **and** non-end-to-end changes <sup>4</sup> | [Software Engineer in Test](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors). |
+| Only End-to-end changes <sup>4</sup> **or** if the MR author is a [Software Engineer in Test](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors) | [Quality maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa). |
 | A new or updated [application limit](https://about.gitlab.com/handbook/product/product-processes/#introducing-application-limits) | [Product manager](https://about.gitlab.com/company/team/). |
-| Analytics Instrumentation (telemetry or analytics) changes | [Analytics Instrumentation engineer](https://gitlab.com/gitlab-org/analytics-section/product-intelligence/engineers). |
+| Analytics Instrumentation (telemetry or analytics) changes | [Analytics Instrumentation engineer](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/engineers). |
 | An addition of, or changes to a [Feature spec](testing_guide/testing_levels.md#frontend-feature-tests) | [Quality maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa) or [Quality reviewer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_reviewers_qa). |
 | A new service to GitLab (Puma, Sidekiq, Gitaly are examples) | [Product manager](https://about.gitlab.com/company/team/). See the [process for adding a service component to GitLab](adding_service_component.md) for details. |
 | Changes related to authentication or authorization | [Manage:Authentication and Authorization team member](https://about.gitlab.com/company/team/). Check the [code review section on the group page](https://about.gitlab.com/handbook/engineering/development/dev/manage/authentication-and-authorization/#additional-considerations) for more details. Patterns for files known to require review from the team are listed in the in the `Authentication and Authorization` section of the [`CODEOWNERS`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/CODEOWNERS) file, and the team will be listed in the approvers section of all merge requests that modify these files. |
 
-- (*1*): Specs other than JavaScript specs are considered `~backend` code. Haml markup is considered `~frontend` code. However, Ruby code within Haml templates is considered `~backend` code. When in doubt, request both a frontend and backend review.
-- (*2*): We encourage you to seek guidance from a database maintainer if your merge
-  request is potentially introducing expensive queries. It is most efficient to comment
-  on the line of code in question with the SQL queries so they can give their advice.
-- (*3*): User-facing changes include both visual changes (regardless of how minor),
-  and changes to the rendered DOM which impact how a screen reader may announce
-  the content.
-- (*4*): End-to-end changes include all files within the `qa` directory.
+1. Specs other than JavaScript specs are considered `~backend` code. Haml markup is considered `~frontend` code. However, Ruby code in Haml templates is considered `~backend` code. When in doubt, request both a frontend and backend review.
+1. We encourage you to seek guidance from a database maintainer if your merge
+   request is potentially introducing expensive queries. It is most efficient to comment
+   on the line of code in question with the SQL queries so they can give their advice.
+1. User-facing changes include both visual changes (regardless of how minor),
+   and changes to the rendered DOM which impact how a screen reader may announce
+   the content.
+1. End-to-end changes include all files in the `qa` directory.
 
 #### Acceptance checklist
 
@@ -210,6 +232,7 @@ See the [test engineering process](https://about.gitlab.com/handbook/engineering
 1. You have considered the availability and reliability risks of this change.
 1. You have considered the scalability risk based on future predicted growth.
 1. You have considered the performance, reliability, and availability impacts of this change on large customers who may have significantly more data than the average customer.
+1. You have considered the performance, reliability, and availability impacts of this change on customers who may run GitLab on the [minimum system](../install/requirements.md).
 
 ##### Observability instrumentation
 
@@ -372,7 +395,7 @@ codebase, and not that of any specific domain, they can review, approve, and mer
 merge requests from any team and in any product area.
 
 Maintainers are the DRI of assuring that the acceptance criteria of a merge request are reasonably met.
-In general, [quality is everyone’s responsibility](https://about.gitlab.com/handbook/engineering/quality/),
+In general, [quality is everyone's responsibility](https://about.gitlab.com/handbook/engineering/quality/),
 but maintainers of an MR are held responsible for **ensuring** that an MR meets those general quality standards.
 
 If a maintainer feels that an MR is substantial enough, or requires a [domain expert](#domain-experts),
@@ -405,10 +428,10 @@ On March 18th 2021, an updated process was put in place aimed at efficiently and
 
 Here is a summary of the changes, also reflected in this section above.
 
-- Merge request authors and DRIs stay as Assignees
-- Authors request a review from Reviewers when they are expected to review
-- Reviewers remove themselves after they're done reviewing/approving
-- The last approver stays as Reviewer upon merging
+- Merge request authors and DRIs stay as Assignees.
+- Authors request a review by assigning users as Reviewers.
+- Reviewers unassign themselves after they're done reviewing and approving.
+- The last approver (who merges the MR) stays assigned as Reviewer.
 
 ## Best practices
 
@@ -541,28 +564,37 @@ Before taking the decision to merge:
 - If the MR contains both Quality and non-Quality-related changes, the MR should be merged by the relevant maintainer for user-facing changes (backend, frontend, or database) after the Quality related changes are approved by a Software Engineer in Test.
 
 At least one maintainer must approve an MR before it can be merged. MR authors and
-people who add commits to an MR are not authorized to approve or merge the MR and
-must seek a maintainer who has not contributed to the MR to approve and merge it.
+people who add commits to an MR are not authorized to approve the MR and
+must seek a maintainer who has not contributed to the MR to approve it. In
+general, the final required approver should merge the MR.
+
+Scenarios in which the final approver might not merge an MR:
+
+- Approver forgets to set auto-merge after approving.
+- Approver doesn't realize that they are the final approver.
+- Approver sets auto-merge but it is un-set by GitLab.
+
+If any of these scenarios occurs, an MR author may merge their own MR if it
+has all required approvals and they have merge rights to the repository.
+This is also in line with the GitLab [bias for action](https://handbook.gitlab.com/handbook/values/#bias-for-action) value.
 
 This policy is in place to satisfy the CHG-04 control of the GitLab
 [Change Management Controls](https://about.gitlab.com/handbook/security/change-management-policy.html).
 
-<!-- Or should it link to: https://about.gitlab.com/handbook/engineering/infrastructure/change-management/ ? -->
-
 To implement this policy in `gitlab-org/gitlab`, we have enabled the following
 settings to ensure MRs get an approval from a top-level CODEOWNERS maintainer:
 
 - [Prevent approval by author](../user/project/merge_requests/approvals/settings.md#prevent-approval-by-author).
 - [Prevent approvals by users who add commits](../user/project/merge_requests/approvals/settings.md#prevent-approvals-by-users-who-add-commits).
 - [Prevent editing approval rules in merge requests](../user/project/merge_requests/approvals/settings.md#prevent-editing-approval-rules-in-merge-requests).
-- [Remove all approvals when commits are added to the source branch](../user/project/merge_requests/approvals/settings.md#remove-all-approvals-when-commits-are-added-to-the-source-branch)
+- [Remove all approvals when commits are added to the source branch](../user/project/merge_requests/approvals/settings.md#remove-all-approvals-when-commits-are-added-to-the-source-branch).
 
 To update the code owners in the `CODEOWNERS` file for `gitlab-org/gitlab`, follow
 the process explained in the [code owners approvals handbook section](https://about.gitlab.com/handbook/engineering/workflow/code-review/#code-owner-approvals).
 
-  There are scenarios such as rebasing locally or applying suggestions that are considered
-  the same as adding a commit and could reset existing approvals. Approvals are not removed
-  when rebasing from the UI or with the [`/rebase` quick action](../user/project/quick_actions.md).
+Some actions, such as rebasing locally or applying suggestions, are considered
+the same as adding a commit and could reset existing approvals. Approvals are not removed
+when rebasing from the UI or with the [`/rebase` quick action](../user/project/quick_actions.md).
 
 When ready to merge:
 
@@ -576,8 +608,7 @@ WARNING:
   messy commit history, it will be more efficient to squash commits instead of
   circling back with the author about that. Otherwise, if the MR only has a few commits, we'll
   be respecting the author's setting by not squashing them.
-- Start a new merge request pipeline with the `Run pipeline` button in the merge
-  request's "Pipelines" tab, and enable "Merge When Pipeline Succeeds" (MWPS).
+- Go to the merge request's **Pipelines** tab, and select **Run pipeline**. Then, on the **Overview** tab, enable **Auto-merge**.
   Note that:
   - If **[the default branch is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master),
     do not merge the merge request** except for
@@ -587,7 +618,7 @@ WARNING:
   - If the **latest [merged results pipeline](../ci/pipelines/merged_results_pipelines.md)** was **created less than 6 hours ago**, and **finished less than 2 hours ago**, you
     may merge without starting a new pipeline as the merge request is close
     enough to `main`.
-- When you set the MR to "Merge When Pipeline Succeeds", you should take over
+- When you set the MR to auto-merge, you should take over
   subsequent revisions for anything that would be spotted after that.
 - For merge requests that have had [Squash and merge](../user/project/merge_requests/squash_and_merge.md#squash-and-merge) set,
   the squashed commit's default commit message is taken from the merge request title.
@@ -597,7 +628,7 @@ Thanks to **merged results pipelines**, authors no longer have to rebase their
 branch as frequently anymore (only when there are conflicts) because the Merge
 Results Pipeline already incorporate the latest changes from `main`.
 This results in faster review/merge cycles because maintainers don't have to ask
-for a final rebase: instead, they only have to start a MR pipeline and set MWPS.
+for a final rebase: instead, they only have to start a MR pipeline and set auto-merge.
 This step brings us very close to the actual Merge Trains feature by testing the
 Merge Results against the latest `main` at the time of the pipeline creation.
 
@@ -733,7 +764,7 @@ A merge request may benefit from being considered a customer critical priority b
 
 Properties of customer critical merge requests:
 
-- The [VP of Development](https://about.gitlab.com/job-families/engineering/development/management/vp/) ([@clefelhocz1](https://gitlab.com/clefelhocz1)) is the DRI for deciding if a merge request qualifies as customer critical.
+- The [VP of Development](https://about.gitlab.com/job-families/engineering/development/management/vp/) ([@clefelhocz1](https://gitlab.com/clefelhocz1)) is the approver for deciding if a merge request qualifies as customer critical. Also, if two of his direct reports approve, that can also serve as approval.
 - The DRI applies the `customer-critical-merge-request` label to the merge request.
 - It is required that the reviewers and maintainers involved with a customer critical merge request are engaged as soon as this decision is made.
 - It is required to prioritize work for those involved on a customer critical merge request so that they have the time available necessary to focus on it.
diff --git a/doc/development/contributing/design.md b/doc/development/contributing/design.md
index d68bc194266..58ec0de6074 100644
--- a/doc/development/contributing/design.md
+++ b/doc/development/contributing/design.md
@@ -73,7 +73,7 @@ Check visual design properties using your browser's _elements inspector_ ([Chrom
   guidelines.
 - _Optionally_ consider [dark mode](../../user/profile/preferences.md#dark-mode). [^1]
 
- [^1]: You're not required to design for [dark mode](../../user/profile/preferences.md#dark-mode) while the feature is an [Experiment](../../policy/alpha-beta-support.md#experiment). The [UX Foundations team](https://about.gitlab.com/direction/manage/foundations/) plans to improve the dark mode in the future. Until we integrate [Pajamas](https://design.gitlab.com/) components into the product and the underlying design strategy is in place to support dark mode, we cannot guarantee that we won't introduce bugs and debt to this mode. At your discretion, evaluate the need to create dark mode patches.
+ [^1]: You're not required to design for [dark mode](../../user/profile/preferences.md#dark-mode) while the feature is an [Experiment](../../policy/experiment-beta-support.md#experiment). The [UX Foundations team](https://about.gitlab.com/direction/manage/foundations/) plans to improve the dark mode in the future. Until we integrate [Pajamas](https://design.gitlab.com/) components into the product and the underlying design strategy is in place to support dark mode, we cannot guarantee that we won't introduce bugs and debt to this mode. At your discretion, evaluate the need to create dark mode patches.
 
 ### States
 
@@ -110,8 +110,8 @@ Check accessibility using your browser's _accessibility inspector_ ([Chrome](htt
 
 When the design is ready, _before_ starting its implementation:
 
-- Share design specifications in the related issue, preferably through a [Figma link](https://help.figma.com/hc/en-us/articles/360040531773-Share-Files-with-anyone-using-Link-Sharing#copy-link)
-  link or [GitLab Designs feature](../../user/project/issues/design_management.md).
+- Share design specifications in the related issue, preferably through a [Figma link](https://help.figma.com/hc/en-us/articles/360040531773-Share-Files-with-anyone-using-Link-Sharing#Copy_link)
+  or [GitLab Designs feature](../../user/project/issues/design_management.md).
   See [when you should use each tool](https://about.gitlab.com/handbook/product/ux/product-designer/#deliver).
 - Document user flow and states (for example, using [Mermaid flowcharts in Markdown](../../user/markdown.md#mermaid)).
 - Document animations and transitions.
diff --git a/doc/development/contributing/first_contribution.md b/doc/development/contributing/first_contribution.md
index 0c4b5b21171..3cf7f222fe4 100644
--- a/doc/development/contributing/first_contribution.md
+++ b/doc/development/contributing/first_contribution.md
@@ -190,19 +190,19 @@ You can check that you were successful:
 ### Update the translation files
 
 English UI strings are localized into many languages.
-These strings are saved in a `.pot` file, which you must update
+These strings are saved in a `.pot` file, which must be regenerated
 any time you update UI text.
 
-To generate the localization file:
+To automatically regenerate the localization file:
 
 1. Ensure you are in the `gitlab-development-kit/gitlab` directory.
 1. Run the following command:
 
    ```shell
-   bin/rake gettext:compile
+   tooling/bin/gettext_extractor locale/gitlab.pot
    ```
 
-   After several minutes, a `.pot` file is generated in the `/locale` directory.
+   The `.pot` file will be generated in the `/locale` directory.
 
 Now, in the `gitlab-development-kit/gitlab` directory, if you type `git status`
 you should have both files listed:
diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index 82a08246503..eb26ddbd9e9 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -36,13 +36,8 @@ open a [new issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issue%5Bmil
 Select the appropriate template, and add all the necessary information about the work you are planning on doing.
 That way you can get more guidance and support from GitLab team members.
 
-If you're not sure what to work on, you can:
-
-- View issues with the
-  [`~Seeking community contributions` label](../labels/index.md#label-for-community-contributors).
-- Optimize tests. Use [RSpec profiling statistics](https://gitlab-org.gitlab.io/rspec_profiling_stats/)
-  to identify the slowest tests. These tests are good candidates for improving and checking if any
-  [best practices](../testing_guide/best_practices.md) can speed them up.
+If you're not sure what to work on, you can [view issues](https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=quick%20win&label_name%5B%5D=Seeking%20community%20contributions&first_page_size=100) with the
+  `~Seeking community contributions` and `~quick win` label.
 
 When you find an issue, leave a comment on the issue you want to work on.
 This helps the GitLab team and members of the wider GitLab community know that you will be working on that issue.
@@ -65,8 +60,9 @@ To write and test your code, you will use the GitLab Development Kit.
      consider doing so with an empty rails app and port it to GDK after.
 
    - To run a pre-configured GDK instance in the cloud, use [GDK with Gitpod](../../integration/gitpod.md).
-     From a project's repository, select the caret (angle-down) next to **Web IDE**,
-     and select **Gitpod** from the list.
+     From a project repository:
+       1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+       1. In the upper right, select **Edit > Gitpod**.
 1. If you want to contribute to the [website](https://about.gitlab.com/) or the [handbook](https://about.gitlab.com/handbook/),
    go to the footer of any page and select **Edit in Web IDE** to open the [Web IDE](../../user/project/web_ide/index.md).
 
@@ -89,7 +85,7 @@ For details, see the [merge request workflow](merge_request_workflow.md).
 1. When you create a merge request, the [`@gitlab-bot`](https://gitlab.com/gitlab-bot) automatically applies
    the ["~Community contribution"](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#ensure-quick-feedback-for-community-contributions) label.
 1. In the 24-48 hours after you create the merge request, a
-   [Merge Request Coach](https://about.gitlab.com/handbook/marketing/community-relations/contributor-success/merge-request-coach-lifecycle.html)
+   [Merge Request Coach](https://about.gitlab.com/handbook/marketing/developer-relations/contributor-success/merge-request-coach-lifecycle.html)
    will review your merge request and apply stage, group, and type labels.
 1. If a merge request was not automatically assigned, ask for a review by typing `@gitlab-bot ready` in a comment.
    If your code has not been assigned a reviewer within two working days of its initial submission, you can ask
@@ -144,15 +140,10 @@ Lastly, keep the following in mind when submitting merge requests:
 - For the criteria for closing issues, see [the Issue Triage handbook page](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#outdated-issues).
 - For the criteria for closing merge requests, see [the Merge Request Workflow](merge_request_workflow.md).
 
-## Getting an Enterprise Edition license
-
-GitLab has two development platforms:
-
-- GitLab Community Edition (CE), our free and open source edition.
-- GitLab Enterprise Edition (EE), which is our commercial edition.
+## Contributing to Premium/Ultimate features with an Enterprise Edition license
 
-If you need a license for contributing to an EE-feature, see
-[relevant information](https://about.gitlab.com/handbook/marketing/community-relations/contributor-success/community-contributors-workflows.html#contributing-to-the-gitlab-enterprise-edition-ee).
+If you would like to work on GitLab features that are within a paid tier, also known as the code that lives in the [EE folder](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee), it requires a GitLab Enterprise Edition license.
+Please request an Enterprise Edition Developers License according to the [documented process](https://about.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows.html#contributing-to-the-gitlab-enterprise-edition-ee).
 
 ## Get help
 
diff --git a/doc/development/database/adding_database_indexes.md b/doc/development/database/adding_database_indexes.md
index 7b29b1b14de..23a12413975 100644
--- a/doc/development/database/adding_database_indexes.md
+++ b/doc/development/database/adding_database_indexes.md
@@ -429,7 +429,7 @@ Use the asynchronous index helpers on your local environment to test changes for
 For very large tables, index destruction can be a challenge to manage.
 While `remove_concurrent_index` removes indexes in a way that does not block
 ordinary traffic, it can still be problematic if index destruction runs for
-during `autovacuum`. Necessary database operations like `autovacuum` cannot run, and
+many hours. Necessary database operations like `autovacuum` cannot run, and
 the deployment process on GitLab.com is blocked while waiting for index
 destruction to finish.
 
diff --git a/doc/development/database/batched_background_migrations.md b/doc/development/database/batched_background_migrations.md
index 6a6b43e52a0..3e54a78757a 100644
--- a/doc/development/database/batched_background_migrations.md
+++ b/doc/development/database/batched_background_migrations.md
@@ -42,7 +42,159 @@ Background migrations can help when:
 - You should use the [generator](#generator) to create batched background migrations,
   so that required files are created by default.
 
-## Isolation
+## How it works
+
+Batched background migrations (BBM) are subclasses of
+`Gitlab::BackgroundMigration::BatchedMigrationJob` that define a `perform` method.
+As the first step, a regular migration creates a `batched_background_migrations`
+record with the BBM class and the required arguments. By default,
+`batched_background_migrations` is in an active state, and those are picked up
+by the Sidekiq worker to execute the actual batched migration.
+
+All migration classes must be defined in the namespace `Gitlab::BackgroundMigration`. Place the files
+in the directory `lib/gitlab/background_migration/`.
+
+### Execution mechanism
+
+Batched background migrations are picked from the queue in the order they are enqueued. Multiple migrations are fetched
+and executed in parallel, as long they are in active state and do not target the same database table.
+The default number of migrations processed in parallel is 2, for GitLab.com this limit is configured to 4.
+Once migration is picked for execution, a job is created for the specific batch. After each job execution, migration's
+batch size may be increased or decreased, based on the performance of the last 20 jobs.
+
+```plantuml
+@startuml
+hide empty description
+skinparam ConditionEndStyle hline
+left to right direction
+rectangle "Batched Background Migration Queue" as migrations {
+  rectangle "Migration N (active)" as migrationn
+  rectangle "Migration 1 (completed)" as migration1
+  rectangle "Migration 2 (active)" as migration2
+  rectangle "Migration 3 (on hold)" as migration3
+  rectangle "Migration 4 (active)" as migration4
+  migration1 -[hidden]> migration2
+  migration2 -[hidden]> migration3
+  migration3 -[hidden]> migration4
+  migration4 -[hidden]> migrationn
+}
+rectangle "Execution Workers" as workers {
+ rectangle "Execution Worker 1 (busy)" as worker1
+ rectangle "Execution Worker 2 (available)" as worker2
+ worker1 -[hidden]> worker2
+}
+migration2 --> [Scheduling Worker]
+migration4 --> [Scheduling Worker]
+[Scheduling Worker] --> worker2
+@enduml
+```
+
+Soon as a worker is available, the BBM is processed by the runner.
+
+```plantuml
+@startuml
+hide empty description
+start
+rectangle Runner {
+  :Migration;
+  if (Have reached batching bounds?) then (Yes)
+    if (Have jobs to retry?) then (Yes)
+      :Fetch the batched job;
+    else (No)
+      :Finish active migration;
+      stop
+    endif
+  else (No)
+    :Create a batched job;
+  endif
+  :Execute batched job;
+  :Evaluate DB health;
+  note right: Checks for table autovacuum, Patroni Apdex, Write-ahead logging
+  if (Evaluation signs to stop?) then (Yes)
+    :Put migration on hold;
+  else (No)
+    :Optimize migration;
+  endif
+}
+@enduml
+```
+
+### Idempotence
+
+Batched background migrations are executed in a context of a Sidekiq process.
+The usual Sidekiq rules apply, especially the rule that jobs should be small
+and idempotent. Make sure that in case that your migration job is retried, data
+integrity is guaranteed.
+
+See [Sidekiq best practices guidelines](https://github.com/mperham/sidekiq/wiki/Best-Practices)
+for more details.
+
+### Migration optimization
+
+After each job execution, a verification takes place to check if the migration can be optimized.
+The optimization underlying mechanic is based on the concept of time efficiency. It calculates
+the exponential moving average of time efficiencies for the last N jobs and updates the batch
+size of the batched background migration to its optimal value.
+
+### Job retry mechanism
+
+The batched background migrations retry mechanism ensures that a job is executed again in case of failure.
+The following diagram shows the different stages of our retry mechanism:
+
+```plantuml
+@startuml
+hide empty description
+note as N1
+  can_split?:
+  the failure is due to a query timeout
+end note
+    [*] --> Running
+Running --> Failed
+note on link
+  if number of retries <= MAX_ATTEMPTS
+end note
+Running --> Succeeded
+Failed --> Running
+note on link
+  if number of retries > MAX_ATTEMPTS
+  and can_split? == true
+  then two jobs with smaller
+  batch size will be created
+end note
+Failed --> [*]
+Succeeded --> [*]
+@enduml
+```
+
+- `MAX_ATTEMPTS` is defined in the [`Gitlab::Database::BackgroundMigration`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/database/background_migration/batched_job.rb)
+  class.
+- `can_split?` is defined in the [`Gitlab::Database::BatchedJob`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/database/background_migration/batched_job.rb) class.
+
+### Failed batched background migrations
+
+The whole batched background migration is marked as `failed`
+(`/chatops run batched_background_migrations status MIGRATION_ID` shows
+the migration as `failed`) if any of the following is true:
+
+- There are no more jobs to consume, and there are failed jobs.
+- More than [half of the jobs failed since the background migration was started](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/database/background_migration/batched_migration.rb#L160).
+
+### Throttling batched migrations
+
+Because batched migrations are update heavy and there were few incidents in the past because of the heavy load from migrations while the database was underperforming, a throttling mechanism exists to mitigate them.
+
+These database indicators are checked to throttle a migration. On getting a
+stop signal, the migration is paused for a set time (10 minutes):
+
+- WAL queue pending archival crossing a threshold.
+- Active autovacuum on the tables on which the migration works on.
+- Patroni apdex SLI dropping below the SLO.
+
+It's an ongoing effort to add more indicators to further enhance the
+database health check framework. For more details, see
+[epic 7594](https://gitlab.com/groups/gitlab-org/-/epics/7594).
+
+### Isolation
 
 Batched background migrations must be isolated and cannot use application code (for example,
 models defined in `app/models` except the `ApplicationRecord` classes).
@@ -96,16 +248,6 @@ ApplicationRecord.connection.execute("SELECT * FROM projects")
 ActiveRecord::Base.connection.execute("SELECT * FROM projects")
 ```
 
-## Idempotence
-
-Batched background migrations are executed in a context of a Sidekiq process.
-The usual Sidekiq rules apply, especially the rule that jobs should be small
-and idempotent. Make sure that in case that your migration job is retried, data
-integrity is guaranteed.
-
-See [Sidekiq best practices guidelines](https://github.com/mperham/sidekiq/wiki/Best-Practices)
-for more details.
-
 ## Batched background migrations for EE-only features
 
 All the background migration classes for EE-only features should be present in GitLab FOSS.
@@ -118,12 +260,6 @@ Background migration classes for EE-only features that use job arguments should
 in the GitLab FOSS class. This is required to prevent job arguments validation from failing when
 migration is scheduled in GitLab FOSS context.
 
-Batched Background migrations are simple classes that define a `perform` method. A
-Sidekiq worker then executes such a class, passing any arguments to it. All
-migration classes must be defined in the namespace
-`Gitlab::BackgroundMigration`. Place the files in the directory
-`lib/gitlab/background_migration/`.
-
 ## Queueing
 
 Queueing a batched background migration should be done in a post-deployment
@@ -148,49 +284,6 @@ Make sure the newly-created data is either migrated, or
 saved in both the old and new version upon creation. Removals in
 turn can be handled by defining foreign keys with cascading deletes.
 
-### Job retry mechanism
-
-The batched background migrations retry mechanism ensures that a job is executed again in case of failure.
-The following diagram shows the different stages of our retry mechanism:
-
-```plantuml
-@startuml
-hide empty description
-note as N1
-  can_split?:
-  the failure is due to a query timeout
-end note
-[*] --> Running
-Running --> Failed
-note on link
-  if number of retries <= MAX_ATTEMPTS
-end note
-Running --> Succeeded
-Failed --> Running
-note on link
-  if number of retries > MAX_ATTEMPTS
-  and can_split? == true
-  then two jobs with smaller
-  batch size will be created
-end note
-Failed --> [*]
-Succeeded --> [*]
-@enduml
-```
-
-- `MAX_ATTEMPTS` is defined in the [`Gitlab::Database::BackgroundMigration`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/database/background_migration/batched_job.rb)
-class.
-- `can_split?` is defined in the [`Gitlab::Database::BatchedJob`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/database/background_migration/batched_job.rb) class.
-
-### Failed batched background migrations
-
-The whole batched background migration is marked as `failed`
-(`/chatops run batched_background_migrations status MIGRATION_ID` will show
-the migration as `failed`) if any of the following are true:
-
-- There are no more jobs to consume, and there are failed jobs.
-- More than [half of the jobs failed since the background migration was started](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/database/background_migration/batched_migration.rb).
-
 ### Requeuing batched background migrations
 
 If one of the batched background migrations contains a bug that is fixed in a patch
@@ -831,6 +924,7 @@ Let's assume that a batched background migration failed on a particular batch on
 Fortunately you can leverage our [database migration pipeline](database_migration_pipeline.md) to rerun a particular batch with additional logging and/or fix to see if it solves the problem.
 
 <!-- vale gitlab.Substitutions = NO -->
+
 For an example see [Draft: Test PG::CardinalityViolation fix](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110910) but make sure to read the entire section.
 
 To do that, you need to:
@@ -872,7 +966,7 @@ end
 
 #### 3. Apply a workaround for our migration helpers (optional)
 
-If your batched background migration touches tables from a schema other than the one you specified by using `restrict_gitlab_migration` helper (example: the scheduling migration has `restrict_gitlab_migration gitlab_schema: :gitlab_main` but the background job uses tables from the `:gitlab_ci` schema) then the migration will fail. To prevent that from happening you'll have to monkey patch database helpers so they don't fail the testing pipeline job:
+If your batched background migration touches tables from a schema other than the one you specified by using `restrict_gitlab_migration` helper (example: the scheduling migration has `restrict_gitlab_migration gitlab_schema: :gitlab_main` but the background job uses tables from the `:gitlab_ci` schema) then the migration will fail. To prevent that from happening you must to monkey patch database helpers so they don't fail the testing pipeline job:
 
 1. Add the schema names to [`RestrictGitlabSchema`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/database/migration_helpers/restrict_gitlab_schema.rb#L57)
 
diff --git a/doc/development/database/clickhouse/index.md b/doc/development/database/clickhouse/index.md
index 032e4f5f6ee..8ca6240e0f1 100644
--- a/doc/development/database/clickhouse/index.md
+++ b/doc/development/database/clickhouse/index.md
@@ -117,7 +117,7 @@ Files: `config.xml`
 | Topic | Security Requirement | Reason |
 | ----- | -------------------- | ------ |
 | Permissions | ClickHouse runs by default with the `clickhouse` user. Running as `root` is never needed. Use the principle of least privileges for the folders: `/etc/clickhouse-server`, `/var/lib/clickhouse`, `/var/log/clickhouse-server`. These folders must belong to the `clickhouse` user and group, and no other system user must have access to them. | Default passwords, ports and rules are "open doors". ([Fail securely & use secure defaults](https://about.gitlab.com/handbook/security/architecture/#fail-securely--use-secure-defaults) principle) |
-| Encryption | Use an encrypted storage for logs and data if RED data is processed. On Kubernetes, the [StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes/) used must be encrypted. | Encrypt data at rest. ([Defense in depth](https://about.gitlab.com/handbook/security/architecture/#implement-defense-in-depth)) |
+| Encryption | Use an encrypted storage for logs and data if RED data is processed. On Kubernetes, the [StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes/) used must be encrypted. [GKE](https://cloud.google.com/blog/products/containers-kubernetes/exploring-container-security-use-your-own-keys-to-protect-your-data-on-gke) and [EKS](https://aws.github.io/aws-eks-best-practices/security/docs/data/) encrypt all data at rest already. In this case, using your own key is best but not required. | Encrypt data at rest. ([Defense in depth](https://about.gitlab.com/handbook/security/architecture/#implement-defense-in-depth)) |
 
 ### Logging
 
diff --git a/doc/development/database/database_dictionary.md b/doc/development/database/database_dictionary.md
index 84b76ddc34c..70691d8746c 100644
--- a/doc/development/database/database_dictionary.md
+++ b/doc/development/database/database_dictionary.md
@@ -18,7 +18,7 @@ For the `geo` database, the dictionary files are stored under `ee/db/geo/docs/`.
 ## Example dictionary file
 
 ```yaml
-----
+---
 table_name: terraform_states
 classes:
 - Terraform::State
diff --git a/doc/development/database/foreign_keys.md b/doc/development/database/foreign_keys.md
index 25b3d815d7a..5dda3dd55a3 100644
--- a/doc/development/database/foreign_keys.md
+++ b/doc/development/database/foreign_keys.md
@@ -195,5 +195,5 @@ end
 ```
 
 Using a foreign key as primary key saves space but can make
-[batch counting](../service_ping/implement.md#batch-counters) in [Service Ping](../service_ping/index.md) less efficient.
+[batch counting](../internal_analytics/service_ping/implement.md#batch-counters) in [Service Ping](../service_ping/index.md) less efficient.
 Consider using a regular `id` column if the table is relevant for Service Ping.
diff --git a/doc/development/database/query_performance.md b/doc/development/database/query_performance.md
index 10ab726940a..77067e2979d 100644
--- a/doc/development/database/query_performance.md
+++ b/doc/development/database/query_performance.md
@@ -22,7 +22,7 @@ When you are optimizing your SQL queries, there are two dimensions to pay attent
 | Concurrent operations in a migration      | `5min`             | Concurrent operations do not block the database, but they block the GitLab update. This includes operations such as `add_concurrent_index` and `add_concurrent_foreign_key`.                                                                                                                                               |
 | Concurrent operations in a post migration | `20min`            | Concurrent operations do not block the database, but they block the GitLab post update process. This includes operations such as `add_concurrent_index` and `add_concurrent_foreign_key`. If index creation exceeds 20 minutes, consider [async index creation](adding_database_indexes.md#create-indexes-asynchronously). |
 | Background migrations                     | `1s`               |                                                                                                                                                                                                                                                                                                                            |
-| Service Ping                              | `1s`               | See the [Service Ping docs](../service_ping/implement.md) for more details.                                                                                                                                                                                                                                                |
+| Service Ping                              | `1s`               | See the [Service Ping docs](../internal_analytics/service_ping/implement.md) for more details.                                                                                                                                                                                                                                                |
 
 - When analyzing your query's performance, pay attention to if the time you are seeing is on a [cold or warm cache](#cold-and-warm-cache). These guidelines apply for both cache types.
 - When working with batched queries, change the range and batch size to see how it effects the query timing and caching.
diff --git a/doc/development/database_review.md b/doc/development/database_review.md
index 0e34e550098..76e9add215b 100644
--- a/doc/development/database_review.md
+++ b/doc/development/database_review.md
@@ -27,7 +27,7 @@ A database review is required for:
   database review.
 - Changes in Service Data metrics that use `count`, `distinct_count`, `estimate_batch_distinct_count` and `sum`.
   These metrics could have complex queries over large tables.
-  See the [Product Intelligence Guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
+  See the [Analytics Instrumentation Guide](https://about.gitlab.com/handbook/product/analytics-instrumentation-guide/)
   for implementation details.
 
 A database reviewer is expected to look out for overly complex
diff --git a/doc/development/deprecation_guidelines/index.md b/doc/development/deprecation_guidelines/index.md
index bc14b0f127c..e81bed07da9 100644
--- a/doc/development/deprecation_guidelines/index.md
+++ b/doc/development/deprecation_guidelines/index.md
@@ -9,54 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 This page includes information about how and when to remove or make breaking changes
 to GitLab features.
 
-## Terminology
-
-<!--
-If updating these definitions, be sure to update them in the handbook as well:
-https://about.gitlab.com/handbook/product/gitlab-the-product/#definitions
--->
-
-**Deprecation**:
-
-- Required before ending support for a feature or removing a feature.
-- Feature not recommended for use.
-- Development restricted to Priority 1 / Severity 1 bug fixes.
-- Will be removed in a future major release.
-- Begins after a deprecation announcement outlining an end-of-support or removal date.
-- Ends after the end-of-support date or removal date has passed.
-
-**End of Support**:
-
-- Optional step before removal.
-- Feature usage strongly discouraged.
-- No support or fixes provided.
-- No longer tested internally.
-- Will be removed in a future major release.
-- Begins after an end-of-support date has passed.
-
-[Announcing an End of Support period](https://about.gitlab.com/handbook/marketing/blog/release-posts/#announcing-an-end-of-support-period)
-should only be used in special circumstances and is not recommended for general use.
-Most features should be deprecated and then removed.
-
-**Removal**:
-
-- Feature usage impossible.
-- Feature no longer supported (if End of Support period hasn't already been announced).
-- Happens in a major release in line with our
-  [semantic versioning policy](../../policy/maintenance.md).
-- Begins after removal date has passed.
-
-**Breaking change**:
-
-A "breaking change" is any change that requires users to make a corresponding change to their code, settings, or workflow. "Users" might be humans, API clients, or even code classes that "use" another class. Examples of breaking changes include:
-
-- Removing a user-facing feature without a replacement/workaround.
-- Changing the definition of an existing API (by doing things like re-naming query parameters or changing routes).
-- Removing a public method from a code class.
-
-A breaking change can be considered major if it affects many users, or represents a significant change in behavior.
-
-![Deprecation, End of Support, Removal process](img/deprecation_removal_process.png)
+For details about the terms used on this page, see [the terminology](../../update/terminology.md).
 
 ## When can a feature be deprecated?
 
@@ -68,6 +21,8 @@ Do not include the deprecation announcement in the merge request that introduces
 Use a separate MR to create a deprecation entry. For steps to create a deprecation entry, see
 [Deprecations](https://about.gitlab.com/handbook/marketing/blog/release-posts/#deprecations).
 
+![Deprecation, End of Support, Removal process](img/deprecation_removal_process.png)
+
 ## How are Community Contributions to a deprecated feature handled?
 
 Development on deprecated features is restricted to Priority 1 / Severity 1 bug fixes. Any community contributions to deprecated features are unlikely to be prioritized during milestone planning.
diff --git a/doc/development/documentation/alpha_beta.md b/doc/development/documentation/alpha_beta.md
index d421aae3cb9..a6f756f93ae 100644
--- a/doc/development/documentation/alpha_beta.md
+++ b/doc/development/documentation/alpha_beta.md
@@ -7,7 +7,7 @@ group: unassigned
 # Documenting Experiment and Beta features
 
 Some features are not generally available and are instead considered
-[Experiment or Beta](../../policy/alpha-beta-support.md).
+[Experiment or Beta](../../policy/experiment-beta-support.md).
 
 When you document a feature in one of these three statuses:
 
@@ -25,7 +25,7 @@ For example:
 ```markdown
 ## Great new feature (Experiment)
 
-> [Introduced](link) in GitLab 15.10. This feature is an [Experiment](<link_to>/policy/alpha-beta-support.md).
+> [Introduced](link) in GitLab 15.10. This feature is an [Experiment](<link_to>/policy/experiment-beta-support.md).
 
 FLAG:
 On self-managed GitLab, by default this feature is not available.
@@ -34,7 +34,7 @@ On GitLab.com, this feature is not available. This feature is not ready for prod
 
 Use this great new feature when you need to do this new thing.
 
-This feature is an [Experiment](<link_to>/policy/alpha-beta-support.md). To join
+This feature is an [Experiment](<link_to>/policy/experiment-beta-support.md). To join
 the list of users testing this feature, do this thing. If you find a bug,
 [open an issue](link).
 ```
diff --git a/doc/development/documentation/contribute.md b/doc/development/documentation/contribute.md
index 8b08743c6e9..d3b7d9a4d93 100644
--- a/doc/development/documentation/contribute.md
+++ b/doc/development/documentation/contribute.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Contribute to the GitLab documentation
 
-Everyone is welcome to update the GitLab documentation!
+Everyone is welcome to update the GitLab documentation.
 
 ## Work without an issue
 
@@ -50,9 +50,7 @@ When you are ready to update the documentation:
 1. In your fork, find the documentation page in the `\doc` directory.
 1. If you know Git, make your changes and open a merge request.
    If not, follow these steps:
-   1. In the upper-right corner, select **Edit** if it is visible.
-      If it is not, select the down arrow (**{chevron-lg-down}**) next to
-      **Open in Web IDE** or **Gitpod**, and select **Edit**.
+   1. In the upper right, select **Edit > Edit single file**.
    1. In the **Commit message** text box, enter a commit message.
       Use 3-5 words, start with a capital letter, and do not end with a period.
    1. Select **Commit changes**.
diff --git a/doc/development/documentation/feature_flags.md b/doc/development/documentation/feature_flags.md
index 854faa839ef..5cee300481b 100644
--- a/doc/development/documentation/feature_flags.md
+++ b/doc/development/documentation/feature_flags.md
@@ -17,7 +17,7 @@ When the state of a feature flag changes, the developer who made the change
 
 Every feature introduced to the codebase, even if it's behind a disabled feature flag,
 must be documented. For more information, see
-[the discussion that led to this decision](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47917#note_459984428). [Experiment or Beta](../../policy/alpha-beta-support.md) features are usually behind a feature flag, and must also be documented. For more information, see [Document Experiment or Beta features](alpha_beta.md).
+[the discussion that led to this decision](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47917#note_459984428). [Experiment or Beta](../../policy/experiment-beta-support.md) features are usually behind a feature flag, and must also be documented. For more information, see [Document Experiment or Beta features](alpha_beta.md).
 
 When the feature is [implemented in multiple merge requests](../feature_flags/index.md#feature-flags-in-gitlab-development),
 discuss the plan with your technical writer.
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 6811b3d6584..761dde839c1 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -259,8 +259,8 @@ is inside `_()` so it can be translated:
   link:
 
   ```haml
-  - link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: help_page_path('user/permissions') }
-  %p= _("This is a text describing the option/feature in a sentence. %{link_start}Learn more.%{link_end}").html_safe % { link_start: link_start, link_end: '</a>'.html_safe }
+  - link = link_to('', help_page_path('user/permissions'), target: '_blank', rel: 'noopener noreferrer')
+  %p= safe_format(_("This is a text describing the option/feature in a sentence. %{link_start}Learn more.%{link_end}"), tag_pair(link, :link_start, :link_end))
   ```
 
 - Using a button link. Useful in places where text would be out of context with
@@ -290,7 +290,7 @@ be translated:
 
 ```ruby
 docs_link = link_to _('Learn more.'), help_page_url('user/permissions', anchor: 'anchor-link'), target: '_blank', rel: 'noopener noreferrer'
-_('This is a text describing the option/feature in a sentence. %{docs_link}').html_safe % { docs_link: docs_link.html_safe }
+safe_format(_('This is a text describing the option/feature in a sentence. %{docs_link}'), docs_link: docs_link)
 ```
 
 In cases where you need to generate a link from outside of views/helpers, where the `link_to` and `help_page_url` methods are not available, use the following code block
@@ -298,7 +298,7 @@ as a guide where the methods are fully qualified:
 
 ```ruby
 docs_link = ActionController::Base.helpers.link_to _('Learn more.'), Rails.application.routes.url_helpers.help_page_url('user/permissions', anchor: 'anchor-link'), target: '_blank', rel: 'noopener noreferrer'
-_('This is a text describing the option/feature in a sentence. %{docs_link}').html_safe % { docs_link: docs_link.html_safe }
+safe_format(_('This is a text describing the option/feature in a sentence. %{docs_link}'), docs_link: docs_link)
 ```
 
 Do not use `include ActionView::Helpers::UrlHelper` just to make the `link_to` method available as you might see in some existing code. Read more in
diff --git a/doc/development/documentation/restful_api_styleguide.md b/doc/development/documentation/restful_api_styleguide.md
index 93afbf7e6dd..c39c7c02108 100644
--- a/doc/development/documentation/restful_api_styleguide.md
+++ b/doc/development/documentation/restful_api_styleguide.md
@@ -80,7 +80,8 @@ response attributes:
 Example request:
 
 ```shell
-curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/endpoint?parameters"
+curl --header "PRIVATE-TOKEN: <your_access_token>" \
+  --url "https://gitlab.example.com/api/v4/endpoint?parameters"
 ```
 
 Example response:
@@ -201,9 +202,13 @@ For information about writing attribute descriptions, see the [GraphQL API descr
 - Wherever needed use this personal access token: `<your_access_token>`.
 - Always put the request first. `GET` is the default so you don't have to
   include it.
-- Wrap the URL in double quotes (`"`).
+- Use long option names (`--header` instead of `-H`) for legibility. (Tested in
+  [`scripts/lint-doc.sh`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/scripts/lint-doc.sh).)
+- Declare URLs with the `--url` parameter, and wrap the URL in double quotes (`"`).
 - Prefer to use examples using the personal access token and don't pass data of
   username and password.
+- For legibility, use the <code>&#92;</code> character and indentation to break long single-line
+  commands apart into multiple lines.
 
 | Methods                                         | Description                                            |
 |:------------------------------------------------|:-------------------------------------------------------|
@@ -227,7 +232,8 @@ relevant style guide sections on [Fake user information](styleguide/index.md#fak
 Get the details of a group:
 
 ```shell
-curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/gitlab-org"
+curl --header "PRIVATE-TOKEN: <your_access_token>" \
+  --url "https://gitlab.example.com/api/v4/groups/gitlab-org"
 ```
 
 ### cURL example with parameters passed in the URL
@@ -235,7 +241,8 @@ curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/a
 Create a new project under the authenticated user's namespace:
 
 ```shell
-curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects?name=foo"
+curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
+  --url "https://gitlab.example.com/api/v4/projects?name=foo"
 ```
 
 ### Post data using cURL's `--data`
@@ -245,7 +252,9 @@ can use cURL's `--data` option. The example below will create a new project
 `foo` under the authenticated user's namespace.
 
 ```shell
-curl --data "name=foo" --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects"
+curl --data "name=foo" \
+  --header "PRIVATE-TOKEN: <your_access_token>" \
+  --url "https://gitlab.example.com/api/v4/projects"
 ```
 
 ### Post data using JSON content
@@ -254,20 +263,23 @@ This example creates a new group. Be aware of the use of single (`'`) and double
 (`"`) quotes.
 
 ```shell
-curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --header "Content-Type: application/json" \
-     --data '{"path": "my-group", "name": "My group"}' "https://gitlab.example.com/api/v4/groups"
+curl --request POST \
+  --header "PRIVATE-TOKEN: <your_access_token>" \
+  --header "Content-Type: application/json" \
+  --data '{"path": "my-group", "name": "My group"}' \
+  --url "https://gitlab.example.com/api/v4/groups"
 ```
 
 For readability, you can also set up the `--data` by using the following format:
 
 ```shell
 curl --request POST \
---url "https://gitlab.example.com/api/v4/groups" \
---header "content-type: application/json" \
---header "PRIVATE-TOKEN: <your_access_token>" \
---data '{
-  "path": "my-group",
-  "name": "My group"
+  --url "https://gitlab.example.com/api/v4/groups" \
+  --header "content-type: application/json" \
+  --header "PRIVATE-TOKEN: <your_access_token>" \
+  --data '{
+    "path": "my-group",
+    "name": "My group"
 }'
 ```
 
@@ -277,8 +289,11 @@ Instead of using JSON or URL-encoding data, you can use `multipart/form-data` wh
 properly handles data encoding:
 
 ```shell
-curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --form "title=ssh-key" \
-     --form "key=ssh-rsa AAAAB3NzaC1yc2EA..." "https://gitlab.example.com/api/v4/users/25/keys"
+curl --request POST \
+  --header "PRIVATE-TOKEN: <your_access_token>" \
+  --form "title=ssh-key" \
+  --form "key=ssh-rsa AAAAB3NzaC1yc2EA..." \
+  --url "https://gitlab.example.com/api/v4/users/25/keys"
 ```
 
 The above example is run by and administrator and will add an SSH public key
@@ -292,7 +307,9 @@ contains spaces in its title. Observe how spaces are escaped using the `%20`
 ASCII code.
 
 ```shell
-curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/42/issues?title=Hello%20GitLab"
+curl --request POST \
+  --header "PRIVATE-TOKEN: <your_access_token>" \
+  --url "https://gitlab.example.com/api/v4/projects/42/issues?title=Hello%20GitLab"
 ```
 
 Use `%2F` for slashes (`/`).
@@ -304,6 +321,9 @@ exclude specific users when requesting a list of users for a project, you would
 do something like this:
 
 ```shell
-curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" --data "skip_users[]=<user_id>" \
-     --data "skip_users[]=<user_id>" "https://gitlab.example.com/api/v4/projects/<project_id>/users"
+curl --request PUT \
+  --header "PRIVATE-TOKEN: <your_access_token>"
+  --data "skip_users[]=<user_id>" \
+  --data "skip_users[]=<user_id>" \
+  --url "https://gitlab.example.com/api/v4/projects/<project_id>/users"
 ```
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index 00307583be4..6a56d824e35 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -522,6 +522,11 @@ When using code block style:
   [list of supported languages and lexers](https://github.com/rouge-ruby/rouge/wiki/List-of-supported-languages-and-lexers)
   for available syntax highlighters. Use `plaintext` if no better hint is available.
 
+#### cURL commands in code blocks
+
+See [cURL commands](../restful_api_styleguide.md#curl-commands) for information
+about styling cURL commands.
+
 ## Lists
 
 - Do not use a period if the phrase is not a full sentence.
@@ -640,15 +645,27 @@ To keep tables accessible and scannable, tables should not have any
 empty cells. If there is no otherwise meaningful value for a cell, consider entering
 **N/A** for 'not applicable' or **None**.
 
-To help tables be easier to maintain, consider adding additional spaces to the
-column widths to make them consistent. For example:
+To help keep tables easier to maintain, you can:
 
-```markdown
-| App name | Description          | Requirements   |
-|:---------|:---------------------|:---------------|
-| App 1    | Description text 1.  | Requirements 1 |
-| App 2    | Description text 2.  | None           |
-```
+- Add additional spaces to make the column widths consistent. For example:
+
+  ```markdown
+  | App name | Description         | Requirements   |
+  |----------|---------------------|----------------|
+  | App 1    | Description text 1. | Requirements 1 |
+  | App 2    | Description text 2. | None           |
+  ```
+
+- Skip the additional spaces in the rightmost column for tables that are very wide.
+  For example:
+
+  ```markdown
+  | Setting   | Default | Description |
+  |-----------|---------|-------------|
+  | Setting 1 | `1000`  | A short description. |
+  | Setting 2 | `2000`  | A long description that would make the table too wide and add too much whitespace if every cell in this column was aligned. |
+  | Setting 3 | `0`     | Another short description. |
+  ```
 
 Consider installing a plugin or extension in your editor for formatting tables:
 
@@ -656,6 +673,16 @@ Consider installing a plugin or extension in your editor for formatting tables:
 - [Markdown Table Formatter](https://packagecontrol.io/packages/Markdown%20Table%20Formatter) for Sublime Text
 - [Markdown Table Formatter](https://atom.io/packages/markdown-table-formatter) for Atom
 
+### Updates to existing tables
+
+When you add or edit rows in an existing table, the cells in the new rows might be wider.
+If you realign the columns to account for the width, the diff becomes difficult to read,
+because the entire table shows as modified.
+
+Markdown tables naturally fall out of alignment over time, but still render correctly
+on `docs.gitlab.com`. The technical writing team can realign cells the next time
+the page is refactored.
+
 ### Table headings
 
 Use sentence case for table headings. For example, `Keyword value` or `Project name`.
@@ -681,10 +708,10 @@ For the footnotes below the table, use a bold number followed by a sentence.
 For example:
 
 ```markdown
-| App name | Description                      |
-|:---------|:---------------------------------|
-| App A    | Description text. <sup>1</sup>   |
-| App B    | Description text. <sup>2</sup>   |
+| App name | Description                    |
+|:---------|:-------------------------------|
+| App A    | Description text. <sup>1</sup> |
+| App B    | Description text. <sup>2</sup> |
 
 1. This is the footnote.
 1. This is the other footnote.
@@ -692,10 +719,10 @@ For example:
 
 This text renders this output:
 
-| App name | Description                      |
-|:---------|:---------------------------------|
-| App A    | Description text. <sup>1</sup>   |
-| App B    | Description text. <sup>2</sup>   |
+| App name | Description                    |
+|:---------|:-------------------------------|
+| App A    | Description text. <sup>1</sup> |
+| App B    | Description text. <sup>2</sup> |
 
 1. This is the footnote.
 1. This is the other footnote.
@@ -834,7 +861,7 @@ Sometimes they are more precise and will be maintained more actively.
 
 For each external link you add, weigh the customer benefit with the maintenance difficulties.
 
-### Links requiring permissions
+### Links that require permissions
 
 Don't link directly to:
 
@@ -842,23 +869,27 @@ Don't link directly to:
 - Project features that require [special permissions](../../../user/permissions.md)
   to view.
 
-These fail for:
+These links fail for:
 
 - Those without sufficient permissions.
 - Automated link checkers.
 
-Instead:
+If you must use one of these links:
 
-- To reduce confusion, mention in the text that the information is either:
-  - Contained in a confidential issue.
-  - Requires special permission to a project to view.
-- Provide a link in back ticks (`` ` ``) so that those with access to the issue
-  can navigate to it.
+- If the link is to a confidential issue, mention that the issue is visible only to GitLab team members, as in the first example.
+- If the link requires a specific role or permissions, mention that information, as in the second example.
+- Put the link in backticks, so that it does not cause link checkers to fail.
 
-Example:
+Examples:
 
 ```markdown
-For more information, see the [confidential issue](../../../user/project/issues/confidential_issues.md) `https://gitlab.com/gitlab-org/gitlab-foss/-/issues/<issue_number>`.
+GitLab team members can view more information in this confidential issue:
+`https://gitlab.com/gitlab-org/gitlab/-/issues/<issue_number>`
+```
+
+```markdown
+Users with the Maintainer role for the project can use the pipeline editor:
+`https://gitlab.com/gitlab-org/gitlab/-/ci/editor`
 ```
 
 ### Link to specific lines of code
@@ -894,10 +925,10 @@ When documenting how to navigate through the GitLab UI:
 Use these terms when referring to the main GitLab user interface
 elements:
 
-- **Top bar**: This is the top bar that spans the width of the user interface.
-  It includes the menu, the GitLab logo, search field, counters, and the user's avatar.
 - **Left sidebar**: This is the navigation sidebar on the left of the user
-  interface, specific to the project or group.
+  interface.
+  - Do not use the phrase `context switcher` or `switch contexts`. Instead, try to direct the user to the exact location with a set of repeatable steps.
+  - Do not use the phrase `the **Explore** menu` or `the **Your work** sidebar`. Instead, use `the left sidebar`.
 - **Right sidebar**: This is the navigation sidebar on the right of the user
   interface, specific to the open issue, merge request, or epic.
 
@@ -913,51 +944,57 @@ To be consistent, use these templates when you write navigation steps in a task
 To open project settings:
 
 ```markdown
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 ```
 
 To open group settings:
 
 ```markdown
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 ```
 
 To open either project or group settings:
 
 ```markdown
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 ```
 
 To create a project:
 
 ```markdown
-1. On the top bar, select **Create new... > New project**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New project/repository**.
 ```
 
 To create a group:
 
 ```markdown
-1. On the top bar, select **Create new... > New group**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New group**.
 ```
 
 To open the Admin Area:
 
 ```markdown
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+```
+
+To open the **Your work** menu item:
+
+```markdown
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Your work**.
 ```
 
 To select your avatar:
 
 ```markdown
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 ```
 
 To save the selection in some dropdown lists:
@@ -969,6 +1006,20 @@ To save the selection in some dropdown lists:
 1. Select any area outside the dropdown list.
 ```
 
+To view all your projects:
+
+```markdown
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your projects**.
+```
+
+To view all your groups:
+
+```markdown
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your groups**.
+```
+
 ### Optional steps
 
 If a step is optional, start the step with the word `Optional` followed by a period.
@@ -998,8 +1049,8 @@ Use the phrase **Complete the fields**.
 
 For example:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Push rules**.
 1. Complete the fields.
 
diff --git a/doc/development/documentation/styleguide/word_list.md b/doc/development/documentation/styleguide/word_list.md
index 094de2bd724..0bbd679abe5 100644
--- a/doc/development/documentation/styleguide/word_list.md
+++ b/doc/development/documentation/styleguide/word_list.md
@@ -128,6 +128,10 @@ The token generated when you create an agent for Kubernetes. Use **agent access
 - secret token
 - authentication token
 
+## AI, artificial intelligence
+
+Use **AI**. Do not spell out **artificial intelligence**.
+
 ## air gap, air-gapped
 
 Use **offline environment** to describe installations that have physical barriers or security policies that prevent or limit internet access. Do not use **air gap**, **air gapped**, or **air-gapped**. For example:
@@ -208,7 +212,7 @@ Try to avoid **below** when referring to an example or table in a documentation
 
 Use uppercase for **Beta**. For example: **The XYZ feature is in Beta.** or **This Beta release is ready to test.**
 
-You might also want to link to [this section](../../../policy/alpha-beta-support.md#beta)
+You might also want to link to [this section](../../../policy/experiment-beta-support.md#beta)
 in the handbook when writing about Beta features.
 
 ## blacklist
@@ -294,6 +298,10 @@ This version is different than the larger, more monolithic **Linux package** tha
 
 You can also use **cloud-native GitLab** for short. It should be hyphenated and lowercase.
 
+## Code Suggestions
+
+Use title case for **Code Suggestions**.
+
 ## collapse
 
 Use **collapse** instead of **close** when you are talking about expanding or collapsing a section in the UI.
@@ -304,6 +312,16 @@ Use **From the command line** to introduce commands.
 
 Hyphenate when using as an adjective. For example, **a command-line tool**.
 
+## compute
+
+Use **compute** for the resources used by runners to run CI/CD jobs.
+
+Related terms:
+
+- [**units of compute**](#units-of-compute): How compute usage is calculated. For example, `400 units of compute`.
+- [**compute quota**](../../../ci/pipelines/cicd_minutes.md): The limit of units of compute that a namespace can use each month.
+- **compute usage**: The number of units of compute that the namespace has used from the monthly quota.
+
 ## confirmation dialog
 
 Use **confirmation dialog** to describe the dialog box that asks you to confirm your action. For example:
@@ -484,7 +502,7 @@ Use **expand** instead of **open** when you are talking about expanding or colla
 
 Use uppercase for **Experiment**. For example: **The XYZ feature is an Experiment.** or **This Experiment is ready to test.**
 
-You might also want to link to [this section](../../../policy/alpha-beta-support.md#experiment)
+You might also want to link to [this section](../../../policy/experiment-beta-support.md#experiment)
 in the handbook when writing about Experiment features.
 
 ## FAQ
@@ -507,8 +525,8 @@ Instead of:
 However, you can make an exception when you are writing a task and you need to refer to all
 of the fields at once. For example:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 1. Complete the fields.
 
@@ -672,6 +690,12 @@ Do not use Latin abbreviations. Use **that is** instead. ([Vale](../testing.md#v
 
 Do not use **in order to**. Use **to** instead. ([Vale](../testing.md#vale) rule: [`Wordy.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Wordy.yml))
 
+## indexes, indices
+
+For the plural of **index**, use **indexes**.
+
+However, for ElasticSearch, use [**indices**](https://www.elastic.co/blog/what-is-an-elasticsearch-index).
+
 ## Installation from source
 
 When referring to the installation method using the self-compiled code, refer to it
@@ -1225,7 +1249,7 @@ to the GitLab [reference architectures](../../../administration/reference_archit
 
 ## search
 
-When you search, you type a string in the search box on the top bar.
+When you search, you type a string in the search box on the left sidebar.
 The search results are displayed on a search page.
 
 Searching is different from [filtering](#filter).
@@ -1454,9 +1478,8 @@ Use **units of compute** instead of these (or similar) terms:
 - **CI minutes**
 - **pipeline minutes**
 - **CI pipeline minutes**
-- **pipeline minutes quota**
+- **pipeline minutes**
 
-This language is still being standardized in the documentation and UI beginning in March, 2023.
 For more information, see [issue 5218](https://gitlab.com/gitlab-com/Product/-/issues/5218).
 
 ## units of measurement
diff --git a/doc/development/documentation/testing.md b/doc/development/documentation/testing.md
index 4a7e206da20..ab0fe7b20a9 100644
--- a/doc/development/documentation/testing.md
+++ b/doc/development/documentation/testing.md
@@ -25,8 +25,11 @@ in the relevant projects:
 - <https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/.gitlab-ci.yml>
 - <https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/blob/master/.gitlab-ci.yml>
 
-We also run some documentation tests in the GitLab Development Kit project:
-<https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/.gitlab/ci/test.gitlab-ci.yml>.
+We also run some documentation tests in the:
+
+- GitLab Development Kit project:
+  <https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/.gitlab/ci/test.gitlab-ci.yml>.
+- Gitaly project: <https://gitlab.com/gitlab-org/gitaly/-/blob/master/.gitlab-ci.yml>.
 
 ## Run tests locally
 
@@ -48,6 +51,24 @@ To run tests locally, it's important to:
 
 ### Lint checks
 
+Merge requests containing changes to Markdown (`.md`) files run a `docs-lint markdown`
+job. This job runs `markdownlint`, and a set of tests from
+[`/scripts/lint-doc.sh`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/scripts/lint-doc.sh)
+that look for page content problems that Vale and markdownlint cannot test for.
+The job fails if any of these tests fail:
+
+- Curl (`curl`) commands must use long-form options (`--header`) instead of short options, like `-h`.
+- Documentation pages must contain front matter indicating ownership of the page.
+- Non-standard Unicode space characters (NBSP, NNBSP, ZWSP) must not be used in documentation,
+  because they can cause irregularities in search indexing and grepping.
+- `CHANGELOG.md` must not contain duplicate versions.
+- No files in the `doc/` directory may be executable.
+- Use `index.md` instead of `README.md`.
+- Directories and file names must use underscores instead of dashes.
+- Directories and file names must be in lower case.
+
+#### Run lint checks locally
+
 Lint checks are performed by the [`lint-doc.sh`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/scripts/lint-doc.sh)
 script and can be executed with the help of a Rake task as follows:
 
diff --git a/doc/development/documentation/topic_types/index.md b/doc/development/documentation/topic_types/index.md
index 37ed876fc59..381f70914c6 100644
--- a/doc/development/documentation/topic_types/index.md
+++ b/doc/development/documentation/topic_types/index.md
@@ -23,7 +23,7 @@ The acronym refers to the first letter of each topic type.
 
 In addition to the four primary topic types, you can use the following:
 
-- Page types: [Tutorials](tutorial.md) and [Get started](#get-started)
+- Page type: [Tutorials](tutorial.md)
 - Topic type: [Related topics](#related-topics)
 - Page or topic type: [Glossaries](glossary.md)
 
@@ -36,6 +36,7 @@ You should avoid:
 - Topics that have one or two sentences only. In these cases:
   - Incorporate the information in another topic.
   - If the sentence links to another page, use a [Related topics](#related-topics) link instead.
+- Get started topics. To document a procedure for a single feature, use a [task](task.md). For a set of steps, use a [tutorial](tutorial.md).
 
 ## Topic title guidelines
 
@@ -63,27 +64,3 @@ full sentences, and so should not end in a period.
 - [CI/CD variables](link-to-topic)
 - [Environment variables](link-to-topic)
 ```
-
-## Get started
-
-A get started page is a set of steps to help a user get set up
-quickly to use a single GitLab feature or tool.
-It consists of more than one task.
-
-Get started pages should be in this format:
-
-```markdown
-# Title ("Get started with <feature>")
-
-Complete the following steps to ... .
-
-1. First step.
-1. Another step.
-1. Another step.
-
-If you need to add more than one task,
-consider using subsections for each distinct task.
-```
-
-In the left nav, use `Get started` as the text. On the page itself, spell out
-the full name. For example, `Get started with application security`.
diff --git a/doc/development/documentation/topic_types/task.md b/doc/development/documentation/topic_types/task.md
index 2ddfd841ec3..87ce4d770f5 100644
--- a/doc/development/documentation/topic_types/task.md
+++ b/doc/development/documentation/topic_types/task.md
@@ -43,13 +43,13 @@ Prerequisites:
 
 To create an issue:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues > List**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**.
 1. In the upper-right corner, select **New issue**.
 1. Complete the fields. (If you have reference content that lists each field, link to it here.)
 1. Select **Create issue**.
 
-The issue is created. You can view it by going to **Issues > List**.
+The issue is created. You can view it by going to **Plan > Issues**.
 ```
 
 ## Task topic titles
diff --git a/doc/development/documentation/versions.md b/doc/development/documentation/versions.md
index 859e7265a2a..dadae134f4c 100644
--- a/doc/development/documentation/versions.md
+++ b/doc/development/documentation/versions.md
@@ -120,8 +120,8 @@ To deprecate a page or topic:
    You can add any additional context-specific details that might help users.
 
 1. Add the following HTML comments above and below the content.
-   For the `remove_date`, set a date three months after the release where it
-   was deprecated.
+   For `remove_date`, set a date three months after the release where it
+   will be removed.
 
    ```markdown
    <!--- start_remove The following content will be removed on remove_date: 'YYYY-MM-DD' -->
@@ -181,7 +181,7 @@ To remove a topic:
    including the version history items and the word `WARNING:`.
 1. Add `(removed)` after the title.
 1. Add the following HTML comments above and below the topic.
-   For the `remove_date`, set a date three months after the release where it was removed.
+   For `remove_date`, set a date three months after the release where it was removed.
 
    ```markdown
    <!--- start_remove The following content will be removed on remove_date: 'YYYY-MM-DD' -->
@@ -201,8 +201,8 @@ This content is removed from the documentation as part of the Technical Writing
 ## Which versions are removed
 
 GitLab supports the current major version and two previous major versions.
-For example, if 15.0 is the current major version, all major and minor releases of
-GitLab 15.0, 14.0, and 13.0 are supported.
+For example, if 16.0 is the current major version, all major and minor releases of
+GitLab 16.0, 15.0, and 14.0 are supported.
 
 [View the list of supported versions](https://about.gitlab.com/support/statement-of-support/#version-support).
 
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index bc997c37e66..aeb9739ecb3 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -49,13 +49,16 @@ version of the product:
 1. Enable **Allow use of licensed EE features** to make licensed EE features available to projects
    only if the project namespace's plan includes the feature.
 
-   1. Visit **Admin > Settings > General**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
+   1. On the left sidebar, select **Settings > General**.
    1. Expand **Account and limit**.
    1. Select the **Allow use of licensed EE features** checkbox.
    1. Select **Save changes**.
 
 1. Ensure the group you want to test the EE feature for is actually using an EE plan:
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
    1. On the left sidebar, select **Overview > Groups**.
    1. Identify the group you want to modify, and select **Edit**.
    1. Scroll to **Permissions and group features**. For **Plan**, select `Ultimate`.
@@ -548,6 +551,9 @@ EE-specific models should `extend EE::Model`.
 For example, if EE has a specific `Tanuki` model, you would
 place it in `ee/app/models/ee/tanuki.rb`.
 
+ActiveRecord `enums` should be entirely
+[defined in FOSS](database/creating_enums.md#all-of-the-keyvalue-pairs-should-be-defined-in-foss).
+
 ### Code in `app/views/`
 
 It's a very frequent problem that EE is adding some specific view code in a CE
diff --git a/doc/development/fe_guide/customizable_dashboards.md b/doc/development/fe_guide/customizable_dashboards.md
index 9e45c660745..ac8b0b8a1ab 100644
--- a/doc/development/fe_guide/customizable_dashboards.md
+++ b/doc/development/fe_guide/customizable_dashboards.md
@@ -6,27 +6,160 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Customizable dashboards
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98610) in GitLab 15.5 as an [Experiment](../../policy/alpha-beta-support.md#experiment).
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98610) in GitLab 15.5 as an [Experiment](../../policy/experiment-beta-support.md#experiment).
 
-Customizable dashboards provide a dashboard structure that allows users to create
-their own dashboards and commit the structure to a repository.
+Customizable dashboards provide a configuation-based [dashboard](https://design.gitlab.com/patterns/dashboards)
+structure, which is used to render and modify dashboard configurations created by GitLab or users.
 
-This feature is available for Premium and Ultimate subscriptions.
+The dashboard structure does not provide the means to save and version control
+user configuration files on a repository. This functionality is provided by [Analytics dashboards](../../user/analytics/analytics_dashboards.md)
+which uses the customizable dashboard component.
+
+NOTE:
+Customizable dashboards is intended for Premium and Ultimate subscriptions.
+
+## Overview
+
+Customizable dashboard can be broken down into 3 logical components:
+
+- Dashboard
+- Panels
+- Visualizations
+
+A dashboard consists of a list of panels to render, each panel references one
+visualization, and a single visualization can be shared by many panels.
+
+A typical dashboard structure looks like this:
+
+```plaintext
+dashboard
+├── panelA
+│  └── visualizationX
+├── panelB
+│  └── visualizationY
+├── panelC
+│  └── visualizationY
+```
 
 ## Usage
 
 To use customizable dashboards:
 
-1. Create your dashboard component.
-1. Render an instance of `CustomizableDashboard`.
-1. Pass a list of panels to render.
+1. Create a new Vue component for your dashboard.
+1. Create a [visualization configuration](#visualization-configuration).
+1. Create your [dashboard configuration](#dashboard-configuration).
+1. Render an instance of `CustomizableDashboard` and pass it your [dashboard configuration](#using-the-component).
+
+### Visualization configuration
+
+Each visualization is a graphical representation of query results fetched from a data source.
+
+```javascript
+// visualizations.js
+
+export const pageViewsOverTime = {
+  // The name of the Vue component used to render the query.
+  type: 'LineChart',
+  // Chart options defined by the charting library being used by the panel.
+  options: {
+    xAxis: { name: __('Time'), type: 'time' },
+    yAxis: { name: __('Counts'), type: 'time' },
+  },
+  // The data to query
+  data: {
+    // The data source to query. Here it is Product Analytics.
+    type: 'cube_analytics',
+    // The query to run on the data source. Here in Cube.js format.
+    query: {
+      dimensions: [],
+      filters: [
+        {
+          member: 'SnowplowTrackedEvents.event',
+          operator: 'equals',
+          values: ['page_view']
+        }
+      ],
+      measures: ['SnowplowTrackedEvents.pageViewsCount'],
+      timeDimensions: [
+        {
+          dimension: 'SnowplowTrackedEvents.derivedTstamp',
+          granularity: 'day',
+        },
+      ],
+      limit: 100,
+      timezone: 'UTC',
+    },
+  },
+};
+```
+
+#### Adding a new visualization render type
+
+To add a new visualization render type:
+
+1. Create a new Vue component that accepts `data` and `options` properties.
+See [`line_chart.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/components/visualizations/line_chart.vue) as an example.
+1. Add your component to the list of conditional imports in [`panel_base.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/vue_shared/components/customizable_dashboard/panels_base.vue#L13).
+
+#### Adding a new visualization data source
+
+To add a new data source:
+
+1. Create a new JavaScript module that exports a `fetch` method. See [`cube_analytics.js`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/data_sources/cube_analytics.js#L122) as an example.
+1. Add your module to the list exports in [`data_sources/index.js`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/data_sources/index.js).
+
+NOTE:
+Your data source must respect the filters so that all panels show data for
+the same date range.
+
+### Dashboard configuration
+
+Here is an example dashboard configuration:
 
-For example, a customizable dashboard for users over time:
+```javascript
+// constants.js
+import { pageViewsOverTime } from './visualizations';
+
+export const dashboard = {
+  slug: 'my_dashboard', // Used to set the URL path for the dashboard.
+  title: 'My dashboard title', // The title to display.
+  // Each dashboard consists of an array of panels to display.
+  panels: [
+    {
+      id: 1,
+      title: 'Page views over time', // The panel title to display.
+      // The visualization configuration. This can be shared by many panels.
+      visualization: pageViewsOverTime,
+      // Gridstack settings based upon https://github.com/gridstack/gridstack.js/tree/master/doc#item-options.
+      // All values are grid row/column numbers up to 12.
+      // We use the default 12 column grid https://github.com/gridstack/gridstack.js#change-grid-columns.
+      gridAttributes: {
+        yPos: 1,
+        xPos: 0,
+        width: 6,
+        height: 5,
+      },
+      // Optional overrides for the values in `visualization.data.query`.
+      // Here we override the Cube.js query to get page views per week instead of days.
+      queryOverrides: {
+        timeDimensions: {
+          dimension: 'SnowplowTrackedEvents.derivedTstamp',
+          granularity: 'week',
+        },
+      },
+    },
+  ],
+};
+```
+
+### Using the component
+
+Here is an example component that renders a customizable dashboard:
 
 ```vue
 <script>
 import CustomizableDashboard from 'ee/vue_shared/components/customizable_dashboard/customizable_dashboard.vue';
-import { s__ } from '~/locale';
+import { dashboard } from './constants';
 
 export default {
   name: 'AnalyticsDashboard',
@@ -35,63 +168,107 @@ export default {
   },
   data() {
     return {
-      panels: [
-        {
-          component: 'CubeLineChart', // The name of the panel component.
-          title: s__('ProductAnalytics|Users / Time'), // The title shown on the panel component.
-          // Gridstack settings based upon https://github.com/gridstack/gridstack.js/tree/master/doc#item-options.
-          // All values are grid row/column numbers up to 12.
-          // We use the default 12 column grid https://github.com/gridstack/gridstack.js#change-grid-columns.
-          gridAttributes: {
-            height: 4,
-            width: 6,
-            minHeight: 4,
-            minWidth: 6,
-            xPos: 0,
-            yPos: 0,
-          },
-          // Options that are used to set bespoke values for each panel.
-          // Available customizations are determined by the panel itself.
-          customizations: {},
-          // Chart options defined by the charting library being used by the panel.
-          chartOptions: {
-            xAxis: { name: __('Time'), type: 'time' },
-            yAxis: { name: __('Counts') },
-          },
-          // The data for the panel.
-          // This could be imported or in this case, a query passed to be used by the panels API.
-          // Each panel type determines how it handles this property.
-          data: {
-            query: {
-              users: {
-                measures: ['TrackedEvents.count'],
-                dimensions: ['TrackedEvents.eventType'],
-              },
-            },
-          },
-        },
-      ]
+      // We keep the original (default) dashboard object to track changes.
+      dashboard: {
+        ...dashboard,
+        default: { ...dashboard, }
+      },
+      // Optional dashboard filters. Currently the only availble filter is date range.
+      defaultFilters: {
+        dateRangeOption: 'last_7_days' // 'custom', 'today', 'last_7_days', 'last_30_days'
+        endDate: new Date(2023, 06, 14),
+        startDate: new Date(2023, 06, 7),
+      },
+      // Set to true to sync the filter object with the URL query string.
+      syncUrlFilters: true,
+      // Set to true to show the date range filter.
+      showDateRangeFilter: true,
+      // The maximum size of the date range allowed in days. 0 for unlimited.
+      dateRangeLimit: 0,
     };
   },
 };
 </script>
 
 <template>
-  <h1>{{ s__('ProductAnalytics|Analytics dashboard') }}</h1>
-  <customizable-dashboard :panels="panels" />
+  <customizable-dashboard
+    :initial-dashboard="dashboard"
+    :default-filters="defaultFilters"
+    :sync-url-filters="syncUrlFilters"
+    :show-date-range-filter="showDateRangeFilter"
+    :date-range-limit="dateRangeLimit"
+  />
 </template>
 ```
 
-The panels data can be retrieved from a file or API request, or imported through HTML data attributes.
+## Dashboard designer
 
-For each panel, a `component` is defined. Each `component` is a component declaration and should be included in
-[`vue_shared/components/customizable_dashboard/panels_base.vue`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/assets/javascripts/vue_shared/components/customizable_dashboard/panels_base.vue)
-as a dynamic import, to keep the memory usage down until it is used.
+> Introduced in GitLab 16.1 [with a flag](../../administration/feature_flags.md) named `combined_analytics_dashboards_editor`. Disabled by default.
 
-For example:
+The dashboard designer provides a graphical interface for users to modify the
+panels and add new ones on user-defined dashboards. Is is not available on
+GitLab hardcoded dashboards.
 
-```javascript
-components: {
-  CubeLineChart: () => import('ee/product_analytics/dashboards/components/panels/cube_line_chart.vue')
+NOTE:
+The dashboard designer is in the early experimental stage and subject to
+change.
+
+```vue
+<script>
+import { s__ } from '~/locale';
+
+export const I18N_MY_NEW_CATEGORY = s__('Namespace|My data source');
+
+export default {
+  name: 'AnalyticsDashboard',
+  data() {
+    return {
+      ...,
+      // Set to true to render the dashboard saving state.
+      isSaving: false,
+      // A list of availble visualizations categorized by feature.
+      availableVisualizations: {
+        // The visualization category title to display.
+        [I18N_MY_NEW_CATEGORY]: {
+          // Set to true when asynchronously loading the visualization IDs
+          loading: false,
+          // List of availble visualization IDs for the user to add to the dashboard.
+          visualizationIds: [
+            'page_views_over_time',
+            'events_over_time',
+          ],
+        },
+      }
+    };
+  },
+  methods: {
+    /**
+     * Event handler for when a user saves changes made to the current dashboard.
+     * @param  {String} dashboardId The current dashboard ID.
+     * @param  {String} newDashboardObject The newly modified dashboard object.
+     */
+    saveDashboard(dashboardId, newDashboardObject) {
+      // Save changes and modify `this.dashboard`.
+    },
+    /**
+     * Event handler for when a user adds a visualization in a new panel.
+     * @param  {String} visualizationId The ID (usually filename) of the visualization.
+     * @param  {String} visualizationSource The source to get the new visualization config.
+     */
+    addNewPanel(visualizationId, visualizationSource) {
+      // Load the visualization and push a new panel onto `this.dashboard.panels`.
+    },
+  },
 }
+</script>
+
+<template>
+  <customizable-dashboard
+    ...
+    :available-visualizations="availableVisualizations"
+    :is-saving="isSaving"
+    @save="handleSave"
+    @add-panel="handleAddPanel"
+  />
+</template>
 ```
diff --git a/doc/development/fe_guide/haml.md b/doc/development/fe_guide/haml.md
index 9dc5b265783..1dc8cf63de9 100644
--- a/doc/development/fe_guide/haml.md
+++ b/doc/development/fe_guide/haml.md
@@ -42,7 +42,7 @@ For example:
         = f.check_box :prevent_sharing_groups_outside_hierarchy, disabled: !can_change_prevent_sharing_groups_outside_hierarchy?(@group), class: 'custom-control-input'
         = f.label :prevent_sharing_groups_outside_hierarchy, class: 'custom-control-label' do
           %span
-            = s_('GroupSettings|Prevent members from sending invitations to groups outside of %{group} and its subgroups.').html_safe % { group: link_to_group(@group) }
+            = safe_format(s_('GroupSettings|Prevent members from sending invitations to groups outside of %{group} and its subgroups.'), group: link_to_group(@group))
           %p.help-text= prevent_sharing_groups_outside_hierarchy_help_text(@group)
 
     .form-group.gl-mb-3
@@ -61,16 +61,16 @@ For example:
   = gitlab_ui_form_for @group do |f|
     .form-group.gl-mb-3
       = f.gitlab_ui_checkbox_component :prevent_sharing_groups_outside_hierarchy,
-          s_('GroupSettings|Prevent members from sending invitations to groups outside of %{group} and its subgroups.').html_safe % { group: link_to_group(@group) },
+          safe_format(s_('GroupSettings|Prevent members from sending invitations to groups outside of %{group} and its subgroups.'), group: link_to_group(@group)),
           help_text: prevent_sharing_groups_outside_hierarchy_help_text(@group),
           checkbox_options: { disabled: !can_change_prevent_sharing_groups_outside_hierarchy?(@group) }
 
     .form-group.gl-mb-3
       = f.gitlab_ui_checkbox_component :lfs_enabled, checkbox_options: { checked: @group.lfs_enabled? } do |c|
-        = c.label do
+        - c.with_label do
           = _('Allow projects within this group to use Git LFS')
           = link_to sprite_icon('question-o'), help_page_path('topics/git/lfs/index')
-        = c.help_text do
+        - c.with_help_text do
           = _('This setting can be overridden in each project.')
   ```
 
diff --git a/doc/development/fe_guide/source_editor.md b/doc/development/fe_guide/source_editor.md
index 45ec3ba1464..943ac2969f3 100644
--- a/doc/development/fe_guide/source_editor.md
+++ b/doc/development/fe_guide/source_editor.md
@@ -210,7 +210,7 @@ export default {
 
 In the code example, `this` refers to the instance. By referring to the instance,
 we can access the complete underlying
-[Monaco editor API](https://microsoft.github.io/monaco-editor/api/),
+[Monaco editor API](https://microsoft.github.io/monaco-editor/docs.html),
 which includes functions like `getValue()`.
 
 Now let's use our extension:
diff --git a/doc/development/fe_guide/storybook.md b/doc/development/fe_guide/storybook.md
index 8e0814ad96b..eaa8f8b4068 100644
--- a/doc/development/fe_guide/storybook.md
+++ b/doc/development/fe_guide/storybook.md
@@ -53,8 +53,85 @@ To add a story:
    If the component is located in the `ee/` directory, make sure to prefix the story's title with `ee/` as well.
    This will ensure the Storybook navigation maps closely to our internal directory structure.
 
-## Mock backend APIs
+## Using GitLab REST and GraphQL APIs
 
-The GitLab Storybook uses [MirajeJS](https://miragejs.com/) to mock REST and GraphQL APIs. Storybook shares the MirajeJS server
-with the [frontend integration tests](../testing_guide/testing_levels.md#frontend-integration-tests). You can find the MirajeJS
-configuration files in `spec/frontend_integration/mock_server`.
+You can write stories for components that use either GitLab’s [REST](../../api/rest/index.md) or
+[GraphQL](../../api/graphql/index.md) APIs.
+
+### Set up API access token and GitLab instance URL
+
+To add a story with API access:
+
+1. Create a [personal access token](../../user/profile/personal_access_tokens.md) in your GitLab instance.
+
+   NOTE:
+   If you test against `gitlab.com`, make sure to use a token with `read_api` if possible and to make the token short-lived.
+
+1. Create an `.env` file in the `storybook` directory. Use the `storybook/.env.template` file as
+a starting point.
+
+1. Set the `API_ACCESS_TOKEN` variable to the access token that you created.
+
+1. Set the `GITLAB_URL` variable to the GitLab instance’s domain URL, for example: `http://gdk.test:3000`.
+
+1. Start or restart your storybook.
+
+You can also use the GitLab API Access panel in the Storybook UI to set the GitLab instance URL and access token.
+
+### Set up API access in your stories
+
+You should apply the `withGitLabAPIAccess` decorator to the stories that will consume GitLab’s APIs. This decorator
+will display a badge indicating that the story won't work without providing the API access parameters:
+
+```javascript
+import { withGitLabAPIAccess } from 'storybook_addons/gitlab_api_access';
+import Api from '~/api';
+import { ContentEditor } from './index';
+
+export default {
+  component: ContentEditor,
+  title: 'ce/content_editor/content_editor',
+  decorators: [withGitLabAPIAccess],
+};
+```
+
+#### Using REST API
+
+The Storybook sets up `~/lib/utils/axios_utils` in `storybook/config/preview.js`. Components that use the REST API
+should work out of the box as long as you provide a valid GitLab instance URL and access token.
+
+#### Using GraphQL
+
+To write a story for a component that uses the GraphQL API, use the `createVueApollo` method provided in
+the Story context.
+
+```javascript
+import Vue from 'vue';
+import VueApollo from 'vue-apollo';
+import { withGitLabAPIAccess } from 'storybook_addons/gitlab_api_access';
+import WorkspacesList from './list.vue';
+
+Vue.use(VueApollo);
+
+const Template = (_, { argTypes, createVueApollo }) => {
+  return {
+    components: { WorkspacesList },
+    apolloProvider: createVueApollo(),
+    provide: {
+      emptyStateSvgPath: '',
+    },
+    props: Object.keys(argTypes),
+    template: '<workspaces-list />',
+  };
+};
+
+export default {
+  component: WorkspacesList,
+  title: 'ee/remote_development/workspaces_list',
+  decorators: [withGitLabAPIAccess],
+};
+
+export const Default = Template.bind({});
+
+Default.args = {};
+```
diff --git a/doc/development/fe_guide/view_component.md b/doc/development/fe_guide/view_component.md
index 0245110ec75..cfd78597501 100644
--- a/doc/development/fe_guide/view_component.md
+++ b/doc/development/fe_guide/view_component.md
@@ -66,7 +66,7 @@ In its simplest form the banner component looks like this:
 ```haml
 = render Pajamas::BannerComponent.new(button_text: 'Learn more', button_link: example_path,
   svg_path: 'illustrations/example.svg') do |c|
-  - c.title { 'Hello world!' }
+  - c.with_title { 'Hello world!' }
   %p Content of your banner goes here...
 ```
 
@@ -75,11 +75,11 @@ instead of `svg_path` and the `primary_action` slot instead of `button_text` and
 
 ```haml
 = render Pajamas::BannerComponent.new do |c|
-  - c.illustration do
+  - c.with_illustration do
     = custom_icon('my_inline_svg')
-  - c.title do
+  - c.with_title do
     Hello world!
-  - c.primary_action do
+  - c.with_primary_action do
     = render 'my_button_in_a_partial'
 ```
 
@@ -133,12 +133,12 @@ The card has one mandatory `body` slot and optional `header` and `footer` slots:
 
 ```haml
 = render Pajamas::CardComponent.new do |c|
-  - c.header do
+  - c.with_header do
     I'm the header.
-  - c.body do
+  - c.with_body do
     %p Multiple line
     %p body content.
-  - c.footer do
+  - c.with_footer do
     Footer goes here.
 ```
 
@@ -164,9 +164,9 @@ For example:
 ```haml
 = render Pajamas::CheckboxTagComponent.new(name: 'project[initialize_with_sast]',
   checkbox_options: { data: { qa_selector: 'initialize_with_sast_checkbox', track_label: track_label, track_action: 'activate_form_input', track_property: 'init_with_sast' } }) do |c|
-  = c.label do
+  - c.with_label do
     = s_('ProjectsNew|Enable Static Application Security Testing (SAST)')
-  = c.help_text do
+  - c.with_help_text do
     = s_('ProjectsNew|Analyze your source code for known security vulnerabilities.')
     = link_to _('Learn more.'), help_page_path('user/application_security/sast/index'), target: '_blank', rel: 'noopener noreferrer', data: { track_action: 'followed' }
 ```
@@ -219,11 +219,11 @@ Many of the settings pages use a layout where the title and description are on t
 
 ```haml
 = render ::Layouts::HorizontalSectionComponent.new(options: { class: 'gl-mb-6' }) do |c|
-  = c.title { _('Naming, visibility') }
-  = c.description do
+  - c.with_title { _('Naming, visibility') }
+  - c.with_description do
     = _('Update your group name, description, avatar, and visibility.')
     = link_to _('Learn more about groups.'), help_page_path('user/group/index')
-  = c.body do
+  - c.with_body do
     .form-group.gl-form-group
       = f.label :name, _('New group name')
       = f.text_field :name
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 7ba774392a1..1a43084245e 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -28,10 +28,24 @@ To better explain this, let's imagine the page that has one toggle, and toggling
 - when you have to maintain any form of application state and share it between tags/elements;
 - when you expect complex logic to be added in the future - it's easier to start with basic Vue application than having to rewrite JS/HAML to Vue on the next step.
 
+## Avoid multiple Vue applications on the page
+
+In the past, we added interactivity to the page piece-by-piece, adding multiple small Vue applications to different parts of the rendered HAML page. However, this approach led us to multiple complications:
+
+- in most cases, these applications don't share state and perform API requests independently which grows a number of requests;
+- we have to provide data from Rails to Vue using multiple endpoints;
+- we cannot render Vue applications dynamically after page load, so the page structure becomes rigid;
+- we cannot fully leverage client-side routing to replace Rails routing;
+- multiple applications lead to unpredictable user experience, increased page complexity, harder debugging process;
+- the way apps communicate with each other affects Web Vitals numbers.
+
+Because of these reasons, we want to be cautious about adding new Vue applications to the pages where another Vue application is already present (this does not include old or new navigation). Before adding a new app, please make sure that it is absolutely impossible to extend an existing application to achieve a desired functionality. When in doubt, please feel free to ask for the architectural advise on `#frontend` or `#frontend-maintainers` Slack channel.
+
+If you still need to add a new application, please make sure it shares local state with existing applications (preferably via Apollo Client, or Vuex if we use REST API)
+
 ## Vue architecture
 
-All new features built with Vue.js must follow a [Flux architecture](https://facebookarchive.github.io/flux/).
-The main goal we are trying to achieve is to have only one data flow, and only one data entry.
+The main goal we are trying to achieve with Vue architecture is to have only one data flow, and only one data entry.
 To achieve this goal we use [Vuex](#vuex) or [Apollo Client](graphql.md#libraries)
 
 You can also read about this architecture in Vue documentation about
diff --git a/doc/development/feature_development.md b/doc/development/feature_development.md
index 15058134092..c4a5c996ab1 100644
--- a/doc/development/feature_development.md
+++ b/doc/development/feature_development.md
@@ -160,9 +160,9 @@ The following integration guides are internal. Some integrations require access
 - [Externalization](i18n/externalization.md)
 - [Translation](i18n/translation.md)
 
-## Product Intelligence guides
+## Analytics Instrumentation guides
 
-- [Product Intelligence guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
+- [Analytics Instrumentation guide](https://about.gitlab.com/handbook/product/analytics-instrumentation-guide/)
 - [Service Ping guide](service_ping/index.md)
 - [Snowplow guide](snowplow/index.md)
 
diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md
index 87d2da016d6..30837ac8f3f 100644
--- a/doc/development/feature_flags/index.md
+++ b/doc/development/feature_flags/index.md
@@ -144,6 +144,14 @@ An `experiment` feature flag should conform to the same standards as a `developm
 although the interface has some differences. An experiment feature flag should have a rollout issue,
 created using the [Experiment Tracking template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Experiment%20Rollout.md). More information can be found in the [experiment guide](../experiment_guide/index.md).
 
+### `worker` type
+
+`worker` feature flags are used for controlling Sidekiq workers behavior, such as deferring Sidekiq jobs.
+
+`worker` feature flags likely do not have any YAML definition as the name could be dynamically generated using
+the worker name itself, e.g. `defer_sidekiq_jobs_AuthorizedProjectsWorker`. Some examples for using `worker` type feature
+flags can be found in [deferring Sidekiq jobs](#deferring-sidekiq-jobs).
+
 ## Feature flag definition and validation
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/229161) in GitLab 13.3.
@@ -698,3 +706,40 @@ test is written to enable/disable a feature flag explicitly.
 When a feature flag is changed on Staging or on GitLab.com, a Slack message will be posted to the `#qa-staging` or `#qa-production` channels to inform
 the pipeline triage DRI so that they can more easily determine if any failures are related to a feature flag change. However, if you are working on a change you can
 help to avoid unexpected failures by [confirming that the end-to-end tests pass with a feature flag enabled.](../testing_guide/end_to_end/feature_flags.md#confirming-that-end-to-end-tests-pass-with-a-feature-flag-enabled)
+
+## Controlling Sidekiq worker behavior with feature flags
+
+Feature flags with [`worker` type](#worker-type) can be used to control the behavior of a Sidekiq worker.
+
+### Deferring Sidekiq jobs
+
+Feature flags with the format of `defer_sidekiq_jobs_{WorkerName}` delay the execution of the worker
+by scheduling the job at a later time.
+Deferring jobs can be useful during an incident where contentious behavior from
+worker instances are saturating infrastructure resources (such as database and database connection pool).
+The implementation can be found at [DeferJobs Sidekiq server middleware](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/sidekiq_middleware/defer_jobs.rb).
+
+NOTE:
+Jobs are deferred indefinitely as long as the feature flag is enabled. It is important to disable the
+feature flag after the worker is deemed safe to continue processing.
+
+When set to true, 100% of the jobs are deferred. When you want processing to resume, you can
+use a **percentage of time** rollout. For example:
+
+```shell
+# defer 100% of the jobs
+/chatops run feature set defer_sidekiq_jobs_SlowRunningWorker true
+
+# defer 99% of the jobs, only letting 1% processed
+/chatops run feature set defer_sidekiq_jobs_SlowRunningWorker 99
+
+# defer 50% of the jobs
+/chatops run feature set defer_sidekiq_jobs_SlowRunningWorker 50
+
+# stop deferring the jobs, jobs are being processed normally
+/chatops run feature set defer_sidekiq_jobs_SlowRunningWorker false
+```
+
+NOTE:
+The percentage of time value denotes the percentage of time the jobs are being deferred (instead of being processed).
+For example, setting to `99` means only 1% of the jobs are being processed at random.
diff --git a/doc/development/gemfile.md b/doc/development/gemfile.md
index add93e37024..e6275068ea8 100644
--- a/doc/development/gemfile.md
+++ b/doc/development/gemfile.md
@@ -112,71 +112,7 @@ ourselves, or because we think it would benefit the wider community.
 Extracting code to a gem also means that we can be sure that the gem
 does not contain any hidden dependencies on our application code.
 
-In general, we want to think carefully before doing this as there are
-also disadvantages:
-
-### Potential disadvantages
-
-1. Gems - even those maintained by GitLab - do not necessarily go
-   through the same [code review process](code_review.md) as the main
-   Rails application.
-1. Extracting the code into a separate project means that we need a
-   minimum of two merge requests to change functionality: one in the gem
-   to make the functional change, and one in the Rails app to bump the
-   version.
-1. Our needs for our own usage of the gem may not align with the wider
-   community's needs. In general, if we are not using the latest version
-   of our own gem, that might be a warning sign.
-
-### Create and publish a Ruby gem
-
-In the case where we do want to extract some library code we've written
-to a gem, go through these steps:
-
-1. Determine a suitable name for the gem. If it's a GitLab-owned gem, prefix
-   the gem name with `gitlab-`. For example, `gitlab-sidekiq-fetcher`.
-1. Create the gem or fork as necessary.
-1. Ensure the `gitlab_rubygems` group is an owner of the new gem by running:
-
-   ```shell
-   gem owner <gem-name> --add gitlab_rubygems
-   ```
-
-1. [Publish the gem to rubygems.org](https://guides.rubygems.org/publishing/#publishing-to-rubygemsorg)
-1. Visit `https://rubygems.org/gems/<gem-name>` and verify that the gem published
-   successfully and `gitlab_rubygems` is also an owner.
-1. Start with the code in the Rails application. Here it's fine to have
-   the code in `lib/` and loaded automatically. We can skip this step if
-   the step below makes more sense initially.
-1. Before extracting to its own project, move the gem to `vendor/gems` and
-   load it in the `Gemfile` using the `path` option. This gives us a gem
-   that can be published to RubyGems.org, with its own test suite and
-   isolated set of dependencies, that is still in our main code tree and
-   goes through the standard code review process.
-   - For an example, see the [merge request !57805](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57805).
-1. Once the gem is stable - we have been using it in production for a
-   while with few, if any, changes - extract to its own project under
-   the [`gitlab-org/ruby/gems` namespace](https://gitlab.com/gitlab-org/ruby/gems/).
-
-   - To create this project:
-       1. Follow the [instructions for new projects](https://about.gitlab.com/handbook/engineering/gitlab-repositories/#creating-a-new-project).
-       1. Follow the instructions for setting up a [CI/CD configuration](https://about.gitlab.com/handbook/engineering/gitlab-repositories/#cicd-configuration).
-       1. Follow the instructions for [publishing a project](https://about.gitlab.com/handbook/engineering/gitlab-repositories/#publishing-a-project).
-   - See [issue #325463](https://gitlab.com/gitlab-org/gitlab/-/issues/325463)
-     for an example.
-   - In some cases we may want to move a gem to its own namespace. Some
-     examples might be that it will naturally have more than one project
-     (say, something that has plugins as separate libraries), or that we
-     expect non-GitLab-team-members to be maintainers on this project as
-     well as GitLab team members.
-
-     The latter situation (maintainers from outside GitLab) could also
-     apply if someone who currently works at GitLab wants to maintain
-     the gem beyond their time working at GitLab.
-
-When publishing a gem to RubyGems.org, also note the section on
-[gem owners](https://about.gitlab.com/handbook/developer-onboarding/#ruby-gems)
-in the handbook.
+Read more about [Gems development guidelines](gems.md).
 
 ## Upgrade Rails
 
diff --git a/doc/development/gems.md b/doc/development/gems.md
new file mode 100644
index 00000000000..709dfa105bf
--- /dev/null
+++ b/doc/development/gems.md
@@ -0,0 +1,321 @@
+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Gems development guidelines
+
+GitLab uses Gems as a tool to improve code reusability and modularity
+in a monolithic codebase.
+
+Sometimes we create libraries within our codebase that we want to
+extract, either because their functionality is highly isolated,
+we want to use them in other applications
+ourselves, or we think it would benefit the wider community.
+Extracting code to a gem also means that we can be sure that the gem
+does not contain any hidden dependencies on our application code.
+
+## When to use Gems
+
+Gems should be used always when implementing functions that can be considered isolated,
+that are decoupled from the business logic of GitLab and can be developed separately. Consider the
+following examples where Gem logic could be placed:
+
+The best example where we can look for opportunities to introduce new gems
+is the [lib/](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/) folder.
+
+The **lib/** folder is a mix of code that is generic/universal, GitLab-specific, and tightly integrated with the rest of the codebase.
+
+If you cannot find a good place for your code in **lib/** you should strongly
+consider creating the new Gem [In the same repo](#in-the-same-repo).
+
+## In the same repo
+
+**Our GitLab Gems should be always put in `gems/` of GitLab monorepo.**
+
+That gives us the advantages of gems (modular code, quicker to run tests in development).
+and prevents complexity (coordinating changes across repos, new permissions, multiple projects, etc.).
+
+Gems stored in the same repo should be referenced in `Gemfile` with the `path:` syntax.
+They should not be published to RubyGems.
+
+### Advantages
+
+Using Gems can provide several benefits for code maintenance:
+
+- Code Reusability - Gems are isolated libraries that serve single purpose. When using Gems, a common functions
+  can be isolated in a simple package, that is well documented, tested, and re-used in different applications.
+
+- Modularity - Gems help to create isolation by encapsulating specific functionality within self-contained library.
+  This helps to better organize code, better define who is owner of a given module, makes it easier to maintain
+  or update specific gems.
+
+- Small - Gems by design due to implementing isolated set of functions are small. Small projects are much easier
+  to comprehend, extend and maintain.
+
+- Testing - Using Gems since they are small makes much faster to run all tests, or be very through with testing of the gem.
+  Since the gem is packaged, not changed too often, it also allows us to run those tests less frequently improving
+  CI testing time.
+
+### To Do
+
+#### Desired use cases
+
+The `gitlab-utils` is a Gem containing as of set of class that implement common intrisic functions
+used by GitLab developers, like `strong_memoize` or `Gitlab::Utils.to_boolean`.
+
+The `gitlab-database-schema-migrations` is a potential Gem containing our extensions to Rails
+framework improving how database migrations are stored in repository. This builds on top of Rails
+and is not specific to GitLab the application, and could be generally used for other projects
+or potentially be upstreamed.
+
+The `gitlab-database-load-balancing` similar to previous is a potential Gem to implement GitLab specific
+load balancing to Rails database handling. Since this is rather complex and highly specific code
+maintaing it's complexity in a isolated and well tested Gem would help with removing this complexity
+from a big monolithic codebase.
+
+The `gitlab-flipper` is another potential Gem implementing all our custom extensions to support feature
+flags in a codebase. Over-time the monolithic codebase did grow with the check for feature flags
+usage, adding consistency checks and various helpers to track owners of feature flags added. This is
+not really part of GitLab business logic and could be used to better track our implementation
+of Flipper and possibly much easier change it to dogfood [GitLab Feature Flags](../operations/feature_flags.md).
+
+The `gitlab-ci-reports-parsers` is a potential Gem that could implement all various parsers for various formats.
+The parsed output would be transformed into objects that could then be used by GitLab the application
+to store it in the database. This functionality could be an additional Gem since it is isolated,
+rarely changed, and GitLab Rails only consumes the data.
+
+The same pattern could be applied to all other type of parsers, like security vulnerabilities, or any
+other complex structures that need to be transformed into a form that is consumed by GitLab Rails.
+
+The `gitlab-active_record` is a gem adding GitLab specific Active Record patches.
+It is very well desired for such to be managed separately to isolate complexity.
+
+#### Other potential use cases
+
+The `gitlab-ci-config` is a potential Gem containing all our CI code used to parse `.gitlab-ci.yml`.
+This code is today lightly interlocked with GitLab the application due to lack of proper abstractions.
+However, moving this to dedicated Gem could allow us to build various adapters to handle integration
+with GitLab the application. The interface would for example define an adapter to resolve `includes:`.
+Once we would have a `gitlab-ci-config` Gem it could be used within GitLab and outside of GitLab Rails
+and [GitLab CLI](https://gitlab.com/gitlab-org/cli).
+
+### Create and use a new Gem
+
+You can see example adding new Gem: [!121676](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121676).
+
+1. Create a new Ruby Gem in `gems/gitlab-<name-of-gem>` with `bundle gem gems/gitlab-<name-of-gem> --no-exe --no-coc --no-ext --no-mit`.
+1. Edit or remove `gitlab-<name-of-gem>/README.md` to provide a simple one paragraph description of the Gem.
+1. Edit `gitlab-<name-of-gem>/gitlab-<name-of-gem>.gemspec` and fill the details about the Gem as in the following example:
+
+    ```ruby
+    Gem::Specification.new do |spec|
+      spec.name = "gitlab-<name-of-gem>"
+      spec.version = Gitlab::NameOfGem::VERSION
+      spec.authors = ["group::tenant-scale"]
+      spec.email = ["engineering@gitlab.com"]
+
+      spec.summary = "GitLab's RSpec extensions"
+      spec.description = "A set of useful helpers to configure RSpec with various stubs and CI configs."
+      spec.homepage = "https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-<name-of-gem>"
+      spec.required_ruby_version = ">= 2.6.0"
+    end
+    ```
+
+1. Update `gems/gitlab-<name-of-gem>/.rubocop` with:
+
+    ```yaml
+    inherit_from:
+      - ../../.rubocop.yml
+
+    CodeReuse/ActiveRecord:
+      Enabled: false
+
+    AllCops:
+      TargetRubyVersion: 3.0
+
+    Naming/FileName:
+      Exclude:
+        - spec/**/*.rb
+    ```
+
+1. Configure CI for a newly added Gem:
+
+- Add `gems/gitlab-<name-of-gem>/.gitlab-ci.yml`:
+
+    ```yaml
+    workflow:
+      rules:
+        - if: $CI_MERGE_REQUEST_ID
+
+    rspec:
+      image: "ruby:${RUBY_VERSION}"
+      cache:
+        key: gitlab-<name-of-gem>
+        paths:
+          - gitlab-<name-of-gem>/vendor/ruby
+      before_script:
+        - cd vendor/gems/bundler-checksum
+        - ruby -v                                   # Print out ruby version for debugging
+        - gem install bundler --no-document         # Bundler is not installed with the image
+        - bundle config set --local path 'vendor'   # Install dependencies into ./vendor/ruby
+        - bundle config set with 'development'
+        - bundle config set --local frozen 'true'   # Disallow Gemfile.lock changes on CI
+        - bundle config                             # Show bundler configuration
+        - bundle install -j $(nproc)
+      script:
+        - bundle exec rspec
+      parallel:
+        matrix:
+          - RUBY_VERSION: ["2.7", "3.0", "3.1", "3.2"]
+    ```
+
+- To `.gitlab/ci/rules.gitlab-ci.yml` add:
+
+    ```yaml
+    .gems:rules:gitlab-<name-of-gem>:
+      rules:
+        - <<: *if-merge-request
+          changes: ["gems/gitlab-<name-of-gem>/**/*"]
+    ```
+
+- To `.gitlab/ci/gitlab-gems.gitlab-ci.yml` add:
+
+    ```yaml
+    gems gitlab-<name-of-gem>:
+      extends:
+        - .gems:rules:gitlab-<name-of-gem>
+      needs: []
+      trigger:
+        include: gems/gitlab-<name-of-gem>/.gitlab-ci.yml
+        strategy: depend
+    ```
+
+1. Reference Gem in `Gemfile` with:
+
+    ```ruby
+    gem 'gitlab-<name-of-gem>', path: 'gems/gitlab-<name-of-gem>'
+    ```
+
+## In the external repo
+
+In general, we want to think carefully before doing this as there are
+severe disadvantages.
+
+Gems stored in the external repo MUST be referenced in `Gemfile` with `version` syntax.
+They MUST be always published to RubyGems.
+
+### Examples
+
+At GitLab we use a number of external gems:
+
+- [LabKit Ruby](https://gitlab.com/gitlab-org/labkit-ruby)
+- [GitLab Ruby Gems](https://gitlab.com/gitlab-org/ruby/gems)
+
+### Potential disadvantages
+
+- Gems - even those maintained by GitLab - do not necessarily go
+  through the same [code review process](code_review.md) as the main
+  Rails application. This is particularly critical for Application Security.
+- Requires setting up CI/CD from scratch, including tools like Danger that
+  support consistent code review standards.
+- Extracting the code into a separate project means that we need a
+  minimum of two merge requests to change functionality: one in the gem
+  to make the functional change, and one in the Rails app to bump the
+  version.
+- Integration with `gitlab-rails` requiring a second MR means integration problems
+  may be discovered late.
+- With a smaller pool of reviewers and maintainers compared to `gitlab-rails`,
+  it may take longer to get code reviewed and the impact of "bus factor" increases.
+- Inconsistent workflows for how a new gem version is released. It is currently at
+  the discretion of library maintainers to decide how it works.
+- Promotes knowledge silos because code has less visibility and exposure than `gitlab-rails`.
+- We have a well defined process for promoting GitLab reviewers to maintainers.
+  This is not true for extracted libraries, increasing the risk of lowering the bar for code reviews,
+  and increasing the risk of shipping a change.
+- Our needs for our own usage of the gem may not align with the wider
+  community's needs. In general, if we are not using the latest version
+  of our own gem, that might be a warning sign.
+
+### Potential advantages
+
+- Faster feedback loops, since CI/CD runs against smaller repositories.
+- Ability to expose the project to the wider community and benefit from external contributions.
+- Repository owners are most likely the best audience to review a change, which reduces
+  the necessity of finding the right reviewers in `gitlab-rails`.
+
+### Create and publish a Ruby gem
+
+The project for a new Gem should always be created in [`gitlab-org/ruby/gems` namespace](https://gitlab.com/gitlab-org/ruby/gems/):
+
+1. Determine a suitable name for the gem. If it's a GitLab-owned gem, prefix
+   the gem name with `gitlab-`. For example, `gitlab-sidekiq-fetcher`.
+1. Create the gem or fork as necessary.
+1. Ensure the `gitlab_rubygems` group is an owner of the new gem by running:
+
+   ```shell
+   gem owner <gem-name> --add gitlab_rubygems
+   ```
+
+1. [Publish the gem to rubygems.org](https://guides.rubygems.org/publishing/#publishing-to-rubygemsorg)
+1. Visit `https://rubygems.org/gems/<gem-name>` and verify that the gem published
+   successfully and `gitlab_rubygems` is also an owner.
+1. Create a project in [`gitlab-org/ruby/gems` namespace](https://gitlab.com/gitlab-org/ruby/gems/).
+
+   - To create this project:
+       1. Follow the [instructions for new projects](https://about.gitlab.com/handbook/engineering/gitlab-repositories/#creating-a-new-project).
+       1. Follow the instructions for setting up a [CI/CD configuration](https://about.gitlab.com/handbook/engineering/gitlab-repositories/#cicd-configuration).
+       1. Follow the instructions for [publishing a project](https://about.gitlab.com/handbook/engineering/gitlab-repositories/#publishing-a-project).
+   - See [issue #325463](https://gitlab.com/gitlab-org/gitlab/-/issues/325463)
+     for an example.
+   - In some cases we may want to move a gem to its own namespace. Some
+     examples might be that it will naturally have more than one project
+     (say, something that has plugins as separate libraries), or that we
+     expect users outside GitLab to be maintainers on this project as
+     well as GitLab team members.
+
+     The latter situation (maintainers from outside GitLab) could also
+     apply if someone who currently works at GitLab wants to maintain
+     the gem beyond their time working at GitLab.
+
+When publishing a gem to RubyGems.org, also note the section on
+[gem owners](https://about.gitlab.com/handbook/developer-onboarding/#ruby-gems)
+in the handbook.
+
+## The `vendor/gems/`
+
+The purpose of `vendor/` is to pull into GitLab monorepo external dependencies,
+which do have external repositories, but for the sake of simplicity we want
+to store them in monorepo:
+
+- The `vendor/gems/` MUST ONLY be used if we are pulling from external repository either via script, or manually.
+- The `vendor/gems/` MUST NOT be used for storing in-house gems.
+- The `vendor/gems/` MAY accept fixes to make them buildable with GitLab monorepo
+- The `gems/` MUST be used for storing all in-house gems that are part of GitLab monorepo.
+- The **RubyGems** MUST be used for all externally stored dependencies that are not in `gems/` in GitLab monorepo.
+
+### Handling of an existing gems in `vendor/gems`
+
+- For in-house Gems that do not have external repository and are currently stored in `vendor/gems/`:
+
+  - For Gems that are used by other repositories:
+
+    - We will migrate it into its own repository.
+    - We will start or continue publishing them via RubyGems.
+    - Those Gems will be referenced via version in `Gemfile` and fetched from RubyGems.
+
+  - For Gems that are only used by monorepo:
+
+    - We will stop publishing new versions to RubyGems.
+    - We will not pull from RubyGems already published versions since there might
+      be applications depedent on those.
+    - We will move those gems to `gems/`.
+    - Those Gems will be referenced via `path:` in `Gemfile`.
+
+- For `vendor/gems/` that are external and vendored in monorepo:
+
+  - We will maintain them in the repository if they require some fixes that cannot be or are not yet upstreamed.
+  - It is expected that vendored gems might be published by third-party.
+  - Those Gems will not be published by us to RubyGems.
+  - Those Gems will be referenced via `path:` in `Gemfile`, since we cannot depend on RubyGems.
diff --git a/doc/development/github_importer.md b/doc/development/github_importer.md
index 73497c22b65..4a24279043d 100644
--- a/doc/development/github_importer.md
+++ b/doc/development/github_importer.md
@@ -149,10 +149,10 @@ comments.
 This worker imports note attachments that are linked inside Markdown.
 For each entity with Markdown text in the project, we schedule a job of:
 
-- `Gitlab::GithubImport::ImportReleaseAttachmentsWorker` for every release.
-- `Gitlab::GithubImport::ImportNoteAttachmentsWorker` for every note.
-- `Gitlab::GithubImport::ImportIssueAttachmentsWorker` for every issue.
-- `Gitlab::GithubImport::ImportMergeRequestAttachmentsWorker` for every merge request.
+- `Gitlab::GithubImport::Importer::Attachments::ReleasesImporter` for every release.
+- `Gitlab::GithubImport::Importer::Attachments::NotesImporter` for every note.
+- `Gitlab::GithubImport::Importer::Attachments::IssuesImporter` for every issue.
+- `Gitlab::GithubImport::Importer::Attachments::MergeRequestsImporter` for every merge request.
 
 Each job:
 
@@ -205,7 +205,7 @@ also reduces pressure on the system as a whole.
 
 GitLab includes a worker called `Gitlab::Import::StuckProjectImportJobsWorker`
 that periodically runs and marks project imports as failed if they have been
-running for more than 15 hours. For GitHub projects, this poses a bit of a
+running for more than 24 hours. For GitHub projects, this poses a bit of a
 problem: importing large projects could take several hours depending on how
 often we hit the GitHub rate limit (more on this below), but we don't want
 `Gitlab::Import::StuckProjectImportJobsWorker` to mark our import as failed because of this.
diff --git a/doc/development/gitlab_shell/index.md b/doc/development/gitlab_shell/index.md
index 0663341f806..ef034761a1f 100644
--- a/doc/development/gitlab_shell/index.md
+++ b/doc/development/gitlab_shell/index.md
@@ -218,5 +218,5 @@ sequenceDiagram
 ## Related topics
 
 - [LICENSE](https://gitlab.com/gitlab-org/gitlab-shell/-/blob/main/LICENSE)
-- [PROCESS.md](https://gitlab.com/gitlab-org/gitlab-shell/-/blob/main/PROCESS.md)
+- [Processes](process.md)
 - [Using the GitLab Shell chart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-shell/)
diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md
index ac14b1b5ea2..12ef454d234 100644
--- a/doc/development/i18n/externalization.md
+++ b/doc/development/i18n/externalization.md
@@ -561,7 +561,7 @@ To include formatting in the translated string, you can do the following:
 - In Ruby/HAML:
 
   ```ruby
-  safe_format(_('Some %{strongOpen}bold%{strongClose} text.'), strongOpen: '<strong>'.html_safe, strongClose: '</strong>'.html_safe)
+  safe_format(_('Some %{strongOpen}bold%{strongClose} text.'), tag_pair(tag.strong, :strongOpen, :strongClose))
   # => 'Some <strong>bold</strong> text.'
   ```
 
@@ -589,7 +589,7 @@ instead:
 - In Ruby/HAML:
 
    ```ruby
-   html_escape_once(_('In &lt; 1 hour')).html_safe
+   safe_format(_('In &lt; 1 hour'))
 
    # => 'In < 1 hour'
    ```
@@ -800,8 +800,8 @@ translatable in certain languages.
 
   ```haml
   - zones_link_url = 'https://cloud.google.com/compute/docs/regions-zones/regions-zones'
-  - zones_link_start = safe_format('<a href="%{url}" target="_blank" rel="noopener noreferrer">', url: zones_link_url)
-  = safe_format(s_('ClusterIntegration|Learn more about %{zones_link_start}zones%{zones_link_end}'), zones_link_start: zones_link_start, zones_link_end: '</a>'.html_safe)
+  - zones_link = link_to('', zones_link_url, target: '_blank', rel: 'noopener noreferrer')
+  = safe_format(s_('ClusterIntegration|Learn more about %{zones_link_start}zones%{zones_link_end}'), tag_pair(zones_link, :zones_link_start, :zones_link_end))
   ```
 
 - In Vue, instead of:
diff --git a/doc/development/i18n/index.md b/doc/development/i18n/index.md
index 0f9688ec26d..b7e385a774a 100644
--- a/doc/development/i18n/index.md
+++ b/doc/development/i18n/index.md
@@ -31,7 +31,7 @@ See [Externalization for GitLab](externalization.md).
 
 ## Translate strings
 
-The translation process is managed at [https://translate.gitlab.com](https://translate.gitlab.com)
+The translation process is managed at [https://crowdin.com/project/gitlab-ee](https://crowdin.com/project/gitlab-ee)
 using [Crowdin](https://crowdin.com/).
 You must create a Crowdin account before you can submit translations. Once you are signed in, select
 the language you wish to contribute translations to.
diff --git a/doc/development/identity_verification.md b/doc/development/identity_verification.md
new file mode 100644
index 00000000000..a0593905879
--- /dev/null
+++ b/doc/development/identity_verification.md
@@ -0,0 +1,110 @@
+---
+stage: Data Science
+group: Anti-Abuse
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Identity verification development
+
+For information on this feature that are not development-specific, see the [feature documentation](../security/identity_verification.md).
+
+## Feature flags
+
+Because of the many registration paths and multiple verification stages, identity verification has several feature flags.
+
+Before you enable these features, ensure [hard email confirmation](../security/user_email_confirmation.md) is enabled and [Arkose](../integration/arkose.md#configuration) is configured properly.
+
+| Feature flag name | Description |
+|---------|-------------|
+| `identity_verification` | Turns on email verification for all registration paths |
+| `identity_verification_phone_number` | Turns on phone verification for medium risk users for all flows (the Arkose challenge flag for the specific flow and the `identity_verification` flag must be enabled for this to have effect) |
+| `identity_verification_credit_card` | Turns on credit card verification for high risk users for all flows (the Arkose challenge flag for the specific flow and the `identity_verification` flag must be enabled for this to have effect) |
+| `arkose_labs_signup_challenge` | Enables Arkose challenge for all flows, except the Trial and OAuth flows |
+| `arkose_labs_trial_signup_challenge` | Enables Arkose challenge for the Trial flow (the `arkose_labs_signup_challenge` flag must be enabled as well for this to have effect) |
+| `arkose_labs_oauth_signup_challenge` | Enables Arkose challenge for the OAuth flow |
+
+## Logging
+
+You can triage and debug issues raised by identity verification with the [GitLab production logs](https://log.gprd.gitlab.net).
+
+### View logs associated to a user and email verification
+
+To view logs associated to the [email stage](../security/identity_verification.md#email-verification) for a user:
+
+- Query the GitLab production logs with the following KQL:
+
+  ```plaintext
+  KQL: json.controller:"IdentityVerificationController" AND json.username:replace_username_here
+  ```
+
+Valuable debugging information can be found in the `json.action` and `json.location` columns.
+
+### View logs associated to a user and phone verification
+
+To view logs associated to the [phone stage](../security/identity_verification.md#phone-number-verification) for a user:
+
+- Query the GitLab production logs with the following KQL:
+
+  ```plaintext
+  KQL: json.message: "IdentityVerification::Phone" AND json.username:replace_username_here
+  ```
+
+On rows where `json.event` is `Failed Attempt`, you can find valuable debugging information in the `json.reason` column such as:
+
+| Reason  | Description |
+|---------|-------------|
+ | `invalid_phone_number` | Either there was a typo in the phone number, or the user used a VOIP number. GitLab does not allow users to sign up with non-mobile phone numbers. |
+| `invalid_code` | The user entered an incorrect verification code. |
+| `rate_limited` | The user had 10 or more failed attempts, so they were rate-limited for one hour. |
+| `related_to_banned_user` | The user tried a phone number already related to a banned user. |
+
+### View logs associated to a user and credit card verification
+
+To view logs associated to the [credit card stage](../security/identity_verification.md#credit-card-verification) for a user:
+
+- Query the GitLab production logs with the following KQL:
+
+  ```plaintext
+  KQL: json.message: "IdentityVerification::CreditCard" AND json.username:replace_username_here
+  ```
+
+On rows where `json.event` is `Failed Attempt`, you can find valuable debugging information in the `json.reason` column such as:
+
+| Reason  | Description |
+|---------|-------------|
+| `rate_limited` | The user had 10 or more failed attempts, so they were rate-limited for one hour. |
+| `related_to_banned_user` | The user tried a credit card number already related to a banned user. |
+
+### View logs associated with high-risk users
+
+To view logs associated with the [credit card stage](../security/identity_verification.md#credit-card-verification) for high-risk users:
+
+- Query the GitLab production logs with the following KQL:
+
+  ```plaintext
+  json.controller:"SubscriptionsController" AND json.action:"payment_form" AND json.params.value:"cc_registration_validation"
+  ```
+
+## Code walkthrough
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For a walkthrough and high level explanation of the code, see [Identity Verification - Code walkthrough](https://www.youtube.com/watch?v=DIsnMiNzND8).
+
+## QA Integration
+
+For end-to-end production and staging tests to function properly, GitLab [allows QA users to bypass identity verification](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117633).
+
+## Additional resources
+
+<!-- markdownlint-disable MD044 -->
+The [Anti-abuse team](https://about.gitlab.com/handbook/engineering/development/data-science/anti-abuse/#team-members) owns identity verification. You can join our channel on Slack: [#g_anti-abuse](https://gitlab.slack.com/archives/C03EH5HCLPR).
+<!-- markdownlint-enable MD044 -->
+
+For help with Telesign:
+
+<!-- markdownlint-disable MD044 -->
+- Telesign/GitLab collaboration channel on Slack: [#gitlab-telesign-support](https://gitlab.slack.com/archives/C052EAXB6BY)
+<!-- markdownlint-enable MD044 -->
+- Telesign support contact: `support@telesign.com`
+- [Telesign portal](https://teleportal.telesign.com/)
+- [Telesign documentation](https://developer.telesign.com/enterprise/docs/get-started-with-docs)
diff --git a/doc/development/import_project.md b/doc/development/import_project.md
index ed5854f8833..0be17ea5873 100644
--- a/doc/development/import_project.md
+++ b/doc/development/import_project.md
@@ -52,6 +52,12 @@ There is also an option to [import the project via GitHub](../user/project/impor
 
 This method takes longer to import than the other methods and depends on several factors. It's recommended to use the other methods.
 
+To test importing from GitHub Enterprise (GHE) to GitLab, you need a GHE instance. You can request a
+[GitHub Enterprise Server trial](https://docs.github.com/en/get-started/signing-up-for-github/setting-up-a-trial-of-github-enterprise-server) and install it on Google Cloud Platform.
+
+- GitLab team members can use [Sandbox Cloud Realm](https://about.gitlab.com/handbook/infrastructure-standards/realms/sandbox/) for this purpose.
+- Others can request a [Google Cloud Platforms free trial](https://cloud.google.com/free).
+
 ### Import by using a Rake task
 
 To import the test project by using a Rake task, see
diff --git a/doc/development/integrations/index.md b/doc/development/integrations/index.md
index 4c66dbfa1a4..b51a2799088 100644
--- a/doc/development/integrations/index.md
+++ b/doc/development/integrations/index.md
@@ -10,7 +10,7 @@ description: "GitLab's development guidelines for Integrations"
 This page provides development guidelines for implementing [GitLab integrations](../../user/project/integrations/index.md),
 which are part of our [main Rails project](https://gitlab.com/gitlab-org/gitlab).
 
-Also see our [direction page](https://about.gitlab.com/direction/manage/integrations/) for an overview of our strategy around integrations.
+Also see our [direction page](https://about.gitlab.com/direction/manage/import_and_integrate/integrations/) for an overview of our strategy around integrations.
 
 This guide is a work in progress. You're welcome to ping `@gitlab-org/manage/integrations`
 if you need clarification or spot any outdated information.
@@ -300,6 +300,40 @@ All UI strings should be prepared for translation by following our [internationa
 
 The strings should use the integration name as [namespace](../i18n/externalization.md#namespaces), for example, `s_('FooBarIntegration|My string')`.
 
+## Deprecate and remove an integration
+
+To remove an integration, you must first deprecate the integration. For more information,
+see the [feature deprecation guidelines](../../development/deprecation_guidelines/index.md).
+
+### Deprecate an integration
+
+You must announce any deprecation [no later than the third milestone preceding intended removal](../../development/deprecation_guidelines/index.md#when-can-a-feature-be-deprecated).
+To deprecate an integration:
+
+- [Add a deprecation entry](../../development/deprecation_guidelines/index.md#update-the-deprecations-and-removals-documentation-pages).
+- [Mark the integration documentation as deprecated](../../development/documentation/versions.md#deprecate-a-page-or-topic).
+- Optional. To prevent any new project-level records from
+  being created, add the integration to `Project#disabled_integrations` (see [example merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114835)).
+
+### Remove an integration
+
+To safely remove an integration, you must stage the removal across two milestones.
+
+In the major milestone of intended removal (M.0), disable the integration and delete the records from the database:
+
+- Remove the integration from `Integration::INTEGRATION_NAMES`.
+- Delete the integration model's `#execute` and `#test` methods (if defined), but keep the model.
+- Add a post-migration to delete the integration records from PostgreSQL (see [example merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114721)).
+- [Add a removal entry](../../development/deprecation_guidelines/index.md#update-the-deprecations-and-removals-documentation-pages).
+- [Mark the integration documentation as removed](../../development/documentation/versions.md#remove-a-page).
+- [Update the integration API documentation](../../api/integrations.md).
+
+In the next minor release (M.1):
+
+- Remove the integration's model and any remaining code.
+- Close any issues, merge requests, and epics that have the integration's label (`~Integration::<name>`).
+- Delete the integration's label (`~Integration::<name>`) from `gitlab-org`.
+
 ## Ongoing migrations and refactorings
 
 Developers should be aware that the Integrations team is in the process of
diff --git a/doc/development/integrations/jenkins.md b/doc/development/integrations/jenkins.md
index 43487486f97..65194a04a62 100644
--- a/doc/development/integrations/jenkins.md
+++ b/doc/development/integrations/jenkins.md
@@ -24,7 +24,8 @@ brew services start jenkins
 GitLab does not allow requests to localhost or the local network by default. When running Jenkins on your local machine, you need to enable local access.
 
 1. Log into your GitLab instance as an administrator.
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Network**.
 1. Expand **Outbound requests**, and select the following checkboxes:
 
diff --git a/doc/development/internal_analytics/index.md b/doc/development/internal_analytics/index.md
new file mode 100644
index 00000000000..8abea4c2b2f
--- /dev/null
+++ b/doc/development/internal_analytics/index.md
@@ -0,0 +1,12 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Internal analytics
+
+Learn how to implement internal analytics using:
+
+- [Service Ping](service_ping/index.md)
+- [Snowplow](snowplow/index.md)
diff --git a/doc/development/internal_analytics/service_ping/implement.md b/doc/development/internal_analytics/service_ping/implement.md
new file mode 100644
index 00000000000..0dfc3806712
--- /dev/null
+++ b/doc/development/internal_analytics/service_ping/implement.md
@@ -0,0 +1,882 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Implement Service Ping
+
+Service Ping consists of two kinds of data:
+
+- **Counters**: Track how often a certain event happened over time, such as how many CI/CD pipelines have run.
+  They are monotonic and usually trend up.
+- **Observations**: Facts collected from one or more GitLab instances and can carry arbitrary data.
+  There are no general guidelines for how to collect those, due to the individual nature of that data.
+
+To implement a new metric in Service Ping, follow these steps:
+
+1. [Implement the required counter](#types-of-counters)
+1. [Name and place the metric](metrics_dictionary.md#metric-key_path)
+1. [Test counters manually using your Rails console](#test-counters-manually-using-your-rails-console)
+1. [Generate the SQL query](#generate-the-sql-query)
+1. [Optimize queries with Database Lab](#optimize-queries-with-database-lab)
+1. [Add the metric definition to the Metrics Dictionary](#add-the-metric-definition)
+1. [Add the metric to the Versions Application](#add-the-metric-to-the-versions-application)
+1. [Create a merge request](#create-a-merge-request)
+1. [Verify your metric](#verify-your-metric)
+1. [Set up and test Service Ping locally](#set-up-and-test-service-ping-locally)
+
+## Instrumentation classes
+
+NOTE:
+Implementing metrics directly in `usage_data.rb` is deprecated.
+When you add or change a Service Ping Metric, you must migrate metrics to [instrumentation classes](metrics_instrumentation.md).
+For information about the progress on migrating Service Ping metrics, see this [epic](https://gitlab.com/groups/gitlab-org/-/epics/5547).
+
+For example, we have the following instrumentation class:
+`lib/gitlab/usage/metrics/instrumentations/count_boards_metric.rb`.
+
+You should add it to `usage_data.rb` as follows:
+
+```ruby
+boards: add_metric('CountBoardsMetric', time_frame: 'all'),
+```
+
+## Types of counters
+
+There are several types of counters for metrics:
+
+- **[Batch counters](#batch-counters)**: Used for counts, sums, and averages.
+- **[Redis counters](#redis-counters):** Used for in-memory counts.
+- **[Alternative counters](#alternative-counters):** Used for settings and configurations.
+
+NOTE:
+Only use the provided counter methods. Each counter method contains a built-in fail-safe mechanism that isolates each counter to avoid breaking the entire Service Ping process.
+
+### Batch counters
+
+For large tables, PostgreSQL can take a long time to count rows due to MVCC [(Multi-version Concurrency Control)](https://en.wikipedia.org/wiki/Multiversion_concurrency_control). Batch counting is a counting method where a single large query is broken into multiple smaller queries. For example, instead of a single query querying 1,000,000 records, with batch counting, you can execute 100 queries of 10,000 records each. Batch counting is useful for avoiding database timeouts as each batch query is significantly shorter than one single long running query.
+
+For GitLab.com, there are extremely large tables with 15 second query timeouts, so we use batch counting to avoid encountering timeouts. Here are the sizes of some GitLab.com tables:
+
+| Table                        | Row counts in millions |
+|------------------------------|------------------------|
+| `merge_request_diff_commits` | 2280                   |
+| `ci_build_trace_sections`    | 1764                   |
+| `merge_request_diff_files`   | 1082                   |
+| `events`                     | 514                    |
+
+Batch counting requires indexes on columns to calculate max, min, and range queries. In some cases,
+you must add a specialized index on the columns involved in a counter.
+
+#### Ordinary batch counters
+
+Create a new [database metrics](metrics_instrumentation.md#database-metrics) instrumentation class with `count` operation for a given `ActiveRecord_Relation`
+
+Method:
+
+```ruby
+add_metric('CountIssuesMetric', time_frame: 'all')
+```
+
+Examples:
+
+Examples using `usage_data.rb` have been [deprecated](usage_data.md). We recommend to use [instrumentation classes](metrics_instrumentation.md).
+
+#### Distinct batch counters
+
+Create a new [database metrics](metrics_instrumentation.md#database-metrics) instrumentation class with `distinct_count` operation for a given `ActiveRecord_Relation`.
+
+Method:
+
+```ruby
+add_metric('CountUsersAssociatingMilestonesToReleasesMetric', time_frame: 'all')
+```
+
+WARNING:
+Counting over non-unique columns can lead to performance issues. For more information, see the [iterating tables in batches](../../database/iterating_tables_in_batches.md) guide.
+
+Examples:
+
+Examples using `usage_data.rb` have been [deprecated](usage_data.md). We recommend to use [instrumentation classes](metrics_instrumentation.md).
+
+#### Sum batch operation
+
+Sum the values of a given ActiveRecord_Relation on given column and handles errors.
+Handles the `ActiveRecord::StatementInvalid` error
+
+Method:
+
+```ruby
+add_metric('JiraImportsTotalImportedIssuesCountMetric')
+```
+
+#### Average batch operation
+
+Average the values of a given `ActiveRecord_Relation` on given column and handles errors.
+
+Method:
+
+```ruby
+add_metric('CountIssuesWeightAverageMetric')
+```
+
+Examples:
+
+Examples using `usage_data.rb` have been [deprecated](usage_data.md). We recommend to use [instrumentation classes](metrics_instrumentation.md).
+
+#### Grouping and batch operations
+
+The `count`, `distinct_count` and `sum` batch counters can accept an `ActiveRecord::Relation`
+object, which groups by a specified column. With a grouped relation, the methods do batch counting,
+handle errors, and returns a hash table of key-value pairs.
+
+Examples:
+
+```ruby
+count(Namespace.group(:type))
+# returns => {nil=>179, "Group"=>54}
+
+distinct_count(Project.group(:visibility_level), :creator_id)
+# returns => {0=>1, 10=>1, 20=>11}
+
+sum(Issue.group(:state_id), :weight))
+# returns => {1=>3542, 2=>6820}
+```
+
+#### Add operation
+
+Sum the values given as parameters. Handles the `StandardError`.
+Returns `-1` if any of the arguments are `-1`.
+
+Method:
+
+```ruby
+add(*args)
+```
+
+Examples:
+
+```ruby
+project_imports = distinct_count(::Project.where.not(import_type: nil), :creator_id)
+bulk_imports = distinct_count(::BulkImport, :user_id)
+
+ add(project_imports, bulk_imports)
+```
+
+#### Estimated batch counters
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48233) in GitLab 13.7.
+
+Estimated batch counter functionality handles `ActiveRecord::StatementInvalid` errors
+when used through the provided `estimate_batch_distinct_count` method.
+Errors return a value of `-1`.
+
+WARNING:
+This functionality estimates a distinct count of a specific ActiveRecord_Relation in a given column,
+which uses the [HyperLogLog](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/40671.pdf) algorithm.
+As the HyperLogLog algorithm is probabilistic, the **results always include error**.
+The highest encountered error rate is 4.9%.
+
+When correctly used, the `estimate_batch_distinct_count` method enables efficient counting over
+columns that contain non-unique values, which cannot be assured by other counters.
+
+##### `estimate_batch_distinct_count` method
+
+Method:
+
+```ruby
+estimate_batch_distinct_count(relation, column = nil, batch_size: nil, start: nil, finish: nil)
+```
+
+The [method](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/utils/usage_data.rb#L63)
+includes the following arguments:
+
+- `relation`: The ActiveRecord_Relation to perform the count.
+- `column`: The column to perform the distinct count. The default is the primary key.
+- `batch_size`: From `Gitlab::Database::PostgresHll::BatchDistinctCounter::DEFAULT_BATCH_SIZE`. Default value: 10,000.
+- `start`: The custom start of the batch count, to avoid complex minimum calculations.
+- `finish`: The custom end of the batch count to avoid complex maximum calculations.
+
+The method includes the following prerequisites:
+
+- The supplied `relation` must include the primary key defined as the numeric column.
+  For example: `id bigint NOT NULL`.
+- The `estimate_batch_distinct_count` can handle a joined relation. To use its ability to
+  count non-unique columns, the joined relation **must not** have a one-to-many relationship,
+  such as `has_many :boards`.
+- Both `start` and `finish` arguments should always represent primary key relationship values,
+  even if the estimated count refers to another column, for example:
+
+  ```ruby
+    estimate_batch_distinct_count(::Note, :author_id, start: ::Note.minimum(:id), finish: ::Note.maximum(:id))
+  ```
+
+Examples:
+
+1. Simple execution of estimated batch counter, with only relation provided,
+   returned value represents estimated number of unique values in `id` column
+   (which is the primary key) of `Project` relation:
+
+   ```ruby
+     estimate_batch_distinct_count(::Project)
+   ```
+
+1. Execution of estimated batch counter, where provided relation has applied
+   additional filter (`.where(time_period)`), number of unique values estimated
+   in custom column (`:author_id`), and parameters: `start` and `finish` together
+   apply boundaries that defines range of provided relation to analyze:
+
+   ```ruby
+     estimate_batch_distinct_count(::Note.with_suggestions.where(time_period), :author_id, start: ::Note.minimum(:id), finish: ::Note.maximum(:id))
+   ```
+
+When instrumenting metric with usage of estimated batch counter please add
+`_estimated` suffix to its name, for example:
+
+```ruby
+  "counts": {
+    "ci_builds_estimated": estimate_batch_distinct_count(Ci::Build),
+    ...
+```
+
+### Redis counters
+
+Handles `::Redis::CommandError` and `Gitlab::UsageDataCounters::BaseCounter::UnknownEvent`.
+Returns -1 when a block is sent or hash with all values and -1 when a `counter(Gitlab::UsageDataCounters)` is sent.
+The different behavior is due to 2 different implementations of the Redis counter.
+
+Method:
+
+```ruby
+redis_usage_data(counter, &block)
+```
+
+Arguments:
+
+- `counter`: a counter from `Gitlab::UsageDataCounters`, that has `fallback_totals` method implemented
+- or a `block`: which is evaluated
+
+#### Ordinary Redis counters
+
+Example of implementation: [`Gitlab::UsageDataCounters::WikiPageCounter`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/wiki_page_counter.rb), using Redis methods [`INCR`](https://redis.io/commands/incr/) and [`GET`](https://redis.io/commands/get/).
+
+Events are handled by counter classes in the `Gitlab::UsageDataCounters` namespace, inheriting from `BaseCounter`, that are either:
+
+1. Listed in [`Gitlab::UsageDataCounters::COUNTERS`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters.rb#L5) to be then included in `Gitlab::UsageData`.
+
+1. Specified in the metric definition using the `RedisMetric` instrumentation class by their `prefix` option to be picked up using the [metric instrumentation](metrics_instrumentation.md) framework. Refer to the [Redis metrics](metrics_instrumentation.md#redis-metrics) documentation for an example implementation.
+
+Inheriting classes are expected to override `KNOWN_EVENTS` and `PREFIX` constants to build event names and associated metrics. For example, for prefix `issues` and events array `%w[create, update, delete]`, three metrics will be added to the Service Ping payload: `counts.issues_create`, `counts.issues_update` and `counts.issues_delete`.
+
+##### `UsageData` API
+
+You can use the `UsageData` API to track events.
+To track events, the `usage_data_api` feature flag must
+be enabled (set to `default_enabled: true`).
+Enabled by default in GitLab 13.7 and later.
+
+##### UsageData API tracking
+
+1. Track events using the [`UsageData` API](#usagedata-api).
+
+   Increment event count using an ordinary Redis counter, for a given event name.
+
+   API requests are protected by checking for a valid CSRF token.
+
+   ```plaintext
+   POST /usage_data/increment_counter
+   ```
+
+   | Attribute | Type | Required | Description |
+   | :-------- | :--- | :------- | :---------- |
+   | `event` | string | yes | The event name to track. |
+
+   Response:
+
+   - `200` if the event was tracked.
+   - `400 Bad request` if the event parameter is missing.
+   - `401 Unauthorized` if the user is not authenticated.
+   - `403 Forbidden` if an invalid CSRF token is provided.
+
+1. Track events using the JavaScript/Vue API helper which calls the [`UsageData` API](#usagedata-api).
+
+   To track events, `usage_data_api` and `usage_data_#{event_name}` must be enabled.
+
+   ```javascript
+   import api from '~/api';
+
+   api.trackRedisCounterEvent('my_already_defined_event_name'),
+   ```
+
+#### Redis HLL counters
+
+WARNING:
+HyperLogLog (HLL) is a probabilistic algorithm and its **results always includes some small error**. According to [Redis documentation](https://redis.io/commands/pfcount/), data from
+used HLL implementation is "approximated with a standard error of 0.81%".
+
+NOTE:
+ A user's consent for `usage_stats` (`User.single_user&.requires_usage_stats_consent?`) is not checked during the data tracking stage due to performance reasons. Keys corresponding to those counters are present in Redis even if `usage_stats_consent` is still required. However, no metric is collected from Redis and reported back to GitLab as long as `usage_stats_consent` is required.
+
+With `Gitlab::UsageDataCounters::HLLRedisCounter` we have available data structures used to count unique values.
+
+Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd/) and [PFCOUNT](https://redis.io/commands/pfcount/).
+
+##### Add new events
+
+1. Define events in [`known_events`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/).
+
+   Example event:
+
+   ```yaml
+   - name: users_creating_epics
+     aggregation: weekly
+   ```
+
+   Keys:
+
+   - `name`: unique event name.
+
+     Name format for Redis HLL events `{hll_counters}_<name>`
+
+     Example names: `users_creating_epics`, `users_triggering_security_scans`.
+
+   - `aggregation`: may be set to a `:daily` or `:weekly` key. Defines how counting data is stored in Redis.
+     Aggregation on a `daily` basis does not pull more fine grained data.
+
+1. Use one of the following methods to track the event:
+
+   - In the controller using the `ProductAnalyticsTracking` module and the following format:
+
+     ```ruby
+     track_event(*controller_actions, name:, action:, label:, conditions: nil, destinations: [:redis_hll], &block)
+     ```
+
+     Arguments:
+
+     - `controller_actions`: the controller actions to track.
+     - `name`: the event name.
+     - `action`: required if destination is `:snowplow. Action name for the triggered event. See [event schema](../snowplow/index.md#event-schema) for more details.
+     - `label`: required if destination is `:snowplow. Label for the triggered event. See [event schema](../snowplow/index.md#event-schema) for more details.
+     - `conditions`: optional custom conditions. Uses the same format as Rails callbacks.
+     - `destinations`: optional list of destinations. Currently supports `:redis_hll` and `:snowplow`. Default: `:redis_hll`.
+     - `&block`: optional block that computes and returns the `custom_id` that we want to track. This overrides the `visitor_id`.
+
+     Example:
+
+     ```ruby
+     # controller
+     class ProjectsController < Projects::ApplicationController
+       include ProductAnalyticsTracking
+
+       skip_before_action :authenticate_user!, only: :show
+       track_event :index, :show,
+         name: 'users_visiting_projects',
+         action: 'user_perform_visit',
+         label: 'redis_hll_counters.users_visiting_project_monthly',
+         destinations: %i[redis_hll snowplow]
+
+       def index
+         render html: 'index'
+       end
+
+      def new
+        render html: 'new'
+      end
+
+      def show
+        render html: 'show'
+      end
+     end
+     ```
+
+   - In the API using the `increment_unique_values(event_name, values)` helper method.
+
+     Arguments:
+
+     - `event_name`: the event name.
+     - `values`: the values counted. Can be one value or an array of values.
+
+     Example:
+
+     ```ruby
+     get ':id/registry/repositories' do
+       repositories = ContainerRepositoriesFinder.new(
+         user: current_user, subject: user_group
+       ).execute
+
+       increment_unique_values('users_listing_repositories', current_user.id)
+
+       present paginate(repositories), with: Entities::ContainerRegistry::Repository, tags: params[:tags], tags_count: params[:tags_count]
+     end
+     ```
+
+   - Using `track_usage_event(event_name, values)` in services and GraphQL.
+
+     Increment unique values count using Redis HLL, for a given event name.
+
+     Examples:
+
+     - [Track usage event for an incident in a service](https://gitlab.com/gitlab-org/gitlab/-/blob/v13.8.3-ee/app/services/issues/update_service.rb#L66)
+     - [Track usage event for an incident in GraphQL](https://gitlab.com/gitlab-org/gitlab/-/blob/v13.8.3-ee/app/graphql/mutations/alert_management/update_alert_status.rb#L16)
+
+     ```ruby
+       track_usage_event(:incident_management_incident_created, current_user.id)
+     ```
+
+   - Using the [`UsageData` API](#usagedata-api).
+
+     Increment unique users count using Redis HLL, for a given event name.
+
+     API requests are protected by checking for a valid CSRF token.
+
+     ```plaintext
+     POST /usage_data/increment_unique_users
+     ```
+
+     | Attribute | Type | Required | Description |
+     | :-------- | :--- | :------- | :---------- |
+     | `event` | string | yes | The event name to track |
+
+     Response:
+
+     - `200` if the event was tracked, or if tracking failed for any reason.
+     - `400 Bad request` if an event parameter is missing.
+     - `401 Unauthorized` if the user is not authenticated.
+     - `403 Forbidden` if an invalid CSRF token is provided.
+
+   - Using the JavaScript/Vue API helper, which calls the [`UsageData` API](#usagedata-api).
+
+     Example for an existing event already defined in [known events](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/):
+
+     ```javascript
+     import api from '~/api';
+
+     api.trackRedisHllUserEvent('my_already_defined_event_name'),
+     ```
+
+1. Get event data using `Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names:, start_date:, end_date:, context: '')`.
+
+   Arguments:
+
+   - `event_names`: the list of event names.
+   - `start_date`: start date of the period for which we want to get event data.
+   - `end_date`: end date of the period for which we want to get event data.
+   - `context`: context of the event. Allowed values are `default`, `free`, `bronze`, `silver`, `gold`, `starter`, `premium`, `ultimate`.
+
+1. Testing tracking and getting unique events
+
+Trigger events in rails console by using `track_event` method
+
+   ```ruby
+   Gitlab::UsageDataCounters::HLLRedisCounter.track_event('users_viewing_compliance_audit_events', values: 1)
+   Gitlab::UsageDataCounters::HLLRedisCounter.track_event('users_viewing_compliance_audit_events', values: [2, 3])
+   ```
+
+Next, get the unique events for the current week.
+
+   ```ruby
+   # Get unique events for metric for current_week
+   Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'users_viewing_compliance_audit_events',
+   start_date: Date.current.beginning_of_week, end_date: Date.current.next_week)
+   ```
+
+##### Recommendations
+
+We have the following recommendations for [adding new events](#add-new-events):
+
+- Event aggregation: weekly.
+- When adding new metrics, use a [feature flag](../../../operations/feature_flags.md) to control the impact.
+It's recommended to disable the new feature flag by default (set `default_enabled: false`).
+- Events can be triggered using the `UsageData` API, which helps when there are > 10 events per change
+
+##### Enable or disable Redis HLL tracking
+
+We can disable tracking completely by using the global flag:
+
+```shell
+/chatops run feature set redis_hll_tracking true
+/chatops run feature set redis_hll_tracking false
+```
+
+##### Known events are added automatically in Service Data payload
+
+Service Ping adds all events [`known_events/*.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events) to Service Data generation under the `redis_hll_counters` key. This column is stored in [version-app as a JSON](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/db/schema.rb#L209).
+For each event we add metrics for the weekly and monthly time frames, and totals for each where applicable:
+
+- `#{event_name}_weekly`: Data for 7 days for daily [aggregation](#add-new-events) events and data for the last complete week for weekly [aggregation](#add-new-events) events.
+- `#{event_name}_monthly`: Data for 28 days for daily [aggregation](#add-new-events) events and data for the last 4 complete weeks for weekly [aggregation](#add-new-events) events.
+
+Example of `redis_hll_counters` data:
+
+```ruby
+{:redis_hll_counters=>
+  {"compliance"=>
+    {"users_viewing_compliance_dashboard_weekly"=>0,
+     "users_viewing_compliance_dashboard_monthly"=>0,
+     "users_viewing_compliance_audit_events_weekly"=>0,
+     "users_viewing_audit_events_monthly"=>0,
+     "compliance_total_unique_counts_weekly"=>0,
+     "compliance_total_unique_counts_monthly"=>0},
+ "analytics"=>
+    {"users_viewing_analytics_group_devops_adoption_weekly"=>0,
+     "users_viewing_analytics_group_devops_adoption_monthly"=>0,
+     "analytics_total_unique_counts_weekly"=>0,
+     "analytics_total_unique_counts_monthly"=>0},
+   "ide_edit"=>
+    {"users_editing_by_web_ide_weekly"=>0,
+     "users_editing_by_web_ide_monthly"=>0,
+     "users_editing_by_sfe_weekly"=>0,
+     "users_editing_by_sfe_monthly"=>0,
+     "ide_edit_total_unique_counts_weekly"=>0,
+     "ide_edit_total_unique_counts_monthly"=>0}
+ }
+}
+```
+
+Example:
+
+```ruby
+# Redis Counters
+redis_usage_data(Gitlab::UsageDataCounters::WikiPageCounter)
+
+# Define events in common.yml https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/common.yml
+
+# Tracking events
+Gitlab::UsageDataCounters::HLLRedisCounter.track_event('users_expanding_vulnerabilities', values: visitor_id)
+
+# Get unique events for metric
+redis_usage_data { Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'users_expanding_vulnerabilities', start_date: 28.days.ago, end_date: Date.current) }
+```
+
+### Alternative counters
+
+Handles `StandardError` and fallbacks into -1 this way not all measures fail if we encounter one exception.
+Mainly used for settings and configurations.
+
+Method:
+
+```ruby
+alt_usage_data(value = nil, fallback: -1, &block)
+```
+
+Arguments:
+
+- `value`: a static value in which case the value is returned.
+- or a `block`: which is evaluated
+- `fallback: -1`: the common value used for any metrics that are failing.
+
+Example:
+
+```ruby
+alt_usage_data { Gitlab::VERSION }
+alt_usage_data { Gitlab::CurrentSettings.uuid }
+alt_usage_data(999)
+```
+
+### Add counters to build new metrics
+
+When adding the results of two counters, use the `add` Service Data method that
+handles fallback values and exceptions. It also generates a valid [SQL export](index.md#export-service-ping-data).
+
+Example:
+
+```ruby
+add(User.active, User.bot)
+```
+
+### Prometheus queries
+
+In those cases where operational metrics should be part of Service Ping, a database or Redis query is unlikely
+to provide useful data. Instead, Prometheus might be more appropriate, because most GitLab architectural
+components publish metrics to it that can be queried back, aggregated, and included as Service Data.
+
+NOTE:
+Prometheus as a data source for Service Ping is only available for single-node Omnibus installations
+that are running the [bundled Prometheus](../../../administration/monitoring/prometheus/index.md) instance.
+
+To query Prometheus for metrics, a helper method is available to `yield` a fully configured
+`PrometheusClient`, given it is available as per the note above:
+
+```ruby
+with_prometheus_client do |client|
+  response = client.query('<your query>')
+  ...
+end
+```
+
+Refer to [the `PrometheusClient` definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/prometheus_client.rb)
+for how to use its API to query for data.
+
+### Fallback values for Service Ping
+
+We return fallback values in these cases:
+
+| Case                        | Value |
+|-----------------------------|-------|
+| Deprecated Metric ([Removed with version 14.3](https://gitlab.com/gitlab-org/gitlab/-/issues/335894)) | -1000 |
+| Timeouts, general failures  | -1    |
+| Standard errors in counters | -2    |
+| Histogram metrics failure   | { '-1' => -1 } |
+
+## Test counters manually using your Rails console
+
+```ruby
+# count
+Gitlab::UsageData.count(User.active)
+Gitlab::UsageData.count(::Clusters::Cluster.aws_installed.enabled, :cluster_id)
+
+# count distinct
+Gitlab::UsageData.distinct_count(::Project, :creator_id)
+Gitlab::UsageData.distinct_count(::Note.with_suggestions.where(time_period), :author_id, start: ::User.minimum(:id), finish: ::User.maximum(:id))
+```
+
+## Generate the SQL query
+
+Your Rails console returns the generated SQL queries. For example:
+
+```ruby
+pry(main)> Gitlab::UsageData.count(User.active)
+   (2.6ms)  SELECT "features"."key" FROM "features"
+   (15.3ms)  SELECT MIN("users"."id") FROM "users" WHERE ("users"."state" IN ('active')) AND ("users"."user_type" IS NULL OR "users"."user_type" IN (6, 4))
+   (2.4ms)  SELECT MAX("users"."id") FROM "users" WHERE ("users"."state" IN ('active')) AND ("users"."user_type" IS NULL OR "users"."user_type" IN (6, 4))
+   (1.9ms)  SELECT COUNT("users"."id") FROM "users" WHERE ("users"."state" IN ('active')) AND ("users"."user_type" IS NULL OR "users"."user_type" IN (6, 4)) AND "users"."id" BETWEEN 1 AND 100000
+```
+
+## Optimize queries with Database Lab
+
+[Database Lab](../../database/database_lab.md) is a service that uses a production clone to test queries.
+
+- GitLab.com's production database has a 15 second timeout.
+- Any single query must stay below the [1 second execution time](../../database/query_performance.md#timing-guidelines-for-queries) with cold caches.
+- Add a specialized index on columns involved to reduce the execution time.
+
+To understand the query's execution, we add the following information
+to a merge request description:
+
+- For counters that have a `time_period` test, we add information for both:
+  - `time_period = {}` for all time periods.
+  - `time_period = { created_at: 28.days.ago..Time.current }` for the last 28 days.
+- Execution plan and query time before and after optimization.
+- Query generated for the index and time.
+- Migration output for up and down execution.
+
+For more details, see the [database review guide](../../database_review.md#preparation-when-adding-or-modifying-queries).
+
+### Optimization recommendations and examples
+
+- Use specialized indexes. For examples, see these merge requests:
+  - [Example 1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26871)
+  - [Example 2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26445)
+- Use defined `start` and `finish`. These values can be memoized and reused, as in this
+  [example merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37155).
+- Avoid joins and unnecessary complexity in your queries. See this
+  [example merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36316) as an example.
+- Set a custom `batch_size` for `distinct_count`, as in this [example merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38000).
+
+## Add the metric definition
+
+See the [Metrics Dictionary guide](metrics_dictionary.md) for more information.
+
+## Add the metric to the Versions Application
+
+Check if the new metric must be added to the Versions Application. See the `usage_data` [schema](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/db/schema.rb#L147) and Service Data [parameters accepted](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/app/services/usage_ping.rb). Any metrics added under the `counts` key are saved in the `stats` column.
+
+## Create a merge request
+
+Create a merge request for the new Service Ping metric, and do the following:
+
+- Add the `feature` label to the merge request. A metric is a user-facing change and is part of expanding the Service Ping feature.
+- Add a changelog entry that complies with the [changelog entries guide](../../changelog.md).
+- Ask for an Analytics Instrumentation review.
+  On GitLab.com, we have DangerBot set up to monitor Analytics Instrumentation related files and recommend a [Analytics Instrumentation review](review_guidelines.md).
+
+## Verify your metric
+
+On GitLab.com, the Product Intelligence team regularly [monitors Service Ping](https://gitlab.com/groups/gitlab-org/-/epics/6000).
+They may alert you that your metrics need further optimization to run quicker and with greater success.
+
+The Service Ping JSON payload for GitLab.com is shared in the
+[#g_product_intelligence](https://gitlab.slack.com/archives/CL3A7GFPF) Slack channel every week.
+
+You may also use the [Service Ping QA dashboard](https://app.periscopedata.com/app/gitlab/632033/Usage-Ping-QA) to check how well your metric performs.
+The dashboard allows filtering by GitLab version, by "Self-managed" and "SaaS", and shows you how many failures have occurred for each metric. Whenever you notice a high failure rate, you can re-optimize your metric.
+
+Use [Metrics Dictionary](https://metrics.gitlab.com/) [copy query to clipboard feature](https://www.youtube.com/watch?v=n4o65ivta48&list=PL05JrBw4t0Krg3mbR6chU7pXtMt_es6Pb) to get a query ready to run in Sisense for a specific metric.
+
+## Set up and test Service Ping locally
+
+To set up Service Ping locally, you must:
+
+1. [Set up local repositories](#set-up-local-repositories).
+1. [Test local setup](#test-local-setup).
+1. Optional. [Test Prometheus-based Service Ping](#test-prometheus-based-service-ping).
+
+### Set up local repositories
+
+1. Clone and start [GitLab](https://gitlab.com/gitlab-org/gitlab-development-kit).
+1. Clone and start [Versions Application](https://gitlab.com/gitlab-services/version-gitlab-com).
+   Make sure you run `docker-compose up` to start a PostgreSQL and Redis instance.
+1. Point GitLab to the Versions Application endpoint instead of the default endpoint:
+   1. Open [service_ping/submit_service.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/service_ping/submit_service.rb#L5) locally and modify `STAGING_BASE_URL`.
+   1. Set it to the local Versions Application URL: `http://localhost:3000`.
+
+### Test local setup
+
+1. Using the `gitlab` Rails console, manually trigger Service Ping:
+
+   ```ruby
+   GitlabServicePingWorker.new.perform('triggered_from_cron' => false)
+   ```
+
+1. Use the `versions` Rails console to check the Service Ping was successfully received,
+   parsed, and stored in the Versions database:
+
+   ```ruby
+   UsageData.last
+   ```
+
+## Test Prometheus-based Service Ping
+
+If the data submitted includes metrics [queried from Prometheus](#prometheus-queries)
+you want to inspect and verify, you must:
+
+- Ensure that a Prometheus server is running locally.
+- Ensure the respective GitLab components are exporting metrics to the Prometheus server.
+
+If you do not need to test data coming from Prometheus, no further action
+is necessary. Service Ping should degrade gracefully in the absence of a running Prometheus server.
+
+Three kinds of components may export data to Prometheus, and are included in Service Ping:
+
+- [`node_exporter`](https://github.com/prometheus/node_exporter): Exports node metrics
+  from the host machine.
+- [`gitlab-exporter`](https://gitlab.com/gitlab-org/gitlab-exporter): Exports process metrics
+  from various GitLab components.
+- Other various GitLab services, such as Sidekiq and the Rails server, which export their own metrics.
+
+### Test with an Omnibus container
+
+This is the recommended approach to test Prometheus-based Service Ping.
+
+To verify your change, build a new Omnibus image from your code branch using CI/CD, download the image,
+and run a local container instance:
+
+1. From your merge request, select the `qa` stage, then trigger the `e2e:package-and-test` job. This job triggers an Omnibus
+   build in a [downstream pipeline of the `omnibus-gitlab-mirror` project](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/-/pipelines).
+1. In the downstream pipeline, wait for the `gitlab-docker` job to finish.
+1. Open the job logs and locate the full container name including the version. It takes the following form: `registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<VERSION>`.
+1. On your local machine, make sure you are signed in to the GitLab Docker registry. You can find the instructions for this in
+   [Authenticate to the GitLab Container Registry](../../../user/packages/container_registry/authenticate_with_container_registry.md).
+1. Once signed in, download the new image by using `docker pull registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<VERSION>`
+1. For more information about working with and running Omnibus GitLab containers in Docker, refer to [GitLab Docker images](../../../install/docker.md) documentation.
+
+### Test with GitLab development toolkits
+
+This is the less recommended approach, because it comes with a number of difficulties when emulating a real GitLab deployment.
+
+The [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit) is not set up to run a Prometheus server or `node_exporter` alongside other GitLab components. If you would
+like to do so, [Monitoring the GDK with Prometheus](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/prometheus/index.md#monitoring-the-gdk-with-prometheus) is a good start.
+
+The [GCK](https://gitlab.com/gitlab-org/gitlab-compose-kit) has limited support for testing Prometheus based Service Ping.
+By default, it comes with a fully configured Prometheus service that is set up to scrape a number of components.
+However, it has the following limitations:
+
+- It does not run a `gitlab-exporter` instance, so several `process_*` metrics from services such as Gitaly may be missing.
+- While it runs a `node_exporter`, `docker-compose` services emulate hosts, meaning that it normally reports itself as not associated
+  with any of the other running services. That is not how node metrics are reported in a production setup, where `node_exporter`
+  always runs as a process alongside other GitLab components on any given node. For Service Ping, none of the node data would therefore
+  appear to be associated to any of the services running, because they all appear to be running on different hosts. To alleviate this problem, the `node_exporter` in GCK was arbitrarily "assigned" to the `web` service, meaning only for this service `node_*` metrics appears in Service Ping.
+
+## Aggregated metrics
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/45979) in GitLab 13.6.
+
+WARNING:
+This feature is intended solely for internal GitLab use.
+
+The aggregated metrics feature provides insight into the data attributes in a collection of Service Ping metrics.
+This aggregation allows you to count data attributes in events without counting each occurrence of the same data attribute in multiple events.
+For example, you can aggregate the number of users who perform several actions, such as creating a new issue and opening a new merge request.
+You can then count each user that performed any combination of these actions.
+
+### Defining aggregated metric via metric YAML definition
+
+To add data for aggregated metrics to the Service Ping payload,
+create metric YAML definition file following [Aggregated metric instrumentation guide](metrics_instrumentation.md#aggregated-metrics).
+
+### Redis sourced aggregated metrics
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/45979) in GitLab 13.6.
+
+To declare the aggregate of events collected with [Redis HLL Counters](#redis-hll-counters),
+you must fulfill the following requirements:
+
+1. All events listed at `events` attribute must come from
+   [`known_events/*.yml`](#known-events-are-added-automatically-in-service-data-payload) files.
+1. All events listed at `events` attribute must have the same `aggregation` attribute.
+1. `time_frame` does not include `all` value, which is unavailable for Redis sourced aggregated metrics.
+
+While it is possible to aggregate EE-only events together with events that occur in all GitLab editions, it's important to remember that doing so may produce high variance between data collected from EE and CE GitLab instances.
+
+### Database sourced aggregated metrics
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52784) in GitLab 13.9.
+
+To declare an aggregate of metrics based on events collected from database, follow
+these steps:
+
+1. [Persist the metrics for aggregation](#persist-metrics-for-aggregation).
+1. [Add new aggregated metric definition](#add-new-aggregated-metric-definition).
+
+#### Persist metrics for aggregation
+
+Only metrics calculated with [Estimated Batch Counters](#estimated-batch-counters)
+can be persisted for database sourced aggregated metrics. To persist a metric,
+inject a Ruby block into the
+[`estimate_batch_distinct_count`](#estimate_batch_distinct_count-method) method.
+This block should invoke the
+`Gitlab::Usage::Metrics::Aggregates::Sources::PostgresHll.save_aggregated_metrics`
+[method](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage/metrics/aggregates/sources/postgres_hll.rb#L21),
+which stores `estimate_batch_distinct_count` results for future use in aggregated metrics.
+
+The `Gitlab::Usage::Metrics::Aggregates::Sources::PostgresHll.save_aggregated_metrics`
+method accepts the following arguments:
+
+- `metric_name`: The name of metric to use for aggregations. Should be the same
+  as the key under which the metric is added into Service Ping.
+- `recorded_at_timestamp`: The timestamp representing the moment when a given
+  Service Ping payload was collected. You should use the convenience method `recorded_at`
+  to fill `recorded_at_timestamp` argument, like this: `recorded_at_timestamp: recorded_at`
+- `time_period`: The time period used to build the `relation` argument passed into
+  `estimate_batch_distinct_count`. To collect the metric with all available historical
+  data, set a `nil` value as time period: `time_period: nil`.
+- `data`: HyperLogLog buckets structure representing unique entries in `relation`.
+  The `estimate_batch_distinct_count` method always passes the correct argument
+  into the block, so `data` argument must always have a value equal to block argument,
+  like this: `data: result`
+
+Example metrics persistence:
+
+```ruby
+class UsageData
+  def count_secure_pipelines(time_period)
+    ...
+    relation = ::Security::Scan.by_scan_types(scan_type).where(time_period)
+
+    pipelines_with_secure_jobs['dependency_scanning_pipeline'] = estimate_batch_distinct_count(relation, :pipeline_id, batch_size: 1000, start: start_id, finish: finish_id) do |result|
+      ::Gitlab::Usage::Metrics::Aggregates::Sources::PostgresHll
+        .save_aggregated_metrics(metric_name: 'dependency_scanning_pipeline', recorded_at_timestamp: recorded_at, time_period: time_period, data: result)
+    end
+  end
+end
+```
+
+#### Add new aggregated metric definition
+
+After all metrics are persisted, you can add an aggregated metric definition following [Aggregated metric instrumentation guide](metrics_instrumentation.md#aggregated-metrics).
+To declare the aggregate of metrics collected with [Estimated Batch Counters](#estimated-batch-counters),
+you must fulfill the following requirements:
+
+- Metrics names listed in the `events:` attribute, have to use the same names you passed in the `metric_name` argument while persisting metrics in previous step.
+- Every metric listed in the `events:` attribute, has to be persisted for **every** selected `time_frame:` value.
diff --git a/doc/development/internal_analytics/service_ping/index.md b/doc/development/internal_analytics/service_ping/index.md
new file mode 100644
index 00000000000..69d37f0dae2
--- /dev/null
+++ b/doc/development/internal_analytics/service_ping/index.md
@@ -0,0 +1,509 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Service Ping development guidelines
+
+> - Introduced in GitLab Ultimate 11.2, more statistics.
+> - In GitLab 14.1, [renamed from Usage Ping to Service Ping](https://gitlab.com/groups/gitlab-org/-/epics/5990). In 14.0 and earlier, use the Usage Ping documentation for the Rails commands appropriate to your version.
+
+Service Ping is a GitLab process that collects and sends a weekly payload to GitLab.
+The payload provides important high-level data that helps our product, support,
+and sales teams understand how GitLab is used. The data helps to:
+
+- Compare counts month over month (or week over week) to get a rough sense for how an instance uses
+  different product features.
+- Collect other facts that help us classify and understand GitLab installations.
+- Calculate our stage monthly active users (SMAU), which helps to measure the success of our stages
+  and features.
+
+Service Ping information is not anonymous. It's linked to the instance's hostname, but does
+not contain project names, usernames, or any other specific data.
+
+Service Ping is enabled by default. However, you can [disable](../../../user/admin_area/settings/usage_statistics.md#enable-or-disable-usage-statistics) it on any self-managed instance. When Service Ping is enabled, GitLab gathers data from the other instances and can show your instance's usage statistics to your users.
+
+## Service Ping terminology
+
+We use the following terminology to describe the Service Ping components:
+
+- **Service Ping**: the process that collects and generates a JSON payload.
+- **Service Data**: the contents of the Service Ping JSON payload. This includes metrics.
+- **Metrics**: primarily made up of row counts for different tables in an instance's database. Each
+  metric has a corresponding [metric definition](metrics_dictionary.md#metrics-definition-and-validation)
+  in a YAML file.
+- **MAU**: monthly active users.
+- **WAU**: weekly active users.
+
+### Limitations
+
+- Service Ping does not track frontend events things like page views, link clicks, or user sessions.
+- Service Ping focuses only on aggregated backend events.
+
+Because of these limitations we recommend you:
+
+- Instrument your products with Snowplow for more detailed analytics on GitLab.com.
+- Use Service Ping to track aggregated backend events on self-managed instances.
+
+## Service Ping request flow
+
+The following example shows a basic request/response flow between a GitLab instance, the Versions Application, the License Application, Salesforce, the GitLab S3 Bucket, the GitLab Snowflake Data Warehouse, and Sisense:
+
+```mermaid
+sequenceDiagram
+    participant GitLab Instance
+    participant Versions Application
+    participant Licenses Application
+    participant Salesforce
+    participant S3 Bucket
+    participant Snowflake DW
+    participant Sisense Dashboards
+    GitLab Instance->>Versions Application: Send Service Ping
+    loop Process usage data
+        Versions Application->>Versions Application: Parse usage data
+        Versions Application->>Versions Application: Write to database
+        Versions Application->>Versions Application: Update license ping time
+    end
+    loop Process data for Salesforce
+        Versions Application-xLicenses Application: Request Zuora subscription id
+        Licenses Application-xVersions Application: Zuora subscription id
+        Versions Application-xSalesforce: Request Zuora account id  by Zuora subscription id
+        Salesforce-xVersions Application: Zuora account id
+        Versions Application-xSalesforce: Usage data for the Zuora account
+    end
+    Versions Application->>S3 Bucket: Export Versions database
+    S3 Bucket->>Snowflake DW: Import data
+    Snowflake DW->>Snowflake DW: Transform data using dbt
+    Snowflake DW->>Sisense Dashboards: Data available for querying
+    Versions Application->>GitLab Instance: DevOps Score (Conversational Development Index)
+```
+
+## How Service Ping works
+
+1. The Service Ping [cron job](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/gitlab_service_ping_worker.rb#L24) is set in Sidekiq to run weekly.
+1. When the cron job runs, it calls [`Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values)`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/service_ping/submit_service.rb).
+1. `Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values)` [cascades down](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb) to ~400+ other counter method calls.
+1. The response of all methods calls are [merged together](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb#L68) into a single JSON payload.
+1. The JSON payload is then [posted to the Versions application](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/service_ping/submit_service.rb#L20)
+   If a firewall exception is needed, the required URL depends on several things. If
+   the hostname is `version.gitlab.com`, the protocol is `TCP`, and the port number is `443`,
+   the required URL is <https://version.gitlab.com/>.
+1. In case of an error, it will be reported to the Version application along with following pieces of information:
+
+   - `uuid` - GitLab instance unique identifier
+   - `hostname` - GitLab instance hostname
+   - `version` - GitLab instance current versions
+   - `elapsed` - Amount of time which passed since Service Ping report process started and moment of error occurrence
+   - `message` - Error message
+
+   <pre>
+   <code>
+   {
+     "uuid"=>"02333324-1cd7-4c3b-a45b-a4993f05fb1d",
+     "hostname"=>"127.0.0.1",
+     "version"=>"14.7.0-pre",
+     "elapsed"=>0.006946,
+     "message"=>'PG::UndefinedColumn: ERROR:  column \"non_existent_attribute\" does not exist\nLINE 1: SELECT COUNT(non_existent_attribute) FROM \"issues\" /*applica...'
+   }
+   </code>
+   </pre>
+
+1. Finally, the timing metadata information that is used for diagnostic purposes is submitted to the Versions application. It consists of a list of metric identifiers and the time it took to calculate the metrics:
+
+   > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37911) in GitLab 15.0 [with a flag](../../../user/feature_flags.md), enabled by default.
+   > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/295289) in GitLab 15.2. [Feature flag `measure_service_ping_metric_collection`](https://gitlab.com/gitlab-org/gitlab/-/issues/358128) removed.
+
+```ruby
+    {
+      "metadata"=>
+      {
+        "uuid"=>"0000000-0000-0000-0000-000000000000",
+        "metrics"=>
+        [{"name"=>"version", "time_elapsed"=>1.1811964213848114e-05},
+         {"name"=>"installation_type", "time_elapsed"=>0.00017242692410945892},
+         {"name"=>"license_billable_users", "time_elapsed"=>0.009520471096038818},
+         ....
+         {"name"=>"counts.clusters_platforms_eks",
+          "time_elapsed"=>0.05638605775311589},
+         {"name"=>"counts.clusters_platforms_gke",
+          "time_elapsed"=>0.40995341585949063},
+         {"name"=>"counts.clusters_platforms_user",
+          "time_elapsed"=>0.06410990096628666},
+         {"name"=>"counts.clusters_management_project",
+          "time_elapsed"=>0.24020783510059118}
+        ]
+      }
+    }
+```
+
+### On a Geo secondary site
+
+We also collect metrics specific to [Geo](../../../administration/geo/index.md) secondary sites to send with Service Ping.
+
+1. The [Geo secondary service ping cron job](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/workers/geo/secondary_usage_data_cron_worker.rb) is set in Sidekiq to run weekly.
+1. When the cron job runs, it calls [`SecondaryUsageData.update_metrics!`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/geo/secondary_usage_data.rb#L33). This collects the relevant metrics from Prometheus and stores the data in the Geo secondary tracking database for transmission to the primary site during a [Geo node status update](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/geo_node_status.rb#L105).
+1. Geo node status data is sent with the JSON payload in the process described above. The following is an example of the payload where each object in the array represents a Geo node:
+
+   ```json
+   [
+     {
+       "repository_verification_enabled"=>true,
+       "repositories_replication_enabled"=>true,
+       "repositories_synced_count"=>24,
+       "repositories_failed_count"=>0,
+       "git_fetch_event_count_weekly"=>nil,
+       "git_push_event_count_weekly"=>nil,
+       ... other geo node status fields
+     }
+   ]
+   ```
+
+## Implementing Service Ping
+
+See the [implement Service Ping](implement.md) guide.
+
+## Example Service Ping payload
+
+The following is example content of the Service Ping payload.
+
+```json
+{
+  "uuid": "0000000-0000-0000-0000-000000000000",
+  "hostname": "example.com",
+  "version": "12.10.0-pre",
+  "installation_type": "omnibus-gitlab",
+  "active_user_count": 999,
+  "recorded_at": "2020-04-17T07:43:54.162+00:00",
+  "edition": "EEU",
+  "license_md5": "00000000000000000000000000000000",
+  "license_sha256": "0000000000000000000000000000000000000000000000000000000000000000",
+  "license_id": null,
+  "historical_max_users": 999,
+  "licensee": {
+    "Name": "ABC, Inc.",
+    "Email": "email@example.com",
+    "Company": "ABC, Inc."
+  },
+  "license_user_count": 999,
+  "license_starts_at": "2020-01-01",
+  "license_expires_at": "2021-01-01",
+  "license_plan": "ultimate",
+  "license_add_ons": {
+  },
+  "license_trial": false,
+  "counts": {
+    "assignee_lists": 999,
+    "boards": 999,
+    "ci_builds": 999,
+    ...
+  },
+  "container_registry_enabled": true,
+  "dependency_proxy_enabled": false,
+  "gitlab_shared_runners_enabled": true,
+  "gravatar_enabled": true,
+  "influxdb_metrics_enabled": true,
+  "ldap_enabled": false,
+  "mattermost_enabled": false,
+  "omniauth_enabled": true,
+  "prometheus_enabled": false,
+  "prometheus_metrics_enabled": false,
+  "reply_by_email_enabled": "incoming+%{key}@incoming.gitlab.com",
+  "signup_enabled": true,
+  "projects_with_expiration_policy_disabled": 999,
+  "projects_with_expiration_policy_enabled": 999,
+  ...
+  "elasticsearch_enabled": true,
+  "license_trial_ends_on": null,
+  "geo_enabled": false,
+  "git": {
+    "version": {
+      "major": 2,
+      "minor": 26,
+      "patch": 1
+    }
+  },
+  "gitaly": {
+    "version": "12.10.0-rc1-93-g40980d40",
+    "servers": 56,
+    "clusters": 14,
+    "filesystems": [
+      "EXT_2_3_4"
+    ]
+  },
+  "gitlab_pages": {
+    "enabled": true,
+    "version": "1.17.0"
+  },
+  "container_registry_server": {
+    "vendor": "gitlab",
+    "version": "2.9.1-gitlab"
+  },
+  "database": {
+    "adapter": "postgresql",
+    "version": "9.6.15",
+    "pg_system_id": 6842684531675334351,
+    "flavor": "Cloud SQL for PostgreSQL"
+  },
+  "analytics_unique_visits": {
+    "g_analytics_contribution": 999,
+    ...
+  },
+  "usage_activity_by_stage": {
+    "configure": {
+      "project_clusters_enabled": 999,
+      ...
+    },
+    "create": {
+      "merge_requests": 999,
+      ...
+    },
+    "manage": {
+      "events": 999,
+      ...
+    },
+    "monitor": {
+      "clusters": 999,
+      ...
+    },
+    "package": {
+      "projects_with_packages": 999
+    },
+    "plan": {
+      "issues": 999,
+      ...
+    },
+    "release": {
+      "deployments": 999,
+      ...
+    },
+    "secure": {
+      "user_container_scanning_jobs": 999,
+      ...
+    },
+    "verify": {
+      "ci_builds": 999,
+      ...
+    }
+  },
+  "usage_activity_by_stage_monthly": {
+    "configure": {
+      "project_clusters_enabled": 999,
+      ...
+    },
+    "create": {
+      "merge_requests": 999,
+      ...
+    },
+    "manage": {
+      "events": 999,
+      ...
+    },
+    "monitor": {
+      "clusters": 999,
+      ...
+    },
+    "package": {
+      "projects_with_packages": 999
+    },
+    "plan": {
+      "issues": 999,
+      ...
+    },
+    "release": {
+      "deployments": 999,
+      ...
+    },
+    "secure": {
+      "user_container_scanning_jobs": 999,
+      ...
+    },
+    "verify": {
+      "ci_builds": 999,
+      ...
+    }
+  },
+  "topology": {
+    "duration_s": 0.013836685999194742,
+    "application_requests_per_hour": 4224,
+    "query_apdex_weekly_average": 0.996,
+    "failures": [],
+    "nodes": [
+      {
+        "node_memory_total_bytes": 33269903360,
+        "node_memory_utilization": 0.35,
+        "node_cpus": 16,
+        "node_cpu_utilization": 0.2,
+        "node_uname_info": {
+          "machine": "x86_64",
+          "sysname": "Linux",
+          "release": "4.19.76-linuxkit"
+        },
+        "node_services": [
+          {
+            "name": "web",
+            "process_count": 16,
+            "process_memory_pss": 233349888,
+            "process_memory_rss": 788220927,
+            "process_memory_uss": 195295487,
+            "server": "puma"
+          },
+          {
+            "name": "sidekiq",
+            "process_count": 1,
+            "process_memory_pss": 734080000,
+            "process_memory_rss": 750051328,
+            "process_memory_uss": 731533312
+          },
+          ...
+        ],
+        ...
+      },
+      ...
+    ]
+  }
+}
+```
+
+## Notable changes
+
+In GitLab 14.6, [`flavor`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75587) was added to try to detect the underlying managed database variant.
+Possible values are "Amazon Aurora PostgreSQL", "PostgreSQL on Amazon RDS", "Cloud SQL for PostgreSQL",
+"Azure Database for PostgreSQL - Flexible Server", or "null".
+
+In GitLab 13.5, `pg_system_id` was added to send the [PostgreSQL system identifier](https://www.2ndquadrant.com/en/blog/support-for-postgresqls-system-identifier-in-barman/).
+
+## Export Service Ping data
+
+Rake tasks exist to export Service Ping data in different formats.
+
+- The Rake tasks export the raw SQL queries for `count`, `distinct_count`, `sum`.
+- The Rake tasks export the Redis counter class or the line of the Redis block for `redis_usage_data`.
+- The Rake tasks calculate the `alt_usage_data` metrics.
+
+In the home directory of your local GitLab installation run the following Rake tasks for the YAML and JSON versions respectively:
+
+```shell
+# for YAML export of SQL queries
+bin/rake gitlab:usage_data:dump_sql_in_yaml
+
+# for JSON export of SQL queries
+bin/rake gitlab:usage_data:dump_sql_in_json
+
+# for JSON export of Non SQL data
+bin/rake gitlab:usage_data:dump_non_sql_in_json
+
+# You may pipe the output into a file
+bin/rake gitlab:usage_data:dump_sql_in_yaml > ~/Desktop/usage-metrics-2020-09-02.yaml
+```
+
+## Generate Service Ping
+
+To generate Service Ping, use [Teleport](https://goteleport.com/docs/) or a detached screen session on a remote server.
+
+### Triggering
+
+#### Trigger Service Ping with Teleport
+
+1. Request temporary [access](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/teleport/Connect_to_Rails_Console_via_Teleport.md#how-to-use-teleport-to-connect-to-rails-console) to the required environment.
+1. After your approval is issued, [access the Rails console](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/teleport/Connect_to_Rails_Console_via_Teleport.md#access-approval).
+1. Run `GitlabServicePingWorker.new.perform('triggered_from_cron' => false)`.
+
+#### Trigger Service Ping with a detached screen session
+
+1. Connect to bastion with agent forwarding:
+
+   ```shell
+   ssh -A lb-bastion.gprd.gitlab.com
+   ```
+
+1. Create named screen:
+
+   ```shell
+   screen -S <username>_usage_ping_<date>
+   ```
+
+1. Connect to console host:
+
+   ```shell
+   ssh $USER-rails@console-01-sv-gprd.c.gitlab-production.internal
+   ```
+
+1. Run:
+
+   ```shell
+   GitlabServicePingWorker.new.perform('triggered_from_cron' => false)
+   ```
+
+1. To detach from screen, press `ctrl + A`, `ctrl + D`.
+1. Exit from bastion:
+
+   ```shell
+   exit
+   ```
+
+1. Get the metrics duration from logs:
+
+Search in Google Console logs for `time_elapsed`. [Query example](https://cloudlogging.app.goo.gl/nWheZvD8D3nWazNe6).
+
+### Verification (After approx 30 hours)
+
+#### Verify with Teleport
+
+1. Follow [the steps](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/teleport/Connect_to_Rails_Console_via_Teleport.md#how-to-use-teleport-to-connect-to-rails-console) to request a new access to the required environment and connect to the Rails console
+1. Check the last payload in `raw_usage_data` table: `RawUsageData.last.payload`
+1. Check the when the payload was sent: `RawUsageData.last.sent_at`
+
+#### Verify using detached screen session
+
+1. Reconnect to bastion:
+
+   ```shell
+   ssh -A lb-bastion.gprd.gitlab.com
+   ```
+
+1. Find your screen session:
+
+   ```shell
+   screen -ls
+   ```
+
+1. Attach to your screen session:
+
+   ```shell
+   screen -x 14226.mwawrzyniak_usage_ping_2021_01_22
+   ```
+
+1. Check the last payload in `raw_usage_data` table:
+
+   ```shell
+   RawUsageData.last.payload
+   ```
+
+1. Check the when the payload was sent:
+
+   ```shell
+   RawUsageData.last.sent_at
+   ```
+
+### Skip database write operations
+
+To skip database write operations, DevOps report creation, and storage of usage data payload, pass an optional argument:
+
+```shell
+skip_db_write:
+GitlabServicePingWorker.new.perform('triggered_from_cron' => false, 'skip_db_write' => true)
+```
+
+## Monitoring
+
+Service Ping reporting process state is monitored with [internal SiSense dashboard](https://app.periscopedata.com/app/gitlab/968489/Product-Intelligence---Service-Ping-Health).
+
+## Related topics
+
+- [Product Intelligence Guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
+- [Snowplow Guide](../snowplow/index.md)
+- [Product Intelligence Direction](https://about.gitlab.com/direction/analytics/product-intelligence/)
+- [Data Analysis Process](https://about.gitlab.com/handbook/business-technology/data-team/#data-analysis-process/)
+- [Data for Product Managers](https://about.gitlab.com/handbook/business-technology/data-team/programs/data-for-product-managers/)
+- [Data Infrastructure](https://about.gitlab.com/handbook/business-technology/data-team/platform/infrastructure/)
diff --git a/doc/development/internal_analytics/service_ping/metrics_dictionary.md b/doc/development/internal_analytics/service_ping/metrics_dictionary.md
new file mode 100644
index 00000000000..d1f1c0b595a
--- /dev/null
+++ b/doc/development/internal_analytics/service_ping/metrics_dictionary.md
@@ -0,0 +1,334 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Metrics Dictionary Guide
+
+[Service Ping](index.md) metrics are defined in individual YAML files definitions from which the
+[Metrics Dictionary](https://metrics.gitlab.com/) is built. Currently, the metrics dictionary is built automatically once a day. When a change to a metric is made in a YAML file, you can see the change in the dictionary within 24 hours.
+This guide describes the dictionary and how it's implemented.
+
+## Metrics Definition and validation
+
+We are using [JSON Schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json) to validate the metrics definition.
+
+This process is meant to ensure consistent and valid metrics defined for Service Ping. All metrics *must*:
+
+- Comply with the defined [JSON schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json).
+- Have a unique `key_path` .
+- Have an owner.
+
+All metrics are stored in YAML files:
+
+- [`config/metrics`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/metrics)
+
+WARNING:
+Only metrics with a metric definition YAML and whose status is not `removed` are added to the Service Ping JSON payload.
+
+Each metric is defined in a separate YAML file consisting of a number of fields:
+
+| Field               | Required | Additional information                                         |
+|---------------------|----------|----------------------------------------------------------------|
+| `key_path`          | yes      | JSON key path for the metric, location in Service Ping payload.  |
+| `name` (deprecated)  | no       | Metric name suggestion. Does not have any impact on the Service Ping payload, only serves as documentation. |
+| `description`       | yes      |                                                                |
+| `product_section`   | yes      | The [section](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/sections.yml). |
+| `product_stage`     | yes       | The [stage](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) for the metric. |
+| `product_group`     | yes      | The [group](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) that owns the metric. |
+| `value_type`        | yes      | `string`; one of [`string`, `number`, `boolean`, `object`](https://json-schema.org/understanding-json-schema/reference/type.html).                                                     |
+| `status`            | yes      | `string`; [status](#metric-statuses) of the metric, may be set to `active`, `removed`, `broken`. |
+| `time_frame`        | yes      | `string`; may be set to a value like `7d`, `28d`, `all`, `none`. |
+| `data_source`       | yes      | `string`; may be set to a value like `database`, `redis`, `redis_hll`, `prometheus`, `system`, `license`. |
+| `data_category`     | yes      | `string`; [categories](#data-category) of the metric, may be set to `operational`, `optional`, `subscription`, `standard`. The default value is `optional`.|
+| `instrumentation_class` | yes   | `string`; [the class that implements the metric](metrics_instrumentation.md).  |
+| `distribution`      | yes      | `array`; may be set to one of `ce, ee` or `ee`. The [distribution](https://about.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/tiers/#definitions) where the tracked feature is available.  |
+| `performance_indicator_type`  | no      | `array`; may be set to one of [`gmau`, `smau`, `paid_gmau`, `umau` or `customer_health_score`](https://about.gitlab.com/handbook/business-technology/data-team/data-catalog/xmau-analysis/). |
+| `tier`              | yes      | `array`; may contain one or a combination of `free`, `premium` or `ultimate`. The [tier](https://about.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/tiers/#definitions) where the tracked feature is available. This should be verbose and contain all tiers where a metric is available. |
+| `milestone`         | yes       | The milestone when the metric is introduced and when it's available to self-managed instances with the official GitLab release. |
+| `milestone_removed` | no       | The milestone when the metric is removed. |
+| `introduced_by_url` | no       | The URL to the merge request that introduced the metric to be available for self-managed instances. |
+| `removed_by_url`    | no       | The URL to the merge request that removed the metric. |
+| `repair_issue_url`  | no       | The URL of the issue that was created to repair a metric with a `broken` status. |
+| `options`           | no       | `object`: options information needed to calculate the metric value. |
+| `skip_validation`   | no       | This should **not** be set. [Used for imported metrics until we review, update and make them valid](https://gitlab.com/groups/gitlab-org/-/epics/5425). |
+
+### Metric `key_path`
+
+The `key_path` of the metric is the location in the JSON Service Ping payload.
+
+The `key_path` could be composed from multiple parts separated by `.` and it must be unique.
+
+We recommend to add the metric in one of the top-level keys:
+
+- `settings`: for settings related metrics.
+- `counts_weekly`: for counters that have data for the most recent 7 days.
+- `counts_monthly`: for counters that have data for the most recent 28 days.
+- `counts`: for counters that have data for all time.
+
+NOTE:
+We can't control what the metric's `key_path` is, because some of them are generated dynamically in `usage_data.rb`.
+For example, see [Redis HLL metrics](implement.md#redis-hll-counters).
+
+### Metric name (deprecated)
+
+WARNING:
+This feature was deprecated in GitLab 16.1
+and is planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/411602) in 16.2.
+
+To improve metric discoverability by a wider audience, each metric with
+instrumentation added at an appointed `key_path` receives a `name` attribute
+filled with the name suggestion, corresponding to the metric `data_source` and instrumentation.
+Metric name suggestions can contain two types of elements:
+
+1. **User input prompts**: enclosed by angle brackets (`< >`), these pieces should be replaced or
+   removed when you create a metrics YAML file.
+1. **Fixed suggestion**: plaintext parts generated according to well-defined algorithms.
+   They are based on underlying instrumentation, and must not be changed.
+
+For a metric name to be valid, it must not include any prompt, and fixed suggestions
+must not be changed.
+
+#### Generate a metric name suggestion (deprecated)
+
+WARNING:
+This feature was deprecated in GitLab 16.1
+and is planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/411602) in 16.2.
+
+The metric YAML generator can suggest a metric name for you.
+To generate a metric name suggestion, first instrument the metric at the provided `key_path`.
+Then, generate the metric's YAML definition and
+return to the instrumentation and update it.
+
+1. Add the metric instrumentation class to `lib/gitlab/usage/metrics/instrumentations/`.
+1. Add the metric logic in the instrumentation class.
+1. Run the [metrics YAML generator](metrics_dictionary.md#create-a-new-metric-definition).
+1. Use the metric name suggestion to select a suitable metric name.
+1. Update the metric's YAML definition with the correct `key_path`.
+
+### Metric statuses
+
+Metric definitions can have one of the following statuses:
+
+- `active`: Metric is used and reports data.
+- `broken`: Metric reports broken data (for example, -1 fallback), or does not report data at all. A metric marked as `broken` must also have the `repair_issue_url` attribute.
+- `removed`: Metric was removed, but it may appear in Service Ping payloads sent from instances running on older versions of GitLab.
+
+### Metric `value_type`
+
+Metric definitions can have one of the following values for `value_type`:
+
+- `boolean`
+- `number`
+- `string`
+- `object`: A metric with `value_type: object` must have `value_json_schema` with a link to the JSON schema for the object.
+In general, we avoid complex objects and prefer one of the `boolean`, `number`, or `string` value types.
+An example of a metric that uses `value_type: object` is `topology` (`/config/metrics/settings/20210323120839_topology.yml`),
+which has a related schema in `/config/metrics/objects_schemas/topology_schema.json`.
+
+### Metric `time_frame`
+
+A metric's time frame is calculated based on the `time_frame` field and the `data_source` of the metric.
+For `redis_hll` metrics, the type of aggregation is also taken into consideration. In this context, the term "aggregation" refers to [chosen events data storage interval](implement.md#add-new-events), and is **NOT** related to the Aggregated Metrics feature.
+For more information about the aggregation type of each feature, see the [`common.yml` file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/common.yml). Weeks run from Monday to Sunday.
+
+| data_source            | time_frame | aggregation    | Description                                     |
+|------------------------|------------|----------------|-------------------------------------------------|
+| any                    | `none`     | not applicable | A type of data that’s not tracked over time, such as settings and configuration information |
+| `database`             | `all`      | not applicable | The whole time the metric has been active (all-time interval) |
+| `database`             | `7d`       | not applicable | 9 days ago to 2 days ago |
+| `database`             | `28d`      | not applicable | 30 days ago to 2 days ago |
+| `redis`                | `all`      | not applicable | The whole time the metric has been active (all-time interval) |
+| `redis_hll`            | `7d`       | `daily`        | Most recent 7 complete days |
+| `redis_hll`            | `7d`       | `weekly`       | Most recent complete week |
+| `redis_hll`            | `28d`      | `daily`        | Most recent 28 complete days |
+| `redis_hll`            | `28d`      | `weekly`       | Most recent 4 complete weeks |
+
+### Data category
+
+We use the following categories to classify a metric:
+
+- `operational`: Required data for operational purposes.
+- `optional`: Default value for a metric. Data that is optional to collect. This can be [enabled or disabled](../../../user/admin_area/settings/usage_statistics.md#enable-or-disable-usage-statistics) in the Admin Area.
+- `subscription`: Data related to licensing.
+- `standard`: Standard set of identifiers that are included when collecting data.
+
+An aggregate metric is a metric that is the sum of two or more child metrics. Service Ping uses the data category of
+the aggregate metric to determine whether or not the data is included in the reported Service Ping payload.
+
+### Metric name suggestion examples (deprecated)
+
+WARNING:
+This feature was deprecated in GitLab 16.1
+and is planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/411602) in 16.2.
+
+#### Metric with `data_source: database`
+
+For a metric instrumented with SQL:
+
+```sql
+SELECT COUNT(DISTINCT user_id) FROM clusters WHERE clusters.management_project_id IS NOT NULL
+```
+
+- **Suggested name**: `count_distinct_user_id_from_<adjective describing: '(clusters.management_project_id IS NOT NULL)'>_clusters`
+- **Prompt**: `<adjective describing: '(clusters.management_project_id IS NOT NULL)'>`
+  should be replaced with an adjective that best represents filter conditions, such as `project_management`
+- **Final metric name**: For example, `count_distinct_user_id_from_project_management_clusters`
+
+For metric instrumented with SQL:
+
+```sql
+SELECT COUNT(DISTINCT clusters.user_id)
+FROM clusters_applications_helm
+INNER JOIN clusters ON clusters.id = clusters_applications_helm.cluster_id
+WHERE clusters_applications_helm.status IN (3, 5)
+```
+
+- **Suggested name**: `count_distinct_user_id_from_<adjective describing: '(clusters_applications_helm.status IN (3, 5))'>_clusters_<with>_<adjective describing: '(clusters_applications_helm.status IN (3, 5))'>_clusters_applications_helm`
+- **Prompt**: `<adjective describing: '(clusters_applications_helm.status IN (3, 5))'>`
+  should be replaced with an adjective that best represents filter conditions
+- **Final metric name**: `count_distinct_user_id_from_clusters_with_available_clusters_applications_helm`
+
+In the previous example, the prompt is irrelevant, and user can remove it. The second
+occurrence corresponds with the `available` scope defined in `Clusters::Concerns::ApplicationStatus`.
+It can be used as the right adjective to replace prompt.
+
+The `<with>` represents a suggested conjunction for the suggested name of the joined relation.
+The person documenting the metric can use it by either:
+
+- Removing the surrounding `<>`.
+- Using a different conjunction, such as `having` or `including`.
+
+#### Metric with `data_source: redis` or `redis_hll`
+
+For metrics instrumented with a Redis-based counter, the suggested name includes
+only the single prompt to be replaced by the person working with metrics YAML.
+
+- **Prompt**: `<please fill metric name, suggested format is: {subject}_{verb}{ing|ed}_{object} eg: users_creating_epics or merge_requests_viewed_in_single_file_mode>`
+- **Final metric name**: We suggest the metric name should follow the format of
+  `{subject}_{verb}{ing|ed}_{object}`, such as `user_creating_epics`, `users_triggering_security_scans`,
+  or `merge_requests_viewed_in_single_file_mode`
+
+#### Metric with `data_source: prometheus` or `system`
+
+For metrics instrumented with Prometheus or coming from the operating system,
+the suggested name includes only the single prompt by person working with metrics YAML.
+
+- **Prompt**: `<please fill metric name>`
+- **Final metric name**: Due to the variety of cases that can apply to this kind of metric,
+  no naming convention exists. Each person instrumenting a metric should use their
+  best judgment to come up with a descriptive name.
+
+### Example YAML metric definition
+
+The linked [`uuid`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/license/uuid.yml)
+YAML file includes an example metric definition, where the `uuid` metric is the GitLab
+instance unique identifier.
+
+```yaml
+key_path: uuid
+description: GitLab instance unique identifier
+product_section: analytics
+product_stage: analytics
+product_group: analytics_instrumentation
+value_type: string
+status: active
+milestone: 9.1
+instrumentation_class: UuidMetric
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1521
+time_frame: none
+data_source: database
+distribution:
+- ce
+- ee
+tier:
+- free
+- premium
+- ultimate
+```
+
+### Create a new metric definition
+
+The GitLab codebase provides a dedicated [generator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_definition_generator.rb) to create new metric definitions.
+
+For uniqueness, the generated files include a timestamp prefix in ISO 8601 format.
+
+The generator takes a list of key paths and 3 options as arguments. It creates metric YAML definitions in the corresponding location:
+
+- `--ee`, `--no-ee` Indicates if metric is for EE.
+- `--dir=DIR` Indicates the metric directory. It must be one of: `counts_7d`, `7d`, `counts_28d`, `28d`, `counts_all`, `all`, `settings`, `license`.
+- `--class_name=CLASS_NAME` Indicates the instrumentation class. For example `UsersCreatingIssuesMetric`, `UuidMetric`
+
+**Single metric example**
+
+```shell
+bundle exec rails generate gitlab:usage_metric_definition counts.issues --dir=7d --class_name=CountIssues
+// Creates 1 file
+// create  config/metrics/counts_7d/issues.yml
+```
+
+**Multiple metrics example**
+
+```shell
+bundle exec rails generate gitlab:usage_metric_definition counts.issues counts.users --dir=7d --class_name=CountUsersCreatingIssues
+// Creates 2 files
+// create  config/metrics/counts_7d/issues.yml
+// create  config/metrics/counts_7d/users.yml
+```
+
+NOTE:
+To create a metric definition used in EE, add the `--ee` flag.
+
+```shell
+bundle exec rails generate gitlab:usage_metric_definition counts.issues --ee --dir=7d --class_name=CountUsersCreatingIssues
+// Creates 1 file
+// create  ee/config/metrics/counts_7d/issues.yml
+```
+
+### Metrics added dynamic to Service Ping payload
+
+The [Redis HLL metrics](implement.md#known-events-are-added-automatically-in-service-data-payload) are added automatically to Service Ping payload.
+
+A YAML metric definition is required for each metric. A dedicated generator is provided to create metric definitions for Redis HLL events.
+
+The generator takes `category` and `events` arguments, as the root key is `redis_hll_counters`, and creates two metric definitions for each of the events (for weekly and monthly time frames):
+
+**Single metric example**
+
+```shell
+bundle exec rails generate gitlab:usage_metric_definition:redis_hll issues count_users_closing_issues
+// Creates 2 files
+// create  config/metrics/counts_7d/count_users_closing_issues_weekly.yml
+// create  config/metrics/counts_28d/count_users_closing_issues_monthly.yml
+```
+
+**Multiple metrics example**
+
+```shell
+bundle exec rails generate gitlab:usage_metric_definition:redis_hll issues count_users_closing_issues count_users_reopening_issues
+// Creates 4 files
+// create  config/metrics/counts_7d/count_users_closing_issues_weekly.yml
+// create  config/metrics/counts_28d/count_users_closing_issues_monthly.yml
+// create  config/metrics/counts_7d/count_users_reopening_issues_weekly.yml
+// create  config/metrics/counts_28d/count_users_reopening_issues_monthly.yml
+```
+
+To create a metric definition used in EE, add the `--ee` flag.
+
+```shell
+bundle exec rails generate gitlab:usage_metric_definition:redis_hll issues users_closing_issues --ee
+// Creates 2 files
+// create  config/metrics/counts_7d/i_closed_weekly.yml
+// create  config/metrics/counts_28d/i_closed_monthly.yml
+```
+
+## Metrics Dictionary
+
+[Metrics Dictionary is a separate application](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/metric-dictionary).
+
+All metrics available in Service Ping are in the [Metrics Dictionary](https://metrics.gitlab.com/).
+
+### Copy query to clipboard
+
+To check if a metric has data in Sisense, use the copy query to clipboard feature. This copies a query that's ready to use in Sisense. The query gets the last five service ping data for GitLab.com for a given metric. For information about how to check if a Service Ping metric has data in Sisense, see this [demo](https://www.youtube.com/watch?v=n4o65ivta48).
diff --git a/doc/development/internal_analytics/service_ping/metrics_instrumentation.md b/doc/development/internal_analytics/service_ping/metrics_instrumentation.md
new file mode 100644
index 00000000000..b6ca773a572
--- /dev/null
+++ b/doc/development/internal_analytics/service_ping/metrics_instrumentation.md
@@ -0,0 +1,478 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Metrics instrumentation guide
+
+This guide describes how to develop Service Ping metrics using metrics instrumentation.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For a video tutorial, see the [Adding Service Ping metric via instrumentation class](https://youtu.be/p2ivXhNxUoY).
+
+## Nomenclature
+
+- **Instrumentation class**:
+  - Inherits one of the metric classes: `DatabaseMetric`, `RedisMetric`, `RedisHLLMetric`, `NumbersMetric` or `GenericMetric`.
+  - Implements the logic that calculates the value for a Service Ping metric.
+
+- **Metric definition**
+  The Service Data metric YAML definition.
+
+- **Hardening**:
+  Hardening a method is the process that ensures the method fails safe, returning a fallback value like -1.
+
+## How it works
+
+A metric definition has the [`instrumentation_class`](metrics_dictionary.md) field, which can be set to a class.
+
+The defined instrumentation class should inherit one of the existing metric classes: `DatabaseMetric`, `RedisMetric`, `RedisHLLMetric`, `NumbersMetric` or `GenericMetric`.
+
+The current convention is that a single instrumentation class corresponds to a single metric. On rare occasions, there are exceptions to that convention like [Redis metrics](#redis-metrics). To use a single instrumentation class for more than one metric, please reach out to one of the `@gitlab-org/analytics-section/analytics-instrumentation/engineers` members to consult about your case.
+
+Using the instrumentation classes ensures that metrics can fail safe individually, without breaking the entire
+ process of Service Ping generation.
+
+We have built a domain-specific language (DSL) to define the metrics instrumentation.
+
+## Database metrics
+
+You can use database metrics to track data kept in the database, for example, a count of issues that exist on a given instance.
+
+- `operation`: Operations for the given `relation`, one of `count`, `distinct_count`, `sum`, and `average`.
+- `relation`: Assigns lambda that returns the `ActiveRecord::Relation` for the objects we want to perform the `operation`. The assigned lambda can accept up to one parameter. The parameter is hashed and stored under the `options` key in the metric definition.
+- `start`: Specifies the start value of the batch counting, by default is `relation.minimum(:id)`.
+- `finish`: Specifies the end value of the batch counting, by default is `relation.maximum(:id)`.
+- `cache_start_and_finish_as`: Specifies the cache key for `start` and `finish` values and sets up caching them. Use this call when `start` and `finish` are expensive queries that should be reused between different metric calculations.
+- `available?`: Specifies whether the metric should be reported. The default is `true`.
+- `timestamp_column`: Optionally specifies timestamp column for metric used to filter records for time constrained metrics. The default is `created_at`.
+
+[Example of a merge request that adds a database metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60022).
+
+```ruby
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+        class CountIssuesMetric < DatabaseMetric
+          operation :count
+
+          relation ->(options) { Issue.where(confidential: options[:confidential]) }
+        end
+      end
+    end
+  end
+end
+```
+
+### Ordinary batch counters Example
+
+```ruby
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+        class CountIssuesMetric < DatabaseMetric
+          operation :count
+
+          start { Issue.minimum(:id) }
+          finish { Issue.maximum(:id) }
+
+          relation { Issue }
+        end
+      end
+    end
+  end
+end
+```
+
+### Distinct batch counters Example
+
+```ruby
+# frozen_string_literal: true
+
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+        class CountUsersAssociatingMilestonesToReleasesMetric < DatabaseMetric
+          operation :distinct_count, column: :author_id
+
+          relation { Release.with_milestones }
+
+          start { Release.minimum(:author_id) }
+          finish { Release.maximum(:author_id) }
+        end
+      end
+    end
+  end
+end
+```
+
+### Sum Example
+
+```ruby
+# frozen_string_literal: true
+
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+        class JiraImportsTotalImportedIssuesCountMetric < DatabaseMetric
+          operation :sum, column: :imported_issues_count
+
+          relation { JiraImportState.finished }
+        end
+      end
+    end
+  end
+end
+```
+
+### Average Example
+
+```ruby
+# frozen_string_literal: true
+
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+        class CountIssuesWeightAverageMetric < DatabaseMetric
+          operation :average, column: :weight
+
+          relation { Issue }
+        end
+      end
+    end
+  end
+end
+```
+
+## Redis metrics
+
+You can use Redis metrics to track events not kept in the database, for example, a count of how many times the search bar has been used.
+
+[Example of a merge request that adds `Redis` metrics](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/103455).
+
+The `RedisMetric` class can only be used as the `instrumentation_class` for Redis metrics with simple counters classes (classes that only inherit `BaseCounter` and set `PREFIX` and `KNOWN_EVENTS` constants). In case the counter class has additional logic included in it, a new `instrumentation_class`, inheriting from `RedisMetric`, needs to be created. This new class needs to include the additional logic from the counter class.
+
+Required options:
+
+- `event`: the event name.
+- `prefix`: the value of the `PREFIX` constant used in the counter classes from the `Gitlab::UsageDataCounters` namespace.
+
+Count unique values for `source_code_pushes` event.
+
+```yaml
+time_frame: all
+data_source: redis
+instrumentation_class: RedisMetric
+options:
+  event: pushes
+  prefix: source_code
+```
+
+### Availability-restrained Redis metrics
+
+If the Redis metric should only be available in the report under some conditions, then you must specify these conditions in a new class that is a child of the `RedisMetric` class.
+
+```ruby
+# frozen_string_literal: true
+
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+        class MergeUsageCountRedisMetric < RedisMetric
+          available? { Feature.enabled?(:merge_usage_data_missing_key_paths) }
+        end
+      end
+    end
+  end
+end
+```
+
+You must also use the class's name in the YAML setup.
+
+```yaml
+time_frame: all
+data_source: redis
+instrumentation_class: MergeUsageCountRedisMetric
+options:
+  event: pushes
+  prefix: source_code
+```
+
+## Redis HyperLogLog metrics
+
+You can use Redis HyperLogLog metrics to track events not kept in the database and incremented for unique values such as unique users,
+for example, a count of how many different users used the search bar.
+
+[Example of a merge request that adds a `RedisHLL` metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61685).
+
+Count unique values for `i_quickactions_approve` event.
+
+```yaml
+time_frame: 28d
+data_source: redis_hll
+instrumentation_class: RedisHLLMetric
+options:
+  events:
+    - i_quickactions_approve
+```
+
+### Availability-restrained Redis HyperLogLog metrics
+
+If the Redis HyperLogLog metric should only be available in the report under some conditions, then you must specify these conditions in a new class that is a child of the `RedisHLLMetric` class.
+
+```ruby
+# frozen_string_literal: true
+
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+        class MergeUsageCountRedisHLLMetric < RedisHLLMetric
+          available? { Feature.enabled?(:merge_usage_data_missing_key_paths) }
+        end
+      end
+    end
+  end
+end
+```
+
+You must also use the class's name in the YAML setup.
+
+```yaml
+time_frame: 28d
+data_source: redis_hll
+instrumentation_class: MergeUsageCountRedisHLLMetric
+options:
+  events:
+    - i_quickactions_approve
+```
+
+## Aggregated metrics
+
+<div class="video-fallback">
+  See the video from: <a href="https://www.youtube.com/watch?v=22LbYqHwtUQ">Product Intelligence Office Hours Oct 6th</a> for an aggregated metrics walk-through.
+</div>
+<figure class="video-container">
+  <iframe src="https://www.youtube-nocookie.com/embed/22LbYqHwtUQ" frameborder="0" allowfullscreen> </iframe>
+</figure>
+
+The aggregated metrics feature provides insight into the number of data attributes, for example `pseudonymized_user_ids`, that occurred in a collection of events. For example, you can aggregate the number of users who perform multiple actions such as creating a new issue and opening
+a new merge request.
+
+You can use a YAML file to define your aggregated metrics. The following arguments are required:
+
+- `options.events`: List of event names to aggregate into metric data. All events in this list must
+  use the same data source. Additional data source requirements are described in
+  [Database sourced aggregated metrics](implement.md#database-sourced-aggregated-metrics) and
+  [Redis sourced aggregated metrics](implement.md#redis-sourced-aggregated-metrics).
+- `options.aggregate.operator`: Operator that defines how the aggregated metric data is counted. Available operators are:
+  - `OR`: Removes duplicates and counts all entries that triggered any of the listed events.
+  - `AND`: Removes duplicates and counts all elements that were observed triggering all of the following events.
+- `options.aggregate.attribute`: Information pointing to the attribute that is being aggregated across events.
+- `time_frame`: One or more valid time frames. Use these to limit the data included in aggregated metrics to events within a specific date-range. Valid time frames are:
+  - `7d`: The last 7 days of data.
+  - `28d`: The last 28 days of data.
+  - `all`: All historical data, only available for `database` sourced aggregated metrics.
+- `data_source`: Data source used to collect all events data included in the aggregated metrics. Valid data sources are:
+  - [`database`](implement.md#database-sourced-aggregated-metrics)
+  - [`redis_hll`](implement.md#redis-sourced-aggregated-metrics)
+
+Refer to merge request [98206](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98206) for an example of a merge request that adds an `AggregatedMetric` metric.
+
+Count unique `user_ids` that occurred in at least one of the events: `incident_management_alert_status_changed`,
+`incident_management_alert_assigned`, `incident_management_alert_todo`, `incident_management_alert_create_incident`.
+
+```yaml
+time_frame: 28d
+instrumentation_class: AggregatedMetric
+data_source: redis_hll
+options:
+    aggregate:
+        operator: OR
+        attribute: user_id
+    events:
+        - `incident_management_alert_status_changed`
+        - `incident_management_alert_assigned`
+        - `incident_management_alert_todo`
+        - `incident_management_alert_create_incident`
+```
+
+### Availability-restrained Aggregated metrics
+
+If the Aggregated metric should only be available in the report under specific conditions, then you must specify these conditions in a new class that is a child of the `AggregatedMetric` class.
+
+```ruby
+# frozen_string_literal: true
+
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+        class MergeUsageCountAggregatedMetric < AggregatedMetric
+          available? { Feature.enabled?(:merge_usage_data_missing_key_paths) }
+        end
+      end
+    end
+  end
+end
+```
+
+You must also use the class's name in the YAML setup.
+
+```yaml
+time_frame: 28d
+instrumentation_class: MergeUsageCountAggregatedMetric
+data_source: redis_hll
+options:
+    aggregate:
+        operator: OR
+        attribute: user_id
+    events:
+        - `incident_management_alert_status_changed`
+        - `incident_management_alert_assigned`
+        - `incident_management_alert_todo`
+        - `incident_management_alert_create_incident`
+```
+
+## Numbers metrics
+
+- `operation`: Operations for the given `data` block. Currently we only support `add` operation.
+- `data`: a `block` which contains an array of numbers.
+- `available?`: Specifies whether the metric should be reported. The default is `true`.
+
+```ruby
+# frozen_string_literal: true
+
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+          class IssuesBoardsCountMetric < NumbersMetric
+            operation :add
+
+            data do |time_frame|
+              [
+                 CountIssuesMetric.new(time_frame: time_frame).value,
+                 CountBoardsMetric.new(time_frame: time_frame).value
+              ]
+            end
+          end
+        end
+      end
+    end
+  end
+end
+```
+
+You must also include the instrumentation class name in the YAML setup.
+
+```yaml
+time_frame: 28d
+instrumentation_class: IssuesBoardsCountMetric
+```
+
+## Generic metrics
+
+You can use generic metrics for other metrics, for example, an instance's database version. Observations type of data will always have a Generic metric counter type.
+
+- `value`: Specifies the value of the metric.
+- `available?`: Specifies whether the metric should be reported. The default is `true`.
+
+[Example of a merge request that adds a generic metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60256).
+
+```ruby
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+        class UuidMetric < GenericMetric
+          value do
+            Gitlab::CurrentSettings.uuid
+          end
+        end
+      end
+    end
+  end
+end
+```
+
+## Support for instrumentation classes
+
+There is support for:
+
+- `count`, `distinct_count`, `estimate_batch_distinct_count`, `sum`, and `average` for [database metrics](#database-metrics).
+- [Redis metrics](#redis-metrics).
+- [Redis HLL metrics](#redis-hyperloglog-metrics).
+- `add` for [numbers metrics](#numbers-metrics).
+- [Generic metrics](#generic-metrics), which are metrics based on settings or configurations.
+
+There is no support for:
+
+- `add`, `histogram` for database metrics.
+
+You can [track the progress to support these](https://gitlab.com/groups/gitlab-org/-/epics/6118).
+
+## Create a new metric instrumentation class
+
+To create a stub instrumentation for a Service Ping metric, you can use a dedicated [generator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_generator.rb):
+
+The generator takes the class name as an argument and the following options:
+
+- `--type=TYPE` Required. Indicates the metric type. It must be one of: `database`, `generic`, `redis`, `numbers`.
+- `--operation` Required for `database` & `numbers` type.
+  - For `database` it must be one of: `count`, `distinct_count`, `estimate_batch_distinct_count`, `sum`, `average`.
+  - For `numbers` it must be: `add`.
+- `--ee` Indicates if the metric is for EE.
+
+```shell
+rails generate gitlab:usage_metric CountIssues --type database --operation distinct_count
+        create lib/gitlab/usage/metrics/instrumentations/count_issues_metric.rb
+        create spec/lib/gitlab/usage/metrics/instrumentations/count_issues_metric_spec.rb
+```
+
+## Migrate Service Ping metrics to instrumentation classes
+
+This guide describes how to migrate a Service Ping metric from [`lib/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb) or [`ee/lib/ee/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/usage_data.rb) to instrumentation classes.
+
+1. Choose the metric type:
+
+- [Database metric](#database-metrics)
+- [Redis HyperLogLog metrics](#redis-hyperloglog-metrics)
+- [Redis metric](#redis-metrics)
+- [Numbers metric](#numbers-metrics)
+- [Generic metric](#generic-metrics)
+
+1. Determine the location of instrumentation class: either under `ee` or outside `ee`.
+
+1. [Generate the instrumentation class file](#create-a-new-metric-instrumentation-class).
+
+1. Fill the instrumentation class body:
+
+   - Add code logic for the metric. This might be similar to the metric implementation in `usage_data.rb`.
+   - Add tests for the individual metric [`spec/lib/gitlab/usage/metrics/instrumentations/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/usage/metrics/instrumentations).
+   - Add tests for Service Ping.
+
+1. [Generate the metric definition file](metrics_dictionary.md#create-a-new-metric-definition).
+
+1. Remove the code from [`lib/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb) or [`ee/lib/ee/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/usage_data.rb).
+
+1. Remove the tests from [`spec/lib/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/lib/gitlab/usage_data_spec.rb) or [`ee/spec/lib/ee/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/spec/lib/ee/gitlab/usage_data_spec.rb).
+
+## Troubleshoot metrics
+
+Sometimes metrics fail for reasons that are not immediately clear. The failures can be related to performance issues or other problems.
+The following pairing session video gives you an example of an investigation in to a real-world failing metric.
+
+<div class="video-fallback">
+  See the video from: <a href="https://www.youtube.com/watch?v=y_6m2POx2ug">Product Intelligence Office Hours Oct 27th</a> to learn more about the metrics troubleshooting process.
+</div>
+<figure class="video-container">
+  <iframe src="https://www.youtube-nocookie.com/embed/y_6m2POx2ug" frameborder="0" allowfullscreen> </iframe>
+</figure>
diff --git a/doc/development/internal_analytics/service_ping/metrics_lifecycle.md b/doc/development/internal_analytics/service_ping/metrics_lifecycle.md
new file mode 100644
index 00000000000..cc56863690c
--- /dev/null
+++ b/doc/development/internal_analytics/service_ping/metrics_lifecycle.md
@@ -0,0 +1,106 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Service Ping metric lifecycle
+
+The following guidelines explain the steps to follow at each stage of a metric's lifecycle.
+
+## Add a new metric
+
+Follow the [Implement Service Ping](implement.md) guide.
+
+## Change an existing metric
+
+WARNING:
+We want to **PREVENT** changes to the calculation logic or important attributes on any metric as this invalidates comparisons of the same metric across different versions of GitLab.
+
+If you change a metric, you have to consider that not all instances of GitLab are running on the newest version. Old instances will still report the old version of the metric.
+Additionally, a metric's reported numbers are primarily interesting compared to previously reported numbers.
+As a result, if you need to change one of the following parts of a metric, you need to add a new metric instead. It's your choice whether to keep the old metric alongside the new one or [remove it](#remove-a-metric).
+
+- **calculation logic**: This means any changes that can produce a different value than the previous implementation
+- **YAML attributes**: The following attributes are directly used for analysis or calculation: `key_path`, `time_frame`, `value_type`, `data_source`.
+
+If you change the `performance_indicator_type` attribute of a metric or think your case needs an exception from the outlined rules then please notify the Customer Success Ops team (`@csops-team`), Analytics Engineers (`@gitlab-data/analytics-engineers`), and Product Analysts (`@gitlab-data/product-analysts`) teams by `@` mentioning those groups in a comment on the merge request or issue.
+
+You can change any other attributes without impact to the calculation or analysis. See [this video tutorial](https://youtu.be/bYf3c01KCls) for help updating metric attributes.
+
+Currently, the [Metrics Dictionary](https://metrics.gitlab.com/) is built automatically once a day. You can see the change in the dictionary within 24 hours when you change the metric's YAML file.
+
+## Remove a metric
+
+WARNING:
+If a metric is not used in Sisense or any other system after 6 months, the
+Analytics Instrumentation team marks it as inactive and assigns it to the group owner for review.
+
+We are working on automating this process. See [this epic](https://gitlab.com/groups/gitlab-org/-/epics/8988) for details.
+
+Analytics Instrumentation removes metrics from Service Ping if they are not used in any Sisense dashboard.
+
+For an example of the metric removal process, see this [example issue](https://gitlab.com/gitlab-org/gitlab/-/issues/388236).
+
+To remove a metric:
+
+1. Create an issue for removing the metric if none exists yet. The issue needs to outline why the metric should be deleted. You can use this issue to document the removal process.
+
+1. Verify the metric is not used to calculate the conversational index. The
+   conversational index is a measure that reports back to self-managed instances
+   to inform administrators of the progress of DevOps adoption for the instance.
+
+   You can check
+   [`CalculateConvIndexService`](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/app/services/calculate_conv_index_service.rb)
+   to view the metrics that are used. The metrics are represented
+   as the keys that are passed as a field argument into the `get_value` method.
+
+1. Verify that removing the metric from the Service Ping payload does not cause
+   errors in [Version App](https://gitlab.com/gitlab-services/version-gitlab-com)
+   when the updated payload is collected and processed. Version App collects
+   and persists all Service Ping reports. To verify Service Ping processing in your local development environment, follow this [guide](https://www.youtube.com/watch?v=FS5emplabRU).
+   Alternatively, you can modify [fixtures](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/spec/support/usage_data_helpers.rb#L540)
+   used to test the [`UsageDataController#create`](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/3760ef28/spec/controllers/usage_data_controller_spec.rb#L75)
+   endpoint, and assure that test suite does not fail when metric that you wish to remove is not included into test payload.
+
+1. Remove data from Redis
+
+   For [Ordinary Redis](implement.md#ordinary-redis-counters) counters remove data stored in Redis.
+
+   - Add a migration to remove the data from Redis for the related Redis keys. For more details, see [this MR example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82604/diffs).
+
+1. Create an issue in the
+   [GitLab Data Team project](https://gitlab.com/gitlab-data/analytics/-/issues).
+   Ask for confirmation that the metric is not referred to in any SiSense dashboards and
+   can be safely removed from Service Ping. Use this
+   [example issue](https://gitlab.com/gitlab-data/analytics/-/issues/15266) for guidance.
+
+1. Notify the Customer Success Ops team (`@csops-team`), Analytics Engineers (`@gitlab-data/analytics-engineers`), and Product Analysts (`@gitlab-data/product-analysts`) by `@` mentioning those groups in a comment in the issue from step 1 regarding the deletion of the metric.
+   Many Service Ping metrics are relied upon for health score and XMAU reporting and unexpected changes to those metrics could break reporting.
+
+1. After you verify the metric can be safely removed,
+   update the attributes of the metric's YAML definition:
+
+   - Set the `status:` to `removed`.
+   - Set `removed_by_url:` to the URL of the MR removing the metric
+   - Set `milestone_removed:` to the number of the
+     milestone in which the metric was removed.
+
+   Do not remove the metric's YAML definition altogether. Some self-managed
+   instances might not immediately update to the latest version of GitLab, and
+   therefore continue to report the removed metric. The Analytics Instrumentation team
+   requires a record of all removed metrics to identify and filter them.
+
+   For example please take a look at this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60149/diffs#b01f429a54843feb22265100c0e4fec1b7da1240_10_10).
+
+1. After you verify the metric can be safely removed,
+   remove the metric's instrumentation from
+   [`lib/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb)
+   or
+   [`ee/lib/ee/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/usage_data.rb).
+
+   For example please take a look at this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60149/diffs#6335dc533bd21df26db9de90a02dd66278c2390d_167_167).
+
+1. Remove any other records related to the metric:
+   - The feature flag YAML file at [`config/feature_flags/*/*.yaml`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/feature_flags).
+   - The entry in the known events YAML file at [`lib/gitlab/usage_data_counters/known_events/*.yaml`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/usage_data_counters/known_events).
diff --git a/doc/development/internal_analytics/service_ping/performance_indicator_metrics.md b/doc/development/internal_analytics/service_ping/performance_indicator_metrics.md
new file mode 100644
index 00000000000..d7811c52bb1
--- /dev/null
+++ b/doc/development/internal_analytics/service_ping/performance_indicator_metrics.md
@@ -0,0 +1,16 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Performance Indicator Metrics guide
+
+This guide describes how to use metrics definitions to define [performance indicator](https://about.gitlab.com/handbook/product/analytics-instrumentation-guide/#implementing-product-performance-indicators) metrics.
+
+To use a metric definition to manage a performance indicator:
+
+1. Create a merge request that includes related changes.
+1. Use labels `~"analytics instrumentation"`, `"~Data Warehouse::Impact Check"`.
+1. Update the metric definition `performance_indicator_type` [field](metrics_dictionary.md#metrics-definition-and-validation).
+1. Create an issue in GitLab Product Data Insights project with the [PI Chart Help template](https://gitlab.com/gitlab-data/product-analytics/-/issues/new?issuable_template=PI%20Chart%20Help) to have the new metric visualized.
diff --git a/doc/development/internal_analytics/service_ping/review_guidelines.md b/doc/development/internal_analytics/service_ping/review_guidelines.md
new file mode 100644
index 00000000000..31b6c3f5580
--- /dev/null
+++ b/doc/development/internal_analytics/service_ping/review_guidelines.md
@@ -0,0 +1,80 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Service Ping review guidelines
+
+This page includes introductory material for a
+[Analytics Instrumentation](https://about.gitlab.com/handbook/engineering/development/analytics/analytics-instrumentation/)
+review, and is specific to Service Ping related reviews. For broader advice and
+general best practices for code reviews, refer to our [code review guide](../../code_review.md).
+
+## Resources for reviewers
+
+- [Service Ping Guide](index.md)
+- [Metrics Dictionary](https://metrics.gitlab.com/)
+
+## Review process
+
+We recommend a Analytics Instrumentation review when a merge request (MR) touches
+any of the following Service Ping files:
+
+- `usage_data*` files.
+- The Metrics Dictionary, including files in:
+  - [`config/metrics`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/metrics).
+  - [`ee/config/metrics`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/config/metrics).
+  - [`schema.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json).
+- Analytics Instrumentation tooling. For example,
+  [`Gitlab::UsageMetricDefinitionGenerator`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_definition_generator.rb)
+
+### Roles and process
+
+#### The merge request **author** should
+
+- Decide whether a Analytics Instrumentation review is needed. You can skip the Analytics Instrumentation
+review and remove the labels if the changes are not related to the Analytics Instrumentation domain and
+are regular backend changes.
+- If a Analytics Instrumentation review is needed, add the labels
+  `~analytics instrumentation` and `~analytics instrumentation::review pending`.
+- For merge requests authored by Analytics Instrumentation team members:
+  - Assign both the `~backend` and `~analytics instrumentation` reviews to another Analytics Instrumentation team member.
+  - Assign the maintainer review to someone outside of the Analytics Instrumentation group.
+- Assign an
+  [engineer](https://gitlab.com/groups/gitlab-org/analytics-section/analytics-instrumentation/engineers/-/group_members?with_inherited_permissions=exclude) from the Analytics Instrumentation team for a review.
+- Set the correct attributes in the metric's YAML definition:
+  - `product_section`, `product_stage`, `product_group`
+  - Provide a clear description of the metric.
+- Add a changelog [according to guidelines](../../changelog.md).
+
+#### The Analytics Instrumentation **reviewer** should
+
+- Perform a first-pass review on the merge request and suggest improvements to the author.
+- Check the [metrics location](metrics_dictionary.md#metric-key_path) in
+  the Service Ping JSON payload.
+- Add the `~database` label and ask for a [database review](../../database_review.md) for
+  metrics that are based on Database.
+- Add `~Data Warehouse::Impact Check` for any database metric that has a query change. Changes in queries can affect [data operations](https://about.gitlab.com/handbook/business-technology/data-team/how-we-work/triage/#gitlabcom-db-structure-changes).
+- For tracking using Redis HLL (HyperLogLog):
+  - Check if a [feature flag is needed](implement.md#recommendations).
+- For a metric's YAML definition:
+  - Check the metric's `description`.
+  - Check the metric's `key_path`.
+  - Check the `product_section`, `product_stage`, and `product_group` fields.
+    Read the [stages file](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml).
+  - Check the file location. Consider the time frame, and if the file should be under `ee`.
+  - Check the tiers.
+- If a metric was changed or removed: Make sure the MR author notified the Customer Success Ops team (`@csops-team`), Analytics Engineers (`@gitlab-data/analytics-engineers`), and Product Analysts (`@gitlab-data/product-analysts`) by `@` mentioning those groups in a comment on the issue for the MR and all of these groups have acknowledged the removal.
+- Metrics instrumentations
+  - Recommend using metrics instrumentation for new metrics, [if possible](metrics_instrumentation.md#support-for-instrumentation-classes).
+- Approve the MR, and relabel the MR with `~"analytics instrumentation::approved"`.
+
+## Review workload distribution
+
+[Danger bot](../../dangerbot.md) adds the list of changed Analytics Instrumentation files
+and pings the
+[`@gitlab-org/analytics-section/analytics-instrumentation/engineers`](https://gitlab.com/groups/gitlab-org/analytics-section/analytics-instrumentation/engineers/-/group_members?with_inherited_permissions=exclude) group for merge requests
+that are not drafts.
+
+Any of the Analytics Instrumentation engineers can be assigned for the Analytics Instrumentation review.
diff --git a/doc/development/internal_analytics/service_ping/troubleshooting.md b/doc/development/internal_analytics/service_ping/troubleshooting.md
new file mode 100644
index 00000000000..2b285b85bd0
--- /dev/null
+++ b/doc/development/internal_analytics/service_ping/troubleshooting.md
@@ -0,0 +1,164 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Troubleshooting Service Ping
+
+## Service Ping Payload drop
+
+### Symptoms
+
+You will be alerted by the [Data team](https://about.gitlab.com/handbook/business-technology/data-team/) and their [Monte Carlo alerting](https://about.gitlab.com/handbook/business-technology/data-team/platform/monte-carlo/).
+
+### Locating the problem
+
+First you need to identify at which stage in Service Ping data pipeline the drop is occurring.
+
+Start at [Service Ping Health Dashboard](https://app.periscopedata.com/app/gitlab/968489) on Sisense.
+
+You can use [this query](https://gitlab.com/gitlab-org/gitlab/-/issues/347298#note_836685350) as an example, to start detecting when the drop started.
+
+### Troubleshoot the GitLab application layer
+
+For results about an investigation conducted into an unexpected drop in Service ping Payload events volume, see [this issue](https://gitlab.com/gitlab-data/analytics/-/issues/11071).
+
+### Troubleshoot VersionApp layer
+
+Check if the [export jobs](https://gitlab.com/gitlab-services/version-gitlab-com#data-export-using-pipeline-schedules) are successful.
+
+Check [Service Ping errors](https://app.periscopedata.com/app/gitlab/968489?widget=14609989&udv=0) in the [Service Ping Health Dashboard](https://app.periscopedata.com/app/gitlab/968489).
+
+### Troubleshoot Google Storage layer
+
+Check if the files are present in [Google Storage](https://console.cloud.google.com/storage/browser/cloudsql-gs-production-efd5e8-cloudsql-exports;tab=objects?project=gs-production-efd5e8&prefix=&forceOnObjectsSortingFiltering=false).
+
+### Troubleshoot the data warehouse layer
+
+Reach out to the [Data team](https://about.gitlab.com/handbook/business-technology/data-team/) to ask about current state of data warehouse. On their handbook page there is a [section with contact details](https://about.gitlab.com/handbook/business-technology/data-team/#how-to-connect-with-us).
+
+### Cannot disable Service Ping with the configuration file
+
+The method to disable Service Ping with the GitLab configuration file does not work in
+GitLab versions 9.3.0 to 13.12.3. To disable it, you must use the Admin Area in
+the GitLab UI instead. For more information, see
+[this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/333269).
+
+GitLab functionality and application settings cannot override or circumvent
+restrictions at the network layer. If Service Ping is blocked by your firewall,
+you are not impacted by this bug.
+
+#### Check if you are affected
+
+You can check if you were affected by this bug by using the Admin Area or by
+checking the configuration file of your GitLab instance:
+
+- Using the Admin Area:
+
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
+  1. On the left sidebar, select **Settings > Metrics and profiling**.
+  1. Expand **Usage statistics**.
+  1. Are you able to check or uncheck the checkbox to disable Service Ping?
+
+     - If _yes_, your GitLab instance is not affected by this bug.
+     - If you can't check or uncheck the checkbox, you are affected by this bug.
+       See the steps on [how to fix this](#how-to-fix-the-cannot-disable-service-ping-bug).
+
+- Checking your GitLab instance configuration file:
+
+  To check whether you're impacted by this bug, check your instance configuration
+  settings. The configuration file in which Service Ping can be disabled depends
+  on your installation and deployment method, but is typically one of the following:
+
+  - `/etc/gitlab/gitlab.rb` for Linux package installations and Docker.
+  - `charts.yaml` for GitLab Helm and cloud-native Kubernetes deployments.
+  - `gitlab.yml` for GitLab installations from source.
+
+  To check the relevant configuration file for strings that indicate whether
+  Service Ping is disabled, you can use `grep`:
+
+  ```shell
+  # Linux package
+  grep "usage_ping_enabled'\] = false" /etc/gitlab/gitlab.rb
+
+  # Kubernetes charts
+  grep "enableUsagePing: false" values.yaml
+
+  # From source
+  grep "usage_ping_enabled'\] = false" gitlab/config.yml
+  ```
+
+  If you see any output after running the relevant command, your GitLab instance
+  may be affected by the bug. Otherwise, your instance is not affected.
+
+#### How to fix the "Cannot disable Service Ping" bug
+
+To work around this bug, you have two options:
+
+- [Update](../../../update/index.md) to GitLab 13.12.4 or newer to fix this bug.
+- If you can't update to GitLab 13.12.4 or newer, enable Service Ping in the
+  configuration file, then disable Service Ping in the UI. For example, if you're
+  using the Linux package:
+
+  1. Edit `/etc/gitlab/gitlab.rb`:
+
+     ```ruby
+     gitlab_rails['usage_ping_enabled'] = true
+     ```
+
+  1. Reconfigure GitLab:
+
+     ```shell
+     sudo gitlab-ctl reconfigure
+     ```
+
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
+  1. On the left sidebar, select **Settings > Metrics and profiling**.
+  1. Expand **Usage statistics**.
+  1. Clear the **Enable Service Ping** checkbox.
+  1. Select **Save Changes**.
+
+## Generate Service Ping
+
+### Generate or get the cached Service Ping in rails console
+
+Use the following method in the [rails console](../../../administration/operations/rails_console.md#starting-a-rails-console-session).
+
+```ruby
+Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values, cached: true)
+```
+
+### Generate a fresh new Service Ping
+
+Use the following method in the [rails console](../../../administration/operations/rails_console.md#starting-a-rails-console-session).
+
+This also refreshes the cached Service Ping displayed in the Admin Area.
+
+```ruby
+Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values)
+```
+
+### Generate and print
+
+Generates Service Ping data in JSON format.
+
+```shell
+gitlab-rake gitlab:usage_data:generate
+```
+
+Generates Service Ping data in YAML format:
+
+```shell
+gitlab-rake gitlab:usage_data:dump_sql_in_yaml
+```
+
+### Generate and send Service Ping
+
+Prints the metrics saved in `conversational_development_index_metrics`.
+
+```shell
+gitlab-rake gitlab:usage_data:generate_and_send
+```
diff --git a/doc/development/internal_analytics/service_ping/usage_data.md b/doc/development/internal_analytics/service_ping/usage_data.md
new file mode 100644
index 00000000000..b6ec3e00670
--- /dev/null
+++ b/doc/development/internal_analytics/service_ping/usage_data.md
@@ -0,0 +1,69 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Usage Data Metrics guide
+
+This guide describes deprecated usage for metrics in `usage_data.rb`.
+
+NOTE:
+Implementing metrics direct in `usage_data.rb` is deprecated, We recommend you use [instrumentation classes](metrics_instrumentation.md).
+
+## Ordinary batch counters
+
+Simple count of a given `ActiveRecord_Relation`, does a non-distinct batch count, smartly reduces `batch_size`, and handles errors.
+Handles the `ActiveRecord::StatementInvalid` error.
+
+Method:
+
+```ruby
+count(relation, column = nil, batch: true, start: nil, finish: nil)
+```
+
+Arguments:
+
+- `relation` the ActiveRecord_Relation to perform the count
+- `column` the column to perform the count on, by default is the primary key
+- `batch`: default `true` to use batch counting
+- `start`: custom start of the batch counting to avoid complex min calculations
+- `end`: custom end of the batch counting to avoid complex min calculations
+
+Examples:
+
+```ruby
+count(User.active)
+count(::Clusters::Cluster.aws_installed.enabled, :cluster_id)
+count(::Clusters::Cluster.aws_installed.enabled, :cluster_id, start: ::Clusters::Cluster.minimum(:id), finish: ::Clusters::Cluster.maximum(:id))
+```
+
+## Distinct batch counters
+
+Distinct count of a given `ActiveRecord_Relation` on given column, a distinct batch count, smartly reduces `batch_size`, and handles errors.
+Handles the `ActiveRecord::StatementInvalid` error.
+
+Method:
+
+```ruby
+distinct_count(relation, column = nil, batch: true, batch_size: nil, start: nil, finish: nil)
+```
+
+Arguments:
+
+- `relation`: the ActiveRecord_Relation to perform the count
+- `column`: the column to perform the distinct count, by default is the primary key
+- `batch`: default `true` to use batch counting
+- `batch_size`: if none set it uses default value 10000 from `Gitlab::Database::BatchCounter`
+- `start`: custom start of the batch counting to avoid complex min calculations
+- `end`: custom end of the batch counting to avoid complex min calculations
+
+WARNING:
+Counting over non-unique columns can lead to performance issues. For more information, see the [iterating tables in batches](../../database/iterating_tables_in_batches.md) guide.
+
+Examples:
+
+```ruby
+distinct_count(::Project, :creator_id)
+distinct_count(::Note.with_suggestions.where(time_period), :author_id, start: ::User.minimum(:id), finish: ::User.maximum(:id))
+```
diff --git a/doc/development/internal_analytics/snowplow/event_dictionary_guide.md b/doc/development/internal_analytics/snowplow/event_dictionary_guide.md
new file mode 100644
index 00000000000..6e8947e0210
--- /dev/null
+++ b/doc/development/internal_analytics/snowplow/event_dictionary_guide.md
@@ -0,0 +1,91 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Event dictionary guide
+
+NOTE:
+The event dictionary is a work in progress, and this process is subject to change.
+
+This guide describes the event dictionary and how it's implemented.
+
+## Event definition and validation
+
+This process is meant to document all Snowplow events and ensure consistency. Every Snowplow event needs to have such a definition. Event definitions must comply with the [JSON Schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/events/schema.json).
+
+All event definitions are stored in the following directories:
+
+- [`config/events`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/events)
+- [`ee/config/events`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/config/events)
+
+Each event is defined in a separate YAML file consisting of the following fields:
+
+| Field                  | Required | Additional information                                                                                                                                                                      |
+|------------------------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `description`          | yes      | A description of the event.                                                                                                                                                                 |
+| `category`             | yes      | The event category (see [Event schema](index.md#event-schema)).                                                                                                                             |
+| `action`               | yes      | The event action (see [Event schema](index.md#event-schema)).                                                                                                                               |
+| `label_description`    | no       | A description of the event label (see [Event schema](index.md#event-schema)).                                                                                                               |
+| `property_description` | no       | A description of the event property (see [Event schema](index.md#event-schema)).                                                                                                            |
+| `value_description`    | no       | A description of the event value (see [Event schema](index.md#event-schema)).                                                                                                               |
+| `extra_properties`     | no       | The type and description of each extra property sent with the event.                                                                                                                        |
+| `identifiers`          | no       | A list of identifiers sent with the event. Can be set to one or more of `project`, `user`, or `namespace`.                                                                                  |
+| `iglu_schema_url`      | no       | The URL to the custom schema sent with the event, for example, `iglu:com.gitlab/gitlab_experiment/jsonschema/1-0-0`.                                                                        |
+| `product_section`      | yes      | The [section](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/sections.yml).                                                                                                |
+| `product_stage`        | no       | The [stage](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) for the event.                                                                                        |
+| `product_group`        | yes      | The [group](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) that owns the event.                                                                                  |
+| `milestone`            | no       | The milestone when the event is introduced.                                                                                                                                                 |
+| `introduced_by_url`    | no       | The URL to the merge request that introduced the event.                                                                                                                                     |
+| `distributions`        | yes      | The [distributions](https://about.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/tiers/#definitions) where the tracked feature is available. Can be set to one or more of `ce` or `ee`.  |
+| `tiers`                | yes      | The [tiers](https://about.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/tiers/) where the tracked feature is available. Can be set to one or more of `free`, `premium`, or `ultimate`. |
+
+### Example event definition
+
+The linked [`uuid`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/events/epics_promote.yml)
+YAML file includes an example event definition.
+
+```yaml
+description: Issue promoted to epic
+category: epics
+action: promote
+property_description: The string "issue_id"
+value_description: ID of the issue
+extra_properties:
+  weight:
+    type: integer
+    description: Weight of the issue
+identifiers:
+- project
+- user
+- namespace
+product_section: dev
+product_stage: plan
+product_group: group::product planning
+milestone: "11.10"
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/10537
+distributions:
+- ee
+tiers:
+- premium
+- ultimate
+```
+
+## Create a new event definition
+
+Use the dedicated [event definition generator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/snowplow_event_definition_generator.rb)
+to create new event definitions.
+
+The `category` and `action` of each event are included in the filename to standardize file naming.
+
+The generator takes three options:
+
+- `--ee`: Indicates if the event is for EE.
+- `--category=CATEGORY`: Indicates the `category` of the event.
+- `--action=ACTION`: Indicates the `action` of the event.
+
+```shell
+bundle exec rails generate gitlab:snowplow_event_definition --category Groups::EmailCampaignsController --action click
+create  create  config/events/groups__email_campaigns_controller_click.yml
+```
diff --git a/doc/development/internal_analytics/snowplow/implementation.md b/doc/development/internal_analytics/snowplow/implementation.md
new file mode 100644
index 00000000000..5ad97cf528c
--- /dev/null
+++ b/doc/development/internal_analytics/snowplow/implementation.md
@@ -0,0 +1,523 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Implement Snowplow tracking
+
+This page describes how to:
+
+- Implement Snowplow frontend and backend tracking
+- Test Snowplow events
+
+## Event definitions
+
+Every Snowplow event, regardless of frontend or backend, requires a corresponding event definition. These definitions document the event and its properties to make it easier to maintain and analyze.
+These definitions can be browsed in the [event dictionary](https://metrics.gitlab.com/snowplow/). The [event dictionary guide](event_dictionary_guide.md) provides instructions for setting up an event definition.
+
+## Snowplow JavaScript frontend tracking
+
+GitLab provides a `Tracking` interface that wraps the [Snowplow JavaScript tracker](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/)
+to track custom events.
+
+For the recommended frontend tracking implementation, see [Usage recommendations](#usage-recommendations).
+
+Structured events and page views include the [`gitlab_standard`](schemas.md#gitlab_standard)
+context, using the `window.gl.snowplowStandardContext` object which includes
+[default data](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/views/layouts/_snowplow.html.haml)
+as base:
+
+| Property | Example |
+| -------- | ------- |
+| `context_generated_at` | `"2022-01-01T01:00:00.000Z"` |
+| `environment` | `"production"` |
+| `extra` | `{}` |
+| `namespace_id` | `123` |
+| `plan` | `"gold"` |
+| `project_id` | `456` |
+| `source` | `"gitlab-rails"` |
+| `user_id` | `789`* |
+| `is_gitlab_team_member` | `true`|
+
+_\* Undergoes a pseudonymization process at the collector level._
+
+These properties [are overridden](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/tracking/get_standard_context.js)
+with frontend-specific values, like `source` (`gitlab-javascript`), `google_analytics_id`
+and the custom `extra` object. You can modify this object for any subsequent
+structured event that fires, although this is not recommended.
+
+Tracking implementations must have an `action` and a `category`. You can provide additional
+properties from the [event schema](index.md#event-schema), in
+addition to an `extra` object that accepts key-value pairs.
+
+| Property      | Type   | Default value              | Description                                                                                                                                                                                 |
+|:-----------|:-------|:---------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `category` | string | `document.body.dataset.page` | Page or subsection of a page in which events are captured.                                                                                                                                  |
+| `action`   | string | `'generic'`                  | Action the user is taking. Clicks must be `click` and activations must be `activate`. For example, focusing a form field is `activate_form_input`, and clicking a button is `click_button`. |
+| `data`     | object | `{}`                         | Additional data such as `label`, `property`, `value` as described in [Event schema](index.md#event-schema), `context` for custom contexts, and `extra` (key-value pairs object).            |
+
+### Usage recommendations
+
+- Use [data attributes](#implement-data-attribute-tracking) on HTML elements that emit `click`, `show.bs.dropdown`, or `hide.bs.dropdown` events.
+- Use the [Vue mixin](#implement-vue-component-tracking) for tracking custom events, or if the supported events for data attributes are not propagating. For example, clickable components that don't emit `click`.
+- Use the [tracking class](#implement-raw-javascript-tracking) when tracking in vanilla JavaScript files.
+
+### Implement data attribute tracking
+
+To implement tracking for HAML or Vue templates, add a [`data-track` attribute](#data-track-attributes) to the element.
+
+The following example shows `data-track-*` attributes assigned to a button:
+
+```haml
+%button.btn{ data: { track_action: "click_button", track_label: "template_preview", track_property: "my-template" } }
+```
+
+```html
+<button class="btn"
+  data-track-action="click_button"
+  data-track-label="template_preview"
+  data-track-property="my-template"
+  data-track-extra='{ "template_variant": "primary" }'
+/>
+```
+
+#### `data-track` attributes
+
+| Attribute             | Required | Description |
+|:----------------------|:---------|:------------|
+| `data-track-action`    | true     | Action the user is taking. Clicks must be prepended with `click` and activations must be prepended with `activate`. For example, focusing a form field is `activate_form_input` and clicking a button is `click_button`. Replaces `data-track-event`, which was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/290962) in GitLab 13.11. |
+| `data-track-label`    | false    | The specific element or object to act on. This can be: the label of the element, for example, a tab labeled 'Create from template' for `create_from_template`; a unique identifier if no text is available, for example, `groups_dropdown_close` for closing the Groups dropdown list; or the name or title attribute of a record being created. |
+| `data-track-property` | false    | Any additional property of the element, or object being acted on. |
+| `data-track-value`    | false    | Describes a numeric value (decimal) directly related to the event. This could be the value of an input. For example, `10` when clicking `internal` visibility. If omitted, this is the element's `value` property or `undefined`. For checkboxes, the default value is the element's checked attribute or `0` when unchecked. The value is parsed as numeric before sending the event. |
+| `data-track-extra` | false    | A key-value pair object passed as a valid JSON string. This attribute is added to the `extra` property in our [`gitlab_standard`](schemas.md#gitlab_standard) schema. |
+| `data-track-context`  | false    | To append a custom context object, passed as a valid JSON string. |
+
+#### Event listeners
+
+Event listeners bind at the document level to handle click events in elements with data attributes.
+This allows them to be handled when the DOM re-renders or changes. Document-level binding reduces
+the likelihood that click events stop propagating up the DOM tree.
+
+If click events stop propagating, you must implement listeners and [Vue component tracking](#implement-vue-component-tracking) or [raw JavaScript tracking](#implement-raw-javascript-tracking).
+
+#### Helper methods
+
+You can use the following Ruby helpers:
+
+```ruby
+tracking_attrs(label, action, property) # { data: { track_label... } }
+
+tracking_attrs_data(label, action, property) # { track_label... }
+```
+
+You can also use it on HAML templates:
+
+```haml
+%button{ **tracking_attrs('main_navigation', 'click_button', 'navigation') }
+
+// When merging with additional data
+// %button{ data: { platform: "...", **tracking_attrs_data('main_navigation', 'click_button', 'navigation') } }
+```
+
+If you use the GitLab helper method [`nav_link`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/helpers/tab_helper.rb#L76), you must wrap `html_options` under the `html_options` keyword argument. If you
+use the `ActionView` helper method [`link_to`](https://api.rubyonrails.org/classes/ActionView/Helpers/UrlHelper.html#method-i-link_to), you don't need to wrap `html_options`.
+
+```ruby
+# Bad
+= nav_link(controller: ['dashboard/groups', 'explore/groups'], data: { track_label: "explore_groups",
+track_action: "click_button" })
+
+# Good
+= nav_link(controller: ['dashboard/groups', 'explore/groups'], html_options: { data: { track_label:
+"explore_groups", track_action: "click_button" } })
+
+# Good (other helpers)
+= link_to explore_groups_path, title: _("Explore"), data: { track_label: "explore_groups", track_action:
+"click_button" }
+```
+
+### Implement Vue component tracking
+
+For custom event tracking, use the [Vue mixin](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/tracking/tracking.js#L207). It exposes `Tracking.event` as the `track` method.
+You can specify tracking options by creating a `tracking` data object or
+computed property, and as a second parameter: `this.track('click_button', opts)`.
+These options override any defaults and allow the values to be dynamic from props or based on state:
+
+| Property | Type | Default | Example |
+| -- | -- | -- | -- |
+| `category` | string | `document.body.dataset.page` | `'code_quality_walkthrough'` |
+| `label` | string | `''` | `'process_start_button'` |
+| `property` | string | `''` | `'asc'` or `'desc'` |
+| `value` | integer | `undefined` | `0`, `1`, `500` |
+| `extra` | object | `{}` | `{ selectedVariant: this.variant }` |
+
+To implement Vue component tracking:
+
+1. Import the `Tracking` library and call the `mixin` method:
+
+   ```javascript
+   import Tracking from '~/tracking';
+
+   const trackingMixin = Tracking.mixin();
+
+   // Optionally provide default properties
+   // const trackingMixin = Tracking.mixin({ label: 'right_sidebar' });
+   ```
+
+1. Use the mixin in the component:
+
+   ```javascript
+   export default {
+     mixins: [trackingMixin],
+     // Or
+     // mixins: [Tracking.mixin()],
+     // mixins: [Tracking.mixin({ label: 'right_sidebar' })],
+
+     data() {
+       return {
+         expanded: false,
+       };
+     },
+   };
+   ```
+
+1. You can specify tracking options in by creating a `tracking` data object
+or computed property:
+
+   ```javascript
+   export default {
+     name: 'RightSidebar',
+
+     mixins: [Tracking.mixin()],
+
+     data() {
+       return {
+         expanded: false,
+         variant: '',
+         tracking: {
+           label: 'right_sidebar',
+           // property: '',
+           // value: '',
+           // experiment: '',
+           // extra: {},
+         },
+       };
+     },
+
+     // Or
+     // computed: {
+     //   tracking() {
+     //     return {
+     //       property: this.variant,
+     //       extra: { expanded: this.expanded },
+     //     };
+     //   },
+     // },
+   };
+   ```
+
+1. Call the `track` method. Tracking options can be passed as the second parameter:
+
+   ```javascript
+   this.track('click_button', {
+     label: 'right_sidebar',
+   });
+   ```
+
+   Or use the `track` method in the template:
+
+   ```html
+   <template>
+     <div>
+       <button data-testid="toggle" @click="toggle">Toggle</button>
+
+       <div v-if="expanded">
+         <p>Hello world!</p>
+         <button @click="track('click_button')">Track another event</button>
+       </div>
+     </div>
+   </template>
+   ```
+
+#### Testing example
+
+```javascript
+export default {
+  name: 'CountDropdown',
+
+  mixins: [Tracking.mixin({ label: 'count_dropdown' })],
+
+  data() {
+    return {
+      variant: 'counter',
+      count: 0,
+    };
+  },
+
+  methods: {
+    handleChange({ target }) {
+      const { variant } = this;
+
+      this.count = Number(target.value);
+
+      this.track('change_value', {
+        value: this.count,
+        extra: { variant }
+      });
+    },
+  },
+};
+```
+
+```javascript
+import { mockTracking } from 'helpers/tracking_helper';
+// mockTracking(category, documentOverride, spyMethod)
+
+describe('CountDropdown.vue', () => {
+  let trackingSpy;
+  let wrapper;
+
+  ...
+
+  beforeEach(() => {
+    trackingSpy = mockTracking(undefined, wrapper.element, jest.spyOn);
+  });
+
+  const findDropdown = () => wrapper.find('[data-testid="dropdown"]');
+
+  it('tracks change event', () => {
+    const dropdown = findDropdown();
+    dropdown.element.value = 30;
+    dropdown.trigger('change');
+
+    expect(trackingSpy).toHaveBeenCalledWith(undefined, 'change_value', {
+      value: 30,
+      label: 'count_dropdown',
+      extra: { variant: 'counter' },
+    });
+  });
+});
+```
+
+### Implement raw JavaScript tracking
+
+To track from a vanilla JavaScript file, use the `Tracking.event` static function
+(calls [`dispatchSnowplowEvent`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/tracking/dispatch_snowplow_event.js)).
+
+The following example demonstrates tracking a click on a button by manually calling `Tracking.event`.
+
+```javascript
+import Tracking from '~/tracking';
+
+const button = document.getElementById('create_from_template_button');
+
+button.addEventListener('click', () => {
+  Tracking.event(undefined, 'click_button', {
+    label: 'create_from_template',
+    property: 'template_preview',
+    extra: {
+      templateVariant: 'primary',
+      valid: 1,
+    },
+  });
+});
+```
+
+#### Testing example
+
+```javascript
+import Tracking from '~/tracking';
+
+describe('MyTracking', () => {
+  let wrapper;
+
+  beforeEach(() => {
+    jest.spyOn(Tracking, 'event');
+  });
+
+  const findButton = () => wrapper.find('[data-testid="create_from_template"]');
+
+  it('tracks event', () => {
+    findButton().trigger('click');
+
+    expect(Tracking.event).toHaveBeenCalledWith(undefined, 'click_button', {
+      label: 'create_from_template',
+      property: 'template_preview',
+      extra: {
+        templateVariant: 'primary',
+        valid: true,
+      },
+    });
+  });
+});
+```
+
+### Form tracking
+
+To enable Snowplow automatic [form tracking](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracking-specific-events/#form-tracking):
+
+1. Call `Tracking.enableFormTracking` when the DOM is ready.
+1. Provide a `config` object that includes at least one of the following elements:
+    - `forms` determines the forms to track. Identified by the CSS class name.
+    - `fields` determines the fields inside the tracked forms to track. Identified by the field `name`.
+1. Optional. Provide a list of contexts as the second argument. The [`gitlab_standard`](schemas.md#gitlab_standard) schema is excluded from these events.
+
+```javascript
+Tracking.enableFormTracking({
+  forms: { allow: ['sign-in-form', 'password-recovery-form'] },
+  fields: { allow: ['terms_and_conditions', 'newsletter_agreement'] },
+});
+```
+
+#### Testing example
+
+```javascript
+import Tracking from '~/tracking';
+
+describe('MyFormTracking', () => {
+  let formTrackingSpy;
+
+  beforeEach(() => {
+    formTrackingSpy = jest
+      .spyOn(Tracking, 'enableFormTracking')
+      .mockImplementation(() => null);
+  });
+
+  it('initialized with the correct configuration', () => {
+    expect(formTrackingSpy).toHaveBeenCalledWith({
+      forms: { allow: ['sign-in-form', 'password-recovery-form'] },
+      fields: { allow: ['terms_and_conditions', 'newsletter_agreement'] },
+    });
+  });
+});
+```
+
+## Implement Ruby backend tracking
+
+`Gitlab::Tracking` is an interface that wraps the [Snowplow Ruby Tracker](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/ruby-tracker/) for tracking custom events.
+Backend tracking provides:
+
+- User behavior tracking
+- Instrumentation to monitor and visualize performance over time in a section or aspect of code.
+
+To add custom event tracking and instrumentation, call the `GitLab::Tracking.event` class method.
+For example:
+
+```ruby
+class Projects::CreateService < BaseService
+  def execute
+    project = Project.create(params)
+
+    Gitlab::Tracking.event('Projects::CreateService', 'create_project', label: project.errors.full_messages.to_sentence,
+                           property: project.valid?.to_s, project: project, user: current_user, namespace: namespace)
+  end
+end
+```
+
+Use the following arguments:
+
+| Argument   | Type                      | Default value | Description                                                                                                                       |
+|------------|---------------------------|---------------|-----------------------------------------------------------------------------------------------------------------------------------|
+| `category` | String                    |               | Area or aspect of the application. For example,  `HealthCheckController` or `Lfs::FileTransformer`.                  |
+| `action`   | String                    |               | The action being taken. For example, a controller action such as `create`, or an Active Record callback. |
+| `label`    | String                    | `nil`           | The specific element or object to act on. This can be one of the following: the label of the element, for example, a tab labeled 'Create from template' for `create_from_template`; a unique identifier if no text is available, for example, `groups_dropdown_close` for closing the Groups dropdown list; or the name or title attribute of a record being created.                                                          |
+| `property` | String                    | `nil`           | Any additional property of the element, or object being acted on.                                                          |
+| `value`    | Numeric                   | `nil`           | Describes a numeric value (decimal) directly related to the event. This could be the value of an input. For example, `10` when clicking `internal` visibility.                                                          |
+| `context`  | Array\[SelfDescribingJSON\] | `nil`           | An array of custom contexts to send with this event. Most events should not have any custom contexts.                             |
+| `project`  | Project                   | `nil`           | The project associated with the event. |
+| `user`     | User                      | `nil`           | The user associated with the event. This value undergoes a pseudonymization process at the collector level. |
+| `namespace` | Namespace                | `nil`           | The namespace associated with the event. |
+| `extra`   | Hash                | `{}`         | Additional keyword arguments are collected into a hash and sent with the event. |
+
+### Unit testing
+
+To test backend Snowplow events, use the `expect_snowplow_event` helper. For more information, see
+[testing best practices](../../testing_guide/best_practices.md#test-snowplow-events).
+
+### Performance
+
+We use the [AsyncEmitter](https://snowplow.github.io/snowplow-ruby-tracker/SnowplowTracker/AsyncEmitter.html) when tracking events, which allows for instrumentation calls to be run in a background thread. This is still an active area of development.
+
+## Develop and test Snowplow
+
+To develop and test a Snowplow event, there are several tools to test frontend and backend events:
+
+| Testing Tool                                 | Frontend Tracking  | Backend Tracking    | Local Development Environment | Production Environment | Production Environment |
+|----------------------------------------------|--------------------|---------------------|-------------------------------|------------------------|------------------------|
+| Snowplow Analytics Debugger Chrome Extension | Yes | No | Yes            | Yes     | Yes     |
+| Snowplow Inspector Chrome Extension          | Yes | No | Yes            | Yes     | Yes     |
+| Snowplow Micro                               | Yes | Yes  | Yes            | No    | No    |
+
+### Test frontend events
+
+Before you test frontend events in development, you must:
+
+1. [Enable Snowplow tracking in the Admin Area](index.md#enable-snowplow-tracking).
+1. Turn off ad blockers that could prevent Snowplow JavaScript from loading in your environment.
+1. Turn off "Do Not Track" (DNT) in your browser.
+
+All URLs are pseudonymized. The entity identifier [replaces](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracker-setup/other-parameters-2/#setting-a-custom-page-url-and-referrer-url) personally identifiable
+information (PII). PII includes usernames, group, and project names.
+Page titles are hardcoded as `GitLab` for the same reason.
+
+#### Snowplow Analytics Debugger Chrome Extension
+
+[Snowplow Analytics Debugger](https://www.iglooanalytics.com/blog/snowplow-analytics-debugger-chrome-extension.html) is a browser extension for testing frontend events. It works in production, staging, and local development environments.
+
+1. Install the [Snowplow Analytics Debugger](https://chrome.google.com/webstore/detail/snowplow-analytics-debugg/jbnlcgeengmijcghameodeaenefieedm) Chrome browser extension.
+1. Open Chrome DevTools to the Snowplow Analytics Debugger tab.
+
+#### Snowplow Inspector Chrome Extension
+
+Snowplow Inspector Chrome Extension is a browser extension for testing frontend events. This works in production, staging, and local development environments.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For a video tutorial, see the [Snowplow plugin walk through](https://www.youtube.com/watch?v=g4rqnIZ1Mb4).
+
+1. Install [Snowplow Inspector](https://chrome.google.com/webstore/detail/snowplow-inspector/maplkdomeamdlngconidoefjpogkmljm?hl=en).
+1. To open the extension, select the Snowplow Inspector icon beside the address bar.
+1. Click around on a webpage with Snowplow to see JavaScript events firing in the inspector window.
+
+### Test backend events with Snowplow Micro
+
+[Snowplow Micro](https://snowplow.io/blog/introducing-snowplow-micro/) is a
+Docker-based solution for testing backend and frontend in a local development environment. Snowplow Micro
+records the same events as the full Snowplow pipeline. To query events, use the Snowplow Micro API.
+
+It can be set up automatically using [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit).
+See the [how-to docs](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/snowplow_micro.md) for more details.
+
+1. Set the environment variable to tell the GDK to use Snowplow Micro in development. This overrides two `application_settings` options:
+   - `snowplow_enabled` setting will instead return `true` from `Gitlab::Tracking.enabled?`
+   - `snowplow_collector_hostname` setting will instead always return `localhost:9090` (or whatever port is set for `snowplow_micro.port` GDK setting) from `Gitlab::Tracking.collector_hostname`.
+With Snowplow Micro set up you can now manually test backend Snowplow events:
+
+1. Send a test Snowplow event from the Rails console:
+
+   ```ruby
+   Gitlab::Tracking.event('category', 'action')
+   ```
+
+1. Navigate to `localhost:9090/micro/good` to see the event.
+
+#### Useful links
+
+- [Snowplow Micro repository](https://github.com/snowplow-incubator/snowplow-micro)
+- [Installation guide recording](https://www.youtube.com/watch?v=OX46fo_A0Ag)
+
+### Troubleshoot
+
+To control content security policy warnings when using an external host, modify `config/gitlab.yml`
+to allow or prevent them. To allow them, add the relevant host for `connect_src`. For example, for
+`https://snowplow.trx.gitlab.net`:
+
+```yaml
+development:
+  <<: *base
+  gitlab:
+    content_security_policy:
+      enabled: true
+      directives:
+        connect_src: "'self' http://localhost:* http://127.0.0.1:* ws://localhost:* wss://localhost:* ws://127.0.0.1:* https://snowplow.trx.gitlab.net/"
+```
diff --git a/doc/development/internal_analytics/snowplow/index.md b/doc/development/internal_analytics/snowplow/index.md
new file mode 100644
index 00000000000..8265bceaf06
--- /dev/null
+++ b/doc/development/internal_analytics/snowplow/index.md
@@ -0,0 +1,201 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Snowplow development guidelines
+
+Snowplow is an enterprise-grade marketing and Analytics Instrumentation platform that tracks how users engage with our website and application.
+
+[Snowplow](https://snowplow.io/) consists of several loosely-coupled sub-systems:
+
+- **Trackers** fire Snowplow events. Snowplow has twelve trackers that cover web, mobile, desktop, server, and IoT.
+- **Collectors** receive Snowplow events from trackers. We use different event collectors that synchronize events to Amazon S3, Apache Kafka, or Amazon Kinesis.
+- **Enrich** cleans raw Snowplow events, enriches them, and puts them into storage. There is a Hadoop-based enrichment process, and a Kinesis-based or Kafka-based process.
+- **Storage** stores Snowplow events. We store the Snowplow events in a flat file structure on S3, and in the Redshift and PostgreSQL databases.
+- **Data modeling** joins event-level data with other data sets, aggregates them into smaller data sets, and applies business logic. This produces a clean set of tables for data analysis. We use data models for Redshift and Looker.
+- **Analytics** are performed on Snowplow events or on aggregate tables.
+
+![Snowplow flow](../../img/snowplow_flow.png)
+
+## Enable Snowplow tracking
+
+Tracking can be enabled at:
+
+- The instance level, which enables tracking on both the frontend and backend layers.
+- The user level. User tracking can be disabled on a per user basis.
+  GitLab respects the [Do Not Track](https://www.eff.org/issues/do-not-track) standard, so any user who has enabled the Do Not Track option in their browser is not tracked at a user level.
+
+Snowplow tracking is configured to send data for GitLab.com to a collector configured by GitLab. By default, self-managed
+instances do not have a collector configured and do not collect data via Snowplow.
+
+You can configure your self-managed GitLab instance to use a custom Snowplow collector.
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Snowplow**.
+1. Select **Enable Snowplow tracking** and enter your Snowplow configuration information. For example:
+
+   | Name               | Value                         |
+   |--------------------|-------------------------------|
+   | Collector hostname | `your-snowplow-collector.net` |
+   | App ID             | `gitlab`                      |
+   | Cookie domain      | `.your-gitlab-instance.com`   |
+
+1. Select **Save changes**.
+
+## Snowplow request flow
+
+The following example shows a basic request/response flow between the following components:
+
+- Snowplow JS / Ruby Trackers on GitLab.com
+- [GitLab.com Snowplow Collector](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/snowplow/index.md)
+- The GitLab S3 Bucket
+- The GitLab Snowflake Data Warehouse
+- Sisense:
+
+```mermaid
+sequenceDiagram
+    participant Snowplow JS (Frontend)
+    participant Snowplow Ruby (Backend)
+    participant GitLab.com Snowplow Collector
+    participant S3 Bucket
+    participant Snowflake DW
+    participant Sisense Dashboards
+    Snowplow JS (Frontend) ->> GitLab.com Snowplow Collector: FE Tracking event
+    Snowplow Ruby (Backend) ->> GitLab.com Snowplow Collector: BE Tracking event
+    loop Process using Kinesis Stream
+      GitLab.com Snowplow Collector ->> GitLab.com Snowplow Collector: Log raw events
+      GitLab.com Snowplow Collector ->> GitLab.com Snowplow Collector: Enrich events
+      GitLab.com Snowplow Collector ->> GitLab.com Snowplow Collector: Write to disk
+    end
+    GitLab.com Snowplow Collector ->> S3 Bucket: Kinesis Firehose
+    Note over GitLab.com Snowplow Collector, S3 Bucket: Pseudonymization
+    S3 Bucket->>Snowflake DW: Import data
+    Snowflake DW->>Snowflake DW: Transform data using dbt
+    Snowflake DW->>Sisense Dashboards: Data available for querying
+```
+
+For more details about the architecture, see [Snowplow infrastructure](infrastructure.md).
+
+## Event schema
+
+All the events must be consistent. If each feature captures events differently, it can be difficult
+to perform analysis.
+
+Each event provides attributes that describe the event.
+
+| Attribute | Type    | Required | Description |
+| --------- | ------- | -------- | ----------- |
+| category  | text    | true     | The page or backend section of the application. Unless infeasible, use the Rails page attribute by default in the frontend, and namespace + class name on the backend, for example, `Notes::CreateService`. |
+| action    | text    | true     | The action the user takes, or aspect that's being instrumented. The first word must describe the action or aspect. For example, clicks must be `click`, activations must be `activate`, creations must be `create`. Use underscores to describe what was acted on. For example, activating a form field is `activate_form_input`, an interface action like clicking on a dropdown list is `click_dropdown`, a behavior like creating a project record from the backend is `create_project`. |
+| label     | text    | false    | The specific element or object to act on. This can be one of the following: the label of the element, for example, a tab labeled 'Create from template' for `create_from_template`; a unique identifier if no text is available, for example, `groups_dropdown_close` for closing the Groups dropdown list; or the name or title attribute of a record being created. For Service Ping metrics adapted to Snowplow events, this should be the full metric [key path](../service_ping/metrics_dictionary.md#metric-key_path) taken from its definition file. |
+| property  | text    | false    | Any additional property of the element, or object being acted on. For Service Ping metrics adapted to Snowplow events, this should be additional information or context that can help analyze the event. For example, in the case of `usage_activity_by_stage_monthly.create.merge_requests_users`, there are four different possible merge request actions: "create", "merge", "comment", and "close". Each of these would be a possible property value. |
+| value     | decimal | false    | Describes a numeric value (decimal) directly related to the event. This could be the value of an input. For example, `10` when clicking `internal` visibility. |
+| context   | vector  | false    | Additional data in the form of a [self-describing JSON](https://docs.snowplow.io/docs/pipeline-components-and-applications/iglu/common-architecture/self-describing-json-schemas/) to describe the event if the attributes are not sufficient. Each context must have its schema defined to assure data integrity. Refer to the list of GitLab-defined contexts for more details. |
+
+### Examples
+
+| Category* | Label            | Action                | Property** | Value |
+|-------------|------------------|-----------------------|----------|:-----:|
+| `[root:index]` | `main_navigation`            | `click_navigation_link` | `[link_label]`   | - |
+| `[groups:boards:show]` | `toggle_swimlanes` | `click_toggle_button` | - | `[is_active]` |
+| `[projects:registry:index]` | `registry_delete` | `click_button` | - | - |
+| `[projects:registry:index]` | `registry_delete` | `confirm_deletion` | - | - |
+| `[projects:blob:show]` | `congratulate_first_pipeline` | `click_button` | `[human_access]` | - |
+| `[projects:clusters:new]` | `chart_options` | `generate_link` | `[chart_link]` | - |
+| `[projects:clusters:new]` | `chart_options` | `click_add_label_button` | `[label_id]` | - |
+| `API::NpmPackages` | `counts.package_events_i_package_push_package_by_deploy_token` | `push_package` | `npm` | - |
+
+_* If you choose to omit the category you can use the default._<br>
+_** Use property for variable strings._
+
+### Reference SQL
+
+#### Last 20 `reply_comment_button` events
+
+```sql
+SELECT
+  session_id,
+  event_id,
+  event_label,
+  event_action,
+  event_property,
+  event_value,
+  event_category,
+  contexts
+FROM legacy.snowplow_structured_events_all
+WHERE
+  event_label = 'reply_comment_button'
+  AND event_action = 'click_button'
+  -- AND event_category = 'projects:issues:show'
+  -- AND event_value = 1
+ORDER BY collector_tstamp DESC
+LIMIT 20
+```
+
+#### Last 100 page view events
+
+```sql
+SELECT
+  -- page_url,
+  -- page_title,
+  -- referer_url,
+  -- marketing_medium,
+  -- marketing_source,
+  -- marketing_campaign,
+  -- browser_window_width,
+  -- device_is_mobile
+  *
+FROM legacy.snowplow_page_views_30
+ORDER BY page_view_start DESC
+LIMIT 100
+```
+
+#### Top 20 users who fired `reply_comment_button` in the last 30 days
+
+```sql
+SELECT
+  count(*) as hits,
+  se_action,
+  se_category,
+  gsc_pseudonymized_user_id
+FROM legacy.snowplow_gitlab_events_30
+WHERE
+  se_label = 'reply_comment_button'
+  AND gsc_pseudonymized_user_id IS NOT NULL
+GROUP BY gsc_pseudonymized_user_id, se_category, se_action
+ORDER BY count(*) DESC
+LIMIT 20
+```
+
+#### Query JSON formatted data
+
+```sql
+SELECT
+  derived_tstamp,
+  contexts:data[0]:data:extra:old_format as CURRENT_FORMAT,
+  contexts:data[0]:data:extra:value as UPDATED_FORMAT
+FROM legacy.snowplow_structured_events_all
+WHERE event_action in ('wiki_format_updated')
+ORDER BY derived_tstamp DESC
+LIMIT 100
+```
+
+### Web-specific parameters
+
+Snowplow JavaScript adds [web-specific parameters](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/snowplow-tracker-protocol/#Web-specific_parameters) to all web events by default.
+
+## Related topics
+
+- [Snowplow data structure](https://docs.snowplow.io/docs/understanding-your-pipeline/canonical-event/)
+- [Our Iglu schema registry](https://gitlab.com/gitlab-org/iglu)
+- [List of events used in our codebase (Event Dictionary)](https://metrics.gitlab.com/snowplow/)
+- [Analytics Instrumentation Guide](https://about.gitlab.com/handbook/product/analytics-instrumentation-guide/)
+- [Service Ping Guide](../service_ping/index.md)
+- [Analytics Instrumentation Direction](https://about.gitlab.com/direction/analytics/analytics-instrumentation/)
+- [Data Analysis Process](https://about.gitlab.com/handbook/business-technology/data-team/#data-analysis-process/)
+- [Data for Product Managers](https://about.gitlab.com/handbook/business-technology/data-team/programs/data-for-product-managers/)
+- [Data Infrastructure](https://about.gitlab.com/handbook/business-technology/data-team/platform/infrastructure/)
diff --git a/doc/development/internal_analytics/snowplow/infrastructure.md b/doc/development/internal_analytics/snowplow/infrastructure.md
new file mode 100644
index 00000000000..9679abac6b7
--- /dev/null
+++ b/doc/development/internal_analytics/snowplow/infrastructure.md
@@ -0,0 +1,101 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Snowplow infrastructure
+
+Snowplow events on GitLab SaaS fired by a [tracker](implementation.md) go through an AWS pipeline, managed by GitLab.
+
+## Event flow in the AWS pipeline
+
+Every event goes through a collector, enricher, and pseudonymization lambda. The event is then dumped to S3 storage where it can be picked up by the Snowflake data warehouse.
+
+Deploying and managing the infrastructure is automated using Terraform in the current [Terraform repository](https://gitlab.com/gitlab-com/gl-infra/config-mgmt/-/tree/master/environments/aws-snowplow).
+
+```mermaid
+graph LR
+    GL[GitLab.com]-->COL
+
+    subgraph aws-cloud[AWS]
+    COL[Collector]-->|snowplow-raw-good|ENR
+    COL[Collector]-->|snowplow-raw-bad|FRBE
+        subgraph firehoserbe[Firehose]
+        FRBE[AWS Lambda]
+      end
+    FRBE-->S3RBE
+
+    ENR[Enricher]-->|snowplow-enriched-bad|FEBE
+      subgraph firehoseebe[Firehose]
+        FEBE[AWS Lambda]
+      end
+    FEBE-->S3EBE
+
+    ENR[Enricher]-->|snowplow-enriched-good|FRGE
+      subgraph firehosege[Firehose]
+        FRGE[AWS Lambda]
+      end
+    FRGE-->S3GE
+  end
+
+    subgraph snowflake[Data warehouse]
+    S3RBE[S3 raw-bad]-->BE[gitlab_bad_events]
+    S3EBE[S3 enriched-bad]-->BE[gitlab_bad_events]
+    S3GE[S3 output]-->GE[gitlab_events]
+  end
+```
+
+See [Snowplow technology 101](https://github.com/snowplow/snowplow/#snowplow-technology-101) for Snowplow's own documentation and an overview how collectors and enrichers work.
+
+### Pseudonymization
+
+In contrast to a typical Snowplow pipeline, after enrichment, GitLab Snowplow events go through a [pseudonymization service](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/snowplow-pseudonymization) in the form of an AWS Lambda service before they are stored in S3 storage.
+
+#### Why events need to be pseudonymized
+
+GitLab is bound by its [obligations to community](https://about.gitlab.com/handbook/product/analytics-instrumentation-guide/service-usage-data-commitment/)
+and by [legal regulations](https://about.gitlab.com/handbook/legal/privacy/services-usage-data/) to protect the privacy of its users.
+
+GitLab must provide valuable insights for business decisions, and there is a need
+for a better understanding of different users' behavior patterns. The
+pseudonymization process helps you find a compromise between these two requirements.
+
+Pseudonymization processes personally identifiable information inside a Snowplow event in an irreversible fashion
+maintaining deterministic output for given input, while masking any relation to that input.
+
+#### How events are pseudonymized
+
+Pseudonymization uses an allowlist that provides privacy by default. Therefore, each
+attribute received as part of a Snowplow event is pseudonymized unless the attribute
+is an allowed exception.
+
+Pseudonymization is done using the HMAC-SHA256 keyed hash algorithm.
+Attributes are combined with a secret salt to replace each identifiable information with a pseudonym.
+
+### S3 bucket data lake to Snowflake
+
+See [Data team's Snowplow Overview](https://about.gitlab.com/handbook/business-technology/data-team/platform/snowplow/) for further details how data is ingested into our Snowflake data warehouse.
+
+## Monitoring
+
+There are several tools that monitor Snowplow events tracking in different stages of the processing pipeline:
+
+- [Analytics Instrumentation Grafana dashboard](https://dashboards.gitlab.net/d/product-intelligence-main/product-intelligence-product-intelligence?orgId=1) monitors backend events sent from a GitLab.com instance to a collectors fleet. This dashboard provides information about:
+  - The number of events that successfully reach Snowplow collectors.
+  - The number of events that failed to reach Snowplow collectors.
+  - The number of backend events that were sent.
+- [AWS CloudWatch dashboard](https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#dashboards:name=SnowPlow;start=P3D) monitors the state of the events in a processing pipeline. The pipeline starts from Snowplow collectors, goes through to enrichers and pseudonymization, and then up to persistence in an S3 bucket. From S3, the events are imported into the Snowflake Data Warehouse. You must have AWS access rights to view this dashboard. For more information, see [monitoring](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/snowplow-pseudonymization#monitoring) in the Snowplow Events pseudonymization service documentation.
+- [Sisense dashboard](https://app.periscopedata.com/app/gitlab/417669/Snowplow-Summary-Dashboard) provides information about the number of good and bad events imported into the Data Warehouse, in addition to the total number of imported Snowplow events.
+
+For more information, see this [video walk-through](https://www.youtube.com/watch?v=NxPS0aKa_oU).
+
+## Related topics
+
+- [Snowplow technology 101](https://github.com/snowplow/snowplow/#snowplow-technology-101)
+- [Snowplow pseudonymization AWS Lambda project](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/snowplow-pseudonymization)
+- [Analytics Instrumentation Guide](https://about.gitlab.com/handbook/product/analytics-instrumentation-guide/)
+- [Data Infrastructure](https://about.gitlab.com/handbook/business-technology/data-team/platform/infrastructure/)
+- [Snowplow architecture overview (internal)](https://www.youtube.com/watch?v=eVYJjzspsLU)
+- [Snowplow architecture overview slide deck (internal)](https://docs.google.com/presentation/d/16gQEO5CAg8Tx4NBtfnZj-GF4juFI6HfEPWcZgH4Rn14/edit?usp=sharing)
+- [AWS Lambda implementation (internal)](https://youtu.be/cQd0mdMhkQA)
diff --git a/doc/development/internal_analytics/snowplow/review_guidelines.md b/doc/development/internal_analytics/snowplow/review_guidelines.md
new file mode 100644
index 00000000000..03d1812cbfc
--- /dev/null
+++ b/doc/development/internal_analytics/snowplow/review_guidelines.md
@@ -0,0 +1,44 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Snowplow review guidelines
+
+This page includes introductory material for an
+[Analytics Instrumentation](https://about.gitlab.com/handbook/engineering/development/analytics/analytics-instrumentation/)
+review, and is specific to Snowplow related reviews. For broader advice and
+general best practices for code reviews, refer to our [code review guide](../../code_review.md).
+
+## Resources for reviewers
+
+- [Snowplow Guide](index.md)
+- [Event Dictionary](https://metrics.gitlab.com/snowplow/)
+
+## Review process
+
+We recommend an Analytics Instrumentation review when a merge request (MR) involves changes in
+events or touches Snowplow related files.
+
+### Roles and process
+
+#### The merge request **author** should
+
+- For frontend events, when relevant, add a screenshot of the event in
+  the [testing tool](implementation.md#develop-and-test-snowplow) used.
+- For backend events, when relevant, add the output of the
+  [Snowplow Micro](implementation.md#test-backend-events-with-snowplow-micro) good events
+  `GET http://localhost:9090/micro/good` (it might be a good idea
+  to reset with `GET http://localhost:9090/micro/reset` first).
+- Add or update the event definition file according to the [Event Dictionary Guide](event_dictionary_guide.md).
+
+#### The Analytics Instrumentation **reviewer** should
+
+- Check that the [event schema](index.md#event-schema) is correct.
+- Check the [usage recommendations](implementation.md#usage-recommendations).
+- Check that an event definition file was created or updated in accordance with the [Event Dictionary Guide](event_dictionary_guide.md).
+- If needed, check that the events are firing locally using one of the
+[testing tools](implementation.md#develop-and-test-snowplow) available.
+- Approve the MR, and relabel the MR with `~"analytics instrumentation::approved"`.
+- If the snowplow event mirrors a RedisHLL event, then tag @mdrussell to review if the payload is usable for this purpose.
diff --git a/doc/development/internal_analytics/snowplow/schemas.md b/doc/development/internal_analytics/snowplow/schemas.md
new file mode 100644
index 00000000000..21142f68d39
--- /dev/null
+++ b/doc/development/internal_analytics/snowplow/schemas.md
@@ -0,0 +1,190 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Snowplow schemas
+
+This page provides Snowplow schema reference for GitLab events.
+
+## `gitlab_standard`
+
+We are including the [`gitlab_standard` schema](https://gitlab.com/gitlab-org/iglu/-/blob/master/public/schemas/com.gitlab/gitlab_standard/jsonschema/) for structured events and page views.
+
+The [`StandardContext`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/tracking/standard_context.rb)
+class represents this schema in the application. Some properties are
+[automatically populated for frontend events](implementation.md#snowplow-javascript-frontend-tracking),
+and can be [provided manually for backend events](implementation.md#implement-ruby-backend-tracking).
+
+| Field Name              |      Required       | Default value                | Type                      | Description                                                                                                             |
+|-------------------------|:-------------------:|------------------------------|---------------------------|-------------------------------------------------------------------------------------------------------------------------|
+| `project_id`            | **{dotted-circle}** | Current project ID *         | integer                   |                                                                                                                         |
+| `namespace_id`          | **{dotted-circle}** | Current group/namespace ID * | integer                   |                                                                                                                         |
+| `user_id`               | **{dotted-circle}** | Current user ID *            | integer                   | User database record ID attribute. This value undergoes a pseudonymization process at the collector level.              |
+| `context_generated_at`  | **{dotted-circle}** | Current timestamp            | string (date time format) | Timestamp indicating when context was generated.                                                                        |
+| `environment`           | **{check-circle}**  | Current environment          | string (max 32 chars)     | Name of the source environment, such as `production` or `staging`                                                       |
+| `source`                | **{check-circle}**  | Event source                 | string (max 32 chars)     | Name of the source application, such as  `gitlab-rails` or `gitlab-javascript`                                          |
+| `plan`                  | **{dotted-circle}** | Current namespace plan *     | string (max 32 chars)     | Name of the plan for the namespace, such as `free`, `premium`, or `ultimate`. Automatically picked from the `namespace`. |
+| `google_analytics_id`   | **{dotted-circle}** | GA ID value *                | string (max 32 chars)     | Google Analytics ID, present when set from our marketing sites.                                                         |
+| `is_gitlab_team_member` | **{dotted-circle}** |                              | boolean                   | Indicates if the events is triggered by a GitLab team member |
+| `extra`                 | **{dotted-circle}** |                              | JSON                      | Any additional data associated with the event, in the form of key-value pairs                                           |
+
+_\* Default value present for frontend events only_
+
+## Default Schema
+
+Frontend events include a [web-specific schema](https://docs.snowplow.io/docs/understanding-your-pipeline/canonical-event/#web-specific-fields) provided by Snowplow.
+All URLs are pseudonymized. The entity identifier [replaces](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracker-setup/other-parameters-2/#setting-a-custom-page-url-and-referrer-url) personally identifiable
+information (PII). PII includes usernames, group, and project names.
+Page titles are hardcoded as `GitLab` for the same reason.
+
+| Field Name               | Required            | Type      | Description                                                                                                                      |
+|--------------------------|---------------------|-----------|----------------------------------------------------------------------------------------------------------------------------------|
+| `app_id`                   | **{check-circle}**  | string    | Unique identifier for website / application                                                                                      |
+| `base_currency`            | **{dotted-circle}** | string    | Reporting currency                                                                                                               |
+| `br_colordepth`            | **{dotted-circle}** | integer   | Browser color depth                                                                                                              |
+| `br_cookies`               | **{dotted-circle}** | boolean   | Does the browser permit cookies?                                                                                                 |
+| `br_family`                | **{dotted-circle}** | string    | Browser family                                                                                                                   |
+| `br_features_director`     | **{dotted-circle}** | boolean   | Director plugin installed?                                                                                                       |
+| `br_features_flash`        | **{dotted-circle}** | boolean   | Flash plugin installed?                                                                                                          |
+| `br_features_gears`        | **{dotted-circle}** | boolean   | Google gears installed?                                                                                                          |
+| `br_features_java`         | **{dotted-circle}** | boolean   | Java plugin installed?                                                                                                           |
+| `br_features_pdf`          | **{dotted-circle}** | boolean   | Adobe PDF plugin installed?                                                                                                      |
+| `br_features_quicktime`    | **{dotted-circle}** | boolean   | Quicktime plugin installed?                                                                                                      |
+| `br_features_realplayer`   | **{dotted-circle}** | boolean   | RealPlayer plugin installed?                                                                                                     |
+| `br_features_silverlight`  | **{dotted-circle}** | boolean   | Silverlight plugin installed?                                                                                                    |
+| `br_features_windowsmedia` | **{dotted-circle}** | boolean   | Windows media plugin installed?                                                                                                  |
+| `br_lang`                  | **{dotted-circle}** | string    | Language the browser is set to                                                                                                   |
+| `br_name`                  | **{dotted-circle}** | string    | Browser name                                                                                                                     |
+| `br_renderengine`          | **{dotted-circle}** | string    | Browser rendering engine                                                                                                         |
+| `br_type`                  | **{dotted-circle}** | string    | Browser type                                                                                                                     |
+| `br_version`               | **{dotted-circle}** | string    | Browser version                                                                                                                  |
+| `br_viewheight`            | **{dotted-circle}** | string    | Browser viewport height                                                                                                          |
+| `br_viewwidth`             | **{dotted-circle}** | string    | Browser viewport width                                                                                                           |
+| `collector_tstamp`         | **{dotted-circle}** | timestamp | Time stamp for the event recorded by the collector                                                                               |
+| `contexts`                 | **{dotted-circle}** |           |                                                                                                                                  |
+| `derived_contexts`         | **{dotted-circle}** |           | Contexts derived in the Enrich process                                                                                           |
+| `derived_tstamp`           | **{dotted-circle}** | timestamp | Timestamp making allowance for inaccurate device clock                                                                          |
+| `doc_charset`              | **{dotted-circle}** | string    | Web page's character encoding                                                                                                    |
+| `doc_height`               | **{dotted-circle}** | string    | Web page height                                                                                                                  |
+| `doc_width`                | **{dotted-circle}** | string    | Web page width                                                                                                                   |
+| `domain_sessionid`         | **{dotted-circle}** | string    | Unique identifier (UUID) for this visit of this `user_id` to this domain                                                         |
+| `domain_sessionidx`        | **{dotted-circle}** | integer   | Index of number of visits that this `user_id` has made to this domain (The first visit is `1`)                                   |
+| `domain_userid`            | **{dotted-circle}** | string    | Unique identifier for a user, based on a first party cookie (so domain specific)                                                 |
+| `dvce_created_tstamp`      | **{dotted-circle}** | timestamp | Timestamp when event occurred, as recorded by client device                                                                      |
+| `dvce_ismobile`            | **{dotted-circle}** | boolean   | Indicates whether device is mobile                                                                                               |
+| `dvce_screenheight`        | **{dotted-circle}** | string    | Screen / monitor resolution                                                                                                      |
+| `dvce_screenwidth`         | **{dotted-circle}** | string    | Screen / monitor resolution                                                                                                      |
+| `dvce_sent_tstamp`         | **{dotted-circle}** | timestamp | Timestamp when event was sent by client device to collector                                                                      |
+| `dvce_type`                | **{dotted-circle}** | string    | Type of device                                                                                                                   |
+| `etl_tags`                 | **{dotted-circle}** | string    | JSON of tags for this ETL run                                                                                                    |
+| `etl_tstamp`               | **{dotted-circle}** | timestamp | Timestamp event began ETL                                                                                                        |
+| `event`                    | **{dotted-circle}** | string    | Event type                                                                                                                       |
+| `event_fingerprint`        | **{dotted-circle}** | string    | Hash client-set event fields                                                                                                     |
+| `event_format`             | **{dotted-circle}** | string    | Format for event                                                                                                                 |
+| `event_id`                 | **{dotted-circle}** | string    | Event UUID                                                                                                                       |
+| `event_name`               | **{dotted-circle}** | string    | Event name                                                                                                                       |
+| `event_vendor`             | **{dotted-circle}** | string    | The company who developed the event model                                                                                        |
+| `event_version`            | **{dotted-circle}** | string    | Version of event schema                                                                                                          |
+| `geo_city`                 | **{dotted-circle}** | string    | City of IP origin                                                                                                                |
+| `geo_country`              | **{dotted-circle}** | string    | Country of IP origin                                                                                                             |
+| `geo_latitude`             | **{dotted-circle}** | string    | An approximate latitude                                                                                                          |
+| `geo_longitude`            | **{dotted-circle}** | string    | An approximate longitude                                                                                                         |
+| `geo_region`               | **{dotted-circle}** | string    | Region of IP origin                                                                                                              |
+| `geo_region_name`          | **{dotted-circle}** | string    | Region of IP origin                                                                                                              |
+| `geo_timezone`             | **{dotted-circle}** | string    | Time zone of IP origin                                                                                                            |
+| `geo_zipcode`              | **{dotted-circle}** | string    | Zip (postal) code of IP origin                                                                                                   |
+| `ip_domain`                | **{dotted-circle}** | string    | Second level domain name associated with the visitor's IP address                                                                |
+| `ip_isp`                   | **{dotted-circle}** | string    | Visitor's ISP                                                                                                                    |
+| `ip_netspeed`              | **{dotted-circle}** | string    | Visitor's connection type                                                                                                        |
+| `ip_organization`          | **{dotted-circle}** | string    | Organization associated with the visitor's IP address – defaults to ISP name if none is found                                    |
+| `mkt_campaign`             | **{dotted-circle}** | string    | The campaign ID                                                                                                                  |
+| `mkt_clickid`              | **{dotted-circle}** | string    | The click ID                                                                                                                     |
+| `mkt_content`              | **{dotted-circle}** | string    | The content or ID of the ad.                                                                   |
+| `mkt_medium`               | **{dotted-circle}** | string    | Type of traffic source                                                                                                           |
+| `mkt_network`              | **{dotted-circle}** | string    | The ad network to which the click ID belongs                                                                                     |
+| `mkt_source`               | **{dotted-circle}** | string    | The company / website where the traffic came from                                                                                |
+| `mkt_term`                 | **{dotted-circle}** | string    | Keywords associated with the referrer                                                                                        |
+| `name_tracker`             | **{dotted-circle}** | string    | The tracker namespace                                                                                                            |
+| `network_userid`           | **{dotted-circle}** | string    | Unique identifier for a user, based on a cookie from the collector (so set at a network level and shouldn't be set by a tracker) |
+| `os_family`                | **{dotted-circle}** | string    | Operating system family                                                                                                          |
+| `os_manufacturer`          | **{dotted-circle}** | string    | Manufacturers of operating system                                                                                                |
+| `os_name`                  | **{dotted-circle}** | string    | Name of operating system                                                                                                         |
+| `os_timezone`              | **{dotted-circle}** | string    | Client operating system time zone                                                                                                 |
+| `page_referrer`            | **{dotted-circle}** | string    | Referrer URL                                                                                                                     |
+| `page_title`               | **{dotted-circle}** | string    | To not expose personal identifying information, the page title is hardcoded as `GitLab`                                          |
+| `page_url`                 | **{dotted-circle}** | string    | Page URL                                                                                                                         |
+| `page_urlfragment`         | **{dotted-circle}** | string    | Fragment aka anchor                                                                                                              |
+| `page_urlhost`             | **{dotted-circle}** | string    | Host aka domain                                                                                                                  |
+| `page_urlpath`             | **{dotted-circle}** | string    | Path to page                                                                                                                     |
+| `page_urlport`             | **{dotted-circle}** | integer   | Port if specified, 80 if not                                                                                                     |
+| `page_urlquery`            | **{dotted-circle}** | string    | Query string                                                                                                                      |
+| `page_urlscheme`           | **{dotted-circle}** | string    | Scheme (protocol name)                                                                                                              |
+| `platform`                 | **{dotted-circle}** | string    | The platform the app runs on                                                                                                     |
+| `pp_xoffset_max`           | **{dotted-circle}** | integer   | Maximum page x offset seen in the last ping period                                                                               |
+| `pp_xoffset_min`           | **{dotted-circle}** | integer   | Minimum page x offset seen in the last ping period                                                                               |
+| `pp_yoffset_max`           | **{dotted-circle}** | integer   | Maximum page y offset seen in the last ping period                                                                               |
+| `pp_yoffset_min`           | **{dotted-circle}** | integer   | Minimum page y offset seen in the last ping period                                                                               |
+| `refr_domain_userid`       | **{dotted-circle}** | string    | The Snowplow `domain_userid` of the referring website                                                                              |
+| `refr_dvce_tstamp`         | **{dotted-circle}** | timestamp | The time of attaching the `domain_userid` to the inbound link                                                                      |
+| `refr_medium`              | **{dotted-circle}** | string    | Type of referer                                                                                                                  |
+| `refr_source`              | **{dotted-circle}** | string    | Name of referer if recognised                                                                                                    |
+| `refr_term`                | **{dotted-circle}** | string    | Keywords if source is a search engine                                                                                            |
+| `refr_urlfragment`         | **{dotted-circle}** | string    | Referer URL fragment                                                                                                             |
+| `refr_urlhost`             | **{dotted-circle}** | string    | Referer host                                                                                                                     |
+| `refr_urlpath`             | **{dotted-circle}** | string    | Referer page path                                                                                                                |
+| `refr_urlport`             | **{dotted-circle}** | integer   | Referer port                                                                                                                     |
+| `refr_urlquery`            | **{dotted-circle}** | string    | Referer URL query string                                                                                                          |
+| `refr_urlscheme`           | **{dotted-circle}** | string    | Referer scheme                                                                                                                   |
+| `se_action`                | **{dotted-circle}** | string    | The action / event itself                                                                                                        |
+| `se_category`              | **{dotted-circle}** | string    | The category of event                                                                                                            |
+| `se_label`                 | **{dotted-circle}** | string    | A label often used to refer to the 'object' the action is performed on                                                           |
+| `se_property`              | **{dotted-circle}** | string    | A property associated with either the action or the object                                                                       |
+| `se_value`                 | **{dotted-circle}** | decimal   | A value associated with the user action                                                                                          |
+| `ti_category`              | **{dotted-circle}** | string    | Item category                                                                                                                    |
+| `ti_currency`              | **{dotted-circle}** | string    | Currency                                                                                                                         |
+| `ti_name`                  | **{dotted-circle}** | string    | Item name                                                                                                                        |
+| `ti_orderid`               | **{dotted-circle}** | string    | Order ID                                                                                                                         |
+| `ti_price`                 | **{dotted-circle}** | decimal   | Item price                                                                                                                       |
+| `ti_price_base`            | **{dotted-circle}** | decimal   | Item price in base currency                                                                                                      |
+| `ti_quantity`              | **{dotted-circle}** | integer   | Item quantity                                                                                                                    |
+| `ti_sku`                   | **{dotted-circle}** | string    | Item SKU                                                                                                                         |
+| `tr_affiliation`           | **{dotted-circle}** | string    | Transaction affiliation (such as channel)                                                                                           |
+| `tr_city`                  | **{dotted-circle}** | string    | Delivery address: city                                                                                                           |
+| `tr_country`               | **{dotted-circle}** | string    | Delivery address: country                                                                                                        |
+| `tr_currency`              | **{dotted-circle}** | string    | Transaction Currency                                                                                                             |
+| `tr_orderid`               | **{dotted-circle}** | string    | Order ID                                                                                                                         |
+| `tr_shipping`              | **{dotted-circle}** | decimal   | Delivery cost charged                                                                                                            |
+| `tr_shipping_base`         | **{dotted-circle}** | decimal   | Shipping cost in base currency                                                                                                   |
+| `tr_state`                 | **{dotted-circle}** | string    | Delivery address: state                                                                                                          |
+| `tr_tax`                   | **{dotted-circle}** | decimal   | Transaction tax value (such as amount of VAT included)                                                                              |
+| `tr_tax_base`              | **{dotted-circle}** | decimal   | Tax applied in base currency                                                                                                     |
+| `tr_total`                 | **{dotted-circle}** | decimal   | Transaction total value                                                                                                          |
+| `tr_total_base`            | **{dotted-circle}** | decimal   | Total amount of transaction in base currency                                                                                     |
+| `true_tstamp`              | **{dotted-circle}** | timestamp | User-set exact timestamp                                                                                                         |
+| `txn_id`                   | **{dotted-circle}** | string    | Transaction ID                                                                                                                   |
+| `unstruct_event`           | **{dotted-circle}** | JSON      | The properties of the event                                                                                                      |
+| `uploaded_at`              | **{dotted-circle}** |           |                                                                                                                                  |
+| `user_fingerprint`         | **{dotted-circle}** | integer   | User identifier based on (hopefully unique) browser features                                                                     |
+| `user_id`                  | **{dotted-circle}** | string    | Unique identifier for user, set by the business using setUserId                                                                  |
+| `user_ipaddress`           | **{dotted-circle}** | string    | IP address                                                                                                                       |
+| `useragent`                | **{dotted-circle}** | string    | User agent (expressed as a browser string)                                                                                                |
+| `v_collector`              | **{dotted-circle}** | string    | Collector version                                                                                                                |
+| `v_etl`                    | **{dotted-circle}** | string    | ETL version                                                                                                                      |
+| `v_tracker`                | **{dotted-circle}** | string    | Identifier for Snowplow tracker                                                                                                  |
+
+## `gitlab_service_ping`
+
+Backend events converted from ServicePing (`redis` and `redis_hll`) must include [ServicePing context](https://gitlab.com/gitlab-org/iglu/-/tree/master/public/schemas/com.gitlab/gitlab_service_ping/jsonschema)
+using the [helper class](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/tracking/service_ping_context.rb).
+
+An example of converted `redis_hll` [event with context](https://gitlab.com/gitlab-org/gitlab/-/edit/master/app/controllers/concerns/product_analytics_tracking.rb#L58).
+
+| Field Name    |      Required       | Type                   | Description                                                                                                                                                        |
+|---------------|:-------------------:|------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `data_source` | **{check-circle}**  | string (max 64 chars)  | The `data_source` attribute from the metrics YAML definition. |
+| `event_name`* | **{dotted-circle}** | string (max 128 chars) | When there is a many-to-many relationship between events and metrics, this field contains the name of a Redis event that can be used for aggregations in downstream systems |
+| `key_path`*   | **{dotted-circle}** | string (max 256 chars) | The `key_path` attribute from the metrics YAML definition |
+
+_\* Either `event_name` or `key_path` is required_
diff --git a/doc/development/internal_analytics/snowplow/troubleshooting.md b/doc/development/internal_analytics/snowplow/troubleshooting.md
new file mode 100644
index 00000000000..885f4e0c16f
--- /dev/null
+++ b/doc/development/internal_analytics/snowplow/troubleshooting.md
@@ -0,0 +1,80 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Troubleshooting Snowplow
+
+## Monitoring
+
+This page covers dashboards and alerts coming from a number of internal tools.
+
+For a brief video overview of the tools used to monitor Snowplow usage, please check out [this internal video](https://www.youtube.com/watch?v=NxPS0aKa_oU) (you must be logged into GitLab Unfiltered to view).
+
+## Good events drop
+
+### Symptoms
+
+You will be alarmed via a [Sisense alert](https://app.periscopedata.com/app/gitlab/alert/Volume-of-Snowplow-Good-events/5a5f80ef34fe450da5ebb84eaa84067f/edit) that is sent to `#g_product_intelligence` Slack channel
+
+### Locating the problem
+
+First you need to identify at which stage in Snowplow the data pipeline the drop is occurring.
+Start at [Snowplow dashboard](https://console.aws.amazon.com/systems-manager/resource-groups/cloudwatch?dashboard=SnowPlow&region=us-east-1#) on CloudWatch,
+if you do not have access to CloudWatch you need to create an [access request issue](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/9730) first.
+While on CloudWatch dashboard set time range to last 4 weeks, to get better picture of system characteristics over time. Than visit following charts:
+
+1. `ELB New Flow Count` and `Collector Auto Scaling Group Network In/Out` - they show in order: number of connections to collectors via load balancers and data volume (in bytes) processed by collectors. If there is drop visible there, it means less events were fired from the GitLab application. Proceed to [application layer guide](#troubleshooting-gitlab-application-layer) for more details
+1. `Firehose Records to S3` - it shows how many event records were saved to S3 bucket, if there was drop on this chart but not on the charts from 1. it means that problem is located at AWS infrastructure layer, please refer to [AWS layer guide](#troubleshooting-aws-layer)
+1. If drop wasn't visible on any of previous charts it means that problem is at data warehouse layer, please refer to [data warehouse layer guide](#troubleshooting-data-warehouse-layer)
+
+### Troubleshooting GitLab application layer
+
+Drop occurring at application layer can be symptom of some issue, but it might be also a result of normal application lifecycle, intended changes done to analytics instrumentation or experiments tracking
+or even a result of a public holiday in some regions of the world with a larger user-base. To verify if there is an underlying problem to solve, you can check following things:
+
+1. Check `about.gitlab.com` website traffic on [Google Analytics](https://analytics.google.com/analytics/web/) to verify if some public holiday might impact overall use of GitLab system
+   1. You may require to open an access request for Google Analytics access first, for example: [access request internal issue](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/1772)
+1. Plot `select date(dvce_created_tstamp) , event , count(*) from legacy.snowplow_unnested_events_90 where dvce_created_tstamp > '2021-06-15' and dvce_created_tstamp < '2021-07-10' group by 1 , 2 order by 1 , 2` in SiSense to see what type of events was responsible for drop
+1. Plot `select date(dvce_created_tstamp) ,se_category , count(*) from legacy.snowplow_unnested_events_90 where dvce_created_tstamp > '2021-06-15' and dvce_created_tstamp < '2021-07-31' and event = 'struct' group by  1 , 2 order by  1, 2` what events recorded the biggest drops in suspected category
+1. Check if there was any MR merged that might cause reduction in reported events, pay an attention to ~"analytics instrumentation" and ~"growth experiment" labeled MRs
+1. Check (via [Grafana explore tab](https://dashboards.gitlab.net/explore) ) following Prometheus counters `gitlab_snowplow_events_total`, `gitlab_snowplow_failed_events_total` and `gitlab_snowplow_successful_events_total` to see how many events were fired correctly from GitLab.com. Example query to use `sum(rate(gitlab_snowplow_successful_events_total{env="gprd"}[5m])) / sum(rate(gitlab_snowplow_events_total{env="gprd"}[5m]))` would chart rate at which number of good events rose in comparison to events sent in total. If number drops from 1 it means that problem might be in communication between GitLab and AWS collectors fleet.
+1. Check [logs in Kibana](https://log.gprd.gitlab.net/app/discover#) and filter with `{ "query": { "match_phrase": { "json.message": "failed to be reported to collector at" } } }` if there are some failed events logged
+
+For results about an investigation conducted into an unexpected drop in snowplow events volume, see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/335206).
+
+### Troubleshooting AWS layer
+
+Already conducted investigations:
+
+- [Steep decrease of Snowplow page views](https://gitlab.com/gitlab-org/gitlab/-/issues/268009)
+- [`snowplow.trx.gitlab.net` unreachable](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/5073)
+
+### Troubleshooting data warehouse layer
+
+Reach out to [Data team](https://about.gitlab.com/handbook/business-technology/data-team/) to ask about current state of data warehouse. On their handbook page there is a [section with contact details](https://about.gitlab.com/handbook/business-technology/data-team/#how-to-connect-with-us)
+
+## Delay in Snowplow Enrichers
+
+If there is an alert for **Snowplow Raw Good Stream Backing Up**, we receive an email notification. This sometimes happens because Snowplow Enrichers don't scale well enough for the amount of Snowplow events.
+
+If the delay goes over 48 hours, we lose data.
+
+### Contact SRE on-call
+
+Send a message in the [#infrastructure_lounge](https://gitlab.slack.com/archives/CB3LSMEJV) Slack channel using the following template:
+
+```markdown
+Hello team!
+
+We received an alert for [Snowplow Raw Good Stream Backing Up](https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#alarmsV2:alarm/SnowPlow+Raw+Good+Stream+Backing+Up?).
+
+Enrichers are not scalling well for the amount of events we receive.
+
+See the [dashboard](https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#dashboards:name=SnowPlow).
+
+Could we get assistance to fix the delay?
+
+Thank you!
+```
diff --git a/doc/development/internal_api/index.md b/doc/development/internal_api/index.md
index c1c0177609b..5fceb9013da 100644
--- a/doc/development/internal_api/index.md
+++ b/doc/development/internal_api/index.md
@@ -14,7 +14,7 @@ working on the GitLab codebase.
 This documentation does not yet include the internal API used by
 GitLab Pages.
 
-## Adding new endpoints
+## Add new endpoints
 
 API endpoints should be externally accessible by default, with proper authentication and authorization.
 Before adding a new internal endpoint, consider if the API would potentially be
@@ -492,13 +492,14 @@ curl --request GET --header "Gitlab-Kas-Api-Request: <JWT token>" \
 Called from GitLab agent server (`kas`) to increase the usage
 metric counters.
 
-| Attribute                                                                  | Type          | Required | Description                                                                                                      |
-|:---------------------------------------------------------------------------|:--------------|:---------|:-----------------------------------------------------------------------------------------------------------------|
-| `counters`                                                                 | hash          | no | The number to increase the `k8s_api_proxy_request` counter by                                                    |
-| `counters["k8s_api_proxy_request"]`                                        | integer       | no | The number to increase the `k8s_api_proxy_request` counter by                                                    |
-| `counters["gitops_sync"]`                                                  | integer       | no | The number to increase the `gitops_sync` counter by                                                              |
-| `unique_counters`                                                          | hash          | no | The number to increase the `k8s_api_proxy_request` counter by                                                    |
-| `unique_counters["agent_users_using_ci_tunnel"]`                              | integer array | no | The set of unique user ids that have interacted a CI Tunnel to track the `agent_users_using_ci_tunnel` metric event |
+| Attribute                                        | Type          | Required | Description                                                                                                          |
+|:-------------------------------------------------|:--------------|:---------|:---------------------------------------------------------------------------------------------------------------------|
+| `counters`                                       | hash          | no       | Hash of counters                                                                                                     |
+| `counters["k8s_api_proxy_request"]`              | integer       | no       | The number to increase the `k8s_api_proxy_request` counter by                                                        |
+| `counters["gitops_sync"]`                        | integer       | no       | The number to increase the `gitops_sync` counter by                                                                  |
+| `counters["flux_git_push_notifications_total"]`  | integer       | no       | The number to increase the `flux_git_push_notifications_total` counter by                                            |
+| `unique_counters`                                | hash          | no       | Array of unique numbers                                                                                              |
+| `unique_counters["agent_users_using_ci_tunnel"]` | integer array | no       | The set of unique user ids that have interacted a CI Tunnel to track the `agent_users_using_ci_tunnel` metric event  |
 
 ```plaintext
 POST /internal/kubernetes/usage_metrics
@@ -663,9 +664,9 @@ Example response:
 
 The subscriptions endpoint is used by [CustomersDot](https://gitlab.com/gitlab-org/customers-gitlab-com) (`customers.gitlab.com`) to apply subscriptions including trials, and add-on purchases, for personal namespaces or top-level groups within GitLab.com.
 
-### Creating a subscription
+### Create a subscription
 
-Use a POST to create a subscription.
+Use a POST command to create a subscription.
 
 ```plaintext
 POST /namespaces/:id/gitlab_subscription
@@ -714,7 +715,7 @@ Example response:
 }
 ```
 
-### Updating a subscription
+### Update a subscription
 
 Use a PUT command to update an existing subscription.
 
@@ -765,7 +766,7 @@ Example response:
 }
 ```
 
-### Retrieving a subscription
+### Retrieve a subscription
 
 Use a GET command to view an existing subscription.
 
@@ -809,6 +810,107 @@ Example response:
 
 - CustomersDot
 
+## Subscription add-on purchases (excluding storage and compute packs)
+
+The subscription add-on purchase endpoint is used by [CustomersDot](https://gitlab.com/gitlab-org/customers-gitlab-com) (`customers.gitlab.com`) to apply subscription add-on purchases like code suggestions for personal namespaces, or top-level groups within GitLab.com. It is not used to apply storage and compute pack purchases.
+
+### Create a subscription add-on purchase
+
+Use a POST command to create a subscription add-on purchase.
+
+```plaintext
+POST /namespaces/:id/subscription_add_on_purchase/:add_on_name
+```
+
+| Attribute   | Type    | Required | Description |
+|:------------|:--------|:---------|:------------|
+| `quantity` | integer | yes | Amount of units in the subscription add-on purchase (Example: Number of seats for a code suggestions add-on) |
+| `expires_on` | date | yes | Expiration date of the subscription add-on purchase |
+| `purchase_xid` | string | yes | Identifier for the subscription add-on purchase (Example: Subscription name for a code suggestions add-on) |
+
+Example request:
+
+```shell
+curl --request POST --header "PRIVATE-TOKEN: <admin_access_token>" "https://gitlab.com/api/v4/namespaces/1234/subscription_add_on_purchase/code_suggestions?&quantity=10&expires_on="2024-07-15"&purchase_xid="A-S12345678""
+```
+
+Example response:
+
+```json
+{
+  "namespace_id":1234,
+  "namespace_name":"A Namespace Name",
+  "add_on":"Code Suggestions",
+  "quantity":10,
+  "expires_on":"2024-07-15",
+  "purchase_xid":"A-S12345678"
+}
+```
+
+### Update a subscription add-on purchases
+
+Use a PUT command to update an existing subscription add-on purchase.
+
+```plaintext
+PUT /namespaces/:id/subscription_add_on_purchase/:add_on_name
+```
+
+| Attribute   | Type    | Required | Description |
+|:------------|:--------|:---------|:------------|
+| `quantity` | integer | yes | Amount of units in the subscription add-on purchase (Example: Number of seats for a code suggestions add-on) |
+| `expires_on` | date | yes | Expiration date of the subscription add-on purchase |
+| `purchase_xid` | string | yes | Identifier for the subscription add-on purchase (Example: Subscription name for a code suggestions add-on) |
+
+Example request:
+
+```shell
+curl --request PUT --header "PRIVATE-TOKEN: <admin_access_token>" "https://gitlab.com/api/v4/namespaces/1234/subscription_add_on_purchase/code_suggestions?&quantity=15&expires_on="2024-07-15"&purchase_xid="A-S12345678""
+```
+
+Example response:
+
+```json
+{
+  "namespace_id":1234,
+  "namespace_name":"A Namespace Name",
+  "add_on":"Code Suggestions",
+  "quantity":15,
+  "expires_on":"2024-07-15",
+  "purchase_xid":"A-S12345678"
+}
+```
+
+### Retrieve a subscription add-on purchases
+
+Use a GET command to view an existing subscription add-on purchase.
+
+```plaintext
+GET /namespaces/:id/subscription_add_on_purchase/:add_on_name
+```
+
+Example request:
+
+```shell
+curl --header "PRIVATE-TOKEN: <admin_access_token>" "https://gitlab.com/api/v4/namespaces/1234/subscription_add_on_purchase/code_suggestions"
+```
+
+Example response:
+
+```json
+{
+  "namespace_id":1234,
+  "namespace_name":"A Namespace Name",
+  "add_on":"Code Suggestions",
+  "quantity":15,
+  "expires_on":"2024-07-15",
+  "purchase_xid":"A-S12345678"
+}
+```
+
+### Known consumers
+
+- CustomersDot
+
 ## Storage limit exclusions
 
 The namespace storage limit exclusion endpoints manage storage limit exclusions on top-level namespaces on GitLab.com.
@@ -827,7 +929,7 @@ Example request:
 ```shell
 curl --request GET \
   --url "https://gitlab.com/v4/namespaces/storage/limit_exclusions" \
-  --header 'PRIVATE-TOKEN: <admin access token>' 
+  --header 'PRIVATE-TOKEN: <admin access token>'
 ```
 
 Example response:
@@ -910,14 +1012,16 @@ Example response:
 
 - GitLab.com Admin Area
 
-## CI/CD minutes provisioning
+## Compute quota provisioning
 
-The CI/CD Minutes endpoints are used by [CustomersDot](https://gitlab.com/gitlab-org/customers-gitlab-com) (`customers.gitlab.com`)
-to apply additional packs of CI/CD minutes, for personal namespaces or top-level groups within GitLab.com.
+> [Renamed](https://gitlab.com/groups/gitlab-com/-/epics/2150) from "CI/CD minutes" to "compute quota" and "units of compute" in GitLab 16.1.
 
-### Creating an additional pack
+The compute quota endpoints are used by [CustomersDot](https://gitlab.com/gitlab-org/customers-gitlab-com) (`customers.gitlab.com`)
+to apply additional packs of units of compute, for personal namespaces or top-level groups in GitLab.com.
 
-Use a POST to create additional packs.
+### Create an additional pack
+
+Use a POST command to create additional packs.
 
 ```plaintext
 POST /namespaces/:id/minutes
@@ -925,9 +1029,9 @@ POST /namespaces/:id/minutes
 
 | Attribute   | Type    | Required | Description |
 |:------------|:--------|:---------|:------------|
-| `packs`     | array   | yes      | An array of purchased minutes packs |
+| `packs`     | array   | yes      | An array of purchased compute packs |
 | `packs[expires_at]` | date   | yes      | Expiry date of the purchased pack|
-| `packs[number_of_minutes]`  | integer    | yes       | Number of additional minutes |
+| `packs[number_of_minutes]`  | integer    | yes       | Number of additional units of compute |
 | `packs[purchase_xid]` | string  | yes       | The unique ID of the purchase |
 
 Example request:
@@ -961,9 +1065,9 @@ Example response:
 ]
 ```
 
-### Moving additional packs
+### Move additional packs
 
-Use a `PATCH` to move additional packs from one namespace to another.
+Use a `PATCH` command to move additional packs from one namespace to another.
 
 ```plaintext
 PATCH /namespaces/:id/minutes/move/:target_id
@@ -999,7 +1103,7 @@ Example response:
 The `upcoming_reconciliations` endpoint is used by [CustomersDot](https://gitlab.com/gitlab-org/customers-gitlab-com) (`customers.gitlab.com`)
 to update upcoming reconciliations for namespaces.
 
-### Updating `upcoming_reconciliations`
+### Update `upcoming_reconciliations`
 
 Use a PUT command to update `upcoming_reconciliations`.
 
@@ -1033,7 +1137,7 @@ Example response:
 200
 ```
 
-### Deleting an `upcoming_reconciliation`
+### Delete an `upcoming_reconciliation`
 
 Use a DELETE command to delete an `upcoming_reconciliation`.
 
@@ -1254,7 +1358,7 @@ Example request:
 
 ```shell
 curl --verbose --request PATCH "https://gitlab.example.com/api/scim/v2/groups/test_group/Users/f0b1d561c-21ff-4092-beab-8154b17f82f2" \
-     --data '{ "Operations": [{"op":"Add","path":"name.formatted","value":"New Name"}] }' \
+     --data '{ "Operations": [{"op":"Update","path":"name.formatted","value":"New Name"}] }' \
      --header "Authorization: Bearer <your_scim_token>" --header "Content-Type: application/scim+json"
 ```
 
@@ -1451,7 +1555,7 @@ Fields that can be updated are:
 | SCIM/IdP field                   | GitLab field                                                                 |
 |:---------------------------------|:-----------------------------------------------------------------------------|
 | `id/externalId`                  | `extern_uid`                                                                 |
-| `active`                         | Identity removal if `active` = `false`                                       |
+| `active`                         | If `false`, the user is blocked, but the SCIM identity remains linked.       |
 
 ```plaintext
 PATCH /api/scim/v2/application/Users/:id
@@ -1468,7 +1572,7 @@ Example request:
 
 ```shell
 curl --verbose --request PATCH "https://gitlab.example.com/api/scim/v2/application/Users/f0b1d561c-21ff-4092-beab-8154b17f82f2" \
-     --data '{ "Operations": [{"op":"Add","path":"name.formatted","value":"New Name"}] }' \
+     --data '{ "Operations": [{"op":"Update","path":"active","value":"false"}] }' \
      --header "Authorization: Bearer <your_scim_token>" --header "Content-Type: application/scim+json"
 ```
 
diff --git a/doc/development/jh_features_review.md b/doc/development/jh_features_review.md
index 7b81ecfe8f5..7e90d79c067 100644
--- a/doc/development/jh_features_review.md
+++ b/doc/development/jh_features_review.md
@@ -20,6 +20,10 @@ We have two kinds of changes related to JH:
     codes under `jh/`.
   - We will generalize this so both EE and JH can share the same mechanism,
     then we wouldn't have to treat them differently.
+  - Database migrations and database schema changes which are required to
+    support running JH edition. See
+    [JiHu guidelines for database changes](https://about.gitlab.com/handbook/ceo/chief-of-staff-team/jihu-support/jihu-database-change-process.html)
+    for details.
 
 If needed, review the corresponding JH merge request located at [JH repository](https://jihulab.com/gitlab-cn/gitlab).
 
@@ -33,9 +37,12 @@ the reference from being misidentified as a missing partial and subsequently del
 
 ## Process overview
 
-See the [merge request process](https://about.gitlab.com/handbook/ceo/chief-of-staff-team/jihu-support/#merge-request-process)
-on the JiHu Support handbook.
-This page is the single source of truth for JiHu-related processes.
+Read the following process guides:
+
+- [Contribution review process](https://about.gitlab.com/handbook/ceo/chief-of-staff-team/jihu-support/jihu-contribution-review-process.html)
+- [Database change process](https://about.gitlab.com/handbook/ceo/chief-of-staff-team/jihu-support/jihu-database-change-process.html)
+- [Security review process](https://about.gitlab.com/handbook/ceo/chief-of-staff-team/jihu-support/jihu-security-review-process.html)
+- [Merge request process](https://about.gitlab.com/handbook/ceo/chief-of-staff-team/jihu-support/#merge-request-process)
 
 ## Act as EE when `jh/` does not exist or when `EE_ONLY=1`
 
diff --git a/doc/development/labels/index.md b/doc/development/labels/index.md
index 50b6ec74575..dfd2a9e4fd3 100644
--- a/doc/development/labels/index.md
+++ b/doc/development/labels/index.md
@@ -194,6 +194,8 @@ The current department labels are:
 
 - `~"UX"`
 - `~"Quality"`
+- `~"infrastructure"`
+- `~"security"`
 
 ## Team labels
 
@@ -206,8 +208,10 @@ people.
 
 The current team labels are:
 
-- `~"Delivery"~`
+- `~"Delivery"`
 - `~"Technical Writing"`
+- `~"Engineering Productivity"`
+- `~"Contributor Success"`
 
 ### Naming and color convention
 
diff --git a/doc/development/licensing.md b/doc/development/licensing.md
index cb703e98264..02b6af6ee49 100644
--- a/doc/development/licensing.md
+++ b/doc/development/licensing.md
@@ -48,6 +48,27 @@ For all of the above, please include `--why "Reason"` and `--who "My Name"` so t
 
 More detailed information on how the gem and its commands work is available in the [License Finder README](https://github.com/pivotal/LicenseFinder).
 
+## Getting an unknown or Lead licensed software approved
+
+We sometimes need to use third-party softwares whose license is not part of the Blue Oak Council
+license list, or is marked as Lead-rated in the list. In this case, the use-case needs to be
+legal-approved before the software can be installed. More on this can be [found in the Handbook](https://about.gitlab.com/handbook/legal/product/#using-open-source-software).
+
+To get legal approval, follow these steps:
+
+1. Create a new [legal issue](https://gitlab.com/gitlab-com/legal-and-compliance/-/issues/new?issuable_template=general-legal-template). Make sure to include as many details as possible:
+   - What license is the software using?
+   - How and where will it be used?
+   - Is it being vendored or forked, or will we be using the upstream project?
+   - Any relevant links.
+1. After the usage has been legal-approved, allowlist the software in the GitLab project.
+   See [License Finder commands](#license-finder-commands) above.
+1. Make sure the software is also recognized by Omnibus. Create a new MR against the [`omnibus-gitlab`](https://gitlab.com/gitlab-org/omnibus-gitlab)
+   project. Refer to [this MR](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/6870)
+   for an example of what the changes should look like. You'll need to edit the following files:
+   - `lib/gitlab/license/analyzer.rb`
+   - `support/dependency_decisions.yml`
+
 ## Encryption keys
 
 If your license was created in your local development or staging environment for Customers Portal or License App, an environment variable called `GITLAB_LICENSE_MODE` with the value `test` needs to be set to use the correct decryption key.
diff --git a/doc/development/merge_request_concepts/diffs/development.md b/doc/development/merge_request_concepts/diffs/development.md
index 1c22eff34db..37d87d4e4eb 100644
--- a/doc/development/merge_request_concepts/diffs/development.md
+++ b/doc/development/merge_request_concepts/diffs/development.md
@@ -72,6 +72,14 @@ contents, individual commits, and the files containing changes.
 Diff content is usually accessed through this class. Logic is often applied
 to diff, file, and commit content before it is returned to a user.
 
+#### `MergeRequestDiff#commits_count`
+
+When `MergeRequestDiff` is saved, associated `MergeRequestDiffCommit` records are
+counted and cached into the `commits_count` column. This number displays on the
+merge request page as the counter for the **Commits** tab.
+
+If `MergeRequestDiffCommit` records are deleted, the counter doesn't update.
+
 ### `MergeRequestDiffCommit`
 
 `MergeRequestDiffCommit` is defined in `app/models/merge_request_diff_commit.rb`.
@@ -119,6 +127,23 @@ relationship to the change, such as:
 - Its ordering in the diff.
 - The raw diff output itself.
 
+#### External diff storage
+
+By default, diff data of a `MergeRequestDiffFile` is stored in `diff` column in
+the `merge_request_diff_files` table. On some installations, the table can grow
+too large, so they're configured to store diffs on external storage to save space.
+To configure it, see [Merge request diffs storage](../../../administration/merge_request_diffs.md).
+
+When configured to use external storage:
+
+- The `diff` column in the database is left `NULL`.
+- The associated `MergeRequestDiff` record sets the `stored_externally` attribute
+  to `true` on creation of `MergeRequestDiff`.
+
+A cron job named `ScheduleMigrateExternalDiffsWorker` is also scheduled at
+minute 15 of every hour. This migrates `diff` that are still stored in the
+database to external storage.
+
 ### `MergeRequestDiffDetail`
 
 `MergeRequestDiffDetail` is defined in `app/models/merge_request_diff_detail.rb`.
diff --git a/doc/development/merge_request_concepts/rate_limits.md b/doc/development/merge_request_concepts/rate_limits.md
index 97d20b57eb4..62c50e3d044 100644
--- a/doc/development/merge_request_concepts/rate_limits.md
+++ b/doc/development/merge_request_concepts/rate_limits.md
@@ -14,7 +14,7 @@ Every new feature should have safe usage limits included in its implementation.
 Limits are applicable for:
 
 - System-level resource pools such as API requests, SSHD connections, database connections, storage, and so on.
-- Domain-level objects such as CI/CD minutes, groups, sign-in attempts, and so on.
+- Domain-level objects such as compute quota, groups, sign-in attempts, and so on.
 
 ## When limits are required
 
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 513659d0f68..33f51c20446 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -973,6 +973,8 @@ Under the hood, it works like this:
 
 ```ruby
 class SwapPrimaryKey < Gitlab::Database::Migration[2.1]
+  disable_ddl_transaction!
+
   TABLE_NAME = :table_name
   PRIMARY_KEY = :table_name_pkey
   OLD_INDEX_NAME = :old_index_name
diff --git a/doc/development/navigation_sidebar.md b/doc/development/navigation_sidebar.md
index cd543012ddd..f7ab75b62f4 100644
--- a/doc/development/navigation_sidebar.md
+++ b/doc/development/navigation_sidebar.md
@@ -15,10 +15,7 @@ the sidebar is a work in progress, and so is this documentation.
 
 ## Enable the new navigation sidebar
 
-To enable the new navigation sidebar:
-
-- Enable the `super_sidebar_nav` feature flag.
-- Select your avatar, then turn on the **New navigation** toggle.
+To enable the new navigation sidebar, select your avatar, then turn on the **New navigation** toggle.
 
 ## Adding items to the sidebar
 
diff --git a/doc/development/packages/debian_repository.md b/doc/development/packages/debian_repository.md
index 1523d777e7b..b3e9bedfdd4 100644
--- a/doc/development/packages/debian_repository.md
+++ b/doc/development/packages/debian_repository.md
@@ -102,18 +102,33 @@ Next, if the file is a `.changes` format:
       1. A [Release file](https://wiki.debian.org/DebianRepository/Format#A.22Release.22_files) is written, signed by the GPG key, and then stored.
    1. Old component files are destroyed.
 
-This diagram shows the path taken after a file is uploaded to the Debian API:
+The three following diagrams show the path taken after a file is uploaded to the Debian API:
 
 ```mermaid
 sequenceDiagram
+    autonumber
+    actor Client
     Client->>+DebianProjectPackages: PUT projects/:id/packages/debian/:file_name
+    Note over DebianProjectPackages: If `.changes` file or distribution param present
+    DebianProjectPackages->>+CreateTemporaryPackageService: Create temporary package
+    Note over DebianProjectPackages: Else
     DebianProjectPackages->>+FindOrCreateIncomingService: Create "incoming" package
+    Note over DebianProjectPackages: Finally
     DebianProjectPackages->>+CreatePackageFileService: Create "unknown" file
-    Note over DebianProjectPackages: If `.changes` file
-    DebianProjectPackages->>+ProcessChangesWorker: Schedule worker to process the file
+    Note over CreatePackageFileService: If `.changes` file or distribution param present
+    CreatePackageFileService->>+ProcessPackageFileWorker: Schedule worker to process the file
     DebianProjectPackages->>+Client: 202 Created
-    ProcessChangesWorker->>+ProcessChangesService: Start service
-    ProcessChangesService->>+ExtractChangesMetadataService: Extract changesmetadata
+
+    ProcessPackageFileWorker->>+ProcessPackageFileService: Start service
+```
+
+`ProcessPackageFileWorker` background job:
+
+```mermaid
+sequenceDiagram
+    autonumber
+    ProcessPackageFileWorker->>+ProcessPackageFileService: Start service
+    ProcessPackageFileService->>+ExtractChangesMetadataService: Extract changes metadata
     ExtractChangesMetadataService->>+ExtractMetadataService: Extract file metadata
     ExtractMetadataService->>+ParseDebian822Service: run `dpkg --field` to get control file
     ExtractMetadataService->>+ExtractDebMetadataService: If .deb, .udeb or ddeb
@@ -123,9 +138,9 @@ sequenceDiagram
     ExtractMetadataService->>+ParseDebian822Service: if .dsc, .changes, or buildinfo
     ParseDebian822Service-->>-ExtractMetadataService:  Parse String as Debian RFC822 control data format
     ExtractMetadataService-->>-ExtractChangesMetadataService: Parse Metadata file
-    ExtractChangesMetadataService-->>-ProcessChangesService: Return list of files and hashes from the .changes file
+    ExtractChangesMetadataService-->>-ProcessPackageFileService: Return list of files and hashes from the .changes file
     loop process files listed in .changes
-        ProcessChangesService->>+ExtractMetadataService: Process file
+        ProcessPackageFileService->>+ExtractMetadataService: Process file
         ExtractMetadataService->>+ParseDebian822Service: run `dpkg --field` to get control file
         ExtractMetadataService->>+ExtractDebMetadataService: If .deb, .udeb or ddeb
         ExtractDebMetadataService->>+ParseDebian822Service: run `dpkg --field` to get control file
@@ -133,9 +148,18 @@ sequenceDiagram
         ExtractDebMetadataService-->>-ExtractMetadataService: Return the parsed control file
         ExtractMetadataService->>+ParseDebian822Service: if .dsc, .changes, or buildinfo
         ParseDebian822Service-->>-ExtractMetadataService:  Parse String as Debian RFC822 control data format
-        ExtractMetadataService-->>-ProcessChangesService: Use parsed metadata to update "unknown" (or known) file
+        ExtractMetadataService-->>-ProcessPackageFileService: Use parsed metadata to update "unknown" (or known) file
     end
-    ProcessChangesService->>+GenerateDistributionWorker: Find distribution and start service
+    ProcessPackageFileService->>+GenerateDistributionWorker: Find distribution and start service
+
+    GenerateDistributionWorker->>+GenerateDistributionService: Generate distribution
+```
+
+`GenerateDistributionWorker` background job:
+
+```mermaid
+sequenceDiagram
+    autonumber
     GenerateDistributionWorker->>+GenerateDistributionService: Generate distribution
     GenerateDistributionService->>+GenerateDistributionService: generate component files based on new archs and updates from .changes
     GenerateDistributionService->>+GenerateDistributionKeyService: generate GPG key for distribution
@@ -143,7 +167,7 @@ sequenceDiagram
     GenerateDistributionService-->>-GenerateDistributionService: Generate distribution file
     GenerateDistributionService->>+SignDistributionService: Sign release file with GPG key
     SignDistributionService-->>-GenerateDistributionService: Save the signed release file
-    GenerateDistributionWorker->>+GenerateDistributionService: destroy no longer used component files
+    GenerateDistributionService->>+GenerateDistributionService: destroy no longer used component files
 ```
 
 ### Distributions
diff --git a/doc/development/pages/dnsmasq.md b/doc/development/pages/dnsmasq.md
new file mode 100644
index 00000000000..a14e215ccd7
--- /dev/null
+++ b/doc/development/pages/dnsmasq.md
@@ -0,0 +1,65 @@
+---
+type: reference, dev
+stage: Plan
+group: Knowledge
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+description: "dnsmasq configuration guidelines for GitLab Pages"
+---
+
+# Using `dnsmasq` to dynamically handle GitLab Pages subdomains
+
+You can use [`dnsmasq`](https://wiki.debian.org/dnsmasq) to test
+GitLab Pages sites locally without having to configure each site on `/etc/hosts`.
+
+## Use `dnsmasq` on macOS
+
+To use `dnsmasq` on macOS:
+
+1. Install `dnsmasq`:
+
+```console
+brew install dnsmasq
+```
+
+1. Set up the `*.test` domain lookup:
+
+```console
+# Ensure the configuration directory exists
+mkdir -p $(brew --prefix)/etc/
+
+# Add `*.test` to the `127.0.0.1` lookup
+echo 'address=/.test/127.0.0.1' >> $(brew --prefix)/etc/dnsmasq.conf
+
+# Start `dnsmasq`
+sudo brew services start dnsmasq
+```
+
+1. Create a DNS resolver:
+
+```console
+# Ensure the resolver directory exists
+sudo mkdir -p /etc/resolver
+
+# Add the localhost address as a resolver for `.test` domains
+echo "nameserver 127.0.0.1" | sudo tee /etc/resolver/test
+```
+
+You can now create a GitLab Pages site locally with a dynamic domain.
+If you [configure GitLab Pages](index.md#configuring-gitlab-pages-with-gdk) and
+create a `root/html` project, that project is accessible through `http://root.gdk.pages.test:3010/html`.
+
+## Troubleshooting
+
+For GitLab Runner, you must define `gdk.test` in `/etc/hosts`.
+If you're using GitLab Runner locally, you must also configure `/etc/hosts`:
+
+```console
+# Append GDK configuration in `/etc/hosts`
+cat <<-EOF | sudo tee -a /etc/hosts
+
+## GDK
+127.0.0.1  gdk.test
+::1        gdk.test
+# ----------------------------
+EOF
+```
diff --git a/doc/development/pages/index.md b/doc/development/pages/index.md
index 4769dbf427d..25c1ea7a864 100644
--- a/doc/development/pages/index.md
+++ b/doc/development/pages/index.md
@@ -37,7 +37,7 @@ for GitLab Pages, and then one entry for each page site:
 If instead of editing your `/etc/hosts` you'd prefer to use a DNS wildcard, you can use:
 
 - [`nip.io`](https://nip.io)
-- [`dnsmasq`](https://wiki.debian.org/dnsmasq)
+- [`dnsmasq`](dnsmasq.md)
 
 ## Configuring GitLab Pages without GDK
 
diff --git a/doc/development/permissions.md b/doc/development/permissions.md
index 3abadc98501..aa58447b818 100644
--- a/doc/development/permissions.md
+++ b/doc/development/permissions.md
@@ -7,315 +7,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Permission development guidelines
 
 There are multiple types of permissions across GitLab, and when implementing
-anything that deals with permissions, all of them should be considered.
+anything that deals with permissions, all of them should be considered. For more information, see:
 
-## Instance
-
-### User types
-
-Each user can be one of the following types:
-
-- Regular.
-- External - access to groups and projects only if direct member.
-- [Internal users](internal_users.md) - system created.
-- [Auditor](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/policies/ee/base_policy.rb#L9):
-  - No access to projects or groups settings menu.
-  - No access to Admin Area.
-  - Read-only access to everything else.
-- [Administrator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/policies/base_policy.rb#L6) - read-write access.
-
-See the [permissions page](../user/permissions.md) for details on how each user type is used.
-
-## Groups and Projects
-
-### General permissions
-
-Groups and projects can have the following visibility levels:
-
-- public (`20`) - an entity is visible to everyone
-- internal (`10`) - an entity is visible to authenticated users
-- private (`0`) - an entity is visible only to the approved members of the entity
-
-By default, subgroups can **not** have higher visibility levels.
-For example, if you create a new private group, it cannot include a public subgroup.
-
-The visibility level of a group can be changed only if all subgroups and
-sub-projects have the same or lower visibility level. For example, a group can be set
-to internal only if all subgroups and projects are internal or private.
-
-WARNING:
-If you migrate an existing group to a lower visibility level, that action does not migrate subgroups
-in the same way. This is a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/22406).
-
-Visibility levels can be found in the `Gitlab::VisibilityLevel` module.
-
-### Feature specific permissions
-
-Additionally, the following project features can have different visibility levels:
-
-- Issues
-- Repository
-  - Merge request
-  - Forks
-  - Pipelines
-- Analytics
-- Requirements
-- Security and Compliance
-- Wiki
-- Snippets
-- Pages
-- Operations
-- Metrics Dashboard
-
-These features can be set to "Everyone with Access" or "Only Project Members".
-They make sense only for public or internal projects because private projects
-can be accessed only by project members by default.
-
-### Members
-
-Users can be members of multiple groups and projects. The following access
-levels are available (defined in the
-[`Gitlab::Access`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/access.rb)
-module):
-
-- No access (`0`)
-- [Minimal access](../user/permissions.md#users-with-minimal-access) (`5`)
-- Guest (`10`)
-- Reporter (`20`)
-- Developer (`30`)
-- Maintainer (`40`)
-- Owner (`50`)
-
-If a user is the member of both a project and the project parent groups, the
-highest permission is the applied access level for the project.
-
-If a user is the member of a project, but not the parent groups, they
-can still view the groups and their entities (like epics).
-
-Project membership (where the group membership is already taken into account)
-is stored in the `project_authorizations` table.
-
-NOTE:
-In [GitLab 14.9](https://gitlab.com/gitlab-org/gitlab/-/issues/351211) and later, projects in personal namespaces have a maximum role of Owner.
-Because of a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/219299) in GitLab 14.8 and earlier, projects in personal namespaces have a maximum role of Maintainer.
-
-### Confidential issues
-
-[Confidential issues](../user/project/issues/confidential_issues.md) can be accessed
-only by project members who are at least
-reporters (they can't be accessed by guests). Additionally they can be accessed
-by their authors and assignees.
-
-### Licensed features
-
-Some features can be accessed only if the user has the correct license plan.
-
-## Permission dependencies
-
-Feature policies can be quite complex and consist of multiple rules.
-Quite often, one permission can be based on another.
-
-Designing good permissions means reusing existing permissions as much as possible
-and making access to features granular.
-
-In the case of a complex resource, it should be broken into smaller pieces of information
-and each piece should be granted a different permission.
-
-A good example in this case is the _Merge Request widget_ and the _Security reports_.
-Depending on the visibility level of the _Pipelines_, the _Security reports_ are either visible
-in the widget or not. So, the _Merge Request widget_, the _Pipelines_, and the _Security reports_,
-have separate permissions. Moreover, the permissions for the _Merge Request widget_
-and the _Pipelines_ are dependencies of the _Security reports_.
-
-### Permission dependencies of Secure features
-
-Secure features have complex permissions since these features are integrated
-into different features like Merge Requests and CI flow.
-
- Here is a list of some permission dependencies.
-
-| Activity level | Resource | Locations |Permission dependency|
-|----------------|----------|-----------|-----|
-| View | License information | Dependency list, License Compliance | Can view repository |
-| View | Dependency information | Dependency list, License Compliance | Can view repository |
-| View | Vulnerabilities information | Dependency list | Can view security findings |
-| View | Black/Whitelisted licenses for the project | License Compliance, merge request  | Can view repository |
-| View | Security findings | merge request, CI job page, Pipeline security tab | Can read the project and CI jobs |
-| View | Vulnerability feedback | merge request | Can read security findings |
-| View | Dependency List page | Project | Can access Dependency information |
-| View | License Compliance page | Project | Can access License information|
-
-## Where should permissions be checked?
-
-We should typically apply defense-in-depth (implementing multiple checks at
-various layers) starting with low-level layers, such as finders and services,
-followed by high-level layers, such as GraphQL, public REST API, and controllers.
-
-See [Guidelines for reusing abstractions](reusing_abstractions.md).
-
-Protecting the same resources at many points means that if one layer of defense is compromised
-or missing, customer data is still protected by the additional layers.
-
-See the permissions section in the [Secure Coding Guidelines](secure_coding_guidelines.md#permissions).
-
-### Considerations
-
-Services or finders are appropriate locations because:
-
-- Multiple endpoints share services or finders so downstream logic is more likely to be re-used.
-- Sometimes authorization logic must be incorporated in DB queries to filter records.
-- Permission checks at the display layer should be avoided except to provide better UX
-  and not as a security check. For example, showing and hiding non-data elements like buttons.
-
-The downsides to defense-in-depth are:
-
-- `DeclarativePolicy` rules are relatively performant, but conditions may perform database calls.
-- Higher maintenance costs.
-
-### Exceptions
-
-Developers can choose to do authorization in only a single area after weighing
-the risks and drawbacks for their specific case.
-
-Prefer domain logic (services or finders) as the source of truth when making exceptions.
-
-Logic, like backend worker logic, might not need authorization based on the current user.
-If the service or finder's constructor does not expect `current_user`, then it typically won't
-check permissions.
-
-### Tips
-
-If a class accepts `current_user`, then it may be responsible for authorization.
-
-### Example: Adding a new API endpoint
-
-By default, we authorize at the endpoint. Checking an existing ability may make sense; if not, then we probably need to add one.
-
-As an aside, most endpoints can be cleanly categorized as a CRUD (create, read, update, destroy) action on a resource. The services and abilities follow suit, which is why many are named like `Projects::CreateService` or `:read_project`.
-
-Say, for example, we extract the whole endpoint into a service. The `can?` check will now be in the service. Say the service reuses an existing finder, which we are modifying for our purposes. Should we make the finder check an ability?
-
-- If the finder doesn't accept `current_user`, and therefore doesn't check permissions, then probably no.
-- If the finder accepts `current_user`, and doesn't check permissions, then it would be a good idea to double check other usages of the finder, and we might consider adding authorization.
-- If the finder accepts `current_user`, and already checks permissions, then either we need to add our case, or the existing checks are appropriate.
-
-### Refactoring permissions
-
-#### Finding existing permissions checks
-
-As mentioned [above](#where-should-permissions-be-checked), permissions are
-often checked in multiple locations for a single endpoint or web request. As a
-result, finding the list of authorization checks that are run for a given endpoint
-can be challenging.
-
-To assist with this, you can locally set `GITLAB_DEBUG_POLICIES=true`.
-
-This outputs information about which abilities are checked in the requests
-made in any specs that you run. The output also includes the line of code where the
-authorization check was made. Caller information is especially helpful in cases
-where there is metaprogramming used because those cases are difficult to find by
-grepping for ability name strings.
-
-Example:
-
-```shell
-# example spec run
-
-GITLAB_DEBUG_POLICIES=true bundle exec rspec spec/controllers/groups_controller_spec.rb:162
-
-# permissions debug output when spec is run; if multiple policy checks are run they will all be in the debug output.
-
-POLICY CHECK DEBUG -> policy: GlobalPolicy, ability: create_group, called_from: ["/gitlab/app/controllers/application_controller.rb:245:in `can?'", "/gitlab/app/controllers/groups_controller.rb:255:in `authorize_create_group!'"]
-```
-
-This flag is meant to help learn more about authorization checks while
-refactoring and should not remain enabled for any specs on the default branch.
-
-#### Understanding logic for individual abilities
-
-References to an ability may appear in a `DeclarativePolicy` class many times
-and depend on conditions and rules which reference other abilities. As a result,
-it can be challenging to know exactly which conditions apply to a particular
-ability.
-
-`DeclarativePolicy` provides a `ability_map` for each Policy class, which
-pulls all Rules for an ability into an array.
-
-Example:
-
-```ruby
-> GroupPolicy.ability_map.map.select { |k,v| k == :read_group_member }
-=> {:read_group_member=>[[:enable, #<Rule can?(:read_group)>], [:prevent, #<Rule ~can_read_group_member>]]}
-
-> GroupPolicy.ability_map.map.select { |k,v| k == :read_group }
-=> {:read_group=>
-  [[:enable, #<Rule public_group>],
-   [:enable, #<Rule logged_in_viewable>],
-   [:enable, #<Rule guest>],
-   [:enable, #<Rule admin>],
-   [:enable, #<Rule has_projects>],
-   [:enable, #<Rule read_package_registry_deploy_token>],
-   [:enable, #<Rule write_package_registry_deploy_token>],
-   [:prevent, #<Rule all?(~public_group, ~admin, user_banned_from_group)>],
-   [:enable, #<Rule auditor>],
-   [:prevent, #<Rule needs_new_sso_session>],
-   [:prevent, #<Rule all?(ip_enforcement_prevents_access, ~owner, ~auditor)>]]}
-```
-
-`DeclarativePolicy` also provides a `debug` method that can be used to
-understand the logic tree for a specific object and actor. The output is similar
-to the list of rules from `ability_map`. But, `DeclarativePolicy` stops
-evaluating rules once one `prevent`s an ability, so it is possible that
-not all conditions are called.
-
-Example:
-
-```ruby
-policy = GroupPolicy.new(User.last,  Group.last)
-policy.debug(:read_group)
-
-- [0] enable when public_group ((@custom_guest_user1 : Group/139))
-- [0] enable when logged_in_viewable ((@custom_guest_user1 : Group/139))
-- [0] enable when admin ((@custom_guest_user1 : Group/139))
-- [0] enable when auditor ((@custom_guest_user1 : Group/139))
-- [14] prevent when all?(~public_group, ~admin, user_banned_from_group) ((@custom_guest_user1 : Group/139))
-- [14] prevent when needs_new_sso_session ((@custom_guest_user1 : Group/139))
-- [16] enable when guest ((@custom_guest_user1 : Group/139))
-- [16] enable when has_projects ((@custom_guest_user1 : Group/139))
-- [16] enable when read_package_registry_deploy_token ((@custom_guest_user1 : Group/139))
-- [16] enable when write_package_registry_deploy_token ((@custom_guest_user1 : Group/139))
-  [21] prevent when all?(ip_enforcement_prevents_access, ~owner, ~auditor) ((@custom_guest_user1 : Group/139))
-
-=> #<DeclarativePolicy::Runner::State:0x000000015c665050
- @called_conditions=
-  #<Set: {
-   "/dp/condition/GroupPolicy/public_group/Group:139",
-   "/dp/condition/GroupPolicy/logged_in_viewable/User:83,Group:139",
-   "/dp/condition/BasePolicy/admin/User:83",
-   "/dp/condition/BasePolicy/auditor/User:83",
-   "/dp/condition/GroupPolicy/user_banned_from_group/User:83,Group:139",
-   "/dp/condition/GroupPolicy/needs_new_sso_session/User:83,Group:139",
-   "/dp/condition/GroupPolicy/guest/User:83,Group:139",
-   "/dp/condition/GroupPolicy/has_projects/User:83,Group:139",
-   "/dp/condition/GroupPolicy/read_package_registry_deploy_token/User:83,Group:139",
-   "/dp/condition/GroupPolicy/write_package_registry_deploy_token/User:83,Group:139"}>,
- @enabled=false,
- @prevented=true>
-```
-
-#### Testing that individual policies are equivalent
-
-You can use the `'equivalent project policy abilities'` shared example to ensure
-that 2 project policy abilities are equivalent for all project visibility levels
-and access levels.
-
-Example:
-
-```ruby
-  context 'when refactoring read_pipeline_schedule and read_pipeline' do
-    let(:old_policy) { :read_pipeline_schedule }
-    let(:new_policy) { :read_pipeline }
-
-    it_behaves_like 'equivalent policies'
-  end
-```
+- [Predefined roles system](permissions/predefined_roles.md): a general overview about predefined roles, user types, feature specific permissions or permissions dependencies.
+- [Authorizations](permissions/authorizations.md): guidance on where to check permissions.
+- [Custom roles](permissions/custom_roles.md): guidance on how to work on custom role, how to introduce a new ability for custom roles, how to refactor permissions.
diff --git a/doc/development/permissions/authorizations.md b/doc/development/permissions/authorizations.md
new file mode 100644
index 00000000000..8d8944562a8
--- /dev/null
+++ b/doc/development/permissions/authorizations.md
@@ -0,0 +1,61 @@
+---
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Authorization
+
+## Where should permissions be checked?
+
+When deciding where to check permissions, apply defense-in-depth by implementing multiple checks at
+different layers. Starting with low-level layers, such as finders and services,
+followed by high-level layers, such as GraphQL, public REST API, and controllers.
+
+For more information, see [guidelines for reusing abstractions](../reusing_abstractions.md).
+
+Protecting the same resources at many points means that if one layer of defense is compromised
+or missing, customer data is still protected by the additional layers.
+
+For more information on permissions, see the permissions section in the [secure coding guidelines](../secure_coding_guidelines.md#permissions).
+
+### Considerations
+
+Services or finders are appropriate locations because:
+
+- Multiple endpoints share services or finders so downstream logic is more likely to be re-used.
+- Sometimes authorization logic must be incorporated in DB queries to filter records.
+- You should avoid permission checks at the display layer except to provide better UX,
+  and not as a security check. For example, showing and hiding non-data elements like buttons.
+
+The downsides to defense-in-depth are:
+
+- `DeclarativePolicy` rules are relatively performant, but conditions may perform database calls.
+- Higher maintenance costs.
+
+### Exceptions
+
+Developers can choose to do authorization in only a single area after weighing
+the risks and drawbacks for their specific case.
+
+Prefer domain logic (services or finders) as the source of truth when making exceptions.
+
+Logic, like backend worker logic, might not need authorization based on the current user.
+If the service or finder's constructor does not expect `current_user`, then it typically does not
+check permissions.
+
+### Tips
+
+If a class accepts `current_user`, then it may be responsible for authorization.
+
+### Example: Adding a new API endpoint
+
+By default, we authorize at the endpoint. Checking an existing ability may make sense; if not, then we probably need to add one.
+
+As an aside, most endpoints can be cleanly categorized as a CRUD (create, read, update, destroy) action on a resource. The services and abilities follow suit, which is why many are named like `Projects::CreateService` or `:read_project`.
+
+Say, for example, we extract the whole endpoint into a service. The `can?` check will now be in the service. Say the service reuses an existing finder, which we are modifying for our purposes. Should we make the finder check an ability?
+
+- If the finder does not accept `current_user`, and therefore does not check permissions, then probably no.
+- If the finder accepts `current_user`, and does not check permissions, then you should double-check other usages of the finder, and you might consider adding authorization.
+- If the finder accepts `current_user`, and already checks permissions, then either we need to add our case, or the existing checks are appropriate.
diff --git a/doc/development/permissions/custom_roles.md b/doc/development/permissions/custom_roles.md
new file mode 100644
index 00000000000..73a8c920894
--- /dev/null
+++ b/doc/development/permissions/custom_roles.md
@@ -0,0 +1,166 @@
+---
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Custom Roles
+
+Users can create custom roles and define those roles by assigning specific abilities. For example, a user could create an "Engineer" role with `read code` and `admin merge requests` abilities, but without abilities like `admin issues`.
+
+## Technical overview
+
+Individual custom roles are stored in the `member_roles` table (`MemberRole` model) and can be defined only for top-level groups. This table includes individual abilities and a `base_access_level` value. This value defines the minimum access level of:
+
+- Users who can be assigned to the custom role.
+- Every ability.
+
+For example, the `read_vulnerability` ability has a minimum access level of `Reporter`. That means only member role records with `base_access_level = REPORTER` (20) or higher can have the `read_vulnerability` value set to `true`. Also, only users who have at least the Reporter role can be assigned that ability.
+
+For now, custom role abilities are supported only at project level.
+
+## How to implement a new ability for custom roles
+
+Usually 2-3 merge requests should be created for a new ability. The rough guidance is following:
+
+1. Pick a feature you want to add abilities to custom roles.
+1. Refactor & consolidate abilities for the feature (1-2 merge requests depending on the feature complexity)
+1. Implement a new ability (1 merge request)
+
+### Refactoring abilities
+
+#### Finding existing abilities checks
+
+Abilities are often [checked in multiple locations](../permissions/authorizations.md#where-should-permissions-be-checked) for a single endpoint or web request. Therefore, it can be difficult to find the list of authorization checks that are run for a given endpoint.
+
+To assist with this, you can locally set `GITLAB_DEBUG_POLICIES=true`.
+
+This outputs information about which abilities are checked in the requests
+made in any specs that you run. The output also includes the line of code where the
+authorization check was made. Caller information is especially helpful in cases
+where there is metaprogramming used because those cases are difficult to find by
+grepping for ability name strings.
+
+For example:
+
+```shell
+# example spec run
+
+GITLAB_DEBUG_POLICIES=true bundle exec rspec spec/controllers/groups_controller_spec.rb:162
+
+# permissions debug output when spec is run; if multiple policy checks are run they will all be in the debug output.
+
+POLICY CHECK DEBUG -> policy: GlobalPolicy, ability: create_group, called_from: ["/gitlab/app/controllers/application_controller.rb:245:in `can?'", "/gitlab/app/controllers/groups_controller.rb:255:in `authorize_create_group!'"]
+```
+
+Use this setting to learn more about authorization checks while
+refactoring. You should not keep this setting enabled for any specs on the default branch.
+
+#### Understanding logic for individual abilities
+
+References to an ability may appear in a `DeclarativePolicy` class many times
+and depend on conditions and rules which reference other abilities. As a result,
+it can be challenging to know exactly which conditions apply to a particular
+ability.
+
+`DeclarativePolicy` provides a `ability_map` for each policy class, which
+pulls all rules for an ability into an array.
+
+For example:
+
+```ruby
+> GroupPolicy.ability_map.map.select { |k,v| k == :read_group_member }
+=> {:read_group_member=>[[:enable, #<Rule can?(:read_group)>], [:prevent, #<Rule ~can_read_group_member>]]}
+
+> GroupPolicy.ability_map.map.select { |k,v| k == :read_group }
+=> {:read_group=>
+  [[:enable, #<Rule public_group>],
+   [:enable, #<Rule logged_in_viewable>],
+   [:enable, #<Rule guest>],
+   [:enable, #<Rule admin>],
+   [:enable, #<Rule has_projects>],
+   [:enable, #<Rule read_package_registry_deploy_token>],
+   [:enable, #<Rule write_package_registry_deploy_token>],
+   [:prevent, #<Rule all?(~public_group, ~admin, user_banned_from_group)>],
+   [:enable, #<Rule auditor>],
+   [:prevent, #<Rule needs_new_sso_session>],
+   [:prevent, #<Rule all?(ip_enforcement_prevents_access, ~owner, ~auditor)>]]}
+```
+
+`DeclarativePolicy` also provides a `debug` method that can be used to
+understand the logic tree for a specific object and actor. The output is similar
+to the list of rules from `ability_map`. But, `DeclarativePolicy` stops
+evaluating rules after you `prevent` an ability, so it is possible that
+not all conditions are called.
+
+Example:
+
+```ruby
+policy = GroupPolicy.new(User.last,  Group.last)
+policy.debug(:read_group)
+
+- [0] enable when public_group ((@custom_guest_user1 : Group/139))
+- [0] enable when logged_in_viewable ((@custom_guest_user1 : Group/139))
+- [0] enable when admin ((@custom_guest_user1 : Group/139))
+- [0] enable when auditor ((@custom_guest_user1 : Group/139))
+- [14] prevent when all?(~public_group, ~admin, user_banned_from_group) ((@custom_guest_user1 : Group/139))
+- [14] prevent when needs_new_sso_session ((@custom_guest_user1 : Group/139))
+- [16] enable when guest ((@custom_guest_user1 : Group/139))
+- [16] enable when has_projects ((@custom_guest_user1 : Group/139))
+- [16] enable when read_package_registry_deploy_token ((@custom_guest_user1 : Group/139))
+- [16] enable when write_package_registry_deploy_token ((@custom_guest_user1 : Group/139))
+  [21] prevent when all?(ip_enforcement_prevents_access, ~owner, ~auditor) ((@custom_guest_user1 : Group/139))
+
+=> #<DeclarativePolicy::Runner::State:0x000000015c665050
+ @called_conditions=
+  #<Set: {
+   "/dp/condition/GroupPolicy/public_group/Group:139",
+   "/dp/condition/GroupPolicy/logged_in_viewable/User:83,Group:139",
+   "/dp/condition/BasePolicy/admin/User:83",
+   "/dp/condition/BasePolicy/auditor/User:83",
+   "/dp/condition/GroupPolicy/user_banned_from_group/User:83,Group:139",
+   "/dp/condition/GroupPolicy/needs_new_sso_session/User:83,Group:139",
+   "/dp/condition/GroupPolicy/guest/User:83,Group:139",
+   "/dp/condition/GroupPolicy/has_projects/User:83,Group:139",
+   "/dp/condition/GroupPolicy/read_package_registry_deploy_token/User:83,Group:139",
+   "/dp/condition/GroupPolicy/write_package_registry_deploy_token/User:83,Group:139"}>,
+ @enabled=false,
+ @prevented=true>
+```
+
+#### Abilities consolidation
+
+Every feature added to custom roles should have minimal abilities. For most features, having `read_*` and `admin_*` should be enough. You should consolidate all:
+
+- View-related abilities under `read_*`. For example, viewing a list or detail.
+- Object updates under `admin_*`. For example, updating an object, adding assignees or closing it that object. Usually, a role that enables `admin_` has to have also `read_` abilities enabled. This is defined in `requirement` option in the `ALL_CUSTOMIZABLE_PERMISSIONS` hash on `MemberRole` model.
+
+There might be features that require additional abilities but try to minimalize those. You can always ask members of the Authentication and Authorization group for their opinion or help.
+
+This is also where your work should begin. Take all the abilities for the feature you work on, and consolidate those abilities into `read_`, `admin_`, or additional abilities if necessary.
+
+### Implement a new ability
+
+To add a new ability to a custom role:
+
+- Add a new column to `member_roles` table, for example in [this change in merge request 114734](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114734/diffs#diff-content-5c53d6f1c29a272a87eecea3f62d017ab6635275).
+- Add the ability to the  `MemberRole` model, `ALL_CUSTOMIZABLE_PERMISSIONS` hash, for example in [this change in merge request 121534](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121534/diffs#ce5ec769500a53ce2b603467d9984fc2b33ca71d_8_8). There are following possible keys in the `ALL_CUSTOMIZABLE_PERMISSIONS` hash:
+
+  - `description` - description of the ability.
+  - `minimal_level` - minimal level a user has to have in order to be able to be assigned to the ability.
+  - `requirement` - required ability for the ability defined in the hash, in case the requirement is `false`, the ability can not be `true`.
+
+- Add the ability to the respective Policy for example in [this change in merge request 114734](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114734/diffs#diff-content-edcbe28bdecbd848d4d9efdc5b5e9bddd2a7299e).
+- Update the specs.
+
+Examples of merge requests adding new abilities to custom roles:
+
+- [Read code](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106256)
+- [Read vulnerability](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114734)
+- [Admin vulnerability](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121534) - this is the newest MR implementing a new custom role ability. Some changes from the previous MRs are not neccessary anymore (eg. change of the Preloader query or adding a method to `User` model).
+
+You should make sure a new custom roles ability is under a feature flag.
+
+### Consuming seats
+
+If a new user with a role `Guest` is added to a member role that includes enablement of an ability that is **not** in the `CUSTOMIZABLE_PERMISSIONS_EXEMPT_FROM_CONSUMING_SEAT` array, a seat is consumed. We simply want to make sure we are charging Ultimate customers for guest users, who have "elevated" abilities. This only applies to billable users on SaaS (billable users that are counted towards namespace subscription). More details about this topic can be found in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/390269).
diff --git a/doc/development/permissions/predefined_roles.md b/doc/development/permissions/predefined_roles.md
new file mode 100644
index 00000000000..9afc5966e93
--- /dev/null
+++ b/doc/development/permissions/predefined_roles.md
@@ -0,0 +1,143 @@
+---
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Predefined system of user roles
+
+## Instance
+
+### User types
+
+Each user can be one of the following types:
+
+- Regular.
+- External - access to groups and projects only if direct member.
+- [Internal users](../internal_users.md) - system created.
+- [Auditor](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/policies/ee/base_policy.rb#L9):
+  - No access to projects or groups settings menu.
+  - No access to Admin Area.
+  - Read-only access to everything else.
+- [Administrator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/policies/base_policy.rb#L6) - read-write access.
+
+See the [permissions page](../../user/permissions.md) for details on how each user type is used.
+
+## Groups and Projects
+
+### General permissions
+
+Groups and projects can have the following visibility levels:
+
+- public (`20`) - an entity is visible to everyone
+- internal (`10`) - an entity is visible to authenticated users
+- private (`0`) - an entity is visible only to the approved members of the entity
+
+By default, subgroups can **not** have higher visibility levels.
+For example, if you create a new private group, it cannot include a public subgroup.
+
+The visibility level of a group can be changed only if all subgroups and
+sub-projects have the same or lower visibility level. For example, a group can be set
+to internal only if all subgroups and projects are internal or private.
+
+WARNING:
+If you migrate an existing group to a lower visibility level, that action does not migrate subgroups
+in the same way. This is a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/22406).
+
+Visibility levels can be found in the `Gitlab::VisibilityLevel` module.
+
+### Feature specific permissions
+
+Additionally, the following project features can have different visibility levels:
+
+- Issues
+- Repository
+  - Merge request
+  - Forks
+  - Pipelines
+- Analytics
+- Requirements
+- Security and Compliance
+- Wiki
+- Snippets
+- Pages
+- Operations
+- Metrics Dashboard
+
+These features can be set to "Everyone with Access" or "Only Project Members".
+They make sense only for public or internal projects because private projects
+can be accessed only by project members by default.
+
+### Members
+
+Users can be members of multiple groups and projects. The following access
+levels are available (defined in the
+[`Gitlab::Access`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/access.rb)
+module):
+
+- No access (`0`)
+- [Minimal access](../../user/permissions.md#users-with-minimal-access) (`5`)
+- Guest (`10`)
+- Reporter (`20`)
+- Developer (`30`)
+- Maintainer (`40`)
+- Owner (`50`)
+
+If a user is the member of both a project and the project parent groups, the
+highest permission is the applied access level for the project.
+
+If a user is the member of a project, but not the parent groups, they
+can still view the groups and their entities (like epics).
+
+Project membership (where the group membership is already taken into account)
+is stored in the `project_authorizations` table.
+
+NOTE:
+In [GitLab 14.9](https://gitlab.com/gitlab-org/gitlab/-/issues/351211) and later, projects in personal namespaces have a maximum role of Owner.
+Because of a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/219299) in GitLab 14.8 and earlier, projects in personal namespaces have a maximum role of Maintainer.
+
+### Confidential issues
+
+[Confidential issues](../../user/project/issues/confidential_issues.md) can be accessed
+only by project members who are at least
+reporters (they can't be accessed by guests). Additionally they can be accessed
+by their authors and assignees.
+
+### Licensed features
+
+Some features can be accessed only if the user has the correct license plan.
+
+## Permission dependencies
+
+Feature policies can be quite complex and consist of multiple rules.
+Quite often, one permission can be based on another.
+
+Designing good permissions means reusing existing permissions as much as possible
+and making access to features granular.
+
+In the case of a complex resource, it should be broken into smaller pieces of information
+and each piece should be granted a different permission.
+
+A good example in this case is the _Merge Request widget_ and the _Security reports_.
+Depending on the visibility level of the _Pipelines_, the _Security reports_ are either visible
+in the widget or not. So, the _Merge Request widget_, the _Pipelines_, and the _Security reports_,
+have separate permissions. Moreover, the permissions for the _Merge Request widget_
+and the _Pipelines_ are dependencies of the _Security reports_.
+
+### Permission dependencies of Secure features
+
+Secure features have complex permissions since these features are integrated
+into different features like Merge Requests and CI flow.
+
+ Here is a list of some permission dependencies.
+
+| Activity level | Resource | Locations |Permission dependency|
+|----------------|----------|-----------|-----|
+| View | License information | Dependency list, License Compliance | Can view repository |
+| View | Dependency information | Dependency list, License Compliance | Can view repository |
+| View | Vulnerabilities information | Dependency list | Can view security findings |
+| View | Black/Whitelisted licenses for the project | License Compliance, merge request  | Can view repository |
+| View | Security findings | merge request, CI job page, Pipeline security tab | Can read the project and CI jobs |
+| View | Vulnerability feedback | merge request | Can read security findings |
+| View | Dependency List page | Project | Can access Dependency information |
+| View | License Compliance page | Project | Can access License information|
diff --git a/doc/development/pipelines/index.md b/doc/development/pipelines/index.md
index 651fa2d2ce9..cadba17f03e 100644
--- a/doc/development/pipelines/index.md
+++ b/doc/development/pipelines/index.md
@@ -135,7 +135,7 @@ If so, please have a look at [the Engineering Productivity RUNBOOK on predictive
 ### Fork pipelines
 
 We run only the predictive RSpec & Jest jobs for fork pipelines, unless the `pipeline:run-all-rspec`
-label is set on the MR. The goal is to reduce the CI/CD minutes consumed by fork pipelines.
+label is set on the MR. The goal is to reduce the compute quota consumed by fork pipelines.
 
 See the [experiment issue](https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/issues/1170).
 
@@ -186,8 +186,8 @@ This number can be overridden by setting a CI/CD variable named `RSPEC_FAIL_FAST
 
 ## Re-run previously failed tests in merge request pipelines
 
-In order to reduce the feedback time after resolving failed tests for a merge request, the `rspec rspec-pg13-rerun-previous-failed-tests`
-and `rspec rspec-ee-pg13-rerun-previous-failed-tests` jobs run the failed tests from the previous MR pipeline.
+In order to reduce the feedback time after resolving failed tests for a merge request, the `rspec rspec-pg14-rerun-previous-failed-tests`
+and `rspec rspec-ee-pg14-rerun-previous-failed-tests` jobs run the failed tests from the previous MR pipeline.
 
 This was introduced on August 25th 2021, with <https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69053>.
 
@@ -195,7 +195,7 @@ This was introduced on August 25th 2021, with <https://gitlab.com/gitlab-org/git
 
 1. The `detect-previous-failed-tests` job (`prepare` stage) detects the test files associated with failed RSpec
    jobs from the previous MR pipeline.
-1. The `rspec rspec-pg13-rerun-previous-failed-tests` and `rspec rspec-ee-pg13-rerun-previous-failed-tests` jobs
+1. The `rspec rspec-pg14-rerun-previous-failed-tests` and `rspec rspec-ee-pg14-rerun-previous-failed-tests` jobs
    will run the test files gathered by the `detect-previous-failed-tests` job.
 
 ```mermaid
@@ -205,8 +205,8 @@ graph LR
     end
 
     subgraph "test stage";
-        B["rspec rspec-pg13-rerun-previous-failed-tests"];
-        C["rspec rspec-ee-pg13-rerun-previous-failed-tests"];
+        B["rspec rspec-pg14-rerun-previous-failed-tests"];
+        C["rspec rspec-ee-pg14-rerun-previous-failed-tests"];
     end
 
     A --"artifact: list of test files"--> B & C
@@ -442,7 +442,7 @@ This [GitLab JH validation](https://gitlab.com/gitlab-org-sandbox/gitlab-jh-vali
 project variables set.
 
 It's a pull mirror pulling from [GitLab JH mirror](https://gitlab.com/gitlab-org/gitlab-jh-mirrors/gitlab),
-mirroring only protected branches, `master` and `main-jh`, overriding
+mirroring specific branches: `(master|main-jh)`, overriding
 divergent refs, triggering no pipelines when mirror is updated.
 
 The pulling user is [`@gitlab-jh-validation-bot`](https://gitlab.com/gitlab-jh-validation-bot), who is a maintainer in the project, and also a
@@ -481,6 +481,50 @@ for how it works.
     committed. More context can be found at:
     [Setting it to `false` to skip it](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118938#note_1374688877)
 
+##### Why do we have both the mirror project and validation project?
+
+We have separate projects for a several reasons.
+
+- **Security**: Previously, we had the mirror project only. However, to fully
+  mitigate a [security issue](https://gitlab.com/gitlab-org/gitlab/-/issues/369898),
+  we had to make the mirror project private.
+- **Isolation**: We want to run JH code in a completely isolated and standalone project.
+  We should not run it under the `gitlab-org` group, which is where the mirror
+  project is. The validation project is completely isolated.
+- **Cost**: We don't want to connect to JiHuLab.com from each merge request.
+  It is more cost effective to mirror the code from JiHuLab.com to
+  somewhere at GitLab.com, and have our merge requests fetch code from there.
+  This means that the validation project can fetch code from the mirror, rather
+  than from JiHuLab.com. The mirror project will periodically fetch from
+  JiHuLab.com.
+- **Branch separation/security/efficiency**: We want to mirror all branches,
+  so that we can fetch the corresponding JH branch from JiHuLab.com. However,
+  we don't want to overwrite the `as-if-jh-code-sync` branch in the validation project,
+  because we use it to control the validation pipeline and it has access to
+  `AS_IF_JH_TOKEN`. However, we cannot mirror all branches except a single
+  one. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/413032) for details.
+
+  Given this issue, the validation project is set to only mirror `master` and
+  `main-jh`. Technically, we don't even need those branches, but we do want to
+  keep the repository up-to-date with all the default branches so that when
+  we push changes from the merge request, we only need to push changes from
+  the merge request, which can be more efficient.
+
+- Separation of concerns:
+  - Validation project only has the following branches:
+    - `master` and `main-jh` to keep changes up-to-date.
+    - `as-if-jh-code-sync` for dependency synchronization.
+      We should never mirror this.
+    - `as-if-jh/*` branches from the merge requests.
+      We should never mirror these.
+  - All branches from the mirror project are all coming from JiHuLab.com.
+    We never push anything to the mirror project, nor does it run any
+    pipelines. CI/CD is disabled in the mirror project.
+
+We can consider merging the two projects to simplify the
+setup and process, but we need to make sure that all of these reasons
+are no longer concerns.
+
 ### `rspec:undercoverage` job
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74859) in GitLab 14.6.
@@ -581,22 +625,22 @@ This should let us:
 
 ### PostgreSQL versions testing
 
-Our test suite runs against PG13 as GitLab.com runs on PG13 and
-[Omnibus defaults to PG13 for new installs and upgrades](../../administration/package_information/postgresql_versions.md).
+Our test suite runs against PostgreSQL 14 as GitLab.com runs on PostgreSQL 14 and
+[Omnibus defaults to PG14 for new installs and upgrades](../../administration/package_information/postgresql_versions.md).
 
-We do run our test suite against PG13 on nightly scheduled pipelines.
+We do run our test suite against PostgreSQL 14 on nightly scheduled pipelines.
 
-We also run our test suite against PG13 upon specific database library changes in MRs and `main` pipelines (with the `rspec db-library-code pg13` job).
+We also run our test suite against PostgreSQL 12 and PostgreSQL 13 upon specific database library changes in merge requests and `main` pipelines (with the `rspec db-library-code pg12` and `rspec db-library-code pg13` jobs).
 
 #### Current versions testing
 
 | Where?                                                                                         | PostgreSQL version                              | Ruby version          |
 |------------------------------------------------------------------------------------------------|-------------------------------------------------|-----------------------|
-| Merge requests                                                                                 | 13 (default version), 12 for DB library changes | 3.0 (default version) |
-| `master` branch commits                                                                        | 13 (default version), 12 for DB library changes | 3.0 (default version) |
-| `maintenance` scheduled pipelines for the `master` branch (every even-numbered hour)           | 13 (default version), 12 for DB library changes | 3.0 (default version) |
-| `maintenance` scheduled pipelines for the `ruby2` branch (every odd-numbered hour), see below. | 13 (default version), 12 for DB library changes | 2.7                   |
-| `nightly` scheduled pipelines for the `master` branch                                          | 13 (default version), 12, 14 | 3.0 (default version) |
+| Merge requests                                                                                 | 14 (default version), 13 for DB library changes | 3.0 (default version) |
+| `master` branch commits                                                                        | 14 (default version), 13 for DB library changes | 3.0 (default version) |
+| `maintenance` scheduled pipelines for the `master` branch (every even-numbered hour)           | 14 (default version), 13 for DB library changes | 3.0 (default version) |
+| `maintenance` scheduled pipelines for the `ruby2` branch (every odd-numbered hour), see below. | 14 (default version), 13 for DB library changes | 2.7                   |
+| `nightly` scheduled pipelines for the `master` branch                                          | 14 (default version), 12, 13, 15                | 3.0 (default version) |
 
 There are 2 pipeline schedules used for testing Ruby 2.7. One is triggering a
 pipeline in `ruby2-sync` branch, which updates the `ruby2` branch with latest
diff --git a/doc/development/pipelines/internals.md b/doc/development/pipelines/internals.md
index 678297eb3e5..35881db8c6d 100644
--- a/doc/development/pipelines/internals.md
+++ b/doc/development/pipelines/internals.md
@@ -130,16 +130,18 @@ that are scoped to a single [configuration keyword](../../ci/yaml/index.md#job-k
 | `.default-retry` | Allows a job to [retry](../../ci/yaml/index.md#retry) upon `unknown_failure`, `api_failure`, `runner_system_failure`, `job_execution_timeout`, or `stuck_or_timeout_failure`. |
 | `.default-before_script` | Allows a job to use a default `before_script` definition suitable for Ruby/Rails tasks that may need a database running (for example, tests). |
 | `.setup-test-env-cache` | Allows a job to use a default `cache` definition suitable for setting up test environment for subsequent Ruby/Rails tasks. |
-| `.rails-cache` | Allows a job to use a default `cache` definition suitable for Ruby/Rails tasks. |
+| `.ruby-cache` | Allows a job to use a default `cache` definition suitable for Ruby tasks. |
 | `.static-analysis-cache` | Allows a job to use a default `cache` definition suitable for static analysis tasks. |
 | `.coverage-cache` | Allows a job to use a default `cache` definition suitable for coverage tasks. |
 | `.qa-cache` | Allows a job to use a default `cache` definition suitable for QA tasks. |
 | `.yarn-cache` | Allows a job to use a default `cache` definition suitable for frontend jobs that do a `yarn install`. |
 | `.assets-compile-cache` | Allows a job to use a default `cache` definition suitable for frontend jobs that compile assets. |
-| `.use-pg13` | Allows a job to use the `postgres` 13 and `redis` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
+| `.use-pg13` | Allows a job to use the `postgres` 13, `redis`, and `rediscluster` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
 | `.use-pg13-ee` | Same as `.use-pg13` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
-| `.use-pg14` | Allows a job to use the `postgres` 14 and `redis` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
+| `.use-pg14` | Allows a job to use the `postgres` 14, `redis`, and `rediscluster` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
 | `.use-pg14-ee` | Same as `.use-pg14` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
+| `.use-pg15` | Allows a job to use the `postgres` 15, `redis`, and `rediscluster` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
+| `.use-pg15-ee` | Same as `.use-pg15` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
 | `.use-kaniko` | Allows a job to use the `kaniko` tool to build Docker images. |
 | `.as-if-foss` | Simulate the FOSS project by setting the `FOSS_ONLY='1'` CI/CD variable. |
 | `.use-docker-in-docker` | Allows a job to use Docker in Docker. |
diff --git a/doc/development/pipelines/performance.md b/doc/development/pipelines/performance.md
index d0eef0c86bd..2dbed640fbb 100644
--- a/doc/development/pipelines/performance.md
+++ b/doc/development/pipelines/performance.md
@@ -38,7 +38,6 @@ This works well for the following reasons:
    with fixed keys:
    - `.setup-test-env-cache`
    - `.ruby-cache`
-   - `.rails-cache`
    - `.static-analysis-cache`
    - `.rubocop-cache`
    - `.coverage-cache`
@@ -139,12 +138,3 @@ and `compile-production-assets` jobs to:
    This task is responsible for deciding if assets need to be compiled or not.
    It [compares the `HEAD` `SHA256` hexdigest from `$GITLAB_ASSETS_HASH` with the `master` hexdigest from `cached-assets-hash.txt`](https://gitlab.com/gitlab-org/gitlab/-/blob/c023191ef412e868ae957f3341208a41ca678403/lib/tasks/gitlab/assets.rake#L86).
 1. If the hashes are the same, we don't compile anything. If they're different, we compile the assets.
-
-## Pre-clone step
-
-NOTE:
-We no longer use this optimization for `gitlab-org/gitlab` because the [pack-objects cache](../../administration/gitaly/configure_gitaly.md#pack-objects-cache)
-allows Gitaly to serve the full CI/CD fetch traffic now. See [Git fetch caching](#git-fetch-caching).
-
-The pre-clone step works by using the `CI_PRE_CLONE_SCRIPT` variable
-[defined by GitLab.com shared runners](../../ci/runners/saas/linux_saas_runner.md#pre-clone-script-deprecated).
diff --git a/doc/development/product_qualified_lead_guide/index.md b/doc/development/product_qualified_lead_guide/index.md
index fb8ec478840..9f5a1a1110f 100644
--- a/doc/development/product_qualified_lead_guide/index.md
+++ b/doc/development/product_qualified_lead_guide/index.md
@@ -87,7 +87,7 @@ The hand-raise lead form accepts the following parameters via provide or inject.
     },
 ```
 
-The `ctaTracking` parameters follow [the `data-track` attributes](../snowplow/implementation.md#data-track-attributes) for implementing Snowplow tracking. The provided tracking attributes are attached to the button inside the `HandRaiseLeadButton` component, which triggers the hand-raise lead modal when selected.
+The `ctaTracking` parameters follow [the `data-track` attributes](../internal_analytics/snowplow/implementation.md#data-track-attributes) for implementing Snowplow tracking. The provided tracking attributes are attached to the button inside the `HandRaiseLeadButton` component, which triggers the hand-raise lead modal when selected.
 
 ### Monitor the lead location
 
diff --git a/doc/development/rails_endpoints/index.md b/doc/development/rails_endpoints/index.md
new file mode 100644
index 00000000000..c5a166dd4be
--- /dev/null
+++ b/doc/development/rails_endpoints/index.md
@@ -0,0 +1,79 @@
+---
+stage: Create
+group: Source Code
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
+type: reference, api
+---
+
+# Rails Endpoints
+
+Rails Endpoints are used by different GitLab components, they cannot be
+used by other consumers. This documentation is intended for people
+working on the GitLab codebase.
+
+These Rails Endpoints:
+
+- May not have extensive documentation or follow the same conventions as our public or private APIs.
+- May not adhere to standardized rules or guidelines.
+- Are designed to serve specific internal purposes in the codebase.
+- Are subject to change at any time.
+
+## Proof of concept period: Feedback Request
+
+We are currently evaluating a new approach for documenting Rails endpoints. Please [check out the Feedback Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/411605) and feel free to share your thoughts, suggestions, or concerns. We appreciate your participation in helping us improve the documentation!
+
+## SAST Scanners
+
+Static Application Security Testing (SAST) checks your source code for known vulnerabilities. When SAST is enabled
+on a Project these endpoints are available.
+
+### List existing merge request code quality findings sorted by files
+
+Get a list of existing code quality Findings, if any, sorted by files.
+
+```plaintext
+GET /projects/:id/merge_requests/:merge_request_iid/codequality_mr_diff_reports.json
+```
+
+Response:
+
+```json
+{
+  "files": {
+    "index.js": [
+      {
+        "line": 1,
+        "description": "Unexpected 'debugger' statement.",
+        "severity": "major"
+      }
+    ]
+  }
+}
+```
+
+### List new, resolved and existing merge request code quality findings
+
+Get a list of new, resolved, and existing code quality Findings, if any.
+
+```plaintext
+GET /projects/:id/merge_requests/:merge_request_iid/codequality_reports.json
+```
+
+```json
+{
+  "status": "failed",
+  "new_errors": [
+    {
+      "description": "Unexpected 'debugger' statement.",
+      "severity": "major",
+      "file_path": "index.js",
+      "line": 1,
+      "web_url": "https://gitlab.com/jannik_lehmann/code-quality-test/-/blob/ed1c1b3052fe6963beda0e416d5e2ba3378eb715/noise.rb#L12",
+      "engine_name": "eslint"
+    }
+  ],
+  "resolved_errors": [],
+  "existing_errors": [],
+  "summary": { "total": 1, "resolved": 0, "errored": 1 }
+}
+```
diff --git a/doc/development/rails_initializers.md b/doc/development/rails_initializers.md
index 24647429a57..93a7b568974 100644
--- a/doc/development/rails_initializers.md
+++ b/doc/development/rails_initializers.md
@@ -6,6 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Rails initializers
 
+Initializers are executed when the Rails process is started. That means that initializers are also executed during every deploy.
+
 By default, Rails loads Zeitwerk after the initializers in `config/initializers` are loaded.
 Autoloading before Zeitwerk is loaded is now deprecated but because we use a lot of autoloaded
 constants in our initializers, we had to move the loading of Zeitwerk earlier than these
diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md
index 8261330223d..0305cbf25b4 100644
--- a/doc/development/rake_tasks.md
+++ b/doc/development/rake_tasks.md
@@ -310,7 +310,7 @@ One way to generate the initial list is to run the Rake task `rubocop:todo:gener
 bundle exec rake rubocop:todo:generate
 ```
 
-To generate TODO list for specific RuboCop rules, pass them comma-seperated as
+To generate TODO list for specific RuboCop rules, pass them comma-separated as
 argument to the Rake task:
 
 ```shell
diff --git a/doc/development/reusing_abstractions.md b/doc/development/reusing_abstractions.md
index 3bacea859ef..bfb568d2fd2 100644
--- a/doc/development/reusing_abstractions.md
+++ b/doc/development/reusing_abstractions.md
@@ -302,7 +302,7 @@ Some examples:
 - [`DesignManagement::DesignAtVersion`](https://gitlab.com/gitlab-org/gitlab/-/blob/b62ce98cff8e0530210670f9cb0314221181b77f/app/models/design_management/design_at_version.rb)
   is a model that leverages validations to combine designs and versions.
 - [`Ci::Minutes::Usage`](https://gitlab.com/gitlab-org/gitlab/-/blob/ec52f19f7325410177c00fef06379f55ab7cab67/ee/app/models/ci/minutes/usage.rb)
-  is a Value Object that provides [CI/CD minutes usage](../ci/pipelines/cicd_minutes.md)
+  is a Value Object that provides [compute usage](../ci/pipelines/cicd_minutes.md)
   for a given namespace.
 
 #### Model class methods
diff --git a/doc/development/search/advanced_search_migration_styleguide.md b/doc/development/search/advanced_search_migration_styleguide.md
index 2f8cd036dcf..d7c0dddee7b 100644
--- a/doc/development/search/advanced_search_migration_styleguide.md
+++ b/doc/development/search/advanced_search_migration_styleguide.md
@@ -54,7 +54,7 @@ The following migration helpers are available in `ee/app/workers/concerns/elasti
 
 Backfills a specific field in an index. In most cases, the mapping for the field should already be added.
 
-Requires the `index_name` and `field_name` methods.
+Requires the `index_name` and `field_name` methods to backfill a single field.
 
 ```ruby
 class MigrationName < Elastic::Migration
@@ -72,6 +72,24 @@ class MigrationName < Elastic::Migration
 end
 ```
 
+Requires the `index_name` and `field_names` methods to backfill multiple fields if any field is null.
+
+```ruby
+class MigrationName < Elastic::Migration
+  include Elastic::MigrationBackfillHelper
+
+  private
+
+  def index_name
+    Issue.__elasticsearch__.index_name
+  end
+
+  def field_names
+    %w[schema_version visibility_level]
+  end
+end
+```
+
 #### `Elastic::MigrationUpdateMappingsHelper`
 
 Updates a mapping in an index by calling `put_mapping` with the mapping specified.
@@ -152,6 +170,34 @@ class MigrationName < Elastic::Migration
 end
 ```
 
+#### `Elastic::MigrationCreateIndex`
+
+Creates a new index.
+
+Requires:
+
+- The `target_class` and `document_type` methods
+- Mappings and index settings for the class in `ee/lib/elastic/latest/` and `ee/lib/elastic/v12p1/`
+
+WARNING:
+You must perform a follow-up migration to populate the index in the same milestone.
+
+```ruby
+class MigrationName < Elastic::Migration
+  include Elastic::MigrationCreateIndex
+
+  retry_on_failure
+
+  def document_type
+    :epic
+  end
+
+  def target_class
+    Epic
+  end
+end
+```
+
 #### `Elastic::MigrationHelper`
 
 Contains methods you can use when a migration doesn't fit the previous examples.
@@ -215,9 +261,22 @@ class BatchedMigrationName < Elastic::Migration
 end
 ```
 
+## Avoiding downtime in migrations
+
+### Reverting a migration
+
+If a migration fails or is halted on GitLab.com, we prefer to revert the change that introduced the migration. This
+prevents self-managed customers from receiving a broken migration and reduces the need for backports.
+
+### When to merge
+
+We prefer not to merge migrations within 1 week of the release. This allows time for a revert if a migration fails or
+doesn't work as expected. Migrations still in development or review during the final week of the release should be pushed
+to the next milestone.
+
 ### Multi-version compatibility
 
-These advanced search migrations, like any other GitLab changes, need to support the case where
+Advanced search migrations, like any other GitLab changes, need to support the case where
 [multiple versions of the application are running at the same time](../multi_version_compatibility.md).
 
 Depending on the order of deployment, it's possible that the migration
@@ -225,7 +284,7 @@ has started or finished and there's still a server running the application code
 migration. We need to take this into consideration until we can
 [ensure all advanced search migrations start after the deployment has finished](https://gitlab.com/gitlab-org/gitlab/-/issues/321619).
 
-### Reverting a migration
+### High risk migrations
 
 Because Elasticsearch does not support transactions, we always need to design our
 migrations to accommodate a situation where the application
@@ -236,7 +295,26 @@ some data is moved) to a later merge request after the migrations have
 completed successfully. To be safe, for self-managed customers we should also
 defer it to another release if there is risk of important data loss.
 
-### Best practices for advanced search migrations
+## Calculating migration runtime
+
+It's important to understand how long a migration might take to run on GitLab.com. Derive the number of documents that
+will be processed by the migration. This number may come from querying the database or an existing Elasticsearch index.
+Use the following formula to calculate the runtime:
+
+```ruby
+> batch_size = 9_000
+=> 9000
+> throttle_delay = 1.minute
+=> 1 minute
+> number_of_documents = 15_536_906
+=> 15536906
+> (number_of_documents / batch_size) * throttle_delay
+=> 1726 minutes
+> (number_of_documents / batch_size) * throttle_delay / 1.hour
+=> 28
+```
+
+## Best practices for advanced search migrations
 
 Follow these best practices for best results:
 
diff --git a/doc/development/sec/analyzer_development_guide.md b/doc/development/sec/analyzer_development_guide.md
index 31058427b55..af8d1758713 100644
--- a/doc/development/sec/analyzer_development_guide.md
+++ b/doc/development/sec/analyzer_development_guide.md
@@ -88,7 +88,7 @@ The following independent criteria determine which analyzer needs to be run on a
 1. Each analyzer runs a customizable [match interface](https://gitlab.com/gitlab-org/security-products/analyzers/common/-/blob/master/search/search.go) before it performs the actual analysis. For example: [Flawfinder checks for C/C++ files](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder/-/blob/f972ac786268fb649553056a94cda05cdc1248b2/plugin/plugin.go#L14).
 1. For some analyzers that run on generic file extensions, there is a check based on a CI/CD variable. For example: Kubernetes manifests are written in YAML, so [Kubesec](https://gitlab.com/gitlab-org/security-products/analyzers/kubesec) runs only when [`SCAN_KUBERNETES_MANIFESTS` is set to true](../../user/application_security/sast/index.md#enabling-kubesec-analyzer).
 
-Step 1 helps prevent wastage of CI/CD minutes that would be spent running analyzers not suitable for the project. However, due to [technical limitations](https://gitlab.com/gitlab-org/gitlab/-/issues/227632), it cannot be used for large projects. Therefore, step 2 acts as final check to ensure a mismatched analyzer is able to exit early.
+Step 1 helps prevent wastage of compute quota that would be spent running analyzers not suitable for the project. However, due to [technical limitations](https://gitlab.com/gitlab-org/gitlab/-/issues/227632), it cannot be used for large projects. Therefore, step 2 acts as final check to ensure a mismatched analyzer is able to exit early.
 
 ## How to test the analyzers
 
@@ -361,3 +361,9 @@ This issue will guide you through the whole release process. In general, you hav
     - Max role: `Developer`
     - Scope of the associated `GITLAB_TOKEN`:
     - Expiry Date of the associated `GITLAB_TOKEN`:
+
+#### Dependency updates
+
+All dependencies and upstream scanners (if any) used in the analyzer source are updated on a monthly cadence which primarily includes security fixes and non-breaking changes.
+
+- Static Analysis team uses a custom internal tool ([SastBot](https://gitlab.com/gitlab-org/security-products/analyzers/sast-analyzer-deps-bot#dependency-update-automation)) to automate dependency management of all the SAST analyzers. SastBot generates MRs on the **8th of each month** and distributes their assignment among Static Analysis team members to take them forward for review. For details on the process, see [Dependency Update Automation](https://gitlab.com/gitlab-org/security-products/analyzers/sast-analyzer-deps-bot#dependency-update-automation).
diff --git a/doc/development/sec/CycloneDX_property_taxonomy.md b/doc/development/sec/cyclonedx_property_taxonomy.md
index 6d09529a194..6d09529a194 100644
--- a/doc/development/sec/CycloneDX_property_taxonomy.md
+++ b/doc/development/sec/cyclonedx_property_taxonomy.md
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index 7a3dc1c01fc..c5e7a58af0d 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -344,7 +344,7 @@ Much of the impact is contingent upon the function of the application and the ca
 
 For a demonstration of the impact on GitLab with a realistic attack scenario, see [this video on the GitLab Unfiltered channel](https://www.youtube.com/watch?v=t4PzHNycoKo) (internal, it requires being logged in with the GitLab Unfiltered account).
 
-### When to consider?
+### When to consider
 
 When user submitted data is included in responses to end users, which is just about anywhere.
 
@@ -485,7 +485,7 @@ In order to prevent Path Traversal vulnerabilities, user-controlled filenames or
 
 #### GitLab specific validations
 
-The methods `Gitlab::Utils.check_path_traversal!()` and `Gitlab::Utils.check_allowed_absolute_path!()`
+The methods `Gitlab::PathTraversal.check_path_traversal!()` and `Gitlab::PathTraversal.check_allowed_absolute_path!()`
 can be used to validate user-supplied paths and prevent vulnerabilities.
 `check_path_traversal!()` will detect their Path Traversal payloads and accepts URL-encoded paths.
 `check_allowed_absolute_path!()` will check if a path is absolute and whether it is inside the allowed path list. By default, absolute
@@ -495,7 +495,7 @@ parameter when using `check_allowed_absolute_path!()`.
 To use a combination of both checks, follow the example below:
 
 ```ruby
-Gitlab::Utils.check_allowed_absolute_path_and_path_traversal!(path, path_allowlist)
+Gitlab::PathTraversal.check_allowed_absolute_path_and_path_traversal!(path, path_allowlist)
 ```
 
 In the REST API, we have the [`FilePath`](https://gitlab.com/gitlab-org/security/gitlab/-/blob/master/lib/api/validations/validators/file_path.rb)
@@ -1395,3 +1395,20 @@ Additional resources:
 - <https://github.com/EthicalML/fml-security#exploring-the-owasp-top-10-for-ml>
 - <https://learn.microsoft.com/en-us/security/engineering/threat-modeling-aiml>
 - <https://learn.microsoft.com/en-us/security/engineering/failure-modes-in-machine-learning>
+
+## Local Storage
+
+### Description
+
+Local storage uses a built-in browser storage feature that caches data in read-only UTF-16 key-value pairs. Unlike `sessionStorage`, this mechanism has no built-in expiration mechanism, which can lead to large troves of potentially sensitive information being stored for indefinite periods.
+
+### Impact
+
+Local storage is subject to exfiltration during XSS attacks. These type of attacks highlight the inherent insecurity of storing sensitive information locally.
+
+### Mitigations
+
+If circumstances dictate that local storage is the only option, a couple of precautions should be taken.
+
+- Local storage should only be used for the minimal amount of data possible. Consider alternative storage formats.
+- If you have to store sensitive data using local storage, do so for the minimum time possible, calling `localStorage.removeItem` on the item as soon as we're done with it. Another alternative is to call `localStorage.clear()`.
diff --git a/doc/development/service_ping/implement.md b/doc/development/service_ping/implement.md
index 73b74feb239..c1077793fb9 100644
--- a/doc/development/service_ping/implement.md
+++ b/doc/development/service_ping/implement.md
@@ -1,884 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/service_ping/implement.md'
+remove_date: '2023-08-20'
 ---
 
-# Implement Service Ping
+This document was moved to [another location](../internal_analytics/service_ping/implement.md).
 
-Service Ping consists of two kinds of data:
-
-- **Counters**: Track how often a certain event happened over time, such as how many CI/CD pipelines have run.
-  They are monotonic and usually trend up.
-- **Observations**: Facts collected from one or more GitLab instances and can carry arbitrary data.
-  There are no general guidelines for how to collect those, due to the individual nature of that data.
-
-To implement a new metric in Service Ping, follow these steps:
-
-1. [Implement the required counter](#types-of-counters)
-1. [Name and place the metric](metrics_dictionary.md#metric-key_path)
-1. [Test counters manually using your Rails console](#test-counters-manually-using-your-rails-console)
-1. [Generate the SQL query](#generate-the-sql-query)
-1. [Optimize queries with Database Lab](#optimize-queries-with-database-lab)
-1. [Add the metric definition to the Metrics Dictionary](#add-the-metric-definition)
-1. [Add the metric to the Versions Application](#add-the-metric-to-the-versions-application)
-1. [Create a merge request](#create-a-merge-request)
-1. [Verify your metric](#verify-your-metric)
-1. [Set up and test Service Ping locally](#set-up-and-test-service-ping-locally)
-
-## Instrumentation classes
-
-NOTE:
-Implementing metrics directly in `usage_data.rb` is deprecated.
-When you add or change a Service Ping Metric, you must migrate metrics to [instrumentation classes](metrics_instrumentation.md).
-For information about the progress on migrating Service Ping metrics, see this [epic](https://gitlab.com/groups/gitlab-org/-/epics/5547).
-
-For example, we have the following instrumentation class:
-`lib/gitlab/usage/metrics/instrumentations/count_boards_metric.rb`.
-
-You should add it to `usage_data.rb` as follows:
-
-```ruby
-boards: add_metric('CountBoardsMetric', time_frame: 'all'),
-```
-
-## Types of counters
-
-There are several types of counters for metrics:
-
-- **[Batch counters](#batch-counters)**: Used for counts, sums, and averages.
-- **[Redis counters](#redis-counters):** Used for in-memory counts.
-- **[Alternative counters](#alternative-counters):** Used for settings and configurations.
-
-NOTE:
-Only use the provided counter methods. Each counter method contains a built-in fail-safe mechanism that isolates each counter to avoid breaking the entire Service Ping process.
-
-### Batch counters
-
-For large tables, PostgreSQL can take a long time to count rows due to MVCC [(Multi-version Concurrency Control)](https://en.wikipedia.org/wiki/Multiversion_concurrency_control). Batch counting is a counting method where a single large query is broken into multiple smaller queries. For example, instead of a single query querying 1,000,000 records, with batch counting, you can execute 100 queries of 10,000 records each. Batch counting is useful for avoiding database timeouts as each batch query is significantly shorter than one single long running query.
-
-For GitLab.com, there are extremely large tables with 15 second query timeouts, so we use batch counting to avoid encountering timeouts. Here are the sizes of some GitLab.com tables:
-
-| Table                        | Row counts in millions |
-|------------------------------|------------------------|
-| `merge_request_diff_commits` | 2280                   |
-| `ci_build_trace_sections`    | 1764                   |
-| `merge_request_diff_files`   | 1082                   |
-| `events`                     | 514                    |
-
-Batch counting requires indexes on columns to calculate max, min, and range queries. In some cases,
-you must add a specialized index on the columns involved in a counter.
-
-#### Ordinary batch counters
-
-Create a new [database metrics](metrics_instrumentation.md#database-metrics) instrumentation class with `count` operation for a given `ActiveRecord_Relation`
-
-Method:
-
-```ruby
-add_metric('CountIssuesMetric', time_frame: 'all')
-```
-
-Examples:
-
-Examples using `usage_data.rb` have been [deprecated](usage_data.md). We recommend to use [instrumentation classes](metrics_instrumentation.md).
-
-#### Distinct batch counters
-
-Create a new [database metrics](metrics_instrumentation.md#database-metrics) instrumentation class with `distinct_count` operation for a given `ActiveRecord_Relation`.
-
-Method:
-
-```ruby
-add_metric('CountUsersAssociatingMilestonesToReleasesMetric', time_frame: 'all')
-```
-
-WARNING:
-Counting over non-unique columns can lead to performance issues. For more information, see the [iterating tables in batches](../database/iterating_tables_in_batches.md) guide.
-
-Examples:
-
-Examples using `usage_data.rb` have been [deprecated](usage_data.md). We recommend to use [instrumentation classes](metrics_instrumentation.md).
-
-#### Sum batch operation
-
-Sum the values of a given ActiveRecord_Relation on given column and handles errors.
-Handles the `ActiveRecord::StatementInvalid` error
-
-Method:
-
-```ruby
-add_metric('JiraImportsTotalImportedIssuesCountMetric')
-```
-
-#### Average batch operation
-
-Average the values of a given `ActiveRecord_Relation` on given column and handles errors.
-
-Method:
-
-```ruby
-add_metric('CountIssuesWeightAverageMetric')
-```
-
-Examples:
-
-Examples using `usage_data.rb` have been [deprecated](usage_data.md). We recommend to use [instrumentation classes](metrics_instrumentation.md).
-
-#### Grouping and batch operations
-
-The `count`, `distinct_count` and `sum` batch counters can accept an `ActiveRecord::Relation`
-object, which groups by a specified column. With a grouped relation, the methods do batch counting,
-handle errors, and returns a hash table of key-value pairs.
-
-Examples:
-
-```ruby
-count(Namespace.group(:type))
-# returns => {nil=>179, "Group"=>54}
-
-distinct_count(Project.group(:visibility_level), :creator_id)
-# returns => {0=>1, 10=>1, 20=>11}
-
-sum(Issue.group(:state_id), :weight))
-# returns => {1=>3542, 2=>6820}
-```
-
-#### Add operation
-
-Sum the values given as parameters. Handles the `StandardError`.
-Returns `-1` if any of the arguments are `-1`.
-
-Method:
-
-```ruby
-add(*args)
-```
-
-Examples:
-
-```ruby
-project_imports = distinct_count(::Project.where.not(import_type: nil), :creator_id)
-bulk_imports = distinct_count(::BulkImport, :user_id)
-
- add(project_imports, bulk_imports)
-```
-
-#### Estimated batch counters
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48233) in GitLab 13.7.
-
-Estimated batch counter functionality handles `ActiveRecord::StatementInvalid` errors
-when used through the provided `estimate_batch_distinct_count` method.
-Errors return a value of `-1`.
-
-WARNING:
-This functionality estimates a distinct count of a specific ActiveRecord_Relation in a given column,
-which uses the [HyperLogLog](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/40671.pdf) algorithm.
-As the HyperLogLog algorithm is probabilistic, the **results always include error**.
-The highest encountered error rate is 4.9%.
-
-When correctly used, the `estimate_batch_distinct_count` method enables efficient counting over
-columns that contain non-unique values, which cannot be assured by other counters.
-
-##### `estimate_batch_distinct_count` method
-
-Method:
-
-```ruby
-estimate_batch_distinct_count(relation, column = nil, batch_size: nil, start: nil, finish: nil)
-```
-
-The [method](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/utils/usage_data.rb#L63)
-includes the following arguments:
-
-- `relation`: The ActiveRecord_Relation to perform the count.
-- `column`: The column to perform the distinct count. The default is the primary key.
-- `batch_size`: From `Gitlab::Database::PostgresHll::BatchDistinctCounter::DEFAULT_BATCH_SIZE`. Default value: 10,000.
-- `start`: The custom start of the batch count, to avoid complex minimum calculations.
-- `finish`: The custom end of the batch count to avoid complex maximum calculations.
-
-The method includes the following prerequisites:
-
-- The supplied `relation` must include the primary key defined as the numeric column.
-  For example: `id bigint NOT NULL`.
-- The `estimate_batch_distinct_count` can handle a joined relation. To use its ability to
-  count non-unique columns, the joined relation **must not** have a one-to-many relationship,
-  such as `has_many :boards`.
-- Both `start` and `finish` arguments should always represent primary key relationship values,
-  even if the estimated count refers to another column, for example:
-
-  ```ruby
-    estimate_batch_distinct_count(::Note, :author_id, start: ::Note.minimum(:id), finish: ::Note.maximum(:id))
-  ```
-
-Examples:
-
-1. Simple execution of estimated batch counter, with only relation provided,
-   returned value represents estimated number of unique values in `id` column
-   (which is the primary key) of `Project` relation:
-
-   ```ruby
-     estimate_batch_distinct_count(::Project)
-   ```
-
-1. Execution of estimated batch counter, where provided relation has applied
-   additional filter (`.where(time_period)`), number of unique values estimated
-   in custom column (`:author_id`), and parameters: `start` and `finish` together
-   apply boundaries that defines range of provided relation to analyze:
-
-   ```ruby
-     estimate_batch_distinct_count(::Note.with_suggestions.where(time_period), :author_id, start: ::Note.minimum(:id), finish: ::Note.maximum(:id))
-   ```
-
-When instrumenting metric with usage of estimated batch counter please add
-`_estimated` suffix to its name, for example:
-
-```ruby
-  "counts": {
-    "ci_builds_estimated": estimate_batch_distinct_count(Ci::Build),
-    ...
-```
-
-### Redis counters
-
-Handles `::Redis::CommandError` and `Gitlab::UsageDataCounters::BaseCounter::UnknownEvent`.
-Returns -1 when a block is sent or hash with all values and -1 when a `counter(Gitlab::UsageDataCounters)` is sent.
-The different behavior is due to 2 different implementations of the Redis counter.
-
-Method:
-
-```ruby
-redis_usage_data(counter, &block)
-```
-
-Arguments:
-
-- `counter`: a counter from `Gitlab::UsageDataCounters`, that has `fallback_totals` method implemented
-- or a `block`: which is evaluated
-
-#### Ordinary Redis counters
-
-Example of implementation: [`Gitlab::UsageDataCounters::WikiPageCounter`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/wiki_page_counter.rb), using Redis methods [`INCR`](https://redis.io/commands/incr/) and [`GET`](https://redis.io/commands/get/).
-
-Events are handled by counter classes in the `Gitlab::UsageDataCounters` namespace, inheriting from `BaseCounter`, that are either:
-
-1. Listed in [`Gitlab::UsageDataCounters::COUNTERS`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters.rb#L5) to be then included in `Gitlab::UsageData`.
-
-1. Specified in the metric definition using the `RedisMetric` instrumentation class by their `prefix` option to be picked up using the [metric instrumentation](metrics_instrumentation.md) framework. Refer to the [Redis metrics](metrics_instrumentation.md#redis-metrics) documentation for an example implementation.
-
-Inheriting classes are expected to override `KNOWN_EVENTS` and `PREFIX` constants to build event names and associated metrics. For example, for prefix `issues` and events array `%w[create, update, delete]`, three metrics will be added to the Service Ping payload: `counts.issues_create`, `counts.issues_update` and `counts.issues_delete`.
-
-##### `UsageData` API
-
-You can use the `UsageData` API to track events.
-To track events, the `usage_data_api` feature flag must
-be enabled (set to `default_enabled: true`).
-Enabled by default in GitLab 13.7 and later.
-
-##### UsageData API tracking
-
-1. Track events using the [`UsageData` API](#usagedata-api).
-
-   Increment event count using an ordinary Redis counter, for a given event name.
-
-   API requests are protected by checking for a valid CSRF token.
-
-   ```plaintext
-   POST /usage_data/increment_counter
-   ```
-
-   | Attribute | Type | Required | Description |
-   | :-------- | :--- | :------- | :---------- |
-   | `event` | string | yes | The event name to track. |
-
-   Response:
-
-   - `200` if the event was tracked.
-   - `400 Bad request` if the event parameter is missing.
-   - `401 Unauthorized` if the user is not authenticated.
-   - `403 Forbidden` if an invalid CSRF token is provided.
-
-1. Track events using the JavaScript/Vue API helper which calls the [`UsageData` API](#usagedata-api).
-
-   To track events, `usage_data_api` and `usage_data_#{event_name}` must be enabled.
-
-   ```javascript
-   import api from '~/api';
-
-   api.trackRedisCounterEvent('my_already_defined_event_name'),
-   ```
-
-#### Redis HLL counters
-
-WARNING:
-HyperLogLog (HLL) is a probabilistic algorithm and its **results always includes some small error**. According to [Redis documentation](https://redis.io/commands/pfcount/), data from
-used HLL implementation is "approximated with a standard error of 0.81%".
-
-NOTE:
- A user's consent for `usage_stats` (`User.single_user&.requires_usage_stats_consent?`) is not checked during the data tracking stage due to performance reasons. Keys corresponding to those counters are present in Redis even if `usage_stats_consent` is still required. However, no metric is collected from Redis and reported back to GitLab as long as `usage_stats_consent` is required.
-
-With `Gitlab::UsageDataCounters::HLLRedisCounter` we have available data structures used to count unique values.
-
-Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd/) and [PFCOUNT](https://redis.io/commands/pfcount/).
-
-##### Add new events
-
-1. Define events in [`known_events`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/).
-
-   Example event:
-
-   ```yaml
-   - name: users_creating_epics
-     aggregation: weekly
-   ```
-
-   Keys:
-
-   - `name`: unique event name.
-
-     Name format for Redis HLL events `{hll_counters}_<name>`
-
-     [See Metric name](metrics_dictionary.md#metric-name) for a complete guide on metric naming suggestion.
-
-     Example names: `users_creating_epics`, `users_triggering_security_scans`.
-
-   - `aggregation`: may be set to a `:daily` or `:weekly` key. Defines how counting data is stored in Redis.
-     Aggregation on a `daily` basis does not pull more fine grained data.
-
-1. Use one of the following methods to track the event:
-
-   - In the controller using the `ProductAnalyticsTracking` module and the following format:
-
-     ```ruby
-     track_event(*controller_actions, name:, action:, label:, conditions: nil, destinations: [:redis_hll], &block)
-     ```
-
-     Arguments:
-
-     - `controller_actions`: the controller actions to track.
-     - `name`: the event name.
-     - `action`: required if destination is `:snowplow. Action name for the triggered event. See [event schema](../snowplow/index.md#event-schema) for more details.
-     - `label`: required if destination is `:snowplow. Label for the triggered event. See [event schema](../snowplow/index.md#event-schema) for more details.
-     - `conditions`: optional custom conditions. Uses the same format as Rails callbacks.
-     - `destinations`: optional list of destinations. Currently supports `:redis_hll` and `:snowplow`. Default: `:redis_hll`.
-     - `&block`: optional block that computes and returns the `custom_id` that we want to track. This overrides the `visitor_id`.
-
-     Example:
-
-     ```ruby
-     # controller
-     class ProjectsController < Projects::ApplicationController
-       include ProductAnalyticsTracking
-
-       skip_before_action :authenticate_user!, only: :show
-       track_event :index, :show,
-         name: 'users_visiting_projects',
-         action: 'user_perform_visit',
-         label: 'redis_hll_counters.users_visiting_project_monthly',
-         destinations: %i[redis_hll snowplow]
-
-       def index
-         render html: 'index'
-       end
-
-      def new
-        render html: 'new'
-      end
-
-      def show
-        render html: 'show'
-      end
-     end
-     ```
-
-   - In the API using the `increment_unique_values(event_name, values)` helper method.
-
-     Arguments:
-
-     - `event_name`: the event name.
-     - `values`: the values counted. Can be one value or an array of values.
-
-     Example:
-
-     ```ruby
-     get ':id/registry/repositories' do
-       repositories = ContainerRepositoriesFinder.new(
-         user: current_user, subject: user_group
-       ).execute
-
-       increment_unique_values('users_listing_repositories', current_user.id)
-
-       present paginate(repositories), with: Entities::ContainerRegistry::Repository, tags: params[:tags], tags_count: params[:tags_count]
-     end
-     ```
-
-   - Using `track_usage_event(event_name, values)` in services and GraphQL.
-
-     Increment unique values count using Redis HLL, for a given event name.
-
-     Examples:
-
-     - [Track usage event for an incident in a service](https://gitlab.com/gitlab-org/gitlab/-/blob/v13.8.3-ee/app/services/issues/update_service.rb#L66)
-     - [Track usage event for an incident in GraphQL](https://gitlab.com/gitlab-org/gitlab/-/blob/v13.8.3-ee/app/graphql/mutations/alert_management/update_alert_status.rb#L16)
-
-     ```ruby
-       track_usage_event(:incident_management_incident_created, current_user.id)
-     ```
-
-   - Using the [`UsageData` API](#usagedata-api).
-
-     Increment unique users count using Redis HLL, for a given event name.
-
-     API requests are protected by checking for a valid CSRF token.
-
-     ```plaintext
-     POST /usage_data/increment_unique_users
-     ```
-
-     | Attribute | Type | Required | Description |
-     | :-------- | :--- | :------- | :---------- |
-     | `event` | string | yes | The event name to track |
-
-     Response:
-
-     - `200` if the event was tracked, or if tracking failed for any reason.
-     - `400 Bad request` if an event parameter is missing.
-     - `401 Unauthorized` if the user is not authenticated.
-     - `403 Forbidden` if an invalid CSRF token is provided.
-
-   - Using the JavaScript/Vue API helper, which calls the [`UsageData` API](#usagedata-api).
-
-     Example for an existing event already defined in [known events](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/):
-
-     ```javascript
-     import api from '~/api';
-
-     api.trackRedisHllUserEvent('my_already_defined_event_name'),
-     ```
-
-1. Get event data using `Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names:, start_date:, end_date:, context: '')`.
-
-   Arguments:
-
-   - `event_names`: the list of event names.
-   - `start_date`: start date of the period for which we want to get event data.
-   - `end_date`: end date of the period for which we want to get event data.
-   - `context`: context of the event. Allowed values are `default`, `free`, `bronze`, `silver`, `gold`, `starter`, `premium`, `ultimate`.
-
-1. Testing tracking and getting unique events
-
-Trigger events in rails console by using `track_event` method
-
-   ```ruby
-   Gitlab::UsageDataCounters::HLLRedisCounter.track_event('users_viewing_compliance_audit_events', values: 1)
-   Gitlab::UsageDataCounters::HLLRedisCounter.track_event('users_viewing_compliance_audit_events', values: [2, 3])
-   ```
-
-Next, get the unique events for the current week.
-
-   ```ruby
-   # Get unique events for metric for current_week
-   Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'users_viewing_compliance_audit_events',
-   start_date: Date.current.beginning_of_week, end_date: Date.current.next_week)
-   ```
-
-##### Recommendations
-
-We have the following recommendations for [adding new events](#add-new-events):
-
-- Event aggregation: weekly.
-- When adding new metrics, use a [feature flag](../../operations/feature_flags.md) to control the impact.
-It's recommended to disable the new feature flag by default (set `default_enabled: false`).
-- Events can be triggered using the `UsageData` API, which helps when there are > 10 events per change
-
-##### Enable or disable Redis HLL tracking
-
-We can disable tracking completely by using the global flag:
-
-```shell
-/chatops run feature set redis_hll_tracking true
-/chatops run feature set redis_hll_tracking false
-```
-
-##### Known events are added automatically in Service Data payload
-
-Service Ping adds all events [`known_events/*.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events) to Service Data generation under the `redis_hll_counters` key. This column is stored in [version-app as a JSON](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/db/schema.rb#L209).
-For each event we add metrics for the weekly and monthly time frames, and totals for each where applicable:
-
-- `#{event_name}_weekly`: Data for 7 days for daily [aggregation](#add-new-events) events and data for the last complete week for weekly [aggregation](#add-new-events) events.
-- `#{event_name}_monthly`: Data for 28 days for daily [aggregation](#add-new-events) events and data for the last 4 complete weeks for weekly [aggregation](#add-new-events) events.
-
-Example of `redis_hll_counters` data:
-
-```ruby
-{:redis_hll_counters=>
-  {"compliance"=>
-    {"users_viewing_compliance_dashboard_weekly"=>0,
-     "users_viewing_compliance_dashboard_monthly"=>0,
-     "users_viewing_compliance_audit_events_weekly"=>0,
-     "users_viewing_audit_events_monthly"=>0,
-     "compliance_total_unique_counts_weekly"=>0,
-     "compliance_total_unique_counts_monthly"=>0},
- "analytics"=>
-    {"users_viewing_analytics_group_devops_adoption_weekly"=>0,
-     "users_viewing_analytics_group_devops_adoption_monthly"=>0,
-     "analytics_total_unique_counts_weekly"=>0,
-     "analytics_total_unique_counts_monthly"=>0},
-   "ide_edit"=>
-    {"users_editing_by_web_ide_weekly"=>0,
-     "users_editing_by_web_ide_monthly"=>0,
-     "users_editing_by_sfe_weekly"=>0,
-     "users_editing_by_sfe_monthly"=>0,
-     "ide_edit_total_unique_counts_weekly"=>0,
-     "ide_edit_total_unique_counts_monthly"=>0}
- }
-}
-```
-
-Example:
-
-```ruby
-# Redis Counters
-redis_usage_data(Gitlab::UsageDataCounters::WikiPageCounter)
-
-# Define events in common.yml https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/common.yml
-
-# Tracking events
-Gitlab::UsageDataCounters::HLLRedisCounter.track_event('users_expanding_vulnerabilities', values: visitor_id)
-
-# Get unique events for metric
-redis_usage_data { Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'users_expanding_vulnerabilities', start_date: 28.days.ago, end_date: Date.current) }
-```
-
-### Alternative counters
-
-Handles `StandardError` and fallbacks into -1 this way not all measures fail if we encounter one exception.
-Mainly used for settings and configurations.
-
-Method:
-
-```ruby
-alt_usage_data(value = nil, fallback: -1, &block)
-```
-
-Arguments:
-
-- `value`: a static value in which case the value is returned.
-- or a `block`: which is evaluated
-- `fallback: -1`: the common value used for any metrics that are failing.
-
-Example:
-
-```ruby
-alt_usage_data { Gitlab::VERSION }
-alt_usage_data { Gitlab::CurrentSettings.uuid }
-alt_usage_data(999)
-```
-
-### Add counters to build new metrics
-
-When adding the results of two counters, use the `add` Service Data method that
-handles fallback values and exceptions. It also generates a valid [SQL export](index.md#export-service-ping-data).
-
-Example:
-
-```ruby
-add(User.active, User.bot)
-```
-
-### Prometheus queries
-
-In those cases where operational metrics should be part of Service Ping, a database or Redis query is unlikely
-to provide useful data. Instead, Prometheus might be more appropriate, because most GitLab architectural
-components publish metrics to it that can be queried back, aggregated, and included as Service Data.
-
-NOTE:
-Prometheus as a data source for Service Ping is only available for single-node Omnibus installations
-that are running the [bundled Prometheus](../../administration/monitoring/prometheus/index.md) instance.
-
-To query Prometheus for metrics, a helper method is available to `yield` a fully configured
-`PrometheusClient`, given it is available as per the note above:
-
-```ruby
-with_prometheus_client do |client|
-  response = client.query('<your query>')
-  ...
-end
-```
-
-Refer to [the `PrometheusClient` definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/prometheus_client.rb)
-for how to use its API to query for data.
-
-### Fallback values for Service Ping
-
-We return fallback values in these cases:
-
-| Case                        | Value |
-|-----------------------------|-------|
-| Deprecated Metric ([Removed with version 14.3](https://gitlab.com/gitlab-org/gitlab/-/issues/335894)) | -1000 |
-| Timeouts, general failures  | -1    |
-| Standard errors in counters | -2    |
-| Histogram metrics failure   | { '-1' => -1 } |
-
-## Test counters manually using your Rails console
-
-```ruby
-# count
-Gitlab::UsageData.count(User.active)
-Gitlab::UsageData.count(::Clusters::Cluster.aws_installed.enabled, :cluster_id)
-
-# count distinct
-Gitlab::UsageData.distinct_count(::Project, :creator_id)
-Gitlab::UsageData.distinct_count(::Note.with_suggestions.where(time_period), :author_id, start: ::User.minimum(:id), finish: ::User.maximum(:id))
-```
-
-## Generate the SQL query
-
-Your Rails console returns the generated SQL queries. For example:
-
-```ruby
-pry(main)> Gitlab::UsageData.count(User.active)
-   (2.6ms)  SELECT "features"."key" FROM "features"
-   (15.3ms)  SELECT MIN("users"."id") FROM "users" WHERE ("users"."state" IN ('active')) AND ("users"."user_type" IS NULL OR "users"."user_type" IN (6, 4))
-   (2.4ms)  SELECT MAX("users"."id") FROM "users" WHERE ("users"."state" IN ('active')) AND ("users"."user_type" IS NULL OR "users"."user_type" IN (6, 4))
-   (1.9ms)  SELECT COUNT("users"."id") FROM "users" WHERE ("users"."state" IN ('active')) AND ("users"."user_type" IS NULL OR "users"."user_type" IN (6, 4)) AND "users"."id" BETWEEN 1 AND 100000
-```
-
-## Optimize queries with Database Lab
-
-[Database Lab](../database/database_lab.md) is a service that uses a production clone to test queries.
-
-- GitLab.com's production database has a 15 second timeout.
-- Any single query must stay below the [1 second execution time](../database/query_performance.md#timing-guidelines-for-queries) with cold caches.
-- Add a specialized index on columns involved to reduce the execution time.
-
-To understand the query's execution, we add the following information
-to a merge request description:
-
-- For counters that have a `time_period` test, we add information for both:
-  - `time_period = {}` for all time periods.
-  - `time_period = { created_at: 28.days.ago..Time.current }` for the last 28 days.
-- Execution plan and query time before and after optimization.
-- Query generated for the index and time.
-- Migration output for up and down execution.
-
-For more details, see the [database review guide](../database_review.md#preparation-when-adding-or-modifying-queries).
-
-### Optimization recommendations and examples
-
-- Use specialized indexes. For examples, see these merge requests:
-  - [Example 1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26871)
-  - [Example 2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26445)
-- Use defined `start` and `finish`. These values can be memoized and reused, as in this
-  [example merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37155).
-- Avoid joins and unnecessary complexity in your queries. See this
-  [example merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36316) as an example.
-- Set a custom `batch_size` for `distinct_count`, as in this [example merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38000).
-
-## Add the metric definition
-
-See the [Metrics Dictionary guide](metrics_dictionary.md) for more information.
-
-## Add the metric to the Versions Application
-
-Check if the new metric must be added to the Versions Application. See the `usage_data` [schema](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/db/schema.rb#L147) and Service Data [parameters accepted](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/app/services/usage_ping.rb). Any metrics added under the `counts` key are saved in the `stats` column.
-
-## Create a merge request
-
-Create a merge request for the new Service Ping metric, and do the following:
-
-- Add the `feature` label to the merge request. A metric is a user-facing change and is part of expanding the Service Ping feature.
-- Add a changelog entry that complies with the [changelog entries guide](../changelog.md).
-- Ask for an Analytics Instrumentation review.
-  On GitLab.com, we have DangerBot set up to monitor Analytics Instrumentation related files and recommend a [Analytics Instrumentation review](review_guidelines.md).
-
-## Verify your metric
-
-On GitLab.com, the Product Intelligence team regularly [monitors Service Ping](https://gitlab.com/groups/gitlab-org/-/epics/6000).
-They may alert you that your metrics need further optimization to run quicker and with greater success.
-
-The Service Ping JSON payload for GitLab.com is shared in the
-[#g_product_intelligence](https://gitlab.slack.com/archives/CL3A7GFPF) Slack channel every week.
-
-You may also use the [Service Ping QA dashboard](https://app.periscopedata.com/app/gitlab/632033/Usage-Ping-QA) to check how well your metric performs.
-The dashboard allows filtering by GitLab version, by "Self-managed" and "SaaS", and shows you how many failures have occurred for each metric. Whenever you notice a high failure rate, you can re-optimize your metric.
-
-Use [Metrics Dictionary](https://metrics.gitlab.com/) [copy query to clipboard feature](https://www.youtube.com/watch?v=n4o65ivta48&list=PL05JrBw4t0Krg3mbR6chU7pXtMt_es6Pb) to get a query ready to run in Sisense for a specific metric.
-
-## Set up and test Service Ping locally
-
-To set up Service Ping locally, you must:
-
-1. [Set up local repositories](#set-up-local-repositories).
-1. [Test local setup](#test-local-setup).
-1. Optional. [Test Prometheus-based Service Ping](#test-prometheus-based-service-ping).
-
-### Set up local repositories
-
-1. Clone and start [GitLab](https://gitlab.com/gitlab-org/gitlab-development-kit).
-1. Clone and start [Versions Application](https://gitlab.com/gitlab-services/version-gitlab-com).
-   Make sure you run `docker-compose up` to start a PostgreSQL and Redis instance.
-1. Point GitLab to the Versions Application endpoint instead of the default endpoint:
-   1. Open [service_ping/submit_service.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/service_ping/submit_service.rb#L5) locally and modify `STAGING_BASE_URL`.
-   1. Set it to the local Versions Application URL: `http://localhost:3000`.
-
-### Test local setup
-
-1. Using the `gitlab` Rails console, manually trigger Service Ping:
-
-   ```ruby
-   GitlabServicePingWorker.new.perform('triggered_from_cron' => false)
-   ```
-
-1. Use the `versions` Rails console to check the Service Ping was successfully received,
-   parsed, and stored in the Versions database:
-
-   ```ruby
-   UsageData.last
-   ```
-
-## Test Prometheus-based Service Ping
-
-If the data submitted includes metrics [queried from Prometheus](#prometheus-queries)
-you want to inspect and verify, you must:
-
-- Ensure that a Prometheus server is running locally.
-- Ensure the respective GitLab components are exporting metrics to the Prometheus server.
-
-If you do not need to test data coming from Prometheus, no further action
-is necessary. Service Ping should degrade gracefully in the absence of a running Prometheus server.
-
-Three kinds of components may export data to Prometheus, and are included in Service Ping:
-
-- [`node_exporter`](https://github.com/prometheus/node_exporter): Exports node metrics
-  from the host machine.
-- [`gitlab-exporter`](https://gitlab.com/gitlab-org/gitlab-exporter): Exports process metrics
-  from various GitLab components.
-- Other various GitLab services, such as Sidekiq and the Rails server, which export their own metrics.
-
-### Test with an Omnibus container
-
-This is the recommended approach to test Prometheus-based Service Ping.
-
-To verify your change, build a new Omnibus image from your code branch using CI/CD, download the image,
-and run a local container instance:
-
-1. From your merge request, select the `qa` stage, then trigger the `e2e:package-and-test` job. This job triggers an Omnibus
-   build in a [downstream pipeline of the `omnibus-gitlab-mirror` project](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/-/pipelines).
-1. In the downstream pipeline, wait for the `gitlab-docker` job to finish.
-1. Open the job logs and locate the full container name including the version. It takes the following form: `registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<VERSION>`.
-1. On your local machine, make sure you are signed in to the GitLab Docker registry. You can find the instructions for this in
-   [Authenticate to the GitLab Container Registry](../../user/packages/container_registry/authenticate_with_container_registry.md).
-1. Once signed in, download the new image by using `docker pull registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<VERSION>`
-1. For more information about working with and running Omnibus GitLab containers in Docker, refer to [GitLab Docker images](../../install/docker.md) documentation.
-
-### Test with GitLab development toolkits
-
-This is the less recommended approach, because it comes with a number of difficulties when emulating a real GitLab deployment.
-
-The [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit) is not set up to run a Prometheus server or `node_exporter` alongside other GitLab components. If you would
-like to do so, [Monitoring the GDK with Prometheus](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/prometheus/index.md#monitoring-the-gdk-with-prometheus) is a good start.
-
-The [GCK](https://gitlab.com/gitlab-org/gitlab-compose-kit) has limited support for testing Prometheus based Service Ping.
-By default, it comes with a fully configured Prometheus service that is set up to scrape a number of components.
-However, it has the following limitations:
-
-- It does not run a `gitlab-exporter` instance, so several `process_*` metrics from services such as Gitaly may be missing.
-- While it runs a `node_exporter`, `docker-compose` services emulate hosts, meaning that it normally reports itself as not associated
-  with any of the other running services. That is not how node metrics are reported in a production setup, where `node_exporter`
-  always runs as a process alongside other GitLab components on any given node. For Service Ping, none of the node data would therefore
-  appear to be associated to any of the services running, because they all appear to be running on different hosts. To alleviate this problem, the `node_exporter` in GCK was arbitrarily "assigned" to the `web` service, meaning only for this service `node_*` metrics appears in Service Ping.
-
-## Aggregated metrics
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/45979) in GitLab 13.6.
-
-WARNING:
-This feature is intended solely for internal GitLab use.
-
-The aggregated metrics feature provides insight into the data attributes in a collection of Service Ping metrics.
-This aggregation allows you to count data attributes in events without counting each occurrence of the same data attribute in multiple events.
-For example, you can aggregate the number of users who perform several actions, such as creating a new issue and opening a new merge request.
-You can then count each user that performed any combination of these actions.
-
-### Defining aggregated metric via metric YAML definition
-
-To add data for aggregated metrics to the Service Ping payload,
-create metric YAML definition file following [Aggregated metric instrumentation guide](metrics_instrumentation.md#aggregated-metrics).
-
-### Redis sourced aggregated metrics
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/45979) in GitLab 13.6.
-
-To declare the aggregate of events collected with [Redis HLL Counters](#redis-hll-counters),
-you must fulfill the following requirements:
-
-1. All events listed at `events` attribute must come from
-   [`known_events/*.yml`](#known-events-are-added-automatically-in-service-data-payload) files.
-1. All events listed at `events` attribute must have the same `aggregation` attribute.
-1. `time_frame` does not include `all` value, which is unavailable for Redis sourced aggregated metrics.
-
-While it is possible to aggregate EE-only events together with events that occur in all GitLab editions, it's important to remember that doing so may produce high variance between data collected from EE and CE GitLab instances.
-
-### Database sourced aggregated metrics
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52784) in GitLab 13.9.
-
-To declare an aggregate of metrics based on events collected from database, follow
-these steps:
-
-1. [Persist the metrics for aggregation](#persist-metrics-for-aggregation).
-1. [Add new aggregated metric definition](#add-new-aggregated-metric-definition).
-
-#### Persist metrics for aggregation
-
-Only metrics calculated with [Estimated Batch Counters](#estimated-batch-counters)
-can be persisted for database sourced aggregated metrics. To persist a metric,
-inject a Ruby block into the
-[`estimate_batch_distinct_count`](#estimate_batch_distinct_count-method) method.
-This block should invoke the
-`Gitlab::Usage::Metrics::Aggregates::Sources::PostgresHll.save_aggregated_metrics`
-[method](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage/metrics/aggregates/sources/postgres_hll.rb#L21),
-which stores `estimate_batch_distinct_count` results for future use in aggregated metrics.
-
-The `Gitlab::Usage::Metrics::Aggregates::Sources::PostgresHll.save_aggregated_metrics`
-method accepts the following arguments:
-
-- `metric_name`: The name of metric to use for aggregations. Should be the same
-  as the key under which the metric is added into Service Ping.
-- `recorded_at_timestamp`: The timestamp representing the moment when a given
-  Service Ping payload was collected. You should use the convenience method `recorded_at`
-  to fill `recorded_at_timestamp` argument, like this: `recorded_at_timestamp: recorded_at`
-- `time_period`: The time period used to build the `relation` argument passed into
-  `estimate_batch_distinct_count`. To collect the metric with all available historical
-  data, set a `nil` value as time period: `time_period: nil`.
-- `data`: HyperLogLog buckets structure representing unique entries in `relation`.
-  The `estimate_batch_distinct_count` method always passes the correct argument
-  into the block, so `data` argument must always have a value equal to block argument,
-  like this: `data: result`
-
-Example metrics persistence:
-
-```ruby
-class UsageData
-  def count_secure_pipelines(time_period)
-    ...
-    relation = ::Security::Scan.by_scan_types(scan_type).where(time_period)
-
-    pipelines_with_secure_jobs['dependency_scanning_pipeline'] = estimate_batch_distinct_count(relation, :pipeline_id, batch_size: 1000, start: start_id, finish: finish_id) do |result|
-      ::Gitlab::Usage::Metrics::Aggregates::Sources::PostgresHll
-        .save_aggregated_metrics(metric_name: 'dependency_scanning_pipeline', recorded_at_timestamp: recorded_at, time_period: time_period, data: result)
-    end
-  end
-end
-```
-
-#### Add new aggregated metric definition
-
-After all metrics are persisted, you can add an aggregated metric definition following [Aggregated metric instrumentation guide](metrics_instrumentation.md#aggregated-metrics).
-To declare the aggregate of metrics collected with [Estimated Batch Counters](#estimated-batch-counters),
-you must fulfill the following requirements:
-
-- Metrics names listed in the `events:` attribute, have to use the same names you passed in the `metric_name` argument while persisting metrics in previous step.
-- Every metric listed in the `events:` attribute, has to be persisted for **every** selected `time_frame:` value.
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/service_ping/index.md b/doc/development/service_ping/index.md
index 3504a730eed..d0806ed375b 100644
--- a/doc/development/service_ping/index.md
+++ b/doc/development/service_ping/index.md
@@ -1,509 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/service_ping/index.md'
+remove_date: '2023-08-20'
 ---
 
-# Service Ping development guidelines
+This document was moved to [another location](../internal_analytics/service_ping/index.md).
 
-> - Introduced in GitLab Ultimate 11.2, more statistics.
-> - In GitLab 14.1, [renamed from Usage Ping to Service Ping](https://gitlab.com/groups/gitlab-org/-/epics/5990). In 14.0 and earlier, use the Usage Ping documentation for the Rails commands appropriate to your version.
-
-Service Ping is a GitLab process that collects and sends a weekly payload to GitLab.
-The payload provides important high-level data that helps our product, support,
-and sales teams understand how GitLab is used. The data helps to:
-
-- Compare counts month over month (or week over week) to get a rough sense for how an instance uses
-  different product features.
-- Collect other facts that help us classify and understand GitLab installations.
-- Calculate our stage monthly active users (SMAU), which helps to measure the success of our stages
-  and features.
-
-Service Ping information is not anonymous. It's linked to the instance's hostname, but does
-not contain project names, usernames, or any other specific data.
-
-Service Ping is enabled by default. However, you can [disable](../../user/admin_area/settings/usage_statistics.md#enable-or-disable-usage-statistics) it on any self-managed instance. When Service Ping is enabled, GitLab gathers data from the other instances and can show your instance's usage statistics to your users.
-
-## Service Ping terminology
-
-We use the following terminology to describe the Service Ping components:
-
-- **Service Ping**: the process that collects and generates a JSON payload.
-- **Service Data**: the contents of the Service Ping JSON payload. This includes metrics.
-- **Metrics**: primarily made up of row counts for different tables in an instance's database. Each
-  metric has a corresponding [metric definition](metrics_dictionary.md#metrics-definition-and-validation)
-  in a YAML file.
-- **MAU**: monthly active users.
-- **WAU**: weekly active users.
-
-### Limitations
-
-- Service Ping does not track frontend events things like page views, link clicks, or user sessions.
-- Service Ping focuses only on aggregated backend events.
-
-Because of these limitations we recommend you:
-
-- Instrument your products with Snowplow for more detailed analytics on GitLab.com.
-- Use Service Ping to track aggregated backend events on self-managed instances.
-
-## Service Ping request flow
-
-The following example shows a basic request/response flow between a GitLab instance, the Versions Application, the License Application, Salesforce, the GitLab S3 Bucket, the GitLab Snowflake Data Warehouse, and Sisense:
-
-```mermaid
-sequenceDiagram
-    participant GitLab Instance
-    participant Versions Application
-    participant Licenses Application
-    participant Salesforce
-    participant S3 Bucket
-    participant Snowflake DW
-    participant Sisense Dashboards
-    GitLab Instance->>Versions Application: Send Service Ping
-    loop Process usage data
-        Versions Application->>Versions Application: Parse usage data
-        Versions Application->>Versions Application: Write to database
-        Versions Application->>Versions Application: Update license ping time
-    end
-    loop Process data for Salesforce
-        Versions Application-xLicenses Application: Request Zuora subscription id
-        Licenses Application-xVersions Application: Zuora subscription id
-        Versions Application-xSalesforce: Request Zuora account id  by Zuora subscription id
-        Salesforce-xVersions Application: Zuora account id
-        Versions Application-xSalesforce: Usage data for the Zuora account
-    end
-    Versions Application->>S3 Bucket: Export Versions database
-    S3 Bucket->>Snowflake DW: Import data
-    Snowflake DW->>Snowflake DW: Transform data using dbt
-    Snowflake DW->>Sisense Dashboards: Data available for querying
-    Versions Application->>GitLab Instance: DevOps Score (Conversational Development Index)
-```
-
-## How Service Ping works
-
-1. The Service Ping [cron job](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/gitlab_service_ping_worker.rb#L24) is set in Sidekiq to run weekly.
-1. When the cron job runs, it calls [`Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values)`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/service_ping/submit_service.rb).
-1. `Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values)` [cascades down](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb) to ~400+ other counter method calls.
-1. The response of all methods calls are [merged together](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb#L68) into a single JSON payload.
-1. The JSON payload is then [posted to the Versions application](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/service_ping/submit_service.rb#L20)
-   If a firewall exception is needed, the required URL depends on several things. If
-   the hostname is `version.gitlab.com`, the protocol is `TCP`, and the port number is `443`,
-   the required URL is <https://version.gitlab.com/>.
-1. In case of an error, it will be reported to the Version application along with following pieces of information:
-
-   - `uuid` - GitLab instance unique identifier
-   - `hostname` - GitLab instance hostname
-   - `version` - GitLab instance current versions
-   - `elapsed` - Amount of time which passed since Service Ping report process started and moment of error occurrence
-   - `message` - Error message
-
-   <pre>
-   <code>
-   {
-     "uuid"=>"02333324-1cd7-4c3b-a45b-a4993f05fb1d",
-     "hostname"=>"127.0.0.1",
-     "version"=>"14.7.0-pre",
-     "elapsed"=>0.006946,
-     "message"=>'PG::UndefinedColumn: ERROR:  column \"non_existent_attribute\" does not exist\nLINE 1: SELECT COUNT(non_existent_attribute) FROM \"issues\" /*applica...'
-   }
-   </code>
-   </pre>
-
-1. Finally, the timing metadata information that is used for diagnostic purposes is submitted to the Versions application. It consists of a list of metric identifiers and the time it took to calculate the metrics:
-
-   > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37911) in GitLab 15.0 [with a flag](../../user/feature_flags.md), enabled by default.
-   > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/295289) in GitLab 15.2. [Feature flag `measure_service_ping_metric_collection`](https://gitlab.com/gitlab-org/gitlab/-/issues/358128) removed.
-
-```ruby
-    {
-      "metadata"=>
-      {
-        "uuid"=>"0000000-0000-0000-0000-000000000000",
-        "metrics"=>
-        [{"name"=>"version", "time_elapsed"=>1.1811964213848114e-05},
-         {"name"=>"installation_type", "time_elapsed"=>0.00017242692410945892},
-         {"name"=>"license_billable_users", "time_elapsed"=>0.009520471096038818},
-         ....
-         {"name"=>"counts.clusters_platforms_eks",
-          "time_elapsed"=>0.05638605775311589},
-         {"name"=>"counts.clusters_platforms_gke",
-          "time_elapsed"=>0.40995341585949063},
-         {"name"=>"counts.clusters_platforms_user",
-          "time_elapsed"=>0.06410990096628666},
-         {"name"=>"counts.clusters_management_project",
-          "time_elapsed"=>0.24020783510059118}
-        ]
-      }
-    }
-```
-
-### On a Geo secondary site
-
-We also collect metrics specific to [Geo](../../administration/geo/index.md) secondary sites to send with Service Ping.
-
-1. The [Geo secondary service ping cron job](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/workers/geo/secondary_usage_data_cron_worker.rb) is set in Sidekiq to run weekly.
-1. When the cron job runs, it calls [`SecondaryUsageData.update_metrics!`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/geo/secondary_usage_data.rb#L33). This collects the relevant metrics from Prometheus and stores the data in the Geo secondary tracking database for transmission to the primary site during a [Geo node status update](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/geo_node_status.rb#L105).
-1. Geo node status data is sent with the JSON payload in the process described above. The following is an example of the payload where each object in the array represents a Geo node:
-
-   ```json
-   [
-     {
-       "repository_verification_enabled"=>true,
-       "repositories_replication_enabled"=>true,
-       "repositories_synced_count"=>24,
-       "repositories_failed_count"=>0,
-       "git_fetch_event_count_weekly"=>nil,
-       "git_push_event_count_weekly"=>nil,
-       ... other geo node status fields
-     }
-   ]
-   ```
-
-## Implementing Service Ping
-
-See the [implement Service Ping](implement.md) guide.
-
-## Example Service Ping payload
-
-The following is example content of the Service Ping payload.
-
-```json
-{
-  "uuid": "0000000-0000-0000-0000-000000000000",
-  "hostname": "example.com",
-  "version": "12.10.0-pre",
-  "installation_type": "omnibus-gitlab",
-  "active_user_count": 999,
-  "recorded_at": "2020-04-17T07:43:54.162+00:00",
-  "edition": "EEU",
-  "license_md5": "00000000000000000000000000000000",
-  "license_sha256": "0000000000000000000000000000000000000000000000000000000000000000",
-  "license_id": null,
-  "historical_max_users": 999,
-  "licensee": {
-    "Name": "ABC, Inc.",
-    "Email": "email@example.com",
-    "Company": "ABC, Inc."
-  },
-  "license_user_count": 999,
-  "license_starts_at": "2020-01-01",
-  "license_expires_at": "2021-01-01",
-  "license_plan": "ultimate",
-  "license_add_ons": {
-  },
-  "license_trial": false,
-  "counts": {
-    "assignee_lists": 999,
-    "boards": 999,
-    "ci_builds": 999,
-    ...
-  },
-  "container_registry_enabled": true,
-  "dependency_proxy_enabled": false,
-  "gitlab_shared_runners_enabled": true,
-  "gravatar_enabled": true,
-  "influxdb_metrics_enabled": true,
-  "ldap_enabled": false,
-  "mattermost_enabled": false,
-  "omniauth_enabled": true,
-  "prometheus_enabled": false,
-  "prometheus_metrics_enabled": false,
-  "reply_by_email_enabled": "incoming+%{key}@incoming.gitlab.com",
-  "signup_enabled": true,
-  "projects_with_expiration_policy_disabled": 999,
-  "projects_with_expiration_policy_enabled": 999,
-  ...
-  "elasticsearch_enabled": true,
-  "license_trial_ends_on": null,
-  "geo_enabled": false,
-  "git": {
-    "version": {
-      "major": 2,
-      "minor": 26,
-      "patch": 1
-    }
-  },
-  "gitaly": {
-    "version": "12.10.0-rc1-93-g40980d40",
-    "servers": 56,
-    "clusters": 14,
-    "filesystems": [
-      "EXT_2_3_4"
-    ]
-  },
-  "gitlab_pages": {
-    "enabled": true,
-    "version": "1.17.0"
-  },
-  "container_registry_server": {
-    "vendor": "gitlab",
-    "version": "2.9.1-gitlab"
-  },
-  "database": {
-    "adapter": "postgresql",
-    "version": "9.6.15",
-    "pg_system_id": 6842684531675334351,
-    "flavor": "Cloud SQL for PostgreSQL"
-  },
-  "analytics_unique_visits": {
-    "g_analytics_contribution": 999,
-    ...
-  },
-  "usage_activity_by_stage": {
-    "configure": {
-      "project_clusters_enabled": 999,
-      ...
-    },
-    "create": {
-      "merge_requests": 999,
-      ...
-    },
-    "manage": {
-      "events": 999,
-      ...
-    },
-    "monitor": {
-      "clusters": 999,
-      ...
-    },
-    "package": {
-      "projects_with_packages": 999
-    },
-    "plan": {
-      "issues": 999,
-      ...
-    },
-    "release": {
-      "deployments": 999,
-      ...
-    },
-    "secure": {
-      "user_container_scanning_jobs": 999,
-      ...
-    },
-    "verify": {
-      "ci_builds": 999,
-      ...
-    }
-  },
-  "usage_activity_by_stage_monthly": {
-    "configure": {
-      "project_clusters_enabled": 999,
-      ...
-    },
-    "create": {
-      "merge_requests": 999,
-      ...
-    },
-    "manage": {
-      "events": 999,
-      ...
-    },
-    "monitor": {
-      "clusters": 999,
-      ...
-    },
-    "package": {
-      "projects_with_packages": 999
-    },
-    "plan": {
-      "issues": 999,
-      ...
-    },
-    "release": {
-      "deployments": 999,
-      ...
-    },
-    "secure": {
-      "user_container_scanning_jobs": 999,
-      ...
-    },
-    "verify": {
-      "ci_builds": 999,
-      ...
-    }
-  },
-  "topology": {
-    "duration_s": 0.013836685999194742,
-    "application_requests_per_hour": 4224,
-    "query_apdex_weekly_average": 0.996,
-    "failures": [],
-    "nodes": [
-      {
-        "node_memory_total_bytes": 33269903360,
-        "node_memory_utilization": 0.35,
-        "node_cpus": 16,
-        "node_cpu_utilization": 0.2,
-        "node_uname_info": {
-          "machine": "x86_64",
-          "sysname": "Linux",
-          "release": "4.19.76-linuxkit"
-        },
-        "node_services": [
-          {
-            "name": "web",
-            "process_count": 16,
-            "process_memory_pss": 233349888,
-            "process_memory_rss": 788220927,
-            "process_memory_uss": 195295487,
-            "server": "puma"
-          },
-          {
-            "name": "sidekiq",
-            "process_count": 1,
-            "process_memory_pss": 734080000,
-            "process_memory_rss": 750051328,
-            "process_memory_uss": 731533312
-          },
-          ...
-        ],
-        ...
-      },
-      ...
-    ]
-  }
-}
-```
-
-## Notable changes
-
-In GitLab 14.6, [`flavor`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75587) was added to try to detect the underlying managed database variant.
-Possible values are "Amazon Aurora PostgreSQL", "PostgreSQL on Amazon RDS", "Cloud SQL for PostgreSQL",
-"Azure Database for PostgreSQL - Flexible Server", or "null".
-
-In GitLab 13.5, `pg_system_id` was added to send the [PostgreSQL system identifier](https://www.2ndquadrant.com/en/blog/support-for-postgresqls-system-identifier-in-barman/).
-
-## Export Service Ping data
-
-Rake tasks exist to export Service Ping data in different formats.
-
-- The Rake tasks export the raw SQL queries for `count`, `distinct_count`, `sum`.
-- The Rake tasks export the Redis counter class or the line of the Redis block for `redis_usage_data`.
-- The Rake tasks calculate the `alt_usage_data` metrics.
-
-In the home directory of your local GitLab installation run the following Rake tasks for the YAML and JSON versions respectively:
-
-```shell
-# for YAML export of SQL queries
-bin/rake gitlab:usage_data:dump_sql_in_yaml
-
-# for JSON export of SQL queries
-bin/rake gitlab:usage_data:dump_sql_in_json
-
-# for JSON export of Non SQL data
-bin/rake gitlab:usage_data:dump_non_sql_in_json
-
-# You may pipe the output into a file
-bin/rake gitlab:usage_data:dump_sql_in_yaml > ~/Desktop/usage-metrics-2020-09-02.yaml
-```
-
-## Generate Service Ping
-
-To generate Service Ping, use [Teleport](https://goteleport.com/docs/) or a detached screen session on a remote server.
-
-### Triggering
-
-#### Trigger Service Ping with Teleport
-
-1. Request temporary [access](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/teleport/Connect_to_Rails_Console_via_Teleport.md#how-to-use-teleport-to-connect-to-rails-console) to the required environment.
-1. After your approval is issued, [access the Rails console](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/teleport/Connect_to_Rails_Console_via_Teleport.md#access-approval).
-1. Run `GitlabServicePingWorker.new.perform('triggered_from_cron' => false)`.
-
-#### Trigger Service Ping with a detached screen session
-
-1. Connect to bastion with agent forwarding:
-
-   ```shell
-   ssh -A lb-bastion.gprd.gitlab.com
-   ```
-
-1. Create named screen:
-
-   ```shell
-   screen -S <username>_usage_ping_<date>
-   ```
-
-1. Connect to console host:
-
-   ```shell
-   ssh $USER-rails@console-01-sv-gprd.c.gitlab-production.internal
-   ```
-
-1. Run:
-
-   ```shell
-   GitlabServicePingWorker.new.perform('triggered_from_cron' => false)
-   ```
-
-1. To detach from screen, press `ctrl + A`, `ctrl + D`.
-1. Exit from bastion:
-
-   ```shell
-   exit
-   ```
-
-1. Get the metrics duration from logs:
-
-Search in Google Console logs for `time_elapsed`. [Query example](https://cloudlogging.app.goo.gl/nWheZvD8D3nWazNe6).
-
-### Verification (After approx 30 hours)
-
-#### Verify with Teleport
-
-1. Follow [the steps](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/teleport/Connect_to_Rails_Console_via_Teleport.md#how-to-use-teleport-to-connect-to-rails-console) to request a new access to the required environment and connect to the Rails console
-1. Check the last payload in `raw_usage_data` table: `RawUsageData.last.payload`
-1. Check the when the payload was sent: `RawUsageData.last.sent_at`
-
-#### Verify using detached screen session
-
-1. Reconnect to bastion:
-
-   ```shell
-   ssh -A lb-bastion.gprd.gitlab.com
-   ```
-
-1. Find your screen session:
-
-   ```shell
-   screen -ls
-   ```
-
-1. Attach to your screen session:
-
-   ```shell
-   screen -x 14226.mwawrzyniak_usage_ping_2021_01_22
-   ```
-
-1. Check the last payload in `raw_usage_data` table:
-
-   ```shell
-   RawUsageData.last.payload
-   ```
-
-1. Check the when the payload was sent:
-
-   ```shell
-   RawUsageData.last.sent_at
-   ```
-
-### Skip database write operations
-
-To skip database write operations, DevOps report creation, and storage of usage data payload, pass an optional argument:
-
-```shell
-skip_db_write:
-GitlabServicePingWorker.new.perform('triggered_from_cron' => false, 'skip_db_write' => true)
-```
-
-## Monitoring
-
-Service Ping reporting process state is monitored with [internal SiSense dashboard](https://app.periscopedata.com/app/gitlab/968489/Product-Intelligence---Service-Ping-Health).
-
-## Related topics
-
-- [Product Intelligence Guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
-- [Snowplow Guide](../snowplow/index.md)
-- [Product Intelligence Direction](https://about.gitlab.com/direction/analytics/product-intelligence/)
-- [Data Analysis Process](https://about.gitlab.com/handbook/business-technology/data-team/#data-analysis-process/)
-- [Data for Product Managers](https://about.gitlab.com/handbook/business-technology/data-team/programs/data-for-product-managers/)
-- [Data Infrastructure](https://about.gitlab.com/handbook/business-technology/data-team/platform/infrastructure/)
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/service_ping/metrics_dictionary.md b/doc/development/service_ping/metrics_dictionary.md
index f36a97bcf6b..fecab4916f5 100644
--- a/doc/development/service_ping/metrics_dictionary.md
+++ b/doc/development/service_ping/metrics_dictionary.md
@@ -1,322 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/service_ping/metrics_dictionary.md'
+remove_date: '2023-08-20'
 ---
 
-# Metrics Dictionary Guide
+This document was moved to [another location](../internal_analytics/service_ping/metrics_dictionary.md).
 
-[Service Ping](index.md) metrics are defined in individual YAML files definitions from which the
-[Metrics Dictionary](https://metrics.gitlab.com/) is built. Currently, the metrics dictionary is built automatically once a day. When a change to a metric is made in a YAML file, you can see the change in the dictionary within 24 hours.
-This guide describes the dictionary and how it's implemented.
-
-## Metrics Definition and validation
-
-We are using [JSON Schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json) to validate the metrics definition.
-
-This process is meant to ensure consistent and valid metrics defined for Service Ping. All metrics *must*:
-
-- Comply with the defined [JSON schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json).
-- Have a unique `key_path` .
-- Have an owner.
-
-All metrics are stored in YAML files:
-
-- [`config/metrics`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/metrics)
-
-WARNING:
-Only metrics with a metric definition YAML and whose status is not `removed` are added to the Service Ping JSON payload.
-
-Each metric is defined in a separate YAML file consisting of a number of fields:
-
-| Field               | Required | Additional information                                         |
-|---------------------|----------|----------------------------------------------------------------|
-| `key_path`          | yes      | JSON key path for the metric, location in Service Ping payload.  |
-| `name`              | no       | Metric name suggestion. Can replace the last part of `key_path`. |
-| `description`       | yes      |                                                                |
-| `product_section`   | yes      | The [section](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/sections.yml). |
-| `product_stage`     | yes       | The [stage](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) for the metric. |
-| `product_group`     | yes      | The [group](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) that owns the metric. |
-| `value_type`        | yes      | `string`; one of [`string`, `number`, `boolean`, `object`](https://json-schema.org/understanding-json-schema/reference/type.html).                                                     |
-| `status`            | yes      | `string`; [status](#metric-statuses) of the metric, may be set to `active`, `removed`, `broken`. |
-| `time_frame`        | yes      | `string`; may be set to a value like `7d`, `28d`, `all`, `none`. |
-| `data_source`       | yes      | `string`; may be set to a value like `database`, `redis`, `redis_hll`, `prometheus`, `system`, `license`. |
-| `data_category`     | yes      | `string`; [categories](#data-category) of the metric, may be set to `operational`, `optional`, `subscription`, `standard`. The default value is `optional`.|
-| `instrumentation_class` | yes   | `string`; [the class that implements the metric](metrics_instrumentation.md).  |
-| `distribution`      | yes      | `array`; may be set to one of `ce, ee` or `ee`. The [distribution](https://about.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/tiers/#definitions) where the tracked feature is available.  |
-| `performance_indicator_type`  | no      | `array`; may be set to one of [`gmau`, `smau`, `paid_gmau`, `umau` or `customer_health_score`](https://about.gitlab.com/handbook/business-technology/data-team/data-catalog/xmau-analysis/). |
-| `tier`              | yes      | `array`; may contain one or a combination of `free`, `premium` or `ultimate`. The [tier](https://about.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/tiers/#definitions) where the tracked feature is available. This should be verbose and contain all tiers where a metric is available. |
-| `milestone`         | yes       | The milestone when the metric is introduced and when it's available to self-managed instances with the official GitLab release. |
-| `milestone_removed` | no       | The milestone when the metric is removed. |
-| `introduced_by_url` | no       | The URL to the merge request that introduced the metric to be available for self-managed instances. |
-| `removed_by_url`    | no       | The URL to the merge request that removed the metric. |
-| `repair_issue_url`  | no       | The URL of the issue that was created to repair a metric with a `broken` status. |
-| `options`           | no       | `object`: options information needed to calculate the metric value. |
-| `skip_validation`   | no       | This should **not** be set. [Used for imported metrics until we review, update and make them valid](https://gitlab.com/groups/gitlab-org/-/epics/5425). |
-
-### Metric `key_path`
-
-The `key_path` of the metric is the location in the JSON Service Ping payload.
-
-The `key_path` could be composed from multiple parts separated by `.` and it must be unique.
-
-We recommend to add the metric in one of the top-level keys:
-
-- `settings`: for settings related metrics.
-- `counts_weekly`: for counters that have data for the most recent 7 days.
-- `counts_monthly`: for counters that have data for the most recent 28 days.
-- `counts`: for counters that have data for all time.
-
-NOTE:
-We can't control what the metric's `key_path` is, because some of them are generated dynamically in `usage_data.rb`.
-For example, see [Redis HLL metrics](implement.md#redis-hll-counters).
-
-### Metric name
-
-To improve metric discoverability by a wider audience, each metric with
-instrumentation added at an appointed `key_path` receives a `name` attribute
-filled with the name suggestion, corresponding to the metric `data_source` and instrumentation.
-Metric name suggestions can contain two types of elements:
-
-1. **User input prompts**: enclosed by angle brackets (`< >`), these pieces should be replaced or
-   removed when you create a metrics YAML file.
-1. **Fixed suggestion**: plaintext parts generated according to well-defined algorithms.
-   They are based on underlying instrumentation, and must not be changed.
-
-For a metric name to be valid, it must not include any prompt, and fixed suggestions
-must not be changed.
-
-#### Generate a metric name suggestion
-
-The metric YAML generator can suggest a metric name for you.
-To generate a metric name suggestion, first instrument the metric at the provided `key_path`.
-Then, generate the metric's YAML definition and
-return to the instrumentation and update it.
-
-1. Add the metric instrumentation class to `lib/gitlab/usage/metrics/instrumentations/`.
-1. Add the metric logic in the instrumentation class.
-1. Run the [metrics YAML generator](metrics_dictionary.md#create-a-new-metric-definition).
-1. Use the metric name suggestion to select a suitable metric name.
-1. Update the metric's YAML definition with the correct `key_path`.
-
-### Metric statuses
-
-Metric definitions can have one of the following statuses:
-
-- `active`: Metric is used and reports data.
-- `broken`: Metric reports broken data (for example, -1 fallback), or does not report data at all. A metric marked as `broken` must also have the `repair_issue_url` attribute.
-- `removed`: Metric was removed, but it may appear in Service Ping payloads sent from instances running on older versions of GitLab.
-
-### Metric `value_type`
-
-Metric definitions can have one of the following values for `value_type`:
-
-- `boolean`
-- `number`
-- `string`
-- `object`: A metric with `value_type: object` must have `value_json_schema` with a link to the JSON schema for the object.
-In general, we avoid complex objects and prefer one of the `boolean`, `number`, or `string` value types.
-An example of a metric that uses `value_type: object` is `topology` (`/config/metrics/settings/20210323120839_topology.yml`),
-which has a related schema in `/config/metrics/objects_schemas/topology_schema.json`.
-
-### Metric `time_frame`
-
-A metric's time frame is calculated based on the `time_frame` field and the `data_source` of the metric.
-For `redis_hll` metrics, the type of aggregation is also taken into consideration. In this context, the term "aggregation" refers to [chosen events data storage interval](implement.md#add-new-events), and is **NOT** related to the Aggregated Metrics feature.
-For more information about the aggregation type of each feature, see the [`common.yml` file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/common.yml). Weeks run from Monday to Sunday.
-
-| data_source            | time_frame | aggregation    | Description                                     |
-|------------------------|------------|----------------|-------------------------------------------------|
-| any                    | `none`     | not applicable | A type of data that’s not tracked over time, such as settings and configuration information |
-| `database`             | `all`      | not applicable | The whole time the metric has been active (all-time interval) |
-| `database`             | `7d`       | not applicable | 9 days ago to 2 days ago |
-| `database`             | `28d`      | not applicable | 30 days ago to 2 days ago |
-| `redis`                | `all`      | not applicable | The whole time the metric has been active (all-time interval) |
-| `redis_hll`            | `7d`       | `daily`        | Most recent 7 complete days |
-| `redis_hll`            | `7d`       | `weekly`       | Most recent complete week |
-| `redis_hll`            | `28d`      | `daily`        | Most recent 28 complete days |
-| `redis_hll`            | `28d`      | `weekly`       | Most recent 4 complete weeks |
-
-### Data category
-
-We use the following categories to classify a metric:
-
-- `operational`: Required data for operational purposes.
-- `optional`: Default value for a metric. Data that is optional to collect. This can be [enabled or disabled](../../user/admin_area/settings/usage_statistics.md#enable-or-disable-usage-statistics) in the Admin Area.
-- `subscription`: Data related to licensing.
-- `standard`: Standard set of identifiers that are included when collecting data.
-
-An aggregate metric is a metric that is the sum of two or more child metrics. Service Ping uses the data category of
-the aggregate metric to determine whether or not the data is included in the reported Service Ping payload.
-
-### Metric name suggestion examples
-
-#### Metric with `data_source: database`
-
-For a metric instrumented with SQL:
-
-```sql
-SELECT COUNT(DISTINCT user_id) FROM clusters WHERE clusters.management_project_id IS NOT NULL
-```
-
-- **Suggested name**: `count_distinct_user_id_from_<adjective describing: '(clusters.management_project_id IS NOT NULL)'>_clusters`
-- **Prompt**: `<adjective describing: '(clusters.management_project_id IS NOT NULL)'>`
-  should be replaced with an adjective that best represents filter conditions, such as `project_management`
-- **Final metric name**: For example, `count_distinct_user_id_from_project_management_clusters`
-
-For metric instrumented with SQL:
-
-```sql
-SELECT COUNT(DISTINCT clusters.user_id)
-FROM clusters_applications_helm
-INNER JOIN clusters ON clusters.id = clusters_applications_helm.cluster_id
-WHERE clusters_applications_helm.status IN (3, 5)
-```
-
-- **Suggested name**: `count_distinct_user_id_from_<adjective describing: '(clusters_applications_helm.status IN (3, 5))'>_clusters_<with>_<adjective describing: '(clusters_applications_helm.status IN (3, 5))'>_clusters_applications_helm`
-- **Prompt**: `<adjective describing: '(clusters_applications_helm.status IN (3, 5))'>`
-  should be replaced with an adjective that best represents filter conditions
-- **Final metric name**: `count_distinct_user_id_from_clusters_with_available_clusters_applications_helm`
-
-In the previous example, the prompt is irrelevant, and user can remove it. The second
-occurrence corresponds with the `available` scope defined in `Clusters::Concerns::ApplicationStatus`.
-It can be used as the right adjective to replace prompt.
-
-The `<with>` represents a suggested conjunction for the suggested name of the joined relation.
-The person documenting the metric can use it by either:
-
-- Removing the surrounding `<>`.
-- Using a different conjunction, such as `having` or `including`.
-
-#### Metric with `data_source: redis` or `redis_hll`
-
-For metrics instrumented with a Redis-based counter, the suggested name includes
-only the single prompt to be replaced by the person working with metrics YAML.
-
-- **Prompt**: `<please fill metric name, suggested format is: {subject}_{verb}{ing|ed}_{object} eg: users_creating_epics or merge_requests_viewed_in_single_file_mode>`
-- **Final metric name**: We suggest the metric name should follow the format of
-  `{subject}_{verb}{ing|ed}_{object}`, such as `user_creating_epics`, `users_triggering_security_scans`,
-  or `merge_requests_viewed_in_single_file_mode`
-
-#### Metric with `data_source: prometheus` or `system`
-
-For metrics instrumented with Prometheus or coming from the operating system,
-the suggested name includes only the single prompt by person working with metrics YAML.
-
-- **Prompt**: `<please fill metric name>`
-- **Final metric name**: Due to the variety of cases that can apply to this kind of metric,
-  no naming convention exists. Each person instrumenting a metric should use their
-  best judgment to come up with a descriptive name.
-
-### Example YAML metric definition
-
-The linked [`uuid`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/license/uuid.yml)
-YAML file includes an example metric definition, where the `uuid` metric is the GitLab
-instance unique identifier.
-
-```yaml
-key_path: uuid
-description: GitLab instance unique identifier
-product_section: analytics
-product_stage: analytics
-product_group: product_intelligence
-value_type: string
-status: active
-milestone: 9.1
-instrumentation_class: UuidMetric
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1521
-time_frame: none
-data_source: database
-distribution:
-- ce
-- ee
-tier:
-- free
-- premium
-- ultimate
-```
-
-### Create a new metric definition
-
-The GitLab codebase provides a dedicated [generator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_definition_generator.rb) to create new metric definitions.
-
-For uniqueness, the generated files include a timestamp prefix in ISO 8601 format.
-
-The generator takes a list of key paths and 3 options as arguments. It creates metric YAML definitions in the corresponding location:
-
-- `--ee`, `--no-ee` Indicates if metric is for EE.
-- `--dir=DIR` Indicates the metric directory. It must be one of: `counts_7d`, `7d`, `counts_28d`, `28d`, `counts_all`, `all`, `settings`, `license`.
-- `--class_name=CLASS_NAME` Indicates the instrumentation class. For example `UsersCreatingIssuesMetric`, `UuidMetric`
-
-**Single metric example**
-
-```shell
-bundle exec rails generate gitlab:usage_metric_definition counts.issues --dir=7d --class_name=CountIssues
-// Creates 1 file
-// create  config/metrics/counts_7d/issues.yml
-```
-
-**Multiple metrics example**
-
-```shell
-bundle exec rails generate gitlab:usage_metric_definition counts.issues counts.users --dir=7d --class_name=CountUsersCreatingIssues
-// Creates 2 files
-// create  config/metrics/counts_7d/issues.yml
-// create  config/metrics/counts_7d/users.yml
-```
-
-NOTE:
-To create a metric definition used in EE, add the `--ee` flag.
-
-```shell
-bundle exec rails generate gitlab:usage_metric_definition counts.issues --ee --dir=7d --class_name=CountUsersCreatingIssues
-// Creates 1 file
-// create  ee/config/metrics/counts_7d/issues.yml
-```
-
-### Metrics added dynamic to Service Ping payload
-
-The [Redis HLL metrics](implement.md#known-events-are-added-automatically-in-service-data-payload) are added automatically to Service Ping payload.
-
-A YAML metric definition is required for each metric. A dedicated generator is provided to create metric definitions for Redis HLL events.
-
-The generator takes `category` and `events` arguments, as the root key is `redis_hll_counters`, and creates two metric definitions for each of the events (for weekly and monthly time frames):
-
-**Single metric example**
-
-```shell
-bundle exec rails generate gitlab:usage_metric_definition:redis_hll issues count_users_closing_issues
-// Creates 2 files
-// create  config/metrics/counts_7d/count_users_closing_issues_weekly.yml
-// create  config/metrics/counts_28d/count_users_closing_issues_monthly.yml
-```
-
-**Multiple metrics example**
-
-```shell
-bundle exec rails generate gitlab:usage_metric_definition:redis_hll issues count_users_closing_issues count_users_reopening_issues
-// Creates 4 files
-// create  config/metrics/counts_7d/count_users_closing_issues_weekly.yml
-// create  config/metrics/counts_28d/count_users_closing_issues_monthly.yml
-// create  config/metrics/counts_7d/count_users_reopening_issues_weekly.yml
-// create  config/metrics/counts_28d/count_users_reopening_issues_monthly.yml
-```
-
-To create a metric definition used in EE, add the `--ee` flag.
-
-```shell
-bundle exec rails generate gitlab:usage_metric_definition:redis_hll issues users_closing_issues --ee
-// Creates 2 files
-// create  config/metrics/counts_7d/i_closed_weekly.yml
-// create  config/metrics/counts_28d/i_closed_monthly.yml
-```
-
-## Metrics Dictionary
-
-[Metrics Dictionary is a separate application](https://gitlab.com/gitlab-org/analytics-section/product-intelligence/metric-dictionary).
-
-All metrics available in Service Ping are in the [Metrics Dictionary](https://metrics.gitlab.com/).
-
-### Copy query to clipboard
-
-To check if a metric has data in Sisense, use the copy query to clipboard feature. This copies a query that's ready to use in Sisense. The query gets the last five service ping data for GitLab.com for a given metric. For information about how to check if a Service Ping metric has data in Sisense, see this [demo](https://www.youtube.com/watch?v=n4o65ivta48).
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/service_ping/metrics_instrumentation.md b/doc/development/service_ping/metrics_instrumentation.md
index 7441a2d1bd4..5a4dfc325e2 100644
--- a/doc/development/service_ping/metrics_instrumentation.md
+++ b/doc/development/service_ping/metrics_instrumentation.md
@@ -1,478 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/service_ping/metrics_instrumentation.md'
+remove_date: '2023-08-20'
 ---
 
-# Metrics instrumentation guide
+This document was moved to [another location](../internal_analytics/service_ping/metrics_instrumentation.md).
 
-This guide describes how to develop Service Ping metrics using metrics instrumentation.
-
-<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For a video tutorial, see the [Adding Service Ping metric via instrumentation class](https://youtu.be/p2ivXhNxUoY).
-
-## Nomenclature
-
-- **Instrumentation class**:
-  - Inherits one of the metric classes: `DatabaseMetric`, `RedisMetric`, `RedisHLLMetric`, `NumbersMetric` or `GenericMetric`.
-  - Implements the logic that calculates the value for a Service Ping metric.
-
-- **Metric definition**
-  The Service Data metric YAML definition.
-
-- **Hardening**:
-  Hardening a method is the process that ensures the method fails safe, returning a fallback value like -1.
-
-## How it works
-
-A metric definition has the [`instrumentation_class`](metrics_dictionary.md) field, which can be set to a class.
-
-The defined instrumentation class should inherit one of the existing metric classes: `DatabaseMetric`, `RedisMetric`, `RedisHLLMetric`, `NumbersMetric` or `GenericMetric`.
-
-The current convention is that a single instrumentation class corresponds to a single metric. On rare occasions, there are exceptions to that convention like [Redis metrics](#redis-metrics). To use a single instrumentation class for more than one metric, please reach out to one of the `@gitlab-org/analytics-section/product-intelligence/engineers` members to consult about your case.
-
-Using the instrumentation classes ensures that metrics can fail safe individually, without breaking the entire
- process of Service Ping generation.
-
-We have built a domain-specific language (DSL) to define the metrics instrumentation.
-
-## Database metrics
-
-You can use database metrics to track data kept in the database, for example, a count of issues that exist on a given instance.
-
-- `operation`: Operations for the given `relation`, one of `count`, `distinct_count`, `sum`, and `average`.
-- `relation`: Assigns lambda that returns the `ActiveRecord::Relation` for the objects we want to perform the `operation`. The assigned lambda can accept up to one parameter. The parameter is hashed and stored under the `options` key in the metric definition.
-- `start`: Specifies the start value of the batch counting, by default is `relation.minimum(:id)`.
-- `finish`: Specifies the end value of the batch counting, by default is `relation.maximum(:id)`.
-- `cache_start_and_finish_as`: Specifies the cache key for `start` and `finish` values and sets up caching them. Use this call when `start` and `finish` are expensive queries that should be reused between different metric calculations.
-- `available?`: Specifies whether the metric should be reported. The default is `true`.
-- `timestamp_column`: Optionally specifies timestamp column for metric used to filter records for time constrained metrics. The default is `created_at`.
-
-[Example of a merge request that adds a database metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60022).
-
-```ruby
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-        class CountIssuesMetric < DatabaseMetric
-          operation :count
-
-          relation ->(options) { Issue.where(confidential: options[:confidential]) }
-        end
-      end
-    end
-  end
-end
-```
-
-### Ordinary batch counters Example
-
-```ruby
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-        class CountIssuesMetric < DatabaseMetric
-          operation :count
-
-          start { Issue.minimum(:id) }
-          finish { Issue.maximum(:id) }
-
-          relation { Issue }
-        end
-      end
-    end
-  end
-end
-```
-
-### Distinct batch counters Example
-
-```ruby
-# frozen_string_literal: true
-
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-        class CountUsersAssociatingMilestonesToReleasesMetric < DatabaseMetric
-          operation :distinct_count, column: :author_id
-
-          relation { Release.with_milestones }
-
-          start { Release.minimum(:author_id) }
-          finish { Release.maximum(:author_id) }
-        end
-      end
-    end
-  end
-end
-```
-
-### Sum Example
-
-```ruby
-# frozen_string_literal: true
-
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-        class JiraImportsTotalImportedIssuesCountMetric < DatabaseMetric
-          operation :sum, column: :imported_issues_count
-
-          relation { JiraImportState.finished }
-        end
-      end
-    end
-  end
-end
-```
-
-### Average Example
-
-```ruby
-# frozen_string_literal: true
-
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-        class CountIssuesWeightAverageMetric < DatabaseMetric
-          operation :average, column: :weight
-
-          relation { Issue }
-        end
-      end
-    end
-  end
-end
-```
-
-## Redis metrics
-
-You can use Redis metrics to track events not kept in the database, for example, a count of how many times the search bar has been used.
-
-[Example of a merge request that adds `Redis` metrics](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/103455).
-
-The `RedisMetric` class can only be used as the `instrumentation_class` for Redis metrics with simple counters classes (classes that only inherit `BaseCounter` and set `PREFIX` and `KNOWN_EVENTS` constants). In case the counter class has additional logic included in it, a new `instrumentation_class`, inheriting from `RedisMetric`, needs to be created. This new class needs to include the additional logic from the counter class.
-
-Required options:
-
-- `event`: the event name.
-- `prefix`: the value of the `PREFIX` constant used in the counter classes from the `Gitlab::UsageDataCounters` namespace.
-
-Count unique values for `source_code_pushes` event.
-
-```yaml
-time_frame: all
-data_source: redis
-instrumentation_class: RedisMetric
-options:
-  event: pushes
-  prefix: source_code
-```
-
-### Availability-restrained Redis metrics
-
-If the Redis metric should only be available in the report under some conditions, then you must specify these conditions in a new class that is a child of the `RedisMetric` class.
-
-```ruby
-# frozen_string_literal: true
-
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-        class MergeUsageCountRedisMetric < RedisMetric
-          available? { Feature.enabled?(:merge_usage_data_missing_key_paths) }
-        end
-      end
-    end
-  end
-end
-```
-
-You must also use the class's name in the YAML setup.
-
-```yaml
-time_frame: all
-data_source: redis
-instrumentation_class: MergeUsageCountRedisMetric
-options:
-  event: pushes
-  prefix: source_code
-```
-
-## Redis HyperLogLog metrics
-
-You can use Redis HyperLogLog metrics to track events not kept in the database and incremented for unique values such as unique users,
-for example, a count of how many different users used the search bar.
-
-[Example of a merge request that adds a `RedisHLL` metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61685).
-
-Count unique values for `i_quickactions_approve` event.
-
-```yaml
-time_frame: 28d
-data_source: redis_hll
-instrumentation_class: RedisHLLMetric
-options:
-  events:
-    - i_quickactions_approve
-```
-
-### Availability-restrained Redis HyperLogLog metrics
-
-If the Redis HyperLogLog metric should only be available in the report under some conditions, then you must specify these conditions in a new class that is a child of the `RedisHLLMetric` class.
-
-```ruby
-# frozen_string_literal: true
-
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-        class MergeUsageCountRedisHLLMetric < RedisHLLMetric
-          available? { Feature.enabled?(:merge_usage_data_missing_key_paths) }
-        end
-      end
-    end
-  end
-end
-```
-
-You must also use the class's name in the YAML setup.
-
-```yaml
-time_frame: 28d
-data_source: redis_hll
-instrumentation_class: MergeUsageCountRedisHLLMetric
-options:
-  events:
-    - i_quickactions_approve
-```
-
-## Aggregated metrics
-
-<div class="video-fallback">
-  See the video from: <a href="https://www.youtube.com/watch?v=22LbYqHwtUQ">Product Intelligence Office Hours Oct 6th</a> for an aggregated metrics walk-through.
-</div>
-<figure class="video-container">
-  <iframe src="https://www.youtube-nocookie.com/embed/22LbYqHwtUQ" frameborder="0" allowfullscreen> </iframe>
-</figure>
-
-The aggregated metrics feature provides insight into the number of data attributes, for example `pseudonymized_user_ids`, that occurred in a collection of events. For example, you can aggregate the number of users who perform multiple actions such as creating a new issue and opening
-a new merge request.
-
-You can use a YAML file to define your aggregated metrics. The following arguments are required:
-
-- `options.events`: List of event names to aggregate into metric data. All events in this list must
-  use the same data source. Additional data source requirements are described in
-  [Database sourced aggregated metrics](implement.md#database-sourced-aggregated-metrics) and
-  [Redis sourced aggregated metrics](implement.md#redis-sourced-aggregated-metrics).
-- `options.aggregate.operator`: Operator that defines how the aggregated metric data is counted. Available operators are:
-  - `OR`: Removes duplicates and counts all entries that triggered any of the listed events.
-  - `AND`: Removes duplicates and counts all elements that were observed triggering all of the following events.
-- `options.aggregate.attribute`: Information pointing to the attribute that is being aggregated across events.
-- `time_frame`: One or more valid time frames. Use these to limit the data included in aggregated metrics to events within a specific date-range. Valid time frames are:
-  - `7d`: The last 7 days of data.
-  - `28d`: The last 28 days of data.
-  - `all`: All historical data, only available for `database` sourced aggregated metrics.
-- `data_source`: Data source used to collect all events data included in the aggregated metrics. Valid data sources are:
-  - [`database`](implement.md#database-sourced-aggregated-metrics)
-  - [`redis_hll`](implement.md#redis-sourced-aggregated-metrics)
-
-Refer to merge request [98206](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98206) for an example of a merge request that adds an `AggregatedMetric` metric.
-
-Count unique `user_ids` that occurred in at least one of the events: `incident_management_alert_status_changed`,
-`incident_management_alert_assigned`, `incident_management_alert_todo`, `incident_management_alert_create_incident`.
-
-```yaml
-time_frame: 28d
-instrumentation_class: AggregatedMetric
-data_source: redis_hll
-options:
-    aggregate:
-        operator: OR
-        attribute: user_id
-    events:
-        - `incident_management_alert_status_changed`
-        - `incident_management_alert_assigned`
-        - `incident_management_alert_todo`
-        - `incident_management_alert_create_incident`
-```
-
-### Availability-restrained Aggregated metrics
-
-If the Aggregated metric should only be available in the report under specific conditions, then you must specify these conditions in a new class that is a child of the `AggregatedMetric` class.
-
-```ruby
-# frozen_string_literal: true
-
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-        class MergeUsageCountAggregatedMetric < AggregatedMetric
-          available? { Feature.enabled?(:merge_usage_data_missing_key_paths) }
-        end
-      end
-    end
-  end
-end
-```
-
-You must also use the class's name in the YAML setup.
-
-```yaml
-time_frame: 28d
-instrumentation_class: MergeUsageCountAggregatedMetric
-data_source: redis_hll
-options:
-    aggregate:
-        operator: OR
-        attribute: user_id
-    events:
-        - `incident_management_alert_status_changed`
-        - `incident_management_alert_assigned`
-        - `incident_management_alert_todo`
-        - `incident_management_alert_create_incident`
-```
-
-## Numbers metrics
-
-- `operation`: Operations for the given `data` block. Currently we only support `add` operation.
-- `data`: a `block` which contains an array of numbers.
-- `available?`: Specifies whether the metric should be reported. The default is `true`.
-
-```ruby
-# frozen_string_literal: true
-
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-          class IssuesBoardsCountMetric < NumbersMetric
-            operation :add
-
-            data do |time_frame|
-              [
-                 CountIssuesMetric.new(time_frame: time_frame).value,
-                 CountBoardsMetric.new(time_frame: time_frame).value
-              ]
-            end
-          end
-        end
-      end
-    end
-  end
-end
-```
-
-You must also include the instrumentation class name in the YAML setup.
-
-```yaml
-time_frame: 28d
-instrumentation_class: IssuesBoardsCountMetric
-```
-
-## Generic metrics
-
-You can use generic metrics for other metrics, for example, an instance's database version. Observations type of data will always have a Generic metric counter type.
-
-- `value`: Specifies the value of the metric.
-- `available?`: Specifies whether the metric should be reported. The default is `true`.
-
-[Example of a merge request that adds a generic metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60256).
-
-```ruby
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-        class UuidMetric < GenericMetric
-          value do
-            Gitlab::CurrentSettings.uuid
-          end
-        end
-      end
-    end
-  end
-end
-```
-
-## Support for instrumentation classes
-
-There is support for:
-
-- `count`, `distinct_count`, `estimate_batch_distinct_count`, `sum`, and `average` for [database metrics](#database-metrics).
-- [Redis metrics](#redis-metrics).
-- [Redis HLL metrics](#redis-hyperloglog-metrics).
-- `add` for [numbers metrics](#numbers-metrics).
-- [Generic metrics](#generic-metrics), which are metrics based on settings or configurations.
-
-There is no support for:
-
-- `add`, `histogram` for database metrics.
-
-You can [track the progress to support these](https://gitlab.com/groups/gitlab-org/-/epics/6118).
-
-## Create a new metric instrumentation class
-
-To create a stub instrumentation for a Service Ping metric, you can use a dedicated [generator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_generator.rb):
-
-The generator takes the class name as an argument and the following options:
-
-- `--type=TYPE` Required. Indicates the metric type. It must be one of: `database`, `generic`, `redis`, `numbers`.
-- `--operation` Required for `database` & `numbers` type.
-  - For `database` it must be one of: `count`, `distinct_count`, `estimate_batch_distinct_count`, `sum`, `average`.
-  - For `numbers` it must be: `add`.
-- `--ee` Indicates if the metric is for EE.
-
-```shell
-rails generate gitlab:usage_metric CountIssues --type database --operation distinct_count
-        create lib/gitlab/usage/metrics/instrumentations/count_issues_metric.rb
-        create spec/lib/gitlab/usage/metrics/instrumentations/count_issues_metric_spec.rb
-```
-
-## Migrate Service Ping metrics to instrumentation classes
-
-This guide describes how to migrate a Service Ping metric from [`lib/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb) or [`ee/lib/ee/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/usage_data.rb) to instrumentation classes.
-
-1. Choose the metric type:
-
-- [Database metric](#database-metrics)
-- [Redis HyperLogLog metrics](#redis-hyperloglog-metrics)
-- [Redis metric](#redis-metrics)
-- [Numbers metric](#numbers-metrics)
-- [Generic metric](#generic-metrics)
-
-1. Determine the location of instrumentation class: either under `ee` or outside `ee`.
-
-1. [Generate the instrumentation class file](#create-a-new-metric-instrumentation-class).
-
-1. Fill the instrumentation class body:
-
-   - Add code logic for the metric. This might be similar to the metric implementation in `usage_data.rb`.
-   - Add tests for the individual metric [`spec/lib/gitlab/usage/metrics/instrumentations/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/usage/metrics/instrumentations).
-   - Add tests for Service Ping.
-
-1. [Generate the metric definition file](metrics_dictionary.md#create-a-new-metric-definition).
-
-1. Remove the code from [`lib/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb) or [`ee/lib/ee/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/usage_data.rb).
-
-1. Remove the tests from [`spec/lib/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/lib/gitlab/usage_data_spec.rb) or [`ee/spec/lib/ee/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/spec/lib/ee/gitlab/usage_data_spec.rb).
-
-## Troubleshoot metrics
-
-Sometimes metrics fail for reasons that are not immediately clear. The failures can be related to performance issues or other problems.
-The following pairing session video gives you an example of an investigation in to a real-world failing metric.
-
-<div class="video-fallback">
-  See the video from: <a href="https://www.youtube.com/watch?v=y_6m2POx2ug">Product Intelligence Office Hours Oct 27th</a> to learn more about the metrics troubleshooting process.
-</div>
-<figure class="video-container">
-  <iframe src="https://www.youtube-nocookie.com/embed/y_6m2POx2ug" frameborder="0" allowfullscreen> </iframe>
-</figure>
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/service_ping/metrics_lifecycle.md b/doc/development/service_ping/metrics_lifecycle.md
index 318db6895fb..520b18139ff 100644
--- a/doc/development/service_ping/metrics_lifecycle.md
+++ b/doc/development/service_ping/metrics_lifecycle.md
@@ -1,106 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/service_ping/metrics_lifecycle.md'
+remove_date: '2023-08-20'
 ---
 
-# Service Ping metric lifecycle
+This document was moved to [another location](../internal_analytics/service_ping/metrics_lifecycle.md).
 
-The following guidelines explain the steps to follow at each stage of a metric's lifecycle.
-
-## Add a new metric
-
-Follow the [Implement Service Ping](implement.md) guide.
-
-## Change an existing metric
-
-WARNING:
-We want to **PREVENT** changes to the calculation logic or important attributes on any metric as this invalidates comparisons of the same metric across different versions of GitLab.
-
-If you change a metric, you have to consider that not all instances of GitLab are running on the newest version. Old instances will still report the old version of the metric.
-Additionally, a metric's reported numbers are primarily interesting compared to previously reported numbers.
-As a result, if you need to change one of the following parts of a metric, you need to add a new metric instead. It's your choice whether to keep the old metric alongside the new one or [remove it](#remove-a-metric).
-
-- **calculation logic**: This means any changes that can produce a different value than the previous implementation
-- **YAML attributes**: The following attributes are directly used for analysis or calculation: `key_path`, `time_frame`, `value_type`, `data_source`.
-
-If you change the `performance_indicator_type` attribute of a metric or think your case needs an exception from the outlined rules then please notify the Customer Success Ops team (`@csops-team`), Analytics Engineers (`@gitlab-data/analytics-engineers`), and Product Analysts (`@gitlab-data/product-analysts`) teams by `@` mentioning those groups in a comment on the merge request or issue.
-
-You can change any other attributes without impact to the calculation or analysis. See [this video tutorial](https://youtu.be/bYf3c01KCls) for help updating metric attributes.
-
-Currently, the [Metrics Dictionary](https://metrics.gitlab.com/) is built automatically once a day. You can see the change in the dictionary within 24 hours when you change the metric's YAML file.
-
-## Remove a metric
-
-WARNING:
-If a metric is not used in Sisense or any other system after 6 months, the
-Product Intelligence team marks it as inactive and assigns it to the group owner for review.
-
-We are working on automating this process. See [this epic](https://gitlab.com/groups/gitlab-org/-/epics/8988) for details.
-
-Product Intelligence removes metrics from Service Ping if they are not used in any Sisense dashboard.
-
-For an example of the metric removal process, see this [example issue](https://gitlab.com/gitlab-org/gitlab/-/issues/388236).
-
-To remove a metric:
-
-1. Create an issue for removing the metric if none exists yet. The issue needs to outline why the metric should be deleted. You can use this issue to document the removal process.
-
-1. Verify the metric is not used to calculate the conversational index. The
-   conversational index is a measure that reports back to self-managed instances
-   to inform administrators of the progress of DevOps adoption for the instance.
-
-   You can check
-   [`CalculateConvIndexService`](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/app/services/calculate_conv_index_service.rb)
-   to view the metrics that are used. The metrics are represented
-   as the keys that are passed as a field argument into the `get_value` method.
-
-1. Verify that removing the metric from the Service Ping payload does not cause
-   errors in [Version App](https://gitlab.com/gitlab-services/version-gitlab-com)
-   when the updated payload is collected and processed. Version App collects
-   and persists all Service Ping reports. To verify Service Ping processing in your local development environment, follow this [guide](https://www.youtube.com/watch?v=FS5emplabRU).
-   Alternatively, you can modify [fixtures](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/spec/support/usage_data_helpers.rb#L540)
-   used to test the [`UsageDataController#create`](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/3760ef28/spec/controllers/usage_data_controller_spec.rb#L75)
-   endpoint, and assure that test suite does not fail when metric that you wish to remove is not included into test payload.
-
-1. Remove data from Redis
-
-   For [Ordinary Redis](implement.md#ordinary-redis-counters) counters remove data stored in Redis.
-
-   - Add a migration to remove the data from Redis for the related Redis keys. For more details, see [this MR example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82604/diffs).
-
-1. Create an issue in the
-   [GitLab Data Team project](https://gitlab.com/gitlab-data/analytics/-/issues).
-   Ask for confirmation that the metric is not referred to in any SiSense dashboards and
-   can be safely removed from Service Ping. Use this
-   [example issue](https://gitlab.com/gitlab-data/analytics/-/issues/15266) for guidance.
-
-1. Notify the Customer Success Ops team (`@csops-team`), Analytics Engineers (`@gitlab-data/analytics-engineers`), and Product Analysts (`@gitlab-data/product-analysts`) by `@` mentioning those groups in a comment in the issue from step 1 regarding the deletion of the metric.
-   Many Service Ping metrics are relied upon for health score and XMAU reporting and unexpected changes to those metrics could break reporting.
-
-1. After you verify the metric can be safely removed,
-   update the attributes of the metric's YAML definition:
-
-   - Set the `status:` to `removed`.
-   - Set `removed_by_url:` to the URL of the MR removing the metric
-   - Set `milestone_removed:` to the number of the
-     milestone in which the metric was removed.
-
-   Do not remove the metric's YAML definition altogether. Some self-managed
-   instances might not immediately update to the latest version of GitLab, and
-   therefore continue to report the removed metric. The Product Intelligence team
-   requires a record of all removed metrics to identify and filter them.
-
-   For example please take a look at this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60149/diffs#b01f429a54843feb22265100c0e4fec1b7da1240_10_10).
-
-1. After you verify the metric can be safely removed,
-   remove the metric's instrumentation from
-   [`lib/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb)
-   or
-   [`ee/lib/ee/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/usage_data.rb).
-
-   For example please take a look at this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60149/diffs#6335dc533bd21df26db9de90a02dd66278c2390d_167_167).
-
-1. Remove any other records related to the metric:
-   - The feature flag YAML file at [`config/feature_flags/*/*.yaml`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/feature_flags).
-   - The entry in the known events YAML file at [`lib/gitlab/usage_data_counters/known_events/*.yaml`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/usage_data_counters/known_events).
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/service_ping/performance_indicator_metrics.md b/doc/development/service_ping/performance_indicator_metrics.md
index 0ca663ce09a..eda7224732d 100644
--- a/doc/development/service_ping/performance_indicator_metrics.md
+++ b/doc/development/service_ping/performance_indicator_metrics.md
@@ -1,16 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/service_ping/performance_indicator_metrics.md'
+remove_date: '2023-08-20'
 ---
 
-# Performance Indicator Metrics guide
+This document was moved to [another location](../internal_analytics/service_ping/performance_indicator_metrics.md).
 
-This guide describes how to use metrics definitions to define [performance indicator](https://about.gitlab.com/handbook/product/product-intelligence-guide/#implementing-product-performance-indicators) metrics.
-
-To use a metric definition to manage a performance indicator:
-
-1. Create a merge request that includes related changes.
-1. Use labels `~"product intelligence"`, `"~Data Warehouse::Impact Check"`.
-1. Update the metric definition `performance_indicator_type` [field](metrics_dictionary.md#metrics-definition-and-validation).
-1. Create an issue in GitLab Product Data Insights project with the [PI Chart Help template](https://gitlab.com/gitlab-data/product-analytics/-/issues/new?issuable_template=PI%20Chart%20Help) to have the new metric visualized.
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/service_ping/review_guidelines.md b/doc/development/service_ping/review_guidelines.md
index 8128f1e371b..d5805f615e2 100644
--- a/doc/development/service_ping/review_guidelines.md
+++ b/doc/development/service_ping/review_guidelines.md
@@ -1,82 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/service_ping/review_guidelines.md'
+remove_date: '2023-08-20'
 ---
 
-# Service Ping review guidelines
+This document was moved to [another location](../internal_analytics/service_ping/review_guidelines.md).
 
-This page includes introductory material for a
-[Analytics Instrumentation](https://about.gitlab.com/handbook/engineering/development/analytics/analytics-instrumentation/)
-review, and is specific to Service Ping related reviews. For broader advice and
-general best practices for code reviews, refer to our [code review guide](../code_review.md).
-
-## Resources for reviewers
-
-- [Service Ping Guide](index.md)
-- [Metrics Dictionary](https://metrics.gitlab.com/)
-
-## Review process
-
-We recommend a Analytics Instrumentation review when a merge request (MR) touches
-any of the following Service Ping files:
-
-- `usage_data*` files.
-- The Metrics Dictionary, including files in:
-  - [`config/metrics`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/metrics).
-  - [`ee/config/metrics`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/config/metrics).
-  - [`schema.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json).
-- Analytics Instrumentation tooling. For example,
-  [`Gitlab::UsageMetricDefinitionGenerator`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_definition_generator.rb)
-
-### Roles and process
-
-#### The merge request **author** should
-
-- Decide whether a Analytics Instrumentation review is needed. You can skip the Analytics Instrumentation
-review and remove the labels if the changes are not related to the Analytics Instrumentation domain and
-are regular backend changes.
-- If a Analytics Instrumentation review is needed, add the labels
-  `~analytics instrumentation` and `~analytics instrumentation::review pending`.
-- For merge requests authored by Analytics Instrumentation team members:
-  - Assign both the `~backend` and `~analytics instrumentation` reviews to another Analytics Instrumentation team member.
-  - Assign the maintainer review to someone outside of the Analytics Instrumentation group.
-- Assign an
-  [engineer](https://gitlab.com/groups/gitlab-org/analytics-section/product-intelligence/engineers/-/group_members?with_inherited_permissions=exclude) from the Analytics Instrumentation team for a review.
-- Set the correct attributes in the metric's YAML definition:
-  - `product_section`, `product_stage`, `product_group`
-  - Provide a clear description of the metric.
-- Add a changelog [according to guidelines](../changelog.md).
-
-#### The Analytics Instrumentation **reviewer** should
-
-- Perform a first-pass review on the merge request and suggest improvements to the author.
-- Check the [metrics location](metrics_dictionary.md#metric-key_path) in
-  the Service Ping JSON payload.
-- Suggest that the author checks the [naming suggestion](metrics_dictionary.md#generate-a-metric-name-suggestion) while
-  generating the metric's YAML definition.
-- Add the `~database` label and ask for a [database review](../database_review.md) for
-  metrics that are based on Database.
-- Add `~Data Warehouse::Impact Check` for any database metric that has a query change. Changes in queries can affect [data operations](https://about.gitlab.com/handbook/business-technology/data-team/how-we-work/triage/#gitlabcom-db-structure-changes).
-- For tracking using Redis HLL (HyperLogLog):
-  - Check if a [feature flag is needed](implement.md#recommendations).
-- For a metric's YAML definition:
-  - Check the metric's `description`.
-  - Check the metric's `key_path`.
-  - Check the `product_section`, `product_stage`, and `product_group` fields.
-    Read the [stages file](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml).
-  - Check the file location. Consider the time frame, and if the file should be under `ee`.
-  - Check the tiers.
-- If a metric was changed or removed: Make sure the MR author notified the Customer Success Ops team (`@csops-team`), Analytics Engineers (`@gitlab-data/analytics-engineers`), and Product Analysts (`@gitlab-data/product-analysts`) by `@` mentioning those groups in a comment on the issue for the MR and all of these groups have acknowledged the removal.
-- Metrics instrumentations
-  - Recommend using metrics instrumentation for new metrics, [if possible](metrics_instrumentation.md#support-for-instrumentation-classes).
-- Approve the MR, and relabel the MR with `~"analytics instrumentation::approved"`.
-
-## Review workload distribution
-
-[Danger bot](../dangerbot.md) adds the list of changed Analytics Instrumentation files
-and pings the
-[`@gitlab-org/analytics-section/product-intelligence/engineers`](https://gitlab.com/groups/gitlab-org/analytics-section/product-intelligence/engineers/-/group_members?with_inherited_permissions=exclude) group for merge requests
-that are not drafts.
-
-Any of the Analytics Instrumentation engineers can be assigned for the Analytics Instrumentation review.
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/service_ping/troubleshooting.md b/doc/development/service_ping/troubleshooting.md
index 1b896efb726..31b04c1a6bc 100644
--- a/doc/development/service_ping/troubleshooting.md
+++ b/doc/development/service_ping/troubleshooting.md
@@ -1,164 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/service_ping/troubleshooting.md'
+remove_date: '2023-08-20'
 ---
 
-# Troubleshooting Service Ping
+This document was moved to [another location](../internal_analytics/service_ping/troubleshooting.md).
 
-## Service Ping Payload drop
-
-### Symptoms
-
-You will be alerted by a [Sisense alert](https://app.periscopedata.com/app/gitlab/alert/Service-ping-payload-drop-Alert/5a5b8766b8af43b4a75d6e9c684a365f/edit) that is sent to `#g_product_intelligence` Slack channel
-
-### Locating the problem
-
-First you need to identify at which stage in Service Ping data pipeline the drop is occurring.
-
-Start at [Service Ping Health Dashboard](https://app.periscopedata.com/app/gitlab/968489/Product-Intelligence---Service-Ping-Health) on Sisense.
-
-The alert compares the current daily value with the daily value from previous week, excluding the last 48 hours as this is the interval where we export the data in GCP and get it into DWH.
-
-You can use [this query](https://gitlab.com/gitlab-org/gitlab/-/issues/347298#note_836685350) as an example, to start detecting when the drop started.
-
-### Troubleshoot the GitLab application layer
-
-For results about an investigation conducted into an unexpected drop in Service ping Payload events volume, see [this issue](https://gitlab.com/gitlab-data/analytics/-/issues/11071).
-
-### Troubleshoot VersionApp layer
-
-Check if the [export jobs](https://gitlab.com/gitlab-services/version-gitlab-com#data-export-using-pipeline-schedules) are successful.
-
-Check [Service Ping errors](https://app.periscopedata.com/app/gitlab/968489/Product-Intelligence---Service-Ping-Health?widget=14609989&udv=0) in the [Service Ping Health Dashboard](https://app.periscopedata.com/app/gitlab/968489/Product-Intelligence---Service-Ping-Health).
-
-### Troubleshoot Google Storage layer
-
-Check if the files are present in [Google Storage](https://console.cloud.google.com/storage/browser/cloudsql-gs-production-efd5e8-cloudsql-exports;tab=objects?project=gs-production-efd5e8&prefix=&forceOnObjectsSortingFiltering=false).
-
-### Troubleshoot the data warehouse layer
-
-Reach out to the [Data team](https://about.gitlab.com/handbook/business-technology/data-team/) to ask about current state of data warehouse. On their handbook page there is a [section with contact details](https://about.gitlab.com/handbook/business-technology/data-team/#how-to-connect-with-us).
-
-### Cannot disable Service Ping with the configuration file
-
-The method to disable Service Ping with the GitLab configuration file does not work in
-GitLab versions 9.3.0 to 13.12.3. To disable it, you must use the Admin Area in
-the GitLab UI instead. For more information, see
-[this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/333269).
-
-GitLab functionality and application settings cannot override or circumvent
-restrictions at the network layer. If Service Ping is blocked by your firewall,
-you are not impacted by this bug.
-
-#### Check if you are affected
-
-You can check if you were affected by this bug by using the Admin Area or by
-checking the configuration file of your GitLab instance:
-
-- Using the Admin Area:
-
-  1. On the top bar, select **Main menu > Admin**.
-  1. On the left sidebar, select **Settings > Metrics and profiling**.
-  1. Expand **Usage Statistics**.
-  1. Are you able to check or uncheck the checkbox to disable Service Ping?
-
-     - If _yes_, your GitLab instance is not affected by this bug.
-     - If you can't check or uncheck the checkbox, you are affected by this bug.
-       See the steps on [how to fix this](#how-to-fix-the-cannot-disable-service-ping-bug).
-
-- Checking your GitLab instance configuration file:
-
-  To check whether you're impacted by this bug, check your instance configuration
-  settings. The configuration file in which Service Ping can be disabled depends
-  on your installation and deployment method, but is typically one of the following:
-
-  - `/etc/gitlab/gitlab.rb` for Omnibus GitLab Linux Package and Docker.
-  - `charts.yaml` for GitLab Helm and cloud-native Kubernetes deployments.
-  - `gitlab.yml` for GitLab installations from source.
-
-  To check the relevant configuration file for strings that indicate whether
-  Service Ping is disabled, you can use `grep`:
-
-  ```shell
-  # Linux package
-  grep "usage_ping_enabled'\] = false" /etc/gitlab/gitlab.rb
-
-  # Kubernetes charts
-  grep "enableUsagePing: false" values.yaml
-
-  # From source
-  grep "usage_ping_enabled'\] = false" gitlab/config.yml
-  ```
-
-  If you see any output after running the relevant command, your GitLab instance
-  may be affected by the bug. Otherwise, your instance is not affected.
-
-#### How to fix the "Cannot disable Service Ping" bug
-
-To work around this bug, you have two options:
-
-- [Update](../../update/index.md) to GitLab 13.12.4 or newer to fix this bug.
-- If you can't update to GitLab 13.12.4 or newer, enable Service Ping in the
-  configuration file, then disable Service Ping in the UI. For example, if you're
-  using the Linux package:
-
-  1. Edit `/etc/gitlab/gitlab.rb`:
-
-     ```ruby
-     gitlab_rails['usage_ping_enabled'] = true
-     ```
-
-  1. Reconfigure GitLab:
-
-     ```shell
-     sudo gitlab-ctl reconfigure
-     ```
-
-  1. In GitLab, on the top bar, select **Main menu > Admin**.
-  1. On the left sidebar, select **Settings > Metrics and profiling**.
-  1. Expand **Usage Statistics**.
-  1. Clear the **Enable Service Ping** checkbox.
-  1. Select **Save Changes**.
-
-## Generate Service Ping
-
-### Generate or get the cached Service Ping in rails console
-
-Use the following method in the [rails console](../../administration/operations/rails_console.md#starting-a-rails-console-session).
-
-```ruby
-Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values, cached: true)
-```
-
-### Generate a fresh new Service Ping
-
-Use the following method in the [rails console](../../administration/operations/rails_console.md#starting-a-rails-console-session).
-
-This also refreshes the cached Service Ping displayed in the Admin Area.
-
-```ruby
-Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values)
-```
-
-### Generate and print
-
-Generates Service Ping data in JSON format.
-
-```shell
-gitlab-rake gitlab:usage_data:generate
-```
-
-Generates Service Ping data in YAML format:
-
-```shell
-gitlab-rake gitlab:usage_data:dump_sql_in_yaml
-```
-
-### Generate and send Service Ping
-
-Prints the metrics saved in `conversational_development_index_metrics`.
-
-```shell
-gitlab-rake gitlab:usage_data:generate_and_send
-```
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/service_ping/usage_data.md b/doc/development/service_ping/usage_data.md
index b3bdaedd60a..94ae90273d0 100644
--- a/doc/development/service_ping/usage_data.md
+++ b/doc/development/service_ping/usage_data.md
@@ -1,69 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/service_ping/usage_data.md'
+remove_date: '2023-08-20'
 ---
 
-# Usage Data Metrics guide
+This document was moved to [another location](../internal_analytics/service_ping/usage_data.md).
 
-This guide describes deprecated usage for metrics in `usage_data.rb`.
-
-NOTE:
-Implementing metrics direct in `usage_data.rb` is deprecated, We recommend you use [instrumentation classes](metrics_instrumentation.md).
-
-## Ordinary batch counters
-
-Simple count of a given `ActiveRecord_Relation`, does a non-distinct batch count, smartly reduces `batch_size`, and handles errors.
-Handles the `ActiveRecord::StatementInvalid` error.
-
-Method:
-
-```ruby
-count(relation, column = nil, batch: true, start: nil, finish: nil)
-```
-
-Arguments:
-
-- `relation` the ActiveRecord_Relation to perform the count
-- `column` the column to perform the count on, by default is the primary key
-- `batch`: default `true` to use batch counting
-- `start`: custom start of the batch counting to avoid complex min calculations
-- `end`: custom end of the batch counting to avoid complex min calculations
-
-Examples:
-
-```ruby
-count(User.active)
-count(::Clusters::Cluster.aws_installed.enabled, :cluster_id)
-count(::Clusters::Cluster.aws_installed.enabled, :cluster_id, start: ::Clusters::Cluster.minimum(:id), finish: ::Clusters::Cluster.maximum(:id))
-```
-
-## Distinct batch counters
-
-Distinct count of a given `ActiveRecord_Relation` on given column, a distinct batch count, smartly reduces `batch_size`, and handles errors.
-Handles the `ActiveRecord::StatementInvalid` error.
-
-Method:
-
-```ruby
-distinct_count(relation, column = nil, batch: true, batch_size: nil, start: nil, finish: nil)
-```
-
-Arguments:
-
-- `relation`: the ActiveRecord_Relation to perform the count
-- `column`: the column to perform the distinct count, by default is the primary key
-- `batch`: default `true` to use batch counting
-- `batch_size`: if none set it uses default value 10000 from `Gitlab::Database::BatchCounter`
-- `start`: custom start of the batch counting to avoid complex min calculations
-- `end`: custom end of the batch counting to avoid complex min calculations
-
-WARNING:
-Counting over non-unique columns can lead to performance issues. For more information, see the [iterating tables in batches](../database/iterating_tables_in_batches.md) guide.
-
-Examples:
-
-```ruby
-distinct_count(::Project, :creator_id)
-distinct_count(::Note.with_suggestions.where(time_period), :author_id, start: ::User.minimum(:id), finish: ::User.maximum(:id))
-```
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/sidekiq/index.md b/doc/development/sidekiq/index.md
index 2010a21130d..d510414baa3 100644
--- a/doc/development/sidekiq/index.md
+++ b/doc/development/sidekiq/index.md
@@ -114,6 +114,41 @@ def perform(project_id)
 end
 ```
 
+## Deferring Sidekiq workers
+
+Sidekiq workers are deferred by two ways,
+
+1. Manual: Feature flags can be used to explicitly defer a particular worker, more details can be found [here](../feature_flags/index.md#deferring-sidekiq-jobs).
+1. Automatic: Similar to the [throttling mechanism](../database/batched_background_migrations.md#throttling-batched-migrations) in batched migrations, database health indicators are used to defer a Sidekiq worker.
+
+   To use the automatic deferring mechanism, worker has to opt-in by calling `defer_on_database_health_signal` with gitlab_schema, delay_by (time to delay) and tables (which is used by autovacuum db indicator) as it's parameters.
+
+   **Example:**
+
+   ```ruby
+    module Chaos
+      class SleepWorker # rubocop:disable Scalability/IdempotentWorker
+        include ApplicationWorker
+
+        data_consistency :always
+
+        sidekiq_options retry: 3
+        include ChaosQueue
+
+        defer_on_database_health_signal :gitlab_main, 1.minute, [:users]
+
+        def perform(duration_s)
+          Gitlab::Chaos.sleep(duration_s)
+        end
+      end
+    end
+   ```
+
+For deferred jobs, logs contain the following to indicate the source:
+
+- `job_status`: `deferred`
+- `job_deferred_by`: 'feature_flag' or 'database_health_check'
+
 ## Sidekiq Queues
 
 Previously, each worker had its own queue, which was automatically set based on the
diff --git a/doc/development/snowplow/event_dictionary_guide.md b/doc/development/snowplow/event_dictionary_guide.md
index 6e8947e0210..2bea681bf59 100644
--- a/doc/development/snowplow/event_dictionary_guide.md
+++ b/doc/development/snowplow/event_dictionary_guide.md
@@ -1,91 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/snowplow/event_dictionary_guide.md'
+remove_date: '2023-08-20'
 ---
 
-# Event dictionary guide
+This document was moved to [another location](../internal_analytics/snowplow/event_dictionary_guide.md).
 
-NOTE:
-The event dictionary is a work in progress, and this process is subject to change.
-
-This guide describes the event dictionary and how it's implemented.
-
-## Event definition and validation
-
-This process is meant to document all Snowplow events and ensure consistency. Every Snowplow event needs to have such a definition. Event definitions must comply with the [JSON Schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/events/schema.json).
-
-All event definitions are stored in the following directories:
-
-- [`config/events`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/events)
-- [`ee/config/events`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/config/events)
-
-Each event is defined in a separate YAML file consisting of the following fields:
-
-| Field                  | Required | Additional information                                                                                                                                                                      |
-|------------------------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `description`          | yes      | A description of the event.                                                                                                                                                                 |
-| `category`             | yes      | The event category (see [Event schema](index.md#event-schema)).                                                                                                                             |
-| `action`               | yes      | The event action (see [Event schema](index.md#event-schema)).                                                                                                                               |
-| `label_description`    | no       | A description of the event label (see [Event schema](index.md#event-schema)).                                                                                                               |
-| `property_description` | no       | A description of the event property (see [Event schema](index.md#event-schema)).                                                                                                            |
-| `value_description`    | no       | A description of the event value (see [Event schema](index.md#event-schema)).                                                                                                               |
-| `extra_properties`     | no       | The type and description of each extra property sent with the event.                                                                                                                        |
-| `identifiers`          | no       | A list of identifiers sent with the event. Can be set to one or more of `project`, `user`, or `namespace`.                                                                                  |
-| `iglu_schema_url`      | no       | The URL to the custom schema sent with the event, for example, `iglu:com.gitlab/gitlab_experiment/jsonschema/1-0-0`.                                                                        |
-| `product_section`      | yes      | The [section](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/sections.yml).                                                                                                |
-| `product_stage`        | no       | The [stage](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) for the event.                                                                                        |
-| `product_group`        | yes      | The [group](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) that owns the event.                                                                                  |
-| `milestone`            | no       | The milestone when the event is introduced.                                                                                                                                                 |
-| `introduced_by_url`    | no       | The URL to the merge request that introduced the event.                                                                                                                                     |
-| `distributions`        | yes      | The [distributions](https://about.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/tiers/#definitions) where the tracked feature is available. Can be set to one or more of `ce` or `ee`.  |
-| `tiers`                | yes      | The [tiers](https://about.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/tiers/) where the tracked feature is available. Can be set to one or more of `free`, `premium`, or `ultimate`. |
-
-### Example event definition
-
-The linked [`uuid`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/events/epics_promote.yml)
-YAML file includes an example event definition.
-
-```yaml
-description: Issue promoted to epic
-category: epics
-action: promote
-property_description: The string "issue_id"
-value_description: ID of the issue
-extra_properties:
-  weight:
-    type: integer
-    description: Weight of the issue
-identifiers:
-- project
-- user
-- namespace
-product_section: dev
-product_stage: plan
-product_group: group::product planning
-milestone: "11.10"
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/10537
-distributions:
-- ee
-tiers:
-- premium
-- ultimate
-```
-
-## Create a new event definition
-
-Use the dedicated [event definition generator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/snowplow_event_definition_generator.rb)
-to create new event definitions.
-
-The `category` and `action` of each event are included in the filename to standardize file naming.
-
-The generator takes three options:
-
-- `--ee`: Indicates if the event is for EE.
-- `--category=CATEGORY`: Indicates the `category` of the event.
-- `--action=ACTION`: Indicates the `action` of the event.
-
-```shell
-bundle exec rails generate gitlab:snowplow_event_definition --category Groups::EmailCampaignsController --action click
-create  create  config/events/groups__email_campaigns_controller_click.yml
-```
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/snowplow/implementation.md b/doc/development/snowplow/implementation.md
index 37948f2a3e0..a9e4e252a53 100644
--- a/doc/development/snowplow/implementation.md
+++ b/doc/development/snowplow/implementation.md
@@ -1,522 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/snowplow/implementation.md'
+remove_date: '2023-08-20'
 ---
 
-# Implement Snowplow tracking
+This document was moved to [another location](../internal_analytics/snowplow/implementation.md).
 
-This page describes how to:
-
-- Implement Snowplow frontend and backend tracking
-- Test Snowplow events
-
-## Event definitions
-
-Every Snowplow event, regardless of frontend or backend, requires a corresponding event definition. These definitions document the event and its properties to make it easier to maintain and analyze.
-These defintions can be browsed in the [event dictionary](https://metrics.gitlab.com/snowplow). The [event dictionary guide](event_dictionary_guide.md) provides instructions for setting up an event definition.
-
-## Snowplow JavaScript frontend tracking
-
-GitLab provides a `Tracking` interface that wraps the [Snowplow JavaScript tracker](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/)
-to track custom events.
-
-For the recommended frontend tracking implementation, see [Usage recommendations](#usage-recommendations).
-
-Structured events and page views include the [`gitlab_standard`](schemas.md#gitlab_standard)
-context, using the `window.gl.snowplowStandardContext` object which includes
-[default data](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/views/layouts/_snowplow.html.haml)
-as base:
-
-| Property | Example |
-| -------- | ------- |
-| `context_generated_at` | `"2022-01-01T01:00:00.000Z"` |
-| `environment` | `"production"` |
-| `extra` | `{}` |
-| `namespace_id` | `123` |
-| `plan` | `"gold"` |
-| `project_id` | `456` |
-| `source` | `"gitlab-rails"` |
-| `user_id` | `789`* |
-
-_\* Undergoes a pseudonymization process at the collector level._
-
-These properties [are overridden](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/tracking/get_standard_context.js)
-with frontend-specific values, like `source` (`gitlab-javascript`), `google_analytics_id`
-and the custom `extra` object. You can modify this object for any subsequent
-structured event that fires, although this is not recommended.
-
-Tracking implementations must have an `action` and a `category`. You can provide additional
-properties from the [event schema](index.md#event-schema), in
-addition to an `extra` object that accepts key-value pairs.
-
-| Property      | Type   | Default value              | Description                                                                                                                                                                                 |
-|:-----------|:-------|:---------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `category` | string | `document.body.dataset.page` | Page or subsection of a page in which events are captured.                                                                                                                                  |
-| `action`   | string | `'generic'`                  | Action the user is taking. Clicks must be `click` and activations must be `activate`. For example, focusing a form field is `activate_form_input`, and clicking a button is `click_button`. |
-| `data`     | object | `{}`                         | Additional data such as `label`, `property`, `value` as described in [Event schema](index.md#event-schema), `context` for custom contexts, and `extra` (key-value pairs object).            |
-
-### Usage recommendations
-
-- Use [data attributes](#implement-data-attribute-tracking) on HTML elements that emit `click`, `show.bs.dropdown`, or `hide.bs.dropdown` events.
-- Use the [Vue mixin](#implement-vue-component-tracking) for tracking custom events, or if the supported events for data attributes are not propagating. For example, clickable components that don't emit `click`.
-- Use the [tracking class](#implement-raw-javascript-tracking) when tracking in vanilla JavaScript files.
-
-### Implement data attribute tracking
-
-To implement tracking for HAML or Vue templates, add a [`data-track` attribute](#data-track-attributes) to the element.
-
-The following example shows `data-track-*` attributes assigned to a button:
-
-```haml
-%button.btn{ data: { track_action: "click_button", track_label: "template_preview", track_property: "my-template" } }
-```
-
-```html
-<button class="btn"
-  data-track-action="click_button"
-  data-track-label="template_preview"
-  data-track-property="my-template"
-  data-track-extra='{ "template_variant": "primary" }'
-/>
-```
-
-#### `data-track` attributes
-
-| Attribute             | Required | Description |
-|:----------------------|:---------|:------------|
-| `data-track-action`    | true     | Action the user is taking. Clicks must be prepended with `click` and activations must be prepended with `activate`. For example, focusing a form field is `activate_form_input` and clicking a button is `click_button`. Replaces `data-track-event`, which was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/290962) in GitLab 13.11. |
-| `data-track-label`    | false    | The specific element or object to act on. This can be: the label of the element, for example, a tab labeled 'Create from template' for `create_from_template`; a unique identifier if no text is available, for example, `groups_dropdown_close` for closing the Groups dropdown list in the top bar; or the name or title attribute of a record being created. |
-| `data-track-property` | false    | Any additional property of the element, or object being acted on. |
-| `data-track-value`    | false    | Describes a numeric value (decimal) directly related to the event. This could be the value of an input. For example, `10` when clicking `internal` visibility. If omitted, this is the element's `value` property or `undefined`. For checkboxes, the default value is the element's checked attribute or `0` when unchecked. The value is parsed as numeric before sending the event. |
-| `data-track-extra` | false    | A key-value pair object passed as a valid JSON string. This attribute is added to the `extra` property in our [`gitlab_standard`](schemas.md#gitlab_standard) schema. |
-| `data-track-context`  | false    | To append a custom context object, passed as a valid JSON string. |
-
-#### Event listeners
-
-Event listeners bind at the document level to handle click events in elements with data attributes.
-This allows them to be handled when the DOM re-renders or changes. Document-level binding reduces
-the likelihood that click events stop propagating up the DOM tree.
-
-If click events stop propagating, you must implement listeners and [Vue component tracking](#implement-vue-component-tracking) or [raw JavaScript tracking](#implement-raw-javascript-tracking).
-
-#### Helper methods
-
-You can use the following Ruby helpers:
-
-```ruby
-tracking_attrs(label, action, property) # { data: { track_label... } }
-
-tracking_attrs_data(label, action, property) # { track_label... }
-```
-
-You can also use it on HAML templates:
-
-```haml
-%button{ **tracking_attrs('main_navigation', 'click_button', 'navigation') }
-
-// When merging with additional data
-// %button{ data: { platform: "...", **tracking_attrs_data('main_navigation', 'click_button', 'navigation') } }
-```
-
-If you use the GitLab helper method [`nav_link`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/helpers/tab_helper.rb#L76), you must wrap `html_options` under the `html_options` keyword argument. If you
-use the `ActionView` helper method [`link_to`](https://api.rubyonrails.org/classes/ActionView/Helpers/UrlHelper.html#method-i-link_to), you don't need to wrap `html_options`.
-
-```ruby
-# Bad
-= nav_link(controller: ['dashboard/groups', 'explore/groups'], data: { track_label: "explore_groups",
-track_action: "click_button" })
-
-# Good
-= nav_link(controller: ['dashboard/groups', 'explore/groups'], html_options: { data: { track_label:
-"explore_groups", track_action: "click_button" } })
-
-# Good (other helpers)
-= link_to explore_groups_path, title: _("Explore"), data: { track_label: "explore_groups", track_action:
-"click_button" }
-```
-
-### Implement Vue component tracking
-
-For custom event tracking, use the [Vue mixin](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/tracking/tracking.js#L207). It exposes `Tracking.event` as the `track` method.
-You can specify tracking options by creating a `tracking` data object or
-computed property, and as a second parameter: `this.track('click_button', opts)`.
-These options override any defaults and allow the values to be dynamic from props or based on state:
-
-| Property | Type | Default | Example |
-| -- | -- | -- | -- |
-| `category` | string | `document.body.dataset.page` | `'code_quality_walkthrough'` |
-| `label` | string | `''` | `'process_start_button'` |
-| `property` | string | `''` | `'asc'` or `'desc'` |
-| `value` | integer | `undefined` | `0`, `1`, `500` |
-| `extra` | object | `{}` | `{ selectedVariant: this.variant }` |
-
-To implement Vue component tracking:
-
-1. Import the `Tracking` library and call the `mixin` method:
-
-   ```javascript
-   import Tracking from '~/tracking';
-
-   const trackingMixin = Tracking.mixin();
-
-   // Optionally provide default properties
-   // const trackingMixin = Tracking.mixin({ label: 'right_sidebar' });
-   ```
-
-1. Use the mixin in the component:
-
-   ```javascript
-   export default {
-     mixins: [trackingMixin],
-     // Or
-     // mixins: [Tracking.mixin()],
-     // mixins: [Tracking.mixin({ label: 'right_sidebar' })],
-
-     data() {
-       return {
-         expanded: false,
-       };
-     },
-   };
-   ```
-
-1. You can specify tracking options in by creating a `tracking` data object
-or computed property:
-
-   ```javascript
-   export default {
-     name: 'RightSidebar',
-
-     mixins: [Tracking.mixin()],
-
-     data() {
-       return {
-         expanded: false,
-         variant: '',
-         tracking: {
-           label: 'right_sidebar',
-           // property: '',
-           // value: '',
-           // experiment: '',
-           // extra: {},
-         },
-       };
-     },
-
-     // Or
-     // computed: {
-     //   tracking() {
-     //     return {
-     //       property: this.variant,
-     //       extra: { expanded: this.expanded },
-     //     };
-     //   },
-     // },
-   };
-   ```
-
-1. Call the `track` method. Tracking options can be passed as the second parameter:
-
-   ```javascript
-   this.track('click_button', {
-     label: 'right_sidebar',
-   });
-   ```
-
-   Or use the `track` method in the template:
-
-   ```html
-   <template>
-     <div>
-       <button data-testid="toggle" @click="toggle">Toggle</button>
-
-       <div v-if="expanded">
-         <p>Hello world!</p>
-         <button @click="track('click_button')">Track another event</button>
-       </div>
-     </div>
-   </template>
-   ```
-
-#### Testing example
-
-```javascript
-export default {
-  name: 'CountDropdown',
-
-  mixins: [Tracking.mixin({ label: 'count_dropdown' })],
-
-  data() {
-    return {
-      variant: 'counter',
-      count: 0,
-    };
-  },
-
-  methods: {
-    handleChange({ target }) {
-      const { variant } = this;
-
-      this.count = Number(target.value);
-
-      this.track('change_value', {
-        value: this.count,
-        extra: { variant }
-      });
-    },
-  },
-};
-```
-
-```javascript
-import { mockTracking } from 'helpers/tracking_helper';
-// mockTracking(category, documentOverride, spyMethod)
-
-describe('CountDropdown.vue', () => {
-  let trackingSpy;
-  let wrapper;
-
-  ...
-
-  beforeEach(() => {
-    trackingSpy = mockTracking(undefined, wrapper.element, jest.spyOn);
-  });
-
-  const findDropdown = () => wrapper.find('[data-testid="dropdown"]');
-
-  it('tracks change event', () => {
-    const dropdown = findDropdown();
-    dropdown.element.value = 30;
-    dropdown.trigger('change');
-
-    expect(trackingSpy).toHaveBeenCalledWith(undefined, 'change_value', {
-      value: 30,
-      label: 'count_dropdown',
-      extra: { variant: 'counter' },
-    });
-  });
-});
-```
-
-### Implement raw JavaScript tracking
-
-To track from a vanilla JavaScript file, use the `Tracking.event` static function
-(calls [`dispatchSnowplowEvent`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/tracking/dispatch_snowplow_event.js)).
-
-The following example demonstrates tracking a click on a button by manually calling `Tracking.event`.
-
-```javascript
-import Tracking from '~/tracking';
-
-const button = document.getElementById('create_from_template_button');
-
-button.addEventListener('click', () => {
-  Tracking.event(undefined, 'click_button', {
-    label: 'create_from_template',
-    property: 'template_preview',
-    extra: {
-      templateVariant: 'primary',
-      valid: 1,
-    },
-  });
-});
-```
-
-#### Testing example
-
-```javascript
-import Tracking from '~/tracking';
-
-describe('MyTracking', () => {
-  let wrapper;
-
-  beforeEach(() => {
-    jest.spyOn(Tracking, 'event');
-  });
-
-  const findButton = () => wrapper.find('[data-testid="create_from_template"]');
-
-  it('tracks event', () => {
-    findButton().trigger('click');
-
-    expect(Tracking.event).toHaveBeenCalledWith(undefined, 'click_button', {
-      label: 'create_from_template',
-      property: 'template_preview',
-      extra: {
-        templateVariant: 'primary',
-        valid: true,
-      },
-    });
-  });
-});
-```
-
-### Form tracking
-
-To enable Snowplow automatic [form tracking](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracking-specific-events/#form-tracking):
-
-1. Call `Tracking.enableFormTracking` when the DOM is ready.
-1. Provide a `config` object that includes at least one of the following elements:
-    - `forms` determines the forms to track. Identified by the CSS class name.
-    - `fields` determines the fields inside the tracked forms to track. Identified by the field `name`.
-1. Optional. Provide a list of contexts as the second argument. The [`gitlab_standard`](schemas.md#gitlab_standard) schema is excluded from these events.
-
-```javascript
-Tracking.enableFormTracking({
-  forms: { allow: ['sign-in-form', 'password-recovery-form'] },
-  fields: { allow: ['terms_and_conditions', 'newsletter_agreement'] },
-});
-```
-
-#### Testing example
-
-```javascript
-import Tracking from '~/tracking';
-
-describe('MyFormTracking', () => {
-  let formTrackingSpy;
-
-  beforeEach(() => {
-    formTrackingSpy = jest
-      .spyOn(Tracking, 'enableFormTracking')
-      .mockImplementation(() => null);
-  });
-
-  it('initialized with the correct configuration', () => {
-    expect(formTrackingSpy).toHaveBeenCalledWith({
-      forms: { allow: ['sign-in-form', 'password-recovery-form'] },
-      fields: { allow: ['terms_and_conditions', 'newsletter_agreement'] },
-    });
-  });
-});
-```
-
-## Implement Ruby backend tracking
-
-`Gitlab::Tracking` is an interface that wraps the [Snowplow Ruby Tracker](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/ruby-tracker/) for tracking custom events.
-Backend tracking provides:
-
-- User behavior tracking
-- Instrumentation to monitor and visualize performance over time in a section or aspect of code.
-
-To add custom event tracking and instrumentation, call the `GitLab::Tracking.event` class method.
-For example:
-
-```ruby
-class Projects::CreateService < BaseService
-  def execute
-    project = Project.create(params)
-
-    Gitlab::Tracking.event('Projects::CreateService', 'create_project', label: project.errors.full_messages.to_sentence,
-                           property: project.valid?.to_s, project: project, user: current_user, namespace: namespace)
-  end
-end
-```
-
-Use the following arguments:
-
-| Argument   | Type                      | Default value | Description                                                                                                                       |
-|------------|---------------------------|---------------|-----------------------------------------------------------------------------------------------------------------------------------|
-| `category` | String                    |               | Area or aspect of the application. For example,  `HealthCheckController` or `Lfs::FileTransformer`.                  |
-| `action`   | String                    |               | The action being taken. For example, a controller action such as `create`, or an Active Record callback. |
-| `label`    | String                    | `nil`           | The specific element or object to act on. This can be one of the following: the label of the element, for example, a tab labeled 'Create from template' for `create_from_template`; a unique identifier if no text is available, for example, `groups_dropdown_close` for closing the Groups dropdown list in the top bar; or the name or title attribute of a record being created.                                                          |
-| `property` | String                    | `nil`           | Any additional property of the element, or object being acted on.                                                          |
-| `value`    | Numeric                   | `nil`           | Describes a numeric value (decimal) directly related to the event. This could be the value of an input. For example, `10` when clicking `internal` visibility.                                                          |
-| `context`  | Array\[SelfDescribingJSON\] | `nil`           | An array of custom contexts to send with this event. Most events should not have any custom contexts.                             |
-| `project`  | Project                   | `nil`           | The project associated with the event. |
-| `user`     | User                      | `nil`           | The user associated with the event. This value undergoes a pseudonymization process at the collector level. |
-| `namespace` | Namespace                | `nil`           | The namespace associated with the event. |
-| `extra`   | Hash                | `{}`         | Additional keyword arguments are collected into a hash and sent with the event. |
-
-### Unit testing
-
-To test backend Snowplow events, use the `expect_snowplow_event` helper. For more information, see
-[testing best practices](../testing_guide/best_practices.md#test-snowplow-events).
-
-### Performance
-
-We use the [AsyncEmitter](https://snowplow.github.io/snowplow-ruby-tracker/SnowplowTracker/AsyncEmitter.html) when tracking events, which allows for instrumentation calls to be run in a background thread. This is still an active area of development.
-
-## Develop and test Snowplow
-
-To develop and test a Snowplow event, there are several tools to test frontend and backend events:
-
-| Testing Tool                                 | Frontend Tracking  | Backend Tracking    | Local Development Environment | Production Environment | Production Environment |
-|----------------------------------------------|--------------------|---------------------|-------------------------------|------------------------|------------------------|
-| Snowplow Analytics Debugger Chrome Extension | Yes | No | Yes            | Yes     | Yes     |
-| Snowplow Inspector Chrome Extension          | Yes | No | Yes            | Yes     | Yes     |
-| Snowplow Micro                               | Yes | Yes  | Yes            | No    | No    |
-
-### Test frontend events
-
-Before you test frontend events in development, you must:
-
-1. [Enable Snowplow tracking in the Admin Area](index.md#enable-snowplow-tracking).
-1. Turn off ad blockers that could prevent Snowplow JavaScript from loading in your environment.
-1. Turn off "Do Not Track" (DNT) in your browser.
-
-All URLs are pseudonymized. The entity identifier [replaces](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracker-setup/other-parameters-2/#setting-a-custom-page-url-and-referrer-url) personally identifiable
-information (PII). PII includes usernames, group, and project names.
-Page titles are hardcoded as `GitLab` for the same reason.
-
-#### Snowplow Analytics Debugger Chrome Extension
-
-[Snowplow Analytics Debugger](https://www.iglooanalytics.com/blog/snowplow-analytics-debugger-chrome-extension.html) is a browser extension for testing frontend events. It works in production, staging, and local development environments.
-
-1. Install the [Snowplow Analytics Debugger](https://chrome.google.com/webstore/detail/snowplow-analytics-debugg/jbnlcgeengmijcghameodeaenefieedm) Chrome browser extension.
-1. Open Chrome DevTools to the Snowplow Analytics Debugger tab.
-
-#### Snowplow Inspector Chrome Extension
-
-Snowplow Inspector Chrome Extension is a browser extension for testing frontend events. This works in production, staging, and local development environments.
-
-<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For a video tutorial, see the [Snowplow plugin walk through](https://www.youtube.com/watch?v=g4rqnIZ1Mb4).
-
-1. Install [Snowplow Inspector](https://chrome.google.com/webstore/detail/snowplow-inspector/maplkdomeamdlngconidoefjpogkmljm?hl=en).
-1. To open the extension, select the Snowplow Inspector icon beside the address bar.
-1. Click around on a webpage with Snowplow to see JavaScript events firing in the inspector window.
-
-### Test backend events with Snowplow Micro
-
-[Snowplow Micro](https://snowplow.io/blog/introducing-snowplow-micro/) is a
-Docker-based solution for testing backend and frontend in a local development environment. Snowplow Micro
-records the same events as the full Snowplow pipeline. To query events, use the Snowplow Micro API.
-
-It can be set up automatically using [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit).
-See the [how-to docs](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/snowplow_micro.md) for more details.
-
-1. Set the environment variable to tell the GDK to use Snowplow Micro in development. This overrides two `application_settings` options:
-   - `snowplow_enabled` setting will instead return `true` from `Gitlab::Tracking.enabled?`
-   - `snowplow_collector_hostname` setting will instead always return `localhost:9090` (or whatever port is set for `snowplow_micro.port` GDK setting) from `Gitlab::Tracking.collector_hostname`.
-With Snowplow Micro set up you can now manually test backend Snowplow events:
-
-1. Send a test Snowplow event from the Rails console:
-
-   ```ruby
-   Gitlab::Tracking.event('category', 'action')
-   ```
-
-1. Navigate to `localhost:9090/micro/good` to see the event.
-
-#### Useful links
-
-- [Snowplow Micro repository](https://github.com/snowplow-incubator/snowplow-micro)
-- [Installation guide recording](https://www.youtube.com/watch?v=OX46fo_A0Ag)
-
-### Troubleshoot
-
-To control content security policy warnings when using an external host, modify `config/gitlab.yml`
-to allow or prevent them. To allow them, add the relevant host for `connect_src`. For example, for
-`https://snowplow.trx.gitlab.net`:
-
-```yaml
-development:
-  <<: *base
-  gitlab:
-    content_security_policy:
-      enabled: true
-      directives:
-        connect_src: "'self' http://localhost:* http://127.0.0.1:* ws://localhost:* wss://localhost:* ws://127.0.0.1:* https://snowplow.trx.gitlab.net/"
-```
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/snowplow/index.md b/doc/development/snowplow/index.md
index 4ccb90c22a6..c0e53fe3b1b 100644
--- a/doc/development/snowplow/index.md
+++ b/doc/development/snowplow/index.md
@@ -1,202 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/snowplow/index.md'
+remove_date: '2023-08-20'
 ---
 
-# Snowplow development guidelines
+This document was moved to [another location](../internal_analytics/snowplow/index.md).
 
-Snowplow is an enterprise-grade marketing and Product Intelligence platform that tracks how users engage with our website and application.
-
-[Snowplow](https://snowplow.io/) consists of several loosely-coupled sub-systems:
-
-- **Trackers** fire Snowplow events. Snowplow has twelve trackers that cover web, mobile, desktop, server, and IoT.
-- **Collectors** receive Snowplow events from trackers. We use different event collectors that synchronize events to Amazon S3, Apache Kafka, or Amazon Kinesis.
-- **Enrich** cleans raw Snowplow events, enriches them, and puts them into storage. There is a Hadoop-based enrichment process, and a Kinesis-based or Kafka-based process.
-- **Storage** stores Snowplow events. We store the Snowplow events in a flat file structure on S3, and in the Redshift and PostgreSQL databases.
-- **Data modeling** joins event-level data with other data sets, aggregates them into smaller data sets, and applies business logic. This produces a clean set of tables for data analysis. We use data models for Redshift and Looker.
-- **Analytics** are performed on Snowplow events or on aggregate tables.
-
-![Snowplow flow](../img/snowplow_flow.png)
-
-## Enable Snowplow tracking
-
-Tracking can be enabled at:
-
-- The instance level, which enables tracking on both the frontend and backend layers.
-- The user level. User tracking can be disabled on a per user basis.
-  GitLab respects the [Do Not Track](https://www.eff.org/issues/do-not-track) standard, so any user who has enabled the Do Not Track option in their browser is not tracked at a user level.
-
-Snowplow tracking is configured to send data for GitLab.com to a collector configured by GitLab. By default, self-managed
-instances do not have a collector configured and do not collect data via Snowplow.
-
-You can configure your self-managed GitLab instance to use a custom Snowplow collector.
-
-1. On the top bar, select **Main menu > Admin**, then select **Settings > General**.
-   Alternatively, go to `admin/application_settings/general` in your browser.
-
-1. Expand **Snowplow**.
-
-1. Select **Enable Snowplow tracking** and enter your Snowplow configuration information. For example:
-
-   | Name               | Value                         |
-   |--------------------|-------------------------------|
-   | Collector hostname | `your-snowplow-collector.net` |
-   | App ID             | `gitlab`                      |
-   | Cookie domain      | `.your-gitlab-instance.com`   |
-
-1. Select **Save changes**.
-
-## Snowplow request flow
-
-The following example shows a basic request/response flow between the following components:
-
-- Snowplow JS / Ruby Trackers on GitLab.com
-- [GitLab.com Snowplow Collector](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/snowplow/index.md)
-- The GitLab S3 Bucket
-- The GitLab Snowflake Data Warehouse
-- Sisense:
-
-```mermaid
-sequenceDiagram
-    participant Snowplow JS (Frontend)
-    participant Snowplow Ruby (Backend)
-    participant GitLab.com Snowplow Collector
-    participant S3 Bucket
-    participant Snowflake DW
-    participant Sisense Dashboards
-    Snowplow JS (Frontend) ->> GitLab.com Snowplow Collector: FE Tracking event
-    Snowplow Ruby (Backend) ->> GitLab.com Snowplow Collector: BE Tracking event
-    loop Process using Kinesis Stream
-      GitLab.com Snowplow Collector ->> GitLab.com Snowplow Collector: Log raw events
-      GitLab.com Snowplow Collector ->> GitLab.com Snowplow Collector: Enrich events
-      GitLab.com Snowplow Collector ->> GitLab.com Snowplow Collector: Write to disk
-    end
-    GitLab.com Snowplow Collector ->> S3 Bucket: Kinesis Firehose
-    Note over GitLab.com Snowplow Collector, S3 Bucket: Pseudonymization
-    S3 Bucket->>Snowflake DW: Import data
-    Snowflake DW->>Snowflake DW: Transform data using dbt
-    Snowflake DW->>Sisense Dashboards: Data available for querying
-```
-
-For more details about the architecture, see [Snowplow infrastructure](infrastructure.md).
-
-## Event schema
-
-All the events must be consistent. If each feature captures events differently, it can be difficult
-to perform analysis.
-
-Each event provides attributes that describe the event.
-
-| Attribute | Type    | Required | Description |
-| --------- | ------- | -------- | ----------- |
-| category  | text    | true     | The page or backend section of the application. Unless infeasible, use the Rails page attribute by default in the frontend, and namespace + class name on the backend, for example, `Notes::CreateService`. |
-| action    | text    | true     | The action the user takes, or aspect that's being instrumented. The first word must describe the action or aspect. For example, clicks must be `click`, activations must be `activate`, creations must be `create`. Use underscores to describe what was acted on. For example, activating a form field is `activate_form_input`, an interface action like clicking on a dropdown list is `click_dropdown`, a behavior like creating a project record from the backend is `create_project`. |
-| label     | text    | false    | The specific element or object to act on. This can be one of the following: the label of the element, for example, a tab labeled 'Create from template' for `create_from_template`; a unique identifier if no text is available, for example, `groups_dropdown_close` for closing the Groups dropdown list in the top bar; or the name or title attribute of a record being created. For Service Ping metrics adapted to Snowplow events, this should be the full metric [key path](../service_ping/metrics_dictionary.md#metric-key_path) taken from its definition file. |
-| property  | text    | false    | Any additional property of the element, or object being acted on. For Service Ping metrics adapted to Snowplow events, this should be additional information or context that can help analyze the event. For example, in the case of `usage_activity_by_stage_monthly.create.merge_requests_users`, there are four different possible merge request actions: "create", "merge", "comment", and "close". Each of these would be a possible property value. |
-| value     | decimal | false    | Describes a numeric value (decimal) directly related to the event. This could be the value of an input. For example, `10` when clicking `internal` visibility. |
-| context   | vector  | false    | Additional data in the form of a [self-describing JSON](https://docs.snowplow.io/docs/pipeline-components-and-applications/iglu/common-architecture/self-describing-json-schemas/) to describe the event if the attributes are not sufficient. Each context must have its schema defined to assure data integrity. Refer to the list of GitLab-defined contexts for more details. |
-
-### Examples
-
-| Category* | Label            | Action                | Property** | Value |
-|-------------|------------------|-----------------------|----------|:-----:|
-| `[root:index]` | `main_navigation`            | `click_navigation_link` | `[link_label]`   | - |
-| `[groups:boards:show]` | `toggle_swimlanes` | `click_toggle_button` | - | `[is_active]` |
-| `[projects:registry:index]` | `registry_delete` | `click_button` | - | - |
-| `[projects:registry:index]` | `registry_delete` | `confirm_deletion` | - | - |
-| `[projects:blob:show]` | `congratulate_first_pipeline` | `click_button` | `[human_access]` | - |
-| `[projects:clusters:new]` | `chart_options` | `generate_link` | `[chart_link]` | - |
-| `[projects:clusters:new]` | `chart_options` | `click_add_label_button` | `[label_id]` | - |
-| `API::NpmPackages` | `counts.package_events_i_package_push_package_by_deploy_token` | `push_package` | `npm` | - |
-
-_* If you choose to omit the category you can use the default._<br>
-_** Use property for variable strings._
-
-### Reference SQL
-
-#### Last 20 `reply_comment_button` events
-
-```sql
-SELECT
-  session_id,
-  event_id,
-  event_label,
-  event_action,
-  event_property,
-  event_value,
-  event_category,
-  contexts
-FROM legacy.snowplow_structured_events_all
-WHERE
-  event_label = 'reply_comment_button'
-  AND event_action = 'click_button'
-  -- AND event_category = 'projects:issues:show'
-  -- AND event_value = 1
-ORDER BY collector_tstamp DESC
-LIMIT 20
-```
-
-#### Last 100 page view events
-
-```sql
-SELECT
-  -- page_url,
-  -- page_title,
-  -- referer_url,
-  -- marketing_medium,
-  -- marketing_source,
-  -- marketing_campaign,
-  -- browser_window_width,
-  -- device_is_mobile
-  *
-FROM legacy.snowplow_page_views_30
-ORDER BY page_view_start DESC
-LIMIT 100
-```
-
-#### Top 20 users who fired `reply_comment_button` in the last 30 days
-
-```sql
-SELECT
-  count(*) as hits,
-  se_action,
-  se_category,
-  gsc_pseudonymized_user_id
-FROM legacy.snowplow_gitlab_events_30
-WHERE
-  se_label = 'reply_comment_button'
-  AND gsc_pseudonymized_user_id IS NOT NULL
-GROUP BY gsc_pseudonymized_user_id, se_category, se_action
-ORDER BY count(*) DESC
-LIMIT 20
-```
-
-#### Query JSON formatted data
-
-```sql
-SELECT
-  derived_tstamp,
-  contexts:data[0]:data:extra:old_format as CURRENT_FORMAT,
-  contexts:data[0]:data:extra:value as UPDATED_FORMAT
-FROM legacy.snowplow_structured_events_all
-WHERE event_action in ('wiki_format_updated')
-ORDER BY derived_tstamp DESC
-LIMIT 100
-```
-
-### Web-specific parameters
-
-Snowplow JavaScript adds [web-specific parameters](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/snowplow-tracker-protocol/#Web-specific_parameters) to all web events by default.
-
-## Related topics
-
-- [Snowplow data structure](https://docs.snowplow.io/docs/understanding-your-pipeline/canonical-event/)
-- [Our Iglu schema registry](https://gitlab.com/gitlab-org/iglu)
-- [List of events used in our codebase (Event Dictionary)](https://metrics.gitlab.com/snowplow/)
-- [Product Intelligence Guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
-- [Service Ping Guide](../service_ping/index.md)
-- [Product Intelligence Direction](https://about.gitlab.com/direction/analytics/product-intelligence/)
-- [Data Analysis Process](https://about.gitlab.com/handbook/business-technology/data-team/#data-analysis-process/)
-- [Data for Product Managers](https://about.gitlab.com/handbook/business-technology/data-team/programs/data-for-product-managers/)
-- [Data Infrastructure](https://about.gitlab.com/handbook/business-technology/data-team/platform/infrastructure/)
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/snowplow/infrastructure.md b/doc/development/snowplow/infrastructure.md
index ac146542630..6374af40ffe 100644
--- a/doc/development/snowplow/infrastructure.md
+++ b/doc/development/snowplow/infrastructure.md
@@ -1,101 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/snowplow/infrastructure.md'
+remove_date: '2023-08-20'
 ---
 
-# Snowplow infrastructure
+This document was moved to [another location](../internal_analytics/snowplow/infrastructure.md).
 
-Snowplow events on GitLab SaaS fired by a [tracker](implementation.md) go through an AWS pipeline, managed by GitLab.
-
-## Event flow in the AWS pipeline
-
-Every event goes through a collector, enricher, and pseudonymization lambda. The event is then dumped to S3 storage where it can be picked up by the Snowflake data warehouse.
-
-Deploying and managing the infrastructure is automated using Terraform in the current [Terraform repository](https://gitlab.com/gitlab-com/gl-infra/config-mgmt/-/tree/master/environments/aws-snowplow).
-
-```mermaid
-graph LR
-    GL[GitLab.com]-->COL
-
-    subgraph aws-cloud[AWS]
-    COL[Collector]-->|snowplow-raw-good|ENR
-    COL[Collector]-->|snowplow-raw-bad|FRBE
-        subgraph firehoserbe[Firehose]
-        FRBE[AWS Lambda]
-      end
-    FRBE-->S3RBE
-
-    ENR[Enricher]-->|snowplow-enriched-bad|FEBE
-      subgraph firehoseebe[Firehose]
-        FEBE[AWS Lambda]
-      end
-    FEBE-->S3EBE
-
-    ENR[Enricher]-->|snowplow-enriched-good|FRGE
-      subgraph firehosege[Firehose]
-        FRGE[AWS Lambda]
-      end
-    FRGE-->S3GE
-  end
-
-    subgraph snowflake[Data warehouse]
-    S3RBE[S3 raw-bad]-->BE[gitlab_bad_events]
-    S3EBE[S3 enriched-bad]-->BE[gitlab_bad_events]
-    S3GE[S3 output]-->GE[gitlab_events]
-  end
-```
-
-See [Snowplow technology 101](https://github.com/snowplow/snowplow/#snowplow-technology-101) for Snowplow's own documentation and an overview how collectors and enrichers work.
-
-### Pseudonymization
-
-In contrast to a typical Snowplow pipeline, after enrichment, GitLab Snowplow events go through a [pseudonymization service](https://gitlab.com/gitlab-org/analytics-section/product-intelligence/snowplow-pseudonymization) in the form of an AWS Lambda service before they are stored in S3 storage.
-
-#### Why events need to be pseudonymized
-
-GitLab is bound by its [obligations to community](https://about.gitlab.com/handbook/product/product-intelligence-guide/service-usage-data-commitment/)
-and by [legal regulations](https://about.gitlab.com/handbook/legal/privacy/services-usage-data/) to protect the privacy of its users.
-
-GitLab must provide valuable insights for business decisions, and there is a need
-for a better understanding of different users' behavior patterns. The
-pseudonymization process helps you find a compromise between these two requirements.
-
-Pseudonymization processes personally identifiable information inside a Snowplow event in an irreversible fashion
-maintaining deterministic output for given input, while masking any relation to that input.
-
-#### How events are pseudonymized
-
-Pseudonymization uses an allowlist that provides privacy by default. Therefore, each
-attribute received as part of a Snowplow event is pseudonymized unless the attribute
-is an allowed exception.
-
-Pseudonymization is done using the HMAC-SHA256 keyed hash algorithm.
-Attributes are combined with a secret salt to replace each identifiable information with a pseudonym.
-
-### S3 bucket data lake to Snowflake
-
-See [Data team's Snowplow Overview](https://about.gitlab.com/handbook/business-technology/data-team/platform/snowplow/) for further details how data is ingested into our Snowflake data warehouse.
-
-## Monitoring
-
-There are several tools that monitor Snowplow events tracking in different stages of the processing pipeline:
-
-- [Product Intelligence Grafana dashboard](https://dashboards.gitlab.net/d/product-intelligence-main/product-intelligence-product-intelligence?orgId=1) monitors backend events sent from a GitLab.com instance to a collectors fleet. This dashboard provides information about:
-  - The number of events that successfully reach Snowplow collectors.
-  - The number of events that failed to reach Snowplow collectors.
-  - The number of backend events that were sent.
-- [AWS CloudWatch dashboard](https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#dashboards:name=SnowPlow;start=P3D) monitors the state of the events in a processing pipeline. The pipeline starts from Snowplow collectors, goes through to enrichers and pseudonymization, and then up to persistence in an S3 bucket. From S3, the events are imported into the Snowflake Data Warehouse. You must have AWS access rights to view this dashboard. For more information, see [monitoring](https://gitlab.com/gitlab-org/analytics-section/product-intelligence/snowplow-pseudonymization#monitoring) in the Snowplow Events pseudonymization service documentation.
-- [Sisense dashboard](https://app.periscopedata.com/app/gitlab/417669/Snowplow-Summary-Dashboard) provides information about the number of good and bad events imported into the Data Warehouse, in addition to the total number of imported Snowplow events.
-
-For more information, see this [video walk-through](https://www.youtube.com/watch?v=NxPS0aKa_oU).
-
-## Related topics
-
-- [Snowplow technology 101](https://github.com/snowplow/snowplow/#snowplow-technology-101)
-- [Snowplow pseudonymization AWS Lambda project](https://gitlab.com/gitlab-org/analytics-section/product-intelligence/snowplow-pseudonymization)
-- [Product Intelligence Guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
-- [Data Infrastructure](https://about.gitlab.com/handbook/business-technology/data-team/platform/infrastructure/)
-- [Snowplow architecture overview (internal)](https://www.youtube.com/watch?v=eVYJjzspsLU)
-- [Snowplow architecture overview slide deck (internal)](https://docs.google.com/presentation/d/16gQEO5CAg8Tx4NBtfnZj-GF4juFI6HfEPWcZgH4Rn14/edit?usp=sharing)
-- [AWS Lambda implementation (internal)](https://youtu.be/cQd0mdMhkQA)
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/snowplow/review_guidelines.md b/doc/development/snowplow/review_guidelines.md
index d5432cc9075..f4752e08dde 100644
--- a/doc/development/snowplow/review_guidelines.md
+++ b/doc/development/snowplow/review_guidelines.md
@@ -1,44 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/snowplow/review_guidelines.md'
+remove_date: '2023-08-20'
 ---
 
-# Snowplow review guidelines
+This document was moved to [another location](../internal_analytics/snowplow/review_guidelines.md).
 
-This page includes introductory material for an
-[Analytics Instrumentation](https://about.gitlab.com/handbook/engineering/development/analytics/analytics-instrumentation/)
-review, and is specific to Snowplow related reviews. For broader advice and
-general best practices for code reviews, refer to our [code review guide](../code_review.md).
-
-## Resources for reviewers
-
-- [Snowplow Guide](index.md)
-- [Event Dictionary](https://metrics.gitlab.com/snowplow/)
-
-## Review process
-
-We recommend an Analytics Instrumentation review when a merge request (MR) involves changes in
-events or touches Snowplow related files.
-
-### Roles and process
-
-#### The merge request **author** should
-
-- For frontend events, when relevant, add a screenshot of the event in
-  the [testing tool](implementation.md#develop-and-test-snowplow) used.
-- For backend events, when relevant, add the output of the
-  [Snowplow Micro](implementation.md#test-backend-events-with-snowplow-micro) good events
-  `GET http://localhost:9090/micro/good` (it might be a good idea
-  to reset with `GET http://localhost:9090/micro/reset` first).
-- Add or update the event definition file according to the [Event Dictionary Guide](event_dictionary_guide.md).
-
-#### The Analytics Instrumentation **reviewer** should
-
-- Check that the [event schema](index.md#event-schema) is correct.
-- Check the [usage recommendations](implementation.md#usage-recommendations).
-- Check that an event definition file was created or updated in accordance with the [Event Dictionary Guide](event_dictionary_guide.md).
-- If needed, check that the events are firing locally using one of the
-[testing tools](implementation.md#develop-and-test-snowplow) available.
-- Approve the MR, and relabel the MR with `~"product intelligence::approved"`.
-- If the snowplow event mirrors a RedisHLL event, then tag @mdrussell to review if the payload is usable for this purpose.
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/snowplow/schemas.md b/doc/development/snowplow/schemas.md
index 0ef6ed04aa3..7e00ddd976d 100644
--- a/doc/development/snowplow/schemas.md
+++ b/doc/development/snowplow/schemas.md
@@ -1,189 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/snowplow/schemas.md'
+remove_date: '2023-08-20'
 ---
 
-# Snowplow schemas
+This document was moved to [another location](../internal_analytics/snowplow/schemas.md).
 
-This page provides Snowplow schema reference for GitLab events.
-
-## `gitlab_standard`
-
-We are including the [`gitlab_standard` schema](https://gitlab.com/gitlab-org/iglu/-/blob/master/public/schemas/com.gitlab/gitlab_standard/jsonschema/) for structured events and page views.
-
-The [`StandardContext`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/tracking/standard_context.rb)
-class represents this schema in the application. Some properties are
-[automatically populated for frontend events](implementation.md#snowplow-javascript-frontend-tracking),
-and can be [provided manually for backend events](implementation.md#implement-ruby-backend-tracking).
-
-| Field Name     | Required            | Default value | Type                  | Description                                                                                 |
-|----------------|:-------------------:|-----------------------|--|---------------------------------------------------------------------------------------------|
-| `project_id`   | **{dotted-circle}** | Current project ID * | integer               |                                                                 |
-| `namespace_id` | **{dotted-circle}** | Current group/namespace ID * | integer               |                                                               |
-| `user_id`      | **{dotted-circle}** | Current user ID * | integer               | User database record ID attribute. This value undergoes a pseudonymization process at the collector level. |
-| `context_generated_at` | **{dotted-circle}** | Current timestamp | string (date time format) | Timestamp indicating when context was generated.                                                                |
-| `environment`  | **{check-circle}**  | Current environment | string (max 32 chars) | Name of the source environment, such as `production` or `staging`             |
-| `source`       | **{check-circle}**  | Event source | string (max 32 chars) | Name of the source application, such as  `gitlab-rails` or `gitlab-javascript` |
-| `plan`         | **{dotted-circle}**  | Current namespace plan * | string (max 32 chars) | Name of the plan for the namespace, such as `free`, `premium`, or `ultimate`. Automatically picked from the `namespace`. |
-| `google_analytics_id` | **{dotted-circle}**  | GA ID value * | string (max 32 chars) | Google Analytics ID, present when set from our marketing sites. |
-| `extra`        | **{dotted-circle}**  |  | JSON                  | Any additional data associated with the event, in the form of key-value pairs |
-
-_\* Default value present for frontend events only_
-
-## Default Schema
-
-Frontend events include a [web-specific schema](https://docs.snowplow.io/docs/understanding-your-pipeline/canonical-event/#web-specific-fields) provided by Snowplow.
-All URLs are pseudonymized. The entity identifier [replaces](https://docs.snowplow.io/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracker-setup/other-parameters-2/#setting-a-custom-page-url-and-referrer-url) personally identifiable
-information (PII). PII includes usernames, group, and project names.
-Page titles are hardcoded as `GitLab` for the same reason.
-
-| Field Name               | Required            | Type      | Description                                                                                                                      |
-|--------------------------|---------------------|-----------|----------------------------------------------------------------------------------------------------------------------------------|
-| `app_id`                   | **{check-circle}**  | string    | Unique identifier for website / application                                                                                      |
-| `base_currency`            | **{dotted-circle}** | string    | Reporting currency                                                                                                               |
-| `br_colordepth`            | **{dotted-circle}** | integer   | Browser color depth                                                                                                              |
-| `br_cookies`               | **{dotted-circle}** | boolean   | Does the browser permit cookies?                                                                                                 |
-| `br_family`                | **{dotted-circle}** | string    | Browser family                                                                                                                   |
-| `br_features_director`     | **{dotted-circle}** | boolean   | Director plugin installed?                                                                                                       |
-| `br_features_flash`        | **{dotted-circle}** | boolean   | Flash plugin installed?                                                                                                          |
-| `br_features_gears`        | **{dotted-circle}** | boolean   | Google gears installed?                                                                                                          |
-| `br_features_java`         | **{dotted-circle}** | boolean   | Java plugin installed?                                                                                                           |
-| `br_features_pdf`          | **{dotted-circle}** | boolean   | Adobe PDF plugin installed?                                                                                                      |
-| `br_features_quicktime`    | **{dotted-circle}** | boolean   | Quicktime plugin installed?                                                                                                      |
-| `br_features_realplayer`   | **{dotted-circle}** | boolean   | RealPlayer plugin installed?                                                                                                     |
-| `br_features_silverlight`  | **{dotted-circle}** | boolean   | Silverlight plugin installed?                                                                                                    |
-| `br_features_windowsmedia` | **{dotted-circle}** | boolean   | Windows media plugin installed?                                                                                                  |
-| `br_lang`                  | **{dotted-circle}** | string    | Language the browser is set to                                                                                                   |
-| `br_name`                  | **{dotted-circle}** | string    | Browser name                                                                                                                     |
-| `br_renderengine`          | **{dotted-circle}** | string    | Browser rendering engine                                                                                                         |
-| `br_type`                  | **{dotted-circle}** | string    | Browser type                                                                                                                     |
-| `br_version`               | **{dotted-circle}** | string    | Browser version                                                                                                                  |
-| `br_viewheight`            | **{dotted-circle}** | string    | Browser viewport height                                                                                                          |
-| `br_viewwidth`             | **{dotted-circle}** | string    | Browser viewport width                                                                                                           |
-| `collector_tstamp`         | **{dotted-circle}** | timestamp | Time stamp for the event recorded by the collector                                                                               |
-| `contexts`                 | **{dotted-circle}** |           |                                                                                                                                  |
-| `derived_contexts`         | **{dotted-circle}** |           | Contexts derived in the Enrich process                                                                                           |
-| `derived_tstamp`           | **{dotted-circle}** | timestamp | Timestamp making allowance for inaccurate device clock                                                                          |
-| `doc_charset`              | **{dotted-circle}** | string    | Web page's character encoding                                                                                                    |
-| `doc_height`               | **{dotted-circle}** | string    | Web page height                                                                                                                  |
-| `doc_width`                | **{dotted-circle}** | string    | Web page width                                                                                                                   |
-| `domain_sessionid`         | **{dotted-circle}** | string    | Unique identifier (UUID) for this visit of this `user_id` to this domain                                                         |
-| `domain_sessionidx`        | **{dotted-circle}** | integer   | Index of number of visits that this `user_id` has made to this domain (The first visit is `1`)                                   |
-| `domain_userid`            | **{dotted-circle}** | string    | Unique identifier for a user, based on a first party cookie (so domain specific)                                                 |
-| `dvce_created_tstamp`      | **{dotted-circle}** | timestamp | Timestamp when event occurred, as recorded by client device                                                                      |
-| `dvce_ismobile`            | **{dotted-circle}** | boolean   | Indicates whether device is mobile                                                                                               |
-| `dvce_screenheight`        | **{dotted-circle}** | string    | Screen / monitor resolution                                                                                                      |
-| `dvce_screenwidth`         | **{dotted-circle}** | string    | Screen / monitor resolution                                                                                                      |
-| `dvce_sent_tstamp`         | **{dotted-circle}** | timestamp | Timestamp when event was sent by client device to collector                                                                      |
-| `dvce_type`                | **{dotted-circle}** | string    | Type of device                                                                                                                   |
-| `etl_tags`                 | **{dotted-circle}** | string    | JSON of tags for this ETL run                                                                                                    |
-| `etl_tstamp`               | **{dotted-circle}** | timestamp | Timestamp event began ETL                                                                                                        |
-| `event`                    | **{dotted-circle}** | string    | Event type                                                                                                                       |
-| `event_fingerprint`        | **{dotted-circle}** | string    | Hash client-set event fields                                                                                                     |
-| `event_format`             | **{dotted-circle}** | string    | Format for event                                                                                                                 |
-| `event_id`                 | **{dotted-circle}** | string    | Event UUID                                                                                                                       |
-| `event_name`               | **{dotted-circle}** | string    | Event name                                                                                                                       |
-| `event_vendor`             | **{dotted-circle}** | string    | The company who developed the event model                                                                                        |
-| `event_version`            | **{dotted-circle}** | string    | Version of event schema                                                                                                          |
-| `geo_city`                 | **{dotted-circle}** | string    | City of IP origin                                                                                                                |
-| `geo_country`              | **{dotted-circle}** | string    | Country of IP origin                                                                                                             |
-| `geo_latitude`             | **{dotted-circle}** | string    | An approximate latitude                                                                                                          |
-| `geo_longitude`            | **{dotted-circle}** | string    | An approximate longitude                                                                                                         |
-| `geo_region`               | **{dotted-circle}** | string    | Region of IP origin                                                                                                              |
-| `geo_region_name`          | **{dotted-circle}** | string    | Region of IP origin                                                                                                              |
-| `geo_timezone`             | **{dotted-circle}** | string    | Time zone of IP origin                                                                                                            |
-| `geo_zipcode`              | **{dotted-circle}** | string    | Zip (postal) code of IP origin                                                                                                   |
-| `ip_domain`                | **{dotted-circle}** | string    | Second level domain name associated with the visitor's IP address                                                                |
-| `ip_isp`                   | **{dotted-circle}** | string    | Visitor's ISP                                                                                                                    |
-| `ip_netspeed`              | **{dotted-circle}** | string    | Visitor's connection type                                                                                                        |
-| `ip_organization`          | **{dotted-circle}** | string    | Organization associated with the visitor's IP address – defaults to ISP name if none is found                                    |
-| `mkt_campaign`             | **{dotted-circle}** | string    | The campaign ID                                                                                                                  |
-| `mkt_clickid`              | **{dotted-circle}** | string    | The click ID                                                                                                                     |
-| `mkt_content`              | **{dotted-circle}** | string    | The content or ID of the ad.                                                                   |
-| `mkt_medium`               | **{dotted-circle}** | string    | Type of traffic source                                                                                                           |
-| `mkt_network`              | **{dotted-circle}** | string    | The ad network to which the click ID belongs                                                                                     |
-| `mkt_source`               | **{dotted-circle}** | string    | The company / website where the traffic came from                                                                                |
-| `mkt_term`                 | **{dotted-circle}** | string    | Keywords associated with the referrer                                                                                        |
-| `name_tracker`             | **{dotted-circle}** | string    | The tracker namespace                                                                                                            |
-| `network_userid`           | **{dotted-circle}** | string    | Unique identifier for a user, based on a cookie from the collector (so set at a network level and shouldn't be set by a tracker) |
-| `os_family`                | **{dotted-circle}** | string    | Operating system family                                                                                                          |
-| `os_manufacturer`          | **{dotted-circle}** | string    | Manufacturers of operating system                                                                                                |
-| `os_name`                  | **{dotted-circle}** | string    | Name of operating system                                                                                                         |
-| `os_timezone`              | **{dotted-circle}** | string    | Client operating system time zone                                                                                                 |
-| `page_referrer`            | **{dotted-circle}** | string    | Referrer URL                                                                                                                     |
-| `page_title`               | **{dotted-circle}** | string    | To not expose personal identifying information, the page title is hardcoded as `GitLab`                                          |
-| `page_url`                 | **{dotted-circle}** | string    | Page URL                                                                                                                         |
-| `page_urlfragment`         | **{dotted-circle}** | string    | Fragment aka anchor                                                                                                              |
-| `page_urlhost`             | **{dotted-circle}** | string    | Host aka domain                                                                                                                  |
-| `page_urlpath`             | **{dotted-circle}** | string    | Path to page                                                                                                                     |
-| `page_urlport`             | **{dotted-circle}** | integer   | Port if specified, 80 if not                                                                                                     |
-| `page_urlquery`            | **{dotted-circle}** | string    | Query string                                                                                                                      |
-| `page_urlscheme`           | **{dotted-circle}** | string    | Scheme (protocol name)                                                                                                              |
-| `platform`                 | **{dotted-circle}** | string    | The platform the app runs on                                                                                                     |
-| `pp_xoffset_max`           | **{dotted-circle}** | integer   | Maximum page x offset seen in the last ping period                                                                               |
-| `pp_xoffset_min`           | **{dotted-circle}** | integer   | Minimum page x offset seen in the last ping period                                                                               |
-| `pp_yoffset_max`           | **{dotted-circle}** | integer   | Maximum page y offset seen in the last ping period                                                                               |
-| `pp_yoffset_min`           | **{dotted-circle}** | integer   | Minimum page y offset seen in the last ping period                                                                               |
-| `refr_domain_userid`       | **{dotted-circle}** | string    | The Snowplow `domain_userid` of the referring website                                                                              |
-| `refr_dvce_tstamp`         | **{dotted-circle}** | timestamp | The time of attaching the `domain_userid` to the inbound link                                                                      |
-| `refr_medium`              | **{dotted-circle}** | string    | Type of referer                                                                                                                  |
-| `refr_source`              | **{dotted-circle}** | string    | Name of referer if recognised                                                                                                    |
-| `refr_term`                | **{dotted-circle}** | string    | Keywords if source is a search engine                                                                                            |
-| `refr_urlfragment`         | **{dotted-circle}** | string    | Referer URL fragment                                                                                                             |
-| `refr_urlhost`             | **{dotted-circle}** | string    | Referer host                                                                                                                     |
-| `refr_urlpath`             | **{dotted-circle}** | string    | Referer page path                                                                                                                |
-| `refr_urlport`             | **{dotted-circle}** | integer   | Referer port                                                                                                                     |
-| `refr_urlquery`            | **{dotted-circle}** | string    | Referer URL query string                                                                                                          |
-| `refr_urlscheme`           | **{dotted-circle}** | string    | Referer scheme                                                                                                                   |
-| `se_action`                | **{dotted-circle}** | string    | The action / event itself                                                                                                        |
-| `se_category`              | **{dotted-circle}** | string    | The category of event                                                                                                            |
-| `se_label`                 | **{dotted-circle}** | string    | A label often used to refer to the 'object' the action is performed on                                                           |
-| `se_property`              | **{dotted-circle}** | string    | A property associated with either the action or the object                                                                       |
-| `se_value`                 | **{dotted-circle}** | decimal   | A value associated with the user action                                                                                          |
-| `ti_category`              | **{dotted-circle}** | string    | Item category                                                                                                                    |
-| `ti_currency`              | **{dotted-circle}** | string    | Currency                                                                                                                         |
-| `ti_name`                  | **{dotted-circle}** | string    | Item name                                                                                                                        |
-| `ti_orderid`               | **{dotted-circle}** | string    | Order ID                                                                                                                         |
-| `ti_price`                 | **{dotted-circle}** | decimal   | Item price                                                                                                                       |
-| `ti_price_base`            | **{dotted-circle}** | decimal   | Item price in base currency                                                                                                      |
-| `ti_quantity`              | **{dotted-circle}** | integer   | Item quantity                                                                                                                    |
-| `ti_sku`                   | **{dotted-circle}** | string    | Item SKU                                                                                                                         |
-| `tr_affiliation`           | **{dotted-circle}** | string    | Transaction affiliation (such as channel)                                                                                           |
-| `tr_city`                  | **{dotted-circle}** | string    | Delivery address: city                                                                                                           |
-| `tr_country`               | **{dotted-circle}** | string    | Delivery address: country                                                                                                        |
-| `tr_currency`              | **{dotted-circle}** | string    | Transaction Currency                                                                                                             |
-| `tr_orderid`               | **{dotted-circle}** | string    | Order ID                                                                                                                         |
-| `tr_shipping`              | **{dotted-circle}** | decimal   | Delivery cost charged                                                                                                            |
-| `tr_shipping_base`         | **{dotted-circle}** | decimal   | Shipping cost in base currency                                                                                                   |
-| `tr_state`                 | **{dotted-circle}** | string    | Delivery address: state                                                                                                          |
-| `tr_tax`                   | **{dotted-circle}** | decimal   | Transaction tax value (such as amount of VAT included)                                                                              |
-| `tr_tax_base`              | **{dotted-circle}** | decimal   | Tax applied in base currency                                                                                                     |
-| `tr_total`                 | **{dotted-circle}** | decimal   | Transaction total value                                                                                                          |
-| `tr_total_base`            | **{dotted-circle}** | decimal   | Total amount of transaction in base currency                                                                                     |
-| `true_tstamp`              | **{dotted-circle}** | timestamp | User-set exact timestamp                                                                                                         |
-| `txn_id`                   | **{dotted-circle}** | string    | Transaction ID                                                                                                                   |
-| `unstruct_event`           | **{dotted-circle}** | JSON      | The properties of the event                                                                                                      |
-| `uploaded_at`              | **{dotted-circle}** |           |                                                                                                                                  |
-| `user_fingerprint`         | **{dotted-circle}** | integer   | User identifier based on (hopefully unique) browser features                                                                     |
-| `user_id`                  | **{dotted-circle}** | string    | Unique identifier for user, set by the business using setUserId                                                                  |
-| `user_ipaddress`           | **{dotted-circle}** | string    | IP address                                                                                                                       |
-| `useragent`                | **{dotted-circle}** | string    | User agent (expressed as a browser string)                                                                                                |
-| `v_collector`              | **{dotted-circle}** | string    | Collector version                                                                                                                |
-| `v_etl`                    | **{dotted-circle}** | string    | ETL version                                                                                                                      |
-| `v_tracker`                | **{dotted-circle}** | string    | Identifier for Snowplow tracker                                                                                                  |
-
-## `gitlab_service_ping`
-
-Backend events converted from ServicePing (`redis` and `redis_hll`) must include [ServicePing context](https://gitlab.com/gitlab-org/iglu/-/tree/master/public/schemas/com.gitlab/gitlab_service_ping/jsonschema)
-using the [helper class](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/tracking/service_ping_context.rb).
-
-An example of converted `redis_hll` [event with context](https://gitlab.com/gitlab-org/gitlab/-/edit/master/app/controllers/concerns/product_analytics_tracking.rb#L58).
-
-| Field Name    |      Required       | Type                   | Description                                                                                                                                                        |
-|---------------|:-------------------:|------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `data_source` | **{check-circle}**  | string (max 64 chars)  | The `data_source` attribute from the metrics YAML definition. |
-| `event_name`* | **{dotted-circle}** | string (max 128 chars) | When there is a many-to-many relationship between events and metrics, this field contains the name of a Redis event that can be used for aggregations in downstream systems |
-| `key_path`*   | **{dotted-circle}** | string (max 256 chars) | The `key_path` attribute from the metrics YAML definition |
-
-_\* Either `event_name` or `key_path` is required_
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/snowplow/troubleshooting.md b/doc/development/snowplow/troubleshooting.md
index 92267dfcb0c..ed1f5033239 100644
--- a/doc/development/snowplow/troubleshooting.md
+++ b/doc/development/snowplow/troubleshooting.md
@@ -1,80 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../internal_analytics/snowplow/troubleshooting.md'
+remove_date: '2023-08-20'
 ---
 
-# Troubleshooting Snowplow
+This document was moved to [another location](../internal_analytics/snowplow/troubleshooting.md).
 
-## Monitoring
-
-This page covers dashboards and alerts coming from a number of internal tools.
-
-For a brief video overview of the tools used to monitor Snowplow usage, please check out [this internal video](https://www.youtube.com/watch?v=NxPS0aKa_oU) (you must be logged into GitLab Unfiltered to view).
-
-## Good events drop
-
-### Symptoms
-
-You will be alarmed via a [Sisense alert](https://app.periscopedata.com/app/gitlab/alert/Volume-of-Snowplow-Good-events/5a5f80ef34fe450da5ebb84eaa84067f/edit) that is sent to `#g_product_intelligence` Slack channel
-
-### Locating the problem
-
-First you need to identify at which stage in Snowplow the data pipeline the drop is occurring.
-Start at [Snowplow dashboard](https://console.aws.amazon.com/systems-manager/resource-groups/cloudwatch?dashboard=SnowPlow&region=us-east-1#) on CloudWatch,
-if you do not have access to CloudWatch you need to create an [access request issue](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/9730) first.
-While on CloudWatch dashboard set time range to last 4 weeks, to get better picture of system characteristics over time. Than visit following charts:
-
-1. `ELB New Flow Count` and `Collector Auto Scaling Group Network In/Out` - they show in order: number of connections to collectors via load balancers and data volume (in bytes) processed by collectors. If there is drop visible there, it means less events were fired from the GitLab application. Proceed to [application layer guide](#troubleshooting-gitlab-application-layer) for more details
-1. `Firehose Records to S3` - it shows how many event records were saved to S3 bucket, if there was drop on this chart but not on the charts from 1. it means that problem is located at AWS infrastructure layer, please refer to [AWS layer guide](#troubleshooting-aws-layer)
-1. If drop wasn't visible on any of previous charts it means that problem is at data warehouse layer, please refer to [data warehouse layer guide](#troubleshooting-data-warehouse-layer)
-
-### Troubleshooting GitLab application layer
-
-Drop occurring at application layer can be symptom of some issue, but it might be also a result of normal application lifecycle, intended changes done to product intelligence or experiments tracking
-or even a result of a public holiday in some regions of the world with a larger user-base. To verify if there is an underlying problem to solve, you can check following things:
-
-1. Check `about.gitlab.com` website traffic on [Google Analytics](https://analytics.google.com/analytics/web/) to verify if some public holiday might impact overall use of GitLab system
-   1. You may require to open an access request for Google Analytics access first, for example: [access request internal issue](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/1772)
-1. Plot `select date(dvce_created_tstamp) , event , count(*) from legacy.snowplow_unnested_events_90 where dvce_created_tstamp > '2021-06-15' and dvce_created_tstamp < '2021-07-10' group by 1 , 2 order by 1 , 2` in SiSense to see what type of events was responsible for drop
-1. Plot `select date(dvce_created_tstamp) ,se_category , count(*) from legacy.snowplow_unnested_events_90 where dvce_created_tstamp > '2021-06-15' and dvce_created_tstamp < '2021-07-31' and event = 'struct' group by  1 , 2 order by  1, 2` what events recorded the biggest drops in suspected category
-1. Check if there was any MR merged that might cause reduction in reported events, pay an attention to ~"product intelligence" and ~"growth experiment" labeled MRs
-1. Check (via [Grafana explore tab](https://dashboards.gitlab.net/explore) ) following Prometheus counters `gitlab_snowplow_events_total`, `gitlab_snowplow_failed_events_total` and `gitlab_snowplow_successful_events_total` to see how many events were fired correctly from GitLab.com. Example query to use `sum(rate(gitlab_snowplow_successful_events_total{env="gprd"}[5m])) / sum(rate(gitlab_snowplow_events_total{env="gprd"}[5m]))` would chart rate at which number of good events rose in comparison to events sent in total. If number drops from 1 it means that problem might be in communication between GitLab and AWS collectors fleet.
-1. Check [logs in Kibana](https://log.gprd.gitlab.net/app/discover#) and filter with `{ "query": { "match_phrase": { "json.message": "failed to be reported to collector at" } } }` if there are some failed events logged
-
-For results about an investigation conducted into an unexpected drop in snowplow events volume, see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/335206).
-
-### Troubleshooting AWS layer
-
-Already conducted investigations:
-
-- [Steep decrease of Snowplow page views](https://gitlab.com/gitlab-org/gitlab/-/issues/268009)
-- [`snowplow.trx.gitlab.net` unreachable](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/5073)
-
-### Troubleshooting data warehouse layer
-
-Reach out to [Data team](https://about.gitlab.com/handbook/business-technology/data-team/) to ask about current state of data warehouse. On their handbook page there is a [section with contact details](https://about.gitlab.com/handbook/business-technology/data-team/#how-to-connect-with-us)
-
-## Delay in Snowplow Enrichers
-
-If there is an alert for **Snowplow Raw Good Stream Backing Up**, we receive an email notification. This sometimes happens because Snowplow Enrichers don't scale well enough for the amount of Snowplow events.
-
-If the delay goes over 48 hours, we lose data.
-
-### Contact SRE on-call
-
-Send a message in the [#infrastructure_lounge](https://gitlab.slack.com/archives/CB3LSMEJV) Slack channel using the following template:
-
-```markdown
-Hello team!
-
-We received an alert for [Snowplow Raw Good Stream Backing Up](https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#alarmsV2:alarm/SnowPlow+Raw+Good+Stream+Backing+Up?).
-
-Enrichers are not scalling well for the amount of events we receive.
-
-See the [dashboard](https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#dashboards:name=SnowPlow).
-
-Could we get assistance to fix the delay?
-
-Thank you!
-```
+<!-- This redirect file can be deleted after <2023-08-20>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html
diff --git a/doc/development/spam_protection_and_captcha/graphql_api.md b/doc/development/spam_protection_and_captcha/graphql_api.md
index 383b52df1fc..5723433203b 100644
--- a/doc/development/spam_protection_and_captcha/graphql_api.md
+++ b/doc/development/spam_protection_and_captcha/graphql_api.md
@@ -16,9 +16,8 @@ related to changing a model's confidential/public flag.
 The main steps are:
 
 1. Use `include Mutations::SpamProtection` in your mutation.
-1. Create a `spam_params` instance based on the request. Obtain the request from the context
-   via `context[:request]` when creating the `SpamParams` instance.
-1. Pass `spam_params` to the relevant Service class constructor.
+1. Pass `perform_spam_check: true` to the Update Service class constructor.
+   It is set to `true` by default in the Create Service.
 1. After you create or update the `Spammable` model instance, call `#check_spam_action_response!`
    and pass it the model instance. This call:
    1. Performs the necessary spam checks on the model.
@@ -44,13 +43,10 @@ module Mutations
       include Mutations::SpamProtection
 
       def resolve(args)
-        spam_params = ::Spam::SpamParams.new_from_request(request: context[:request])
-
         service_response = ::Widgets::CreateService.new(
           project: project,
           current_user: current_user,
-          params: args,
-          spam_params: spam_params
+          params: args
         ).execute
 
         widget = service_response.payload[:widget]
diff --git a/doc/development/spam_protection_and_captcha/model_and_services.md b/doc/development/spam_protection_and_captcha/model_and_services.md
index 2c7ec8c3f50..5f91bf47af4 100644
--- a/doc/development/spam_protection_and_captcha/model_and_services.md
+++ b/doc/development/spam_protection_and_captcha/model_and_services.md
@@ -20,7 +20,7 @@ To do this:
 
 1. [Add `Spammable` support to the ActiveRecord model](#add-spammable-support-to-the-activerecord-model).
 1. [Add support for the `mark_as_spam` action to the controller](#add-support-for-the-mark_as_spam-action-to-the-controller).
-1. [Add a call to SpamActionService to the execute method of services](#add-a-call-to-spamactionservice-to-the-execute-method-of-services).
+1. [Add a call to `check_for_spam` to the execute method of services](#add-a-call-to-check_for_spam-to-the-execute-method-of-services).
 
 ## Add `Spammable` support to the ActiveRecord model
 
@@ -80,13 +80,11 @@ NOTE:
 There may be other changes needed to controllers, depending on how the feature is
 implemented. See [Web UI](web_ui.md) for more details.
 
-## Add a call to SpamActionService to the execute method of services
+## Add a call to `check_for_spam` to the execute method of services
 
 This approach applies to any service which can persist spammable attributes:
 
-1. In the relevant Create or Update service under `app/services`, pass in a populated
-   `Spam::SpamParams` instance. (Refer to instructions later on in this page.)
-1. Use it and the `Spammable` model instance to execute a `Spam::SpamActionService` instance.
+1. In the relevant Create or Update service under `app/services`, call the `check_for_spam` method on the model.
 1. If the spam check fails:
    - An error is added to the model, which causes it to be invalid and prevents it from being saved.
    - The `needs_recaptcha` property is set to `true`.
@@ -95,38 +93,24 @@ This approach applies to any service which can persist spammable attributes:
 
 Make these changes to each relevant service:
 
-1. Change the constructor to take a `spam_params:` argument as a required named argument.
-
-   Using named arguments for the constructor helps you identify all the calls to
-   the constructor that need changing. It's less risky because the interpreter raises
-   type errors unless the caller is changed to pass the `spam_params` argument.
-   If you use an IDE (such as RubyMine) which supports this, your
-   IDE flags it as an error in the editor.
-
-1. In the constructor, set the `@spam_params` instance variable from the `spam_params` constructor
-   argument. Add an `attr_reader: :spam_params` in the `private` section of the class.
-
-1. In the `execute` method, add a call to execute the `Spam::SpamActionService`.
+1. In the `execute` method, call the `check_for_spam` method on the model.
    (You can also use `before_create` or `before_update`, if the service
    uses that pattern.) This method uses named arguments, so its usage is clear if
    you refer to existing examples. However, two important considerations exist:
-   1. The `SpamActionService` must be executed _after_ all necessary changes are made to
+   1. The `check_for_spam` must be executed _after_ all necessary changes are made to
       the unsaved (and dirty) `Spammable` model instance. This ordering ensures
       spammable attributes exist to be spam-checked.
-   1. The `SpamActionService` must be executed _before_ the model is checked for errors and
+   1. The `check_for_spam` must be executed _before_ the model is checked for errors and
       attempting a `save`. If potential spam is detected in the model's changed attributes, we must prevent a save.
 
 ```ruby
 module Widget
   class CreateService < ::Widget::BaseService
-    # NOTE: We require the spam_params and do not default it to nil, because
-    # spam_checking is likely to be necessary.  However, if there is not a request available in scope
-    # in the caller (for example, a note created via email) and the required arguments to the
-    # SpamParams constructor are not otherwise available, spam_params: must be explicitly passed as nil.
-    def initialize(project:, current_user: nil, params: {}, spam_params:)
+    # NOTE: We add a default value of `true` for `perform_spam_check`, because spam checking is likely to be necessary.
+    def initialize(project:, current_user: nil, params: {}, perform_spam_check: true)
       super(project: project, current_user: current_user, params: params)
 
-      @spam_params = spam_params
+      @perform_spam_check = perform_spam_check
     end
 
     def execute
@@ -136,13 +120,7 @@ module Widget
 
       # NOTE: do this AFTER the spammable model is instantiated, but BEFORE
       # it is validated or saved.
-      Spam::SpamActionService.new(
-        spammable: widget,
-        spam_params: spam_params,
-        user: current_user,
-        # Or `action: :update` for a UpdateService or service for an existing model.
-        action: :create
-      ).execute
+      widget.check_for_spam(user: current_user, action: :create) if perform_spam_check
 
       # Possibly more code related to saving model, but should not change any attributes.
 
@@ -151,5 +129,5 @@ module Widget
 
     private
 
-    attr_reader :spam_params
+    attr_reader :perform_spam_check
 ```
diff --git a/doc/development/spam_protection_and_captcha/rest_api.md b/doc/development/spam_protection_and_captcha/rest_api.md
index d7012ffb418..76ffbc2f157 100644
--- a/doc/development/spam_protection_and_captcha/rest_api.md
+++ b/doc/development/spam_protection_and_captcha/rest_api.md
@@ -16,8 +16,8 @@ related to changing a model's confidential/public flag.
 The main steps are:
 
 1. Add `helpers SpammableActions::CaptchaCheck::RestApiActionsSupport` in your `resource`.
-1. Create a `spam_params` instance based on the request.
-1. Pass `spam_params` to the relevant Service class constructor.
+1. Pass `perform_spam_check: true` to the Update Service class constructor.
+   It is set to `true` by default in the Create Service.
 1. After you create or update the `Spammable` model instance, call `#check_spam_action_response!`,
    save the created or updated instance in a variable.
 1. Identify the error handling logic for the `failure` case of the request,
@@ -53,8 +53,7 @@ module API
 
       post do
         #...
-        spam_params = ::Spam::SpamParams.new_from_request(request: request)
-        service_response = ::Snippets::CreateService.new(project: nil, current_user: current_user, params: attrs, spam_params: spam_params).execute
+        service_response = ::Snippets::CreateService.new(project: nil, current_user: current_user, params: attrs).execute
         snippet = service_response.payload[:snippet]
 
         if service_response.success?
@@ -71,8 +70,7 @@ module API
 
       put ':id' do
         #...
-        spam_params = ::Spam::SpamParams.new_from_request(request: request)
-        service_response = ::Snippets::UpdateService.new(project: nil, current_user: current_user, params: attrs, spam_params: spam_params).execute(snippet)
+        service_response = ::Snippets::UpdateService.new(project: nil, current_user: current_user, params: attrs, perform_spam_check: true).execute(snippet)
 
         snippet = service_response.payload[:snippet]
 
diff --git a/doc/development/spam_protection_and_captcha/web_ui.md b/doc/development/spam_protection_and_captcha/web_ui.md
index 0ae5e98f399..0cc17854010 100644
--- a/doc/development/spam_protection_and_captcha/web_ui.md
+++ b/doc/development/spam_protection_and_captcha/web_ui.md
@@ -75,11 +75,9 @@ sequenceDiagram
 The backend is also cleanly abstracted via mixin modules and helper methods. The three main
 changes required to the relevant backend controller actions (normally just `create`/`update`) are:
 
-1. Create a `SpamParams` parameter object instance based on the request, using the static
-   `#new_from_request` factory method. This method takes a request, and returns a `SpamParams` instance.
-1. Pass the created `SpamParams` instance as the `spam_params` named argument to the
-   Service class constructor, which you should have already added. If the spam check indicates
-   the changes to the model are possibly spam, then:
+1. Pass `perform_spam_check: true` to the Update Service class constructor.
+   It is set to `true` by default in the Create Service.
+1. If the spam check indicates the changes to the model are possibly spam, then:
    - An error is added to the model.
    - The `needs_recaptcha` property on the model is set to true.
 1. Wrap the existing controller action return value (rendering or redirecting) in a block passed to
@@ -116,12 +114,10 @@ module WidgetsActions
   include SpammableActions::CaptchaCheck::JsonFormatActionsSupport
 
   def create
-    spam_params = ::Spam::SpamParams.new_from_request(request: request)
     widget = ::Widgets::CreateService.new(
       project: project,
       current_user: current_user,
-      params: params,
-      spam_params: spam_params
+      params: params
     ).execute
 
     respond_to do |format|
@@ -166,13 +162,11 @@ class WidgetsController < ApplicationController
 
   def update
     # Existing logic to find the `widget` model instance...
-
-    spam_params = ::Spam::SpamParams.new_from_request(request: request)
     ::Widgets::UpdateService.new(
       project: project,
       current_user: current_user,
       params: params,
-      spam_params: spam_params
+      perform_spam_check: true
     ).execute(widget)
 
     respond_to do |format|
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index e257bddb900..90267a517b8 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -388,9 +388,10 @@ With [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/375983) we defined th
 
 For tests that are not meeting the thresholds it is recommended to create issues and improve the tests duration.
 
-| Date | Feature tests | Controllers and Requests tests | Other |
-| --- | --- | --- | --- |
-| 2023-02-15 | 67.42 seconds | 44.66 seconds | 76.86 seconds |
+| Date | Feature tests | Controllers and Requests tests | Unit | Other | Method |
+| :-: | :-: | :-: | :-: | :-: | :-: |
+| 2023-02-15 | 67.42 seconds | 44.66 seconds | - | 76.86 seconds | Top slow test eliminating the maximum |
+| 2023-06-15 | 50.13 seconds | 19.20 seconds | 27.12 | 45.40 seconds | Avg for top 100 slow tests|
 
 #### Avoid repeating expensive actions
 
@@ -1140,8 +1141,17 @@ variables example can be used, but avoid this if at all possible.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61171) in GitLab 14.0.
 
 Specs that require Elasticsearch must be marked with the `:elastic` trait. This
-creates and deletes indices between examples to ensure a clean index, so that there is no room
-for polluting the tests with nonessential data.
+creates and deletes indices before and after all examples.
+
+The `:elastic_delete_by_query` trait was added to reduce runtime for pipelines by creating and deleting indices at the
+start and end of each context only. The [Elasticsearch delete by query API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete-by-query.html)
+is used to delete data in all indices between examples to ensure a clean index.
+
+The `:elastic_clean` trait creates and deletes indices between examples to ensure a clean index. This way, tests are not
+polluted with non-essential data. If using the `:elastic` or `:elastic_delete_by_query` trait
+is causing issues, use `:elastic_clean` instead. `:elastic_clean` is significantly slower than the other traits
+and should be used sparingly.
+
 Most tests for Elasticsearch logic relate to:
 
 - Creating data in PostgreSQL and waiting for it to be indexed in Elasticsearch.
@@ -1150,11 +1160,8 @@ Most tests for Elasticsearch logic relate to:
 
 There are some exceptions, such as checking for structural changes rather than individual records in an index.
 
-The `:elastic_delete_by_query` trait was added to reduce run time for pipelines by creating and deleting indices
-at the start and end of each context only. The [Elasticsearch DeleteByQuery API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete-by-query.html)
-is used to delete data in all indices in between examples to ensure a clean index.
-
-Note that Elasticsearch indexing uses [`Gitlab::Redis::SharedState`](../../../ee/development/redis.md#gitlabrediscachesharedstatequeues).
+NOTE:
+Elasticsearch indexing uses [`Gitlab::Redis::SharedState`](../../../ee/development/redis.md#gitlabrediscachesharedstatequeues).
 Therefore, the Elasticsearch traits dynamically use the `:clean_gitlab_redis_shared_state` trait.
 You do not need to add `:clean_gitlab_redis_shared_state` manually.
 
diff --git a/doc/development/testing_guide/end_to_end/capybara_to_chemlab_migration_guide.md b/doc/development/testing_guide/end_to_end/capybara_to_chemlab_migration_guide.md
index f3911176263..7bac76c88e8 100644
--- a/doc/development/testing_guide/end_to_end/capybara_to_chemlab_migration_guide.md
+++ b/doc/development/testing_guide/end_to_end/capybara_to_chemlab_migration_guide.md
@@ -13,21 +13,21 @@ Given the view:
 ```html
 <form id="my-form">
     <label for="first-name">First name</label>
-    <input type="text" name="first-name" data-qa-selector="first_name" />
+    <input type="text" name="first-name" data-testid="first_name" />
 
     <label for="last-name">Last name</label>
-    <input type="text" name="last-name" data-qa-selector="last_name" />
+    <input type="text" name="last-name" data-testid="last_name" />
 
     <label for="company-name">Company name</label>
-    <input type="text" name="company-name" data-qa-selector="company_name" />
+    <input type="text" name="company-name" data-testid="company_name" />
 
     <label for="user-name">User name</label>
-    <input type="text" name="user-name" data-qa-selector="user_name" />
+    <input type="text" name="user-name" data-testid="user_name" />
 
     <label for="password">Password</label>
-    <input type="password" name="password" data-qa-selector="password" />
+    <input type="password" name="password" data-testid="password" />
 
-    <input type="submit" value="Continue" data-qa-selector="continue"/>
+    <input type="submit" value="Continue" data-testid="continue"/>
 </form>
 ```
 
@@ -137,12 +137,12 @@ Since the element type is preserved within the Page Library, there is no need to
 
 ```html
 <!-- Before -->
-<input type="text" name="first-name" data-qa-selector="first_name_field" />
-<input type="submit" name="continue" value="Continue" data-qa-selector="continue_button" />
+<input type="text" name="first-name" data-testid="first_name_field" />
+<input type="submit" name="continue" value="Continue" data-testid="continue_button" />
 
 <!-- After -->
-<input type="text" name="first-name" data-qa-selector="first_name" />
-<input type="submit" name="continue" value="Continue" data-qa-selector="continue" />
+<input type="text" name="first-name" data-testid="first_name" />
+<input type="submit" name="continue" value="Continue" data-testid="continue" />
 ```
 
 This makes it much easier for Developers to write tests and contributes to testability since we can write the Page Library while we look at the UI.
diff --git a/doc/development/testing_guide/end_to_end/execution_context_selection.md b/doc/development/testing_guide/end_to_end/execution_context_selection.md
index 4d83884f4d0..0082bb6ee23 100644
--- a/doc/development/testing_guide/end_to_end/execution_context_selection.md
+++ b/doc/development/testing_guide/end_to_end/execution_context_selection.md
@@ -44,8 +44,8 @@ Matches use:
 | `gitlab.com and staging.gitlab.com`      | `only: { subdomain: /(staging.)?/, domain: 'gitlab' }` | `(staging.)?gitlab.com` |
 | `dev.gitlab.org`                         | `only: { tld: '.org', domain: 'gitlab', subdomain: 'dev' }` | `(dev).gitlab.org` |
 | `staging.gitlab.com and domain.gitlab.com` | `only: { subdomain: %i[staging domain] }` | `(staging\|domain).+.com`             |
-| The `nightly` pipeline                     | `only: { pipeline: :nightly }` | "nightly" |
-| The `nightly` and `canary` pipelines | `only: { pipeline: [:nightly, :canary] }` | ["nightly"](https://gitlab.com/gitlab-org/quality/nightly) and ["canary"](https://gitlab.com/gitlab-org/quality/canary) |
+| The `nightly` pipeline                     | `only: { pipeline: :nightly }` | ["nightly scheduled pipeline"](https://gitlab.com/gitlab-org/gitlab/-/pipeline_schedules) |
+| The `nightly` and `canary` pipelines | `only: { pipeline: [:nightly, :canary] }` | ["nightly scheduled pipeline"](https://gitlab.com/gitlab-org/gitlab/-/pipeline_schedules) and ["canary"](https://gitlab.com/gitlab-org/quality/canary) |
 | The `ee:instance` job | `only: { job: 'ee:instance' }` | The `ee:instance` job in any pipeline |
 | Any `quarantine` job | `only: { job: '.*quarantine' }` | Any job ending in `quarantine` in any pipeline |
 | Any run where condition evaluates to a truthy value | `only: { condition: -> { ENV['TEST_ENV'] == 'true' } }` | Any run where `TEST_ENV` is set to true
@@ -87,8 +87,8 @@ Matches use:
 | `gitlab.com and staging.gitlab.com`      | `except: { subdomain: /(staging.)?/, domain: 'gitlab' }` | `(staging.)?gitlab.com` |
 | `dev.gitlab.org`                         | `except: { tld: '.org', domain: 'gitlab', subdomain: 'dev' }` | `(dev).gitlab.org` |
 | `staging.gitlab.com and domain.gitlab.com` | `except: { subdomain: %i[staging domain] }` | `(staging\|domain).+.com`             |
-| The `nightly` pipeline                     | `except: { pipeline: :nightly }` | ["nightly"](https://gitlab.com/gitlab-org/quality/nightly) |
-| The `nightly` and `canary` pipelines | `except: { pipeline: [:nightly, :canary] }` | ["nightly"](https://gitlab.com/gitlab-org/quality/nightly) and ["canary"](https://gitlab.com/gitlab-org/quality/canary) |
+| The `nightly` pipeline                     | `only: { pipeline: :nightly }` | ["nightly scheduled pipeline"](https://gitlab.com/gitlab-org/gitlab/-/pipeline_schedules) |
+| The `nightly` and `canary` pipelines | `only: { pipeline: [:nightly, :canary] }` | ["nightly scheduled pipeline"](https://gitlab.com/gitlab-org/gitlab/-/pipeline_schedules) and ["canary"](https://gitlab.com/gitlab-org/quality/canary) |
 | The `ee:instance` job | `except: { job: 'ee:instance' }` | The `ee:instance` job in any pipeline |
 | Any `quarantine` job | `except: { job: '.*quarantine' }` | Any job ending in `quarantine` in any pipeline |
 | Any run except where condition evaluates to a truthy value | `except: { condition: -> { ENV['TEST_ENV'] == 'true' } }` | Any run where `TEST_ENV` is not set to true
diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md
index 77ceb9fa546..adf679c44a2 100644
--- a/doc/development/testing_guide/end_to_end/index.md
+++ b/doc/development/testing_guide/end_to_end/index.md
@@ -21,8 +21,8 @@ using the [GitLab QA orchestrator](https://gitlab.com/gitlab-org/gitlab-qa) tool
 ### Testing nightly builds
 
 We run scheduled pipelines each night to test nightly builds created by Omnibus.
-You can find these pipelines at <https://gitlab.com/gitlab-org/quality/nightly/pipelines>
-(requires the Developer role). Results are reported in the `#qa-nightly` Slack channel.
+You can find these pipelines at <https://gitlab.com/gitlab-org/gitlab/-/pipeline_schedules>
+(requires the Developer role). Results are reported in the `#qa-master` Slack channel.
 
 ### Testing staging
 
@@ -97,8 +97,8 @@ This problem was discovered in <https://gitlab.com/gitlab-org/gitlab-qa/-/issues
 work-around was suggested in <https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4717>.
 A feature proposal to segregate access control regarding running pipelines from ability to push/merge was also created at <https://gitlab.com/gitlab-org/gitlab/-/issues/24585>.
 
-For more technical details on CI/CD setup and documentation on adding new test jobs to `package-and-test` pipeline, see
-[`package_and_test` setup documentation](package_and_test_pipeline.md).
+For more technical details on CI/CD setup and documentation on adding new test jobs to `e2e:package-and-test` pipeline, see
+[`e2e:package_and_test` setup documentation](package_and_test_pipeline.md).
 
 #### With merged results pipelines
 
@@ -165,8 +165,8 @@ In order to limit amount of tests executed in a merge request, dynamic selection
 on changed files and merge request labels. Following criteria determine which tests will run:
 
 1. Changes in `qa` framework code would execute the full suite
-1. Changes in particular `_spec.rb` file in `qa` folder would execute only that particular test
-1. Merge request with backend changes and label `devops::manage` would execute all e2e tests related to `manage` stage
+1. Changes in particular `_spec.rb` file in `qa` folder would execute only that particular test. In this case knapsack will not be used to run jobs in parallel.
+1. Merge request with backend changes and label `devops::manage` would execute all e2e tests related to `manage` stage. Jobs will be run in parallel in this case using knapsack.
 
 #### Overriding selective test execution
 
@@ -198,7 +198,7 @@ Use these environment variables to configure metrics export:
 | -------- | -------- | ----------- |
 | `QA_INFLUXDB_URL` | `true` | Should be set to `https://influxdb.quality.gitlab.net`. No default value. |
 | `QA_INFLUXDB_TOKEN` | `true` | InfluxDB write token that can be found under `Influxdb auth tokens` document in `Gitlab-QA` `1Password` vault. No default value. |
-| `QA_RUN_TYPE` | `false` | Arbitrary name for test execution, like `package-and-test`. Automatically inferred from the project name for live environment test executions. No default value. |
+| `QA_RUN_TYPE` | `false` | Arbitrary name for test execution, like `e2e:package-and-test`. Automatically inferred from the project name for live environment test executions. No default value. |
 | `QA_EXPORT_TEST_METRICS` | `false` | Flag to enable or disable metrics export to InfluxDB. Defaults to `false`. |
 | `QA_SAVE_TEST_METRICS` | `false` | Flag to enable or disable saving metrics as JSON file. Defaults to `false`. |
 
diff --git a/doc/development/testing_guide/end_to_end/page_objects.md b/doc/development/testing_guide/end_to_end/page_objects.md
index 6a599ce9a50..3e13aaa4f02 100644
--- a/doc/development/testing_guide/end_to_end/page_objects.md
+++ b/doc/development/testing_guide/end_to_end/page_objects.md
@@ -98,7 +98,7 @@ end
 The `view` DSL method corresponds to the Rails view, partial, or Vue component that renders the elements.
 
 The `element` DSL method in turn declares an element for which a corresponding
-`data-qa-selector=element_name_snaked` data attribute must be added to the view file.
+`testid=element_name` data attribute must be added, if not already, to the view file.
 
 You can also define a value (String or Regexp) to match to the actual view
 code but **this is deprecated** in favor of the above method for two reasons:
@@ -112,7 +112,7 @@ view 'app/views/my/view.html.haml' do
 
   ### Good ###
 
-  # Implicitly require the CSS selector `[data-qa-selector="logout_button"]` to be present in the view
+  # Implicitly require the CSS selector `[data-testid="logout_button"]` to be present in the view
   element :logout_button
 
   ### Bad ###
@@ -140,38 +140,38 @@ view 'app/views/my/view.html.haml' do
 end
 ```
 
-To add these elements to the view, you must change the Rails view, partial, or Vue component by adding a `data-qa-selector` attribute
+To add these elements to the view, you must change the Rails view, partial, or Vue component by adding a `data-testid` attribute
 for each element defined.
 
-In our case, `data-qa-selector="login_field"`, `data-qa-selector="password_field"` and `data-qa-selector="sign_in_button"`
+In our case, `data-testid="login_field"`, `data-testid="password_field"` and `data-testid="sign_in_button"`
 
 `app/views/my/view.html.haml`
 
 ```haml
-= f.text_field :login, class: "form-control top", autofocus: "autofocus", autocapitalize: "off", autocorrect: "off", required: true, title: "This field is required.", data: { qa_selector: 'login_field' }
-= f.password_field :password, class: "form-control bottom", required: true, title: "This field is required.", data: { qa_selector: 'password_field' }
-= f.submit "Sign in", class: "btn btn-confirm", data: { qa_selector: 'sign_in_button' }
+= f.text_field :login, class: "form-control top", autofocus: "autofocus", autocapitalize: "off", autocorrect: "off", required: true, title: "This field is required.", data: { testid: 'login_field' }
+= f.password_field :password, class: "form-control bottom", required: true, title: "This field is required.", data: { testid: 'password_field' }
+= f.submit "Sign in", class: "btn btn-confirm", data: { testid: 'sign_in_button' }
 ```
 
 Things to note:
 
-- The name of the element and the `qa_selector` must match and be snake cased
+- The name of the element and the `data-testid` must match and be either snake cased or kebab cased
 - If the element appears on the page unconditionally, add `required: true` to the element. See
   [Dynamic element validation](dynamic_element_validation.md)
-- You may see `.qa-selector` classes in existing Page Objects. We should prefer the [`data-qa-selector`](#data-qa-selector-vs-qa-selector)
-  method of definition over the `.qa-selector` CSS class
+- You may see `data-qa-selector` classes in existing Page Objects. We should prefer the [`data-testid`](#data-testid-vs-data-qa-selector)
+  method of definition over the `data-qa-selector` CSS class
 
-### `data-qa-selector` vs `.qa-selector`
+### `data-testid` vs `data-qa-selector`
 
-> Introduced in GitLab 12.1
+> Introduced in GitLab 16.1
 
 There are two supported methods of defining elements within a view.
 
+1. `data-testid`
 1. `data-qa-selector` attribute
-1. `.qa-selector` class
 
-Any existing `.qa-selector` class should be considered deprecated
-and we should prefer the `data-qa-selector` method of definition.
+Any existing `data-qa-selector` class should be considered deprecated
+and we should prefer the `data-testid` method of definition.
 
 ### Dynamic element selection
 
@@ -193,7 +193,7 @@ Given the following Rails view (using GitLab Issues as an example):
 ```haml
 %ul.issues-list
  - @issues.each do |issue|
-   %li.issue{data: { qa_selector: 'issue', qa_issue_title: issue.title } }= link_to issue
+   %li.issue{data: { testid: 'issue', qa_issue_title: issue.title } }= link_to issue
 ```
 
 We can select on that specific issue by matching on the Rails model.
@@ -225,7 +225,7 @@ end
 ```haml
 %ol
   - @some_model.each_with_index do |model, idx|
-    %li.model{ data: { qa_selector: 'model', qa_index: idx } }
+    %li.model{ data: { testid: 'model', qa_index: idx } }
 ```
 
 ```ruby
diff --git a/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md b/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
index a42d5e3df1d..b698eb53f75 100644
--- a/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
+++ b/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
@@ -35,8 +35,7 @@ This is a partial list of the [RSpec metadata](https://rspec.info/features/3-12/
 | `:mixed_env`                | The test should only be executed in environments that have a paired canary version available through traffic routing based on the existence of the `gitlab_canary=true` cookie. Tests in this category are switching the cookie mid-test to validate mixed deployment environments.                                                                                                                                                                                                                          |
 | `:object_storage`           | The test requires a GitLab instance to be configured to use multiple [object storage types](../../../administration/object_storage.md). Uses MinIO as the object storage server.                                                                                                                                                                                                                                                                                                                             |
 | `:only`                     | The test is only to be run in specific execution contexts. See [test execution context selection](execution_context_selection.md) for more information.                                                                                                                                                                                                                                                                                                                                                      |
-| `:orchestrated`             | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate Docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify the GitLab configuration (for example, Staging).                             |
-| `:packages`                 | The test requires a GitLab instance that has the [Package Registry](../../../administration/packages/index.md#gitlab-package-registry-administration) enabled.                                                                                                                                                                                                                                                                                                                                                       |
+| `:orchestrated`             | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate Docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify the GitLab configuration (for example, Staging).                             |                                                                       |
 | `:product_group`            | Specifies what product group the test belongs to. See [Product sections, stages, groups, and categories](https://about.gitlab.com/handbook/product/categories/) for the comprehensive groups list.                                                                                                                                                                                                                                                                                                            |
 | `:quarantine`               | The test has been [quarantined](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/debugging-qa-test-failures/#quarantining-tests), runs in a separate job that only includes quarantined tests, and is allowed to fail. The test is skipped in its regular job so that if it fails it doesn't hold up the pipeline. Note that you can also [quarantine a test only when it runs in a specific context](execution_context_selection.md#quarantine-a-test-for-a-specific-environment). |
 | `:relative_url`             | The test requires a GitLab instance to be installed under a [relative URL](../../../install/relative_url.md).                                                                                                                                                                                                                                                                                                                                                                                                |
diff --git a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
index adf7bccb7fb..0544b331b1a 100644
--- a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
+++ b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
@@ -428,8 +428,6 @@ For instructions on how to run these tests using the `gitlab-qa` gem, please ref
 
 Tests that are tagged with `:mobile` can be run against specified mobile devices using cloud emulator/simulator services.
 
-These tests run in the [nightly pipeline](https://gitlab.com/gitlab-org/quality/nightly/-/pipelines) in the `ce:remote_mobile_safari` job.
-
 ### How to run mobile tests with Sauce Labs
 
 Running directly against an environment like staging is not recommended because Sauce Labs test logs expose credentials. Therefore, it is best practice and the default to use a tunnel.
@@ -587,18 +585,18 @@ You can verify whether GitLab is appropriately redirecting your session to the `
 
 The above spec is verbose, written specifically this way to ensure the idea behind the implementation is clear. We recommend following the practices detailed within our [Beginner's guide to writing end-to-end tests](beginners_guide.md).
 
-## OpenID Connect (OIDC) tests
+## Tests for GitLab as OpenID Connect (OIDC) and OAuth provider
 
-To run the [`login_via_oidc_with_gitlab_as_idp_spec`](https://gitlab.com/gitlab-org/gitlab/-/blob/188e2c876a17a097448d7f3ed35bdf264fed0d3b/qa/qa/specs/features/browser_ui/1_manage/login/login_via_oidc_with_gitlab_as_idp_spec.rb) on your local machine:
+To run the [`login_via_oauth_and_oidc_with_gitlab_as_idp_spec`](https://gitlab.com/gitlab-org/gitlab/-/blob/2e2c8bcfa4f68cd39041806af531038ce4d2ab04/qa/qa/specs/features/browser_ui/1_manage/login/login_via_oauth_and_oidc_with_gitlab_as_idp_spec.rb) on your local machine:
 
 1. Make sure your GDK is set to run on a non-localhost address such as `gdk.test:3000`.
 1. Configure a [loopback interface to 172.16.123.1](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/6fe7b46403229f12ab6d903f99b024e0b82cb94a/doc/howto/local_network.md#create-loopback-interface).
 1. Make sure Docker Desktop or Rancher Desktop is running.
-1. Add an entry to your `/etc/hosts` file for `gitlab-oidc-consumer.bridge` pointing to `127.0.0.1`.
+1. Add an entry to your `/etc/hosts` file for `gitlab-oidc-consumer.bridge` and `gitlab-oauth-consumer.bridge` pointing to `127.0.0.1`.
 1. From the `qa` directory, run the following command. To set the GitLab image you want to use, update the `RELEASE` variable. For example, to use the latest EE image, set `RELEASE` to `gitlab/gitlab-ee:latest`:
 
    ```shell
    bundle install
 
-   RELEASE_REGISTRY_URL='registry.gitlab.com' RELEASE_REGISTRY_USERNAME='<your_gitlab_username>' RELEASE_REGISTRY_PASSWORD='<your_gitlab_personal_access_token>' RELEASE='registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:1d5a644145dfe901ea7648d825f8f9f3006d0acf' GITLAB_QA_ADMIN_ACCESS_TOKEN="<your_gdk_admin_personal_access_token>" QA_DEBUG=true CHROME_HEADLESS=false bundle exec bin/qa Test::Instance::All http://gdk.test:3000 qa/specs/features/browser_ui/1_manage/login/login_via_oidc_with_gitlab_as_idp_spec.rb
+   RELEASE_REGISTRY_URL='registry.gitlab.com' RELEASE_REGISTRY_USERNAME='<your_gitlab_username>' RELEASE_REGISTRY_PASSWORD='<your_gitlab_personal_access_token>' RELEASE='registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:c0ae46db6b31ea231b2de88961cd687acf634179' GITLAB_QA_ADMIN_ACCESS_TOKEN="<your_gdk_admin_personal_access_token>" QA_DEBUG=true CHROME_HEADLESS=false bundle exec bin/qa Test::Instance::All http://gdk.test:3000 qa/specs/features/browser_ui/1_manage/login/login_via_oauth_and_oidc_with_gitlab_as_idp_spec.rb
    ```
diff --git a/doc/development/testing_guide/end_to_end/test_infrastructure.md b/doc/development/testing_guide/end_to_end/test_infrastructure.md
new file mode 100644
index 00000000000..00d4507d35e
--- /dev/null
+++ b/doc/development/testing_guide/end_to_end/test_infrastructure.md
@@ -0,0 +1,32 @@
+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# End-to-end Testing Infrastructure for Cloud Integrations
+
+This content is about infrastructure we integrate with GitLab QA test scenarios, at the end-to-end level.
+
+## What infrastructure do we have in place?
+
+We currently use GCP and AWS platforms to test a few end-to-end scenarios. These are separated from other
+sandbox projects to prevent accidental deletion of resources that run beyond automated test runs. If you do not have
+access to these accounts already, you can create an access request. In GCP, we use `group-qa-tests-566cc6`
+and in AWS, the cloud account `eng-quality-ops-ci-cd-shared-infra-498dbd5a`.
+
+If you have test scenarios that require these platforms, we encourage you to use the existing infrastructure and
+accounts so we can efficiently consolidate and maintain our end-to-end test suite.
+
+## Why do we have this infrastructure?
+
+GitLab has several features that integrate well with known Cloud Providers. To fully test this integration,
+we have infrastructure in place that connects GitLab QA with these providers.
+
+We currently use GCP for its Cloud Storage resources to test Object Storage (GCS) and to create Kubernetes clusters. We also use AWS to test Object Storage (S3).
+
+## How do we maintain this infrastructure?
+
+We have an active [Janitor](https://gitlab.com/gitlab-com/gl-infra/gitlab-gcp-janitor) project that ensures resources in GCP are cleaned up if a test fails to remove it. The Janitor jobs run daily on a scheduled pipeline and target exclusively GCP `group-qa-tests-566cc6`.
+
+AWS uses lifecycle management rules to delete objects after 1 day. We have an established [process](https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/blob/main/runbooks/rotating-credentials.md) that enables anyone with access to these environments to rotate credentials.
diff --git a/doc/development/testing_guide/flaky_tests.md b/doc/development/testing_guide/flaky_tests.md
index 40be7a7d094..9114ec3d179 100644
--- a/doc/development/testing_guide/flaky_tests.md
+++ b/doc/development/testing_guide/flaky_tests.md
@@ -13,62 +13,48 @@ eventually.
 
 ## What are the potential cause for a test to be flaky?
 
-### Unclean environment
+### State leak
 
-**Label:** `flaky-test::unclean environment`
+**Label:** `flaky-test::state leak`
 
-**Description:** The environment got dirtied by a previous test. The actual cause is probably not the flaky test here.
+**Description:** Data state has leaked from a previous test. The actual cause is probably not the flaky test here.
 
 **Difficulty to reproduce:** Moderate. Usually, running the same spec files until the one that's failing reproduces the problem.
 
-**Resolution:** Fix the previous tests and/or places where the environment is modified, so that
+**Resolution:** Fix the previous tests and/or places where the test data or environment is modified, so that
 it's reset to a pristine test after each test.
 
 **Examples:**
 
-- [Example 1](https://gitlab.com/gitlab-org/gitlab/-/issues/378414#note_1142026988): A migration
+- [Example 1](https://gitlab.com/gitlab-org/gitlab/-/issues/402915): State leakage can result from
+  data records created with `let_it_be` shared between test examples, while some test modifies the model
+  either deliberately or unwillingly causing out-of-sync data in test examples. This can result in `PG::QueryCanceled: ERROR` in the subsequent test examples or retries.
+  For more information about state leakages and resolution options, see [GitLab testing best practices](best_practices.md#lets-talk-about-let).
+- [Example 2](https://gitlab.com/gitlab-org/gitlab/-/issues/378414#note_1142026988): A migration
   test might roll-back the database, perform its testing, and then roll-up the database in an
   inconsistent state, so that following tests might not know about certain columns.
-- [Example 2](https://gitlab.com/gitlab-org/gitlab/-/issues/368500): A test modifies data that is
+- [Example 3](https://gitlab.com/gitlab-org/gitlab/-/issues/368500): A test modifies data that is
   used by a following test.
-- [Example 3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/103434#note_1172316521): A test for a database query passes in a fresh database, but in a
+- [Example 4](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/103434#note_1172316521): A test for a database query passes in a fresh database, but in a
   CI/CD pipeline where the database is used to process previous test sequences, the test fails. This likely
-    means that the query itself needs to be updated to work in a non-clean database.
-
-### Ordering assertion
-
-**Label:** `flaky-test::ordering assertion`
-
-**Description:** The test is expecting a specific order in the data under test yet the data is in
-a non-deterministic order.
-
-**Difficulty to reproduce:** Easy. Usually, running the test locally several times would reproduce
-the problem.
-
-**Resolution:** Depending on the problem, you might want to:
-
-- loosen the assertion if the test shouldn't care about ordering but only on the elements
-- fix the test by specifying a deterministic ordering
-- fix the app code by specifying a deterministic ordering
-
-**Examples:**
-
-- [Example 1](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10148/diffs): Without
-  specifying `ORDER BY`, database will not give deterministic ordering, or data race happening
-  in the tests.
-- [Example 2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106936/diffs).
+  means that the query itself needs to be updated to work in a non-clean database.
 
 ### Dataset-specific
 
 **Label:** `flaky-test::dataset-specific`
 
-**Description:** The test assumes the dataset is in a particular (usually limited) state, which
+**Description:** The test assumes the dataset is in a particular (usually limited) state or order, which
 might not be true depending on when the test run during the test suite.
 
 **Difficulty to reproduce:** Moderate, as the amount of data needed to reproduce the issue might be
-difficult to achieve locally.
+difficult to achieve locally. Ordering issues are easier to reproduce by repeatedly running the tests several times.
 
-**Resolution:** Fix the test to not assume that the dataset is in a particular state, don't hardcode IDs.
+**Resolution:**
+
+- Fix the test to not assume that the dataset is in a particular state, don't hardcode IDs.
+- Loosen the assertion if the test shouldn't care about ordering but only on the elements.
+- Fix the test by specifying a deterministic ordering.
+- Fix the app code by specifying a deterministic ordering.
 
 **Examples:**
 
@@ -81,11 +67,10 @@ difficult to achieve locally.
   suite, it might pass as not enough records were created before it, but as soon as it would run
   later in the suite, there could be a record that actually has the ID `42`, hence the test would
   start to fail.
-- [Example 3](https://gitlab.com/gitlab-org/gitlab/-/issues/402915): State leakage can result from
-  data records created with `let_it_be` shared between test examples, while some test modifies the model
-  either deliberately or unwillingly causing out-of-sync data in test examples. This can result in `PG::QueryCanceled: ERROR` in the subsequent test examples or retries.
-  For more information about state leakages and resolution options,
-  see [GitLab testing best practices](best_practices.md#lets-talk-about-let).
+- [Example 3](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10148/diffs): Without
+  specifying `ORDER BY`, database is not given deterministic ordering, or data race can happen
+  in the tests.
+- [Example 4](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106936/diffs).
 
 ### Random input
 
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index d596c21bd5c..b1fde5ed139 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -218,7 +218,6 @@ it('exists', () => {
   wrapper.find('.js-foo');
   wrapper.find('.btn-primary');
   wrapper.find('.qa-foo-component');
-  wrapper.find('[data-qa-selector="foo"]');
 });
 ```
 
@@ -226,7 +225,7 @@ It is recommended to use `kebab-case` for `data-testid` attribute.
 
 It is not recommended that you add `.js-*` classes just for testing purposes. Only do this if there are no other feasible options available.
 
-Do not use a `.qa-*` class or `data-qa-selector` attribute for any tests other than QA end-to-end testing.
+Do not use `.qa-*` class attributes for any tests other than QA end-to-end testing.
 
 ### Querying for child components
 
diff --git a/doc/development/testing_guide/index.md b/doc/development/testing_guide/index.md
index 5008564de01..38fda1bb742 100644
--- a/doc/development/testing_guide/index.md
+++ b/doc/development/testing_guide/index.md
@@ -79,4 +79,8 @@ Everything you should know about how to test migrations.
 
 Introduction to contract testing, how to run the tests, and how to write them.
 
+## [Test results tracking](test_results_tracking.md)
+
+How we track our test suite run results.
+
 [Return to Development documentation](../index.md)
diff --git a/doc/development/testing_guide/test_results_tracking.md b/doc/development/testing_guide/test_results_tracking.md
new file mode 100644
index 00000000000..28407e806a3
--- /dev/null
+++ b/doc/development/testing_guide/test_results_tracking.md
@@ -0,0 +1,29 @@
+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Test results tracking
+
+We developed the [`gitlab_quality-test_tooling`](https://gitlab.com/gitlab-org/ruby/gems/gitlab_quality-test_tooling) gem that includes several commands to automate test results tracking.
+
+The goal of this gem is to have a consolidated set of tooling that we use accross our various test suite (e.g. GitLab Rails & E2E test suites).
+
+The initial motivation and development was tracked by [this epic](https://gitlab.com/groups/gitlab-org/-/epics/10536).
+
+## Rails test results tracking
+
+We [plan to use](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122008) the `relate-failure-issue` command from the gem (see the gem's README for details about the command).
+
+## End-to-end test results tracking
+
+This is described specifically at <https://about.gitlab.com/handbook/engineering/quality/#test-results-tracking>.
+
+For the E2E test suite, we use the following commands from the gem (see the gem's README for details about each command):
+
+- `prepare-stage-reports`
+- `generate-test-session`
+- `report-results`
+- `update-screenshot-paths`
+- `relate-failure-issue`
diff --git a/doc/development/uploads/index.md b/doc/development/uploads/index.md
index a62e8ea2d58..92b52d2b59c 100644
--- a/doc/development/uploads/index.md
+++ b/doc/development/uploads/index.md
@@ -1,6 +1,6 @@
 ---
-stage: none
-group: unassigned
+stage: SaaS Platforms
+group: Scalability
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/uploads/working_with_uploads.md b/doc/development/uploads/working_with_uploads.md
index 5575297ad6b..e487f2a19d3 100644
--- a/doc/development/uploads/working_with_uploads.md
+++ b/doc/development/uploads/working_with_uploads.md
@@ -1,6 +1,6 @@
 ---
-stage: none
-group: unassigned
+stage: SaaS Platforms
+group: Scalability
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/value_stream_analytics.md b/doc/development/value_stream_analytics.md
index afbd1a76a1b..e056ce9b064 100644
--- a/doc/development/value_stream_analytics.md
+++ b/doc/development/value_stream_analytics.md
@@ -365,7 +365,7 @@ Seed issues and merge requests for value stream analytics:
 
 Seed DORA daily metrics for value stream, insights and CI/CD analytics:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. On the project's homepage, in the upper-left corner, copy the **Project ID**. You need it in a later step.
 1. [Create an environment for your selected project from the UI](../ci/environments/index.md#create-a-static-environment) named `production`.
 1. Open the rails console:
diff --git a/doc/development/vs_code_debugging.md b/doc/development/vs_code_debugging.md
index 08aa4688bfd..129eddf853b 100644
--- a/doc/development/vs_code_debugging.md
+++ b/doc/development/vs_code_debugging.md
@@ -6,12 +6,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # VS Code debugging
 
-This document describes how to set up Rails debugging in [VS Code](https://code.visualstudio.com/).
+This document describes how to set up Rails debugging in [Visual Studio Code (VSCode)](https://code.visualstudio.com/) using the [GitLab Development Kit (GDK)](contributing/first_contribution.md#step-1-configure-the-gitlab-development-kit).
 
 ## Setup
 
 1. Install the `debug` gem by running `gem install debug` inside your `gitlab` folder.
-1. Add the following configuration to your `.vscode/tasks.json` file:
+1. Install the [VSCode Ruby rdbg Debugger](https://marketplace.visualstudio.com/items?itemName=KoichiSasada.vscode-rdbg) extension to add support for the `rdbg` debugger type to VSCode.
+1. In case you want to automatically stop and start GitLab and its associated Ruby Rails server, you may add the following VSCode task to your configuration under the `.vscode/tasks.json` file:
 
     ```json
     {
@@ -20,7 +21,7 @@ This document describes how to set up Rails debugging in [VS Code](https://code.
           {
             "label": "start rdbg",
             "type": "shell",
-            "command": "gdk stop rails-web && GITLAB_RAILS_RACK_TIMEOUT_ENABLE_LOGGING=false PUMA_SINGLE_MODE=true rdbg --open -c -- bin/rails s",
+            "command": "gdk stop rails-web && GITLAB_RAILS_RACK_TIMEOUT_ENABLE_LOGGING=false PUMA_SINGLE_MODE=true rdbg --open -c bin/rails server",
             "isBackground": true,
             "problemMatcher": {
               "owner": "rails",
@@ -42,26 +43,29 @@ This document describes how to set up Rails debugging in [VS Code](https://code.
 
     ```json
     {
-        // Use IntelliSense to learn about possible attributes.
-        // Hover to view descriptions of existing attributes.
-        // For more information, see https://go.microsoft.com/fwlink/?linkid=830387.
         "version": "0.2.0",
         "configurations": [
           {
             "type": "rdbg",
             "name": "Attach with rdbg",
             "request": "attach",
+
+            // remove the following "preLaunchTask" if you do not wish to stop and start
+            // GitLab via VS Code but manually on a separate terminal.
             "preLaunchTask": "start rdbg"
           }
         ]
     }
     ```
 
+WARNING:
+The VSCode Ruby extension might have issues finding the correct Ruby installation and the appropriate `rdbg` command. In this case, add `"rdbgPath": "/home/user/.asdf/shims/` (in the case of asdf) to the launch configuration above.
+
 ## Debugging
 
-Prerequisite:
+### Prerequisites
 
-- You must have a running GDK instance.
+- You must have a running [GDK](contributing/first_contribution.md#step-1-configure-the-gitlab-development-kit) instance.
 
 To start debugging, do one of the following:
 
diff --git a/doc/development/work_items_widgets.md b/doc/development/work_items_widgets.md
index bafceccdafe..6c453f49db1 100644
--- a/doc/development/work_items_widgets.md
+++ b/doc/development/work_items_widgets.md
@@ -146,18 +146,24 @@ You can update widgets using custom fine-grained mutations (for example, `WorkIt
 ### Widget callbacks
 
 When updating the widget together with the work item's mutation, backend code should be implemented using
-callback classes that inherit from `Issuable::Callbacks::Base`. These classes have callback methods
+callback classes that inherit from `WorkItems::Callbacks::Base`. These classes have callback methods
 that are named similar to ActiveRecord callbacks and behave similarly.
 
-Callback classes with the same name as the widget are automatically used. For example, `Issuable::Callbacks::Milestone`
-is called when the work item has the milestone widget. To use a different class, you can override the `callback_class`
+Callback classes with the same name as the widget are automatically used. For example, `WorkItems::Callbacks::AwardEmoji`
+is called when the work item has the `AwardEmoji` widget. To use a different class, you can override the `callback_class`
 class method.
 
+When a callback class is also used for other issuables like merge requests or epics, define the class under `Issuable::Callbacks`
+and add the class to the list in `IssuableBaseService#available_callbacks`. These are executed for both work item updates and
+legacy issue, merge request, or epic updates.
+
 #### Available callbacks
 
 - `after_initialize` is called after the work item is initialized by the `BuildService` and before
   the work item is saved by the `CreateService` and `UpdateService`. This callback runs outside the
   creation or update database transaction.
+- `before_update` is called before the work item is saved by the `UpdateService`. This callback runs
+  within the update database transaction.
 - `after_update_commit` is called after the DB update transaction is committed by the `UpdateService`.
 - `after_save_commit` is called after the creation or DB update transaction is committed by the
   `CreateService` or `UpdateService`.
diff --git a/doc/development/workspace/index.md b/doc/development/workspace/index.md
deleted file mode 100644
index ca404702d72..00000000000
--- a/doc/development/workspace/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../organization/index.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../organization/index.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/gitlab-basics/add-file.md b/doc/gitlab-basics/add-file.md
index 425b8927520..b5c4c78ac8e 100644
--- a/doc/gitlab-basics/add-file.md
+++ b/doc/gitlab-basics/add-file.md
@@ -25,7 +25,7 @@ If you are unfamiliar with the command line, use the
 <!-- Original source for this list: doc/user/project/repository/web_editor.md#upload-a-file -->
 <!-- For why we duplicated the info, see https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111072#note_1267429478 -->
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. From the project dashboard or repository, next to the branch name, select the plus icon (**{plus}**).
 1. From the dropdown list, select **Upload file**.
 1. Complete the fields. To create a merge request with the uploaded file, ensure the **Start a new merge request with these changes** toggle is turned on.
diff --git a/doc/gitlab-basics/command-line-commands.md b/doc/gitlab-basics/command-line-commands.md
deleted file mode 100644
index 2850669ce57..00000000000
--- a/doc/gitlab-basics/command-line-commands.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../user/index.md'
-remove_date: '2023-06-09'
----
-
-This document was moved to [another location](../user/index.md).
-
-<!-- This redirect file can be deleted after <2023-06-09>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/gitlab-basics/start-using-git.md b/doc/gitlab-basics/start-using-git.md
index fd322b67abe..c824fc2e44f 100644
--- a/doc/gitlab-basics/start-using-git.md
+++ b/doc/gitlab-basics/start-using-git.md
@@ -276,7 +276,7 @@ git checkout -b <name-of-branch>
 ```
 
 GitLab enforces [branch naming rules](../user/project/repository/branches/index.md#name-your-branch)
-to prevent problems, and provides 
+to prevent problems, and provides
 [branch naming patterns](../user/project/repository/branches/index.md#prefix-branch-names-with-issue-numbers)
 to streamline merge request creation.
 
diff --git a/doc/index.md b/doc/index.md
index 958f7fe6111..367f18ec159 100644
--- a/doc/index.md
+++ b/doc/index.md
@@ -19,16 +19,15 @@ description: 'Learn how to use and administer GitLab, the most scalable Git-base
 
 # GitLab Docs
 
-Welcome to the GitLab documentation!
+Explore the different areas of the documentation:
 
 |                         |                         |
 |:------------------------|:------------------------|
 | [**Use GitLab**](user/index.md)<br>Get started with GitLab features and functionality. | [**Administer GitLab**](administration/index.md)<br/>Administer a self-managed GitLab instance. |
-| [**New to Git and GitLab?**](tutorials/index.md)<br/>Start learning about Git and GitLab. | [**Contribute to GitLab development**](#contributing-to-gitlab)<br/>Create new GitLab functionality and documentation. |
+| [**New to Git and GitLab?**](tutorials/index.md)<br/>Start learning about Git and GitLab. | [**Contribute to GitLab development**](#contribute-to-gitlab)<br/>Create new GitLab functionality and documentation. |
 | [**Coming to GitLab from another platform?**](#coming-to-gitlab-from-another-platform)<br/>Learn how to move to GitLab. | [**Build an integration with GitLab**](#build-an-integration-with-gitlab)<br/>Integrate with Jira and other common applications. |
-| [**Choose a subscription**](subscriptions/index.md)<br/>Determine which subscription tier makes sense for you. | [**Install GitLab**](https://about.gitlab.com/install/)<br/>Install GitLab on different platforms. |
+| [**Choose a subscription**](subscriptions/index.md)<br/>Determine which subscription tier makes sense for you. | [**Install GitLab**](install/index.md)<br/>Install GitLab on different platforms. |
 | [**Reference architectures**](administration/reference_architectures/index.md)<br/>View recommended deployments at scale. | [**Upgrade GitLab**](update/index.md)<br/>Upgrade your GitLab self-managed instance to the latest version. |
-| [**GitLab releases**](https://about.gitlab.com/releases/)<br/>See what's new in GitLab. |  |
 
 ## Popular topics
 
@@ -43,20 +42,12 @@ Have a look at some of our most popular topics:
 | [Back up and restore GitLab](raketasks/backup_restore.md)                                  | Rake tasks for backing up and restoring GitLab self-managed instances. |
 | [GitLab release and maintenance policy](policy/maintenance.md)                             | Policies for version naming and cadence, and also upgrade recommendations. |
 | [Elasticsearch integration](integration/advanced_search/elasticsearch.md)                  | Integrate Elasticsearch with GitLab to enable advanced search. |
-| [Omnibus GitLab database settings](https://docs.gitlab.com/omnibus/settings/database.html) | Database settings for Omnibus GitLab self-managed instances. |
-| [Omnibus GitLab NGINX settings](https://docs.gitlab.com/omnibus/settings/nginx.html)       | NGINX settings for Omnibus GitLab self-managed instances. |
-| [Omnibus GitLab SSL configuration](https://docs.gitlab.com/omnibus/settings/ssl/index.html)      | SSL settings for Omnibus GitLab self-managed instances. |
+| [Database settings for Linux package installations](https://docs.gitlab.com/omnibus/settings/database.html) | Database settings for self-managed instances installed using Linux packages. |
+| [NGINX settings for Linux package installations](https://docs.gitlab.com/omnibus/settings/nginx.html)       | NGINX settings for self-managed instances installed using Linux packages. |
+| [SSL configuration for Linux package installations](https://docs.gitlab.com/omnibus/settings/ssl/index.html)      | SSL settings for self-managed instances installed using Linux packages. |
 | [GitLab.com settings](user/gitlab_com/index.md)                                            | Settings used for GitLab.com. |
 
-## The entire DevOps lifecycle
-
-GitLab is the first single application for software development, security,
-and operations that enables [Concurrent DevOps](https://about.gitlab.com/topics/concurrent-devops/).
-GitLab makes the software lifecycle faster and radically improves the speed of business.
-
-GitLab provides solutions for [each of the stages of the DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/).
-
-### User account
+## User account
 
 For more information about GitLab account management, see:
 
@@ -78,7 +69,7 @@ If you are coming to GitLab from another platform, the following information is
 
 ## Build an integration with GitLab
 
-There are many ways to integrate with GitLab, including:
+You can build integrations with GitLab:
 
 | Topic                                      | Description |
 |:-------------------------------------------|:------------|
@@ -86,15 +77,11 @@ There are many ways to integrate with GitLab, including:
 | [GitLab GraphQL API](api/graphql/index.md) | Integrate with GitLab using our GraphQL API. |
 | [Integrations](integration/index.md)      | Integrations with third-party products. |
 
-## Contributing to GitLab
-
-GitLab Community Edition is [open source](https://gitlab.com/gitlab-org/gitlab-foss/)
-and GitLab Enterprise Edition is [open-core](https://gitlab.com/gitlab-org/gitlab/).
+## Contribute to GitLab
 
 Learn how to contribute to GitLab with the following resources:
 
 | Topic                                                       | Description |
 |:------------------------------------------------------------|:------------|
-| [Development](development/index.md)                        | How to contribute to GitLab development. |
-| [Legal](legal/index.md)                                    | Contributor license agreements. |
-| [Writing documentation](development/documentation/index.md) | How to contribute to GitLab Docs. |
+| [Contribute to GitLab development](development/index.md).  | How to contribute to GitLab development. |
+| [Contribute to the documentation](development/documentation/index.md)             | How to contribute to GitLab documentation. |
diff --git a/doc/install/aws/eks_clusters_aws.md b/doc/install/aws/eks_clusters_aws.md
index ccbc0752975..7b4f815d3ff 100644
--- a/doc/install/aws/eks_clusters_aws.md
+++ b/doc/install/aws/eks_clusters_aws.md
@@ -23,7 +23,7 @@ Using `eksctl` enables the following when building an EKS Cluster:
 - You have various cluster configuration options:
   - Selection of operating system: Amazon Linux 2, Windows, Bottlerocket
   - Selection of Hardware Architecture: x86, ARM, GPU
-  - Selection of Kubernetes version (the GitLab-managed clusters for your project's applications have [specific Kubernetes version requirements](../../user/clusters/agent/index.md#gitlab-agent-for-kubernetes-supported-cluster-versions))
+  - Selection of Kubernetes version (the GitLab-managed clusters for your project's applications have [specific Kubernetes version requirements](../../user/clusters/agent/index.md#supported-kubernetes-versions-for-gitlab-features))
 - It can deploy high value-add items to the cluster, including:
   - A bastion host to keep the cluster endpoint private and possible perform performance testing.
   - Prometheus and Grafana for monitoring.
diff --git a/doc/install/aws/gitlab_hybrid_on_aws.md b/doc/install/aws/gitlab_hybrid_on_aws.md
index e4eb0117410..75b39a387dc 100644
--- a/doc/install/aws/gitlab_hybrid_on_aws.md
+++ b/doc/install/aws/gitlab_hybrid_on_aws.md
@@ -48,7 +48,7 @@ The Beta version deploys Aurora PostgreSQL, but the release version will deploy
 | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
 | Overview and Vision                                          | [AWS Quick Start](https://aws.amazon.com/solutions/implementations/amazon-eks/)        | [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/blob/main/README.md) |
 | Licensing                                                    | [Open Source (Apache 2.0)](https://github.com/aws-quickstart/quickstart-eks-gitlab/blob/main/LICENSE.txt) | [GitLab Enterprise Edition license](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/blob/main/LICENSE) ([GitLab Premium tier](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/blob/main/README.md)) |
-| GitLab Support                                               | [GitLab Beta Support](../../policy/alpha-beta-support.md#beta) | [GitLab GA Support](../../policy/alpha-beta-support.md#generally-available-ga) |
+| GitLab Support                                               | [GitLab Beta Support](../../policy/experiment-beta-support.md#beta) | [GitLab GA Support](../../policy/experiment-beta-support.md#generally-available-ga) |
 | GitLab Reference Architecture Compliant                      | Yes                                                          | Yes                                                          |
 | GitLab Performance Tool (GPT) Tested                         | Yes                                                          | Yes                                                          |
 | Amazon Well Architected Compliant                            | Yes<br />(via Quick Start program)                           | Critical portions <br />reviewed by AWS                      |
diff --git a/doc/install/aws/manual_install_aws.md b/doc/install/aws/manual_install_aws.md
index bd81e0583b5..92375fff59e 100644
--- a/doc/install/aws/manual_install_aws.md
+++ b/doc/install/aws/manual_install_aws.md
@@ -8,23 +8,23 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Installing a GitLab POC on Amazon Web Services (AWS) **(FREE SELF)**
 
-This page offers a walkthrough of a common configuration for GitLab on AWS using the official GitLab Linux package. You should customize it to accommodate your needs.
+This page offers a walkthrough of a common configuration for GitLab on AWS using the official Linux package. You should customize it to accommodate your needs.
 
 NOTE:
-For organizations with 1,000 users or less, the recommended AWS installation method is to launch an EC2 single box [Omnibus Installation](https://about.gitlab.com/install/) and implement a snapshot strategy for backing up the data. See the [1,000 user reference architecture](../../administration/reference_architectures/1k_users.md) for more information.
+For organizations with 1,000 users or less, the recommended AWS installation method is to launch an EC2 single box [Linux package installation](https://about.gitlab.com/install/) and implement a snapshot strategy for backing up the data. See the [1,000 user reference architecture](../../administration/reference_architectures/1k_users.md) for more information.
 
 ## Getting started for production-grade GitLab
 
 NOTE:
 This document is an installation guide for a proof of concept instance. It is not a reference architecture and it does not result in a highly available configuration.
 
-Following this guide exactly results in a proof of concept instance that roughly equates to a **scaled down** version of a **two availability zone implementation** of the **Non-HA** [Omnibus 2000 User Reference Architecture](../../administration/reference_architectures/2k_users.md). The 2K reference architecture is not HA because it is primarily intended to provide some scaling while keeping costs and complexity low. The [3000 User Reference Architecture](../../administration/reference_architectures/3k_users.md) is the smallest size that is GitLab HA. It has additional service roles to achieve HA, most notably it uses Gitaly Cluster to achieve HA for Git repository storage and specifies triple redundancy.
+Following this guide exactly results in a proof of concept instance that roughly equates to a **scaled down** version of a **two availability zone implementation** of the **Non-HA** [2000 User Reference Architecture](../../administration/reference_architectures/2k_users.md). The 2K reference architecture is not HA because it is primarily intended to provide some scaling while keeping costs and complexity low. The [3000 User Reference Architecture](../../administration/reference_architectures/3k_users.md) is the smallest size that is GitLab HA. It has additional service roles to achieve HA, most notably it uses Gitaly Cluster to achieve HA for Git repository storage and specifies triple redundancy.
 
-GitLab maintains and tests two main types of Reference Architectures. The **Omnibus architectures** are implemented on instance compute while **Cloud Native Hybrid architectures** maximize the use of a Kubernetes cluster. Cloud Native Hybrid reference architecture specifications are addendum sections to the Reference Architecture size pages that start by describing the Omnibus architecture. For example, the 3000 User Cloud Native Reference Architecture is in the subsection titled [Cloud Native Hybrid reference architecture with Helm Charts (alternative)](../../administration/reference_architectures/3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) in the 3000 User Reference Architecture page.
+GitLab maintains and tests two main types of Reference Architectures. The **Linux package architectures** are implemented on instance compute while **Cloud Native Hybrid architectures** maximize the use of a Kubernetes cluster. Cloud Native Hybrid reference architecture specifications are addendum sections to the Reference Architecture size pages that start by describing the Linux package architecture. For example, the 3000 User Cloud Native Reference Architecture is in the subsection titled [Cloud Native Hybrid reference architecture with Helm Charts (alternative)](../../administration/reference_architectures/3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) in the 3000 User Reference Architecture page.
 
-### Getting started for production-grade Omnibus GitLab
+### Getting started for production-grade Linux package installations
 
-The Infrastructure as Code tooling [GitLab Environment Tool (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/tree/main) is the best place to start for building Omnibus GitLab on AWS and most especially if you are targeting an HA setup. While it does not automate everything, it does complete complex setups like Gitaly Cluster for you. GET is open source so anyone can build on top of it and contribute improvements to it.
+The Infrastructure as Code tooling [GitLab Environment Tool (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/tree/main) is the best place to start for building using the Linux package on AWS and most especially if you are targeting an HA setup. While it does not automate everything, it does complete complex setups like Gitaly Cluster for you. GET is open source so anyone can build on top of it and contribute improvements to it.
 
 ### Getting started for production-grade Cloud Native Hybrid GitLab
 
@@ -32,7 +32,7 @@ For the Cloud Native Hybrid architectures there are two Infrastructure as Code o
 
 ## Introduction
 
-For the most part, we make use of Omnibus GitLab in our setup, but we also leverage native AWS services. Instead of using the Omnibus bundled PostgreSQL and Redis, we use Amazon RDS and ElastiCache.
+For the most part, we make use of the Linux package in our setup, but we also leverage native AWS services. Instead of using the Linux package-bundled PostgreSQL and Redis, we use Amazon RDS and ElastiCache.
 
 In this guide, we go through a multi-node setup where we start by
 configuring our Virtual Private Cloud and subnets to later integrate
@@ -783,7 +783,7 @@ For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
 
 To restore GitLab, first review the [restore documentation](../../raketasks/backup_restore.md#restore-gitlab),
 and primarily the restore prerequisites. Then, follow the steps under the
-[Omnibus installations section](../../raketasks/restore_gitlab.md#restore-for-omnibus-gitlab-installations).
+[Linux package installations section](../../raketasks/restore_gitlab.md#restore-for-omnibus-gitlab-installations).
 
 ## Updating GitLab
 
@@ -831,7 +831,7 @@ to request additional material:
   GitLab supports several different types of clustering.
 - [Geo replication](../../administration/geo/index.md):
   Geo is the solution for widely distributed development teams.
-- [Omnibus GitLab](https://docs.gitlab.com/omnibus/) - Everything you must know
+- [Linux package](https://docs.gitlab.com/omnibus/) - Everything you must know
   about administering your GitLab instance.
 - [Add a license](../../user/admin_area/license.md):
   Activate all GitLab Enterprise Edition functionality with a license.
diff --git a/doc/install/azure/index.md b/doc/install/azure/index.md
index 088ef50c005..8a3cd720079 100644
--- a/doc/install/azure/index.md
+++ b/doc/install/azure/index.md
@@ -248,7 +248,8 @@ in this section whenever you need to update GitLab.
 
 To determine the version of GitLab you're currently running:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Overview > Dashboard**.
 1. Find the version under the **Components** table.
 
diff --git a/doc/install/docker.md b/doc/install/docker.md
index d387a4d0abb..ab1aec98b16 100644
--- a/doc/install/docker.md
+++ b/doc/install/docker.md
@@ -774,3 +774,17 @@ xargs: tail: terminated by signal 6
 ```
 
 Removing old log files helps fix the error, and ensures a clean startup of the instance.
+
+### ThreadError can't create Thread Operation not permitted
+
+```plaintext
+can't create Thread: Operation not permitted
+```
+
+This error occurs when running a container built with newer `glibc` versions on a
+[host that doesn't have support for the new clone3 function](https://github.com/moby/moby/issues/42680). In GitLab 16.0 and later, the container image includes
+the Ubuntu 22.04 Linux package which is built with this newer `glibc`.
+
+This problem is fixed with newer container runtime tools like [Docker 20.10.10](https://github.com/moby/moby/pull/42836).
+
+To resolve this issue, update Docker to version 20.10.10 or later.
diff --git a/doc/install/google_cloud_platform/index.md b/doc/install/google_cloud_platform/index.md
index e492b5d75ce..7b90d4ad19c 100644
--- a/doc/install/google_cloud_platform/index.md
+++ b/doc/install/google_cloud_platform/index.md
@@ -7,7 +7,7 @@ description: 'Learn how to install a GitLab instance on Google Cloud Platform.'
 
 # Installing GitLab on Google Cloud Platform **(FREE SELF)**
 
-You can install GitLab on a [Google Cloud Platform (GCP)](https://cloud.google.com/) using the official GitLab Linux package. You should customize it to accommodate your needs.
+You can install GitLab on a [Google Cloud Platform (GCP)](https://cloud.google.com/) using the official Linux package. You should customize it to accommodate your needs.
 
 NOTE:
 To deploy production-ready GitLab on
@@ -92,7 +92,7 @@ here's how you configure GitLab to be aware of the change:
    In the future you might want to set up [connecting with an SSH key](https://cloud.google.com/compute/docs/instances/connecting-to-instance)
    instead.
 
-1. Edit the configuration file of Omnibus GitLab using your favorite text editor:
+1. Edit the configuration file of the Linux package using your favorite text editor:
 
    ```shell
    sudo vim /etc/gitlab/gitlab.rb
@@ -123,14 +123,14 @@ Although not needed, it's strongly recommended to secure GitLab with a
 ### Configuring the email SMTP settings
 
 You must configure the email SMTP settings correctly otherwise GitLab cannot send notification emails, like comments, and password changes.
-Check the [Omnibus documentation](https://docs.gitlab.com/omnibus/settings/smtp.html#smtp-settings) how to do so.
+Check the [Linux package documentation](https://docs.gitlab.com/omnibus/settings/smtp.html#smtp-settings) how to do so.
 
 ## Further reading
 
 GitLab can be configured to authenticate with other OAuth providers, like LDAP,
 SAML, and Kerberos. Here are some documents you might be interested in reading:
 
-- [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/)
+- [Linux package documentation](https://docs.gitlab.com/omnibus/)
 - [Integration documentation](../../integration/index.md)
 - [GitLab Pages configuration](../../administration/pages/index.md)
 - [GitLab Container Registry configuration](../../administration/packages/container_registry.md)
diff --git a/doc/install/installation.md b/doc/install/installation.md
index 28aa37f0d1b..4d80a02c9f1 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -4,14 +4,13 @@ group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Installation from source **(FREE SELF)**
+# Self-compiled installation **(FREE SELF)**
 
 This is the official installation guide to set up a production GitLab server
-using the source files. To set up a **development installation** or for many
-other installation options, see the [main installation page](index.md).
-It was created for and tested on **Debian/Ubuntu** operating systems.
+using the source files. It was created for and tested on **Debian/Ubuntu** operating systems.
 Read [requirements.md](requirements.md) for hardware and operating system requirements.
-If you want to install on RHEL/CentOS, you should use the [Omnibus packages](https://about.gitlab.com/install/).
+If you want to install on RHEL/CentOS, you should use the [Linux packages](https://about.gitlab.com/install/).
+For many other installation options, see the [main installation page](index.md).
 
 This guide is long because it covers many cases and includes all commands you
 need, this is [one of the few installation scripts that actually work out of the box](https://twitter.com/robinvdvleuten/status/424163226532986880).
@@ -24,21 +23,20 @@ If you find a bug/error in this guide, **submit a merge request**
 following the
 [contributing guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/CONTRIBUTING.md).
 
-## Consider the Omnibus package installation
+## Consider the Linux package installation
 
-Because an installation from source is a lot of work and error prone we strongly recommend the fast and reliable [Omnibus package installation](https://about.gitlab.com/install/) (deb/rpm).
+Because a self-compiled installation is a lot of work and error prone, we strongly recommend the fast and reliable [Linux package installation](https://about.gitlab.com/install/) (deb/rpm).
 
-One reason the Omnibus package is more reliable is its use of runit to restart any of the GitLab processes in case one crashes.
+One reason the Linux package is more reliable is its use of runit to restart any of the GitLab processes in case one crashes.
 On heavily used GitLab instances the memory usage of the Sidekiq background worker grows over time.
-
-Omnibus packages solve this by [letting the Sidekiq terminate gracefully](../administration/sidekiq/sidekiq_memory_killer.md) if it uses too much memory.
+The Linux packages solve this by [letting the Sidekiq terminate gracefully](../administration/sidekiq/sidekiq_memory_killer.md) if it uses too much memory.
 After this termination runit detects Sidekiq is not running and starts it.
-Because installations from source don't use runit for process supervision, Sidekiq
+Because self-compiled installations don't use runit for process supervision, Sidekiq
 can't be terminated and its memory usage grows over time.
 
 ## Select a version to install
 
-Make sure you view [this installation guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/install/installation.md) from the branch (version) of GitLab you would like to install (for example, `11-7-stable`).
+Make sure you view [this installation guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/install/installation.md) from the branch (version) of GitLab you would like to install (for example, `16-0-stable`).
 You can select the branch in the version dropdown list in the upper-left corner of GitLab (below the menu bar).
 
 If the highest number stable branch is unclear, check the [GitLab blog](https://about.gitlab.com/blog/) for installation guide links by version.
@@ -51,7 +49,7 @@ If the highest number stable branch is unclear, check the [GitLab blog](https://
 | [RubyGems](#3-rubygems) | `3.4.x`         | A specific RubyGems version is not fully needed, but it's recommended to update so you can enjoy some known performance improvements.                                                                                                                                                  |
 | [Go](#4-go)             | `1.18.x`        | From GitLab 15.6, Go 1.18 or later is required.                                                                                                                                                                                                                                        |
 | [Git](#git)             | `2.38.x`        | From GitLab 15.8, Git 2.38.x and later is required. It's highly recommended that you use the [Git version provided by Gitaly](#git).                                                                                                                                                   |
-| [Node.js](#5-node)      | `16.15.0`       | From GitLab 15.7, Node.js 16.15.0 or later is required.                                                                                                                                                                                                                                |
+| [Node.js](#5-node)      | `18.16.x`       | From GitLab 16.1, Node.js 18.16 or later is required.                                                                                                                                                                                                                                |
 
 ## GitLab directory structure
 
@@ -262,8 +260,8 @@ GitLab requires the use of Node to compile JavaScript
 assets, and Yarn to manage JavaScript dependencies. The current minimum
 requirements for these are:
 
-- `node` 16.x releases (v16.15.0 or later).
-  [Other LTS versions of Node.js](https://github.com/nodejs/release#release-schedule) might be able to build assets, but we only guarantee Node.js 16.x.
+- `node` 18.x releases (v18.16.0 or later).
+  [Other LTS versions of Node.js](https://github.com/nodejs/release#release-schedule) might be able to build assets, but we only guarantee Node.js 18.x.
 - `yarn` = v1.22.x (Yarn 2 is not supported yet)
 
 In many distributions,
@@ -271,8 +269,8 @@ the versions provided by the official package repositories are out of date, so
 we must install through the following commands:
 
 ```shell
-# install node v16.x
-curl --location "https://deb.nodesource.com/setup_16.x" | sudo bash -
+# install node v18.x
+curl --location "https://deb.nodesource.com/setup_18.x" | sudo bash -
 sudo apt-get install -y nodejs
 
 npm install --global yarn
@@ -423,7 +421,7 @@ In GitLab 12.1 and later, only PostgreSQL is supported. In GitLab 16.0 and later
 
 ## 8. Redis
 
-See the [requirements page](requirements.md#redis-versions) for the minimum
+See the [requirements page](requirements.md#redis) for the minimum
 Redis requirements.
 
 Install Redis with:
@@ -1147,15 +1145,6 @@ You must also change the corresponding options (for example, `ssh_user`, `ssh_ho
 
 Apart from the always supported Markdown style, there are other rich text files that GitLab can display. But you might have to install a dependency to do so. See the [`github-markup` gem README](https://github.com/gitlabhq/markup#markups) for more information.
 
-### Using Sidekiq instead of Sidekiq Cluster
-
-As of GitLab 12.10, Source installations are using `bin/sidekiq-cluster` for managing Sidekiq processes.
-Using Sidekiq directly is still supported until 14.0. So if you're experiencing issues:
-
-1. Edit the system `init.d` script to remove the `SIDEKIQ_WORKERS` flag. If you have `/etc/default/gitlab`, then you should edit it instead.
-1. Restart GitLab.
-1. [Create an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/-/new) describing the problem.
-
 ### Prometheus server setup
 
 You can configure the Prometheus server in `config/gitlab.yml`:
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index 7fdbdfc2b24..64dfd3e6044 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -8,12 +8,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 This page includes information about the minimum requirements you need to install and use GitLab.
 
-## Software requirements
-
-### Redis versions
-
-GitLab 16.0 and later requires Redis 6.0 or later.
-
 ## Hardware requirements
 
 ### Storage
@@ -161,10 +155,10 @@ of GitLab Support or other GitLab engineers.
 ## Puma settings
 
 The recommended settings for Puma are determined by the infrastructure on which it's running.
-The GitLab Linux package defaults to the recommended Puma settings. Regardless of installation method, you can
+The Linux package defaults to the recommended Puma settings. Regardless of installation method, you can
 tune the Puma settings:
 
-- If you're using the GitLab Linux package, see [Puma settings](../administration/operations/puma.md)
+- If you're using the Linux package, see [Puma settings](../administration/operations/puma.md)
   for instructions on changing the Puma settings.
 - If you're using the GitLab Helm chart, see the
   [`webservice` chart](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
@@ -248,11 +242,19 @@ By default, each Puma worker is limited to 1.2 GB of memory.
 You can [adjust this memory setting](../administration/operations/puma.md#reducing-memory-use) and should do so
 if you must increase the number of Puma workers.
 
-## Redis and Sidekiq
+## Redis
 
 Redis stores all user sessions and the background task queue.
-The storage requirements for Redis are minimal, about 25 kB per user.
-Sidekiq processes the background jobs with a multi-threaded process.
+
+The requirements for Redis are as follows:
+
+- Redis 6.0 is required from GitLab 16.0 and later.
+- Redis Cluster mode is not supported. Redis Standalone must be used.
+- Storage requirements for Redis are minimal, about 25 kB per user on average.
+
+## Sidekiq
+
+Sidekiq processes the background jobs with a multithreaded process.
 This process starts with the entire Rails stack (200 MB+) but it can grow over time due to memory leaks.
 On a very active server (10,000 billable users) the Sidekiq process can use 1 GB+ of memory.
 
diff --git a/doc/integration/advanced_search/elasticsearch.md b/doc/integration/advanced_search/elasticsearch.md
index e886f2a4b37..7b23eaa278a 100644
--- a/doc/integration/advanced_search/elasticsearch.md
+++ b/doc/integration/advanced_search/elasticsearch.md
@@ -172,7 +172,8 @@ Prerequisite:
 
 To enable advanced search:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Advanced Search**.
 
    NOTE:
@@ -219,8 +220,7 @@ The following Elasticsearch settings are available:
 | `URL`                                                 | The URL of your Elasticsearch instance. Use a comma-separated list to support clustering (for example, `http://host1, https://host2:9200`). If your Elasticsearch instance is password-protected, use the `Username` and `Password` fields described below. Alternatively, use inline credentials such as `http://<username>:<password>@<elastic_host>:9200/`. |
 | `Username`                                                 | The `username` of your Elasticsearch instance. |
 | `Password`                                                 | The password of your Elasticsearch instance. |
-| `Number of Elasticsearch shards`                      | Elasticsearch indices are split into multiple shards for performance reasons. In general, you should use at least 5 shards, and indices with tens of millions of documents need to have more shards ([see below](#guidance-on-choosing-optimal-cluster-configuration)). Changes to this value do not take effect until the index is recreated. You can read more about tradeoffs in the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/scalability.html). |
-| `Number of Elasticsearch replicas`                    | Each Elasticsearch shard can have a number of replicas. These are a complete copy of the shard, and can provide increased query performance or resilience against hardware failure. Increasing this value increases total disk space required by the index. |
+| `Number of Elasticsearch shards and replicas per index`    | Elasticsearch indices are split into multiple shards for performance reasons. In general, you should use at least five shards. Indices with tens of millions of documents should have more shards ([see the guidance](#guidance-on-choosing-optimal-cluster-configuration)). Changes to this value do not take effect until you re-create the index. For more information about scalability and resilience, see the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/scalability.html). Each Elasticsearch shard can have a number of replicas. These replicas are a complete copy of the shard and can provide increased query performance or resilience against hardware failure. Increasing this value increases the total disk space required by the index. You can set the number of shards and replicas for each of the indices. |
 | `Limit the number of namespaces and projects that can be indexed`   | Enabling this allows you to select namespaces and projects to index. All other namespaces and projects use database search instead. If you enable this option but do not select any namespaces or projects, none are indexed. [Read more below](#limit-the-number-of-namespaces-and-projects-that-can-be-indexed).|
 | `Using AWS OpenSearch Service with IAM credentials` | Sign your OpenSearch requests using [AWS IAM authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html), [AWS EC2 Instance Profile Credentials](https://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-create-iam-instance-profile.html#getting-started-create-iam-instance-profile-cli), or [AWS ECS Tasks Credentials](https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-iam-roles.html). Refer to [Identity and Access Management in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html) for details of AWS hosted OpenSearch domain access policy configuration. |
 | `AWS Region`                                          | The AWS region in which your OpenSearch Service is located. |
@@ -377,7 +377,8 @@ You can improve the language support for Chinese and Japanese languages by utili
 To enable languages support:
 
 1. Install the desired plugins, refer to [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/plugins/7.9/installation.html) for plugins installation instructions. The plugins must be installed on every node in the cluster, and each node must be restarted after installation. For a list of plugins, see the table later in this section.
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Advanced Search**.
 1. Locate **Custom analyzers: language support**.
 1. Enable plugins support for **Indexing**.
@@ -398,7 +399,8 @@ For guidance on what to install, see the following Elasticsearch language plugin
 
 To disable the Elasticsearch integration:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Advanced Search**.
 1. Clear the **Elasticsearch indexing** and **Search with Elasticsearch enabled** checkboxes.
 1. Select **Save changes**.
@@ -414,7 +416,8 @@ To disable the Elasticsearch integration:
 
 ## Unpause Indexing
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Advanced Search**.
 1. Expand **Advanced Search**.
 1. Clear the **Pause Elasticsearch indexing** checkbox.
@@ -441,7 +444,8 @@ You can use zero-downtime reindexing to configure index settings or mappings tha
 To trigger the reindexing process:
 
 1. Sign in to your GitLab instance as an administrator.
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Advanced Search**.
 1. Expand **Elasticsearch zero-downtime reindexing**.
 1. Select **Trigger cluster reindexing**.
@@ -458,7 +462,8 @@ While the reindexing is running, you can follow its progress under that same sec
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55681) in GitLab 13.12.
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Advanced Search**.
 1. Expand **Elasticsearch zero-downtime reindexing**, and you'll
    find the following options:
@@ -506,7 +511,8 @@ Sometimes, you might want to abandon the unfinished reindex job and resume the i
    bundle exec rake gitlab:elastic:mark_reindex_failed RAILS_ENV=production
    ```
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Advanced Search**.
 1. Expand **Advanced Search**.
 1. Clear the **Pause Elasticsearch indexing** checkbox.
@@ -578,11 +584,17 @@ is recreated with the correct up-to-date schema.
 
 ### All migrations must be finished before doing a major upgrade
 
-Before doing a major version GitLab upgrade, you should have completed all
+Before upgrading to a major GitLab version, you must complete all
 migrations that exist up until the latest minor version before that major
-version. If you have halted migrations, these need to be resolved and
-[retried](#retry-a-halted-migration) before proceeding with a major version
-upgrade. Read more about [upgrading to a new major version](../../update/index.md#upgrading-to-a-new-major-version).
+version. You must also resolve and [retry any halted migrations](#retry-a-halted-migration)
+before proceeding with a major version upgrade. For more information, see [Upgrading to a new major version](../../update/index.md#upgrading-to-a-new-major-version).
+
+Migrations that have been removed are
+[marked as obsolete](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63001).
+If you upgrade GitLab before all pending advanced search migrations are completed,
+any pending migrations that have been removed in the new version cannot be executed or retried.
+In this case, you must
+[re-create your index from scratch](elasticsearch_troubleshooting.md#last-resort-to-recreate-an-index).
 
 ## GitLab advanced search Rake tasks
 
diff --git a/doc/integration/advanced_search/elasticsearch_troubleshooting.md b/doc/integration/advanced_search/elasticsearch_troubleshooting.md
index 0c4895f34fa..e8eace7bd16 100644
--- a/doc/integration/advanced_search/elasticsearch_troubleshooting.md
+++ b/doc/integration/advanced_search/elasticsearch_troubleshooting.md
@@ -17,7 +17,7 @@ See [Starting a Rails console session](../../administration/operations/rails_con
 
 To list all available attributes:
 
-1. Open the Rails console (`gitlab rails c`).
+1. Open the Rails console (`sudo gitlab-rails console`).
 1. Run the following command:
 
 ```ruby
@@ -453,3 +453,41 @@ When using fine-grained access control with an IAM role or a role created using
 ```
 
 To fix this, you need to [map the roles to users](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-mapping) in Kibana.
+
+## Elasticsearch workers overload Sidekiq
+
+In some cases, Elasticsearch cannot connect to GitLab anymore because:
+
+- The Elasticsearch password has been updated on one side only (`Unauthorized [401] ... unable to authenticate user` errors).
+- A firewall or network issue impairs connectivity (`Failed to open TCP connection to <ip>:9200` errors).
+
+These errors are logged in [`gitlab-rails/elasticsearch.log`](../../administration/logs/index.md#elasticsearchlog). To retrieve the errors, use [`jq`](../../administration/logs/log_parsing.md):
+
+```shell
+$ jq --raw-output 'select(.severity == "ERROR") | [.error_class, .error_message] | @tsv' \
+    gitlab-rails/elasticsearch.log |
+  sort | uniq -c
+```
+
+`Elastic` workers and [Sidekiq jobs](../../user/admin_area/index.md#background-jobs) could also appear much more often
+because Elasticsearch frequently attempts to reindex if a previous job fails.
+You can use [`fast-stats`](https://gitlab.com/gitlab-com/support/toolbox/fast-stats#usage)
+or `jq` to count workers in the [Sidekiq logs](../../administration/logs/index.md#sidekiq-logs):
+
+```shell
+$ fast-stats --print-fields=count,score sidekiq/current
+WORKER                            COUNT   SCORE
+ElasticIndexBulkCronWorker          234  123456
+ElasticIndexInitialBulkCronWorker   345   12345
+Some::OtherWorker                    12     123
+...
+
+$ jq '.class' sidekiq/current | sort | uniq -c | sort -nr
+ 234 "ElasticIndexInitialBulkCronWorker"
+ 345 "ElasticIndexBulkCronWorker"
+  12 "Some::OtherWorker"
+...
+```
+
+In this case, `free -m` on the overloaded GitLab node would also show
+unexpectedly high `buff/cache` usage.
diff --git a/doc/integration/akismet.md b/doc/integration/akismet.md
index 09f16c76765..a7ab4ec5a84 100644
--- a/doc/integration/akismet.md
+++ b/doc/integration/akismet.md
@@ -30,8 +30,10 @@ To use Akismet:
 1. Sign in or create a new account.
 1. Select **Show** to reveal the API key, and copy the API key's value.
 1. Sign in to GitLab as an administrator.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Reporting** (`/admin/application_settings/reporting`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > Reporting**.
+1. Expand **Spam and Anti-bot Protection**.
 1. Select the **Enable Akismet** checkbox.
 1. Fill in the API key from step 3.
 1. Save the configuration.
diff --git a/doc/integration/alicloud.md b/doc/integration/alicloud.md
index 4270444f0bb..db27cb78173 100644
--- a/doc/integration/alicloud.md
+++ b/doc/integration/alicloud.md
@@ -88,6 +88,6 @@ Sign in to the AliCloud platform and create an application on it. AliCloud gener
 
 1. Save the configuration file.
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
-   if you installed using Omnibus, or [restart GitLab](../administration/restart_gitlab.md#installations-from-source)
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
+   if you installed using the Linux package, or [restart GitLab](../administration/restart_gitlab.md#installations-from-source)
    if you installed from source.
diff --git a/doc/integration/arkose.md b/doc/integration/arkose.md
index 8f6cec0ac0a..cd0b80e5a66 100644
--- a/doc/integration/arkose.md
+++ b/doc/integration/arkose.md
@@ -48,6 +48,10 @@ sequenceDiagram
     end
 ```
 
+## How do we treat malicious sign-up attempts?
+
+Depending on the risk score received, a user might be required to perform up to three stages of [identity verification](../security/identity_verification.md) to register an account.
+
 ## How do we treat malicious sign-in attempts?
 
 Users are not denied access if Arkose Protect considers they are malicious. However,
diff --git a/doc/integration/auth0.md b/doc/integration/auth0.md
index 07a750143d6..03b4980ad66 100644
--- a/doc/integration/auth0.md
+++ b/doc/integration/auth0.md
@@ -48,7 +48,7 @@ application.
 
 1. Add the provider configuration:
 
-   For Omnibus GitLab:
+   For Linux package installations:
 
    ```ruby
    gitlab_rails['omniauth_providers'] = [
@@ -65,7 +65,7 @@ application.
    ]
    ```
 
-   For installations from source:
+   For self-compiled installations:
 
    ```yaml
    - { name: 'auth0',
@@ -82,9 +82,9 @@ application.
 1. Replace `<your_auth0_client_secret>` with the client secret from the Auth0 Console page.
 1. Replace `<your_auth0_client_secret>` with the domain from the Auth0 Console page.
 1. Reconfigure or restart GitLab, depending on your installation method:
-   - *If you installed from Omnibus GitLab,*
-     [Reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab.
-   - *If you installed from source,*
+   - If you installed using the Linux package,
+     [reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation).
+   - If you self-compiled your installation,
      [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
 
 On the sign-in page there should now be an Auth0 icon below the regular sign-in
diff --git a/doc/integration/azure.md b/doc/integration/azure.md
index 0d8c830c016..d49fa8f53f7 100644
--- a/doc/integration/azure.md
+++ b/doc/integration/azure.md
@@ -29,9 +29,13 @@ You must set the `uid_field`, which differs across the providers:
 | [`omniauth_openid_connect`](https://github.com/omniauth/omniauth_openid_connect/)                               | `sub` | Specify `uid_field` to use another field                              |
 
 To migrate from `omniauth-azure-oauth2` to `omniauth_openid_connect` you
-must change the configuration:
+must change the configuration.
 
-- **For Omnibus installations**
+::Tabs
+
+:::TabTitle Linux package (Omnibus)
+
+Remove some of the existing configuration and add new configuration as shown.
 
 ```diff
 gitlab_rails['omniauth_providers'] = [
@@ -60,7 +64,9 @@ gitlab_rails['omniauth_providers'] = [
 ]
 ```
 
-- **For installations from source**
+:::TabTitle Self-compiled (source)
+
+Remove some of the existing configuration and add new configuration as shown.
 
 ```diff
   - { name: 'azure_oauth2',
@@ -88,10 +94,16 @@ gitlab_rails['omniauth_providers'] = [
     }
 ```
 
+::EndTabs
+
 To migrate for example from `omniauth-azure-activedirectory-v2` to `omniauth_openid_connect` you
-must change the configuration:
+must change the configuration.
 
-- **For Omnibus installations**
+::Tabs
+
+:::TabTitle Linux package (Omnibus)
+
+Remove some of the existing configuration and add new configuration as shown.
 
 ```diff
 gitlab_rails['omniauth_providers'] = [
@@ -120,7 +132,9 @@ gitlab_rails['omniauth_providers'] = [
 ]
 ```
 
-- **For installations from source**
+:::TabTitle Self-compiled (source)
+
+Remove some of the existing configuration and add new configuration as shown.
 
 ```diff
   - { name: 'azure_activedirectory_v2',
@@ -148,6 +162,8 @@ gitlab_rails['omniauth_providers'] = [
     }
 ```
 
+::EndTabs
+
 For more information on other customizations, see [`gitlab_username_claim`](index.md#authentication-sources).
 
 ## Register an Azure application
@@ -299,9 +315,9 @@ Alternatively, add the `User.Read.All` application permission.
 
 1. Save the configuration file.
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
-   if you installed using Omnibus, or [restart GitLab](../administration/restart_gitlab.md#installations-from-source)
-   if you installed from source.
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
+   if you installed using the Linux package, or [restart GitLab](../administration/restart_gitlab.md#installations-from-source)
+   if you self-compiled your installation.
 
 1. Refresh the GitLab sign-in page. A Microsoft icon should display below the
    sign-in form.
diff --git a/doc/integration/bitbucket.md b/doc/integration/bitbucket.md
index 8019eccc421..81564e6eaae 100644
--- a/doc/integration/bitbucket.md
+++ b/doc/integration/bitbucket.md
@@ -110,9 +110,9 @@ you to use.
    from the Bitbucket application page.
 
 1. Save the configuration file.
-1. For the changes to take effect, [reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
-   if you installed using Omnibus GitLab, or [restart](../administration/restart_gitlab.md#installations-from-source)
-   if you installed from source.
+1. For the changes to take effect, [reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
+   if you installed using the Linux package, or [restart](../administration/restart_gitlab.md#installations-from-source)
+   if you self-compiled your installation.
 
 On the sign-in page there should now be a Bitbucket icon below the regular
 sign-in form. Select the icon to begin the authentication process. Bitbucket asks
diff --git a/doc/integration/datadog.md b/doc/integration/datadog.md
index edae3d0f9bd..affc707f504 100644
--- a/doc/integration/datadog.md
+++ b/doc/integration/datadog.md
@@ -27,7 +27,8 @@ project, group, or instance level:
 1. *For project-level or group-level integrations:* In GitLab, go to your project or group.
 1. *For instance-level integrations:*
    1. Sign in to GitLab as a user with administrator access.
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Integrations**.
 1. Scroll to **Add an integration**, and select **Datadog**.
 1. Select **Active** to enable the integration.
@@ -45,7 +46,7 @@ project, group, or instance level:
 <!-- vale gitlab.Spelling = YES -->
 1. Optional. To define any custom tags for all spans at which the integration is being configured,
    enter one tag per line in **Tags**. Each line must be in the format `key:value`. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79665) in GitLab 14.8.)
-1. Optional. Select **Test settings** to test your integration.
+1. Optional. Select **Test settings**.
 1. Select **Save changes**.
 
 When the integration sends data, you can view it in the [CI Visibility](https://app.datadoghq.com/ci)
diff --git a/doc/integration/ding_talk.md b/doc/integration/ding_talk.md
index 97ffab146a0..fd836b80208 100644
--- a/doc/integration/ding_talk.md
+++ b/doc/integration/ding_talk.md
@@ -86,6 +86,6 @@ Sign in to DingTalk Open Platform and create an application on it. DingTalk gene
 
 1. Save the configuration file.
 
-1. For the changes to take effect, if you installed:
-   - Using Omnibus, [reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure).
-   - From source, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
+1. For the changes to take effect, if you:
+   - Installed using the Linux package, [reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation).
+   - Self-compiled your installation, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
diff --git a/doc/integration/external-issue-tracker.md b/doc/integration/external-issue-tracker.md
index c63c2e3fd24..b8cffc449ec 100644
--- a/doc/integration/external-issue-tracker.md
+++ b/doc/integration/external-issue-tracker.md
@@ -21,6 +21,16 @@ The references are automatically converted to links to the issues.
 You can keep the GitLab issue tracker enabled in parallel or disable it. When enabled, the **Issues** link in the
 GitLab menu always opens the internal issue tracker. When disabled, the link is not visible in the menu.
 
+## Disable the GitLab issue tracker
+
+To disable the GitLab issue tracker:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
+1. Expand **Visibility, project features, permissions**.
+1. Under **Issues**, turn off the toggle.
+1. Select **Save changes**.
+
 ## Configure an external issue tracker
 
 To enable an external issue tracker, you must configure the appropriate [integration](../user/project/integrations/index.md).
@@ -28,6 +38,7 @@ To enable an external issue tracker, you must configure the appropriate [integra
 The following external issue tracker integrations are available:
 
 - [Bugzilla](../user/project/integrations/bugzilla.md)
+- [ClickUp](../user/project/integrations/clickup.md)
 - [Custom Issue Tracker](../user/project/integrations/custom_issue_tracker.md)
 - [Engineering Workflow Management](../user/project/integrations/ewm.md)
 - [Jira](../integration/jira/index.md)
diff --git a/doc/integration/facebook.md b/doc/integration/facebook.md
index aeea798715f..4dd17d71602 100644
--- a/doc/integration/facebook.md
+++ b/doc/integration/facebook.md
@@ -107,8 +107,8 @@ Facebook. Facebook generates an app ID and secret key for you to use.
 1. Save the configuration file.
 
 1. For the changes to take effect:
-   - If you installed via Omnibus, [reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure).
-   - If you installed from source, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
+   - If you installed using the Linux package, [reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation).
+   - If you self-compiled your installation, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
 
 On the sign in page there should now be a Facebook icon below the regular sign
 in form. Select the icon to begin the authentication process. Facebook asks the
diff --git a/doc/integration/github.md b/doc/integration/github.md
index 00303754d85..1f7b4f26476 100644
--- a/doc/integration/github.md
+++ b/doc/integration/github.md
@@ -81,7 +81,7 @@ your website could enable the covert redirect attack.
         ]
         ```
 
-     1. Save the file and [reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
+     1. Save the file and [reconfigure](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
         GitLab.
 
    - **For installations from source**
@@ -187,9 +187,9 @@ To fix this issue, you must disable SSL verification:
      git config --global http.sslVerify false
      ```
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
-   if you installed using Omnibus, or [restart GitLab](../administration/restart_gitlab.md#installations-from-source)
-   if you installed from source.
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
+   if you installed using the Linux package, or [restart GitLab](../administration/restart_gitlab.md#installations-from-source)
+   if you self-compiled your installation.
 
 ### Signing in using GitHub Enterprise returns a 500 error
 
@@ -233,7 +233,7 @@ and then connect it to your GitHub account
 
 To fix this issue, you must activate GitHub sign-in in GitLab:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Account**.
 1. In the **Service sign-in** section, select **Connect to GitHub**.
diff --git a/doc/integration/gitlab.md b/doc/integration/gitlab.md
index 59f122a5110..8767d1398ac 100644
--- a/doc/integration/gitlab.md
+++ b/doc/integration/gitlab.md
@@ -12,7 +12,7 @@ To enable the GitLab.com OmniAuth provider you must register your application wi
 GitLab.com generates an application ID and secret key for you to use.
 
 1. Sign in to GitLab.com.
-1. In the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Applications**.
 1. Provide the required details for **Add new application**.
@@ -111,10 +111,9 @@ GitLab.com generates an application ID and secret key for you to use.
 1. Change `'YOUR_APP_ID'` to the Application ID from the GitLab.com application page.
 1. Change `'YOUR_APP_SECRET'` to the secret from the GitLab.com application page.
 1. Save the configuration file.
-1. Based on how GitLab was installed, implement these changes by using
-   the appropriate method:
-   - Omnibus GitLab: [reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure).
-   - Source: [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
+1. Implement these changes by using the appropriate method:
+   - For Linux package installations, [reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation).
+   - For self-compiled installations, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
 
 On the sign-in page, there should now be a GitLab.com icon following the
 regular sign-in form. Select the icon to begin the authentication process.
diff --git a/doc/integration/gitpod.md b/doc/integration/gitpod.md
index 0ba227c2a85..f43f4cb4f40 100644
--- a/doc/integration/gitpod.md
+++ b/doc/integration/gitpod.md
@@ -35,7 +35,7 @@ For more information about Gitpod, see the Gitpod [features](https://www.gitpod.
 
 With the Gitpod integration enabled for your GitLab instance, to enable it for yourself:
 
-1. In the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Preferences**.
 1. Under **Preferences**, locate the **Integrations** section.
 1. Select the **Enable Gitpod integration** checkbox and select **Save changes**.
@@ -45,7 +45,8 @@ With the Gitpod integration enabled for your GitLab instance, to enable it for y
 For self-managed GitLab instances, a GitLab administrator must:
 
 1. Enable the Gitpod integration in GitLab:
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
    1. On the left sidebar, select **Settings > General**.
    1. Expand the **Gitpod** configuration section.
    1. Select the **Enable Gitpod integration** checkbox.
@@ -59,16 +60,12 @@ GitLab users can then [enable the Gitpod integration for themselves](#enable-git
 
 You can launch Gitpod directly from GitLab in one of these ways:
 
-- *From your project's page:*
-  1. Go to your project, then go to the page you want to edit.
-  1. Select the caret (**{chevron-lg-down}**) next to **Web IDE**, and select **Gitpod**
-     from the list:
+- **From a project repository:**
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+  1. In the upper right, select **Edit > Gitpod**.
 
-     ![Gitpod Button on Project Page](img/gitpod_button_project_page_v13_4.png)
-
-  1. Select **Open in Gitpod**.
-- *From a merge request:*
+- **From a merge request:**
   1. Go to your merge request.
-  1. In the upper-right corner, select **Code**, then select **Open in Gitpod**.
+  1. In the upper-right corner, select **Code > Open in Gitpod**.
 
 Gitpod builds your development environment for your branch.
diff --git a/doc/integration/google.md b/doc/integration/google.md
index d60c1b43ed6..211c86b557a 100644
--- a/doc/integration/google.md
+++ b/doc/integration/google.md
@@ -9,29 +9,34 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 To enable the Google OAuth 2.0 OmniAuth provider you must register your application
 with Google. Google generates a client ID and secret key for you to use.
 
-## Enable Google OAuth
-
-In Google's side:
-
-1. Navigate to the [cloud resource manager](https://console.cloud.google.com/cloud-resource-manager) page
-1. Select **Create Project**
-1. Provide the project information:
-   - **Project name** - "GitLab" works just fine here.
-   - **Project ID** - Must be unique to all Google Developer registered applications.
-     Google provides a randomly generated Project ID by default. You can use
-     the randomly generated ID or choose a new one.
-1. Refresh the page and you should see your new project in the list
-1. Go to the [Google API Console](https://console.developers.google.com/apis/dashboard)
-1. In the upper-left corner, select the previously created project
-1. Select **Credentials** from the sidebar
-1. Select **OAuth consent screen** and fill the form with the required information
-1. In the **Credentials** tab, select **Create credentials > OAuth client ID**
-1. Fill in the required information
-   - **Application type** - Choose "Web Application"
-   - **Name** - Use the default one or provide your own
-   - **Authorized JavaScript origins** -This isn't really used by GitLab but go
-     ahead and put `https://gitlab.example.com`
-   - **Authorized redirect URIs** - Enter your domain name followed by the
+To enable Google OAuth, you must configure the:
+
+- Google Cloud Resource Manager
+- Google API Console
+- GitLab server
+
+## Configure the Google Cloud Resource Manager
+
+1. Go to the [Google Cloud Resource Manager](https://console.cloud.google.com/cloud-resource-manager).
+1. Select **CREATE PROJECT**.
+1. In **Project name**, enter `GitLab`.
+1. In **Project ID**, Google provides a randomly generated project ID by default.
+   You can use this randomly generated ID or create a new one. If you create a new
+   ID, it must be unique to all Google Developer registered applications.
+
+To see your new project in the list, refresh the page.
+
+## Configure the Google API Console
+
+1. Go to the [Google API Console](https://console.developers.google.com/apis/dashboard).
+1. In the upper-left corner, select your previously created project.
+1. Select **OAuth consent screen** and complete the fields.
+1. Select **Credentials > Create credentials > OAuth client ID**.
+1. Complete the fields:
+   - **Application type**: Select **Web application**.
+   - **Name**: Use the default name or enter your own.
+   - **Authorized JavaScript origins**: Enter `https://gitlab.example.com`.
+   - **Authorized redirect URIs**: Enter your domain name followed by the
      callback URIs one at a time:
 
      ```plaintext
@@ -39,22 +44,22 @@ In Google's side:
      https://gitlab.example.com/-/google_api/auth/callback
      ```
 
-1. You should now be able to see a Client ID and Client secret. Note them down
+1. You should see a client ID and client secret. Note them down
    or keep this page open as you need them later.
-1. To enable projects to access [Google Kubernetes Engine](../user/infrastructure/clusters/index.md), you must also
-   enable these APIs:
+1. To enable projects to access [Google Kubernetes Engine](../user/infrastructure/clusters/index.md),
+   you must also enable the:
    - Google Kubernetes Engine API
    - Cloud Resource Manager API
    - Cloud Billing API
 
-   To do so you should:
+   To do so:
 
    1. Go to the [Google API Console](https://console.developers.google.com/apis/dashboard).
    1. Select **ENABLE APIS AND SERVICES** at the top of the page.
    1. Find each of the above APIs. On the page for the API, select **ENABLE**.
       It may take a few minutes for the API to be fully functional.
 
-On your GitLab server:
+## Configure the GitLab server
 
 1. Open the configuration file.
 
@@ -83,8 +88,8 @@ On your GitLab server:
      {
        name: "google_oauth2",
        # label: "Provider name", # optional label for login button, defaults to "Google"
-       app_id: "YOUR_APP_ID",
-       app_secret: "YOUR_APP_SECRET",
+       app_id: "<YOUR_APP_ID>",
+       app_secret: "<YOUR_APP_SECRET>",
        args: { access_type: "offline", approval_prompt: "" }
      }
    ]
@@ -100,8 +105,8 @@ On your GitLab server:
        args: { access_type: 'offline', approval_prompt: '' } }
    ```
 
-1. Change `YOUR_APP_ID` to the client ID from the Google Developer page
-1. Similarly, change `YOUR_APP_SECRET` to the client secret
+1. Replace `<YOUR_APP_ID>` with the client ID from the Google Developer page.
+1. Replace `<YOUR_APP_SECRET>` with the client secret from the Google Developer page.
 1. Make sure that you configure GitLab to use a fully-qualified domain name, as
    Google doesn't accept raw IP addresses.
 
@@ -120,8 +125,8 @@ On your GitLab server:
 
 1. Save the configuration file.
 1. For the changes to take effect:
-   - If you installed via Omnibus, [reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure).
-   - If you installed from source, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
+   - If you installed using the Linux package, [reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation).
+   - If you self-compiled your installation, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
 
 On the sign in page there should now be a Google icon below the regular sign in
 form. Select the icon to begin the authentication process. Google asks the
diff --git a/doc/integration/img/gitpod_button_project_page_v13_4.png b/doc/integration/img/gitpod_button_project_page_v13_4.png
deleted file mode 100644
index 55a70d89169..00000000000
--- a/doc/integration/img/gitpod_button_project_page_v13_4.png
+++ /dev/null
diff --git a/doc/integration/jenkins.md b/doc/integration/jenkins.md
index 3db02ed1221..760488b895f 100644
--- a/doc/integration/jenkins.md
+++ b/doc/integration/jenkins.md
@@ -117,8 +117,8 @@ Configure the GitLab integration with Jenkins in one of the following ways.
 GitLab recommends this approach for Jenkins integrations because it is easier to configure
 than the [webhook integration](#configure-a-webhook).
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Jenkins**.
 1. Select the **Active** checkbox.
 1. Select the events you want GitLab to trigger a Jenkins build for:
@@ -134,7 +134,7 @@ than the [webhook integration](#configure-a-webhook).
    project.
 1. If your Jenkins server requires
    authentication, enter the **Username** and **Password**.
-1. To test the connection to Jenkins, select **Test settings**.
+1. Optional. Select **Test settings**.
 1. Select **Save changes**.
 
 ### Configure a webhook
diff --git a/doc/integration/jira/configure.md b/doc/integration/jira/configure.md
index 3f3511c3838..89afa998431 100644
--- a/doc/integration/jira/configure.md
+++ b/doc/integration/jira/configure.md
@@ -10,6 +10,8 @@ The Jira issue integration connects one or more GitLab projects to a Jira instan
 
 ## Configure the integration
 
+> Authentication with Jira personal access tokens was [introduced](https://gitlab.com/groups/gitlab-org/-/epics/8222) in GitLab 16.0.
+
 Prerequisites:
 
 - Your GitLab installation must not use a [relative URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configure-a-relative-url-for-gitlab).
@@ -17,55 +19,51 @@ Prerequisites:
   the email address you used to create the token.
 - **For Jira Data Center or Jira Server**, you must have one of the following:
   - [Jira username and password](jira_server_configuration.md).
-  - Jira personal access token.
+  - Jira personal access token (GitLab 16.0 and later).
 
 You can enable the Jira issue integration by configuring your project settings in GitLab.
-You can also configure these settings at the:
-
-- [Group level](../../user/admin_area/settings/project_integration_management.md#manage-group-level-default-settings-for-a-project-integration)
-- [Instance level](../../user/admin_area/settings/project_integration_management.md#manage-instance-level-default-settings-for-a-project-integration) for self-managed GitLab
+You can configure these settings at the [group level](../../user/admin_area/settings/project_integration_management.md#manage-group-level-default-settings-for-a-project-integration) or at the [instance level](../../user/admin_area/settings/project_integration_management.md#manage-instance-level-default-settings-for-a-project-integration) for self-managed GitLab.
 
 To configure your project settings in GitLab:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Jira**.
-1. Select **Enable integration**.
-1. Select **Trigger** actions. Your choice determines whether a mention of Jira issue
-   (in a GitLab commit, merge request, or both) creates a cross-link in Jira back to GitLab.
-1. To comment in the Jira issue when a **Trigger** action is made in GitLab, select
-   **Enable comments**.
-1. To transition Jira issues when a
-   [closing reference](../../user/project/issues/managing_issues.md#closing-issues-automatically)
-   is made in GitLab, select **Enable Jira transitions**.
-1. Provide Jira configuration information:
+1. In **Enable integration**, select the **Active** checkbox.
+1. Provide connection details:
    - **Web URL**: Base URL for the Jira instance web interface you're linking to
      this GitLab project (for example, `https://jira.example.com`).
    - **Jira API URL**: Base URL for the Jira instance API (for example, `https://jira-api.example.com`).
      If this URL is not set, the **Web URL** value is used by default. For Jira Cloud, leave **Jira API URL** blank.
-   - **Authentication type**: From the dropdown list, select:
-     - **Basic**
-     - **Jira personal access token (Jira Data Center and Jira Server only)**
-   - **Email or username** (relevant to **Basic** authentication only):
-     - For Jira Cloud, enter an email.
-     - For Jira Data Center or Jira Server, enter a username.
-   - **New API token, password, or Jira personal access token**:
-     - For **Basic** authentication:
-         - For Jira Cloud, enter an API token.
-         - For Jira Data Center or Jira Server, enter a password.
-     - For **Jira personal access token** authentication, enter a personal access token.
-1. To enable users to [view Jira issues](issues.md#view-jira-issues) inside the GitLab project, select **Enable Jira issues** and
-   enter a Jira project key.
-
-   You can display issues only from a single Jira project in a given GitLab project.
+   - **Authentication method**:
+     - **Basic**:
+       - **Email or username**:
+          - For Jira Cloud, enter an email.
+          - For Jira Data Center or Jira Server, enter a username.
+       - **API token or password**:
+          - For Jira Cloud, enter an API token.
+          - For Jira Data Center or Jira Server, enter a password.
+     - **Jira personal access token** (only available for Jira Data Center and Jira Server): Enter a personal access token.
+1. Provide trigger settings:
+   - Select **Commit**, **Merge request**, or both as triggers. When you mention a Jira issue ID in GitLab,
+   GitLab links to that issue.
+   - To add a comment to the Jira issue that links back to GitLab, select the
+   **Enable comments** checkbox and the information that the comment displays.
+   - To [transition Jira issues automatically](../../user/project/issues/managing_issues.md#closing-issues-automatically) in GitLab,
+   select the **Enable Jira transitions** checkbox.
+1. In the **Jira issue matching** section:
+   - For **Jira issue regex**, [enter a regex pattern](issues.md#use-regular-expression).
+   - For **Jira issue prefix**, [enter a prefix](issues.md#use-a-prefix).
+1. In the **Issues** section:
+   - To [view Jira issues](issues.md#view-jira-issues) in a GitLab project, select the **Enable Jira issues** checkbox and
+   enter a Jira project key. You can only view issues from a single Jira project in a GitLab project.
 
    WARNING:
-   If you enable Jira issues with this setting, all users with access to this GitLab project
-   can view all issues from the specified Jira project.
+   When you enable this setting, all users with access to that GitLab project
+   can view all issues from the Jira project you've specified.
 
-1. To enable [issue creation for vulnerabilities](../../user/application_security/vulnerabilities/index.md#create-a-jira-issue-for-a-vulnerability), select **Enable Jira issue creation from vulnerabilities**.
-1. Select the **Jira issue type**. If the dropdown list is empty, select **Refresh** (**{retry}**) and try again.
-1. To verify the Jira connection is working, select **Test settings**.
+   - To [create Jira issues for vulnerabilities](../../user/application_security/vulnerabilities/index.md#create-a-jira-issue-for-a-vulnerability), select the **Enable Jira issue creation from vulnerabilities** checkbox.
+1. Optional. Select **Test settings**.
 1. Select **Save changes**.
 
 Your GitLab project can now interact with all Jira projects in your instance, and the project
@@ -77,7 +75,7 @@ To configure the Jira issue integration for Jira Cloud, you must have a Jira Clo
 To create a Jira Cloud API token:
 
 1. Sign in to [Atlassian](https://id.atlassian.com/manage-profile/security/api-tokens)
-   from an account with **write** access to Jira projects.
+   from an account with write access to Jira projects.
 
    The link opens the **API tokens** page. Alternatively, from your Atlassian
    profile, select **Account Settings > Security > Create and manage API tokens**.
@@ -85,20 +83,20 @@ To create a Jira Cloud API token:
 1. Select **Create API token**.
 1. In the dialog, enter a label for your token and select **Create**.
 
-To copy the API token, select **Copy** and paste the token somewhere safe.
+To copy the API token, select **Copy**.
 
 ## Migrate from Jira Server to Jira Cloud in GitLab
 
 To migrate from Jira Server to Jira Cloud in GitLab and maintain your Jira integration:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Jira**.
 1. In **Web URL**, enter the new Jira site URL (for example, `https://myjirasite.atlassian.net`).
-1. In **Username or Email**, enter the username or email registered on your Jira profile.
+1. In **Email or username**, enter the email registered on your Jira profile.
 1. [Create a Jira Cloud API token](#create-a-jira-cloud-api-token), and copy the token value.
-1. In **Password or API token**, paste the API token value.
-1. Optional. Select **Test settings** to check if the connection is working.
+1. In **API token or password**, paste the API token value.
+1. Optional. Select **Test settings**.
 1. Select **Save changes**.
 
 To update existing Jira issue references in GitLab to use the new Jira site URL, you must [invalidate the Markdown cache](../../administration/invalidate_markdown_cache.md#invalidate-the-cache).
diff --git a/doc/integration/jira/connect-app.md b/doc/integration/jira/connect-app.md
index e60eeb8fba1..67f51a6f472 100644
--- a/doc/integration/jira/connect-app.md
+++ b/doc/integration/jira/connect-app.md
@@ -20,6 +20,8 @@ If you use Jira Data Center or Jira Server, use the [Jira DVCS connector](dvcs/i
 
 ## Install the GitLab for Jira Cloud app **(FREE SAAS)**
 
+> Link groups feature [renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/331432) from Add namespace in GitLab 16.1.
+
 Prerequisites:
 
 - You must have at least the Maintainer role for the GitLab group.
@@ -35,7 +37,7 @@ To install the GitLab for Jira Cloud app:
 
 1. To go to the configurations page, select **Get started**.
    You can always access this page in **Jira Settings > Apps > Manage apps**.
-1. For a list of groups to link, select **Add namespace**.
+1. For a list of groups to link, select **Link groups**.
 1. To link to a group, select **Link**.
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
@@ -50,11 +52,9 @@ After you add a group, the following data is synced to Jira for all projects in
 
 ## Update the GitLab for Jira Cloud app
 
-Most updates to the app are fully automated and don't require any user interaction. See the
-[Atlassian Marketplace documentation](https://developer.atlassian.com/platform/marketplace/upgrading-and-versioning-cloud-apps/)
-for details.
-
-If the app requires additional permissions, [the update must first be manually approved in Jira](https://developer.atlassian.com/platform/marketplace/upgrading-and-versioning-cloud-apps/#changes-that-require-manual-customer-approval).
+Most updates to the app are automatic. For more information, see the
+[Atlassian documentation](https://developer.atlassian.com/platform/marketplace/upgrading-and-versioning-cloud-apps/).
+If the app requires additional permissions, [you must manually approve the update in Jira](https://developer.atlassian.com/platform/marketplace/upgrading-and-versioning-cloud-apps/#changes-that-require-manual-customer-approval).
 
 ## Set up OAuth authentication for self-managed instances **(FREE SELF)**
 
@@ -68,8 +68,9 @@ You must enable OAuth authentication to:
 
 To create an OAuth application:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Applications** (`/admin/applications`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Applications**.
 1. Select **New application**.
 1. In **Redirect URI**:
    - If you're installing the app from the official marketplace listing, enter `https://gitlab.com/-/jira_connect/oauth_callbacks`.
@@ -78,7 +79,7 @@ To create an OAuth application:
 1. In **Scopes**, select the `api` checkbox only.
 1. Select **Save application**.
 1. Copy the **Application ID** value.
-1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
+1. On the left sidebar, select **Settings > General**.
 1. Expand **GitLab for Jira App**.
 1. Paste the **Application ID** value into **Jira Connect Application ID**.
 1. Select **Save changes**.
@@ -105,7 +106,11 @@ To create branches from Jira Cloud, [install the app manually](#install-the-gitl
 - The instance must be publicly available.
 - The instance must be on GitLab version 15.7 or later.
 - You must set up [OAuth authentication](#set-up-oauth-authentication-for-self-managed-instances).
-- Your network must allow inbound and outbound connections between GitLab and Jira.
+- Your network must allow inbound and outbound connections between GitLab and Jira. For self-managed instances that are behind a
+  firewall and cannot be directly accessed from the internet, you can:
+  - Open your firewall and only allow inbound traffic from [Atlassian IP addresses](https://support.atlassian.com/organization-administration/docs/ip-addresses-and-domains-for-atlassian-cloud-products/#Outgoing-Connections).
+  - Set up an internet-facing reverse proxy in front of your self-managed instance. To secure this proxy further, only allow inbound
+    traffic from [Atlassian IP addresses](https://support.atlassian.com/organization-administration/docs/ip-addresses-and-domains-for-atlassian-cloud-products/#Outgoing-Connections).
 
 ### Set up your instance
 
@@ -113,8 +118,9 @@ To create branches from Jira Cloud, [install the app manually](#install-the-gitl
 
 To set up your self-managed instance for the GitLab for Jira Cloud app in GitLab 15.7 and later:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > General**.
 1. Expand **GitLab for Jira App**.
 1. In **Jira Connect Proxy URL**, enter `https://gitlab.com`.
 1. Select **Save changes**.
@@ -207,8 +213,9 @@ You might want to use a proxy if you're managing multiple GitLab instances but o
 
 To configure your GitLab instance to serve as a proxy:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > General**.
 1. Expand **GitLab for Jira App**.
 1. Select **Enable public key storage**.
 1. Select **Save changes**.
@@ -276,8 +283,9 @@ To resolve this issue, disable the **Jira Connect Proxy URL** setting.
 
 - In GitLab 15.8 and later:
 
-  1. On the top bar, select **Main menu > Admin**.
-  1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
+  1. On the left sidebar, select **Settings > General**.
   1. Expand **GitLab for Jira App**.
   1. Clear the **Jira Connect Proxy URL** text box.
   1. Select **Save changes**.
@@ -306,14 +314,9 @@ To resolve this issue on GitLab self-managed, follow one of the solutions below,
   - In all GitLab versions:
     - Re-install the GitLab for Jira Cloud app. This method might remove all synced data from the Jira development panel.
 
-### `Failed to update GitLab version` error when setting up the GitLab for Jira Cloud app for self-managed instances
+### `Failed to update the GitLab instance` for self-managed instances
 
-When you set up the GitLab for Jira Cloud app, you might get the following message after you enter your
-self-managed instance URL:
-
-```plaintext
-Failed to update GitLab version. Please try again.
-```
+When you set up the GitLab for Jira Cloud app, you might get a `Failed to update the GitLab instance` error after you enter your self-managed instance URL.
 
 To resolve this issue, ensure all prerequisites for your installation method have been met:
 
diff --git a/doc/integration/jira/dvcs/index.md b/doc/integration/jira/dvcs/index.md
index 0406fef3f1e..3ebbc9a921d 100644
--- a/doc/integration/jira/dvcs/index.md
+++ b/doc/integration/jira/dvcs/index.md
@@ -49,16 +49,14 @@ To create a GitLab application for DVCS:
 
 To configure Jira for DVCS:
 
-1. Go to your DVCS account. **For Jira Server**, select **Settings (gear) > Applications > DVCS accounts**.
-1. To create a new integration, for **Host**, select **GitLab** or **GitLab Self-Managed**.
-1. For **Team or User Account**, enter the relative path of a top-level GitLab group that [the GitLab user](#create-a-gitlab-application-for-dvcs) can access.
-1. In the **Host URL** text box, enter the appropriate URL.
-   Replace `<gitlab.example.com>` with your GitLab instance domain.
-   Use `https://<gitlab.example.com>`.
-1. For **Client ID**, use the [**Application ID** value](#create-a-gitlab-application-for-dvcs).
-1. For **Client Secret**, use the [**Secret** value](#create-a-gitlab-application-for-dvcs).
-1. Ensure that all other checkboxes are selected.
-1. To create the DVCS account, select **Add**, then **Continue**.
+1. On the top bar, in the upper-right corner, select **Administration** (**{settings}**) > **Applications**.
+1. On the left sidebar, select **DVCS accounts**.
+1. From the **Host** dropdown list, select **GitLab** or **GitLab Self-Managed**.
+1. For **Team or User Account**, enter the relative path of a [top-level GitLab group](#create-a-gitlab-application-for-dvcs) the GitLab user can access.
+1. For **Host URL**, enter the domain of your GitLab instance.
+1. From the **Client Configuration** dropdown list, select the [application link](#create-a-gitlab-application-for-dvcs) you've created.
+1. Optional. Select or clear the **Auto Link New Repositories** and **Enable Smart Commits** checkboxes.
+1. Select **Add**, then **Continue**.
 
 Jira redirects to GitLab where you have to confirm the authorization. GitLab then redirects back to Jira
 where the synced projects are displayed in the new account. The initial sync takes a few minutes.
@@ -72,6 +70,10 @@ personal namespaces, repeat the previous steps with additional Jira DVCS account
 Jira imports commits and branches for GitLab projects every 60 minutes. To refresh the data manually in Jira:
 
 1. Sign in to your Jira instance as the user you configured the integration with.
-1. Go to **Settings (gear) > Applications**.
-1. Select **DVCS accounts**.
-1. In the **Last activity** column, next to the repository you want to refresh, select **Refresh** (**{retry}**).
+1. On the top bar, in the upper-right corner, select **Administration** (**{settings}**) > **Applications**.
+1. On the left sidebar, select **DVCS accounts**.
+1. To refresh one or more repositories in a DVCS account:
+   - **For all repositories**, next to the account, select the ellipsis (**{ellipsis_h}**) > **Refresh repositories**.
+   - **For a single repository**:
+     1. Select the account.
+     1. Hover over the repository you want to refresh, and in the **Last activity** column, select **Click to sync repository** (**{retry}**).
diff --git a/doc/integration/jira/dvcs/troubleshooting.md b/doc/integration/jira/dvcs/troubleshooting.md
index 541c743b609..31038526d63 100644
--- a/doc/integration/jira/dvcs/troubleshooting.md
+++ b/doc/integration/jira/dvcs/troubleshooting.md
@@ -137,7 +137,7 @@ In the example above, the merge requests feature is disabled.
 
 To resolve the issue, enable the relevant feature:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. Use the toggles to enable the features as needed.
@@ -146,7 +146,7 @@ To resolve the issue, enable the relevant feature:
 
 To find webhook logs in a DVCS-linked project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. On the left sidebar, select **Settings > Webhooks**.
 1. Scroll down to **Project Hooks**.
 1. Next to the log that points to your Jira instance, select **Edit**.
diff --git a/doc/integration/jira/issues.md b/doc/integration/jira/issues.md
index 086d478ac15..7ed9d3ab329 100644
--- a/doc/integration/jira/issues.md
+++ b/doc/integration/jira/issues.md
@@ -27,7 +27,7 @@ git commit -m "GIT-1 this is a test commit"
 
 GitLab adds to that Jira issue:
 
-- A reference in the **Web links** section
+- A reference in the **Web links** section.
 - A comment in the **Activity** section that follows this format:
 
   ```plaintext
@@ -41,9 +41,9 @@ GitLab adds to that Jira issue:
   - `COMMENTLINK`: Link to where the Jira issue is mentioned.
   - `ENTITY_TITLE`: Title of the GitLab commit (first line), issue, or merge request.
 
-Only a single cross-reference comment appears in Jira per GitLab issue, merge request, or commit.
+Only a single cross-reference appears in Jira per GitLab issue, merge request, or commit.
 For example, multiple comments on a GitLab merge request that reference a Jira issue
-create only a single cross-reference comment back to that merge request in Jira.
+create only a single cross-reference back to that merge request in Jira.
 
 You can [disable comments](#disable-comments-on-jira-issues) on issues.
 
@@ -55,8 +55,8 @@ You can [disable comments](#disable-comments-on-jira-issues) on issues.
 With this integration, you can prevent merge requests from being merged if they do not refer to a Jira issue.
 To enable this feature:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. In the **Merge checks** section, select **Require an associated issue from Jira**.
 1. Select **Save**.
 
@@ -79,8 +79,8 @@ When you don't configure custom rules, the [default behavior](https://gitlab.com
 
 To define a regex pattern for Jira issue keys:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Jira**.
 1. Go to the **Jira issue matching** section.
 1. In the **Jira issue regex** text box, enter a regex pattern.
@@ -92,8 +92,8 @@ For more information, see the [Atlassian documentation](https://confluence.atlas
 
 To define a prefix for Jira issue keys:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Jira**.
 1. Go to the **Jira issue matching** section.
 1. In the **Jira issue prefix** text box, enter a prefix.
@@ -138,8 +138,8 @@ provided your GitLab administrator [has configured the integration](configure.md
 
 To view Jira issues:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues > Jira issues**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Plan > Jira issues**.
 
 The issues are sorted by **Created date** by default, with the most recently created issues listed at the top.
 
@@ -173,10 +173,6 @@ of these filters:
 Enhancements to use these filters through the user interface
 [are planned](https://gitlab.com/groups/gitlab-org/-/epics/3622).
 
-## Create a Jira issue for a vulnerability **(ULTIMATE)**
-
-You can create a Jira issue for a vulnerability from a [Vulnerability Page](../../user/application_security/vulnerabilities/index.md#create-a-jira-issue-for-a-vulnerability).
-
 ## Automatic issue transitions
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55773) in GitLab 13.11.
@@ -217,3 +213,7 @@ adding a comment to the Jira issue:
 
 1. Refer to the [Configure GitLab](configure.md) instructions.
 1. Clear the **Enable comments** checkbox.
+
+## Related topics
+
+- [Create a Jira issue for a vulnerability](../../user/application_security/vulnerabilities/index.md#create-a-jira-issue-for-a-vulnerability)
diff --git a/doc/integration/jira/jira_server_configuration.md b/doc/integration/jira/jira_server_configuration.md
index c840e1ebde5..672df5d615f 100644
--- a/doc/integration/jira/jira_server_configuration.md
+++ b/doc/integration/jira/jira_server_configuration.md
@@ -4,55 +4,55 @@ group: Import and Integrate
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Jira Server credentials **(FREE)**
+# Tutorial: Create Jira credentials **(FREE)**
 
-To [integrate Jira with GitLab](configure.md), you should create a separate Jira user account for your Jira projects
-to access projects in GitLab. This Jira user account must have write access to your Jira projects.
-To create the credentials:
+This tutorial shows you how to create Jira credentials. You can use your new Jira credentials to
+configure the [Jira issue integration](configure.md) in GitLab for Jira Data Center or Jira Server.
 
-1. [Create a Jira Server user](#create-a-jira-server-user).
-1. [Create a Jira Server group for the user](#create-a-jira-server-group-for-the-user).
+To create Jira credentials, here's what we're going to do:
+
+1. [Create a Jira user](#create-a-jira-user).
+1. [Create a Jira group for the user](#create-a-jira-group-for-the-user).
 1. [Create a permission scheme for the group](#create-a-permission-scheme-for-the-group).
 
-Alternatively, you can use an existing Jira user account, provided the user belongs to a Jira group that
-has been granted the **Administer Projects** [permission scheme](#create-a-permission-scheme-for-the-group).
+Prerequisite:
+
+- You must have administrator access to the Jira instance.
+
+## Create a Jira user
 
-After you select a Jira user account, [configure the integration](configure.md#configure-the-integration) in GitLab to use the account.
+To create a Jira user:
 
-## Create a Jira Server user
+1. Sign in to your Jira instance as an administrator.
+1. On the top bar, in the upper-right corner, select **Administration** (**{settings}**) > **User management**.
+1. [Create a new user account](https://confluence.atlassian.com/adminjiraserver/create-edit-or-remove-a-user-938847025.html#Create,edit,orremoveauser-CreateusersmanuallyinJira) with write access to your Jira projects.
 
-To create a Jira Server user:
+   Alternatively, you can use an existing user account, provided the user belongs to a Jira group that has been granted
+   the **Administer Projects** [permission scheme](#create-a-permission-scheme-for-the-group).
 
-1. Sign in to your Jira instance as a Jira administrator.
-1. On the top bar, in the upper-right corner, select the gear icon, then
-   select **User Management**.
-1. [Create a new user account manually](https://confluence.atlassian.com/adminjiraserver/create-edit-or-remove-a-user-938847025.html#Create,edit,orremoveauser-CreateusersmanuallyinJira) with write access to
-   projects in Jira.
-   - **Email address**: You should use a valid email address.
-   - **Username**: Set the username to `gitlab`.
-   - **Password**: You must set a password because the Jira issue integration does not
-     support SSO such as SAML.
+   - In **Email address**, enter a valid email address.
+   - In **Username**, enter `gitlab`.
+   - In **Password**, enter a password (the Jira issue integration does not support SSO such as SAML).
 1. Select **Create user**.
 
 Now that you've created a user named `gitlab`, it's time to create a group for the user.
 
-## Create a Jira Server group for the user
+## Create a Jira group for the user
 
-To create a Jira Server group for the user:
+To create a Jira group for the user:
 
-1. Sign in to your Jira instance as a Jira administrator.
-1. On the top bar, in the upper-right corner, select the gear icon, then
-   select **User Management**.
+1. Sign in to your Jira instance as an administrator.
+1. On the top bar, in the upper-right corner, select **Administration** (**{settings}**) > **User management**.
 1. On the left sidebar, select **Groups**.
-1. In the **Add group** section, enter a **Name** for the group (for example,
+1. In the **Add group** section, enter a name for the group (for example,
    `gitlab-developers`), then select **Add group**.
-1. To add the `gitlab` user to the `gitlab-developers` group, select **Edit members**.
+1. To add the `gitlab` user to the new `gitlab-developers` group, select **Edit members**.
    The `gitlab-developers` group appears as a selected group.
 <!-- vale gitlab.BadPlurals = NO -->
 1. In the **Add members to selected group(s)** section, enter `gitlab`.
+<!-- vale gitlab.BadPlurals = YES -->
 1. Select **Add selected users**.
    The `gitlab` user appears as a group member.
-<!-- vale gitlab.BadPlurals = YES -->
 
 Now that you've added the `gitlab` user to a new group named `gitlab-developers`,
 it's time to create a permission scheme for the group.
@@ -61,15 +61,18 @@ it's time to create a permission scheme for the group.
 
 To create a permission scheme for the group:
 
-1. Sign in to your Jira instance as a Jira administrator.
-1. On the top bar, in the upper-right corner, select the gear icon, then
-   select **Issues**.
-1. On the left sidebar, select **Permission Schemes**.
-1. Select **Add Permission Scheme**, enter a **Name** and (optionally) a
-   **Description**, then select **Add**.
-1. In the permissions scheme list, locate your new permissions scheme, and
-   select **Permissions**.
+1. Sign in to your Jira instance as an administrator.
+1. On the top bar, in the upper-right corner, select **Administration** (**{settings}**) > **Issues**.
+1. On the left sidebar, select **Permission schemes**.
+1. Select **Add permission scheme**.
+1. In the **Add permission scheme** dialog:
+   - Enter a name for the scheme.
+   - Optional. Enter a description for the scheme.
+1. Select **Add**.
+1. On the **Permission schemes** page, in the **Actions** column, select **Permissions** for the new scheme.
 1. Next to **Administer Projects**, select **Edit**.
+1. In the **Grant permission** dialog, for **Granted to**, select **Group**.
 1. From the **Group** dropdown list, select `gitlab-developers`, then select **Grant**.
 
-You need the new Jira username and password when you [configure the integration](configure.md#configure-the-integration) in GitLab.
+You've done it! You can now use your new Jira username and password to configure the
+[Jira issue integration](configure.md) in GitLab for Jira Data Center or Jira Server.
diff --git a/doc/integration/jira/troubleshooting.md b/doc/integration/jira/troubleshooting.md
index 586f09be751..d592455788d 100644
--- a/doc/integration/jira/troubleshooting.md
+++ b/doc/integration/jira/troubleshooting.md
@@ -16,7 +16,7 @@ set up for the [Jira integration](configure.md) has permission to:
 - Post comments on a Jira issue.
 - Transition the Jira issue.
 
-Jira issue references and update comments do not work if the GitLab issue tracker is disabled.
+Jira issue references and update comments do not work if the [GitLab issue tracker](../../integration/external-issue-tracker.md) is disabled.
 
 If you [restrict IP addresses for Jira access](https://support.atlassian.com/security-and-access-policies/docs/specify-ip-addresses-for-product-access/), make sure you add your self-managed IP addresses or [GitLab.com IP range](../../user/gitlab_com/index.md#ip-range) to the allowlist in Jira.
 
diff --git a/doc/integration/kerberos.md b/doc/integration/kerberos.md
index c2be5a5a91c..62441f6de8f 100644
--- a/doc/integration/kerberos.md
+++ b/doc/integration/kerberos.md
@@ -82,7 +82,7 @@ For source installations, make sure the `kerberos` gem group
    To avoid GitLab creating users automatically on their first sign in through Kerberos,
    don't set `kerberos` for `gitlab_rails['omniauth_allow_single_sign_on']`.
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 GitLab now offers the `negotiate` authentication method for signing in and
 HTTP Git access, enabling Git clients that support this authentication protocol
@@ -106,7 +106,8 @@ set up GitLab to create a new account when a Kerberos user tries to sign in.
 If you're an administrator, you can link a Kerberos account to an
 existing GitLab account. To do so:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Overview > Users**.
 1. Select a user, then select the **Identities** tab.
 1. From the **Provider** dropdown list, select **Kerberos**.
@@ -115,7 +116,7 @@ existing GitLab account. To do so:
 
 If you're not an administrator:
 
-1. In the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Account**.
 1. In the **Service sign-in** section, select **Connect Kerberos**.
@@ -147,7 +148,8 @@ With that information at hand:
       ```
 
       1. As an administrator, you can confirm the new, blocked account:
-         1. On the top bar, select **Main menu > Admin**.
+         1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+         1. Select **Admin Area**.
          1. On the left sidebar, select **Overview > Users** and review the **Blocked** tab.
       1. You can enable the user.
    1. If `block_auto_created_users` is false, the Kerberos user is
@@ -193,7 +195,7 @@ ignored and an LDAP identity is not linked.
    gitlab_rails['kerberos_simple_ldap_linking_allowed_realms'] = ['example.com','kerberos.example.com']
    ```
 
-1. Save the file and [reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. Save the file and [reconfigure](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
    GitLab for the changes to take effect.
 
 ---
@@ -284,7 +286,7 @@ this can happen in GitLab CI/CD jobs that [authenticate with the CI/CD job token
    gitlab_rails['kerberos_https'] = true
    ```
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 After this change, Git remote URLs have to be updated to
 `https://gitlab.example.com:8443/mygroup/myproject.git` to use
@@ -332,7 +334,7 @@ To disable password-based Kerberos sign-ins, remove the OmniAuth provider
    ]
    ```
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 NOTE:
 Removing the `kerberos` OmniAuth provider can also resolve a rare
diff --git a/doc/integration/mattermost/index.md b/doc/integration/mattermost/index.md
index e1183f62225..0f9192f9a84 100644
--- a/doc/integration/mattermost/index.md
+++ b/doc/integration/mattermost/index.md
@@ -10,7 +10,7 @@ NOTE:
 This document applies to GitLab 11.0 and later.
 
 You can run a [GitLab Mattermost](https://gitlab.com/gitlab-org/gitlab-mattermost)
-service on your GitLab server. Mattermost is not part of the single application that GitLab is. There is a good integration between [Mattermost and GitLab](https://mattermost.com/solutions/mattermost-gitlab/), and our Omnibus installer allows you to easily install it. But it is a separate application from a separate company.
+service on your GitLab server. Mattermost is not part of the single application that GitLab is. There is a good integration between [Mattermost and GitLab](https://mattermost.com/solutions/mattermost-gitlab/), and our Linux package allows you to easily install it. But it is a separate application from a separate company.
 
 ## Prerequisites
 
@@ -38,7 +38,7 @@ GitLab Mattermost is disabled by default. To enable it:
 
 1. Confirm that GitLab Mattermost is reachable at `https://mattermost.example.com` and authorized to connect to GitLab. Authorizing Mattermost with GitLab allows users to use GitLab as an SSO provider.
 
-The Omnibus GitLab package attempts to automatically authorize GitLab Mattermost with GitLab if the applications are running on the same server.
+The Linux package attempts to automatically authorize GitLab Mattermost with GitLab if the applications are running on the same server.
 
 Automatic authorization requires access to the GitLab database. If the GitLab database is not available
 you need to manually authorize GitLab Mattermost for access to GitLab using the process described in the [Authorize GitLab Mattermost section](#authorize-gitlab-mattermost).
@@ -86,7 +86,7 @@ Once the configuration is set, run `sudo gitlab-ctl reconfigure` to apply the ch
 ## Running GitLab Mattermost on its own server
 
 If you want to run GitLab and GitLab Mattermost on two separate servers the GitLab services are still set up on your GitLab Mattermost server, but they do not accept user requests or
-consume system resources. You can use the following settings and configuration details on the GitLab Mattermost server to effectively disable the GitLab service bundled into the Omnibus package.
+consume system resources. You can use the following settings and configuration details on the GitLab Mattermost server to effectively disable the GitLab service bundled into the Linux package.
 
 ```ruby
 mattermost_external_url 'http://mattermost.example.com'
@@ -142,7 +142,7 @@ Save the changes and then run `sudo gitlab-ctl reconfigure`. If there are no err
 
 ## Specify numeric user and group identifiers
 
-Omnibus GitLab creates a user and group `mattermost`. You can specify the
+The Linux pacakage creates a user and group `mattermost`. You can specify the
 numeric identifiers for these users in `/etc/gitlab/gitlab.rb` as follows:
 
 ```ruby
@@ -167,7 +167,7 @@ Run `sudo gitlab-ctl reconfigure` to apply the changes.
 
 ## Connecting to the bundled PostgreSQL database
 
-If you need to connect to the bundled PostgreSQL database and are using the default Omnibus GitLab database configuration, you can connect as
+If you need to connect to the bundled PostgreSQL database and are using the default Linux package database configuration, you can connect as
 the PostgreSQL superuser:
 
 ```shell
@@ -176,14 +176,14 @@ sudo gitlab-psql -d mattermost_production
 
 ## Back up GitLab Mattermost
 
-GitLab Mattermost is not included in the regular [Omnibus GitLab backup](../../raketasks/backup_restore.md) Rake task.
+GitLab Mattermost is not included in the regular [Linux package backup](../../raketasks/backup_restore.md) Rake task.
 
 The general Mattermost [backup and disaster recovery](https://docs.mattermost.com/deploy/backup-disaster-recovery.html) documentation can be used as a guide
 on what needs to be backed up.
 
 ### Back up the bundled PostgreSQL database
 
-If you need to back up the bundled PostgreSQL database and are using the default Omnibus GitLab database configuration, you can back up using this command:
+If you need to back up the bundled PostgreSQL database and are using the default Linux package database configuration, you can back up using this command:
 
 ```shell
 sudo -i -u gitlab-psql -- /opt/gitlab/embedded/bin/pg_dump -h /var/opt/gitlab/postgresql mattermost_production | gzip > mattermost_dbdump_$(date --rfc-3339=date).sql.gz
@@ -286,8 +286,6 @@ Password:
 
 ## Configuring GitLab and Mattermost integrations
 
-As of 12.3, the Mattermost GitLab plugin is shipped with Omnibus GitLab: [Mattermost Plugin for GitLab documentation](https://github.com/mattermost/mattermost-plugin-gitlab).
-
 You can use the plugin to subscribe Mattermost to receive notifications about issues, merge requests, and pull requests as well as personal notifications regarding merge request reviews, unread messages, and task assignments. If you want to use slash commands to perform actions
 such as creating and viewing issues, or to trigger deployments use GitLab [Mattermost slash commands](../../user/project/integrations/mattermost_slash_commands.md).
 
@@ -359,22 +357,22 @@ When upgrading the Mattermost version, it is essential to check the
 [Important Upgrade Notes](https://docs.mattermost.com/administration/important-upgrade-notes.html)
 for Mattermost to address any changes or migrations that need to be performed.
 
-Starting with GitLab 11.0, GitLab Mattermost can be upgraded through the regular Omnibus GitLab update process. When upgrading previous versions of
+Starting with GitLab 11.0, GitLab Mattermost can be upgraded through the regular Linux package update process. When upgrading previous versions of
 GitLab, the update process can only be used if Mattermost configuration settings have not been changed outside of GitLab. That is, no changes to the Mattermost `config.json`
 file have been made - either directly or via the Mattermost **System Console**, which saves changes to `config.json`.
 
-If you are upgrading to at least GitLab 11.0 or have only configured Mattermost using `gitlab.rb`, you can upgrade GitLab using Omnibus and then run `gitlab-ctl reconfigure` to upgrade GitLab Mattermost to the latest version.
+If you are upgrading to at least GitLab 11.0 or have only configured Mattermost using `gitlab.rb`, you can upgrade GitLab using the Linux package and then run `gitlab-ctl reconfigure` to upgrade GitLab Mattermost to the latest version.
 
 If this is not the case, there are two options:
 
 1. Update [`gitlab.rb`](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template#L706)
    with the changes done to `config.json`. This might require adding some parameters as not all
-   settings in `config.json` are available in `gitlab.rb`. Once complete, Omnibus GitLab should be
+   settings in `config.json` are available in `gitlab.rb`. Once complete, the Linux package should be
    able to upgrade GitLab Mattermost from one version to the next.
-1. Migrate Mattermost outside of the directory controlled by Omnibus GitLab so it can be administered
+1. Migrate Mattermost outside of the directory controlled by the Linux package so it can be administered
    and upgraded independently. Follow the [Mattermost Migration Guide](https://docs.mattermost.com/administration/migrating.html)
    to move your Mattermost configuration settings and data to another directory or server independent
-   from Omnibus GitLab.
+   from the Linux package.
 
 For a complete list of upgrade notices and special considerations for older versions, see the [Mattermost documentation](https://docs.mattermost.com/administration/important-upgrade-notes.html).
 
@@ -387,7 +385,7 @@ GitLab 15.10 ships with Mattermost 7.8. Before upgrading, [connect to the bundle
 GitLab 14.6 ships with Mattermost 6.1 including potentially long running database migrations for Mattermost 6.0. For information about upgrading and for ways to reduce the downtime caused by those migrations, read the [Important Upgrade Notes](https://docs.mattermost.com/administration/important-upgrade-notes.html) for both versions. If you need to perform any manual migrations, [connect to the bundled PostgreSQL database](#connecting-to-the-bundled-postgresql-database).
 
 NOTE:
-The Mattermost upgrade notes refer to different impacts when used with a PostgreSQL versus a MySQL database. The GitLab Mattermost included with the GitLab Linux packages uses a PostgreSQL database.
+The Mattermost upgrade notes refer to different impacts when used with a PostgreSQL versus a MySQL database. The GitLab Mattermost included with the Linux package uses a PostgreSQL database.
 
 ## Upgrading GitLab Mattermost from versions prior to 11.0
 
@@ -492,7 +490,7 @@ If you encounter any issues [visit the GitLab Mattermost troubleshooting forum](
 
 ### Upgrading GitLab Mattermost outside of GitLab
 
-If you choose to upgrade Mattermost outside of the Omnibus GitLab automation, [follow this guide](https://docs.mattermost.com/administration/upgrade.html).
+If you choose to upgrade Mattermost outside of the Linux package automation, [follow this guide](https://docs.mattermost.com/administration/upgrade.html).
 
 ## OAuth 2.0 sequence diagram
 
diff --git a/doc/integration/oauth_provider.md b/doc/integration/oauth_provider.md
index 3e8c892cf38..6d08af225db 100644
--- a/doc/integration/oauth_provider.md
+++ b/doc/integration/oauth_provider.md
@@ -35,7 +35,7 @@ After adding an OAuth 2 application to an instance, you can use OAuth 2 to:
 
 To create a new application for your user:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Applications**.
 1. Enter a **Name** and **Redirect URI**.
@@ -74,7 +74,8 @@ To create a new application for a group:
 
 To create an application for your GitLab instance:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Applications**.
 1. Select **New application**.
 
@@ -85,7 +86,7 @@ The user authorization step is automatically skipped for this application.
 
 To see all the application you've authorized with your GitLab credentials:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile** and then select **Applications**.
 1. See the **Authorized applications** section.
 
diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md
index cd287d70ca3..2a871b97a28 100644
--- a/doc/integration/omniauth.md
+++ b/doc/integration/omniauth.md
@@ -35,6 +35,7 @@ GitLab supports the following OmniAuth providers.
 | [OpenID Connect](../administration/auth/oidc.md)                    | `openid_connect`           |
 | [Salesforce](salesforce.md)                                         | `salesforce`               |
 | [SAML](saml.md)                                                     | `saml`                     |
+| [Shibboleth](shibboleth.md)                                         | `shibboleth`               |
 | [Twitter](twitter.md)                                               | `twitter`                  |
 
 ## Configure common settings
@@ -234,7 +235,7 @@ created, you can activate an OmniAuth provider. For example, if you originally s
 provider like Twitter.
 
 1. Sign in to GitLab with your GitLab credentials, LDAP, or another OmniAuth provider.
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Account**.
 1. In the **Connected Accounts** section, select the OmniAuth provider, such as Twitter.
@@ -252,8 +253,9 @@ By default, sign-in is enabled for all the OAuth providers configured in `config
 
 To enable or disable an OmniAuth provider:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > General**.
 1. Expand **Sign-in restrictions**.
 1. In the **Enabled OAuth authentication sources** section, select or clear the checkbox for each provider you want to enable or disable.
 
diff --git a/doc/integration/recaptcha.md b/doc/integration/recaptcha.md
index 3cdbc5303f8..9e44efc3e60 100644
--- a/doc/integration/recaptcha.md
+++ b/doc/integration/recaptcha.md
@@ -17,8 +17,9 @@ To use reCAPTCHA, first create a site and private key.
 1. Go to the [Google reCAPTCHA page](https://www.google.com/recaptcha/admin).
 1. To get reCAPTCHA v2 keys, fill in the form and select **Submit**.
 1. Sign in to your GitLab server as an administrator.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Reporting** (`admin/application_settings/reporting`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > Reporting**.
 1. Expand **Spam and Anti-bot Protection**.
 1. In the reCAPTCHA fields, enter the keys you obtained in the previous steps.
 1. Select the **Enable reCAPTCHA** checkbox.
diff --git a/doc/integration/salesforce.md b/doc/integration/salesforce.md
index 8c43f038f86..40e1c4616a5 100644
--- a/doc/integration/salesforce.md
+++ b/doc/integration/salesforce.md
@@ -85,8 +85,8 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create
 1. Save the configuration file.
 
 1. For the changes to take effect:
-   - If you installed via Omnibus, [reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure).
-   - If you installed from source, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
+   - If you installed using the Linux package, [reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation).
+   - If you self-compiled your installation, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
 
 On the sign in page, there should now be a Salesforce icon below the regular sign in form.
 Select the icon to begin the authentication process. Salesforce asks the user to sign in and authorize the GitLab application.
diff --git a/doc/integration/shibboleth.md b/doc/integration/shibboleth.md
new file mode 100644
index 00000000000..db49b30fa21
--- /dev/null
+++ b/doc/integration/shibboleth.md
@@ -0,0 +1,91 @@
+---
+stage: Create
+group: Ecosystem
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Shibboleth OmniAuth Provider **(FREE)**
+
+NOTE:
+Use the [GitLab SAML integration](saml.md) to integrate specific Shibboleth identity providers (IdPs). For Shibboleth federation support (Discovery Service), use this document.
+
+To enable Shibboleth support in GitLab, use Apache instead of NGINX. Apache uses the `mod_shib2` module for Shibboleth authentication, and can pass attributes as headers to the OmniAuth Shibboleth provider.
+
+You can use the bundled NGINX provided in the Omnibus GitLab package to run a Shibboleth service provider on a different instance using a reverse proxy setup. However if you are not doing this, the bundled NGINX is difficult to configure.
+
+To enable the Shibboleth OmniAuth provider, you must:
+
+- [Install the Apache module](https://wiki.shibboleth.net/confluence/display/SP3/Apache).
+- [Configure the Apache module](https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache).
+
+To enable Shibboleth:
+
+1. Protect the OmniAuth Shibboleth callback URL:
+
+   ```apache
+   <Location /users/auth/shibboleth/callback>
+     AuthType shibboleth
+     ShibRequestSetting requireSession 1
+     ShibUseHeaders On
+     require valid-user
+   </Location>
+
+   Alias /shibboleth-sp /usr/share/shibboleth
+   <Location /shibboleth-sp>
+     Satisfy any
+   </Location>
+
+   <Location /Shibboleth.sso>
+     SetHandler shib
+   </Location>
+   ```
+
+1. Exclude Shibboleth URLs from rewriting. Add `RewriteCond %{REQUEST_URI} !/Shibboleth.sso` and `RewriteCond %{REQUEST_URI} !/shibboleth-sp`. An example configuration:
+
+   ```apache
+   # Apache equivalent of Nginx try files
+   RewriteEngine on
+   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
+   RewriteCond %{REQUEST_URI} !/Shibboleth.sso
+   RewriteCond %{REQUEST_URI} !/shibboleth-sp
+   RewriteRule .* http://127.0.0.1:8080%{REQUEST_URI} [P,QSA]
+   RequestHeader set X_FORWARDED_PROTO 'https'
+   ```
+
+1. Add Shibboleth to `/etc/gitlab/gitlab.rb` as an OmniAuth provider.
+   User attributes are sent from the Apache reverse proxy to GitLab as headers with the names from the Shibboleth attribute mapping.
+   Therefore the values of the `args` hash should be in the form of `"HTTP_ATTRIBUTE"`.
+   The keys in the hash are arguments to the [OmniAuth::Strategies::Shibboleth class](https://github.com/omniauth/omniauth-shibboleth-redux/blob/master/lib/omniauth/strategies/shibboleth.rb) and are documented by the [`omniauth-shibboleth-redux`](https://github.com/omniauth/omniauth-shibboleth-redux) gem (take care to note the version of the gem packaged with GitLab).
+
+   The file should look like this:
+
+   ```ruby
+   external_url 'https://gitlab.example.com'
+   gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
+
+   # disable Nginx
+   nginx['enable'] = false
+
+   gitlab_rails['omniauth_allow_single_sign_on'] = true
+   gitlab_rails['omniauth_block_auto_created_users'] = false
+   gitlab_rails['omniauth_providers'] = [
+     {
+       "name"  => "shibboleth",
+       "label" => "Text for Login Button",
+       "args"  => {
+           "shib_session_id_field"     => "HTTP_SHIB_SESSION_ID",
+           "shib_application_id_field" => "HTTP_SHIB_APPLICATION_ID",
+           "uid_field"                 => 'HTTP_EPPN',
+           "name_field"                => 'HTTP_CN',
+           "info_fields"               => { "email" => 'HTTP_MAIL'}
+       }
+     }
+   ]
+   ```
+
+   If some of your users appear to be authenticated by Shibboleth and Apache, but GitLab rejects their account with a URI that contains "e-mail is invalid" then your Shibboleth Identity Provider or Attribute Authority may be asserting multiple email addresses. In this instance, consider setting the `multi_values` argument to `first`.
+1. For the changes to take effect:
+   - For Linux package installations, [reconfigure](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation) GitLab.
+   - For self-compiled installations, [restart](../administration/restart_gitlab.md#installations-from-source) GitLab.
+
+On the sign in page, there should now be a **Sign in with: Shibboleth** icon below the regular sign-in form. Select the icon to begin the authentication process. You are redirected to the appropriate IdP server for your Shibboleth module configuration. If everything goes well, you are returned to GitLab and signed in.
diff --git a/doc/integration/sourcegraph.md b/doc/integration/sourcegraph.md
index d90a1fa2cca..366a862a9fb 100644
--- a/doc/integration/sourcegraph.md
+++ b/doc/integration/sourcegraph.md
@@ -49,7 +49,8 @@ You can skip this step if you already have your GitLab repositories searchable i
 
 ### Configure your GitLab instance with Sourcegraph
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Sourcegraph** configuration section.
 1. Check **Enable Sourcegraph**.
@@ -63,7 +64,7 @@ If a GitLab administrator has enabled Sourcegraph, you can enable this feature i
 
 In GitLab:
 
-1. In the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Preferences**.
 1. In the **Integrations** section, select the checkbox under **Sourcegraph**.
 1. Select **Save changes**.
diff --git a/doc/integration/twitter.md b/doc/integration/twitter.md
index 0ccda59f9b3..3edb0f25938 100644
--- a/doc/integration/twitter.md
+++ b/doc/integration/twitter.md
@@ -96,10 +96,9 @@ Twitter. Twitter generates a client ID and secret key for you to use.
 
 1. Save the configuration file.
 
-1. For the changes to take effect, if you installed:
-
-   - Using Omnibus, [reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure).
-   - From source, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
+1. For the changes to take effect:
+   - For Linux package installations, [reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation).
+   - For self-compiled installations, [restart GitLab](../administration/restart_gitlab.md#installations-from-source).
 
 On the sign-in page, find the Twitter option below the regular sign-in form. Select the option to begin the authentication process. Twitter asks you to sign in and authorize the GitLab application. After authorization,
 you are returned to GitLab and signed in.
diff --git a/doc/integration/vault.md b/doc/integration/vault.md
index c505097d65c..c93e3e53949 100644
--- a/doc/integration/vault.md
+++ b/doc/integration/vault.md
@@ -26,7 +26,7 @@ GitLab by using our OpenID authentication feature.
 First you must create a GitLab application to obtain an application ID and secret
 for authenticating into Vault. To do this, sign in to GitLab and follow these steps:
 
-1. In the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Applications**.
 1. Fill out the application **Name** and [**Redirect URI**](https://developer.hashicorp.com/vault/docs/auth/jwt#redirect-uris).
diff --git a/doc/operations/error_tracking.md b/doc/operations/error_tracking.md
index db68abf0778..a2d50e43a80 100644
--- a/doc/operations/error_tracking.md
+++ b/doc/operations/error_tracking.md
@@ -6,353 +6,205 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Error Tracking **(FREE)**
 
-Error Tracking allows developers to discover and view errors generated by their application. Because error information is surfaced where the code is being developed, efficiency and awareness are increased.
+Error Tracking allows developers to discover and view errors generated by their application. Because error information is surfaced where the code is developed, this increases efficiency and awareness. Users can choose between [GitLab Integrated error tracking](#integrated-error-tracking) and [Sentry based](#sentry-error-tracking) backends.
 
 ## How error tracking works
 
-For error tracking to work, you need two pieces:
+For error tracking to work, you need:
 
-- **Your application with Sentry SDK:** when the error happens, Sentry SDK captures information
+- **Your application configured with the Sentry SDK:** when the error happens, Sentry SDK captures information
   about it and sends it over the network to the backend. The backend stores information about all
   errors.
 
 - **Error tracking backend:** the backend can be either GitLab itself or Sentry. When it's GitLab,
-  we name it _integrated error tracking_ because you don't need to set up a separate backend. It's
+  you name it _integrated error tracking_ because you don't need to set up a separate backend. It's
   already part of the product.
 
   - To use the GitLab backend, see [integrated error tracking](#integrated-error-tracking).
   - To use Sentry as the backend, see [Sentry error tracking](#sentry-error-tracking).
 
-  No matter what backend you choose, the [error tracking UI](#error-tracking-list)
+  Whatever backend you choose, the [error tracking UI](#error-tracking-list)
   is the same.
 
-## Sentry error tracking
-
-[Sentry](https://sentry.io/) is an open source error tracking system. GitLab allows administrators to connect Sentry to GitLab so users can view a list of Sentry errors in GitLab.
-
-### Deploying Sentry
-
-You can sign up to the cloud-hosted [Sentry](https://sentry.io) or deploy your own [on-premise instance](https://github.com/getsentry/onpremise/).
-
-### Enabling Sentry
-
-GitLab provides a way to connect Sentry to your project. You need at
-least Maintainer [permissions](../user/permissions.md) to enable the Sentry integration.
-
-1. Sign up to Sentry.io or [deploy your own](#deploying-sentry) Sentry instance.
-1. [Create](https://docs.sentry.io/product/sentry-basics/guides/integrate-frontend/create-new-project/) a new Sentry project. For each GitLab project that you want to integrate, we recommend that you create a new Sentry project.
-1. Find or generate a [Sentry auth token](https://docs.sentry.io/api/auth/#auth-tokens).
-   For the SaaS version of Sentry, you can find or generate the auth token at [https://sentry.io/api/](https://sentry.io/api/).
-   Make sure to give the token at least the following scopes: `project:read`, `event:read`, and
-   `event:write` (for resolving events).
-1. In GitLab, enable error tracking:
-   1. On the top bar, select **Main menu > Projects** and find your project.
-   1. On the left sidebar, select **Monitor > Error Tracking**.
-   1. Select **Enable error tracking**.
-1. In GitLab, ensure error tracking is active.
-   1. On the left sidebar, select **Settings > Monitor**.
-   1. Expand **Error Tracking**.
-   1. Ensure the **Active** checkbox is selected.
-1. In the **Sentry API URL** box, enter your Sentry hostname. For example, enter `https://sentry.example.com`. For the SaaS version of Sentry, the hostname is `https://sentry.io`.
-1. In the **Auth Token** box, enter the token you previously generated.
-1. To test the connection to Sentry and populate the **Project** dropdown list, select **Connect**.
-1. From the **Project** list, choose a Sentry project to link to your GitLab project.
-1. Select **Save changes**.
-
-You can now visit **Monitor > Error Tracking** in your project's sidebar to [view a list](#error-tracking-list) of Sentry errors.
-
-### Enabling GitLab issues links
-
-You may also want to enable Sentry's GitLab integration by following the steps in the [Sentry documentation](https://docs.sentry.io/product/integrations/gitlab/)
-
-### Enable GitLab Runner
-
-To configure GitLab Runner with Sentry, you must add the value for `sentry_dsn` to your GitLab
-Runner's `config.toml` configuration file, as referenced in [GitLab Runner Advanced Configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
-While setting up Sentry, select **Go** if you're asked for the project type.
-
-If you see the following error in your GitLab Runner logs, then you should specify the deprecated
-DSN in **Sentry.io > Project Settings > Client Keys (DSN) > Show deprecated DSN**.
-
-```plaintext
-ERROR: Sentry failure builds=0 error=raven: dsn missing private key
-```
-
-## Error Tracking list
-
-Users with at least Reporter [permissions](../user/permissions.md)
-can find the Error Tracking list at **Monitor > Error Tracking** in your project's sidebar.
-Here, you can filter errors by title or by status (one of Ignored , Resolved, or Unresolved) and sort in descending order by Frequency, First Seen, or Last Seen. By default, the error list is ordered by Last Seen and filtered to Unresolved errors.
-
-![Error Tracking list](img/error_tracking_list_v12_6.png)
-
-## Error details
-
-From error list, users can go to the error details page by selecting the title of any error.
-
-This page includes:
-
-- A link to the Sentry issue.
-- A link to the GitLab commit if the Sentry [release ID/version](https://docs.sentry.io/product/releases/?platform=javascript#configure-sdk) on the Sentry Issue's first release matches a commit SHA in your GitLab hosted project.
-- Other details about the issue, including a full stack trace.
-- In [GitLab 12.7 and newer](https://gitlab.com/gitlab-org/gitlab/-/issues/36246), language and urgency are displayed.
-
-By default, a **Create issue** button is displayed:
-
-![Error Details without Issue Link](img/error_details_v12_7.png)
-
-If you create a GitLab issue from the error, the **Create issue** button changes to a **View issue**
-button and a link to the GitLab issue displays in the error detail section.
-
-## Taking action on errors
-
-You can take action on Sentry Errors in the GitLab UI. Marking errors as ignored or resolved requires at least Developer role.
-
-### Ignoring errors
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/39665) in GitLab 12.7.
-
-In the [Error Details](#error-details) page you can ignore a Sentry error by selecting **Ignore** near the top of the page.
-
-Ignoring an error prevents it from appearing in the [Error Tracking List](#error-tracking-list), and silences notifications that were set up in Sentry.
-
-### Resolving errors
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/39825) in GitLab 12.7.
-
-In the [Error Details](#error-details) page you can resolve a Sentry error by
-selecting **Resolve** near the top of the page.
-
-Marking an error as resolved indicates that the error has stopped firing events. If a GitLab issue is linked to the error, then the issue closes.
-
-If another event occurs, the error reverts to unresolved.
-
 ## Integrated error tracking **(FREE SAAS)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/329596) in GitLab 14.4.
-> - [Disabled](https://gitlab.com/gitlab-org/gitlab/-/issues/353639) in GitLab 14.9 [with a flag](../administration/feature_flags.md) named `integrated_error_tracking`. Disabled by default.
-> - [Enabled on GitLab.com](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/7586) in GitLab 15.6.
+This guide provides you with basics of setting up error tracking for your project, using examples from different languages.
 
-NOTE:
-Available only on GitLab.com. This feature is in [Open Beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#open-beta).
+Error tracking provided by GitLab Observability is based on [Sentry SDK](https://docs.sentry.io/). Check the [Sentry SDK documentation](https://docs.sentry.io/platforms/) for more thorough examples of how you can use Sentry SDK in your application.
 
-### Known limitations
+According to the Sentry [data model](https://develop.sentry.dev/sdk/envelopes/#data-model), the item types are:
 
-Only basic support is provided with `capture_exception` as the holding method.
-Additional features requests (see this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/340178)) are added on a case-by-case basis.
+- [Event](https://develop.sentry.dev/sdk/event-payloads/)
+- [Transactions](https://develop.sentry.dev/sdk/event-payloads/transaction/)
+- [Attachments](https://develop.sentry.dev/sdk/envelopes/#attachment)
+- [Session](https://develop.sentry.dev/sdk/envelopes/#session)
+- [Sessions](https://develop.sentry.dev/sdk/envelopes/#sessions)
+- [User feedback](https://develop.sentry.dev/sdk/envelopes/#user-feedback) (also known as user report)
+- [Client report](https://develop.sentry.dev/sdk/client-reports/)
 
-### Debugging issues
+### Enable error tracking for a project
 
-The majority of languages are supported by Sentry expose `debug` option as part of initialization.
-It is also possible to output JSON before it is sent to the API.
-See the [Go example](#go) below for a suggested solution.
+Regardless of the programming language you use, you first need to enable error tracking for your GitLab project.
 
-### Enabling error tracking
+The `GitLab.com` instance is used in this guide.
 
-Regardless of the programming language, you need to enable error tracking for your project. This doc assumes you already have a project for which you want to enable error tracking.
-This example uses the `gitlab.com` instance.
+Prerequisites:
 
-To enable error tracking, follow these steps:
+- You have a project for which you want to enable error tracking. To learn how to create a new one, see [Create a project](../user/project/index.md).
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Monitor**.
-1. Expand the **Error Tracking** tab.
+To enable error tracking with GitLab as the backend:
+
+1. In your project, go to **Settings > Monitor**.
+1. Expand **Error Tracking**.
 1. Under **Enable error tracking**, select the **Active** checkbox.
 1. Under **Error tracking backend**, select **GitLab**.
 1. Select **Save changes**.
-1. Copy the DSN string to use later.
 
-### Listing captured errors
+1. Copy the Data Source Name (DSN) string. You need it for configuring your SDK implementation.
 
-Once your application has emitted errors to the Error Tracking API through the Sentry SDK, they should be available under **Monitor > Error Tracking** tab/section.
+## Error tracking list
 
-For more details, refer to the [GitLab error tracking documentation](https://gitlab.com/help/operations/error_tracking#error-tracking-list).
+After your application has emitted errors to the Error Tracking API through the Sentry SDK,
+they should be available under the **Monitor > Error Tracking** tab/section.
 
-This process assumes the GDK feature flag `integrated_error_tracking` is enabled. If you are running GDK locally and you do not see the option for error tracking, you can enable it by running the following commands:
+![MonitorListErrors](img/list_errors_v16_0.png)
 
-```linux
-cd <PATH_TO_GDK>
-gdk rails console
-Feature.enable(:integrated_error_tracking)
-```
+## Error tracking details
 
-### Emitting errors
+In the Error Details view you can see more details of the exception, including number of occurrences,
+users affected, first seen, and last seen dates.
 
-#### Supported Sentry types
+You can also review the stack trace.
 
-According to the [data model](https://develop.sentry.dev/sdk/envelopes/#data-model), the available item types are:
+![MonitorDetailErrors](img/detail_errors_v16_0.png)
 
-- [Event](https://develop.sentry.dev/sdk/event-payloads/)
-- [Transactions](https://develop.sentry.dev/sdk/event-payloads/transaction/)
-- Attachment
-- [Session](https://develop.sentry.dev/sdk/sessions/)
-- [Sessions](https://develop.sentry.dev/sdk/sessions/)
-- [User feedback](https://develop.sentry.dev/sdk/envelopes/#user-feedback) (also known as user report)
-- [Client report](https://develop.sentry.dev/sdk/client-reports/)
-
-Items of various types can be sent to the error tracking app, using either the Store endpoint, the envelope endpoint, or both. The following table lists all event types available through Sentry SDK. It also explains which endpoint can be used for ingestion and whether it is supported by GitLab Observability Backend.
+## Emit errors
 
-Event item types can contain various interfaces, such as exception, message, stack trace, and template. You can read more about the core data interfaces in [Sentry documentation](https://develop.sentry.dev/sdk/event-payloads/#core-interfaces).
+### Supported language SDKs & Sentry types
 
-| Item type       | Interface   | Can be sent through the Store endpoint | Can be sent through the Envelope endpoint | Supported              |
-| --------------- | ----------- | -------------------------------------- | ----------------------------------------- | ---------------------- |
-| `event`         | exception   | **{check-circle}** Yes                 | **{check-circle}** Yes                    | **{check-circle}** Yes |
-| `event`         | message     | **{check-circle}** Yes                 | **{check-circle}** Yes                    | **{check-circle}** Yes |
-| `event`         | stack trace | **{check-circle}** Yes                 | **{check-circle}** Yes                    | **{check-circle}** Yes |
-| `event`         | template    | **{check-circle}** Yes                 | **{check-circle}** Yes                    | **{dotted-circle}** No |
-| `transaction`   | N/A         | **{dotted-circle}** No                 | **{check-circle}** Yes                    | **{dotted-circle}** No |
-| `attachment`    | N/A         | **{dotted-circle}** No                 | **{check-circle}** Yes                    | **{dotted-circle}** No |
-| `session`       | N/A         | **{dotted-circle}** No                 | **{check-circle}** Yes                    | **{dotted-circle}** No |
-| `sessions`      | N/A         | **{dotted-circle}** No                 | **{check-circle}** Yes                    | **{dotted-circle}** No |
-| `user_report`   | N/A         | **{dotted-circle}** No                 | **{check-circle}** Yes                    | **{dotted-circle}** No |
-| `client_report` | N/A         | **{dotted-circle}** No                 | **{check-circle}** Yes                    | **{dotted-circle}** No |
+In the following table, you can see a list of all event types available through Sentry SDK, and whether they are supported by GitLab Error Tracking.
 
-#### Supported languages
+| Language | Tested SDK client and version   | Endpoint   | Supported item types              |
+| -------- | ------------------------------- | ---------- | --------------------------------- |
+| Go       | `sentry-go/0.20.0`              | `store`    | `exception`, `message`            |
+| Java     | `sentry.java:6.18.1`            | `envelope` | `exception`, `message`            |
+| NodeJS   | `sentry.javascript.node:7.38.0` | `envelope` | `exception`, `message`            |
+| PHP      | `sentry.php/3.18.0`             | `store`    | `exception`, `message`            |
+| Python   | `sentry.python/1.21.0`          | `envelope` | `exception`, `message`, `session` |
+| Ruby     | `sentry.ruby:5.9.0`             | `envelope` | `exception`, `message`            |
+| Rust     | `sentry.rust/0.31.0`            | `envelope` | `exception`, `message`, `session` |
 
-Each language shows a basic example of how to capture exceptions with the respective SDK.
-For more in-depth documentation, see [documentation for Sentry SDK](https://docs.sentry.io/). You can also find information for additional programming languages.
+For a detailed version of this table, see [this issue](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/1737).
 
-Only a subset of languages is supported.
+## Usage examples
 
-The following table lists them:
+You can also find working samples for all [supported language SDKs](https://gitlab.com/gitlab-org/opstrace/opstrace/-/tree/main/test/sentry-sdk/testdata/supported-sdk-clients).
+Each listed program shows a basic example of how to capture exceptions, events,
+or messages with the respective SDK.
 
-| Sentry SDK  | Supported?  |
-| ----------- | ----------- |
-| Ruby        | Yes |
-| Go          | Yes |
-| JavaScript  | Yes |
-| Java        | Yes |
-| Python      | Yes |
-| PHP         | Yes |
-| .NET        | Not tested |
-| Android     | Not tested |
-| Apple       | Not tested |
-| Perl        | Not tested |
+For more in-depth documentation,
+see [Sentry SDK's documentation](https://docs.sentry.io/) specific to the used language.
 
-A more up-to-date version of [this matrix can be found in this doc](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/1737).
+## Rotate generated DSN
 
-#### Go
-
-1. `chdir` into folder `docs/guides/user/error_tracking_examples/go/`
-1. Install the dependencies with the following command:
-
-   ```shell
-   go mod tidy
-   ```
+The Sentry Data Source Name, or DSN, (client key) is a secret and it should not be exposed to the public.
+In case of a leak, rotate the Sentry DSN by following these steps:
 
-1. Run the following command:
+1. [Create an access token](../user/profile/personal_access_tokens.md#create-a-personal-access-token)
+   by selecting your profile picture in GitLab.com.
+   Then select Preferences, and then Access Token. Make sure you add API scope.
+1. Using the [error tracking API](../api/error_tracking.md),
+   create a new Sentry DSN:
 
    ```shell
-   export SENTRY_DSN="<DSN string>"
-   go run main.go <DSN string>
+   curl --request POST --header "PRIVATE-TOKEN: <your_access_token>"
+   --header "Content-Type: application/json" \
+      "https://gitlab.example.com/api/v4/projects/<your_project_number>/error_tracking/client_keys"
    ```
 
-After you've run this program, there should be an error visible in the Error tracking tab from `Listing captured errors` section of this document.
-
-#### Ruby
-
-1. `chdir` into folder `docs/guides/user/error_tracking_examples/ruby/`
-1. Install the dependencies with the following command:
+1. Get the available client keys (Sentry DSNs).
+   Ensure that the newly created Sentry DSN is in place.
+   Then note down the key ID of the old client key:
 
    ```shell
-   gem install bundler
-   bundle install
+   curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/<your_project_number>/error_tracking/client_keys"
    ```
 
-1. Execute the example with the following command:
+1. Delete the old client key.
 
    ```shell
-   export SENTRY_DSN="<DSN string>"
-   ruby app.rb
+   curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/<your_project_number>/error_tracking/client_keys/<key_id>"
    ```
 
-After you've run this program, there should be an error visible in the Error tracking tab from `Listing captured errors` section of this document.
+## Debug SDK issues
 
-#### PHP
+The majority of languages supported by Sentry expose `debug` option as part of initialization.
+This can be helpful when debugging issues with sending errors. Otherwise,
+there are options that could allow outputting JSON before it is sent to the API.
 
-1. `chdir` into folder `docs/guides/user/error_tracking_examples/php/`
+## Sentry error tracking
 
-1. Build and run the Docker container with the following commands:
+[Sentry](https://sentry.io/) is an open source error tracking system. GitLab allows
+administrators to connect Sentry to GitLab
+so users can view a list of Sentry errors in GitLab.
 
-```shell
-export SENTRY_DSN="<DSN string>"
-docker build -t sentry-php .
-docker run -e SENTRY_DSN --rm sentry-php
-```
+### Deploying Sentry
 
-After you've run this program, there should be an error visible in the Error tracking tab from `Listing captured errors` section of this document.
+You can sign up to the cloud-hosted [Sentry](https://sentry.io) or deploy your own
+[on-premise instance](https://github.com/getsentry/onpremise/).
 
-#### Python
+### Enable Sentry integration for a project
 
-1. `chdir` into folder `docs/guides/user/error_tracking_examples/python/`
+GitLab provides a way to connect Sentry to your project.
 
-1. Install the dependencies with the following commands:
+Prerequisites:
 
-   ```shell
-   virtualenv env
-   source env/bin/activate
-   pip install -r requirements.txt
-   ```
+- You must have at least the Developer role for the project.
 
-1. Run the following commands:
+To enable the Sentry integration:
 
-```shell
-export SENTRY_DSN="<DSN string>"
-python send_exception.py
-```
+1. Sign up to Sentry.io or [deploy your own](#deploying-sentry) Sentry instance.
+1. [Create a new Sentry project](https://docs.sentry.io/product/sentry-basics/guides/integrate-frontend/create-new-project/).
+   For each GitLab project that you want to integrate, you should create a new Sentry project.
+1. Find or generate a [Sentry auth token](https://docs.sentry.io/api/auth/#auth-tokens).
+   For the SaaS version of Sentry, you can find or generate the auth token at [https://sentry.io/api/](https://sentry.io/api/).
+   You should give the token at least the following scopes: `project:read`,
+   `event:read`, and
+   `event:write` (for resolving events).
+1. In GitLab, enable and configure Error Tracking:
+   1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+   1. Select **Monitor > Error Tracking**.
+   1. Under **Enable error tracking**, select the **Active** checkbox.
+   1. Under **Error tracking backend**, select **Sentry**.
+   1. Under **Sentry API URL**, enter your Sentry hostname. For example,
+      enter `https://sentry.example.com`.
+      For the SaaS version of Sentry, the hostname is `https://sentry.io`.
+   1. Under **Auth Token**, enter the token you previously generated.
+   1. To test the connection to Sentry and populate the **Project** dropdown list,
+   select **Connect**.
+   1. From the **Project** list, choose a Sentry project to link to your GitLab project.
+   1. Select **Save changes**.
+
+You can now visit **Monitor > Error Tracking** in your project's sidebar to
+[view a list](#error-tracking-list) of Sentry errors.
+
+### Sentry's GitLab integration
+
+You might also want to enable Sentry's GitLab integration by following the steps
+in the [Sentry documentation](https://docs.sentry.io/product/integrations/gitlab/).
 
-After you've run this program, there should be an error visible in the Error tracking tab from `Listing captured errors` section of this document.
+### Enable GitLab Runner
 
-#### Java
+To configure GitLab Runner with Sentry, you must add the value for `sentry_dsn`
+to your runner's `config.toml` configuration file, as referenced in
+[Advanced configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
 
-1. `chdir` into folder `docs/guides/user/error_tracking_examples/python/`
+If you're asked for the project type while setting up Sentry, select **Go**.
 
-1. Run the following command:
+If you see the following error in your GitLab Runner logs, then you should
+specify the deprecated
+DSN in **Sentry.io > Project Settings > Client Keys (DSN) > Show deprecated DSN**.
 
-```shell
-export SENTRY_DSN="<DSN string>"
-./gradlew run
+```plaintext
+ERROR: Sentry failure builds=0 error=raven: dsn missing private key
 ```
-
-#### Node.js
-
-1. `chdir` into folder `docs/guides/user/error_tracking_examples/nodejs/`
-
-1. Install the dependencies with the following command:
-
-   ```shell
-   npm install --save @sentry/node @sentry/tracing
-   ```
-
-1. Run the following command:
-
-   ```shell
-   export SENTRY_DSN="<DSN string>"
-   node ./test.js
-   ```
-
-After you've run this program, there should be an error visible in the Error tracking tab from `Listing captured errors` section of this document.
-
-### Rotating Sentry DSN
-
-The Sentry DSN (client key) is a secret and it should not be exposed to the public. If it's leaked, you can rotate the Sentry DSN with the following steps:
-
-1. [Create an access token](../user/profile/personal_access_tokens.md#create-a-personal-access-token) by clicking your profile picture in GitLab.com. Then choose Preferences,then Access Token. Make sure you add the API scope.
-1. Using the [error tracking API](../api/error_tracking.md), create a new Sentry DSN with the following command:
-
-   ```shell
-   curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --header "Content-Type: application/json" \
-     "https://gitlab.example.com/api/v4/projects/<your_project_number>/error_tracking/client_keys"
-   ```
-
-1. Get the available client keys (Sentry DSNs). Ensure that the newly created Sentry DSN is in place. Then note down the key ID of the old client key:
-
-   ```shell
-   curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/<your_project_number>/error_tracking/client_keys"
-   ```
-
-1. Delete the old client key with the following command:
-
-   ```shell
-   curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/<your_project_number>/error_tracking/client_keys/<key_id>"
-   ```
diff --git a/doc/operations/feature_flags.md b/doc/operations/feature_flags.md
index a3874b54ccd..edb7176c045 100644
--- a/doc/operations/feature_flags.md
+++ b/doc/operations/feature_flags.md
@@ -37,8 +37,8 @@ with GitLab, so it's up to developers to use a compatible client library and
 
 To create and enable a feature flag:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Feature flags**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Deploy > Feature flags**.
 1. Select **New feature flag**.
 1. Enter a name that starts with a letter and contains only lowercase letters, digits, underscores (`_`),
    or dashes (`-`), and does not end with a dash (`-`) or underscore (`_`).
@@ -180,8 +180,8 @@ For example:
 
 To create a user list:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Feature flags**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Deploy > Feature flags**.
 1. Select **View user lists**
 1. Select **New user list**.
 1. Enter a name for the list.
@@ -196,8 +196,8 @@ When viewing a list, you can rename it by selecting **Edit** (**{pencil}**).
 
 To add users to a user list:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Feature flags**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Deploy > Feature flags**.
 1. Select **Edit** (**{pencil}**) next to the list you want to add users to.
 1. Select **Add Users**.
 1. Enter the user IDs as a comma-separated list of values. For example,
@@ -210,8 +210,8 @@ To add users to a user list:
 
 To remove users from a user list:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Feature flags**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Deploy > Feature flags**.
 1. Select **Edit** (**{pencil}**) next to the list you want to change.
 1. Select **Remove** (**{remove}**) next to the ID you want to remove.
 
@@ -224,8 +224,8 @@ code so that you can clean it up when it's time to remove the feature flag.
 
 To search for code references of a feature flag:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Feature flags**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Deploy > Feature flags**.
 1. Edit the feature flag you want to remove.
 1. Select **More actions** (**{ellipsis_v}**).
 1. Select **Search code references**.
@@ -235,8 +235,8 @@ To search for code references of a feature flag:
 In [GitLab 13.0 and earlier](https://gitlab.com/gitlab-org/gitlab/-/issues/8621),
 to disable a feature flag for a specific environment:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Feature flags**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Deploy > Feature flags**.
 1. For the feature flag you want to disable, select **Edit** (**{pencil}**).
 1. To disable the flag:
 
@@ -250,8 +250,8 @@ to disable a feature flag for a specific environment:
 
 To disable a feature flag for all environments:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Feature flags**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Deploy > Feature flags**.
 1. For the feature flag you want to disable, slide the Status toggle to **Disabled**.
 
 The feature flag is displayed on the **Disabled** tab.
@@ -265,8 +265,8 @@ Then prepare your application with a client library.
 
 To get the access credentials that your application needs to communicate with GitLab:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Feature flags**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Deploy > Feature flags**.
 1. Select **Configure** to view the following:
    - **API URL**: URL where the client (application) connects to get a list of feature flags.
    - **Instance ID**: Unique token that authorizes the retrieval of the feature flags.
diff --git a/doc/operations/img/detail_errors_v16_0.png b/doc/operations/img/detail_errors_v16_0.png
new file mode 100644
index 00000000000..3b63c565e56
--- /dev/null
+++ b/doc/operations/img/detail_errors_v16_0.png
diff --git a/doc/operations/img/error_details_v12_7.png b/doc/operations/img/error_details_v12_7.png
deleted file mode 100644
index 05070ce06b9..00000000000
--- a/doc/operations/img/error_details_v12_7.png
+++ /dev/null
diff --git a/doc/operations/img/error_tracking_list_v12_6.png b/doc/operations/img/error_tracking_list_v12_6.png
deleted file mode 100644
index af57691b14a..00000000000
--- a/doc/operations/img/error_tracking_list_v12_6.png
+++ /dev/null
diff --git a/doc/operations/img/list_errors_v16_0.png b/doc/operations/img/list_errors_v16_0.png
new file mode 100644
index 00000000000..0ddf7f93616
--- /dev/null
+++ b/doc/operations/img/list_errors_v16_0.png
diff --git a/doc/operations/incident_management/alerts.md b/doc/operations/incident_management/alerts.md
index 74e0ed5f06a..e701fb2e5fb 100644
--- a/doc/operations/incident_management/alerts.md
+++ b/doc/operations/incident_management/alerts.md
@@ -179,8 +179,8 @@ To assign an alert:
 
 1. Display the list of current alerts:
 
-   1. On the top bar, select **Main menu > Projects** and find your project.
-   1. On the left sidebar, select **Monitor > Alerts**.
+   1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+   1. Select **Monitor > Alerts**.
 
 1. Select your desired alert to display its details.
 
@@ -219,8 +219,8 @@ Prerequisites:
 
 To configure the actions:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Monitor**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Monitor**.
 1. Expand the **Alerts** section, then select the **Alert settings** tab.
 1. Select the **Create an incident** checkbox.
 1. Optional. To customize the incident, from the **Incident template**, select a template to be
diff --git a/doc/operations/incident_management/escalation_policies.md b/doc/operations/incident_management/escalation_policies.md
index 87455906b26..4360fe6243d 100644
--- a/doc/operations/incident_management/escalation_policies.md
+++ b/doc/operations/incident_management/escalation_policies.md
@@ -22,8 +22,8 @@ Prerequisite:
 
 To create an escalation policy:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Escalation Policies**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Escalation Policies**.
 1. Select **Add an escalation policy**.
 1. Enter the policy's name and description, and
    escalation rules to follow when a primary responder misses an alert.
@@ -46,8 +46,8 @@ the paged users is created on the alert.
 
 To update an escalation policy:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Escalation Policies**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Escalation Policies**.
 1. Select **Edit escalation policy** (**{pencil}**).
 1. Edit the information.
 1. Select **Save changes**.
@@ -56,7 +56,7 @@ To update an escalation policy:
 
 To delete an escalation policy:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Escalation Policies**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Escalation Policies**.
 1. Select **Delete escalation policy** (**{remove}**).
 1. On the confirmation dialog, select **Delete escalation policy**.
diff --git a/doc/operations/incident_management/incident_timeline_events.md b/doc/operations/incident_management/incident_timeline_events.md
index d509061eca0..6a52accbfb2 100644
--- a/doc/operations/incident_management/incident_timeline_events.md
+++ b/doc/operations/incident_management/incident_timeline_events.md
@@ -23,8 +23,8 @@ They are grouped with dates and are listed in ascending order of the time when t
 
 To view the event timeline of an incident:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Incidents**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Incidents**.
 1. Select an incident.
 1. Select the **Timeline** tab.
 
@@ -42,8 +42,8 @@ Prerequisites:
 
 To create a timeline event:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Incidents**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Incidents**.
 1. Select an incident.
 1. Select the **Timeline** tab.
 1. Select **Add new timeline event**.
@@ -66,8 +66,8 @@ Prerequisites:
 
 To create a timeline event from a comment on the incident:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Incidents**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Incidents**.
 1. Select an incident.
 1. Create a comment or choose an existing comment.
 1. On the comment you want to add, select **Add comment to incident timeline** (**{clock}**).
@@ -106,8 +106,8 @@ Prerequisites:
 
 To delete a timeline event:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Incidents**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Incidents**.
 1. Select an incident.
 1. Select the **Timeline** tab.
 1. On the right of a timeline event, select **More actions** (**{ellipsis_v}**) and then select **Delete**.
diff --git a/doc/operations/incident_management/incidents.md b/doc/operations/incident_management/incidents.md
index 5f1a2880c4b..4e2be27e424 100644
--- a/doc/operations/incident_management/incidents.md
+++ b/doc/operations/incident_management/incidents.md
@@ -154,8 +154,8 @@ Prerequisites:
 
 To configure the timer:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Monitor**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Monitor**.
 1. Expand the **Incidents** section, then select the **Incident settings** tab.
 1. Select **Activate "time to SLA" countdown timer**.
 1. Set a time limit in increments of 15 minutes.
diff --git a/doc/operations/incident_management/integrations.md b/doc/operations/incident_management/integrations.md
index 41fbe8fe83c..5fe7db71fd8 100644
--- a/doc/operations/incident_management/integrations.md
+++ b/doc/operations/incident_management/integrations.md
@@ -144,8 +144,8 @@ Prerequisites:
 
 - You must have at least the Maintainer role for the project.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Monitor**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Monitor**.
 1. Expand the **Alerts** section, and select **Add new integration**.
 1. From the **Select integration type** dropdown list, select **Prometheus**.
 1. Turn on the **Active** toggle.
diff --git a/doc/operations/incident_management/linked_resources.md b/doc/operations/incident_management/linked_resources.md
index 642a6972bcf..e43b08dfd78 100644
--- a/doc/operations/incident_management/linked_resources.md
+++ b/doc/operations/incident_management/linked_resources.md
@@ -27,8 +27,8 @@ Linked resources for an incident are listed under the **Summary** tab.
 
 To view the linked resources of an incident:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Incidents**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Incidents**.
 1. Select an incident.
 
 ## Add a linked resource
@@ -41,8 +41,8 @@ Prerequisites:
 
 To add a linked resource:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Incidents**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Incidents**.
 1. Select an incident.
 1. In the **Linked resources** section, select the plus icon (**{plus-square}**).
 1. Complete the required fields.
@@ -92,7 +92,7 @@ Prerequisites:
 
 To remove a linked resource:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Incidents**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Incidents**.
 1. Select an incident.
 1. In the **Linked resources** section, select **Remove** (**{close}**).
diff --git a/doc/operations/incident_management/manage_incidents.md b/doc/operations/incident_management/manage_incidents.md
index 187a398b1ee..3d2688daf6a 100644
--- a/doc/operations/incident_management/manage_incidents.md
+++ b/doc/operations/incident_management/manage_incidents.md
@@ -24,8 +24,8 @@ Prerequisites:
 
 To create an incident from the incidents list:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Incidents**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Incidents**.
 1. Select **Create incident**.
 
 ### From the issues list
@@ -38,8 +38,8 @@ Prerequisites:
 
 To create an incident from the issues list:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues > List**, and select **New issue**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, and select **New issue**.
 1. From the **Type** dropdown list, select **Incident**. Only fields relevant to
    incidents are available on the page.
 1. Select **Create issue**.
@@ -57,8 +57,8 @@ Prerequisites:
 
 To create an incident from an alert:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Alerts**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Alerts**.
 1. Select your desired alert.
 1. Select **Create incident**.
 
@@ -88,8 +88,8 @@ Prerequisites:
 
 To set up a webhook with PagerDuty:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Monitor**
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Monitor**
 1. Expand **Incidents**.
 1. Select the **PagerDuty integration** tab.
 1. Turn on the **Active** toggle.
@@ -104,8 +104,8 @@ check if a GitLab incident is created from the incident.
 
 To view the [incidents list](incidents.md#incidents-list):
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > Incidents**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Incidents**.
 
 To view an incident's [details page](incidents.md#incident-details), select it from the list.
 
@@ -239,8 +239,8 @@ Prerequisites:
 
 To configure the setting:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Monitor**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Monitor**.
 1. Expand the **Incidents** section.
 1. Select the **Automatically close associated incident** checkbox.
 1. Select **Save changes**.
diff --git a/doc/operations/incident_management/oncall_schedules.md b/doc/operations/incident_management/oncall_schedules.md
index 9dfac56f0ba..8e3318766b4 100644
--- a/doc/operations/incident_management/oncall_schedules.md
+++ b/doc/operations/incident_management/oncall_schedules.md
@@ -28,8 +28,8 @@ Prerequisite:
 
 To create an on-call schedule:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > On-call Schedules**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > On-call Schedules**.
 1. Select **Add a schedule**.
 1. Enter the schedule's name and description and select a time zone.
 1. Select **Add schedule**.
@@ -43,8 +43,8 @@ create [rotations](#rotations) for your schedule.
 
 To update a schedule:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > On-call Schedules**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > On-call Schedules**.
 1. Select **Edit schedule** (**{pencil}**).
 1. Edit the information.
 1. Select **Save changes**.
@@ -56,8 +56,8 @@ interval (if one is set) to the corresponding times in the new time zone.
 
 To delete a schedule:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > On-call Schedules**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > On-call Schedules**.
 1. Select **Delete escalation policy** (**{remove}**).
 1. On the confirmation dialog, select **Delete schedule**.
 
@@ -67,8 +67,8 @@ Add rotations to an existing schedule to put your team members on-call.
 
 To create a rotation:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > On-call Schedules**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > On-call Schedules**.
 1. Select the **Add a rotation** link.
 1. Enter the following information:
 
@@ -85,8 +85,8 @@ To create a rotation:
 
 To edit a rotation:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > On-call Schedules**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > On-call Schedules**.
 1. In the **Rotations** section, select **Edit rotation** (**{pencil}**).
 1. Edit the information.
 1. Select **Save changes**.
@@ -95,8 +95,8 @@ To edit a rotation:
 
 To delete a rotation:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Monitor > On-call Schedules**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > On-call Schedules**.
 1. In the **Rotations** section, select **Delete rotation** (**{remove}**).
 1. On the confirmation dialog, select **Delete rotation**.
 
diff --git a/doc/operations/incident_management/paging.md b/doc/operations/incident_management/paging.md
index 70c67977b73..be28e94c148 100644
--- a/doc/operations/incident_management/paging.md
+++ b/doc/operations/incident_management/paging.md
@@ -26,8 +26,8 @@ Email notifications are available in projects for triggered alerts. Project
 members with the **Owner** or **Maintainer** roles have the option to receive
 a single email notification for new alerts.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Monitor**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Monitor**.
 1. Expand **Alerts**.
 1. On the **Alert settings** tab, select the
    **Send a single email notification to Owners and Maintainers for new alerts** checkbox.
diff --git a/doc/operations/incident_management/slack.md b/doc/operations/incident_management/slack.md
index 1f6097ccbdb..b007f253fd8 100644
--- a/doc/operations/incident_management/slack.md
+++ b/doc/operations/incident_management/slack.md
@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Incident management for Slack (Beta) **(FREE SAAS)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/344856) in GitLab 15.7 [with a flag](../../administration/feature_flags.md) named `incident_declare_slash_command`. Disabled by default.
-> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/378072) in GitLab 15.10 in [Beta](../../policy/alpha-beta-support.md#beta).
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/378072) in GitLab 15.10 in [Beta](../../policy/experiment-beta-support.md#beta).
 
 FLAG:
 On self-managed GitLab, this feature is not available.
@@ -19,8 +19,6 @@ Use the GitLab for Slack app to:
 
 - Create GitLab incidents from Slack.
 - Receive incident notifications.
-<!-- The below content is commented out until these features are implemented in https://gitlab.com/groups/gitlab-org/-/epics/8545 -->
-<!-- - Send important updates between Slack and GitLab incidents. -->
 
 Incident management for Slack is only available for GitLab.com. Some of the functionality
 described might be available for
@@ -44,18 +42,6 @@ Prerequisites:
    The `<project-alias>` you select must be a project that has the GitLab for Slack app set up.
    For more information, see [issue 377548](https://gitlab.com/gitlab-org/gitlab/-/issues/377548).
 
-<!-- The below content is commented out until these features are implemented in https://gitlab.com/groups/gitlab-org/-/epics/8545 -->
-<!--
-To manage incidents, use the following slash commands in Slack:
-
-| Command                            | Description                                 |
-| ---------------------------------- | ------------------------------------------- |
-| `/gitlab incident declare`         | Creates an incident in GitLab.              |
-| `/gitlab incident comment <text>`  | Adds a comment on a GitLab incident.        |
-| `/gitlab incident timeline <text>` | Adds a timeline event to a GitLab incident. |
-| `/gitlab incident close`           | Closes an incident in GitLab.               |
--->
-
 After the GitLab for Slack app is configured, you can also use any of the existing [Slack slash commands](../../user/project/integrations/slack_slash_commands.md).
 
 ## Declare an incident
@@ -94,24 +80,6 @@ a GitLab incident from Slack. The following quick actions might be most relevant
 | `/link <URL> <text>`     | Adds a link to a dedicated Slack channel, runbook, or any relevant resource to the `Related resources` section of an incident. |
 | `/zoom <URL>`            | Adds a Zoom meeting link to the incident. |
 
-<!-- The below content is commented out until these features are implemented in https://gitlab.com/groups/gitlab-org/-/epics/8545 -->
-<!-- ### Comment on a GitLab incident
-
-To comment on a GitLab incident from Slack, enter the `/gitlab incident comment <text>` slash command.
-Slack shows a prompt asking you to confirm which incident you'd like to post your comment to.
-
-### Add a timeline event
-
-To add a [timeline event](incident_timeline_events.md) to a GitLab incident from Slack, enter the
-`/gitlab incident timeline <text>` slash command.
-Slack shows a prompt asking you to confirm which incident you'd like to add your timeline event to.
-
-### Close an incident
-
-To close a GitLab incident from Slack when it is resolved, enter the `/gitlab incident close`
-slash command.
-Slack shows a prompt asking you to confirm which incident you'd like to close.  -->
-
 ## Send GitLab incident notifications to Slack
 
 If you have [enabled notifications](#manage-an-incident-from-slack) for incidents, you should receive
diff --git a/doc/operations/incident_management/status_page.md b/doc/operations/incident_management/status_page.md
index fd37279806f..a159757842d 100644
--- a/doc/operations/incident_management/status_page.md
+++ b/doc/operations/incident_management/status_page.md
@@ -45,9 +45,9 @@ Prerequisite:
 
 To provide GitLab with the AWS account information needed to push content to your Status Page:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Monitor**.
-1. Expand **Status Page**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Monitor**.
+1. Expand **Status page**.
 1. Select the **Active** checkbox.
 1. In the **Status Page URL** box, provide the URL for your external status page.
 1. In the **S3 Bucket name** box, type the name of your S3 bucket. For more information, see
@@ -96,8 +96,8 @@ the issue can potentially [publish comments to your GitLab Status Page](#publish
 After creating the CI/CD variables, configure the Project you want to use for
 Incident issues:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Monitor**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Monitor**.
 1. Expand **Status page**.
 1. Fill in your cloud provider's credentials and make sure to select the **Active** checkbox.
 1. Select **Save changes**.
diff --git a/doc/policy/alpha-beta-support.md b/doc/policy/alpha-beta-support.md
index e142fe9e908..bfea5b3a2d6 100644
--- a/doc/policy/alpha-beta-support.md
+++ b/doc/policy/alpha-beta-support.md
@@ -1,65 +1,11 @@
 ---
-stage: Systems
-group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: 'experiment-beta-support.md'
+remove_date: '2023-09-07'
 ---
 
-# Support for Experiment, Beta, and Generally Available features **(PREMIUM)**
+This document was moved to [another location](experiment-beta-support.md).
 
-Some GitLab features are released as Experiment or Beta versions and are
-[not fully supported](https://about.gitlab.com/support/statement-of-support/#alpha-beta-features).
-All other features are considered to be Generally Available (GA).
-
-## Experiment
-
-Support is not provided for features listed as "Experimental" or "Alpha" or any similar designation. Issues regarding such features should be opened in the GitLab issue tracker.
-
-- Not ready for production use.
-- No support available.
-- May be unstable or have performance issues.
-- Can be removed at any time.
-- Data loss may occur.
-- Documentation may not exist or just be in a blog format.
-- Behind a feature flag that is on by default and the [UI reflects Experiment status](https://design.gitlab.com/usability/feature-management#highlighting-feature-versions).
-- Behind a toggle that is off by default and the [UI reflects Experiment status](https://design.gitlab.com/usability/feature-management#highlighting-feature-versions).
-- Feedback issue to engage with team.
-- UX not finalized, might be just quick action access.
-- Not announced in a release post.
-
-## Beta
-
-Commercially-reasonable efforts are made to provide limited support for features designated as "Beta," with the expectation that issues require extra time and assistance from development to troubleshoot.
-
-- May not be ready for production use and the UI and documentation will reflect this status.
-- May be unstable and can cause performance and stability issues.
-- Configuration and dependencies unlikely to change.
-- Features and functions unlikely to change. However, breaking changes may occur outside of major releases or with less notice than for Generally Available features.
-- Data loss not likely.
-- Support on a commercially-reasonable effort basis.
-- Documentation reflects Beta status.
-- UX complete or near completion.
-- Behind a feature flag that is on by default and the [UI reflects Beta status](https://design.gitlab.com/usability/feature-management#highlighting-feature-versions).
-- Behind a toggle that is off by default and the [UI reflects Beta status](https://design.gitlab.com/usability/feature-management#highlighting-feature-versions).
-- Can be announced in a release post that reflects Beta status.
-
-## Generally Available (GA)
-
-Generally Available features means that they passed the [Production Readiness Review](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/.gitlab/issue_templates/production_readiness.md) for GitLab.com, and are:
-
-- Ready for production use at any scale.
-- Fully documented and supported.
-- UX complete and in line with GitLab design standards.
-
-## Never internal
-
-Features are never internal (GitLab team-members) only.
-Our [mission is "everyone can contribute"](https://about.gitlab.com/company/mission/), and that is only possible if people outside the company can try a feature.
-We will get higher quality (more diverse) feedback if people from different organizations try something.
-We've also learned that internal only as a state slows us down more than it speeds us up.
-Release the experiment instead of testing internally or waiting for the feature to be in a Beta state.
-The experimental features are only shown when people/organizations opt-in to experiments, we are allowed to make mistakes here and literally experiment.
-
-## All features are in production
-
-All features that are available on GitLab.com are considered "in production."
-Because all Experiment, Beta, and Generally Available features are available on GitLab.com, they are all considered to be in production.
+<!-- This redirect file can be deleted after <2023-09-07>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/policy/experiment-beta-support.md b/doc/policy/experiment-beta-support.md
new file mode 100644
index 00000000000..59490ac3d68
--- /dev/null
+++ b/doc/policy/experiment-beta-support.md
@@ -0,0 +1,69 @@
+---
+stage: Systems
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Support for Experiment, Beta, and Generally Available features **(PREMIUM)**
+
+Some GitLab features are released as Experiment or Beta versions and are
+[not fully supported](https://about.gitlab.com/support/statement-of-support/#alpha-beta-features).
+All other features are considered to be Generally Available (GA).
+
+## Experiment
+
+Support is not provided for features listed as "Experimental" or "Alpha" or any similar designation. Issues regarding such features should be opened in the GitLab issue tracker.
+
+- Not ready for production use.
+- No support available.
+- May be unstable or have performance issues.
+- Can be removed at any time.
+- Data loss may occur.
+- Documentation may not exist or just be in a blog format.
+- [User interface reflects Experiment status](https://design.gitlab.com/usability/feature-management#highlighting-feature-versions).
+- User experience incomplete, might be just quick action access.
+- Behind a feature flag that is on by default.
+- Behind a toggle that is off by default.
+- Not announced in a release post.
+- Can be promoted in the user interface through [discovery moments](https://design.gitlab.com/usability/feature-management#discovery-moments), if needed.
+- Feedback issue to engage with team.
+
+## Beta
+
+Commercially-reasonable efforts are made to provide limited support for features designated as "Beta," with the expectation that issues require extra time and assistance from development to troubleshoot.
+
+- May not be ready for production use.
+- Support on a commercially-reasonable effort basis.
+- May be unstable and can cause performance and stability issues.
+- Configuration and dependencies unlikely to change.
+- Features and functions unlikely to change. However, breaking changes may occur outside of major releases or with less notice than for Generally Available features.
+- Data loss not likely.
+- Documentation reflects Beta status.
+- [User interface reflects Beta status](https://design.gitlab.com/usability/feature-management#highlighting-feature-versions).
+- User experience complete or near completion.
+- Behind a feature flag that is on by default.
+- Behind a toggle that is off by default.
+- Can be announced in a release post that reflects Beta status.
+- Can be promoted in the user interface through [discovery moments](https://design.gitlab.com/usability/feature-management#discovery-moments), if needed.
+
+## Generally Available (GA)
+
+Generally Available features means that they passed the [Production Readiness Review](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/.gitlab/issue_templates/production_readiness.md) for GitLab.com, and are:
+
+- Ready for production use at any scale.
+- Fully documented and supported.
+- User experience complete and in line with GitLab design standards.
+
+## Never internal
+
+Features are never internal (GitLab team-members) only.
+Our [mission is "everyone can contribute"](https://about.gitlab.com/company/mission/), and that is only possible if people outside the company can try a feature.
+We get higher quality (more diverse) feedback if people from different organizations try something.
+We've also learned that internal only as a state slows us down more than it speeds us up.
+Release the experiment instead of testing internally or waiting for the feature to be in a Beta state.
+The experimental features are only shown when people/organizations opt-in to experiments, we are allowed to make mistakes here and literally experiment.
+
+## All features are in production
+
+All features that are available on GitLab.com are considered "in production."
+Because all Experiment, Beta, and Generally Available features are available on GitLab.com, they are all considered to be in production.
diff --git a/doc/policy/maintenance.md b/doc/policy/maintenance.md
index eed9f006bfa..7970f9711e6 100644
--- a/doc/policy/maintenance.md
+++ b/doc/policy/maintenance.md
@@ -53,13 +53,13 @@ cases you must consider. Follow the
 between versions.
 
 NOTE:
-Version specific changes in Omnibus GitLab Linux packages can be found in [the Omnibus GitLab documentation](../update/package/index.md#version-specific-changes).
+Version specific changes in Linux packages can be found in [the Linux package documentation](../update/package/index.md#version-specific-changes).
 
 NOTE:
-Instructions are available for downloading an Omnibus GitLab Linux package locally and [manually installing](../update/package/index.md#upgrade-using-a-manually-downloaded-package) it.
+Instructions are available for downloading the Linux package locally and [manually installing](../update/package/index.md#upgrade-using-a-manually-downloaded-package) it.
 
 NOTE:
-A step-by-step guide to [upgrading the Omnibus-bundled PostgreSQL is documented separately](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).
+A step-by-step guide to [upgrading the Linux package-bundled PostgreSQL is documented separately](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).
 
 ## Upgrading major versions
 
diff --git a/doc/raketasks/backup_gitlab.md b/doc/raketasks/backup_gitlab.md
index e04d63da2ad..a6635c589aa 100644
--- a/doc/raketasks/backup_gitlab.md
+++ b/doc/raketasks/backup_gitlab.md
@@ -21,6 +21,7 @@ including:
 - Packages ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332006) in GitLab 14.7)
 - Snippets
 - [Group wikis](../user/project/wiki/group.md)
+- Project-level Secure Files ([introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121142) in GitLab 16.1)
 
 Backups do not include:
 
@@ -146,7 +147,7 @@ the GitLab container according to the documentation, it should be in the
 
 For [GitLab Helm chart installations](https://gitlab.com/gitlab-org/charts/gitlab)
 on a Kubernetes cluster, you must follow the
-[Back up the secrets](https://docs.gitlab.com/charts/backup-restore/backup.html#backup-the-secrets)
+[Back up the secrets](https://docs.gitlab.com/charts/backup-restore/backup.html#back-up-the-secrets)
 instructions.
 
 You may also want to back up any TLS keys and certificates (`/etc/gitlab/ssl`, `/etc/gitlab/trusted-certs`), and your
@@ -240,6 +241,7 @@ You can exclude specific directories from the backup by adding the environment v
 - `pages` (Pages content)
 - `repositories` (Git repositories data)
 - `packages` (Packages)
+- `ci_secure_files` (Project-level Secure Files)
 
 NOTE:
 When [backing up and restoring Helm Charts](https://docs.gitlab.com/charts/architecture/backup-restore.html), there is an additional option `packages`, which refers to any packages managed by the GitLab [package registry](../user/packages/package_registry/index.md).
@@ -396,23 +398,25 @@ sudo -u git -H bundle exec rake gitlab:backup:create REPOSITORIES_STORAGES=stora
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/88094) in GitLab 15.1.
 
-You can back up a specific repositories using the `REPOSITORIES_PATHS` option.
-The option accepts a comma-separated list of project and group paths. If you
+You can back up specific repositories using the `REPOSITORIES_PATHS` option.
+Similarly, you can use `SKIP_REPOSITORIES_PATHS` to skip certain repositories.
+Both options accept a comma-separated list of project or group paths. If you
 specify a group path, all repositories in all projects in the group and
-descendent groups are included.
+descendent groups are included or skipped, depending on which option you used.
 
-For example, to back up all repositories for all projects in **Group A** (`group-a`), and the repository for **Project C** in **Group B** (`group-b/project-c`):
+For example, to back up all repositories for all projects in **Group A** (`group-a`), the repository for **Project C** in **Group B** (`group-b/project-c`),
+and skip the **Project D** in **Group A** (`group-a/project-d`):
 
 - Omnibus GitLab installations:
 
   ```shell
-  sudo gitlab-backup create REPOSITORIES_PATHS=group-a,group-b/project-c
+  sudo gitlab-backup create REPOSITORIES_PATHS=group-a,group-b/project-c SKIP_REPOSITORIES_PATHS=group-a/project-d
   ```
 
 - Installations from source:
 
   ```shell
-  sudo -u git -H bundle exec rake gitlab:backup:create REPOSITORIES_PATHS=group-a,group-b/project-c
+  sudo -u git -H bundle exec rake gitlab:backup:create REPOSITORIES_PATHS=group-a,group-b/project-c SKIP_REPOSITORIES_PATHS=group-a/project-d
   ```
 
 ### Upload backups to a remote (cloud) storage
@@ -449,7 +453,7 @@ For Omnibus GitLab packages:
    # gitlab_rails['backup_multipart_chunk_size'] = 104857600
    ```
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect
 
 #### S3 Encrypted Buckets
@@ -533,7 +537,7 @@ This example can be used for a bucket in Amsterdam (AMS3):
    gitlab_rails['backup_upload_remote_directory'] = 'my.s3.bucket'
    ```
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect
 
 If you see a `400 Bad Request` error message when using Digital Ocean Spaces,
@@ -674,7 +678,7 @@ For Omnibus GitLab packages:
    gitlab_rails['backup_upload_remote_directory'] = 'my.google.bucket'
    ```
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect
 
 For installations from source:
@@ -712,7 +716,7 @@ For Omnibus GitLab packages:
    gitlab_rails['backup_upload_remote_directory'] = '<AZURE BLOB CONTAINER>'
    ```
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect
 
 For installations from source:
@@ -813,7 +817,7 @@ For Omnibus GitLab packages:
    gitlab_rails['backup_upload_remote_directory'] = 'gitlab_backups'
    ```
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 For installations from source:
@@ -851,7 +855,7 @@ For Omnibus GitLab packages:
    gitlab_rails['backup_archive_permissions'] = 0644 # Makes the backup archives world-readable
    ```
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 For installations from source:
@@ -935,7 +939,7 @@ For Omnibus GitLab packages:
    gitlab_rails['backup_keep_time'] = 604800
    ```
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 For installations from source:
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 18303a5f45c..1fd772c06da 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -55,7 +55,7 @@ If you have a specific reason to change the path, it can be configured in Omnibu
    gitlab_rails['backup_gitaly_backup_path'] = '/path/to/gitaly-backup'
    ```
 
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
 ## Backup timestamp
@@ -288,7 +288,7 @@ To prepare the new server:
       Edit `/etc/gitlab/gitlab.rb` and set the following:
 
       ```ruby
-      nginx['custom_gitlab_server_config'] = "location /api/v4/jobs/request {\n deny all;\n return 503;\n}\n"
+      nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"
       ```
 
    1. Reconfigure GitLab:
@@ -319,7 +319,7 @@ To prepare the new server:
    1. Edit `/etc/gitlab/gitlab.rb`, and set the following:
 
       ```ruby
-      nginx['custom_gitlab_server_config'] = "location /api/v4/jobs/request {\n deny all;\n return 503;\n}\n"
+      nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"
       ```
 
    1. Reconfigure GitLab:
@@ -329,7 +329,8 @@ To prepare the new server:
       ```
 
 1. Disable periodic background jobs:
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
    1. On the left sidebar, select **Monitoring > Background Jobs**.
    1. Under the Sidekiq dashboard, select **Cron** tab and then
       **Disable All**.
@@ -409,7 +410,8 @@ To prepare the new server:
 
 1. [Restore the GitLab backup](#restore-gitlab).
 1. Verify that the Redis database restored correctly:
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
    1. On the left sidebar, select **Monitoring > Background Jobs**.
    1. Under the Sidekiq dashboard, verify that the numbers
       match with what was shown on the old server.
@@ -425,7 +427,7 @@ To prepare the new server:
 
    ```ruby
    # The following line must be removed
-   nginx['custom_gitlab_server_config'] = "location /api/v4/jobs/request {\n deny all;\n return 503;\n}\n"
+   nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"
    ```
 
 1. Reconfigure GitLab:
@@ -570,7 +572,7 @@ after which users must reactivate 2FA.
 
    These are the variables that you need to delete.
 
-1. Drop the table:
+1. Delete all variables:
 
    ```sql
    DELETE FROM ci_group_variables;
diff --git a/doc/raketasks/index.md b/doc/raketasks/index.md
index a44f053bc7b..47fa7e855a1 100644
--- a/doc/raketasks/index.md
+++ b/doc/raketasks/index.md
@@ -44,7 +44,7 @@ The following Rake tasks are available for use with GitLab:
 | [Reset user passwords](../security/reset_user_password.md#use-a-rake-task) | Reset user passwords using Rake. |
 | [Uploads migrate](../administration/raketasks/uploads/migrate.md) | Migrate uploads between local storage and object storage. |
 | [Uploads sanitize](../administration/raketasks/uploads/sanitize.md) | Remove EXIF data from images uploaded to earlier versions of GitLab. |
-| [Service Data](../development/service_ping/troubleshooting.md#generate-service-ping) | Generate and troubleshoot [Service Ping](../development/service_ping/index.md). |
+| [Service Data](../development/internal_analytics/service_ping/troubleshooting.md#generate-service-ping) | Generate and troubleshoot [Service Ping](../development/internal_analytics/service_ping/index.md). |
 | [User management](user_management.md)                 | Perform user management tasks. |
 | [Webhooks administration](web_hooks.md)               | Maintain project webhooks. |
 | [X.509 signatures](x509_signatures.md)                | Update X.509 commit signatures, which can be useful if the certificate store changed. |
diff --git a/doc/raketasks/restore_gitlab.md b/doc/raketasks/restore_gitlab.md
index c7abc7ac562..bbb2f2aa648 100644
--- a/doc/raketasks/restore_gitlab.md
+++ b/doc/raketasks/restore_gitlab.md
@@ -14,7 +14,7 @@ information. Be sure to read and test the complete restore process at least
 once before attempting to perform it in a production environment.
 
 You can restore a backup only to _the exact same version and type (CE/EE)_ of
-GitLab that you created it on (for example CE 9.1.0).
+GitLab that you created it on (for example CE 15.1.4).
 
 If your backup is a different version than the current installation, you must
 [downgrade](../update/package/downgrade.md) or [upgrade](../update/package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) your GitLab installation
@@ -367,24 +367,24 @@ sudo -u git -H bundle exec rake gitlab:backup:restore BACKUP=timestamp_of_backup
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/88094) in GitLab 15.1.
 
-You can restore specific repositories using the `REPOSITORIES_PATHS` option.
-The option accepts a comma-separated list of project and group paths. If you
+You can restore specific repositories using the `REPOSITORIES_PATHS` and the `SKIP_REPOSITORIES_PATHS` options.
+Both options accept a comma-separated list of project and group paths. If you
 specify a group path, all repositories in all projects in the group and
-descendent groups are included. The project and group repositories must exist
-within the specified backup.
+descendent groups are included or skipped, depending on which option you used. The project and group repositories must exist within the specified backup.
 
-For example, to restore all repositories for all projects in **Group A** (`group-a`), and the repository for **Project C** in **Group B** (`group-b/project-c`):
+For example, to restore all repositories for all projects in **Group A** (`group-a`), the repository for **Project C** in **Group B** (`group-b/project-c`),
+and skip the **Project D** in **Group A** (`group-a/project-d`):
 
 - Omnibus GitLab installations:
 
   ```shell
-  sudo gitlab-backup restore BACKUP=timestamp_of_backup REPOSITORIES_PATHS=group-a,group-b/project-c
+  sudo gitlab-backup restore BACKUP=timestamp_of_backup REPOSITORIES_PATHS=group-a,group-b/project-c SKIP_REPOSITORIES_PATHS=group-a/project-d
   ```
 
 - Installations from source:
 
   ```shell
-  sudo -u git -H bundle exec rake gitlab:backup:restore BACKUP=timestamp_of_backup REPOSITORIES_PATHS=group-a,group-b/project-c
+  sudo -u git -H bundle exec rake gitlab:backup:restore BACKUP=timestamp_of_backup REPOSITORIES_PATHS=group-a,group-b/project-c SKIP_REPOSITORIES_PATHS=group-a/project-d
   ```
 
 ### Restore untarred backups
diff --git a/doc/security/hardening.md b/doc/security/hardening.md
new file mode 100644
index 00000000000..21b8594fc6e
--- /dev/null
+++ b/doc/security/hardening.md
@@ -0,0 +1,67 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# GitLab Hardening Recommendations **(FREE SELF)**
+
+This documentation is for GitLab instances where the overall system can be "hardened"
+against common and even not-so-common attacks. It is not designed to completely
+eradicate attacks, but to provide strong mitigation thereby reducing overall risk. Some
+of the techniques apply to any GitLab deployment, such as SaaS or self-managed, while other
+techniques apply to the underlying OS.
+
+These techniques are a work in progress, and have not been tested at scale
+(such as a large environments with many users). They have been tested on a self-managed
+single instance running a Linux package installation, and while many of the techniques can
+translated to other deployment types, they may not all work or apply.
+
+Most of the listed recommendations provide specific recommendations or
+reference choices one can make based upon the general documentation.
+Through hardening, there may be impact to certain features your users may specifically
+want or depend on, so you should communicate with users and do a phased rollout of hardening
+changes.
+
+The hardening instructions are in five categories for easier
+understanding. They are listed in the following section.
+
+## GitLab hardening general concepts
+
+This details information on hardening as an approach to security and some of the larger
+philosophies. For more information, see [hardening general concepts](hardening_general_concepts.md).
+
+## GitLab application settings
+
+Application settings made using the GitLab GUI to the application itself. For more information, see
+[application recommendations](hardening_application_recommendations.md).
+
+## GitLab CI/CD settings
+
+CI/CD is a core component of GitLab, and while application of security principles
+are based upon needs, there are several things you can do to make your CI/CD more secure.
+For more information, see [CI/CD Recommendations](hardening_cicd_recommendations.md).
+
+## GitLab configuration settings
+
+Configuration file settings used to control and configure the
+application (such as `gitlab.rb`) are documented separately. For more information, see the
+[configuration recommendations](hardening_configuration_recommendations.md).
+
+## Operating System settings
+
+You can adjust the underlying operating system to increase overall security. For more information, see the
+[operating system recommendations](hardening_operating_system_recommendations.md).
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/hardening_application_recommendations.md b/doc/security/hardening_application_recommendations.md
new file mode 100644
index 00000000000..9d4d2d562fd
--- /dev/null
+++ b/doc/security/hardening_application_recommendations.md
@@ -0,0 +1,243 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Hardening - Application Recommendations
+
+For general hardening guidelines, see the [main hardening documentation](hardening.md).
+
+You control the hardening recommendations for GitLab instances through the
+web interface.
+
+## System hooks
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **System Hooks**.
+
+In a typical hardened environment, internal information is not transmitted or stored
+outside of the system. For an offline environment system, this is
+implied. System hooks provide a way for local events in the environment to communicate
+information outside of the environment based upon triggers.
+
+Use cases for this capability are supported, particularly monitoring the
+system through a remote system.
+However, you must apply extreme caution when deploying system hooks. For hardened
+systems, if they are intended to be an offline environment, a perimeter of trusted
+systems allowed to communicate with each other must be enforced, so any hooks
+(system, web, or file) must only communicate with those trusted systems. TLS is strongly
+encouraged for communications through system hooks.
+
+## Push rules
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Push Rules**.
+
+Ensure that the following items are selected:
+
+- **Reject unverified users**
+- **Do not allow users to remove Git tags with `git push`**
+- **Check whether the commit author is a GitLab user**
+- **Prevent pushing secret files**
+
+The adjustments help limit pushes to established and authorized users.
+
+## Deploy keys
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Deploy Keys**.
+
+Public deploy keys at are used to give read or read/write access to
+**all** projects on the instance, and are intended for remote automation to access
+projects. Public deploy keys should not be used in a hardened environment. If you
+must use deploy keys, use project deploy keys instead. For more information, refer to
+the documentation on [deploy keys](../user/project/deploy_keys/index.md) and
+[project deploy keys](../user/project/deploy_keys/index.md#create-a-project-deploy-key).
+
+## General
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > General**.
+
+Hardening adjustments can be made in 4 sections.
+
+### Visibility and access control
+
+The default for the following settings is **Private**:
+
+- **Default project visibility**
+- **Default snippet visibility**
+- **Default group visibility**
+
+Only users that are granted specific access to a project, snippet, or group can
+access these resources. This can be adjusted later as needed or at the time of
+their creation. This helps prevent accidental or malicious disclosure of information.
+
+Depending on your security policy and posture, you might wish to set your
+**Restricted visibility level** to **Public**, as this prevents user profiles
+from being viewed by non-authenticated users.
+
+In **Import sources**, select only the sources you really need.
+
+A typical deployment has **Enabled Git access protocols** set to **Both SSH and HTTP(S)**,
+however if one of the Git protocols is not in use by your users, set it to either
+**Only SSH** or **Only HTTP(S)** accordingly. This helps shrink the attack surface.
+
+For SSH key types, the following are preferred: `ED25519` (and `ED25519-SK`), `RSA`, and
+`ECDSA` (and `ECDSA-SK`) in that order. `ED25519` is considered as secure as `RSA` when
+`RSA` is set to 2048 bits or higher, however the `ED25519` keys are smaller and the
+algorithm is much faster.
+
+`ED25519-SK` and `ECDSA-SK` both end with `-SK` which stands for
+"Security Key". The `-SK` types are compatible with FIDO/U2F standards and pertain to
+usage with hardware tokens, for example YubiKeys.
+
+`DSA` should be set to "Are forbidden". `DSA` has known flaws, and many cryptographers
+are suspicious of and do not support using `ECDSA`.
+
+If GitLab is in FIPS mode, use the following:
+
+- If running in FIPS mode:
+  - Use `RSA`, set to **Must be at least 2048 bits**.
+  - Use `ECDSA` (and `ECDSA-SK`), set to **Must be at least 256 bits**.
+  - Set all other key types to **Are forbidden**.
+  `RSA` and `ECDSA` are both approved for FIPS use.
+- If not running in FIPS mode, you must use `ED25519` and can also use `RSA`:
+  - Set `ED25519` (and `ED25519-SK`) to **Must be at least 256 bits**.
+  - If using `RSA`, set it to **Must be at least 2048 bits**.
+  - Set all other key types to **Are forbidden**.
+- If you are setting up an instance for a new group of users, define your user SSH
+key policy with the maximum bits settings for added security.
+
+In a hardened environment RSS feeds are typically not required, and in **Feed token**,
+select the **Disabled feed token** checkbox.
+
+If all of your users are coming from specific IP addresses, use **Global-allowed IP ranges**
+to specifically allow only those addresses.
+
+For more details on **Visibility and access control**, see [visibility and access controls](../user/admin_area/settings/visibility_and_access_controls.md).
+For information on SSH settings, see
+[SSH keys restrictions](../security/ssh_keys_restrictions.md).
+
+### Account and limit
+
+For hardening purposes, ensure the checkbox next to **Gravatar enabled** is not selected.
+All extraneous communications should be curtailed, and in some environments might be
+restricted. Account avatars can be manually uploaded by users.
+
+The settings in this section are intended to help enforce a custom implementation
+of your own specific standards on your users. As the various scenarios are too many
+and too varied, you should review the
+[account and limit settings documentation](../user/admin_area/settings/account_and_limit_settings.md)
+and apply changes to enforce your own policies.
+
+### Sign-up restrictions
+
+Ensure open sign-up is disabled on your hardened instance. Ensure the **Sign-up enabled** checkbox is not selected.
+
+In **Email confirmation settings**, ensure that **Hard** is selected. User verification
+of their email address is now enforced before access is granted.
+
+The **Minimum password length (number of characters)** default setting is 12 which
+should be fine as long as additional authentication techniques are used. The password
+should be complex, so ensure that all four of these checkboxes are selected:
+
+- **Require numbers**
+- **Require uppercase letters**
+- **Require lowercase letters**
+- **Require symbols**
+
+If all of your users belong to the same organization that uses a specific domain for
+email addresses, then list that domain in **Allowed domains for sign-ups**. This
+prevents those with email addresses in other domains from signing up.
+
+For more detailed information, see
+[sign-up restrictions](../user/admin_area/settings/sign_up_restrictions.md).
+
+### Sign-in restrictions
+
+Two-factor authentication (2FA) should be enabled for all users. Ensure that the
+checkbox next to **Two-factor authentication** (2FA) is selected.
+
+The default setting for **Two-factor grace period** is 48 hours. This should be adjusted
+to a much lower value, such as 8 hours.
+
+Ensure the checkbox next to **Enable admin mode** is selected so that **Admin Mode** is
+active. This requires users with Admin access to have to use additional
+authentication in order to perform administrative tasks, enforcing additional 2FA by the user.
+
+In **Email notification for unknown sign-ins**, ensure that **Enable email notification**
+is selected. This sends an email to users when a sign-in occurs from an unrecognized location.
+
+For more detailed information, see
+[sign-in restrictions](../user/admin_area/settings/sign_in_restrictions.md).
+
+## Integrations
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > Integrations**.
+
+In general, as long as administrators control and monitor usage, integrations
+are fine in a hardened environment. Be cautious about integrations that allow
+for actions from an outside system that trigger actions and processes that typically
+require a level of access you would restrict or audit if performed by a local
+process or authenticated user.
+
+## Metrics and profiling
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > Metrics and profiling**.
+
+The main focus for hardening is **Usage statistics**:
+
+- You should make sure **Enable version check** is selected. This checks to see if you
+are running the latest version of GitLab, and as new versions with new features and
+security patches come out frequently, this helps you stay up to date.
+
+- If your environment is isolated or one where your organizational requirements
+restrict data gathering and statistics reporting to a software vendor, you may have
+to disable the **Enable service ping** feature. For more information on what data is collected to
+help you make an informed decision, see
+[service ping](../development/service_ping/index.md).
+
+## Network
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > Network**.
+
+For any setting that enables rate limiting, make sure it is selected. Default values
+should be fine. Additionally there are numerous settings that enable access, and all
+of these should be cleared.
+
+After you've made these adjustments you can fine tune the system to meet performance
+and user needs, which may require disabling and adjusting rate limits or enabling
+accesses. Here are a few notables to keep in mind:
+
+- In **Outbound requests**, if you need to open up access to a limited
+number of systems, you can limit access to just those systems by specifying
+IP address or hostname. Also in this section, make sure you've selected
+**Enforce DNS rebinding attack protection** if you're allowing any access at all.
+
+- Under **Notes rate limit** and **Users API rate limit** you can exclude specific users
+from those limits if needed.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/hardening_cicd_recommendations.md b/doc/security/hardening_cicd_recommendations.md
new file mode 100644
index 00000000000..16b649cbdd7
--- /dev/null
+++ b/doc/security/hardening_cicd_recommendations.md
@@ -0,0 +1,69 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Hardening - CI/CD Recommendations
+
+General hardening guidelines and philosophies are outlined in the [main hardening documentation](hardening.md).
+
+The hardening recommendations and concepts for CI/CD are listed below.
+
+## Basic Recommendations
+
+How you configure the different CI/CD settings depends on your use of CI/CD. For example if you are using it to build
+packages, you often need real-time access to external resources such as Docker
+images or external code repositories. If you are using it for Infrastructure
+as Code (IaC), you often need to store credentials for external systems to
+automate deployment. For these and many other scenarios, you need to store
+potentially sensitive information to be used during CI/CD operations. As the
+individual scenarios themselves are numerous, we have summarized some basic
+information to help harden the CI/CD process.
+
+- **Secrets Management**. Passwords, tokens, keys, and other secrets that require any
+level of protection should never be stored in plaintext. Some type of encrypted
+container technology should be used, such as GCP Secret Manager, AWS KMS, or
+HashiCorp Vault. For self-managed and standalone instances, HashiCorp Vault is
+recommended, and many GitLab features can take advantage of Vault and are well
+documented in the main [Documentation](../index.md). For detailed CI/CD examples, see [using external secrets in CI](../ci/secrets/index.md).
+- **External Communications**. If your CI/CD process requires connectivity to other
+hosts, ensure that these communication channels are encrypted. You should use TLS 1.2 or 1.3, and where possible implement mutual TLS.
+- **Logging**. Logging can be very important for auditing and troubleshooting, so it
+is important that you enable any logging features to ensure you are getting
+the information in logs you need. Make sure through periodic testing that
+plaintext secrets or other sensitive information is not inadvertently added to log
+files.
+
+## Specific Recommendations
+
+### Pipelines
+
+Pipelines are a part of jobs that execute steps in stages to automate tasks on behalf
+of the users of a project. They are a core component of CD/CD.
+
+By default, only the default branch gets a protected pipeline. An owner of a project
+can ensure that other branches are protected by
+[configuring a protected branch](../user/project/protected_branches.md).
+This allows for more restricted security on pipelines. For more information, see
+[pipeline security on a protected branch](../ci/pipelines/index.md#pipeline-security-on-protected-branches).
+
+Deployment is the part of the CI/CD that deploys the results of the pipeline in
+relationship to a given environment. Default settings do not impose many
+restrictions, and as different users with different roles and responsibilities can
+trigger pipelines that can interact with those environments, you should
+restrict these environments. For more information, see
+[protected environments](../ci/environments/protected_environments.md).
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/hardening_configuration_recommendations.md b/doc/security/hardening_configuration_recommendations.md
new file mode 100644
index 00000000000..475ec06835c
--- /dev/null
+++ b/doc/security/hardening_configuration_recommendations.md
@@ -0,0 +1,161 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Hardening - Configuration Recommendations
+
+General hardening guidelines are outlined in the [main hardening documentation](hardening.md).
+
+Some hardening recommendations for GitLab instances involve additional
+services or control through configuration files. As a reminder, any time you are
+making changes to configuration files, make backup copies of
+them before editing. Additionally, if you are making a lot of changes it is
+recommended you do not do all of the changes at once, and test them after each
+change to ensure everything is working.
+
+## NGINX
+
+NGINX is used to serve up the web interface used to access the GitLab instance. As
+NGINX is controlled and integrated into GitLab, modification of the
+`/etc/gitlab/gitlab.rb` file used for adjustments. Here are a few recommendations for helping to improve
+the security of NGINX itself:
+
+```shell
+#
+# Only strong ciphers are used
+#
+nginx['ssl_ciphers'] = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256"
+#
+# Follow preferred ciphers and the order listed as preference
+#
+nginx['ssl_prefer_server_ciphers'] = "on"
+#
+# Only allow TLSv1.2 and TLSv1.3
+#
+nginx['ssl_protocols'] = "TLSv1.2 TLSv1.3"
+
+##! **Recommended in: https://nginx.org/en/docs/http/ngx_http_ssl_module.html**
+nginx['ssl_session_cache'] = "builtin:1000  shared:SSL:10m"
+
+##! **Default according to https://nginx.org/en/docs/http/ngx_http_ssl_module.html**
+nginx['ssl_session_timeout'] = "5m"
+
+# Should prevent logjam attack etc
+# For the example below, run the following first:
+# openssl dhparam -out /etc/gitlab/ssl/dhparam.pem 4096
+nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparams.pem" # changed from nil
+
+# Turn off session ticket reuse
+nginx['ssl_session_tickets'] = "off"
+# Pick our own curve instead of what openssl hands us
+nginx['ssl_ecdh_curve'] = "secp384r1"
+```
+
+## Consul
+
+Consul can be integrated into a GitLab environment, and is intended for larger
+deployments. In general for self-managed and standalone deployments with less than
+1000 users, Consul may not be needed. If it is needed, first review the
+[documentation on Consul](../administration/consul.md), but
+more importantly ensure that encryption is used during communications. For more
+detailed information on Consul visit the
+[HashiCorp website](https://developer.hashicorp.com/consul/docs) to understand how it
+works, and review the information on
+[encryption security](https://developer.hashicorp.com/consul/docs/security/encryption).
+
+## Environment Variables
+
+You can customize multiple
+[environment variables](https://docs.gitlab.com/omnibus/settings/environment-variables.html)
+on self-managed systems. The main environment variable to
+take advantage of from a security perspective is `GITLAB_ROOT_PASSWORD` during the
+installation process. If you are installing the self-managed system with a
+public-facing IP address exposed to the Internet, make sure the password is set to
+something strong. Historically, setting up any type of public-facing service - whether
+it is GitLab or some other application - has shown that opportunistic attacks occur
+as soon as those systems are discovered, so the hardening process should start during
+the installation process.
+
+As mentioned in the [operating system recommendations](hardening_operating_system_recommendations.md)
+ideally there should be firewall rules already in place before the GitLab
+installation begins, but you should still set a secure password before the
+installation through `GITLAB_ROOT_PASSWORD`.
+
+## Git Protocols
+
+To ensure that only authorized users are using SSH for Git access, add the following
+to your `/etc/ssh/sshd_config` file:
+
+```shell
+# Ensure only authorized users are using Git
+AcceptEnv GIT_PROTOCOL
+```
+
+This ensures that users cannot pull down projects using SSH unless they have a valid
+GitLab account that can perform `git` operations over SSH. More details can be found
+under [Configuring Git Protocol](../administration/git_protocol.md).
+
+## Incoming Email
+
+You can configure a GitLab self-managed instance to allow for incoming email to be
+used for commenting or creating issues and merge requests by registered users on
+the GitLab instance. In a hardened environment you should not configure
+this feature as it involves outside communications sending in information.
+
+If the feature is required, follow the instructions in the
+[incoming email documentation](../administration/incoming_email.md), with
+the following recommendations to ensure maximum security:
+
+- Dedicate an email address specifically for inbound emails to the instance.
+- Use [email sub-addressing](../administration/incoming_email.md).
+- Email accounts used by users to send emails should require and have multi-factor authentication (MFA) enabled on those accounts.
+- For Postfix specifically, follow the [set up Postfix for incoming email documentation](../administration/reply_by_email_postfix_setup.md).
+
+## Redis Replication and Failover
+
+Redis is used on a Linux package installation for replication and failover, and can be
+set up when scaling requires that capability. Bear in mind that this opens TCP ports
+`6379` for Redis and `26379` for Sentinel. Follow the
+[replication and failover documentation](../administration/redis/replication_and_failover.md)
+but note the IP addresses of all of the nodes, and set up firewall rules between
+nodes that only allow the other node to access those particular ports.
+
+## Sidekiq Configuration
+
+In the [instructions for configuring an external Sidekiq](../administration/sidekiq/index.md)
+there are numerous references to configuring IP ranges. You must
+[configure HTTPS](../administration/sidekiq/index.md#enable-https),
+and consider restricting those IP addresses to specific systems that Sidekiq talks to.
+You might have to adjust firewall rules at the operating system level as well.
+
+## S/MIME Signing of Email
+
+If the GitLab instance is configured for sending out email notifications to users,
+configure S/MIME signing to help the recipients ensure that the emails are
+legitimate. Follow the instructions on [signing outgoing email](../administration/smime_signing_email.md).
+
+## Container Registry
+
+If Lets Encrypt is configured, the Container Registry is enabled by default. This
+allows projects to store their own Docker images. Follow the instructions for
+configuring the [Container Registry](../administration/packages/container_registry.md),
+so you can do things like restrict automatic enablement on new projects and
+disabling the Container Registry entirely. You may have to adjust firewall rules to
+allow access - if a completely standalone system, you should restrict access to the
+Container Registry to localhost only. Specific examples of ports used and their
+configuration are also included in the documentation.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/hardening_general_concepts.md b/doc/security/hardening_general_concepts.md
new file mode 100644
index 00000000000..a227f0134d0
--- /dev/null
+++ b/doc/security/hardening_general_concepts.md
@@ -0,0 +1,88 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Hardening - General Concepts
+
+General hardening guidelines are outlined in the [main hardening documentation](hardening.md).
+
+The following documentation summarises some of the underlying philosophies for GitLab instance hardening.
+While we reference GitLab, in many cases they can actually apply to all computer systems.
+
+## Layered security
+
+If there are two ways to implement security, both ways should be implemented instead of
+just one. A quick example is account security:
+
+- Use a long, complex, and unique password for the account.
+- Implement a second factor to the authentication process for added security.
+- Use a hardware token as a second factor.
+- Lock out an account (for at least a fixed amount of time) for failed authentication
+attempts.
+- An account that is unused for a specific time frame should be disabled, enforce this
+with either automation or regular audits.
+
+Instead of using only one or two items on the list, use as many as possible. This
+philosophy can apply to other areas besides account security - it should be applied to
+every area possible.
+
+## Eliminate security through obscurity
+
+Security through obscurity means that one does not discuss certain
+elements of a system, service, or process because of a fear that a potential attacker
+might use those details to formulate an attack. Instead, the system should be secured to
+the point that details about its configuration could be public and the system would still
+be as secure as it could be. In essence, if an attacker learned about the details of the
+configuration of a computer system it would not give them an advantage. One of the
+downsides of security through obscurity is that it can lead to a potential false sense of
+security by the administrator of the system who thinks the system is more secure than it
+actually is.
+
+An example of this is running a service on a non-standard TCP port. For example the
+default SSH daemon port on servers is TCP port 22, but it is possible to configure the
+SSH daemon to run on another port such as TCP port 2222. The administrator who configured
+this might think it increases the security of the system, however it is quite common for
+an attacker to port scan a system to discover all open ports, allowing for quick discovery
+of the SSH service, and eliminating any perceived security advantage.
+
+As GitLab is an open-core system and all of the configuration options are well documented
+and public information, the idea of security through obscurity goes against a
+GitLab core value - transparency. These hardening recommendations are intended to be
+public, to help eliminate any security through obscurity.
+
+## Attack Surface Reduction
+
+GitLab is a large system with many components. As a general rule for security, it helps
+if unused systems are disabled. This eliminates the
+available "attack surface" a potential attacker can use to strike. This can also have
+the added advantage of increasing available system resources as well.
+
+As an example, there is a process on a system that fires up and checks queues for input every
+five minutes, querying multiple sub-processes while performing its checks. If you are not
+using that process, there is no reason to have it configured and it should be disabled.
+If an attacker has figured out an attack vector that uses this process, the attacker might exploit it despite your organization not using it. As a general
+rule, you should disable any service not being used.
+
+## External systems
+
+In larger but still hardened deployments, multiple nodes are often used to
+handle the load your GitLab deployment
+requires. In those cases, use a combination of external, operating system, and
+configuration options for firewall rules. Any option that uses restrictions should only
+be opened up enough to allow the subsystem to function. Whenever possible use TLS
+encryption for network traffic.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/hardening_operating_system_recommendations.md b/doc/security/hardening_operating_system_recommendations.md
new file mode 100644
index 00000000000..8b4b706815c
--- /dev/null
+++ b/doc/security/hardening_operating_system_recommendations.md
@@ -0,0 +1,167 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Hardening - Operating System Recommendations
+
+General hardening guidelines are outlined in the [main hardening documentation](hardening.md).
+
+You can configure the underlying operating system to increase overall security. In a
+a controlled environment such as a self-managed GitLab instance it requires additional
+steps, and in fact is often required for certain deployments. FedRAMP is an example of
+such a deployment.
+
+## SSH Configuration
+
+### SSH Client Configuration
+
+For client access (either to the GitLab instance or to the underlying operating
+system), here are a couple of recommendations for SSH key generation. The first one
+is a typical SSH key:
+
+```shell
+ssh-keygen -a 64 -t ed25519 -f ~/.ssh/id_ed25519 -C "ED25519 Key"
+```
+
+For a FIPS-compliant SSH key, use the following:
+
+```shell
+ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -C "RSA FIPS-compliant Key"
+```
+
+### SSH Server Configuration
+
+At the operating system level, if you are allowing SSH access (typically through
+OpenSSH), here is an example of configuration options for the `sshd_config` file
+(the exact location may vary depending on the operating system but it is usually
+`/etc/ssh/sshd_config`):
+
+```shell
+#
+# Example sshd config file. This supports public key authentication and
+# turns off several potential security risk areas
+#
+PubkeyAuthentication yes
+PasswordAuthentication yes
+UsePAM yes
+UseDNS no
+AllowTcpForwarding no
+X11Forwarding no
+PrintMotd no
+PermitTunnel no
+# Allow client to pass locale environment variables
+AcceptEnv LANG LC_*
+# override default of no subsystems
+Subsystem       sftp    /usr/lib/openssh/sftp-server
+# Protocol adjustments, these would be needed/recommended in a FIPS or
+# FedRAMP deployment, and use only strong and proven algorithm choices
+Protocol 2
+Ciphers aes128-ctr,aes192-ctr,aes256-ctr
+HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
+KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
+Macs hmac-sha2-256,hmac-sha2-512
+
+```
+
+## Firewall Rules
+
+For firewall rules, only TCP ports `80` and `443` need to be open for basic usage. By
+default, `5050` is open for remote access to the container registry, however in a
+hardened environment this would most likely exist on a different host, and in some
+environments not open at all. Hence, the recommendation is for ports `80` and `443`
+only, and port `80` should only be used to redirect to `443`.
+
+For a truly hardened or isolated environment such as FedRAMP, you should adjust the firewall rules to restrict all ports except to those networks
+accessing it. For example, if the IP address is `192.168.1.2` and all of the authorized
+clients are also on `192.168.1.0/24`, restrict access to ports `80` and `443` to just
+`192.168.1.0/24` only (as a safety restriction), even if access is restricted
+elsewhere with another firewall.
+
+Ideally, if you're installing a self-managed instance, you should implement the firewall rules before the installation begins with access restricted to the admins and installers, and only add additional ranges of IP addresses for
+users after the instance is installed and properly hardened.
+
+Usage of `iptables` or `ufw` is acceptable to implement and enforce port `80` and `443`
+access on a per-host basis, otherwise usage of cloud-based firewall rules through GCP
+Google Compute or AWS Security Groups should enforce this. All other ports should
+be blocked, or at least restricted to specific ranges. For more information on ports, see
+[Package Defaults](../administration/package_information/defaults.md).
+
+### Firewall Additions
+
+It is possible that various services may be enabled that require external access
+(for example Sidekiq) and need network access to be opened up. Restrict these types
+of services to specific IP addresses, or a specific Class C. As a layered and added
+precaution, where possible restrict these extra services to specific nodes or
+sub-networks in GitLab.
+
+## Kernel Adjustments
+
+Kernel adjustments can be made by editing `/etc/sysctl.conf`, or one of the files in
+`/etc/sysctl.d/`. Kernel adjustments do not completely eliminate the threat of an
+attack, but add an extra layer of security. The following notes explain
+some of the advantages for these adjustments.
+
+```shell
+## Kernel tweaks for sysctl.conf ##
+##
+## The following help mitigate out of bounds, null pointer dereference, heap and
+## buffer overflow bugs, use-after-free etc from being exploited. It does not 100%
+## fix the issues, but seriously hampers exploitation.
+##
+# Default is 65536, 4096 helps mitigate memory issues used in exploitation
+vm.mmap_min_addr=4096
+# Default is 0, randomize virtual address space in memory, makes vuln exploitation
+# harder
+kernel.randomize_va_space=2
+# Restrict kernel pointer access (e.g. cat /proc/kallsyms) for exploit assistance
+kernel.kptr_restrict=2
+# Restrict verbose kernel errors in dmesg
+kernel.dmesg_restrict=1
+# Restrict eBPF
+kernel.unprivileged_bpf_disabled=1
+net.core.bpf_jit_harden=2
+# Prevent common use-after-free exploits
+vm.unprivileged_userfaultfd=0
+
+## Networking tweaks ##
+##
+## Prevent common attacks at the IP stack layer
+##
+# Prevent SYNFLOOD denial of service attacks
+net.ipv4.tcp_syncookies=1
+# Prevent time wait assassination attacks
+net.ipv4.tcp_rfc1337=1
+# IP spoofing/source routing protection
+net.ipv4.conf.all.rp_filter=1
+net.ipv4.conf.default.rp_filter=1
+net.ipv6.conf.all.accept_ra=0
+net.ipv6.conf.default.accept_ra=0
+net.ipv4.conf.all.accept_source_route=0
+net.ipv4.conf.default.accept_source_route=0
+net.ipv6.conf.all.accept_source_route=0
+net.ipv6.conf.default.accept_source_route=0
+# IP redirection protection
+net.ipv4.conf.all.accept_redirects=0
+net.ipv4.conf.default.accept_redirects=0
+net.ipv4.conf.all.secure_redirects=0
+net.ipv4.conf.default.secure_redirects=0
+net.ipv6.conf.all.accept_redirects=0
+net.ipv6.conf.default.accept_redirects=0
+net.ipv4.conf.all.send_redirects=0
+net.ipv4.conf.default.send_redirects=0
+```
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/identity_verification.md b/doc/security/identity_verification.md
new file mode 100644
index 00000000000..761bc114da2
--- /dev/null
+++ b/doc/security/identity_verification.md
@@ -0,0 +1,43 @@
+---
+stage: Anti-Abuse
+group: Anti-Abuse
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Identity verification **(FREE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95722) in GitLab 15.4 [with a flag](../administration/feature_flags.md) named `identity_verification`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available.
+This feature is not ready for production use.
+
+Identity verification provides multiple layers of GitLab account security.
+Depending on your [risk score](../integration/arkose.md), you might be required to perform up to
+three stages of verification to register an account:
+
+- **All users** - Email verification.
+- **Medium-risk users** - Phone number verification.
+- **High-risk users** - Credit card verification.
+
+## Email verification
+
+To register an account, you must provide a valid email address.
+See [Account email verification](email_verification.md).
+
+## Phone number verification
+
+In addition to email verification, you might have to provide a valid phone number and verify a one-time code.
+
+You cannot verify an account with a phone number associated with a banned user.
+
+## Credit card verification
+
+In addition to email and phone number verification, you might have to provide a valid credit card number.
+
+You cannot verify an account with a credit card number associated with a banned user.
+
+## Related topics
+
+- [Identity verification development documentation](../development/identity_verification.md)
+- [Changing risk assessment support](https://about.gitlab.com/handbook/support/workflows/reinstating-blocked-accounts.html#change-risk-assessment-credit-card-verification)
diff --git a/doc/security/index.md b/doc/security/index.md
index 7a78461d717..a62d7171112 100644
--- a/doc/security/index.md
+++ b/doc/security/index.md
@@ -27,6 +27,6 @@ type: index
 - [Project Import decompressed archive size limits](project_import_decompressed_archive_size_limits.md)
 - [Responding to security incidents](responding_to_security_incidents.md)
 
-To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md) .
+To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md). For more detailed information, refer to [Hardening](hardening.md).
 
 Self-managed GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance.
diff --git a/doc/security/password_length_limits.md b/doc/security/password_length_limits.md
index 0211a326e0a..d8e9728f455 100644
--- a/doc/security/password_length_limits.md
+++ b/doc/security/password_length_limits.md
@@ -24,8 +24,10 @@ The user password length is set to a minimum of 8 characters by default.
 
 To change the minimum password length using GitLab UI:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General** and expand **Sign-up restrictions**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Sign-up restrictions**.
 1. Enter a **Minimum password length** value greater than or equal to `8`.
 1. Select **Save changes**.
 
diff --git a/doc/security/reset_user_password.md b/doc/security/reset_user_password.md
index f8ba3953379..7adb6256259 100644
--- a/doc/security/reset_user_password.md
+++ b/doc/security/reset_user_password.md
@@ -20,9 +20,10 @@ The user's new password must meet all [password requirements](../user/profile/us
 
 To reset a user's password in the UI:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Overview > Users**.
-1. For the user whose password you want to update, select **Edit** (**{pencil-square}**).
+1. For the user whose password you want to update, select **Edit**.
 1. In the **Password** area, type a password and password confirmation.
 1. Select **Save changes**.
 
diff --git a/doc/security/ssh_keys_restrictions.md b/doc/security/ssh_keys_restrictions.md
index f15d71461d4..1e4a4226138 100644
--- a/doc/security/ssh_keys_restrictions.md
+++ b/doc/security/ssh_keys_restrictions.md
@@ -20,8 +20,9 @@ limit the allowed SSH key algorithms.
 GitLab allows you to restrict the allowed SSH key technology as well as specify
 the minimum key length for each technology:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > General** .
 1. Expand the **Visibility and access controls** section:
 
    ![SSH keys restriction Admin Area settings](img/ssh_keys_restrictions_settings.png)
diff --git a/doc/security/token_overview.md b/doc/security/token_overview.md
index 8acd4a125ce..5a772106562 100644
--- a/doc/security/token_overview.md
+++ b/doc/security/token_overview.md
@@ -20,6 +20,10 @@ You can create [Personal access tokens](../user/profile/personal_access_tokens.m
 You can limit the scope and expiration date of your personal access tokens. By default,
 they inherit permissions from the user who created them.
 
+You can use the [personal access tokens API](../api/personal_access_tokens.md) to
+programmatically take action, such as
+[rotating a personal access token](../api/personal_access_tokens.md#rotate-a-personal-access-token).
+
 ## OAuth2 tokens
 
 GitLab can serve as an [OAuth2 provider](../api/oauth2.md) to allow other services to access the GitLab API on a user's behalf.
@@ -47,6 +51,10 @@ You can limit the scope and expiration date of project access tokens. When you
 create a project access token, GitLab creates a [bot user for projects](../user/project/settings/project_access_tokens.md#bot-users-for-projects).
 Bot users for projects are service accounts and do not count as licensed seats.
 
+You can use the [project access tokens API](../api/project_access_tokens.md) to
+programmatically take action, such as
+[rotating a project access token](../api/project_access_tokens.md#rotate-a-project-access-token).
+
 ## Group access tokens
 
 [Group access tokens](../user/group/settings/group_access_tokens.md#group-access-tokens)
@@ -60,6 +68,10 @@ You can limit the scope and expiration date of group access tokens. When you
 create a group access token, GitLab creates a [bot user for groups](../user/group/settings/group_access_tokens.md#bot-users-for-groups).
 Bot users for groups are service accounts and do not count as licensed seats.
 
+You can use the [group access tokens API](../api/group_access_tokens.md) to
+programmatically take action, such as
+[rotating a group access token](../api/group_access_tokens.md#rotate-a-group-access-token).
+
 ## Deploy tokens
 
 [Deploy tokens](../user/project/deploy_tokens/index.md) allow you to download (`git clone`) or push and pull packages and container registry images of a project without having a user and a password. Deploy tokens cannot be used with the GitLab API.
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index 9ac799610bb..25937993c16 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -29,8 +29,9 @@ cannot leave the 2FA configuration area at `/-/profile/two_factor_auth`.
 
 To enable 2FA for all users:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > General**.
 1. Expand the **Sign-in restrictions** section, where you can configure both.
 
 If you want 2FA enforcement to take effect during the next sign-in attempt,
@@ -55,8 +56,8 @@ Prerequisites:
 
 To enforce 2FA only for certain groups:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand **Permissions and group features**.
 1. Select **All users in this group must set up two-factor authentication**.
 1. Select **Save changes**.
diff --git a/doc/security/unlock_user.md b/doc/security/unlock_user.md
index 279f466e106..e8215616e1b 100644
--- a/doc/security/unlock_user.md
+++ b/doc/security/unlock_user.md
@@ -7,14 +7,26 @@ type: howto
 
 # Locked users **(FREE SELF)**
 
+## Self-managed users
+
 Users are locked after ten failed sign-in attempts. These users remain locked:
 
 - For 10 minutes, after which time they are automatically unlocked.
 - Until an administrator unlocks them from the [Admin Area](../user/admin_area/index.md) or the command line in under 10 minutes.
 
+## GitLab.com users
+
+If 2FA is not enabled users are locked after three failed sign-in attempts within 24 hours. These users remain locked until:
+
+- Their next successful sign-in, at which point they are sent an email with a six-digit unlock code and redirected to a verification page where they can unlock their account by entering the code.
+- GitLab Support [manually unlock](https://about.gitlab.com/handbook/support/workflows/reinstating-blocked-accounts.html#manual-unlock) the account after account ownership is verified.
+
+If 2FA is enabled, users are locked after five failed sign-in attempts within 10 minutes. Accounts are unlocked automatically after 10 minutes.
+
 ## Unlock a user from the Admin Area
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Overview > Users**.
 1. Use the search bar to find the locked user.
 1. From the **User administration** dropdown list, select **Unlock**.
diff --git a/doc/security/user_email_confirmation.md b/doc/security/user_email_confirmation.md
index 962f6f0fd61..f2c0052c2b8 100644
--- a/doc/security/user_email_confirmation.md
+++ b/doc/security/user_email_confirmation.md
@@ -11,9 +11,10 @@ GitLab can be configured to require confirmation of a user's email address when
 the user signs up. When this setting is enabled, the user is unable to sign in until
 they confirm their email address.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
-1. Expand the **Sign-up restrictions** section and look for the **Email confirmation settings** options.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Sign-up restrictions** and look for the **Email confirmation settings** options.
 
 ## Confirmation token expiry
 
diff --git a/doc/security/user_file_uploads.md b/doc/security/user_file_uploads.md
index 498245c4efb..5895eda8cdd 100644
--- a/doc/security/user_file_uploads.md
+++ b/doc/security/user_file_uploads.md
@@ -47,8 +47,8 @@ Prerequisite:
 
 To configure authentication settings for all media files:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. Scroll to **Project visibility** and select **Require authentication to view media files**.
 
diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md
index 774bfa106f6..13b34d28614 100644
--- a/doc/security/webhooks.md
+++ b/doc/security/webhooks.md
@@ -50,7 +50,8 @@ To prevent exploitation of insecure internal web services, all webhook and integ
 
 To allow access to these addresses:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Network**.
 1. Expand **Outbound requests**.
 1. Select the **Allow requests to the local network from webhooks and integrations** checkbox.
@@ -63,7 +64,8 @@ Prerequisite:
 
 [System hooks](../administration/system_hooks.md) can make requests to the local network by default. To prevent system hook requests to the local network:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Network**.
 1. Expand **Outbound requests**.
 1. Clear the **Allow requests to the local network from system hooks** checkbox.
@@ -78,7 +80,8 @@ Prerequisite:
 
 To filter requests by blocking many requests:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Network**.
 1. Expand **Outbound requests**.
 1. Select the **Block all requests, except for IP addresses, IP ranges, and domain names defined in the allowlist** checkbox.
@@ -103,7 +106,8 @@ Prerequisite:
 
 To allow outbound requests to certain IP addresses and domains:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > Network**.
 1. Expand **Outbound requests**.
 1. In **Local IP addresses and domain names that hooks and integrations can access**, enter your IP addresses and domains.
diff --git a/doc/subscriptions/bronze_starter.md b/doc/subscriptions/bronze_starter.md
index b076987c0ae..b981a63a8b7 100644
--- a/doc/subscriptions/bronze_starter.md
+++ b/doc/subscriptions/bronze_starter.md
@@ -96,7 +96,7 @@ the tiers are no longer mentioned in GitLab documentation:
     - [Mirror with Perforce Helix with Git Fusion](../user/project/repository/mirror/bidirectional.md#mirror-with-perforce-helix-with-git-fusion)
 - Runners:
   - Run pipelines in the parent project [for merge requests from a forked project](../ci/pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project)
-  - [Shared runners CI/CD minutes](../ci/pipelines/cicd_minutes.md)
+  - [Shared runners compute quota](../ci/pipelines/cicd_minutes.md)
 - [Push rules](../user/project/repository/push_rules.md)
 - SAML for self-managed GitLab instance:
   - [Administrator groups](../integration/saml.md#administrator-groups)
diff --git a/doc/subscriptions/community_programs.md b/doc/subscriptions/community_programs.md
index 36a5788a3fa..5e11292a084 100644
--- a/doc/subscriptions/community_programs.md
+++ b/doc/subscriptions/community_programs.md
@@ -10,11 +10,11 @@ GitLab provides the following community program subscriptions.
 
 ## GitLab for Education
 
-For qualifying non-profit educational institutions, the [GitLab for Education Program](https://about.gitlab.com/solutions/education/) provides GitLab Ultimate, plus 50,000 CI/CD minutes per month. The subscription granted under GitLab for Education can only be used for instructional use or non-commercial academic research. For more information—including instructions for applying to the program and renewing program membership—see the [GitLab for Education Program page](https://about.gitlab.com/solutions/education/) and the [GitLab handbook](https://about.gitlab.com/handbook/marketing/community-relations/community-programs/education-program/).
+For qualifying non-profit educational institutions, the [GitLab for Education Program](https://about.gitlab.com/solutions/education/) provides GitLab Ultimate, plus 50,000 units of compute per month. The subscription granted under GitLab for Education can only be used for instructional use or non-commercial academic research. For more information—including instructions for applying to the program and renewing program membership—see the [GitLab for Education Program page](https://about.gitlab.com/solutions/education/) and the [GitLab handbook](https://about.gitlab.com/handbook/marketing/community-relations/community-programs/education-program/).
 
 ## GitLab for Open Source
 
-For qualifying open source projects, the [GitLab for Open Source Program](https://about.gitlab.com/solutions/open-source/) provides GitLab Ultimate, plus 50,000 CI/CD minutes per month. For more information—including instructions for applying to the program and renewing program membership—see the [GitLab for Open Source Program page](https://about.gitlab.com/solutions/open-source/) and the [GitLab handbook](https://about.gitlab.com/handbook/marketing/community-relations/community-programs/opensource-program/).
+For qualifying open source projects, the [GitLab for Open Source Program](https://about.gitlab.com/solutions/open-source/) provides GitLab Ultimate, plus 50,000 units of compute per month. For more information—including instructions for applying to the program and renewing program membership—see the [GitLab for Open Source Program page](https://about.gitlab.com/solutions/open-source/) and the [GitLab handbook](https://about.gitlab.com/handbook/marketing/community-relations/community-programs/opensource-program/).
 
 ### Meeting GitLab for Open Source Program requirements
 
@@ -22,7 +22,7 @@ To meet GitLab for Open Source Program requirements, first add an OSI-approved o
 
 To add a license to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. On the overview page, select **Add LICENSE**. If the license you want is not available as a license template, manually copy the entire, unaltered [text of your chosen license](https://opensource.org/licenses/) into the `LICENSE` file. GitLab defaults to **All rights reserved** if users do not perform this action.
 
 ![Add license](img/add-license.png)
@@ -45,7 +45,7 @@ Benefits of the GitLab Open Source Program apply to all projects in a GitLab nam
 
 #### Screenshot 1: License overview
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. On the left sidebar, select your project avatar. If you haven't specified an avatar for your project, the avatar displays as a single letter.
 1. Take a screenshot of the project overview that clearly displays the license you've chosen for your project.
 
@@ -53,8 +53,8 @@ Benefits of the GitLab Open Source Program apply to all projects in a GitLab nam
 
 #### Screenshot 2: License contents
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository** and locate the project's `LICENSE` file.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1.Select **Code > Repository** and locate the project's `LICENSE` file.
 1. Take a screenshot of the contents of the file. Make sure the screenshot includes the title of the license.
 
 ![License file](img/license-file.png)
@@ -63,8 +63,8 @@ Benefits of the GitLab Open Source Program apply to all projects in a GitLab nam
 
 To be eligible for the GitLab Open Source Program, projects must be publicly visible. To check your project's public visibility settings:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. From the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. From the **Project visibility** dropdown list, select **Public**.
 1. Select the **Users can request access** checkbox.
@@ -77,4 +77,4 @@ Exceptions to this public visibility requirement apply in select circumstances (
 
 ## GitLab for Startups
 
-For qualifying startups, the [GitLab for Startups](https://about.gitlab.com/solutions/startups/) program provides GitLab Ultimate, plus 50,000 CI/CD minutes per month for 12 months. For more information—including instructions for applying to the program and renewing program membership—see the [GitLab for Startups Program page](https://about.gitlab.com/solutions/startups/) and the [GitLab handbook](https://about.gitlab.com/handbook/marketing/community-relations/community-programs/startups-program/).
+For qualifying startups, the [GitLab for Startups](https://about.gitlab.com/solutions/startups/) program provides GitLab Ultimate, plus 50,000 units of compute per month for 12 months. For more information—including instructions for applying to the program and renewing program membership—see the [GitLab for Startups Program page](https://about.gitlab.com/solutions/startups/) and the [GitLab handbook](https://about.gitlab.com/handbook/marketing/community-relations/community-programs/startups-program/).
diff --git a/doc/subscriptions/gitlab_com/index.md b/doc/subscriptions/gitlab_com/index.md
index ff93d1c903a..28eff9032f0 100644
--- a/doc/subscriptions/gitlab_com/index.md
+++ b/doc/subscriptions/gitlab_com/index.md
@@ -16,7 +16,7 @@ You don't need to install anything to use GitLab SaaS, you only need to
 
 The subscription determines which features are available for your private projects. Organizations with public open source projects can actively apply to our [GitLab for Open Source Program](https://about.gitlab.com/solutions/open-source/join/).
 
-Qualifying open source projects also get 50,000 CI/CD minutes and free access to the **Ultimate** tier
+Qualifying open source projects also get 50,000 units of compute and free access to the **Ultimate** tier
 through the [GitLab for Open Source program](https://about.gitlab.com/solutions/open-source/).
 
 ## Obtain a GitLab SaaS subscription
@@ -33,9 +33,9 @@ To subscribe to GitLab SaaS:
    and decide which tier you want.
 1. Create a user account for yourself by using the
    [sign up page](https://gitlab.com/users/sign_up).
-1. Create a [group](../../user/group/manage.md#create-a-group). Your subscription tier applies to the top-level group, its subgroups, and projects.
+1. Create a [group](../../user/group/index.md#create-a-group). Your subscription tier applies to the top-level group, its subgroups, and projects.
 1. Create additional users and
-   [add them to the group](../../user/group/manage.md#add-users-to-a-group). The users in this group, its subgroups, and projects can use
+   [add them to the group](../../user/group/index.md#add-users-to-a-group). The users in this group, its subgroups, and projects can use
    the features of your subscription tier, and they consume a seat in your subscription.
 1. On the left sidebar, select **Settings > Billing** and choose a tier.
 1. Fill out the form to complete your purchase.
@@ -48,8 +48,8 @@ Prerequisite:
 
 To see the status of your GitLab SaaS subscription:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Billing**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Billing**.
 
 The following information is displayed:
 
@@ -99,8 +99,8 @@ In this case, they would see only the features available to that subscription.
 
 To view a list of seats being used:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Usage Quotas**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Usage Quotas**.
 1. On the **Seats** tab, view usage information.
 
 The data in seat usage listing, **Seats in use**, and **Seats in subscription** are updated live.
@@ -108,8 +108,8 @@ The counts for **Max seats used** and **Seats owed** are updated once per day.
 
 To view your subscription information and a summary of seat counts:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Billing**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Billing**.
 
 The usage statistics are updated once per day, which may cause
 a difference between the information in the **Usage Quotas** page and the **Billing page**.
@@ -136,8 +136,8 @@ For example:
 
 To export seat usage data as a CSV file:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Billing**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Billing**.
 1. Under **Seats currently in use**, select **See usage**.
 1. Select **Export list**.
 
@@ -197,8 +197,8 @@ The following is emailed to you:
 
 To remove a billable user from your subscription:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Billing**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Billing**.
 1. In the **Seats currently in use** section, select **See usage**.
 1. In the row for the user you want to remove, on the right side, select the ellipsis and **Remove user**.
 1. Re-type the username and select **Remove user**.
@@ -355,18 +355,18 @@ To change the contacts:
    [these requirements](https://about.gitlab.com/handbook/support/license-and-renewals/workflows/customersdot/associating_purchases.html).
 1. [Create a ticket with the Support team](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000071293). Include any relevant material in your request.
 
-## CI/CD minutes
+## Compute
 
-CI/CD minutes are the execution time for your [pipelines](../../ci/pipelines/index.md)
+Compute is the resource consumed when running [pipelines](../../ci/pipelines/index.md)
 on GitLab shared runners.
 
-Refer to [CI/CD minutes](../../ci/pipelines/cicd_minutes.md)
+Refer to [Compute usage](../../ci/pipelines/cicd_minutes.md)
 for more information.
 
-### Purchase additional CI/CD minutes
+### Purchase additional units of compute
 
-You can [purchase additional minutes](../../ci/pipelines/cicd_minutes.md#purchase-additional-cicd-minutes)
-for your personal or group namespace. CI/CD minutes are a **one-time purchase**, so they do not renew.
+You can [purchase additional units of compute](../../ci/pipelines/cicd_minutes.md#purchase-additional-units-of-compute)
+for your personal or group namespace. Units of compute are a **one-time purchase**, so they do not renew.
 
 ## Add-on subscription for additional Storage and Transfer
 
@@ -424,8 +424,8 @@ main quota. You can find pricing for additional storage on the
 
 To purchase additional storage for your group on GitLab SaaS:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Usage Quotas**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Usage Quotas**.
 1. Select **Storage** tab.
 1. Select **Purchase more storage**.
 1. Complete the details.
diff --git a/doc/subscriptions/gitlab_dedicated/index.md b/doc/subscriptions/gitlab_dedicated/index.md
index 0c2b6375d7a..f14f38f4717 100644
--- a/doc/subscriptions/gitlab_dedicated/index.md
+++ b/doc/subscriptions/gitlab_dedicated/index.md
@@ -6,9 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # GitLab Dedicated
 
-NOTE:
-GitLab Dedicated is currently in limited availability. You can learn more and join the waitlist [on our website](https://about.gitlab.com/single-tenant-saas).
-
 GitLab Dedicated is a fully isolated, single-tenant SaaS service that is:
 
 - Hosted and managed by GitLab, Inc.
@@ -164,6 +161,6 @@ The following AWS regions are not available:
 For more information about the planned improvements to GitLab Dedicated,
 see the [category direction page](https://about.gitlab.com/direction/saas-platforms/dedicated/).
 
-## Join the GitLab Dedicated waitlist
+## Interested in GitLab Dedicated?
 
-As we scale this new offering, we are making GitLab Dedicated available by inviting customers to [join our waitlist](https://about.gitlab.com/dedicated/).
+Learn more about GitLab Dedicated and [talk to an expert](https://about.gitlab.com/dedicated/).
diff --git a/doc/subscriptions/index.md b/doc/subscriptions/index.md
index 9f329700c74..0b78704bb4d 100644
--- a/doc/subscriptions/index.md
+++ b/doc/subscriptions/index.md
@@ -18,5 +18,5 @@ Choose and manage the subscription that's right for you and your organization.
 - [Customers Portal](customers_portal.md)
 - [Quarterly reconciliation](quarterly_reconciliation.md)
 - [Storage usage quota](../user/usage_quotas.md)
-- [CI/CD minutes quota](../ci/pipelines/cicd_minutes.md)
+- [Compute quota](../ci/pipelines/cicd_minutes.md)
 - [Features available to Starter and Bronze subscribers](../subscriptions/bronze_starter.md)
diff --git a/doc/subscriptions/self_managed/index.md b/doc/subscriptions/self_managed/index.md
index ece1484b107..d6e21c3683b 100644
--- a/doc/subscriptions/self_managed/index.md
+++ b/doc/subscriptions/self_managed/index.md
@@ -36,8 +36,9 @@ Prorated charges are not possible without a quarterly usage report.
 
 You can view users for your license and determine if you've gone over your subscription.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left menu, select **Subscription**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Users**.
 
 The lists of users are displayed.
 
@@ -216,8 +217,9 @@ Example of a license sync request:
 
 You can manually synchronize your subscription details at any time.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Subscription**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Subscription**.
 1. In the **Subscription details** section, select **Sync subscription details**.
 
 A job is queued. When the job finishes, the subscription details are updated.
@@ -226,8 +228,9 @@ A job is queued. When the job finishes, the subscription details are updated.
 
 If you are an administrator, you can view the status of your subscription:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Subscription**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Subscription**.
 
 The **Subscription** page includes the following details:
 
@@ -250,8 +253,9 @@ It also displays the following information:
 
 If you are an administrator, you can export your license usage into a CSV:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Subscription**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Subscription**.
 1. In the upper-right corner, select **Export license usage file**.
 
 This file contains the information GitLab uses to manually process quarterly reconciliations or renewals. If your instance is firewalled or an offline environment, you must provide GitLab with this information.
diff --git a/doc/topics/autodevops/cicd_variables.md b/doc/topics/autodevops/cicd_variables.md
index 529f449e452..dff36727bf2 100644
--- a/doc/topics/autodevops/cicd_variables.md
+++ b/doc/topics/autodevops/cicd_variables.md
@@ -136,8 +136,8 @@ Prerequisite:
 
 To configure secret variables:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Variables**.
 1. Create a CI/CD variable with the prefix `K8S_SECRET_`. For example, you
    can create a variable called `K8S_SECRET_RAILS_MASTER_KEY`.
diff --git a/doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md b/doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md
index 0d865b5cf0d..af396e159da 100644
--- a/doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md
+++ b/doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md
@@ -13,8 +13,8 @@ You can choose to target AWS ECS as a deployment platform instead of using Kuber
 To get started on Auto DevOps to AWS ECS, you must add a specific CI/CD variable.
 To do so, follow these steps:
 
-1. In GitLab, on the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Auto DevOps**.
 1. Specify which AWS platform to target during the Auto DevOps deployment
    by adding the `AUTO_DEVOPS_PLATFORM_TARGET` variable with one of the following values:
diff --git a/doc/topics/autodevops/cloud_deployments/auto_devops_with_eks.md b/doc/topics/autodevops/cloud_deployments/auto_devops_with_eks.md
index 32a47bb790b..6348e3a5fa0 100644
--- a/doc/topics/autodevops/cloud_deployments/auto_devops_with_eks.md
+++ b/doc/topics/autodevops/cloud_deployments/auto_devops_with_eks.md
@@ -48,8 +48,7 @@ those projects provide a bare-bones application built on some well-known framewo
 WARNING:
 Create the application project in the group hierarchy at the same level or below the project for cluster management. Otherwise, it fails to [authorize the agent](../../../user/clusters/agent/ci_cd_workflow.md#authorize-the-agent).
 
-1. On the top bar in GitLab, select the plus icon (**{plus-square}**), and select
-   **New project/repository**.
+1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New project/repository**.
 1. Select **Create from template**.
 1. Select the **Ruby on Rails** template.
 1. Give your project a name, optionally a description, and make it public so that
@@ -133,8 +132,8 @@ While Auto DevOps is enabled by default, Auto DevOps can be disabled at both
 the instance level (for self-managed instances) and the group level. Complete
 these steps to enable Auto DevOps if it's disabled:
 
-1. On the top bar, select **Main menu > Projects** and find the application project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the application project.
+1. Select **Settings > CI/CD**.
 1. Expand **Auto DevOps**.
 1. Select **Default to Auto DevOps pipeline** to display more options.
 1. In **Deployment strategy**, select your desired [continuous deployment strategy](../requirements.md#auto-devops-deployment-strategy)
diff --git a/doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md b/doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md
index 1a03a66d17a..dac85926ff5 100644
--- a/doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md
+++ b/doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md
@@ -62,8 +62,7 @@ those projects provide a bare-bones application built on some well-known framewo
 WARNING:
 Create the application project in the group hierarchy at the same level or below the project for cluster management. Otherwise, it fails to [authorize the agent](../../../user/clusters/agent/ci_cd_workflow.md#authorize-the-agent).
 
-1. On the top bar in GitLab, select the plus icon (**{plus-square}**), and select
-   **New project/repository**.
+1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New project/repository**.
 1. Select **Create from template**.
 1. Select the **Ruby on Rails** template.
 1. Give your project a name, optionally a description, and make it public so that
@@ -137,8 +136,8 @@ While Auto DevOps is enabled by default, Auto DevOps can be disabled at both
 the instance level (for self-managed instances) and the group level. Complete
 these steps to enable Auto DevOps if it's disabled:
 
-1. On the top bar, select **Main menu > Projects** and find the application project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the application project.
+1. Select **Settings > CI/CD**.
 1. Expand **Auto DevOps**.
 1. Select **Default to Auto DevOps pipeline** to display more options.
 1. In **Deployment strategy**, select your desired [continuous deployment strategy](../requirements.md#auto-devops-deployment-strategy)
diff --git a/doc/topics/autodevops/img/auto_monitoring.png b/doc/topics/autodevops/img/auto_monitoring.png
deleted file mode 100644
index 2900e5d1877..00000000000
--- a/doc/topics/autodevops/img/auto_monitoring.png
+++ /dev/null
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index 87810193a8d..10979f0bb21 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -40,7 +40,6 @@ Auto DevOps supports development during each of the [DevOps stages](stages.md).
 | Test | [Auto License Compliance](stages.md#auto-license-compliance) |
 | Deploy | [Auto Review Apps](stages.md#auto-review-apps) |
 | Deploy | [Auto Deploy](stages.md#auto-deploy) |
-| Monitor | [Auto Monitoring](stages.md#auto-monitoring) |
 | Secure | [Auto Dynamic Application Security Testing (DAST)](stages.md#auto-dast) |
 | Secure | [Auto Static Application Security Testing (SAST)](stages.md#auto-sast) |
 | Secure | [Auto Secret Detection](stages.md#auto-secret-detection) |
@@ -102,8 +101,8 @@ Prerequisites:
 
 To enable Auto DevOps for a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Auto DevOps**.
 1. Select the **Default to Auto DevOps pipeline** checkbox.
 1. Optional but recommended. Add the [base domain](requirements.md#auto-devops-base-domain).
@@ -133,8 +132,8 @@ Prerequisites:
 
 To enable Auto DevOps for a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > CI/CD**.
 1. Expand **Auto DevOps**.
 1. Select the **Default to Auto DevOps pipeline** checkbox.
 1. Select **Save changes**.
@@ -145,9 +144,9 @@ clear the **Default to Auto DevOps pipeline** checkbox.
 After enabling Auto DevOps at the group level, you can trigger the
 Auto DevOps pipeline for any project that belongs to that group:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Make sure the project doesn't contain a `.gitlab-ci.yml` file.
-1. On the left sidebar, select **CI/CD > Pipelines**.
+1. Select **Build > Pipelines**.
 1. To trigger the Auto DevOps pipeline, select **Run pipeline**.
 
 #### At the instance level **(FREE SELF)**
@@ -165,8 +164,9 @@ Prerequisites:
 
 To enable Auto DevOps for your instance:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand **Auto DevOps**.
 1. Select the **Default to Auto DevOps pipeline** checkbox.
 1. Optional. Add the Auto DevOps [base domain](requirements.md#auto-devops-base-domain).
diff --git a/doc/topics/autodevops/prepare_deployment.md b/doc/topics/autodevops/prepare_deployment.md
index 6f434e8fb84..b71beee708e 100644
--- a/doc/topics/autodevops/prepare_deployment.md
+++ b/doc/topics/autodevops/prepare_deployment.md
@@ -37,8 +37,7 @@ to minimize downtime and risk.
 ## Auto DevOps base domain
 
 The Auto DevOps base domain is required to use
-[Auto Review Apps](stages.md#auto-review-apps), [Auto Deploy](stages.md#auto-deploy), and
-[Auto Monitoring](stages.md#auto-monitoring).
+[Auto Review Apps](stages.md#auto-review-apps) and [Auto Deploy](stages.md#auto-deploy).
 
 To define the base domain, either:
 
diff --git a/doc/topics/autodevops/requirements.md b/doc/topics/autodevops/requirements.md
index dc126edf1aa..dd73a2056e5 100644
--- a/doc/topics/autodevops/requirements.md
+++ b/doc/topics/autodevops/requirements.md
@@ -41,8 +41,8 @@ that works best for your needs:
 
 You can choose the deployment method when enabling Auto DevOps or later:
 
-1. In GitLab, on the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **Auto DevOps**.
 1. Choose the deployment strategy.
 1. Select **Save changes**.
@@ -54,8 +54,7 @@ to minimize downtime and risk.
 ## Auto DevOps base domain
 
 The Auto DevOps base domain is required to use
-[Auto Review Apps](stages.md#auto-review-apps), [Auto Deploy](stages.md#auto-deploy), and
-[Auto Monitoring](stages.md#auto-monitoring).
+[Auto Review Apps](stages.md#auto-review-apps) and [Auto Deploy](stages.md#auto-deploy).
 
 To define the base domain, either:
 
@@ -91,8 +90,8 @@ to the Kubernetes pods running your application.
 
 To make full use of Auto DevOps with Kubernetes, you need:
 
-- **Kubernetes** (for [Auto Review Apps](stages.md#auto-review-apps),
-  [Auto Deploy](stages.md#auto-deploy), and [Auto Monitoring](stages.md#auto-monitoring))
+- **Kubernetes** (for [Auto Review Apps](stages.md#auto-review-apps) and
+  [Auto Deploy](stages.md#auto-deploy))
 
   To enable deployments, you need:
 
@@ -117,8 +116,8 @@ To make full use of Auto DevOps with Kubernetes, you need:
      If your cluster is installed on bare metal, see
      [Auto DevOps Requirements for bare metal](#auto-devops-requirements-for-bare-metal).
 
-- **Base domain** (for [Auto Review Apps](stages.md#auto-review-apps),
-  [Auto Deploy](stages.md#auto-deploy), and [Auto Monitoring](stages.md#auto-monitoring))
+- **Base domain** (for [Auto Review Apps](stages.md#auto-review-apps) and
+  [Auto Deploy](stages.md#auto-deploy))
 
   You must [specify the Auto DevOps base domain](#auto-devops-base-domain),
   which all of your Auto DevOps applications use. This domain must be configured
@@ -148,8 +147,8 @@ To make full use of Auto DevOps with Kubernetes, you need:
   certificates are valid and up-to-date.
 
 If you don't have Kubernetes or Prometheus configured, then
-[Auto Review Apps](stages.md#auto-review-apps),
-[Auto Deploy](stages.md#auto-deploy), and [Auto Monitoring](stages.md#auto-monitoring)
+[Auto Review Apps](stages.md#auto-review-apps) and
+[Auto Deploy](stages.md#auto-deploy)
 are skipped.
 
 After all requirements are met, you can [enable Auto DevOps](index.md#enable-or-disable-auto-devops).
diff --git a/doc/topics/autodevops/stages.md b/doc/topics/autodevops/stages.md
index c95426b03e6..6be8a71cdbc 100644
--- a/doc/topics/autodevops/stages.md
+++ b/doc/topics/autodevops/stages.md
@@ -591,32 +591,14 @@ When using Cloud Native Buildpacks, instead of `/bin/herokuish procfile exec`, u
 /cnb/lifecycle/launcher $COMMAND
 ```
 
-## Auto Monitoring
+<!--- start_remove The following content will be removed on remove_date: '2023-09-22' -->
 
-After your application deploys, Auto Monitoring helps you monitor
-your application's server and response metrics right out of the box. Auto
-Monitoring uses [Prometheus](../../user/project/integrations/prometheus.md) to
-retrieve system metrics, such as CPU and memory usage, directly from
-[Kubernetes](../../user/project/integrations/prometheus_library/kubernetes.md),
-and response metrics, such as HTTP error rates, latency, and throughput, from the
-[NGINX server](../../user/project/integrations/prometheus_library/nginx_ingress.md).
+### Auto Monitoring (removed)
 
-The metrics include:
+This feature was [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/10107) in GitLab 14.7
+and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/399231) in 16.0.
 
-- **Response Metrics:** latency, throughput, error rate
-- **System Metrics:** CPU utilization, memory utilization
-
-To use Auto Monitoring:
-
-1. [Install and configure the Auto DevOps requirements](requirements.md).
-1. [Enable Auto DevOps](index.md#enable-or-disable-auto-devops), if you haven't done already.
-1. On the left sidebar, select **CI/CD > Pipelines**.
-1. Select **Run pipeline**.
-1. After the pipeline finishes successfully, open the
-   [monitoring dashboard for a deployed environment](../../ci/environments/index.md#monitor-environments)
-   to view the metrics of your deployed application.
-
-![Auto Metrics](img/auto_monitoring.png)
+<!--- end_remove -->
 
 ## Auto Code Intelligence
 
diff --git a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
index 0c31ccbfe32..3426f8dad42 100644
--- a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
+++ b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
@@ -179,7 +179,7 @@ used the `v0.17.0` chart, add `AUTO_DEVOPS_FORCE_DEPLOY_V2`.
 
 ## Early adopters
 
-If you want to use the latest [Beta](../../policy/alpha-beta-support.md#beta) or unstable version of `auto-deploy-image`, include
+If you want to use the latest [Beta](../../policy/experiment-beta-support.md#beta) or unstable version of `auto-deploy-image`, include
 the latest Auto Deploy template into your `.gitlab-ci.yml`:
 
 ```yaml
@@ -189,7 +189,7 @@ include:
 ```
 
 WARNING:
-Using a [Beta](../../policy/alpha-beta-support.md#beta) or unstable `auto-deploy-image` could cause unrecoverable damage to
+Using a [Beta](../../policy/experiment-beta-support.md#beta) or unstable `auto-deploy-image` could cause unrecoverable damage to
 your environments. Do not test it with important projects or environments.
 
 The next stable template update is [planned for GitLab v14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/232788).
diff --git a/doc/topics/git/bisect.md b/doc/topics/git/bisect.md
deleted file mode 100644
index eaf619ce36f..00000000000
--- a/doc/topics/git/bisect.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: 'index.md'
-remove_date: '2023-06-09'
----
-
-This document was moved to [another location](index.md).
-
-<!-- This redirect file can be deleted after <2023-06-09>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/topics/git/feature_branching.md b/doc/topics/git/feature_branching.md
deleted file mode 100644
index eaf619ce36f..00000000000
--- a/doc/topics/git/feature_branching.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: 'index.md'
-remove_date: '2023-06-09'
----
-
-This document was moved to [another location](index.md).
-
-<!-- This redirect file can be deleted after <2023-06-09>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/topics/git/git_log.md b/doc/topics/git/git_log.md
deleted file mode 100644
index eaf619ce36f..00000000000
--- a/doc/topics/git/git_log.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: 'index.md'
-remove_date: '2023-06-09'
----
-
-This document was moved to [another location](index.md).
-
-<!-- This redirect file can be deleted after <2023-06-09>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/topics/git/lfs/img/lfs-icon.png b/doc/topics/git/lfs/img/lfs-icon.png
deleted file mode 100644
index eef9a14187a..00000000000
--- a/doc/topics/git/lfs/img/lfs-icon.png
+++ /dev/null
diff --git a/doc/topics/git/lfs/img/lfs_badge_v16_0.png b/doc/topics/git/lfs/img/lfs_badge_v16_0.png
new file mode 100644
index 00000000000..d78da8b5f02
--- /dev/null
+++ b/doc/topics/git/lfs/img/lfs_badge_v16_0.png
diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md
index 4f0d1bfc5e6..5f3458821dd 100644
--- a/doc/topics/git/lfs/index.md
+++ b/doc/topics/git/lfs/index.md
@@ -11,25 +11,37 @@ Managing large files such as audio, video and graphics files has always been one
 of the shortcomings of Git. The general recommendation is to not have Git repositories
 larger than 1 GB to preserve performance.
 
-![Git LFS tracking status](img/lfs-icon.png)
+Your Git LFS client communicates with the GitLab server over HTTPS. It uses HTTP Basic authentication
+to authorize client requests. After the request is authorized, Git LFS client receives
+instructions on where to fetch or where to push the large file.
 
-Files tracked by Git LFS display an icon to indicate if the file is stored as a
-blob or an LFS pointer.
+In the repository view, files tracked by Git LFS display an **LFS** badge next to the filename:
 
-## How it works
+![Git LFS tracking status](img/lfs_badge_v16_0.png)
 
-Git LFS client communicates with the GitLab server over HTTPS. It uses HTTP Basic Authentication
-to authorize client requests. After the request is authorized, Git LFS client receives
-instructions from where to fetch or where to push the large file.
+## Configure your GitLab server for Git LFS **(FREE SELF)**
+
+To install Git LFS on your self-managed GitLab server, see
+[GitLab Git Large File Storage (LFS) Administration](../../../administration/lfs/index.md).
+
+## Enable Git LFS for a project
+
+Prerequisites:
+
+- You must have at least the Developer role in the project.
 
-## GitLab server configuration
+To do this:
 
-Documentation for GitLab instance administrators is under [LFS administration doc](../../../administration/lfs/index.md).
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
+1. Expand the **Visibility, project features, permissions** section.
+1. Turn on the **Git Large File Storage (LFS)** toggle.
+1. Select **Save changes**.
 
-## Prerequisites
+## Install the Git LFS client locally
 
-- Git LFS must be [enabled in project settings](../../../user/project/settings/index.md#configure-project-visibility-features-and-permissions).
-- [Git LFS client](https://git-lfs.com/) version 1.0.1 or later must be installed.
+Install the [Git LFS client](https://github.com/git-lfs/git-lfs) appropriate for
+your operating system. GitLab requires version 1.0.1 or later of the Git LFS client.
 
 ## Known limitations
 
diff --git a/doc/topics/git/subtree.md b/doc/topics/git/subtree.md
deleted file mode 100644
index eaf619ce36f..00000000000
--- a/doc/topics/git/subtree.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: 'index.md'
-remove_date: '2023-06-09'
----
-
-This document was moved to [another location](index.md).
-
-<!-- This redirect file can be deleted after <2023-06-09>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/topics/git/tags.md b/doc/topics/git/tags.md
deleted file mode 100644
index c66c97717f2..00000000000
--- a/doc/topics/git/tags.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../../user/project/repository/tags/index.md'
-remove_date: '2023-05-27'
----
-
-This document was moved to [another location](../../user/project/repository/tags/index.md).
-
-<!-- This redirect file can be deleted after <2023-05-27>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md
index eb298841247..7dd35419c76 100644
--- a/doc/topics/gitlab_flow.md
+++ b/doc/topics/gitlab_flow.md
@@ -311,7 +311,7 @@ In GitLab Flow, you can configure your pipeline to run every time you commit cha
 When you are ready to merge your feature branch, assign the merge request to a maintainer for the project.
 Also, mention any other people from whom you would like feedback.
 After the assigned person feels comfortable with the result, they can merge the branch.
-In GitLab Flow, a [merged results pipeline](../ci/pipelines/merged_results_pipelines.md) runs against the results of the source and target branches merged together. 
+In GitLab Flow, a [merged results pipeline](../ci/pipelines/merged_results_pipelines.md) runs against the results of the source and target branches merged together.
 If the assigned person does not feel comfortable, they can request more changes or close the merge request without merging.
 
 NOTE:
@@ -444,7 +444,7 @@ However, as discussed in [the section about rebasing](#squashing-commits-with-re
 
 Rebasing could create more work, as every time you rebase, you may need to resolve the same conflicts.
 Sometimes you can reuse recorded resolutions (`rerere`), but merging is better, because you only have to resolve conflicts once.
-You can read a more thorough explanation of the tradeoffs between merging and rebasing [here](https://git-scm.com/book/en/v2/Git-Branching-Rebasing#:~:text=Final%20commit%20history-,The,-Perils%20of%20Rebasing).
+The Git documentation has a thorough explanation of the [tradeoffs between merging and rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing#:~:text=Final%20commit%20history-,The,-Perils%20of%20Rebasing).
 
 A good way to prevent creating many merge commits is to not frequently merge `main` into the feature branch.
 Three reasons to merge in `main`:
@@ -513,7 +513,7 @@ The words "change," "improve," "fix," and "refactor" don't add much information
 For more information, see Tim Pope's excellent [note about formatting commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
 
 To add more context to a commit message, consider adding information regarding the
-origin of the change, such the GitLab issue URL or Jira issue number. That way, you provide 
+origin of the change, such the GitLab issue URL or Jira issue number. That way, you provide
 more information for users who need in-depth context about the change.
 
 For example:
@@ -543,9 +543,17 @@ In GitLab Flow, your can include automated CI tests in your branch or merge requ
 
 ## Working with feature branches
 
-When creating a feature branch, always branch from an up-to-date `main`.
-If you know before you start that your work depends on another branch, you can also branch from there.
-If you need to merge in another branch after starting, explain the reason in the merge commit.
-If you have not pushed your commits to a shared location yet, you can also incorporate changes by rebasing on `main` or another feature branch.
-Do not merge from upstream again if your code can work and merge cleanly without doing so.
-Merging only when needed prevents creating merge commits in your feature branch that later end up littering the `main` history.
+Some tips for working with feature branches:
+
+- When you create a feature branch locally, always update your local copy of `main` before
+  branching off from it.
+- When creating a feature branch, always branch from `main` unless you know your work
+  depends on some other branch. For example, to create `feature-x-update`, branch from
+  `feature-x` instead of `main`.
+- If you merge in another branch after starting, explain the reason in the merge commit.
+- If you have not pushed your branch upstream yet, you can still pull in new changes
+  by rebasing your local feature branch against your local copy of its parent branch.
+- Do not merge recent changes from other branches into your local feature branch if your code
+  can work and merge cleanly without those extra changes. Each time you merge commits into your
+  feature branch, you add a merge commit to your feature branch. These merge commits
+  later end up littering the history in your `main` branch.
diff --git a/doc/topics/offline/quick_start_guide.md b/doc/topics/offline/quick_start_guide.md
index 57c7a80fa3e..e51e015dddf 100644
--- a/doc/topics/offline/quick_start_guide.md
+++ b/doc/topics/offline/quick_start_guide.md
@@ -4,7 +4,7 @@ group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Getting started with an offline GitLab Installation **(FREE SELF)**
+# Install an offline self-managed GitLab instance **(FREE SELF)**
 
 This is a step-by-step guide that helps you install, configure, and use a self-managed GitLab
 instance entirely offline.
diff --git a/doc/tutorials/agile_sprint/index.md b/doc/tutorials/agile_sprint/index.md
index 0ce100df65e..fe106af2dc2 100644
--- a/doc/tutorials/agile_sprint/index.md
+++ b/doc/tutorials/agile_sprint/index.md
@@ -23,7 +23,7 @@ After you've created these core components, you can begin running your iteration
 ## Create a group
 
 Iteration cadences are created at the group level, so start by
-[creating one](../../user/group/manage.md#create-a-group) if you don't have one already.
+[creating one](../../user/group/index.md#create-a-group) if you don't have one already.
 
 You use groups to manage one or more related projects at the same time.
 You add your users as members in the group, and assign them a role. Roles determine
diff --git a/doc/tutorials/boards_for_teams/img/frontend_board_empty_v16_0.png b/doc/tutorials/boards_for_teams/img/frontend_board_empty_v16_0.png
new file mode 100644
index 00000000000..6521da25754
--- /dev/null
+++ b/doc/tutorials/boards_for_teams/img/frontend_board_empty_v16_0.png
diff --git a/doc/tutorials/boards_for_teams/img/frontend_board_filled_v16_0.png b/doc/tutorials/boards_for_teams/img/frontend_board_filled_v16_0.png
new file mode 100644
index 00000000000..58f39fdfb10
--- /dev/null
+++ b/doc/tutorials/boards_for_teams/img/frontend_board_filled_v16_0.png
diff --git a/doc/tutorials/boards_for_teams/img/ux_board_empty_v16_0.png b/doc/tutorials/boards_for_teams/img/ux_board_empty_v16_0.png
new file mode 100644
index 00000000000..cfce3bf0743
--- /dev/null
+++ b/doc/tutorials/boards_for_teams/img/ux_board_empty_v16_0.png
diff --git a/doc/tutorials/boards_for_teams/img/ux_board_filled_v16_0.png b/doc/tutorials/boards_for_teams/img/ux_board_filled_v16_0.png
new file mode 100644
index 00000000000..c7c32fed841
--- /dev/null
+++ b/doc/tutorials/boards_for_teams/img/ux_board_filled_v16_0.png
diff --git a/doc/tutorials/boards_for_teams/index.md b/doc/tutorials/boards_for_teams/index.md
index e37bf5a2d31..4e0e50971d3 100644
--- a/doc/tutorials/boards_for_teams/index.md
+++ b/doc/tutorials/boards_for_teams/index.md
@@ -31,12 +31,9 @@ After you set up everything, the two teams will be able to hand off issues from
 1. A product designer on the UX team:
    1. Checks the `Workflow::Ready for design` list on the **UX workflow** board and decides to work on the profile page redesign.
 
-      <!-- Image: UX board with lists:
-            ~Workflow::Ready for design,
-            ~Workflow::Design
-            ~Workflow::Ready for development -->
+      ![Issue board called "UX workflow" with three columns and three issues](img/ux_board_filled_v16_0.png)
 
-   1. Assigns themselves to the issue.
+   1. Assigns themselves to the **Redesign user profile page** issue.
    1. Drags the issue card to the `Workflow::Design` list. The previous workflow label is automatically removed.
    1. Creates the ✨new designs✨.
    1. [Adds the designs to the issue](../../user/project/issues/design_management.md).
@@ -45,12 +42,9 @@ After you set up everything, the two teams will be able to hand off issues from
 1. A developer on the Frontend team:
    1. Checks the `Workflow::Ready for development` list on the **Frontend workflow** board and chooses an issue to work on.
 
-      <!-- Image: Frontend board, scoped to ~Frontend, with lists:
-            ~Workflow::Ready for development
-            ~Workflow::In development
-            ~Workflow::Complete -->
+      ![Issue board called "Frontend workflow" with three columns and three issues](img/frontend_board_filled_v16_0.png)
 
-   1. Assigns themselves to the issue.
+   1. Assigns themselves to the **Redesign user profile page** issue.
    1. Drags the issue card to the `Workflow::In development` list. The previous workflow label is automatically removed.
    1. Adds the frontend code in a [merge request](../../user/project/merge_requests/index.md).
    1. Adds the `Workflow::Complete` label.
@@ -68,7 +62,7 @@ Prerequisites:
 
 To create a group:
 
-1. On the top bar, select **Create new... > New group**.
+1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New group**.
 1. Select **Create group**.
 1. Complete the fields. Name your group `Paperclip Software Factory`.
 1. Select **Create group**.
@@ -104,8 +98,8 @@ projects you create later.
 
 To create each label:
 
-1. On the top bar, select **Main menu > Group** and find your **Paperclip Software Factory** group.
-1. On the left sidebar, select **Group information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your **Paperclip Software Factory** group.
+1. Select **Manage > Labels**.
 1. Select **New label**.
 1. In the **Title** field, enter the name of the label. Start with `Frontend`.
 1. Optional. Select a color by selecting from the available colors, or enter a hex color value for
@@ -129,8 +123,8 @@ to manage issues from all the projects that you might create later in this group
 
 To create a new group issue board:
 
-1. On the top bar, select **Main menu > Group** and find your **Paperclip Software Factory** group.
-1. On the left sidebar, select **Issues > Boards**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your **Paperclip Software Factory** group.
+1. Select **Plan > Issue boards**.
 1. Create the UX workflow and Frontend workflow boards.
 
 To create the **UX workflow** issue board:
@@ -140,15 +134,14 @@ To create the **UX workflow** issue board:
 1. In the **Title field**, enter `UX workflow`.
 1. Clear the **Show the Open list** and **Show the Closed list** checkboxes.
 1. Select **Create board**. You should see an empty board.
-
-   <!-- Image: empty UX workflow board -->
-
 1. Create a list for the `Workflow::Ready for design` label:
    1. In the upper-left corner of the issue board page, select **Create list**.
    1. In the column that appears, from the **Value** dropdown list, select the `Workflow::Ready for design` label.
    1. Select **Add to board**.
 1. Repeat the previous step for labels `Workflow::Design` and `Workflow::Ready for development`.
 
+![Issue board called "UX workflow" with three columns and no issues](img/ux_board_empty_v16_0.png)
+
 To create the **Frontend workflow** board:
 
 1. In the upper-left corner of the issue board page, select the dropdown list with the current board name.
@@ -164,6 +157,8 @@ To create the **Frontend workflow** board:
    1. Select **Add to board**.
 1. Repeat the previous step for labels `Workflow::In development` and `Workflow::Complete`.
 
+![Issue board called "Frontend workflow" with three columns and no issues](img/frontend_board_empty_v16_0.png)
+
 For now, lists in both your boards should be empty. Next, you'll populate them with some issues.
 
 ## Create issues for features
@@ -193,9 +188,9 @@ Repeat these steps to create a few more issues with the same labels.
 
 You should now see at least one issue there, ready for your product designers to start working on!
 
-<!-- Image: UX workflow board with at least one issue in the `Workflow::Ready for design` list -->
-
 Congratulations! Now your teams can start collaborating on amazing software.
+As a next step, you can try out [the goal workflow](#the-goal-workflow) for yourself using these boards,
+simulating the two teams interacting.
 
 ## Learn more about project management in GitLab
 
diff --git a/doc/tutorials/build_application.md b/doc/tutorials/build_application.md
index 2e0130e46ca..8e53f1ccc6b 100644
--- a/doc/tutorials/build_application.md
+++ b/doc/tutorials/build_application.md
@@ -4,7 +4,7 @@ group: Tutorials
 info: For assistance with this tutorials page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
 ---
 
-# Build your application
+# Tutorials: Build your application
 
 ## Learn about CI/CD pipelines
 
@@ -22,6 +22,14 @@ Use CI/CD pipelines to automatically build, test, and deploy your code.
 | <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [Understand CI/CD rules](https://www.youtube.com/watch?v=QjQc-zeL16Q) (8m 56s) |  Learn more about how to use CI/CD rules. | |
 | [Use Auto DevOps to deploy an application](../topics/autodevops/cloud_deployments/auto_devops_with_gke.md)  | Deploy an application to Google Kubernetes Engine (GKE). | |
 
+## Configure GitLab Runner
+
+Set up runners to run jobs in a pipeline.
+
+| Topic | Description | Good for beginners |
+|-------|-------------|--------------------|
+| [Configure GitLab Runner to use the Google Kubernetes Engine](configure_gitlab_runner_to_use_gke/index.md) | Learn how to configure GitLab Runner to use the GKE to run jobs. | |
+
 ## Publish a static website
 
 Use GitLab Pages to publish a static website directly from your project.
@@ -30,3 +38,4 @@ Use GitLab Pages to publish a static website directly from your project.
 |-------|-------------|--------------------|
 | [Create a Pages website from a CI/CD template](../user/project/pages/getting_started/pages_ci_cd_template.md) | Quickly generate a Pages website for your project using a CI/CD template for a popular Static Site Generator (SSG). | **{star}** |
 | [Create a Pages website from scratch](../user/project/pages/getting_started/pages_from_scratch.md) | Create all the components of a Pages website from a blank project. | |
+| [Build, test, and deploy your Hugo site with GitLab](/ee/tutorials/hugo/index.md) | Generate your Hugo site using a CI/CD template and GitLab Pages. | **{star}** |
diff --git a/doc/tutorials/compliance_pipeline/index.md b/doc/tutorials/compliance_pipeline/index.md
index 2dab7a7ecb1..9cf8148fe40 100644
--- a/doc/tutorials/compliance_pipeline/index.md
+++ b/doc/tutorials/compliance_pipeline/index.md
@@ -33,7 +33,7 @@ Compliance frameworks are configured in top-level groups. In this tutorial, you
 
 To create the new group:
 
-1. On the top bar, select **Create new... > New group**.
+1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New group**.
 1. Select **Create group**.
 1. In the **Group name** field, enter `Tutorial group`.
 1. Select **Create group**.
@@ -46,7 +46,7 @@ projects with the compliance framework applied.
 
 To create the compliance pipeline project:
 
-1. On the top bar, select **Main menu > Groups** and find the `Tutorial group` group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `Tutorial group` group.
 1. Select **New project**.
 1. Select **Create blank project**.
 1. In the **Project name** field, enter `Tutorial compliance project`.
@@ -54,8 +54,8 @@ To create the compliance pipeline project:
 
 To add compliance pipeline configuration to `Tutorial compliance project`:
 
-1. On the top bar, select **Main menu > Projects** and find the `Tutorial compliance project` project.
-1. On the left sidebar, select **CI/CD > Editor**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `Tutorial compliance project` project.
+1. Select **Build > Pipeline editor**.
 1. Select **Configure pipeline**.
 1. In the pipeline editor, replace the default configuration with:
 
@@ -74,8 +74,8 @@ The compliance framework is configured in the [new group](#create-a-new-group).
 
 To configure the compliance framework:
 
-1. On the top bar, select **Main menu > Groups** and find the `Tutorial group` group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `Tutorial group` group.
+1. Select **Settings > General**.
 1. Expand **Compliance frameworks**.
 1. Select **Add framework**.
 1. In the **Name** field, enter `Tutorial compliance framework`.
@@ -87,8 +87,8 @@ To configure the compliance framework:
 
 For convenience, make the new compliance framework the default for all new projects in the group:
 
-1. On the top bar, select **Main menu > Groups** and find the `Tutorial group` group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `Tutorial group` group.
+1. Select **Settings > General**.
 1. Expand **Compliance frameworks**.
 1. In the row for `Tutorial compliance framework`, select **Options** (**{ellipsis_v}**).
 1. Select **Set default**.
@@ -100,8 +100,8 @@ compliance pipeline configuration in their pipelines.
 
 To create a new project for running the compliance pipeline configuration:
 
-1. On the top bar, select **Main menu > Groups** and find the `Tutorial group` group.
-1. Select **New project**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `Tutorial group` group.
+1. Select **Create new** (**{plus}**) and **New project/repository**.
 1. Select **Create blank project**.
 1. In the **Project name** field, enter `Tutorial project`.
 1. Select **Create project**.
@@ -114,8 +114,8 @@ pipeline configuration in `Tutorial compliance project`.
 
 To run the compliance pipeline configuration in `Tutorial project`:
 
-1. On the top bar, select **Main menu > Projects** and find the `Tutorial project` project.
-1. Select **CI/CD Pipelines**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `Tutorial project` project.
+1. Select **Build > Pipelines**.
 1. Select **Run pipeline**.
 1. On the **Run pipeline** page, select **Run pipeline**.
 
@@ -132,8 +132,8 @@ compliance pipeline configuration to refer to it.
 
 To create the regular pipeline configuration:
 
-1. On the top bar, select **Main menu > Projects** and find the `Tutorial project` project.
-1. On the left sidebar, select **CI/CD > Editor**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `Tutorial project` project.
+1. Select **Build > Pipeline editor**.
 1. Select **Configure pipeline**.
 1. In the pipeline editor, replace the default configuration with:
 
@@ -148,8 +148,8 @@ To create the regular pipeline configuration:
 
 To combine the new project pipeline configuration with the compliance pipeline configuration:
 
-1. On the top bar, select **Main menu > Projects** and find the `Tutorial compliance project` project.
-1. On the left sidebar, select **CI/CD > Editor**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `Tutorial compliance project` project.
+1. Select **Build > Pipeline editor**.
 1. In the existing configuration, add:
 
    ```yaml
@@ -162,8 +162,8 @@ To combine the new project pipeline configuration with the compliance pipeline c
 
 To confirm the regular pipeline configuration is combined with the compliance pipeline configuration:
 
-1. On the top bar, select **Main menu > Projects** and find the `Tutorial project` project.
-1. Select **CI/CD Pipelines**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `Tutorial project` project.
+1. Select **Build > Pipelines**.
 1. Select **Run pipeline**.
 1. On the **Run pipeline** page, select **Run pipeline**.
 
diff --git a/doc/tutorials/configure_gitlab_runner_to_use_gke/index.md b/doc/tutorials/configure_gitlab_runner_to_use_gke/index.md
new file mode 100644
index 00000000000..e10c5d37ba0
--- /dev/null
+++ b/doc/tutorials/configure_gitlab_runner_to_use_gke/index.md
@@ -0,0 +1,202 @@
+---
+stage: Verify
+group: Runner
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Tutorial: Configure GitLab Runner to use the Google Kubernetes Engine **(FREE)**
+
+This tutorial describes how to configure GitLab Runner to use the Google Kubernetes Engine (GKE)
+to run jobs.
+
+In this tutorial, you configure GitLab Runner to run jobs in the following [GKE cluster modes](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters):
+
+- Autopilot
+- Standard
+
+To configure GitLab Runner to use the GKE:
+
+1. [Set up your environment](#set-up-your-environment).
+1. [Create and connect to a cluster](#create-and-connect-to-a-cluster).
+1. [Install and configure the Kubernetes Operator](#install-and-configure-the-kubernetes-operator).
+1. Optional. [Verify that the configuration was successful](#verify-your-configuration).
+
+## Prerequisites
+
+Before you can configure GitLab Runner to use the GKE you must:
+
+- Have a project where you have the Maintainer or Owner role. If you don't have a project, you can [create it](../../user/project/index.md).
+- [Obtain the project runner registration token](../../ci/runners/register_runner.md#generate-a-registration-token-deprecated).
+- Install GitLab Runner.
+
+## Set up your environment
+
+Install the tools to configure and use GitLab Runner in the GKE.
+
+1. [Install and configure Google Cloud CLI](https://cloud.google.com/sdk/docs/install). You use Google Cloud CLI to connect to the cluster.
+1. [Install and configure kubectl](https://kubernetes.io/docs/tasks/tools/). You use kubectl to communicate with the remote cluster from your local environment.
+
+## Create and connect to a cluster
+
+This step describes how to create a cluster and connect to it. After you connect to the cluster, you use kubectl to interact with it
+and, for autopilot clusters, to add configurations that specify which jobs to run.
+
+1. In the Google Cloud Platform, create an [autopilot](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-an-autopilot-cluster) or [standard](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-zonal-cluster) cluster.
+
+1. Install the kubectl authentication plugin:
+
+   ```shell
+   gcloud components install gke-gcloud-auth-plugin
+   ```
+
+1. Connect to the cluster:
+
+   ```shell
+   gcloud container clusters get-credentials CLUSTER_NAME --zone=CLUSTER_LOCATION
+   ```
+
+1. View the cluster configuration:
+
+   ```shell
+   kubectl config view
+   ```
+
+1. Verify that you are connected to the cluster:
+
+   ```shell
+   kubectl config view current-context
+   ```
+
+## Install and configure the Kubernetes Operator
+
+Now that you have a cluster, you're ready to install and configure the Kubernetes Operator.
+
+1. Install the prerequisites:
+
+   ```shell
+     kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.7.1/cert-manager.yaml
+   ```
+
+1. Install the Operator Lifecycle Manager (OLM), a tool that manages the Kubernetes Operators that
+   run on the cluster:
+
+   <!-- markdownlint-disable -->
+
+   ```shell
+   curl --silent --location "https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.24.0/install.sh" \
+    | bash -s v0.24.0
+   ```
+
+   <!-- markdownlint-enable -->
+
+1. Install the Kubernetes Operator Catalog:
+
+   ```shell
+   kubectl create -f https://raw.githubusercontent.com/operator-framework/operator-lifecycle-manager/master/deploy/upstream/quickstart/crds.yaml
+   kubectl create -f https://raw.githubusercontent.com/operator-framework/operator-lifecycle-manager/master/deploy/upstream/quickstart/olm.yaml
+   ```
+
+1. Install the Kubernetes Operator:
+
+   ```shell
+   kubectl create -f https://operatorhub.io/install/gitlab-runner-operator.yaml
+   ```
+
+1. Create a secret that contains the `runner-registration-token` from your
+   GitLab project:
+
+   ```shell
+    cat > gitlab-runner-secret.yml << EOF
+    apiVersion: v1
+    kind: Secret
+    metadata:
+      name: gitlab-runner-secret
+    type: Opaque
+    stringData:
+   runner-registration-token: YOUR_RUNNER_REGISTRATION_TOKEN
+   EOF
+   ```
+
+1. Apply the secret:
+
+   ```shell
+   kubectl apply -f gitlab-runner-secret.yml
+   ```
+
+1. For autopilot clusters, you must create a YAML file with additional
+   configuration details. Autopilot clusters use this file to instruct the
+   GKE about what resources the Pod needs so it can run the jobs. You don't
+   need to create this file for standard clusters. Here is an example configuration:
+
+   ```shell
+   cat > config.yml << EOF
+   apiVersion: v1
+   kind: configMaps
+   metadata:
+     name: config.toml
+   config: |
+   [[runners]]
+     [runners.kubernetes]
+       image = "alpine"
+       cpu_limit = "1"
+       memory_limit = "128Mi"
+       service_cpu_limit = "1"
+       service_memory_limit = "128Mi"
+       helper_cpu_limit = "500m"
+       helper_memory_limit = "100Mi"
+   ```
+
+1. Apply the `config.yml`:
+
+   ```shell
+   kubectl apply -f config.yml
+   ```
+
+1. Create the custom resource definition file and include the following information:
+
+   ```shell
+   cat > gitlab-runner.yml << EOF
+      apiVersion: apps.gitlab.com/v1beta2
+         kind: Runner
+         metadata:
+         name: gitlab-runner
+      spec:
+         gitlabUrl: https://gitlab.example.com
+         buildImage: alpine
+         config: "config.toml"  # <---- Reference to the config.toml configMap
+         token: gitlab-runner-secret
+      EOF
+   ```
+
+1. Apply the custom resource definition file:
+
+   ```shell
+   kubectl apply -f gitlab-runner.yml
+   ```
+
+That's it! You've configured GitLab Runner to use the GKE.
+In the next step, you can check if your configuration is working.
+
+## Verify your configuration
+
+To check if runners are running in the GKE cluster, you can either:
+
+- Use the following command:
+
+  ```shell
+  kubectl get pods
+  ```
+
+  You should see the following output. This shows that your runners
+  are running in the GKE cluster:
+
+  ```plaintext
+  NAME                             READY   STATUS    RESTARTS   AGE
+  gitlab-runner-hash-short_hash    1/1     Running   0          5m
+  ```
+
+- Check the job log in GitLab:
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**)
+     to find your project.
+  1. Select **Build > Jobs** and find the job.
+  1. To view the job log, select the job status.
diff --git a/doc/tutorials/container_scanning/index.md b/doc/tutorials/container_scanning/index.md
new file mode 100644
index 00000000000..711ed359e89
--- /dev/null
+++ b/doc/tutorials/container_scanning/index.md
@@ -0,0 +1,112 @@
+---
+stage: Secure
+group: Composition Analysis
+info: For assistance with this tutorial, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
+---
+
+# Tutorial: Scan a Docker container for vulnerabilities **(FREE)**
+
+You can use [container scanning](../../user/application_security/container_scanning/index.md) to check for vulnerabilities
+in container images stored in the [container registry](../../user/packages/container_registry/index.md).
+
+Container scanning configuration is added to the pipeline configuration of a project. In this tutorial, you:
+
+1. Create a [new project](#create-a-new-project).
+1. [Add a `Dockerfile`](#add-a-dockerfile-to-new-project) file to the project. This `Dockerfile` contains minimal
+   configuration required to create a Docker image.
+1. Create [pipeline configuration](#create-pipeline-configuration) for the new project to create a Docker
+   image from the `Dockerfile`, build and push a Docker image to the container registry, and then scan the Docker image
+   for vulnerabilities.
+1. Check for [reported vulnerabilities](#check-for-reported-vulnerabilities).
+1. [Update the Docker image](#update-the-docker-image) and scan the updated image.
+
+## Create a new project
+
+To create the new project
+
+1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New project/repository**.
+1. Select **Create blank project**.
+1. In **Project name**, enter `Tutorial container scanning project`.
+1. In **Project URL**, select a namespace for the project.
+1. Select **Create project**.
+
+## Add a `Dockerfile` to new project
+
+To provide something for container scanning to work on, create a `Dockerfile` with very minimal configuration:
+
+1. In your `Tutorial container scanning project` project, select **{plus}** > **New file**.
+1. Enter the filename `Dockerfile`, and provide the following contents for the file:
+
+   ```Dockerfile
+   FROM hello-world:latest
+   ```
+
+Docker images created from this `Dockerfile` are based on [`hello-world`](https://hub.docker.com/_/hello-world) Docker
+image.
+
+1. Select **Commit changes**.
+
+## Create pipeline configuration
+
+Now you're ready to create pipeline configuration. The pipeline configuration:
+
+1. Builds a Docker image from the `Dockerfile` file, and pushes the Docker image to the container registry. The
+   `build-image` job uses [Docker-in-Docker](../../ci/docker/using_docker_build.md) as a
+   [CI/CD service](../../ci/services/index.md) to build the Docker image. You can also
+   [use kaniko](../../ci/docker/using_kaniko.md) to build Docker images in a pipeline.
+1. Includes the `Container-Scanning.gitlab-ci.yml` template, to scan the Docker image stored in the container registry.
+
+To create the pipeline configuration:
+
+1. In the root directory of your project, select **{plus}** > **New file**.
+1. Enter the filename `.gitlab-ci.yml`, and provide the following contents for the file:
+
+   ```yaml
+   include:
+     - template: Security/Container-Scanning.gitlab-ci.yml
+
+   container_scanning:
+     variables:
+       CS_IMAGE: $CI_REGISTRY_IMAGE/tutorial-image
+
+   build-image:
+     image: docker:24.0.2
+     stage: build
+     services:
+       - docker:24.0.2-dind
+     script:
+       - docker build --tag $CI_REGISTRY_IMAGE/tutorial-image --file Dockerfile .
+       - docker login --username gitlab-ci-token --password $CI_JOB_TOKEN $CI_REGISTRY
+       - docker push $CI_REGISTRY_IMAGE/tutorial-image
+   ```
+
+1. Select **Commit changes**.
+
+You're almost done. After you commit the file, a new pipeline starts with this configuration.
+When it's finished, you can check the results of the scan.
+
+## Check for reported vulnerabilities
+
+Vulnerabilities for a scan are located on the pipeline that ran the scan. To check for reported vulnerabilities:
+
+1. Select **CI/CD** > **Pipelines** and select the most recent pipeline. This pipeline should consist of a job called
+   `container_scanning` in the `test` stage.
+1. If the `container_scanning` job was successful, select the **Security** tab. If any vulnerabilities were found, they
+   are listed on that page.
+
+## Update the Docker image
+
+A Docker image based on `hello-world:latest` is unlikely to show any vulnerabilities. For an example of a scan that
+reports vulnerabilities:
+
+1. In the root directory of your project, select the existing `Dockerfile` file.
+1. Select **Edit**.
+1. Replace `FROM hello-world:latest` with a different Docker image for the
+   [`FROM`](https://docs.docker.com/engine/reference/builder/#from) instruction. The best Docker images to demonstrate
+   container scanning have:
+   - Operating system packages. For example, from Debian, Ubuntu, Alpine, or Red Hat.
+   - Programming language packages. For example, NPM packages or Python packages.
+1. Select **Commit changes**.
+
+After you commit changes to the file, a new pipeline starts with this updated `Dockerfile`. When it's finished, you can
+check the results of the new scan.
diff --git a/doc/tutorials/convert_personal_namespace_to_group/index.md b/doc/tutorials/convert_personal_namespace_to_group/index.md
index 53ad46effd9..093dd04882a 100644
--- a/doc/tutorials/convert_personal_namespace_to_group/index.md
+++ b/doc/tutorials/convert_personal_namespace_to_group/index.md
@@ -33,8 +33,7 @@ rename the `alex` namespace to `alex-user`, and `alex-group` namespace to the no
 
 ## Create a group
 
-1. On the top bar, select **Main menu > Groups > View all groups**.
-1. On the right of the page, select **New group**.
+1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New group**.
 1. In **Group name**, enter a name for the group.
 1. In **Group URL**, enter a path for the group, which is used as the namespace.
    Don't worry about the actual path, this is only temporary. You'll change this URL to the username of the personal namespace in the [final step](#rename-the-new-group-namespace-to-the-original-username).
@@ -57,8 +56,8 @@ Before you start the transfer process, make sure you:
 
 To transfer a project to a group:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Advanced**.
 1. Under **Transfer project**, choose the group to transfer the project to.
 1. Select **Transfer project**.
@@ -73,7 +72,7 @@ From the moment you rename the personal namespace, the username becomes availabl
 
 To [change a user's username](../../user/profile/index.md#change-your-username):
 
-1. On the top bar, in the top-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Account**.
 1. In the **Change username** section, enter a new username as the path.
@@ -85,8 +84,8 @@ Finally, rename the new group's URL to the username of the original personal nam
 
 To [change your group path](../../user/group/manage.md#change-a-groups-path) (group URL):
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General page**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Advanced** section.
 1. Under **Change group URL**, enter the user's original username.
 1. Select **Change group URL**.
diff --git a/doc/tutorials/dependency_scanning.md b/doc/tutorials/dependency_scanning.md
new file mode 100644
index 00000000000..51424c3319e
--- /dev/null
+++ b/doc/tutorials/dependency_scanning.md
@@ -0,0 +1,676 @@
+---
+stage: Secure
+group: Composition Analysis
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Tutorial: Set up dependency scanning **(ULTIMATE SAAS)**
+
+Dependency Scanning can automatically find security vulnerabilities in your software dependencies
+while you're developing and testing your applications. For example, dependency scanning lets you
+know if your application uses an external (open source) library that is known to be vulnerable. You
+can then take action to protect your application.
+
+This tutorial shows you how to create a sample vulnerable application, then:
+
+- How to detect, triage, and resolve vulnerabilities in the application's dependencies.
+- How to detect vulnerabilities in a merge request.
+
+To set up dependency scanning:
+
+- [Create example application files](#create-example-application-files).
+- [Triage the vulnerabilities](#triage-the-vulnerabilities).
+- [Resolve the high severity vulnerability](#resolve-the-high-severity-vulnerability).
+- [Test vulnerability detection in a merge request](#test-vulnerability-detection-in-a-merge-request).
+
+## Prerequisites
+
+Before you begin, make sure you have GitPod enabled. GitPod is an on-demand cloud development
+environment. For details, see [GitPod](../integration/gitpod.md). Alternatively you can use your
+own development setup. In this case you need to have Yarn and Node.js installed.
+
+## Create example application files
+
+First, in a new project, create files to configure your pipeline, and add dependencies that can be
+scanned for vulnerabilities.
+
+1. Create a blank project, using the default values.
+
+1. Create the following files in the `main` branch.
+
+   Filename: `.gitlab-ci.yml`
+
+   ```yaml
+   stages:
+   - build
+   - test
+
+   include:
+   - template: Security/Dependency-Scanning.gitlab-ci.yml
+
+   # override the dependency scanning job
+   gemnasium-dependency_scanning:
+     tags: [ saas-linux-large-amd64 ]
+     rules:
+       - if: $CI_COMMIT_BRANCH == "main"
+       - if: $CI_MERGE_REQUEST_IID
+   ```
+
+   Filename: `index.js`
+
+   ```javascript
+   // Require the framework and instantiate it
+   const fastify = require('fastify')({ logger: true })
+   const path = require('path')
+   //const fetch = require('node-fetch')
+
+   fastify.register(require('fastify-static'), {
+     root: path.join(__dirname, 'public'),
+     prefix: '/'
+   })
+
+   fastify.register(require('./routes'), {
+     message: "hello"
+   })
+
+   // fastify.register(require('fastify-redis'), { url: constants.redisUrl, /* other redis options */ })
+
+   // Run the server!
+   const start = async () => {
+     try {
+       await fastify.listen(8080, "0.0.0.0")
+       fastify.log.info(`server listening on ${fastify.server.address().port}`)
+
+     } catch (error) {
+       fastify.log.error(error)
+       //process.exit(1)
+     }
+   }
+   start()
+   ```
+
+   Filename `package.json`
+
+   ```json
+   {
+     "dependencies": {
+       "fastify": "2.14.1",
+       "fastify-static": "2.0.0"
+     }
+   }
+   ```
+
+   Filename `yarn.lock`
+
+   Use the content shown in the [Yarn lockfile](#yarn-lock-file-content) section.
+
+1. Go to **CI/CD > Pipelines** and confirm that the latest pipeline completed successfully.
+
+In the pipeline, dependency scanning runs and the vulnerabilities are detected automatically.
+
+## Triage the vulnerabilities
+
+The vulnerability report provides vital information on vulnerabilities. You would usually triage
+vulnerabilities according to your organization's policies. For this tutorial, you'll dismiss the
+medium severity vulnerabilities and confirm only the high severity vulnerability.
+
+To triage the vulnerabilities:
+
+1. Go to **Security and Compliance > Vulnerability report**.
+1. Select each of the medium severity vulnerabilities by selecting the checkbox in each row.
+1. From the **Set status** dropdown list select **Dismiss**. From the **Dismissal reason** dropdown
+   list select **Used in tests**, add the comment "Used in tests", then select **Change status**.
+
+   The medium severity vulnerabilities are filtered out of the view, leaving only the high
+   severity vulnerability remaining.
+
+1. Select the **High** vulnerability's description.
+
+   The recommended solution is to upgrade the `fastify` package. You would usually investigate
+   this further, but for this tutorial, you can consider this vulnerability confirmed.
+
+1. From the **Status** dropdown list select **Confirm**, then select **Change status**.
+
+## Resolve the high severity vulnerability
+
+Only the high severity vulnerability remains to be resolved. From the triage step you know that you
+need to upgrade the `fastify` package.
+
+To fix the vulnerability:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. In the upper right, select **Edit > GitPod** and open
+   GitPod in a new tab.
+1. If you are prompted to, select **Continue with GitLab**, then select **Authorize**.
+1. On the **New Workspace** page, select **Continue**.
+1. In the **Terminal** pane, enter the following command to create a new branch.
+
+   ```plaintext
+   git checkout -b update_packages main
+   ```
+
+1. In the **Terminal** pane, run the command `yarn upgrade --latest`. This updates the project's
+   dependencies and the `yarn.lock` file.
+1. In the **Terminal** pane, run the following commands to commit your changes. This triggers a CI/CD
+   pipeline.
+
+   ```plaintext
+   git add package.json yarn.lock
+   git commit -m "Update package versions"
+   git push --set-upstream origin update_packages
+   ```
+
+1. Switch to the GitLab browser tab.
+1. Go to **Merge requests**, then select **Create merge request**.
+1. On the **New merge request** page, scroll to the bottom and select **Create merge request**.
+   Wait for the merge request pipeline to complete.
+1. Refresh the page, then select **Merge**.
+1. Wait for the pipeline to complete successfully.
+1. Go to **Security and Compliance > Vulnerability report**.
+1. Select the **High** vulnerability's description.
+
+   A banner confirms that the vulnerability has been resolved in the `main` branch. You would
+   usually confirm that manually by verifying the version of the `fastify` package specified in the
+   `yarn.lock` file. For this tutorial, you can skip the verification step.
+
+1. In the **Status** dropdown list, select **Resolve**, then select **Change status**.
+1. Go to **Security and Compliance > Vulnerability report**.
+
+   You should now see _no_ vulnerabilities listed in the vulnerability report.
+
+## Test vulnerability detection in a merge request
+
+You now know how to triage and resolve vulnerabilities. Now, to see how to detect new potential
+vulnerabilities in a merge request, add a dependency known to have vulnerabilities.
+
+To add a new vulnerability:
+
+1. Switch to the GitPod tab. If it's timed out, select **Open Workspace**.
+1. In the **Terminal** pane run the following command to update the local `main` branch:
+
+   ```plaintext
+   git checkout main
+   git fetch origin
+   git rebase origin/main
+   ```
+
+1. In the **Terminal** pane run the following command to create a new branch:
+
+   ```plaintext
+   git checkout -b add_dependency main
+   ```
+
+1. In the file explorer sidebar, select the `package.json` file.
+1. Add the following line to the `dependencies` section of the `package.json` file.
+
+   ```json
+   "axios": "0.21.0",
+   ```
+
+1. In the **Terminal** pane, run the following command to install the dependency added to the
+   `package.json` file.
+
+   ```plaintext
+   yarn install
+   ```
+
+1. In the **Terminal** pane, run the following commands to commit your changes. This triggers a
+   CI/CD pipeline on GitLab.
+
+   ```plaintext
+   git add package.json yarn.lock
+   git commit -m "Add dependency"
+   git push --set-upstream origin add_dependency
+   ```
+
+1. Switch to the GitLab browser tab.
+1. Go to **Merge requests**, then select **Create merge request**.
+1. On the **New merge request** page, scroll to the bottom and select **Create merge request**.
+
+Wait for the merge request pipeline to complete, then refresh the page. The merge
+request security widget warns of new potential vulnerabilities. These vulnerabilities exist
+only in the `add_dependency` branch, not the `main` branch.
+
+You now know how to:
+
+- Detect vulnerabilities in an application's dependencies.
+- Triage and resolve vulnerabilities.
+- Detect new vulnerabilities in a merge request.
+
+### Yarn lock file content
+
+```yaml
+# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
+# yarn lockfile v1
+
+abstract-logging@^2.0.0:
+  version "2.0.1"
+  resolved "https://registry.yarnpkg.com/abstract-logging/-/abstract-logging-2.0.1.tgz#6b0c371df212db7129b57d2e7fcf282b8bf1c839"
+  integrity sha512-2BjRTZxTPvheOvGbBslFSYOUkr+SjPtOnrLP33f+VIWLzezQpZcqVg7ja3L4dBXmzzgwT+a029jRx5PCi3JuiA==
+
+ajv@^6.10.2, ajv@^6.11.0, ajv@^6.12.0:
+  version "6.12.6"
+  resolved "https://registry.yarnpkg.com/ajv/-/ajv-6.12.6.tgz#baf5a62e802b07d977034586f8c3baf5adf26df4"
+  integrity sha512-j3fVLgvTo527anyYyJOGTYJbG+vnnQYvE0m5mmkc1TK+nxAppkCLMIL0aZ4dblVCNoGShhm+kzE4ZUykBoMg4g==
+  dependencies:
+    fast-deep-equal "^3.1.1"
+    fast-json-stable-stringify "^2.0.0"
+    json-schema-traverse "^0.4.1"
+    uri-js "^4.2.2"
+
+archy@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/archy/-/archy-1.0.0.tgz#f9c8c13757cc1dd7bc379ac77b2c62a5c2868c40"
+  integrity sha512-Xg+9RwCg/0p32teKdGMPTPnVXKD0w3DfHnFTficozsAgsvq2XenPJq/MYpzzQ/v8zrOyJn6Ds39VA4JIDwFfqw==
+
+atomic-sleep@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/atomic-sleep/-/atomic-sleep-1.0.0.tgz#eb85b77a601fc932cfe432c5acd364a9e2c9075b"
+  integrity sha512-kNOjDqAh7px0XWNI+4QbzoiR/nTkHAWNud2uvnJquD1/x5a7EQZMJT0AczqK0Qn67oY/TTQ1LbUKajZpp3I9tQ==
+
+avvio@^6.3.1:
+  version "6.5.0"
+  resolved "https://registry.yarnpkg.com/avvio/-/avvio-6.5.0.tgz#d2cf119967fe90d2156afc29de350ced800cdaab"
+  integrity sha512-BmzcZ7gFpyFJsW8G+tfQw8vJNUboA9SDkkHLZ9RAALhvw/rplfWwni8Ee1rA11zj/J7/E5EvZmweusVvTHjWCA==
+  dependencies:
+    archy "^1.0.0"
+    debug "^4.0.0"
+    fastq "^1.6.0"
+
+cookie@^0.4.0:
+  version "0.4.2"
+  resolved "https://registry.yarnpkg.com/cookie/-/cookie-0.4.2.tgz#0e41f24de5ecf317947c82fc789e06a884824432"
+  integrity sha512-aSWTXFzaKWkvHO1Ny/s+ePFpvKsPnjc551iI41v3ny/ow6tBG5Vd+FuqGNhh1LxOmVzOlGUriIlOaokOvhaStA==
+
+debug@2.6.9:
+  version "2.6.9"
+  resolved "https://registry.yarnpkg.com/debug/-/debug-2.6.9.tgz#5d128515df134ff327e90a4c93f4e077a536341f"
+  integrity sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==
+  dependencies:
+    ms "2.0.0"
+
+debug@^4.0.0:
+  version "4.3.4"
+  resolved "https://registry.yarnpkg.com/debug/-/debug-4.3.4.tgz#1319f6579357f2338d3337d2cdd4914bb5dcc865"
+  integrity sha512-PRWFHuSU3eDtQJPvnNY7Jcket1j0t5OuOsFzPPzsekD52Zl8qUfFIPEiswXqIvHWGVHOgX+7G/vCNNhehwxfkQ==
+  dependencies:
+    ms "2.1.2"
+
+deepmerge@^4.2.2:
+  version "4.2.2"
+  resolved "https://registry.yarnpkg.com/deepmerge/-/deepmerge-4.2.2.tgz#44d2ea3679b8f4d4ffba33f03d865fc1e7bf4955"
+  integrity sha512-FJ3UgI4gIl+PHZm53knsuSFpE+nESMr7M4v9QcgB7S63Kj/6WqMiFQJpBBYz1Pt+66bZpP3Q7Lye0Oo9MPKEdg==
+
+depd@~1.1.2:
+  version "1.1.2"
+  resolved "https://registry.yarnpkg.com/depd/-/depd-1.1.2.tgz#9bcd52e14c097763e749b274c4346ed2e560b5a9"
+  integrity sha512-7emPTl6Dpo6JRXOXjLRxck+FlLRX5847cLKEn00PLAgc3g2hTZZgr+e4c2v6QpSmLeFP3n5yUo7ft6avBK/5jQ==
+
+destroy@~1.0.4:
+  version "1.0.4"
+  resolved "https://registry.yarnpkg.com/destroy/-/destroy-1.0.4.tgz#978857442c44749e4206613e37946205826abd80"
+  integrity sha512-3NdhDuEXnfun/z7x9GOElY49LoqVHoGScmOKwmxhsS8N5Y+Z8KyPPDnaSzqWgYt/ji4mqwfTS34Htrk0zPIXVg==
+
+ee-first@1.1.1:
+  version "1.1.1"
+  resolved "https://registry.yarnpkg.com/ee-first/-/ee-first-1.1.1.tgz#590c61156b0ae2f4f0255732a158b266bc56b21d"
+  integrity sha512-WMwm9LhRUo+WUaRN+vRuETqG89IgZphVSNkdFgeb6sS/E4OrDIN7t48CAewSHXc6C8lefD8KKfr5vY61brQlow==
+
+encodeurl@~1.0.2:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/encodeurl/-/encodeurl-1.0.2.tgz#ad3ff4c86ec2d029322f5a02c3a9a606c95b3f59"
+  integrity sha512-TPJXq8JqFaVYm2CWmPvnP2Iyo4ZSM7/QKcSmuMLDObfpH5fi7RUGmd/rTDf+rut/saiDiQEeVTNgAmJEdAOx0w==
+
+escape-html@~1.0.3:
+  version "1.0.3"
+  resolved "https://registry.yarnpkg.com/escape-html/-/escape-html-1.0.3.tgz#0258eae4d3d0c0974de1c169188ef0051d1d1988"
+  integrity sha512-NiSupZ4OeuGwr68lGIeym/ksIZMJodUGOSCZ/FSnTxcrekbvqrgdUxlJOMpijaKZVjAJrWrGs/6Jy8OMuyj9ow==
+
+etag@~1.8.1:
+  version "1.8.1"
+  resolved "https://registry.yarnpkg.com/etag/-/etag-1.8.1.tgz#41ae2eeb65efa62268aebfea83ac7d79299b0887"
+  integrity sha512-aIL5Fx7mawVa300al2BnEE4iNvo1qETxLrPI/o05L7z6go7fCw1J6EQmbK4FmJ2AS7kgVF/KEZWufBfdClMcPg==
+
+fast-decode-uri-component@^1.0.0:
+  version "1.0.1"
+  resolved "https://registry.yarnpkg.com/fast-decode-uri-component/-/fast-decode-uri-component-1.0.1.tgz#46f8b6c22b30ff7a81357d4f59abfae938202543"
+  integrity sha512-WKgKWg5eUxvRZGwW8FvfbaH7AXSh2cL+3j5fMGzUMCxWBJ3dV3a7Wz8y2f/uQ0e3B6WmodD3oS54jTQ9HVTIIg==
+
+fast-deep-equal@^3.1.1:
+  version "3.1.3"
+  resolved "https://registry.yarnpkg.com/fast-deep-equal/-/fast-deep-equal-3.1.3.tgz#3a7d56b559d6cbc3eb512325244e619a65c6c525"
+  integrity sha512-f3qQ9oQy9j2AhBe/H9VC91wLmKBCCU/gDOnKNAYG5hswO7BLKj09Hc5HYNz9cGI++xlpDCIgDaitVs03ATR84Q==
+
+fast-json-stable-stringify@^2.0.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/fast-json-stable-stringify/-/fast-json-stable-stringify-2.1.0.tgz#874bf69c6f404c2b5d99c481341399fd55892633"
+  integrity sha512-lhd/wF+Lk98HZoTCtlVraHtfh5XYijIjalXck7saUtuanSDyLMxnHhSXEDJqHxD7msR8D0uCmqlkwjCV8xvwHw==
+
+fast-json-stringify@^1.18.0:
+  version "1.21.0"
+  resolved "https://registry.yarnpkg.com/fast-json-stringify/-/fast-json-stringify-1.21.0.tgz#51bc8c6d77d8c7b2cc7e5fa754f7f909f9e1262f"
+  integrity sha512-xY6gyjmHN3AK1Y15BCbMpeO9+dea5ePVsp3BouHCdukcx0hOHbXwFhRodhcI0NpZIgDChSeAKkHW9YjKvhwKBA==
+  dependencies:
+    ajv "^6.11.0"
+    deepmerge "^4.2.2"
+    string-similarity "^4.0.1"
+
+fast-redact@^2.0.0:
+  version "2.1.0"
+  resolved "https://registry.yarnpkg.com/fast-redact/-/fast-redact-2.1.0.tgz#dfe3c1ca69367fb226f110aa4ec10ec85462ffdf"
+  integrity sha512-0LkHpTLyadJavq9sRzzyqIoMZemWli77K2/MGOkafrR64B9ItrvZ9aT+jluvNDsv0YEHjSNhlMBtbokuoqii4A==
+
+fast-safe-stringify@^2.0.7:
+  version "2.1.1"
+  resolved "https://registry.yarnpkg.com/fast-safe-stringify/-/fast-safe-stringify-2.1.1.tgz#c406a83b6e70d9e35ce3b30a81141df30aeba884"
+  integrity sha512-W+KJc2dmILlPplD/H4K9l9LcAHAfPtP6BY84uVLXQ6Evcz9Lcg33Y2z1IVblT6xdY54PXYVHEv+0Wpq8Io6zkA==
+
+fastify-plugin@^1.2.0:
+  version "1.6.1"
+  resolved "https://registry.yarnpkg.com/fastify-plugin/-/fastify-plugin-1.6.1.tgz#122f5a5eeb630d55c301713145a9d188e6d5dd5b"
+  integrity sha512-APBcb27s+MjaBIerFirYmBLatoPCgmHZM6XP0K+nDL9k0yX8NJPWDY1RAC3bh6z+AB5ULS2j31BUfLMT3uaZ4A==
+  dependencies:
+    semver "^6.3.0"
+
+fastify-static@2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/fastify-static/-/fastify-static-2.0.0.tgz#674f3f3180e8b055e5e1ee1bcee68114cfb09a8f"
+  integrity sha512-8YQ4QWcSR3YJTFLpExXIej2GzCHThowyLUUxt1uZN8rBEEI2T2ZcaRXPmkaNcaUiKzLXceGjdbJm5yByp5dlkA==
+  dependencies:
+    fastify-plugin "^1.2.0"
+    readable-stream "^3.0.2"
+    send "^0.16.0"
+
+fastify@2.14.1:
+  version "2.14.1"
+  resolved "https://registry.yarnpkg.com/fastify/-/fastify-2.14.1.tgz#2946e8e9adebcd1b4f634178c8fb7162fb816cf4"
+  integrity sha512-nSL8AgIdFCpZmFwjqB5Zzv+3/1KpwwVtB/h88Q4Og8njYbkddKGpuQlQ2tHUULXPTJrLZ7wop6olzx6HEbHdpw==
+  dependencies:
+    abstract-logging "^2.0.0"
+    ajv "^6.12.0"
+    avvio "^6.3.1"
+    fast-json-stringify "^1.18.0"
+    find-my-way "^2.2.2"
+    flatstr "^1.0.12"
+    light-my-request "^3.7.3"
+    middie "^4.1.0"
+    pino "^5.17.0"
+    proxy-addr "^2.0.6"
+    readable-stream "^3.6.0"
+    rfdc "^1.1.2"
+    secure-json-parse "^2.1.0"
+    tiny-lru "^7.0.2"
+
+fastq@^1.6.0:
+  version "1.13.0"
+  resolved "https://registry.yarnpkg.com/fastq/-/fastq-1.13.0.tgz#616760f88a7526bdfc596b7cab8c18938c36b98c"
+  integrity sha512-YpkpUnK8od0o1hmeSc7UUs/eB/vIPWJYjKck2QKIzAf71Vm1AAQ3EbuZB3g2JIy+pg+ERD0vqI79KyZiB2e2Nw==
+  dependencies:
+    reusify "^1.0.4"
+
+find-my-way@^2.2.2:
+  version "2.2.5"
+  resolved "https://registry.yarnpkg.com/find-my-way/-/find-my-way-2.2.5.tgz#86ce825266fa28cd962e538a45ec2aaa84c3d514"
+  integrity sha512-GjRZZlGcGmTh9t+6Xrj5K0YprpoAFCAiCPgmAH9Kb09O4oX6hYuckDfnDipYj+Q7B1GtYWSzDI5HEecNYscLQg==
+  dependencies:
+    fast-decode-uri-component "^1.0.0"
+    safe-regex2 "^2.0.0"
+    semver-store "^0.3.0"
+
+flatstr@^1.0.12:
+  version "1.0.12"
+  resolved "https://registry.yarnpkg.com/flatstr/-/flatstr-1.0.12.tgz#c2ba6a08173edbb6c9640e3055b95e287ceb5931"
+  integrity sha512-4zPxDyhCyiN2wIAtSLI6gc82/EjqZc1onI4Mz/l0pWrAlsSfYH/2ZIcU+e3oA2wDwbzIWNKwa23F8rh6+DRWkw==
+
+forwarded@0.2.0:
+  version "0.2.0"
+  resolved "https://registry.yarnpkg.com/forwarded/-/forwarded-0.2.0.tgz#2269936428aad4c15c7ebe9779a84bf0b2a81811"
+  integrity sha512-buRG0fpBtRHSTCOASe6hD258tEubFoRLb4ZNA6NxMVHNw2gOcwHo9wyablzMzOA5z9xA9L1KNjk/Nt6MT9aYow==
+
+fresh@0.5.2:
+  version "0.5.2"
+  resolved "https://registry.yarnpkg.com/fresh/-/fresh-0.5.2.tgz#3d8cadd90d976569fa835ab1f8e4b23a105605a7"
+  integrity sha512-zJ2mQYM18rEFOudeV4GShTGIQ7RbzA7ozbU9I/XBpm7kqgMywgmylMwXHxZJmkVoYkna9d2pVXVXPdYTP9ej8Q==
+
+http-errors@~1.6.2:
+  version "1.6.3"
+  resolved "https://registry.yarnpkg.com/http-errors/-/http-errors-1.6.3.tgz#8b55680bb4be283a0b5bf4ea2e38580be1d9320d"
+  integrity sha512-lks+lVC8dgGyh97jxvxeYTWQFvh4uw4yC12gVl63Cg30sjPX4wuGcdkICVXDAESr6OJGjqGA8Iz5mkeN6zlD7A==
+  dependencies:
+    depd "~1.1.2"
+    inherits "2.0.3"
+    setprototypeof "1.1.0"
+    statuses ">= 1.4.0 < 2"
+
+inherits@2.0.3:
+  version "2.0.3"
+  resolved "https://registry.yarnpkg.com/inherits/-/inherits-2.0.3.tgz#633c2c83e3da42a502f52466022480f4208261de"
+  integrity sha512-x00IRNXNy63jwGkJmzPigoySHbaqpNuzKbBOmzK+g2OdZpQ9w+sxCN+VSB3ja7IAge2OP2qpfxTjeNcyjmW1uw==
+
+inherits@^2.0.3:
+  version "2.0.4"
+  resolved "https://registry.yarnpkg.com/inherits/-/inherits-2.0.4.tgz#0fa2c64f932917c3433a0ded55363aae37416b7c"
+  integrity sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==
+
+ipaddr.js@1.9.1:
+  version "1.9.1"
+  resolved "https://registry.yarnpkg.com/ipaddr.js/-/ipaddr.js-1.9.1.tgz#bff38543eeb8984825079ff3a2a8e6cbd46781b3"
+  integrity sha512-0KI/607xoxSToH7GjN1FfSbLoU0+btTicjsQSWQlh/hZykN8KpmMf7uYwPW3R+akZ6R/w18ZlXSHBYXiYUPO3g==
+
+json-schema-traverse@^0.4.1:
+  version "0.4.1"
+  resolved "https://registry.yarnpkg.com/json-schema-traverse/-/json-schema-traverse-0.4.1.tgz#69f6a87d9513ab8bb8fe63bdb0979c448e684660"
+  integrity sha512-xbbCH5dCYU5T8LcEhhuh7HJ88HXuW3qsI3Y0zOZFKfZEHcpWiHU/Jxzk629Brsab/mMiHQti9wMP+845RPe3Vg==
+
+light-my-request@^3.7.3:
+  version "3.8.0"
+  resolved "https://registry.yarnpkg.com/light-my-request/-/light-my-request-3.8.0.tgz#7da96786e4d479371b25cfd524ee05d5d583dae8"
+  integrity sha512-cIOWmNsgoStysmkzcv2EwvLwMb2hEm6oqKMerG/b5ey9F0we2Qony8cAZgBktmGPYUvPyKsDCzMcYU6fXbpWew==
+  dependencies:
+    ajv "^6.10.2"
+    cookie "^0.4.0"
+    readable-stream "^3.4.0"
+    set-cookie-parser "^2.4.1"
+
+middie@^4.1.0:
+  version "4.1.0"
+  resolved "https://registry.yarnpkg.com/middie/-/middie-4.1.0.tgz#0fe986c83d5081489514ca1a2daba5ca36263436"
+  integrity sha512-eylPpZA+K3xO9kpDjagoPkEUkNcWV3EAo5OEz0MqsekUpT7KbnQkk8HNZkh4phx2vvOAmNNZuLRWF9lDDHPpVQ==
+  dependencies:
+    path-to-regexp "^4.0.0"
+    reusify "^1.0.2"
+
+mime@1.4.1:
+  version "1.4.1"
+  resolved "https://registry.yarnpkg.com/mime/-/mime-1.4.1.tgz#121f9ebc49e3766f311a76e1fa1c8003c4b03aa6"
+  integrity sha512-KI1+qOZu5DcW6wayYHSzR/tXKCDC5Om4s1z2QJjDULzLcmf3DvzS7oluY4HCTrc+9FiKmWUgeNLg7W3uIQvxtQ==
+
+ms@2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/ms/-/ms-2.0.0.tgz#5608aeadfc00be6c2901df5f9861788de0d597c8"
+  integrity sha512-Tpp60P6IUJDTuOq/5Z8cdskzJujfwqfOTkrwIwj7IRISpnkJnT6SyJ4PCPnGMoFjC9ddhal5KVIYtAt97ix05A==
+
+ms@2.1.2:
+  version "2.1.2"
+  resolved "https://registry.yarnpkg.com/ms/-/ms-2.1.2.tgz#d09d1f357b443f493382a8eb3ccd183872ae6009"
+  integrity sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==
+
+on-finished@~2.3.0:
+  version "2.3.0"
+  resolved "https://registry.yarnpkg.com/on-finished/-/on-finished-2.3.0.tgz#20f1336481b083cd75337992a16971aa2d906947"
+  integrity sha512-ikqdkGAAyf/X/gPhXGvfgAytDZtDbr+bkNUJ0N9h5MI/dmdgCs3l6hoHrcUv41sRKew3jIwrp4qQDXiK99Utww==
+  dependencies:
+    ee-first "1.1.1"
+
+path-to-regexp@^4.0.0:
+  version "4.0.5"
+  resolved "https://registry.yarnpkg.com/path-to-regexp/-/path-to-regexp-4.0.5.tgz#2d4fd140af9a369bf7b68f77a7fdc340490f4239"
+  integrity sha512-l+fTaGG2N9ZRpCEUj5fG1VKdDLaiqwCIvPngpnxzREhcdobhZC4ou4w984HBu72DqAJ5CfcdV6tjqNOunfpdsQ==
+
+pino-std-serializers@^2.4.2:
+  version "2.5.0"
+  resolved "https://registry.yarnpkg.com/pino-std-serializers/-/pino-std-serializers-2.5.0.tgz#40ead781c65a0ce7ecd9c1c33f409d31fe712315"
+  integrity sha512-wXqbqSrIhE58TdrxxlfLwU9eDhrzppQDvGhBEr1gYbzzM4KKo3Y63gSjiDXRKLVS2UOXdPNR2v+KnQgNrs+xUg==
+
+pino@^5.17.0:
+  version "5.17.0"
+  resolved "https://registry.yarnpkg.com/pino/-/pino-5.17.0.tgz#b9def314e82402154f89a25d76a31f20ca84b4c8"
+  integrity sha512-LqrqmRcJz8etUjyV0ddqB6OTUutCgQULPFg2b4dtijRHUsucaAdBgSUW58vY6RFSX+NT8963F+q0tM6lNwGShA==
+  dependencies:
+    fast-redact "^2.0.0"
+    fast-safe-stringify "^2.0.7"
+    flatstr "^1.0.12"
+    pino-std-serializers "^2.4.2"
+    quick-format-unescaped "^3.0.3"
+    sonic-boom "^0.7.5"
+
+proxy-addr@^2.0.6:
+  version "2.0.7"
+  resolved "https://registry.yarnpkg.com/proxy-addr/-/proxy-addr-2.0.7.tgz#f19fe69ceab311eeb94b42e70e8c2070f9ba1025"
+  integrity sha512-llQsMLSUDUPT44jdrU/O37qlnifitDP+ZwrmmZcoSKyLKvtZxpyV0n2/bD/N4tBAAZ/gJEdZU7KMraoK1+XYAg==
+  dependencies:
+    forwarded "0.2.0"
+    ipaddr.js "1.9.1"
+
+punycode@^2.1.0:
+  version "2.1.1"
+  resolved "https://registry.yarnpkg.com/punycode/-/punycode-2.1.1.tgz#b58b010ac40c22c5657616c8d2c2c02c7bf479ec"
+  integrity sha512-XRsRjdf+j5ml+y/6GKHPZbrF/8p2Yga0JPtdqTIY2Xe5ohJPD9saDJJLPvp9+NSBprVvevdXZybnj2cv8OEd0A==
+
+quick-format-unescaped@^3.0.3:
+  version "3.0.3"
+  resolved "https://registry.yarnpkg.com/quick-format-unescaped/-/quick-format-unescaped-3.0.3.tgz#fb3e468ac64c01d22305806c39f121ddac0d1fb9"
+  integrity sha512-dy1yjycmn9blucmJLXOfZDx1ikZJUi6E8bBZLnhPG5gBrVhHXx2xVyqqgKBubVNEXmx51dBACMHpoMQK/N/AXQ==
+
+range-parser@~1.2.0:
+  version "1.2.1"
+  resolved "https://registry.yarnpkg.com/range-parser/-/range-parser-1.2.1.tgz#3cf37023d199e1c24d1a55b84800c2f3e6468031"
+  integrity sha512-Hrgsx+orqoygnmhFbKaHE6c296J+HTAQXoxEF6gNupROmmGJRoyzfG3ccAveqCBrwr/2yxQ5BVd/GTl5agOwSg==
+
+readable-stream@^3.0.2, readable-stream@^3.4.0, readable-stream@^3.6.0:
+  version "3.6.0"
+  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-3.6.0.tgz#337bbda3adc0706bd3e024426a286d4b4b2c9198"
+  integrity sha512-BViHy7LKeTz4oNnkcLJ+lVSL6vpiFeX6/d3oSH8zCW7UxP2onchk+vTGB143xuFjHS3deTgkKoXXymXqymiIdA==
+  dependencies:
+    inherits "^2.0.3"
+    string_decoder "^1.1.1"
+    util-deprecate "^1.0.1"
+
+ret@~0.2.0:
+  version "0.2.2"
+  resolved "https://registry.yarnpkg.com/ret/-/ret-0.2.2.tgz#b6861782a1f4762dce43402a71eb7a283f44573c"
+  integrity sha512-M0b3YWQs7R3Z917WRQy1HHA7Ba7D8hvZg6UE5mLykJxQVE2ju0IXbGlaHPPlkY+WN7wFP+wUMXmBFA0aV6vYGQ==
+
+reusify@^1.0.2, reusify@^1.0.4:
+  version "1.0.4"
+  resolved "https://registry.yarnpkg.com/reusify/-/reusify-1.0.4.tgz#90da382b1e126efc02146e90845a88db12925d76"
+  integrity sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==
+
+rfdc@^1.1.2:
+  version "1.3.0"
+  resolved "https://registry.yarnpkg.com/rfdc/-/rfdc-1.3.0.tgz#d0b7c441ab2720d05dc4cf26e01c89631d9da08b"
+  integrity sha512-V2hovdzFbOi77/WajaSMXk2OLm+xNIeQdMMuB7icj7bk6zi2F8GGAxigcnDFpJHbNyNcgyJDiP+8nOrY5cZGrA==
+
+safe-buffer@~5.2.0:
+  version "5.2.1"
+  resolved "https://registry.yarnpkg.com/safe-buffer/-/safe-buffer-5.2.1.tgz#1eaf9fa9bdb1fdd4ec75f58f9cdb4e6b7827eec6"
+  integrity sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==
+
+safe-regex2@^2.0.0:
+  version "2.0.0"
+  resolved "https://registry.yarnpkg.com/safe-regex2/-/safe-regex2-2.0.0.tgz#b287524c397c7a2994470367e0185e1916b1f5b9"
+  integrity sha512-PaUSFsUaNNuKwkBijoAPHAK6/eM6VirvyPWlZ7BAQy4D+hCvh4B6lIG+nPdhbFfIbP+gTGBcrdsOaUs0F+ZBOQ==
+  dependencies:
+    ret "~0.2.0"
+
+secure-json-parse@^2.1.0:
+  version "2.5.0"
+  resolved "https://registry.yarnpkg.com/secure-json-parse/-/secure-json-parse-2.5.0.tgz#f929829df2adc7ccfb53703569894d051493a6ac"
+  integrity sha512-ZQruFgZnIWH+WyO9t5rWt4ZEGqCKPwhiw+YbzTwpmT9elgLrLcfuyUiSnwwjUiVy9r4VM3urtbNF1xmEh9IL2w==
+
+semver-store@^0.3.0:
+  version "0.3.0"
+  resolved "https://registry.yarnpkg.com/semver-store/-/semver-store-0.3.0.tgz#ce602ff07df37080ec9f4fb40b29576547befbe9"
+  integrity sha512-TcZvGMMy9vodEFSse30lWinkj+JgOBvPn8wRItpQRSayhc+4ssDs335uklkfvQQJgL/WvmHLVj4Ycv2s7QCQMg==
+
+semver@^6.3.0:
+  version "6.3.0"
+  resolved "https://registry.yarnpkg.com/semver/-/semver-6.3.0.tgz#ee0a64c8af5e8ceea67687b133761e1becbd1d3d"
+  integrity sha512-b39TBaTSfV6yBrapU89p5fKekE2m/NwnDocOVruQFS1/veMgdzuPcnOM34M6CwxW8jH/lxEa5rBoDeUwu5HHTw==
+
+send@^0.16.0:
+  version "0.16.2"
+  resolved "https://registry.yarnpkg.com/send/-/send-0.16.2.tgz#6ecca1e0f8c156d141597559848df64730a6bbc1"
+  integrity sha512-E64YFPUssFHEFBvpbbjr44NCLtI1AohxQ8ZSiJjQLskAdKuriYEP6VyGEsRDH8ScozGpkaX1BGvhanqCwkcEZw==
+  dependencies:
+    debug "2.6.9"
+    depd "~1.1.2"
+    destroy "~1.0.4"
+    encodeurl "~1.0.2"
+    escape-html "~1.0.3"
+    etag "~1.8.1"
+    fresh "0.5.2"
+    http-errors "~1.6.2"
+    mime "1.4.1"
+    ms "2.0.0"
+    on-finished "~2.3.0"
+    range-parser "~1.2.0"
+    statuses "~1.4.0"
+
+set-cookie-parser@^2.4.1:
+  version "2.5.1"
+  resolved "https://registry.yarnpkg.com/set-cookie-parser/-/set-cookie-parser-2.5.1.tgz#ddd3e9a566b0e8e0862aca974a6ac0e01349430b"
+  integrity sha512-1jeBGaKNGdEq4FgIrORu/N570dwoPYio8lSoYLWmX7sQ//0JY08Xh9o5pBcgmHQ/MbsYp/aZnOe1s1lIsbLprQ==
+
+setprototypeof@1.1.0:
+  version "1.1.0"
+  resolved "https://registry.yarnpkg.com/setprototypeof/-/setprototypeof-1.1.0.tgz#d0bd85536887b6fe7c0d818cb962d9d91c54e656"
+  integrity sha512-BvE/TwpZX4FXExxOxZyRGQQv651MSwmWKZGqvmPcRIjDqWub67kTKuIMx43cZZrS/cBBzwBcNDWoFxt2XEFIpQ==
+
+sonic-boom@^0.7.5:
+  version "0.7.7"
+  resolved "https://registry.yarnpkg.com/sonic-boom/-/sonic-boom-0.7.7.tgz#d921de887428208bfa07b0ae32c278de043f350a"
+  integrity sha512-Ei5YOo5J64GKClHIL/5evJPgASXFVpfVYbJV9PILZQytTK6/LCwHvsZJW2Ig4p9FMC2OrBrMnXKgRN/OEoAWfg==
+  dependencies:
+    atomic-sleep "^1.0.0"
+    flatstr "^1.0.12"
+
+"statuses@>= 1.4.0 < 2":
+  version "1.5.0"
+  resolved "https://registry.yarnpkg.com/statuses/-/statuses-1.5.0.tgz#161c7dac177659fd9811f43771fa99381478628c"
+  integrity sha512-OpZ3zP+jT1PI7I8nemJX4AKmAX070ZkYPVWV/AaKTJl+tXCTGyVdC1a4SL8RUQYEwk/f34ZX8UTykN68FwrqAA==
+
+statuses@~1.4.0:
+  version "1.4.0"
+  resolved "https://registry.yarnpkg.com/statuses/-/statuses-1.4.0.tgz#bb73d446da2796106efcc1b601a253d6c46bd087"
+  integrity sha512-zhSCtt8v2NDrRlPQpCNtw/heZLtfUDqxBM1udqikb/Hbk52LK4nQSwr10u77iopCW5LsyHpuXS0GnEc48mLeew==
+
+string-similarity@^4.0.1:
+  version "4.0.4"
+  resolved "https://registry.yarnpkg.com/string-similarity/-/string-similarity-4.0.4.tgz#42d01ab0b34660ea8a018da8f56a3309bb8b2a5b"
+  integrity sha512-/q/8Q4Bl4ZKAPjj8WerIBJWALKkaPRfrvhfF8k/B23i4nzrlRj2/go1m90In7nG/3XDSbOo0+pu6RvCTM9RGMQ==
+
+string_decoder@^1.1.1:
+  version "1.3.0"
+  resolved "https://registry.yarnpkg.com/string_decoder/-/string_decoder-1.3.0.tgz#42f114594a46cf1a8e30b0a84f56c78c3edac21e"
+  integrity sha512-hkRX8U1WjJFd8LsDJ2yQ/wWWxaopEsABU1XfkM8A+j0+85JAGppt16cr1Whg6KIbb4okU6Mql6BOj+uup/wKeA==
+  dependencies:
+    safe-buffer "~5.2.0"
+
+tiny-lru@^7.0.2:
+  version "7.0.6"
+  resolved "https://registry.yarnpkg.com/tiny-lru/-/tiny-lru-7.0.6.tgz#b0c3cdede1e5882aa2d1ae21cb2ceccf2a331f24"
+  integrity sha512-zNYO0Kvgn5rXzWpL0y3RS09sMK67eGaQj9805jlK9G6pSadfriTczzLHFXa/xcW4mIRfmlB9HyQ/+SgL0V1uow==
+
+uri-js@^4.2.2:
+  version "4.4.1"
+  resolved "https://registry.yarnpkg.com/uri-js/-/uri-js-4.4.1.tgz#9b1a52595225859e55f669d928f88c6c57f2a77e"
+  integrity sha512-7rKUyy33Q1yc98pQ1DAmLtwX109F7TIfWlW1Ydo8Wl1ii1SeHieeh0HHfPeL2fMXK6z0s8ecKs9frCuLJvndBg==
+  dependencies:
+    punycode "^2.1.0"
+
+util-deprecate@^1.0.1:
+  version "1.0.2"
+  resolved "https://registry.yarnpkg.com/util-deprecate/-/util-deprecate-1.0.2.tgz#450d4dc9fa70de732762fbd2d4a28981419a0ccf"
+  integrity sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw==
+```
diff --git a/doc/tutorials/develop.md b/doc/tutorials/develop.md
index 08497a09830..349b0899027 100644
--- a/doc/tutorials/develop.md
+++ b/doc/tutorials/develop.md
@@ -4,7 +4,7 @@ group: Tutorials
 info: For assistance with this tutorials page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
 ---
 
-# Develop with GitLab
+# Tutorials: Develop with GitLab
 
 ## Integrate with GitLab
 
@@ -13,5 +13,6 @@ enabling you to work with those services directly from GitLab.
 
 | Topic | Description | Good for beginners |
 |-------|-------------|--------------------|
-| [Integrate with Jira](https://about.gitlab.com/blog/2021/04/12/gitlab-jira-integration-selfmanaged/) | Configure the Jira integration, so you can work with Jira issues from GitLab. | |
-| [Integrate with Gitpod](https://about.gitlab.com/blog/2021/07/19/teams-gitpod-integration-gitlab-speed-up-development/)  | Integrate with Gitpod, to help speed up your development. | |
+| [Create Jira credentials](../integration/jira/jira_server_configuration.md) | Create Jira credentials to configure the Jira issue integration in GitLab. | |
+| [Integrate with Jira](https://about.gitlab.com/blog/2021/04/12/gitlab-jira-integration-selfmanaged/) | Configure the Jira issue integration to connect one or more GitLab projects to a Jira instance. | |
+| [Integrate with Gitpod](https://about.gitlab.com/blog/2021/07/19/teams-gitpod-integration-gitlab-speed-up-development/)  | Integrate with Gitpod to set up a development environment for any GitLab project. | |
diff --git a/doc/tutorials/fuzz_testing/index.md b/doc/tutorials/fuzz_testing/index.md
index 1d4985f9003..41b5068ab72 100644
--- a/doc/tutorials/fuzz_testing/index.md
+++ b/doc/tutorials/fuzz_testing/index.md
@@ -59,7 +59,7 @@ a random buffer as a parameter.
 
 To create the two fuzz target files:
 
-1. On the top bar, select **Main menu > Projects** and select the `fuzz-testing-demo` project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `fuzz-testing-demo` project.
 1. Create a file in the root directory of the project.
 1. Name the file `fuzz-sayhello.js` and add the following code:
 
diff --git a/doc/tutorials/gitlab_navigation.md b/doc/tutorials/gitlab_navigation.md
index 6003fbf67c0..043fc56f025 100644
--- a/doc/tutorials/gitlab_navigation.md
+++ b/doc/tutorials/gitlab_navigation.md
@@ -4,7 +4,7 @@ group: Tutorials
 info: For assistance with this tutorials page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
 ---
 
-# Find your way around GitLab
+# Tutorials: Find your way around GitLab
 
 Get to know the features of GitLab and where to find them so you can get up
 and running quickly.
diff --git a/doc/tutorials/hugo/index.md b/doc/tutorials/hugo/index.md
new file mode 100644
index 00000000000..0e66d096fe2
--- /dev/null
+++ b/doc/tutorials/hugo/index.md
@@ -0,0 +1,168 @@
+---
+stage: Plan
+group: Knowledge
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Tutorial: Build, test, and deploy your Hugo site with GitLab
+
+<!-- vale gitlab.FutureTense = NO -->
+
+This tutorial walks you through creating a CI/CD pipeline to build, test, and deploy a Hugo site.
+
+By the end of the tutorial, you'll have a working pipeline and a Hugo site deployed on GitLab Pages.
+
+Here's an overview of what you're going to do:
+
+1. Prepare your Hugo site.
+1. Create a GitLab project.
+1. Push your Hugo site to GitLab.
+1. Build your Hugo site with a CI/CD pipeline.
+1. Deploy and view your Hugo site with GitLab Pages.
+
+## Prerequisites
+
+- An account on GitLab.com.
+- Familiarity with Git.
+- A Hugo site (if you don't already have one, you can follow the [Hugo Quick Start](https://gohugo.io/getting-started/quick-start/)).
+
+## Prepare your Hugo site
+
+First, make sure your Hugo site is ready to push to GitLab. You need to have your content, a theme, and a configuration file.
+
+Don't *build* your site, as GitLab does that for you. In fact, it's important to **not** upload your `public` folder, as this can cause conflicts later on.
+
+The easiest way to exclude your `public` folder is by creating a `.gitignore` file and adding your `public` folder to it.
+
+You can do this with the following command at the top level of your Hugo project:
+
+```shell
+echo "/public/" >> .gitignore
+```
+
+This either adds `/public/` to a new `.gitignore` file or appends it to an existing file.
+
+OK, your Hugo site is ready to push, after you create a GitLab project.
+
+## Create a GitLab project
+
+If you haven't done so already, create a blank GitLab project for your Hugo site.
+
+To create a blank project, in GitLab:
+
+1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New project/repository**.
+1. Select **Create blank project**.
+1. Enter the project details:
+   - In the **Project name** field, enter the name of your project. The name must start with a lowercase or uppercase letter (`a-zA-Z`), digit (`0-9`), emoji, or underscore (`_`). It can also contain dots (`.`), pluses (`+`), dashes (`-`), or spaces.
+   - In the **Project slug** field, enter the path to your project. The GitLab instance uses the slug as the URL path to the project. To change the slug, first enter the project name, then change the slug.
+   - The **Visibility Level** can be either Private or Public. If you choose Private, your website is still publicly available, but your code remains private.
+   - Because you're pushing an existing repository, clear the box to **Initialize repository with a README**.
+1. When you're ready, select **Create project**.
+1. You should see instructions for pushing your code to this new project. You'll need those instructions in the next step.
+
+You now have a home for your Hugo site!
+
+## Push your Hugo site to GitLab
+
+Next you need to push your local Hugo site to your remote GitLab project.
+
+If you created a new GitLab project in the previous step, you'll see the instructions for initializing your repository, then committing and pushing your files.
+
+Otherwise, make sure the remote origin for your local Git repository matches your GitLab project.
+
+Assuming your default branch is `main`, you can push your Hugo site with the following command:
+
+```shell
+git push origin main
+```
+
+After you've pushed your site, you should see all the content except the `public` folder. The `public` folder was excluded by the `.gitignore` file.
+
+In the next step, you'll use a CI/CD pipeline to build your site and recreate that `public` folder.
+
+## Build your Hugo site
+
+To build a Hugo site with GitLab, you first need to create a `.gitlab-ci.yml` file to specify instructions for the CI/CD pipeline. If you've not done this before, it might sound daunting. However, GitLab provides everything you need.
+
+### Add your configuration options
+
+You specify your configuration options in a special file called `.gitlab-ci.yml`. To create a `.gitlab-ci.yml` file:
+
+1. On the left sidebar, select **Repository > Files**.
+1. Above the file list, select the plus icon ( + ), then select **New file** from the dropdown list.
+1. For the filename, enter `.gitlab-ci.yml`. Don't omit the period at the beginning.
+1. Select the **Apply a template** dropdown list, then enter "Hugo" in the filter box.
+1. Select the result **Hugo**, and your file is populated with all the code you need to build your Hugo site using CI/CD.
+
+Let's take a closer look at what's happening in this `.gitlab-ci.yml` file.
+
+```yaml
+default:
+  image: "${CI_TEMPLATE_REGISTRY_HOST}/pages/hugo:latest"
+
+variables:
+  GIT_SUBMODULE_STRATEGY: recursive
+
+test:  # builds and tests your site
+  script:
+    - hugo
+  rules:
+    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
+
+pages:  # a predefined job that builds your pages and saves them to the specified path.
+  script:
+    - hugo
+  artifacts:
+    paths:
+      - public
+  rules:
+    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
+  environment: production
+```
+
+- `image` specifies an image from the GitLab Registry that contains Hugo. This image is used to create the environment where your site is built.
+- The `GIT_SUBMODULE_STRATEGY` variable ensures GitLab also looks at your Git submodules, which are sometimes used for Hugo themes.
+- `test` is a job where you can run tests on your Hugo site before it's deployed. The test job runs in all cases, *except* if you're committing a change to your default branch. You place any commands under `script`. The command in this job - `hugo`- builds your site so it can be tested.
+- `pages` is a predefined job for creating pages from Static Site Generators. Again, this job runs the `hugo` command to build your site. Then `artifacts` specifies that those resulting pages are added to a directory called `public`. With `rules`, you're checking that this commit was made on the default branch. Typically, you wouldn't want to build and deploy the live site from a feature branch.
+
+You don't need to add anything else to this file. When you're ready, select **Commit changes** at the bottom of the page.
+
+You've just triggered a pipeline to build your Hugo site!
+
+## Deploy and view your Hugo site
+
+If you're quick, you can see GitLab build and deploy your site.
+
+From the left-hand navigation, select **Build > Pipelines**.
+
+You'll see that GitLab has run your `test` and `pages` jobs.
+
+To view your site, on the left-hand navigation, select **Settings > Pages**
+
+The `pages` job in your pipeline has deployed the contents of your `public` directory to GitLab Pages. Under **Access pages**, you should see the link in the format: `https://<your-namespace>.gitlab.io/<project-name>`.
+
+You won't see this link if you haven't yet run your pipeline.
+
+Select the displayed link to view your site.
+
+When you first view your Hugo site, the stylesheet won't work. Don't worry, you need to make a small change in your Hugo configuration file. Hugo needs to know the URL of your GitLab Pages site so it can build relative links to stylesheets and other assets:
+
+1. In your local Hugo site, open your `config.yaml` or `config.toml` file.
+1. Change the value of the `BaseURL` parameter to match the URL that appears in your GitLab Pages settings.
+1. Push your changed file to GitLab, and your pipeline is triggered again.
+
+When the pipeline has finished, your site should be working at the URL you just specified.
+
+If your Hugo site is stored in a private repository, you'll need to change your permissions so the Pages site is visible. Otherwise, it's visible only to authorized users. To change your permissions:
+
+1. Go to **Settings > General > Visibility, project features, permissions**.
+1. Scroll down to the **Pages** section and select **Everyone** from the dropdown list.
+1. Select **Save changes**.
+
+Now everyone can see it.
+
+You've built, tested, and deployed your Hugo site with GitLab. Great work!
+
+Every time you change your site and push it to GitLab, your site is built, tested, and deployed automatically.
+
+To learn more about CI/CD pipelines, try [this tutorial on how to create a complex pipeline](../../ci/quick_start/tutorial.md). You can also learn more about the [different types of testing available](../../ci/testing/index.md).
diff --git a/doc/tutorials/infrastructure.md b/doc/tutorials/infrastructure.md
index e9035461596..688a1a1f7c7 100644
--- a/doc/tutorials/infrastructure.md
+++ b/doc/tutorials/infrastructure.md
@@ -4,7 +4,7 @@ group: Tutorials
 info: For assistance with this tutorials page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
 ---
 
-# Manage your infrastructure
+# Tutorials: Manage your infrastructure
 
 Use GitLab configuration features to reduce the effort needed to
 configure the infrastructure for your application.
diff --git a/doc/tutorials/learn_git.md b/doc/tutorials/learn_git.md
index a5b52ef73e9..6df9b3944b7 100644
--- a/doc/tutorials/learn_git.md
+++ b/doc/tutorials/learn_git.md
@@ -4,7 +4,7 @@ group: Tutorials
 info: For assistance with this tutorials page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
 ---
 
-# Learn Git
+# Tutorials: Learn Git
 
 GitLab is a Git-based platform, so understanding Git is important to get
 the most out of GitLab.
diff --git a/doc/tutorials/left_sidebar/img/shortcuts_v16_0.png b/doc/tutorials/left_sidebar/img/shortcuts_v16_0.png
deleted file mode 100644
index 07094898117..00000000000
--- a/doc/tutorials/left_sidebar/img/shortcuts_v16_0.png
+++ /dev/null
diff --git a/doc/tutorials/left_sidebar/img/sidebar_bottom_v16_1.png b/doc/tutorials/left_sidebar/img/sidebar_bottom_v16_1.png
new file mode 100644
index 00000000000..dd2c7b82d40
--- /dev/null
+++ b/doc/tutorials/left_sidebar/img/sidebar_bottom_v16_1.png
diff --git a/doc/tutorials/left_sidebar/img/sidebar_middle_v16_1.png b/doc/tutorials/left_sidebar/img/sidebar_middle_v16_1.png
new file mode 100644
index 00000000000..67e89c2c0a4
--- /dev/null
+++ b/doc/tutorials/left_sidebar/img/sidebar_middle_v16_1.png
diff --git a/doc/tutorials/left_sidebar/img/sidebar_top_v16_1.png b/doc/tutorials/left_sidebar/img/sidebar_top_v16_1.png
new file mode 100644
index 00000000000..fcb56370fc7
--- /dev/null
+++ b/doc/tutorials/left_sidebar/img/sidebar_top_v16_1.png
diff --git a/doc/tutorials/left_sidebar/index.md b/doc/tutorials/left_sidebar/index.md
index 7de50afbe77..f26849eac45 100644
--- a/doc/tutorials/left_sidebar/index.md
+++ b/doc/tutorials/left_sidebar/index.md
@@ -17,17 +17,39 @@ Provide feedback in
 
 To view the new sidebar:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Turn on the **New navigation** toggle.
 
 To turn off this sidebar, return to your avatar and turn off the toggle.
 
+## Layout of the left sidebar
+
+At the top of the left sidebar are several shortcuts. Use these shortcuts to
+show and hide the left sidebar, create new items, search, and view your profile. You can also view your list of issues,
+merge requests, and to-do items.
+
+![Top of sidebar](img/sidebar_top_v16_1.png)
+
+If you have hidden the left sidebar, you can display it temporarily by hovering your cursor over the left edge of the GitLab window.
+
+The next area of the left sidebar changes based on the information you're viewing. For example,
+you might be viewing a project, exploring projects or groups, or viewing your profile.
+Use this area to switch to other areas of the left sidebar.
+
+![Context switching](img/sidebar_middle_v16_1.png)
+
+The rest of the left sidebar is populated based on the option you choose. For example,
+if you're in a project, the sidebar is project-specific:
+
+![Project-specific options](img/sidebar_bottom_v16_1.png)
+
 ## Find your project
 
-Let's get started exploring the GitLab UI and left sidebar.
+Now let's go over a few common tasks you'll use the left sidebar for.
+
+To start, we will find the project we want to work on.
 
-1. Start by finding the project you want to work on.
-   To explore all available projects, on the left sidebar, select **Explore**:
+1. To explore all available projects, on the left sidebar, select **Explore**:
 
    ![Explore](img/explore_v16_0.png)
 
@@ -41,11 +63,6 @@ Let's get started exploring the GitLab UI and left sidebar.
 
    ![Project-specific options](img/project_selected_v16_0.png)
 
-Your issues, merge requests, and to-do items are listed in the shortcuts
-at the top:
-
-![shortcuts](img/shortcuts_v16_0.png)
-
 ## Customize the sidebar
 
 You can pin menu items if you tend to use them frequently.
diff --git a/doc/tutorials/make_first_git_commit/index.md b/doc/tutorials/make_first_git_commit/index.md
index 794b9d1f4b5..b78fcd237dd 100644
--- a/doc/tutorials/make_first_git_commit/index.md
+++ b/doc/tutorials/make_first_git_commit/index.md
@@ -83,8 +83,7 @@ Here's an overview of what we're going to do:
 
 To start, create a sample project in GitLab.
 
-1. In GitLab, on the top bar, select **Main menu > Projects > View all projects**.
-1. On the right of the page, select **New project**.
+1. In GitLab, on the left sidebar, at the top, select **Create new** (**{plus}**) and **New project/repository**.
 1. For **Project name**, enter `My sample project`. The project slug is generated for you.
    This slug is the URL you can use to access the project after it's created.
 1. Ensure **Initialize repository with a README** is selected.
diff --git a/doc/tutorials/manage_user/index.md b/doc/tutorials/manage_user/index.md
new file mode 100644
index 00000000000..b21454fa5d5
--- /dev/null
+++ b/doc/tutorials/manage_user/index.md
@@ -0,0 +1,459 @@
+---
+stage: none
+group: Tutorials
+info: For assistance with this tutorial, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
+---
+
+# Tutorial: Set up your organization **(FREE SELF)**
+
+In GitLab, you set up and manage your company's GitLab organization by:
+
+- Creating groups, subgroups, and projects.
+- Assigning group members different roles in these groups and projects.
+
+In this tutorial, you are the IT administrator of a small software company. This
+company uses GitLab and is divided into marketing, sales, and development divisions.
+
+You have already set up the marketing and sales organizations. In this tutorial,
+you will set up the software development organization. This organization has the
+following permanent employees:
+
+- One IT administrator: You.
+- One product manager: Alex Smith.
+- One engineering manager: Blake Wang.
+- Three software developers: Charlie Devi, Devon Ivanov, Evan Kim.
+- One UX designer: Frankie Ali.
+- One technical writer: Grayson Garcia.
+
+The organization also has a contractor content strategist, Hunter Silva.
+
+You're going to create:
+
+1. The software development organization.
+1. Groups, subgroups, and projects to manage work.
+1. Users to add to the groups and projects and assign roles to those users.
+1. A project in the organization for a specific piece of work, and add users to
+   that project.
+
+Prerequisites:
+
+- You have administrator access to your self-managed GitLab instance.
+
+## Create the organization parent group and subgroups
+
+You first create a group, Development, to serve as the parent group for the whole
+software development organization.
+
+1. Open your self-managed GitLab instance.
+1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New group**.
+1. Select **Create group**.
+1. In **Group name**, enter `Development`.
+1. Enter `development-group` for the group in **Group URL**. You see a message
+   saying "Group path is available". The group URL is used for the namespace.
+1. For visibility level, make the group **Private**. This means any subgroups of
+   this group must be private as well.
+1. Personalize your GitLab experience by answering the following questions:
+   - For **Role**, select **Development Team Lead**.
+     This role is different to the roles that affect member permissions.
+   - For **Who will be using this group?**, select **My company or team**.
+   - For **What will you use this group for?**, select **I want to store my code**.
+1. Do not invite any GitLab members or other users to join the group yet.
+1. Select **Create group**.
+
+> In GitLab, a namespace provides a place to organize your related projects.
+
+You have created the parent group for your organization. Next you will create subgroups.
+
+## Create the organization subgroups
+
+For this tutorial, we assume that Development is organized into the following
+working areas:
+
+- Product Management.
+- Engineering.
+- User Experience.
+  - UX Design.
+  - Technical Writing.
+
+You will now create subgroups to reflect this organization structure.
+
+> Subgroups and projects must have visibility settings that are at least as restrictive as the visibility setting of their parent group. For example, you cannot have a private parent group and a public subgroup.
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your groups**.
+1. Select **Development**. You should see an **Owner** label next to the group
+   name as you have the Owner role.
+1. On the parent group's overview page, in the upper-right corner, select **New subgroup**.
+1. In **Subgroup name**, enter `Product Management`.
+1. The **Subgroup slug** is automatically completed with **product-management**.
+   Do not change this field.
+1. For **Visibility level**, you can only select **Private** because the parent
+   group, Development, is also private.
+1. Select **Create subgroup**.
+1. Repeat for the following subgroups:
+   - `Engineering`.
+   - `User Experience`.
+     - `UX Design`.
+     - `Technical Writing`.
+
+UX Design and Technical Writing are subgroups nested in the User Experience subgroup.
+
+You have now created the subgroups for your organization. Next you will create users
+for the organization.
+
+## Create the users for your organization
+
+You will now manually create the users for your organization. These are test
+users. To create the first test user, Alex Smith:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Overview > Users**.
+1. Select **New user**.
+1. Complete the required fields:
+   - **Name**: `Alex Smith`
+   - **Username**: `alexsmith`
+   - **Email**: `alexsmith@example.com`
+   - Leave all other fields as is.
+1. Select **Create user**.
+
+For real users, a reset link is sent to the user's email, and that user is forced
+to set their password on first sign in. However, as this user is a test user with
+a fake email, you must set the user's password without using the email confirmation.
+
+### Set the test user's password
+
+1. Select the user.
+1. Select **Edit**.
+1. Complete the password and password confirmation fields.
+1. Select **Save changes**.
+
+You have created the first test user. Now repeat this for the other users:
+
+| Name              | Username         | Email                        |
+|:------------------|:-----------------|:-----------------------------|
+| `Blake Wang`      | `blakewang`      | `blakewang@example.com`      |
+| `Charlie Devi`    | `charliedevi`    | `charliedevi@example.com`    |
+| `Devon Ivanov`    | `devonivanov`    | `devonivanov@example.com`    |
+| `Evan Kim`        | `evankim`        | `evankim@example.com`        |
+| `Frankie Ali`     | `frankieali`     | `frankieali@example.com`     |
+| `Grayson Garcia`  | `graysongarcia`  | `graysongarcia@example.com`  |
+| `Hunter Silva`    | `huntersilva`    | `huntersilva@example.com`    |
+
+You have created the users for your organization. Next you will add these users
+to the different groups and subgroups.
+
+## Add users to the group and subgroups
+
+You can give users access to all projects in a group by adding them to that group.
+
+First, you will add all the users to the parent group, Development.
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the **Development** group.
+1. Select **Manage > Members**.
+1. Select **Invite members**.
+1. Complete the fields for the product manager, Alex Smith.
+   - Give Alex the **Owner** role. The role applies to all subgroups projects
+     in the group.
+   - Leave **Access expiration date** blank.
+1. Select **Invite**.
+1. Repeat this process for the following users:
+
+   | User            | Role        | Access expiration date  |
+   |:----------------|:------------|:------------------------|
+   | Blake Wang      | Maintainer  | Leave blank             |
+   | Charlie Devi    | Developer   | Leave blank             |
+   | Devon Ivanov    | Developer   | Leave blank             |
+   | Evan Kim        | Developer   | Leave blank             |
+   | Frankie Ali     | Reporter    | Leave blank             |
+   | Grayson Garcia  | Reporter    | Leave blank             |
+   | Hunter Silva    | Guest       | `2025-12-31`            |
+
+   You can invite multiple users at the same time if they have the same role and
+   access expiration date.
+
+### Confirm that everything is set up correctly
+
+On the **Group Members** page of the Development group and all subgroups, check
+the membership of these groups.
+
+> The **Source** is the origin of the user's membership of this group. The added members are direct members because you added them directly to the group.
+>
+> The **Max role** is the added members' highest level of access they are allowed to have in this group. You can use the dropdown list in this column to change the added members' roles in this group.
+
+All the users you have added as parent group members are also members of all the
+subgroups with the same role.
+
+#### Filter a subgroup on membership type
+
+You can filter a subgroup to show which users are direct members of that subgroup,
+and which members have inherited membership of that subgroup from the parent group.
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the **Development** group.
+1. Select the **User Experience** subgroup.
+1. On the left sidebar, select **Subgroup information > Members**.
+1. On the **Members** page, select the **Filter members** field.
+1. Select **Membership**, then select **Inherited**, and press <kbd>Return</kbd>.
+
+You now only see the User Experience subgroup members that have inherited membership
+of that subgroup.
+
+You want each user to only be a member of the subgroup that is associated with
+their role in your organization. You decide to remove the users from the groups
+and subgroups.
+
+## Remove users from the groups and subgroups
+
+You cannot remove the members from the subgroups directly. You can only remove
+them from the parent group.
+
+Go back to the parent group and remove everyone except Alex Smith:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the parent group.
+1. Select **Manage > Members**.
+1. On the member row you want to remove, select the vertical ellipsis (**{ellipsis_v}**)
+   and then select **Remove member**.
+1. In the **Remove member** confirmation box, select the
+   **Also remove direct user membership from subgroups and projects** checkbox.
+1. Select **Remove member**.
+
+You now have one member only in the parent group and subgroups, and that member
+has the Owner role.
+
+Next you will add users directly to the subgroups.
+
+## Add users to the subgroups
+
+You will now add users directly to the different subgroups.
+
+### Add users to the Product Management subgroup
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the **Development** group.
+1. Select the **Product Management** subgroup.
+1. On the left sidebar, select **Subgroup information > Members**.
+
+Excluding you, Alex is the only member of this subgroup and is a direct member,
+which is correct. However, you believe they should have the Maintainer role
+instead of the Owner role.
+
+#### Change user role in the subgroup
+
+You cannot change their role directly on the members page. To change their role in
+the subgroup, invite them to the subgroup as a Maintainer.
+
+1. Select **Invite members**.
+1. Complete the fields for the product manager, Alex Smith.
+   - Give Alex the **Maintainer** role.
+   - Leave **Access expiration date** blank.
+1. Select **Invite**.
+
+You will see the following message:
+
+```plaintext
+The following member couldn't be invited
+Review the invite errors and try again:
+- Alex Smith: Access level should be greater than or equal to Owner inherited membership from group Development
+```
+
+> You cannot give Alex a subgroup role with an access level less than their role in the subgroup's parent group, as they have an inherited membership from the parent group.
+
+You decide to keep Alex as an Owner in this subgroup as it is appropriate given
+their role in the organization. Select **Cancel** to cancel this invite.
+
+The Product Management subgroup has the correct members and roles. Next you will
+add users to the Engineering subgroup.
+
+### Add users to the Engineering subgroup
+
+You are now going to invite some users to the Engineering subgroup.
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the **Development** group.
+1. Select the **Engineering** subgroup.
+1. On the left sidebar, select **Subgroup information > Members**. The only
+   members are you and Alex, both with the Owner role. These are inherited roles.
+1. Select **Invite members**.
+1. Complete the fields for the following members:
+
+   | User            | Role        | Access expiration date  |
+   |:----------------|:------------|:------------------------|
+   | Blake Wang      | Maintainer  | Leave blank             |
+   | Charlie Devi    | Developer   | Leave blank             |
+   | Devon Ivanov    | Developer   | Leave blank             |
+   | Evan Kim        | Developer   | Leave blank             |
+
+1. Select **Invite**.
+
+   Blake Wang has the Maintainer role in this subgroup, in line with their responsibilities as
+   engineering manager. The three developers all have the Developer role. These are
+   direct roles.
+
+1. You can change their roles directly on this subgroup's member page. Change Blake Wang
+   to an Owner for this subgroup.
+1. Go back to the Development group's member page. You see that the members of the Engineering
+   subgroup are not members of the parent group.
+
+By adding users directly to the groups and subgroups they need to be members of,
+you avoid the issue of users being members of groups unnecessarily. You can control
+access to different groups and projects in a more precise way.
+
+## Add users to the User Experience subgroup
+
+The User Experience subgroup has two further nested subgroups:
+
+- UX Design.
+- Technical Writing.
+
+In terms of users, UX Design should only include Frankie Ali and Hunter Silva,
+and Technical Writing should only include Grayson Garcia.
+
+If you add all three users to the User Experience subgroup, they will all be
+included in both nested subgroups due to inherited permissions.
+
+Therefore, you will add these users to the appropriate nested subgroup directly
+rather than to the User Experience subgroup.
+
+1. 1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the **Development** group.
+1. Select the **User Experience** subgroup, and then the **UX Design** subgroup.
+1. On the left sidebar, select **Subgroup information > Members**. You and Alex
+   Smith are currently the only members. These are inherited roles.
+1. Select **Invite members**.
+1. Complete the fields and select **Invite** for the following members:
+
+   | User            | Role        | Access expiration date  |
+   |:----------------|:------------|:------------------------|
+   | Frankie Ali     | Maintainer  | Leave blank             |
+   | Hunter Silva    | Guest       | `2025-12-31`            |
+
+1. Repeat for the **Technical Writing** subgroup:
+
+   | User            | Role        | Access expiration date  |
+   |:----------------|:------------|:------------------------|
+   | Grayson Garcia  | Maintainer  | Leave blank             |
+
+You have added the users to their appropriate nested subgroups. You decide that
+Grayson Garcia should be in the **User Experience** subgroup as well.
+
+### Add users to other subgroups
+
+You can add Grayson to the **User Experience** subgroup as a specific role, while
+keeping their role in the **Technical Writing** subgroup the same.
+
+1. Go to the **User Experience** subgroup.
+1. On the left sidebar, select **Subgroup information > Members**. You and Alex
+   Smith are currently the only members. These are inherited roles.
+1. Select **Invite members**.
+1. Invite Grayson Garcia as a Developer, a role with a lower level of permissions
+   than their Maintainer role in the **Technical Writing** subgroup.
+
+This means that Grayson Garcia does not have an unnecessarily high level of permissions
+in the User Experience subgroup.
+
+However, due to inherited permissions, adding Grayson Garcia to the User Experience
+subgroup also adds them to the UX Design nested subgroup as a Developer.
+
+> Be mindful of inherited permissions for groups and subgroups. Add users to a minimum number of groups and subgroups to minimize the chance of inadvertently adding a user to a group they do not need to be a member of.
+
+1. Go to the User Experience subgroup members page.
+1. Add Frankie Ali and Hunter Silva as **Reporters**. Give Hunter the same expiration date.
+1. Go the Technical Writing nested subgroup.
+
+Frankie Ali and Hunter Silva are now members of the Technical Writing subgroup
+due to inherited permissions.
+
+You have successfully set up your organization with groups, subgroups and members.
+
+Next you will create a project in one of the groups for members to work on.
+
+## Create a project
+
+Now, let's assume that you have a piece of work that certain members of your organization
+need to work on, and that piece of work is for the whole organization. To organize
+that work, you are going to create a project in the Development parent group, and
+add different users to that project.
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the **Development** group.
+1. Select **Create new** (**{plus}**) and **New project/repository**.
+1. Select **Create blank project**.
+1. Enter the project details:
+   - In the **Project name** field, enter `Release 2.0` as the name of your project.
+   - Leave the **Project slug** field as is, which is based on the project name.
+   - To modify the project's viewing and access rights for users, you can change
+     the **Visibility Level**. Given that the parent group is private, the project
+     can only be **Private** as well.
+   - To create a `README` file so that the Git repository is initialized, has a
+     default branch, and can be cloned, select the **Initialize repository with a README**
+     checkbox.
+   - To analyze the source code in the project for known security vulnerabilities,
+     select the **Enable Static Application Security Testing (SAST)** checkbox.
+1. Select **Create project**.
+
+You have now created a project in the parent group.
+
+In this project, go to **Project information > Members**.
+
+The existing members of the parent group (you and Alex) are already members of
+this project because when your project belongs to a group, project members inherit
+their role from the group.
+
+There are other users that need to be part of this project. You will now add users
+directly to the project.
+
+## Add users to the project and parent group
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the **Release 2.0** project.
+1. On the left sidebar, select **Manage > Members**.
+1. Select **Invite members**. Invite the following users:
+
+   | User            | Role          | Access expiration date  |
+   |:----------------|:--------------|:------------------------|
+   | Charlie Devi    | Maintainer    | Leave blank             |
+   | Frankie Ali     | Maintainer    | Leave blank             |
+   | Grayson Garcia  | Maintainer    | Leave blank             |
+
+1. Select **Invite**.
+1. Because you added these users directly to the project, you can change
+   their roles on the project members page if needed. Change Grayson Garcia's role
+   to **Developer** to test this out.
+1. Go to the Development parent group members page. The users you just added
+   to the project are not there despite the project being in the parent group.
+1. Add the same users directly to the parent group with **Guest** roles. You can change
+   their role directly on this page. Change Frankie's role to **Reporter**.
+1. Go back to the Release 2.0 project members page. The members' project roles are
+   still 2 Maintainers and 1 Developer.
+
+You have successfully added three users who are members of subgroups to a project
+in the parent group, and given those users specific roles in the project and
+parent group.
+
+## Change the visibility of individual features in a project
+
+You have already seen how you can control access to and permissions in groups and
+projects by assigning roles.
+
+You can also change the visibility of individual features in a project. You cannot
+do this for groups.
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the **Release 2.0** project.
+1. Select **Settings > General**.
+1. Expand **Visibility, project features, permissions**.
+1. In **Project visibility**, you can who can see the project in the public access
+   directory. Because the parent group is private, you can only select **Private**.
+
+You will now use the toggle by each feature to turn features on or off, or change access for.
+
+1. For **Issues**, leave the feature turned on.
+1. In the **Repository** section:
+   - Leave **Merge requests** and **Forks** turned on.
+   - Turn off **Git Large File Storage (LFS)** and **CI/CD**.
+1. For **Analytics**, **Security and Compliance**, **Wiki**, **Snippets**, and
+   **Package registry**, leave these features turned on.
+1. Turn off **Monitor**, **Environments**, **Feature flags**, **Infrastructure**,
+   and **Releases**.
+1. Select the **Disable email notifications** checkbox. Leave the other checkboxes as is.
+1. Select **Save changes**.
+
+You have changed the visibility of individual features in a project. Now, regardless
+of role, the members of this project cannot access the features that you have turned off.
+
+In this tutorial, you've set up your groups, subgroups, projects, and members
+with roles precisely to reflect the structure and workflow of your organization.
diff --git a/doc/tutorials/more_tutorials.md b/doc/tutorials/more_tutorials.md
index c52de180bff..19b3a709ab7 100644
--- a/doc/tutorials/more_tutorials.md
+++ b/doc/tutorials/more_tutorials.md
@@ -13,8 +13,8 @@ If you're learning about GitLab, to find more tutorial content:
 
 - Find recent tutorials on the GitLab blog by [searching by the `tutorial` tag](https://about.gitlab.com/blog/tags.html#tutorial).
 
-- Browse the **Learn@GitLab** [playlist on YouTube](https://www.youtube.com/playlist?list=PLFGfElNsQthYDx0A_FaNNfUm9NHsK6zED)
+- Browse the **GitLab Snapshots** [playlist on YouTube](https://www.youtube.com/playlist?list=PLFGfElNsQthYDx0A_FaNNfUm9NHsK6zED)
   to find video tutorials.
 
 If you find an article, video, or other resource that would be a
-great addition to this page, add it in a [merge request](../development/documentation/index.md).
+great addition to the tutorial pages, add it in a [merge request](../development/documentation/index.md).
diff --git a/doc/tutorials/move_personal_project_to_group/index.md b/doc/tutorials/move_personal_project_to_group/index.md
index d3e695b78df..65d7e8d07e5 100644
--- a/doc/tutorials/move_personal_project_to_group/index.md
+++ b/doc/tutorials/move_personal_project_to_group/index.md
@@ -40,8 +40,7 @@ Maintainer role for the group.
 
 If you don't have a group, create one:
 
-1. On the top bar, select **Main menu > Groups > View all groups**.
-1. On the right of the page, select **New group**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New group**.
 1. In **Group name**, enter a name for the group.
 1. In **Group URL**, enter a path for the group, which is used as the namespace.
 1. Choose the [visibility level](../../user/public_access.md).
@@ -58,8 +57,8 @@ Before you move your project to a group:
 
 Now you're ready to move your project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Advanced**.
 1. Under **Transfer project**, choose the group to transfer the project to.
 1. Select **Transfer project**.
@@ -79,7 +78,7 @@ your related resources and tools, such as websites and package managers.
 
 You can now view your project in your group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. Look for your project under **Subgroups and projects**.
 
 Start enjoying the benefits of a group! For example, as the group Owner, you can
diff --git a/doc/tutorials/plan_and_track.md b/doc/tutorials/plan_and_track.md
index 35b552cdaa5..657ade465b7 100644
--- a/doc/tutorials/plan_and_track.md
+++ b/doc/tutorials/plan_and_track.md
@@ -4,7 +4,7 @@ group: Tutorials
 info: For assistance with this tutorials page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
 ---
 
-# Plan and track your work
+# Tutorials: Plan and track your work
 
 Create a project to host your code, and plan your work using
 issues, epics, and more.
@@ -15,4 +15,5 @@ issues, epics, and more.
 | [Create a project from a template](https://gitlab.com/projects/new#create_from_template) | Choose a project template and create a project with files to get you started. | |
 | [Migrate to GitLab](../user/project/import/index.md) | If you are coming to GitLab from another platform, you can import or convert your projects. | |
 | [Run an agile iteration](agile_sprint/index.md) | Use group, projects, and iterations to run an agile development iteration. |
+| [Set up issue boards for team hand-off](boards_for_teams/index.md) | Use issue boards and scoped labels to set up collaboration across many teams. | **{star}** |
 | <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [Epics and Issue Boards](https://www.youtube.com/watch?v=I1bFIAQBHB8) | Find out how to use epics and issue boards for project management. | |
diff --git a/doc/tutorials/scan_result_policy/index.md b/doc/tutorials/scan_result_policy/index.md
index 6f4feb9ec4f..89bd2e099b6 100644
--- a/doc/tutorials/scan_result_policy/index.md
+++ b/doc/tutorials/scan_result_policy/index.md
@@ -24,8 +24,7 @@ To set up a scan result policy:
 
 ## Create a test project
 
-1. On the top bar, select **Main menu > Projects**.
-1. Select **New project**.
+1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New project/repository**.
 1. Select **Create blank project**.
 1. Complete the fields.
    - **Project name**: `sast-scan-result-policy`.
@@ -36,8 +35,8 @@ To set up a scan result policy:
 
 Next, you'll add a scan result policy to your test project:
 
-1. On the top bar, select **Main menu > Projects** and find the `sast-scan-result-policy` project.
-1. On the left sidebar, go to **Security and Compliance > Policies**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `sast-scan-result-policy` project.
+1. Select **Secure > Policies**.
 1. Select **New policy**.
 1. In **Scan result policy**, select **Select policy**.
 1. Complete the fields.
@@ -61,8 +60,8 @@ Next, you'll add a scan result policy to your test project:
    The application creates a new project to store the policies linked to it, and creates a merge request to define the policy.
 
 1. Select **Merge**.
-1. On the top bar, select **Main menu > Projects** and select the `sast-scan-result-policy` project.
-1. On the left sidebar, select **Security and Compliance > Policies**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `sast-scan-result-policy` project.
+1. Select **Secure > Policies**.
 
    You can see the list of policies added in the previous steps.
 
@@ -70,8 +69,8 @@ Next, you'll add a scan result policy to your test project:
 
 Nice work, you've created a scan result policy. To test it, create some vulnerabilities and check the result:
 
-1. On the top bar, select **Main menu > Projects** and select the `sast-scan-result-policy` project.
-1. On the left sidebar, select **Repository > Files**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the `sast-scan-result-policy` project.
+1. Select **Code > Repository**.
 1. From the **Add** (**{plus}**) dropdown list, select **New file**.
 1. In the **Filename** field enter `main.ts`.
 1. In the file's content, copy the following:
diff --git a/doc/tutorials/secure_application.md b/doc/tutorials/secure_application.md
index 5b7d8733d63..54235d0a6dc 100644
--- a/doc/tutorials/secure_application.md
+++ b/doc/tutorials/secure_application.md
@@ -4,14 +4,15 @@ group: Tutorials
 info: For assistance with this tutorials page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
 ---
 
-# Secure your application and check compliance
+# Tutorials: Secure your application and check compliance
 
 GitLab can check your application for security vulnerabilities and that it meets compliance requirements.
 
 | Topic | Description | Good for beginners |
 |-------|-------------|--------------------|
-| [Set up dependency scanning](https://about.gitlab.com/blog/2021/01/14/try-dependency-scanning/) | Try out dependency scanning, which checks for known vulnerabilities in dependencies. | **{star}** |
+| [Set up dependency scanning](dependency_scanning.md) | Learn how to detect vulnerabilities in an application's dependencies. | **{star}** |
 | [Create a compliance pipeline](compliance_pipeline/index.md) | Learn how to create compliance pipelines for your groups. | **{star}** |
 | [Set up a scan result policy](scan_result_policy/index.md) | Learn how to configure a scan result policy that takes action based on scan results. | **{star}** |
+| [Scan a Docker container for vulnerabilities](container_scanning/index.md) | Learn how to use container scanning templates to add container scanning to your projects. | **{star}** |
 | [Get started with GitLab application security](../user/application_security/get-started-security.md) | Follow recommended steps to set up security tools. | |
 | [GitLab Security Essentials](https://levelup.gitlab.com/courses/security-essentials) | Learn about the essential security capabilities of GitLab in this self-paced course. | |
diff --git a/doc/update/background_migrations.md b/doc/update/background_migrations.md
index be6ad43fa8a..bf9f2df9e87 100644
--- a/doc/update/background_migrations.md
+++ b/doc/update/background_migrations.md
@@ -96,8 +96,9 @@ Batched background migrations are handled by Sidekiq and [run in isolation](../d
 
 To check the status of batched background migrations:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Monitoring > Background Migrations**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Monitoring > Background Migrations**.
 
    ![queued batched background migrations table](img/batched_background_migrations_queued_v14_0.png)
 
@@ -207,11 +208,8 @@ Feature.disable(:optimize_batched_migrations)
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/104027)
 >   in GitLab 15.7, [behind a feature flag](../user/feature_flags.md),
->   [enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/372316).
-> - Enabled on GitLab.com.
-> - Recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to
->   [disable it](#enable-or-disable-parallel-execution-for-batched-background-migrations).
+> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/372316) in GitLab 15.11.
+> - Feature flag `batched_migrations_parallel_execution` removed in GitLab 16.1.
 
 There can be [risks when disabling released features](../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
@@ -225,25 +223,6 @@ the number of batched background migrations executed in parallel:
 ApplicationSetting.update_all(database_max_running_batched_background_migrations: 4)
 ```
 
-#### Enable or disable parallel execution for batched background migrations
-
-Parallel execution for batched background migrations is under development but ready for production use.
-It is deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../administration/feature_flags.md)
-can opt to disable it.
-
-To enable it:
-
-```ruby
-Feature.enable(:batched_migrations_parallel_execution)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:batched_migrations_parallel_execution)
-```
-
 ## Troubleshooting
 
 ### Enable or disable background migrations
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index e30782c70a3..ecf0f68de0e 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -7,6 +7,18 @@ toc: false
 
 # Deprecations by version
 
+These GitLab features are deprecated and no longer recommended for use.
+Each deprecated feature will be removed in a future release.
+Some features cause breaking changes when they are removed.
+
+On GitLab.com, deprecated features can be removed at any time during the month leading up to the release.
+
+**{rss}** **To be notified of upcoming breaking changes**,
+add this URL to your RSS feed reader: `https://about.gitlab.com/breaking-changes.xml`
+
+You can also view [REST API](https://docs.gitlab.com/ee/api/rest/deprecations.html)
+and [GraphQL](https://docs.gitlab.com/ee/api/graphql/removed_items.html) deprecations/removals.
+
 <!-- vale off -->
 
 <!--
@@ -31,18 +43,6 @@ For deprecation reviewers (Technical Writers only):
 
 {::options parse_block_html="true" /}
 
-These GitLab features are deprecated and no longer recommended for use.
-Each deprecated feature will be removed in a future release.
-Some features cause breaking changes when they are removed.
-
-On GitLab.com, deprecated features can be removed at any time during the month leading up to the release.
-
-**{rss}** **To be notified of upcoming breaking changes**,
-add this URL to your RSS feed reader: `https://about.gitlab.com/breaking-changes.xml`
-
-You can also view [REST API](https://docs.gitlab.com/ee/api/rest/deprecations.html)
-and [GraphQL](https://docs.gitlab.com/ee/api/graphql/removed_items.html) deprecations/removals.
-
 <div class="js-deprecation-filters"></div>
 <div class="milestone-wrapper" data-milestone="17.0">
 
@@ -155,6 +155,21 @@ These three variables will be removed in GitLab 17.0.
 
 </div>
 
+<div class="deprecation breaking-change" data-milestone="17.0">
+
+### Deprecate Windows CMD in GitLab Runner
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">16.1</span>
+- End of Support: GitLab <span class="milestone">17.0</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/414864).
+</div>
+
+In GitLab 11.11 the Windows Batch executor, the CMD shell was deprecated in GitLab Runner in favor of PowerShell. Since then, the CMD shell has continued to be supported in GitLab Runner. However this has resulted in additional complexity for both the engineering team and customers using the Runner on Windows. We plan to fully remove support for Windows CMD from GitLab Runner in 17.0. Customers should plan to use PowerShell when using the runner on Windows with the shell executor. Customers can provide feedback or ask questions in the removal issue, [issue 29479](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29479).
+
+</div>
+
 <div class="deprecation " data-milestone="17.0">
 
 ### Deprecate legacy shell escaping and quoting runner shell executor
@@ -259,7 +274,8 @@ are deprecated and will be removed from the GraphQL API. For installation instru
 </div>
 
 The [`runner-registration-token`](https://docs.gitlab.com/runner/install/operator.html#install-the-kubernetes-operator) parameter that uses the OpenShift and Kubernetes Vanilla Operator to install a runner on Kubernetes is deprecated. Authentication tokens will be used to register runners instead. Registration tokens, and support for certain configuration arguments,
-will be disabled behind a feature flag in GitLab 16.6 and removed in GitLab 17.0. The configuration arguments disabled for authentication tokens are:
+will be removed in GitLab 17.0. For more information, see [Migrating to the new runner registration workflow](../ci/runners/new_creation_workflow.md).
+The configuration arguments disabled for authentication tokens are:
 
 - `--locked`
 - `--access-level`
@@ -272,6 +288,22 @@ This change is a breaking change. You should use an [authentication token](../ci
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
+### GraphQL deprecation of `dependencyProxyTotalSizeInBytes` field
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">16.1</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/414236).
+</div>
+
+You can use GraphQL to query the amount of storage used by the GitLab Dependency Proxy. However, the `dependencyProxyTotalSizeInBytes` field is limited to ~2Gb (in bytes), which is not always large enough for the Dependency Proxy. As a result, `dependencyProxyTotalSizeInBytes` is deprecated and will be removed in GitLab 17.0.
+
+Use `dependencyProxyTotalSizeBytes` instead, introduced in GitLab 16.1.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
 ### GraphQL type, `RunnerMembershipFilter` renamed to `CiRunnerMembershipFilter`
 
 <div class="deprecation-notes">
@@ -361,7 +393,7 @@ In milestone 17.0, we will remove the `pipelines` attribute from the API respons
 - To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/343475).
 </div>
 
-The [`project_fingerprint`](https://gitlab.com/groups/gitlab-org/-/epics/2791) attribute of vulnerability findings is being deprecated in favor of a `uuid` attribute. By using UUIDv5 values to identify findings, we can easily associate any related entity with a finding. The `project_fingerprint` attribute is no longer being used to track findings, and will be removed in GitLab 17.0.
+The [`project_fingerprint`](https://gitlab.com/groups/gitlab-org/-/epics/2791) attribute of vulnerability findings is being deprecated in favor of a `uuid` attribute. By using UUIDv5 values to identify findings, we can easily associate any related entity with a finding. The `project_fingerprint` attribute is no longer being used to track findings, and will be removed in GitLab 17.0.  Starting in 16.1, the output of `project_fingerprint` returns the same value as the `uuid` field.
 
 </div>
 
@@ -419,7 +451,9 @@ While the above approach is recommended for most instances, Sidekiq can also be
 The support for registration tokens and certain runner configuration arguments in the `POST` method operation on the `/api/v4/runners` endpoint is deprecated.
 This endpoint [registers](https://docs.gitlab.com/ee/api/runners.html#register-a-new-runner) a runner
 with a GitLab instance at the instance, group, or project level through the API. Registration tokens, and support for certain configuration arguments,
-will be disabled behind a feature flag in GitLab 16.6 and removed in GitLab 17.0. The configuration arguments disabled for authentication tokens are:
+will start returning the HTTP `410 Gone` status code in GitLab 17.0. For more information, see [Migrating to the new runner registration workflow](../ci/runners/new_creation_workflow.md).
+
+The configuration arguments disabled for authentication tokens are:
 
 - `--locked`
 - `--access-level`
@@ -446,7 +480,8 @@ This change is a breaking change. You should [create a runner in the UI](../ci/r
 
 Registration tokens and certain configuration arguments in the command `gitlab-runner register` that [registers](https://docs.gitlab.com/runner/register/) a runner, are deprecated.
 Authentication tokens will be used to register runners instead. Registration tokens, and support for certain configuration arguments,
-will be disabled behind a feature flag in GitLab 16.6 and removed in GitLab 17.0. The configuration arguments disabled for authentication tokens are:
+will be removed in GitLab 17.0. For more information, see [Migrating to the new runner registration workflow](../ci/runners/new_creation_workflow.md).
+The configuration arguments disabled for authentication tokens are:
 
 - `--locked`
 - `--access-level`
@@ -479,6 +514,20 @@ that is available now. We recommend this alternative solution because it provide
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
+### Running a single database is deprecated
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">16.1</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/411239).
+</div>
+
+The option to run self-managed installations of GitLab on a single database is now deprecated. From GitLab 17.0, we will require a [separate database for CI features](https://gitlab.com/groups/gitlab-org/-/epics/7509). With this change, self-managed versions of GitLab will behave similarly to GitLab.com. This change applies to installation methods with Omnibus GitLab, GitLab Helm chart, GitLab Operator, GitLab Docker images, and installation from source. Before upgrading to GitLab 17.0, please ensure [migration](https://docs.gitlab.com/ee/administration/postgresql/multiple_databases.html) to two databases.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
 ### Self-managed certificate-based integration with Kubernetes
 
 <div class="deprecation-notes">
@@ -513,6 +562,8 @@ For updates and details about this deprecation, follow [this epic](https://gitla
 - To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/387898).
 </div>
 
+This deprecation is now superseded by another [deprecation notice](#running-a-single-database-is-deprecated).
+
 Previously, [GitLab's database](https://docs.gitlab.com/omnibus/settings/database.html)
 configuration had a single `main:` section. This is being deprecated. The new
 configuration has both a `main:` and a `ci:` section.
@@ -556,7 +607,7 @@ we'll be introducing support in [this epic](https://gitlab.com/groups/gitlab-org
 </div>
 
 The support for runner registration tokens is deprecated. As a consequence, the REST API endpoints to reset a registration token are also deprecated and will
-be removed in GitLab 17.0.
+return the HTTP `410 Gone` status code in GitLab 17.0.
 The deprecated endpoints are:
 
 - `POST /runners/reset_registration_token`
@@ -631,6 +682,43 @@ In some cases, like when a downstream pipeline had the `passed with warnings` st
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
+### Unified approval rules are deprecated
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">16.1</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/groups/gitlab-org/-/epics/9662).
+</div>
+
+Unified approval rules are deprecated in favor of multiple approval rules, which provide more flexibility.
+You might not be able to migrate your Unified approval rules to multiple approval rules without breaking changes.
+To help you migrate manually, we introduced migration documentation. If you don't migrate manually before unified approval
+rules are removed, GitLab will automatically migrate your settings.
+
+In GitLab 15.11, UI support for unified approval rules was removed.
+You can still access unified approval rules with the API.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
+### Vulnerability confidence field
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.4</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/372332).
+</div>
+
+In GitLab 15.3, [security report schemas below version 15 were deprecated](https://docs.gitlab.com/ee/update/deprecations.html#security-report-schemas-version-14xx).
+The `confidence` attribute on vulnerability findings exists only in schema versions before `15-0-0`, and therefore is effectively deprecated since GitLab 15.4 supports schema version `15-0-0`. To maintain consistency
+between the reports and our public APIs, the `confidence` attribute on any vulnerability-related components of our GraphQL API is now deprecated and will be
+removed in 17.0.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
 ### `runnerRegistrationToken` parameter for GitLab Runner Helm Chart
 
 <div class="deprecation-notes">
@@ -708,34 +796,22 @@ Previous work helped [align the vulnerabilities calls for pipeline security tabs
 </div>
 </div>
 
-<div class="milestone-wrapper" data-milestone="16.6">
+<div class="milestone-wrapper" data-milestone="16.5">
 
-## GitLab 16.6
+## GitLab 16.5
 
-<div class="deprecation breaking-change" data-milestone="16.6">
+<div class="deprecation " data-milestone="16.5">
 
-### Error Tracking UI in GitLab Rails is deprecated
+### Adding non-LDAP synced members to a locked LDAP group is deprecated
 
 <div class="deprecation-notes">
-- Announced in: GitLab <span class="milestone">15.9</span>
-- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/389991).
+- Announced in: GitLab <span class="milestone">16.0</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/213311).
 </div>
 
-The [Error Tracking UI](https://docs.gitlab.com/ee/operations/error_tracking.html) is deprecated in 15.9 and will be removed in 16.6 (milestone might change) once GitLab Observability UI is made available. In future versions, you should use the [GitLab Observability UI](https://gitlab.com/gitlab-org/opstrace/opstrace-ui/), which will gradually be made available on GitLab.com over the next few releases.
-
-During the transition to the GitLab Observability UI, we will migrate the [GitLab Observability Backend](https://gitlab.com/gitlab-org/opstrace/opstrace) from a per-cluster deployment model to a per-tenant deployment model. Because [Integrated Error Tracking](https://docs.gitlab.com/ee/operations/error_tracking.html#integrated-error-tracking) is in Open Beta, we will not migrate any existing user data. For more details about the migration, see the direction pages for:
-
-- [Observability](https://about.gitlab.com/direction/monitor/observability/data-visualization/).
-- The [Observability Backend](https://about.gitlab.com/direction/monitor/observability/data-management/).
-- [Data visualization](https://about.gitlab.com/direction/monitor/observability/data-visualization/).
+Enabling the `ldap_settings_unlock_groups_by_owners` feature flag allowed non-LDAP synced users to be added to a locked LDAP group. This [feature](https://gitlab.com/gitlab-org/gitlab/-/issues/1793) has always been disabled by default and behind a feature flag. We are removing this feature to keep continuity with our SAML integration, and because allowing non-synced group members defeats the "single source of truth" principle of using a directory service. Once this feature is removed, any LDAP group members that are not synced with LDAP will lose access to that group.
 
 </div>
-</div>
-
-<div class="milestone-wrapper" data-milestone="16.5">
-
-## GitLab 16.5
 
 <div class="deprecation breaking-change" data-milestone="16.5">
 
@@ -825,8 +901,8 @@ be available in CI/CD jobs.
 </div>
 
 The version of [Grafana bundled with Omnibus GitLab](https://docs.gitlab.com/omnibus/settings/grafana.html) is
-disabled in 16.0 and will be removed in 16.3.
-If you are using the bundled Grafana, you must migrate to either:
+[deprecated and disabled](https://docs.gitlab.com/ee/administration/monitoring/performance/grafana_configuration.html#deprecation-of-bundled-grafana)
+in 16.0 and will be removed in 16.3. If you are using the bundled Grafana, you must migrate to either:
 
 - Another implementation of Grafana. For more information, see
   [Switch to new Grafana instance](https://docs.gitlab.com/ee/administration/monitoring/performance/grafana_configuration.html#switch-to-new-grafana-instance).
@@ -944,8 +1020,8 @@ The version of Grafana that the GitLab Helm Chart is currently providing is no l
 If you're using the bundled Grafana, you should switch to the [newer chart version from Grafana Labs](https://artifacthub.io/packages/helm/grafana/grafana)
 or a Grafana Operator from a trusted provider.
 
-In your new Grafana instance, you can [configure the GitLab provided Prometheus as a data source](https://docs.gitlab.com/ee/administration/monitoring/performance/grafana_configuration.html#integration-with-gitlab-ui)
-and [connect Grafana to the GitLab UI](https://docs.gitlab.com/ee/administration/monitoring/performance/grafana_configuration.html#integration-with-gitlab-ui).
+In your new Grafana instance, you can [configure the GitLab provided Prometheus as a data source](https://docs.gitlab.com/ee/administration/monitoring/performance/grafana_configuration.html#configure-grafana)
+and [connect Grafana to the GitLab UI](https://docs.gitlab.com/ee/administration/monitoring/performance/grafana_configuration.html#integrate-with-gitlab-ui).
 
 </div>
 
@@ -1949,7 +2025,7 @@ The following templates will be updated:
 - Dependency Scanning: [`Dependency-Scanning.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Dependency-Scanning.gitlab-ci.yml)
 - IaC Scanning: [`SAST-IaC.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST-IaC.gitlab-ci.yml)
 - SAST: [`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml)
-- Secret Detection: [`Secret-Detection.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detction.gitlab-ci.yml)
+- Secret Detection: [`Secret-Detection.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml)
 
 We recommend that you test your pipelines before the 16.0 release if you use one of the templates listed above and you use the `_DISABLED` variables but set a value other than `"true"`.
 
@@ -2184,23 +2260,6 @@ Moving forward, we'll continue to invest in developing and releasing new feature
 
 <div class="deprecation breaking-change" data-milestone="16.0">
 
-### Vulnerability confidence field
-
-<div class="deprecation-notes">
-- Announced in: GitLab <span class="milestone">15.4</span>
-- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/372332).
-</div>
-
-In GitLab 15.3, [security report schemas below version 15 were deprecated](https://docs.gitlab.com/ee/update/deprecations.html#security-report-schemas-version-14xx).
-The `confidence` attribute on vulnerability findings exists only in schema versions before `15-0-0`, and therefore is effectively deprecated since GitLab 15.4 supports schema version `15-0-0`. To maintain consistency
-between the reports and our public APIs, the `confidence` attribute on any vulnerability-related components of our GraphQL API is now deprecated and will be
-removed in 16.0.
-
-</div>
-
-<div class="deprecation breaking-change" data-milestone="16.0">
-
 ### Work items path with global ID at the end of the path is deprecated
 
 <div class="deprecation-notes">
diff --git a/doc/update/index.md b/doc/update/index.md
index 00c55f1e4b4..0380f1a69ef 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -140,6 +140,11 @@ To clean up the migration, upgrade to 15.1 or later.
 
 For other advanced search migrations stuck in pending, see [how to retry a halted migration](../integration/advanced_search/elasticsearch.md#retry-a-halted-migration).
 
+If you upgrade GitLab before all pending advanced search migrations are completed, any pending migrations
+that have been removed in the new version cannot be executed or retried.
+In this case, you must
+[re-create your index from scratch](../integration/advanced_search/elasticsearch_troubleshooting.md#last-resort-to-recreate-an-index).
+
 ### What do you do for the error `Elasticsearch version not compatible`
 
 Confirm that your version of Elasticsearch or OpenSearch is [compatible with your version of GitLab](../integration/advanced_search/elasticsearch.md#version-requirements).
@@ -265,11 +270,30 @@ NOTE:
 Specific information that follow related to Ruby and Git versions do not apply to [Omnibus installations](https://docs.gitlab.com/omnibus/)
 and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with appropriate Ruby and Git versions and are not using system binaries for Ruby and Git. There is no need to install Ruby or Git when utilizing these two approaches.
 
+### 16.1.0
+
+- A `MigrateHumanUserType` background migration will be finalized with
+    the `FinalizeUserTypeMigration` migration.
+    GitLab 16.0 introduced a [batched background migration](background_migrations.md#batched-background-migrations) to
+    [migrate `user_type` values from `NULL` to `0`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115849). This
+    migration may take multiple days to complete on larger GitLab instances. Make sure the migration
+    has completed successfully before upgrading to 16.1.0.
+- A `BackfillPreparedAtMergeRequests` background migration will be finalized with
+  the `FinalizeBackFillPreparedAtMergeRequests` post-deploy migration.
+  GitLab 15.10.0 introduced a [batched background migration](background_migrations.md#batched-background-migrations) to
+  [backfill `prepared_at` values on the `merge_requests` table](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111865). This
+  migration may take multiple days to complete on larger GitLab instances. Make sure the migration
+  has completed successfully before upgrading to 16.1.0.
+
 ### 16.0.0
 
+- Sidekiq crashes if there are non-ASCII characters in the GitLab.rb file. You can fix this
+  by following the workaround in [issue 412767](https://gitlab.com/gitlab-org/gitlab/-/issues/412767#note_1404507549).
 - Sidekiq jobs are only routed to `default` and `mailers` queues by default, and as a result,
   every Sidekiq process also listens to those queues to ensure all jobs are processed across
   all queues. This behavior does not apply if you have configured the [routing rules](../administration/sidekiq/processing_specific_job_classes.md#routing-rules).
+- Docker 20.10.10 or later is required to run the GitLab Docker image. Older versions
+  [throw errors on startup](../install/docker.md#threaderror-cant-create-thread-operation-not-permitted).
 
 ### 15.11.1
 
@@ -1174,6 +1198,8 @@ for how to proceed.
       sudo gitlab-rake "gitlab:password:reset[user_handle]"
       ```
 
+- If you encounter the error, `I18n::InvalidLocale: :en is not a valid locale`, when starting the application, follow the [patching](https://about.gitlab.com/handbook/support/workflows/patching_an_instance.html) process. Use [122978](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122978) as the `mr_iid`.
+
 ### 14.2.0
 
 - [Instances running 14.0.0 - 14.0.4 should not upgrade directly to GitLab 14.2 or later](#upgrading-to-later-14y-releases).
@@ -1213,6 +1239,8 @@ for how to proceed.
   end
   ```
 
+- If you encounter the error, `I18n::InvalidLocale: :en is not a valid locale`, when starting the application, follow the [patching](https://about.gitlab.com/handbook/support/workflows/patching_an_instance.html) process. Use [123476](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123476) as the `mr_iid`.
+
 ### 14.1.0
 
 - [Instances running 14.0.0 - 14.0.4 should not upgrade directly to GitLab 14.2 or later](#upgrading-to-later-14y-releases)
@@ -1230,6 +1258,8 @@ for how to proceed.
 
 - See [Maintenance mode issue in GitLab 13.9 to 14.4](#maintenance-mode-issue-in-gitlab-139-to-144).
 
+- If you encounter the error, `I18n::InvalidLocale: :en is not a valid locale`, when starting the application, follow the [patching](https://about.gitlab.com/handbook/support/workflows/patching_an_instance.html) process. Use [123475](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123475) as the `mr_iid`.
+
 ### 14.0.0
 
 Prerequisites:
diff --git a/doc/update/patch_versions.md b/doc/update/patch_versions.md
index b6530418f97..964c6430a16 100644
--- a/doc/update/patch_versions.md
+++ b/doc/update/patch_versions.md
@@ -4,7 +4,7 @@ group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Universal update guide for patch versions of source installations **(FREE SELF)**
+# Universal update guide for patch versions for self-compiled installations **(FREE SELF)**
 
 ## Select Version to Install
 
diff --git a/doc/update/plan_your_upgrade.md b/doc/update/plan_your_upgrade.md
index e1354ea3665..9378b104c81 100644
--- a/doc/update/plan_your_upgrade.md
+++ b/doc/update/plan_your_upgrade.md
@@ -122,8 +122,9 @@ to your instance and then upgrade it for any relevant features you're using.
   [turning on maintenance mode](../administration/maintenance_mode/index.md) during the
   upgrade.
 - About PostgreSQL:
-  - On the top bar, select **Main menu > Admin**, and look for the version of
-    PostgreSQL you are using.
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
+  1. Look for the version of PostgreSQL you are using.
     If [a PostgreSQL upgrade is needed](../administration/package_information/postgresql_versions.md),
     account for the relevant
     [packaged](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server)
diff --git a/doc/update/removals.md b/doc/update/removals.md
index 7359d74c6f5..a5cd33e50d9 100644
--- a/doc/update/removals.md
+++ b/doc/update/removals.md
@@ -6,7 +6,7 @@ info: "See the Technical Writers assigned to Development Guidelines: https://abo
 
 # Removals by version
 
-In each release, GitLab removes features that were deprecated in an earlier release.
+In each release, GitLab removes features that were [deprecated](deprecations.md) in an earlier release.
 Some features cause breaking changes when they are removed.
 
 **{rss}** **To be notified of upcoming breaking changes**,
@@ -34,13 +34,17 @@ For removal reviewers (Technical Writers only):
   https://about.gitlab.com/handbook/marketing/blog/release-posts/#update-the-removals-doc
 -->
 
+{::options parse_block_html="true" /}
+
 ## Removed in 16.0
 
 ### Auto DevOps no longer provisions a database by default
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/343988).
+</div>
 
 Currently, Auto DevOps provisions an in-cluster PostgreSQL database by default.
 In GitLab 16.0, databases will be provisioned only for users who opt in. This
@@ -51,9 +55,11 @@ set the `POSTGRES_ENABLED` CI/CD variable to `true`.
 
 ### Azure Storage Driver defaults to the correct root prefix
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/container-registry/-/issues/854).
+</div>
 
 The Azure Storage Driver used to write to `//` as the default root directory. This default root directory appeared in some places in the Azure UI as `/<no-name>/`. We maintained this legacy behavior to support older deployments using this storage driver. However, when moving to Azure from another storage driver, this behavior hides all your data until you configure the storage driver with `trimlegacyrootprefix: true` to build root paths without an extra leading slash.
 
@@ -61,9 +67,11 @@ In GitLab 16.0, the new default configuration for the storage driver uses `triml
 
 ### Bundled Grafana Helm Chart
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.10</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/4353).
+</div>
 
 The Grafana Helm chart that was bundled with the GitLab Helm Chart is removed in the GitLab Helm Chart 7.0 release (releasing along with GitLab 16.0).
 
@@ -72,22 +80,26 @@ The `global.grafana.enabled` setting for the GitLab Helm Chart has also been rem
 If you're using the bundled Grafana, you should switch to the [newer chart version from Grafana Labs](https://artifacthub.io/packages/helm/grafana/grafana)
 or a Grafana Operator from a trusted provider.
 
-In your new Grafana instance, you can [configure the GitLab provided Prometheus as a data source](https://docs.gitlab.com/ee/administration/monitoring/performance/grafana_configuration.html#integration-with-gitlab-ui)
-and [connect Grafana to the GitLab UI](https://docs.gitlab.com/ee/administration/monitoring/performance/grafana_configuration.html#integration-with-gitlab-ui).
+In your new Grafana instance, [configure the GitLab provided Prometheus as a data source](https://docs.gitlab.com/ee/administration/monitoring/performance/grafana_configuration.html#configure-grafana)
+and [connect Grafana to the GitLab UI](https://docs.gitlab.com/ee/administration/monitoring/performance/grafana_configuration.html#integrate-with-gitlab-ui).
 
 ### CAS OmniAuth provider is removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.3</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/369127).
+</div>
 
 The `omniauth-cas3` gem that provides GitLab with the CAS OmniAuth provider is being removed. You can no longer authenticate into a GitLab instance through CAS. This gem sees very little use. [The gem](https://rubygems.org/gems/omniauth-cas3/) has not had a new release in almost 5 years, which means that its dependencies are out of date and required manual patching during GitLab's [upgrade to OmniAuth 2.0](https://gitlab.com/gitlab-org/gitlab/-/issues/30073).
 
 ### CiCdSettingsUpdate mutation renamed to ProjectCiCdSettingsUpdate
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.0</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/361801).
+</div>
 
 The `CiCdSettingsUpdate` mutation was renamed to `ProjectCiCdSettingsUpdate` in GitLab 15.0.
 The `CiCdSettingsUpdate` mutation will be removed in GitLab 16.0.
@@ -96,17 +108,21 @@ instead.
 
 ### Conan project-level search returns only project-specific results"
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/384455).
+</div>
 
 The [GitLab Conan repository](https://docs.gitlab.com/ee/user/packages/conan_repository/) supports the `conan search` command, but when searching a project-level endpoint, instance-level Conan packages could have been returned. This unintended functionality is removed in GitLab 16.0. The search endpoint for the project level now only returns packages from the target project.
 
 ### Configuring Redis config file paths using environment variables is no longer supported
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/388255).
+</div>
 
 You can no longer specify Redis configuration file locations
 using the environment variables like `GITLAB_REDIS_CACHE_CONFIG_FILE` or
@@ -116,17 +132,21 @@ configuration file locations instead, for example `config/redis.cache.yml` or
 
 ### Container Registry pull-through cache is removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/container-registry/-/issues/937).
+</div>
 
 The Container Registry [pull-through cache](https://docs.docker.com/registry/recipes/mirror/) was deprecated in GitLab 15.8 and removed in GitLab 16.0. This feature is part of the upstream [Docker Distribution project](https://github.com/distribution/distribution) but we are removing that code in favor of the GitLab Dependency Proxy. Use the GitLab Dependency Proxy to proxy and cache container images from Docker Hub.
 
 ### Container Scanning variables that reference Docker removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.4</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/371840).
+</div>
 
 All Container Scanning variables with a name prefixed by `DOCKER_` have been removed. This includes:
 
@@ -142,19 +162,33 @@ Instead, use the [new variable names](https://docs.gitlab.com/ee/user/applicatio
 - `CS_REGISTRY_USER`
 - `CS_DOCKERFILE_PATH`
 
+### Default value of `ttl_days` now 30 days
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.4</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/369122).
+</div>
+
+From GitLab 16.0, any personal, project, or group access token [must have an expiration date](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96594). If you create a personal access token with the GitLab Shell command `personal_access_token` without specifying `ttl_days`, a default value of 30 days is now applied.
+
 ### Dependency Scanning ends support for Java 13, 14, 15, and 16
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/387560).
+</div>
 
 Dependency Scanning no longer supports projects that use Java versions 13, 14, 15, and 16.
 
 ### Developer role providing the ability to import projects to a group
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/387891).
+</div>
 
 The ability for users with the Developer role for a group to import projects to that group was deprecated in GitLab
 15.8 and is removed in GitLab 16.0.
@@ -163,9 +197,11 @@ From GitLab 16.0, only users with at least the Maintainer role for a group can i
 
 ### Embedding Grafana panels in Markdown is removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/389477).
+</div>
 
 The ability to add Grafana panels in GitLab Flavored Markdown is removed.
 We intend to replace this feature with the ability to [embed charts](https://gitlab.com/groups/gitlab-org/opstrace/-/epics/33)
@@ -173,9 +209,11 @@ with the [GitLab Observability UI](https://gitlab.com/gitlab-org/opstrace/opstra
 
 ### Enforced validation of CI/CD parameter character lengths
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/372770).
+</div>
 
 Previously, only CI/CD [job names](https://docs.gitlab.com/ee/ci/jobs/index.html#job-name-limitations) had a strict 255-character limit. Now, more CI/CD keywords are validated to ensure they stay under the limit.
 
@@ -189,14 +227,21 @@ Users on self-managed instances should update their pipelines to ensure they do
 
 ### GitLab administrators must have permission to modify protected branches or tags
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">16.0</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/12776).
+</div>
 
 GitLab administrators can no longer perform actions on protected branches or tags unless they have been explicitly granted that permission. These actions include pushing and merging into a [protected branch](https://docs.gitlab.com/ee/user/project/protected_branches.html), unprotecting a branch, and creating [protected tags](https://docs.gitlab.com/ee/user/project/protected_tags.html).
 
 ### GitLab.com importer
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-com/Product/-/issues/4895).
+</div>
+
 The [GitLab.com importer](https://docs.gitlab.com/ee/user/project/import/gitlab_com.html) was deprecated in GitLab 15.8 and is removed in GitLab 16.0.
 
 The GitLab.com importer was introduced in 2015 for importing a project from GitLab.com to a self-managed GitLab instance through the UI.
@@ -208,9 +253,11 @@ See [migrated group items](https://docs.gitlab.com/ee/user/group/import/#migrate
 
 ### GraphQL API: Runner status no longer returns `PAUSED` and `ACTIVE` values
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/344648).
+</div>
 
 In GitLab 16.0 and later, the GraphQL query for runners will no longer return the statuses `PAUSED` and `ACTIVE`.
 
@@ -219,18 +266,22 @@ In GitLab 16.0 and later, the GraphQL query for runners will no longer return th
 
 ### Jira DVCS connector for Jira Cloud and Jira 8.13 and earlier
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.1</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/362168).
+</div>
 
 The [Jira DVCS connector](https://docs.gitlab.com/ee/integration/jira/dvcs/) for Jira Cloud was deprecated in GitLab 15.1 and has been removed in 16.0. Use the [GitLab for Jira Cloud app](https://docs.gitlab.com/ee/integration/jira/connect-app.html) instead. The Jira DVCS connector was also deprecated for Jira 8.13 and earlier. You can only use the Jira DVCS connector with Jira Data Center or Jira Server in Jira 8.14 and later. Upgrade your Jira instance to Jira 8.14 or later, and reconfigure the Jira integration in your GitLab instance.
 If you cannot upgrade your Jira instance in time and are on GitLab self-managed version, we offer a workaround until GitLab 16.6. This breaking change is deployed in GitLab 16.0 behind a feature flag named `jira_dvcs_end_of_life_amnesty`. The flag is disabled by default, but you can ask an administrator to enable the flag at any time. For questions related to this announcement, see the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/408185).
 
 ### Legacy Gitaly configuration method
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.10</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/393574).
+</div>
 
 Previously, Gitaly configuration keys for Omnibus GitLab were scattered throughout the configuration file. In GitLab
 15.10, we added support for a single configuration structure that matches Gitaly internal configuration. Both methods
@@ -244,9 +295,11 @@ instructions, see [Gitaly - Omnibus GitLab configuration structure change](https
 
 ### Legacy Gitaly configuration methods with variables
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352609).
+</div>
 
 The environment variables `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL` were deprecated in GitLab 14.8 and are removed
 in GitLab 16.0. These variables are replaced with standard
@@ -257,9 +310,11 @@ using `config.toml`.
 
 ### Legacy Praefect configuration method
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/390291).
+</div>
 
 Previously, Praefect configuration keys for Omnibus GitLab were scattered throughout the configuration file. In GitLab
 15.9, we added support for a single configuration structure that matches Praefect internal configuration. Both methods
@@ -271,19 +326,39 @@ method.
 Before upgrading to GitLab 16.0, administrators must migrate to the new single configuration structure. For
 instructions, see [Praefect - Omnibus GitLab configuration structure change](https://docs.gitlab.com/ee/update/#praefect-omnibus-gitlab-configuration-structure-change).
 
+### Legacy routes removed
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/214217).
+</div>
+
+GitLab 16.0 removes legacy URLs from the GitLab application.
+
+When subgroups were introduced in GitLab 9.0, a `/-/` delimiter was added to URLs to signify the end of a group path. All GitLab URLs now use this delimiter for project, group, and instance level features.
+
+URLs that do not use the `/-/` delimiter are planned for removal in GitLab 16.0. For the full list of these URLs, along with their replacements, see [issue 28848](https://gitlab.com/gitlab-org/gitlab/-/issues/28848#release-notes).
+
+Update any scripts or bookmarks that reference the legacy URLs. GitLab APIs are not affected by this change.
+
 ### License-Check and the Policies tab on the License Compliance page
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/390417).
+</div>
 
 The License Check Policies feature has been removed. Additionally, the Policies tab on the License Compliance page and all APIs related to the License Check feature have been removed. To enforce approvals based on detected licenses, use the [License Approval policy](https://docs.gitlab.com/ee/user/compliance/license_approval_policies.html) feature instead.
 
 ### Limit CI_JOB_TOKEN scope is disabled
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/395708).
+</div>
 
 In GitLab 14.4 we introduced the ability to [limit your project's CI/CD job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#limit-your-projects-job-token-access) (`CI_JOB_TOKEN`) access to make it more secure. You could use the **Limit CI_JOB_TOKEN access** setting to prevent job tokens from your project's pipelines from being used to **access other projects**. When enabled with no other configuration, your pipelines could not access any other projects. To use job tokens to access other projects from your project's pipelines, you needed to list those other projects explicitly in the setting's allowlist, and you needed to be a maintainer in _all_ the projects. You might have seen this mentioned as the "outbound scope" of the job token.
 
@@ -297,9 +372,11 @@ To prepare for this change, users on GitLab.com or self-managed GitLab 15.9 or l
 
 ### Managed Licenses API
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/390417).
+</div>
 
 The [Managed Licenses API](https://archives.docs.gitlab.com/15.8/ee/api/managed_licenses.html) has been removed. To enforce approvals in merge requests when non-compliant licenses are detected, use the [License Approval policy](https://docs.gitlab.com/ee/user/compliance/license_approval_policies.html) feature instead.
 
@@ -309,6 +386,11 @@ To query a list of dependencies and components, use our [Dependencies REST API](
 
 ### Maximum number of active pipelines per project limit (`ci_active_pipelines`)
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.3</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/368195).
+</div>
+
 The [**Maximum number of active pipelines per project** limit](https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#set-cicd-limits) has been removed. Instead, use the other recommended rate limits that offer similar protection:
 
 - [**Pipelines rate limits**](https://docs.gitlab.com/ee/user/admin_area/settings/rate_limit_on_pipelines_creation.html).
@@ -316,9 +398,11 @@ The [**Maximum number of active pipelines per project** limit](https://docs.gitl
 
 ### Monitoring performance metrics through Prometheus is removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.7</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/346541).
+</div>
 
 We previously launched a solution that allows you to view performance metrics by displaying data stored in a Prometheus instance.
 The Prometheus instance can be set up as a GitLab-managed app or you can connect a previously configured Prometheus instance.
@@ -337,9 +421,11 @@ This removal only refers to the GitLab Metrics capabilities, and **does not** in
 
 ### Non-expiring access tokens no longer supported
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.4</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/369123).
+</div>
 
 Currently, you can create access tokens that have no expiration date. These access tokens are valid indefinitely, which presents a security risk if the access token is
 divulged. Because expiring access tokens are better, from GitLab 15.4 we [populate a default expiration date](https://gitlab.com/gitlab-org/gitlab/-/issues/348660).
@@ -348,9 +434,11 @@ In GitLab 16.0, any personal, project, or group access token that does not have
 
 ### Non-standard default Redis ports are no longer supported
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/388269).
+</div>
 
 If GitLab starts without any Redis configuration file present,
 GitLab assumes it can connect to three Redis servers at `localhost:6380`,
@@ -363,17 +451,21 @@ and `config/redis.shared_state.yml` files.
 
 ### PipelineSecurityReportFinding name GraphQL field
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.1</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/346335).
+</div>
 
 Previously, the [PipelineSecurityReportFinding GraphQL type was updated](https://gitlab.com/gitlab-org/gitlab/-/issues/335372) to include a new `title` field. This field is an alias for the current `name` field, making the less specific `name` field redundant. The `name` field is removed from the PipelineSecurityReportFinding type in GitLab 16.0.
 
 ### PostgreSQL 12 compatibility
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.0</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7395).
+</div>
 
 In GitLab 16.0, PostgreSQL 13 is the minimum supported PostgreSQL version. PostgreSQL 12 is no longer shipped with the GitLab Omnibus package.
 Before upgrading to GitLab 16.0, if you are:
@@ -385,9 +477,11 @@ Before upgrading to GitLab 16.0, if you are:
 
 ### Praefect custom metrics endpoint configuration
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/390266).
+</div>
 
 Support for using the `prometheus_exclude_database_from_default_metrics` configuration value was deprecated in
 GitLab 15.9 and is removed in GitLab 16.0. We made this change to improve the performance of Praefect.
@@ -397,9 +491,11 @@ You must update your metrics collection targets to use the `/db_metrics` endpoin
 
 ### Project REST API field `operations_access_level` removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/385798).
+</div>
 
 In project REST API endpoints, the `operations_access_level` field
 is removed in favor of more specialized fields like:
@@ -412,6 +508,11 @@ is removed in favor of more specialized fields like:
 
 ### Rake task for importing bare repositories
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-com/Product/-/issues/5255).
+</div>
+
 The [Rake task for importing bare repositories](https://docs.gitlab.com/ee/raketasks/import.html) `gitlab:import:repos` was deprecated in GitLab 15.8 and is removed in GitLab 16.0.
 
 This Rake task imported a directory tree of repositories into a GitLab instance. These repositories must have been
@@ -432,9 +533,11 @@ Alternatives to using the `gitlab:import:repos` Rake task include:
 
 ### Redis 5 compatibility
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.3</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/331468).
+</div>
 
 In GitLab 13.9, we updated the Omnibus GitLab package and GitLab Helm chart 4.9 to Redis 6. Redis 5 reached end of life in April 2022 and is not supported.
 
@@ -443,9 +546,11 @@ or later.
 
 ### Removal of job_age parameter in `POST /jobs/request` Runner endpoint
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.2</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/334253).
+</div>
 
 The `job_age` parameter, returned from the `POST /jobs/request` API endpoint used in communication with GitLab Runner, has been removed in GitLab 16.0.
 
@@ -453,6 +558,11 @@ This could be a breaking change for anyone that developed their own runner that
 
 ### Remove legacy configuration fields in GitLab Runner Helm Chart
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.6</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/379064).
+</div>
+
 In GitLab 13.6 and later, users can [specify any runner configuration in the GitLab Runner Helm chart](https://docs.gitlab.com/runner/install/kubernetes.html). When this features was released, we deprecated the fields in the GitLab Helm Chart configuration specific to the runner. As of v1.0 of the GitLab Runner Helm chart (GitLab 16.0), the following fields have been removed and are no longer supported:
 
 - `image`
@@ -487,9 +597,11 @@ In GitLab 13.6 and later, users can [specify any runner configuration in the Git
 
 ### Remove the deprecated `environment_tier` parameter from the DORA API
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.2</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/365939).
+</div>
 
 The `environment_tier` parameter has been superseded by the `environment_tiers` parameter.
 
@@ -497,54 +609,111 @@ If you use the `environment_tier` parameter in your integration (REST or GraphQL
 
 ### Removed `external` field from GraphQL `ReleaseAssetLink` type
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/388983).
+</div>
 
 From GitLab 15.9, all Release links are external. The `external` field of the `ReleaseAssetLink` type was deprecated in 15.9, and removed in GitLab 16.0.
 
 ### Removed `external` field from Releases and Release link APIs
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/388984).
+</div>
 
 From GitLab 15.9, all Release links are external. The `external` field in the Releases and Release link APIs was deprecated in 15.9, and removed in GitLab 16.0.
 
+### Secure JWT token setting is removed
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/366798).
+</div>
+
+As part of [the deprecation of old versions of JSON web tokens](https://docs.gitlab.com/ee/update/deprecations.html#old-versions-of-json-web-tokens-are-deprecated), the **Limit JSON Web Token (JWT)** project setting has been removed. This setting was a temporary solution to help users transition to [ID tokens](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html), as a way to switch between the old and new tokens, but the setting is no longer needed. In GitLab 16.0 and later, you can simply start using ID tokens in any job. When you use the `id_tokens` keyword in a job, that job uses only ID tokens and the old `CI_JOB_JWT*` tokens are not available. In jobs that do not use the `id_tokens` keyword, the old behavior remains unchanged.
+
+The old `CI_JOB_JWT*` tokens will be completely removed in GitLab 16.5, so you must switch to ID tokens before that release.
+
+### Secure scanning `_DISABLED` variables now require the value `"true"`
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/391822).
+</div>
+
+In GitLab 16.0, we've changed how values for CI/CD variables like `SAST_DISABLED` and `DEPENDENCY_SCANNING_DISABLED` are handled.
+
+Now, scanning is disabled only if the value is `"true"`, for example `SAST_DISABLED: "true"`. Previously, even if the value were `"false"`, like `SAST_DISABLED: "false"`, scanning would still be disabled.
+
+This change was previously released in the Latest versions of the CI/CD templates because of the potential to disrupt customized CI/CD pipeline configurations.
+
+The following templates have been updated:
+
+- API Fuzzing: [`API-Fuzzing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/API-Fuzzing.gitlab-ci.yml)
+- Container Scanning: [`Container-Scanning.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml)
+- Coverage-Guided Fuzzing: [`Coverage-Fuzzing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Coverage-Fuzzing.gitlab-ci.yml)
+- DAST: [`DAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/DAST.gitlab-ci.yml)
+- DAST API: [`DAST-API.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/DAST-API.gitlab-ci.yml)
+- Dependency Scanning: [`Dependency-Scanning.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Dependency-Scanning.gitlab-ci.yml)
+- IaC Scanning: [`SAST-IaC.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST-IaC.gitlab-ci.yml)
+- SAST: [`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml)
+- Secret Detection: [`Secret-Detection.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml)
+
+If you currently use the `_DISABLED` variables but set a value other than `"true"` to disable scanning, change the value to `"true"`.
+
 ### Security report schemas version 14.x.x
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.3</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/366477).
+</div>
 
 Version 14.x.x [security report schemas](https://gitlab.com/gitlab-org/security-products/security-report-schemas) have been removed.
 Security reports that use schema version 14.x.x will cause an error in the pipeline's **Security** tab. For more information, refer to [security report validation](https://docs.gitlab.com/ee/user/application_security/#security-report-validation).
 
 ### Self-monitoring project is removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/groups/gitlab-org/-/epics/10030).
+</div>
 
 GitLab self-monitoring project was meant to enable self-hosted GitLab administrators to visualize performance metrics of GitLab within GitLab itself. This feature relied on GitLab Metrics dashboards. With metrics dashboard being removed, self-monitoring project is also removed. We recommended that self-hosted users monitor their GitLab instance with alternative visualization tools, such as Grafana.
 
 ### Starboard directive in the config for the GitLab agent for Kubernetes removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.4</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/368828).
+</div>
 
 The GitLab operational container scanning feature no longer requires you to install Starboard. The `starboard:` directive in configuration files for the GitLab agent for Kubernetes has been removed. Use the `container_scanning:` directive instead.
 
 ### Stop publishing GitLab Runner images based on Windows Server 2004 and 20H2
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">16.0</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/31001).
+</div>
+
 As of GitLab 16.0, GitLab Runner images based on Windows Server 2004 and 20H2 will not be provided as these operating systems are end-of-life.
 
 ### The Phabricator task importer
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.7</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-com/Product/-/issues/4894).
+</div>
 
 The [Phabricator task importer](https://docs.gitlab.com/ee/user/project/import/phabricator.html) was deprecated in
 GitLab 15.7 and is removed in 16.0.
@@ -554,9 +723,11 @@ tool. There has been no activity on the open related issues on GitLab.
 
 ### The Security Code Scan-based GitLab SAST analyzer is now removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/390416).
+</div>
 
 GitLab SAST uses various [analyzers](https://docs.gitlab.com/ee/user/application_security/sast/analyzers/) to scan code for vulnerabilities.
 We've reduced the number of supported analyzers used by default in GitLab SAST.
@@ -574,9 +745,11 @@ If you customize the behavior of GitLab SAST by disabling the Semgrep-based anal
 
 ### The stable Terraform CI/CD template has been replaced with the latest template
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/386001).
+</div>
 
 With every major GitLab version, we update the stable Terraform templates with the current latest templates.
 This change affects the [quickstart](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.gitlab-ci.yml)
@@ -594,9 +767,11 @@ To accommodate the changes, you might need to adjust the [`rules`](https://docs.
 
 ### Two DAST API variables have been removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.7</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/383467).
+</div>
 
 The variables `DAST_API_HOST_OVERRIDE` and `DAST_API_SPECIFICATION` have been removed from use for DAST API scans.
 
@@ -606,17 +781,21 @@ The variables `DAST_API_HOST_OVERRIDE` and `DAST_API_SPECIFICATION` have been re
 
 ### Use of `id` field in vulnerabilityFindingDismiss mutation
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.3</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/367166).
+</div>
 
 You can use the vulnerabilityFindingDismiss GraphQL mutation to set the status of a vulnerability finding to `Dismissed`. Previously, this mutation used the `id` field to identify findings uniquely. However, this did not work for dismissing findings from the pipeline security tab. Therefore, using the `id` field as an identifier has been dropped in favor of the `uuid` field. Using the 'uuid' field as an identifier allows you to dismiss the finding from the pipeline security tab.
 
 ### Vulnerability confidence field
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.4</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/372332).
+</div>
 
 In GitLab 15.3, [security report schemas below version 15 were deprecated](https://docs.gitlab.com/ee/update/deprecations.html#security-report-schemas-version-14xx).
 The `confidence` attribute on vulnerability findings exists only in schema versions before `15-0-0` and in GitLab prior to 15.4.  To maintain consistency
@@ -624,9 +803,11 @@ between the reports and our public APIs, the `confidence` attribute on any vulne
 
 ### `CI_BUILD_*` predefined variables removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352957).
+</div>
 
 The predefined CI/CD variables that start with `CI_BUILD_*` were deprecated in GitLab 9.0, and removed in GitLab 16.0. If you still use these variables, you must change to the replacement [predefined variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) which are functionally identical:
 
@@ -645,19 +826,52 @@ The predefined CI/CD variables that start with `CI_BUILD_*` were deprecated in G
 | `CI_BUILD_TOKEN`      | `CI_JOB_TOKEN`          |
 | `CI_BUILD_TRIGGERED`  | `CI_PIPELINE_TRIGGERED` |
 
+### `CI_PRE_CLONE_SCRIPT` variable on GitLab SaaS Runners has been removed
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29405).
+</div>
+
+In GitLab 16.0 and later, the `CI_PRE_CLONE_SCRIPT` variable option on GitLab SaaS Runners has been removed. The `CI_PRE_CLONE_SCRIPT` variable enabled you to run commands in your CI/CD job before the runner executed `git-init` and `git-fetch`. You should use the `pre_get_sources_script` hook instead. For more information, see the blog post, [Guide to pre_clone_script changes on GitLab SaaS Linux Runners](https://about.gitlab.com/blog/2023/03/27/changes-to-the-preclonescript/).
+
+### `POST /projects/:id/merge_requests/:merge_request_iid/approvals` removed
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">12.3</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/353097).
+</div>
+
+The `/approvals` endpoint was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/11132) in GitLab 12.3. To change the approvals required for a merge request via the API, use the `/approval_rules` endpoint described in [Create merge request level rule](https://docs.gitlab.com/ee/api/merge_request_approvals.html#create-merge-request-level-rule).
+
 ### `POST ci/lint` API endpoint removed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.7</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/381669).
+</div>
 
 The `POST ci/lint` API endpoint was deprecated in 15.7, and removed in 16.0. This endpoint did not validate the full range of CI/CD configuration options. Instead, use [`POST /projects/:id/ci/lint`](https://docs.gitlab.com/ee/api/lint.html#validate-a-ci-yaml-configuration-with-a-namespace), which properly validates CI/CD configuration.
 
+### `docker-ssh` and `docker-ssh+machine` executors are removed
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">10.0</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29406).
+</div>
+
+In GitLab 16.0 and later, the `docker-ssh` and `docker+machine-ssh` executors for GitLab Runner have been removed from the GitLab Runner [code base](https://gitlab.com/gitlab-org/gitlab-runner).
+
 ### vulnerabilityFindingDismiss GraphQL mutation
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/375645).
+</div>
 
 The `VulnerabilityFindingDismiss` GraphQL mutation has been removed. This mutation was not used often as the Vulnerability Finding ID was not available to users (this field was [deprecated in 15.3](https://docs.gitlab.com/ee/update/deprecations.html#use-of-id-field-in-vulnerabilityfindingdismiss-mutation)). Instead of `VulnerabilityFindingDismiss`, you should use `VulnerabilityDismiss` to dismiss vulnerabilities in the Vulnerability Report or `SecurityFindingDismiss` for security findings in the CI Pipeline Security tab.
 
@@ -665,6 +879,11 @@ The `VulnerabilityFindingDismiss` GraphQL mutation has been removed. This mutati
 
 ### Exporting and importing projects in JSON format not supported
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.10</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/389888).
+</div>
+
 GitLab previously created project file exports in JSON format. In GitLab 12.10, NDJSON was added as the preferred format.
 
 To support transitions, importing JSON-formatted project file exports was still possible if you configured the
@@ -674,6 +893,11 @@ From GitLab 15.11, importing a JSON-formatted project file exports is not suppor
 
 ### openSUSE Leap 15.3 packages
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7371).
+</div>
+
 Distribution support and security updates for openSUSE Leap 15.3 [ended December 2022](https://en.opensuse.org/Lifetime#Discontinued_distributions).
 
 Starting in GitLab 15.7 we started providing packages for openSUSE Leap 15.4, and in GitLab 15.11 we stopped providing packages for openSUSE Leap 15.3.
@@ -684,32 +908,43 @@ To continue using GitLab, [upgrade](https://en.opensuse.org/SDB:System_upgrade)
 
 ### Live Preview no longer available in the Web IDE
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/383889).
+</div>
 
 The Live Preview feature of the Web IDE was intended to provide a client-side preview of static web applications. However, complex configuration steps and a narrow set of supported project types have limited its utility. With the introduction of the Web IDE Beta in GitLab 15.7, you can now connect to a full server-side runtime environment. With upcoming support for installing extensions in the Web IDE, we’ll also support more advanced workflows than those available with Live Preview. As of GitLab 15.9, Live Preview is no longer available in the Web IDE.
 
 ### `omniauth-authentiq` gem no longer available
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/389452).
+</div>
 
 `omniauth-authentiq` is an OmniAuth strategy gem that was part of GitLab. The company providing authentication services, Authentiq, has shut down. Therefore the gem is being removed.
 
 ### `omniauth-shibboleth` gem no longer available
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">10.0</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/388959).
+</div>
 
-`omniauth-shibboleth` is an OmniAuth strategy gem that was part of GitLab. The gem has not received security updates and does not meet GitLab quality guidance criteria. This gem was originally scheduled for removal by 14.1, but it was not removed at that time. The gem is being removed now.
+`omniauth-shibboleth` is an OmniAuth strategy gem that was part of GitLab. The gem has not received security updates and does not meet GitLab quality guidance criteria. This gem was originally scheduled for removal by 14.1, but it was not removed at that time. The gem is being removed now. In GitLab 16.1 or later, use the `omniauth-shibboleth-redux` gem instead.
 
 ## Removed in 15.8
 
 ### CiliumNetworkPolicy within the auto deploy Helm chart is removed
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/382044).
+</div>
+
 All functionality related to the GitLab Container Network Security and Container Host Security categories was deprecated in GitLab 14.8 and scheduled for removal in GitLab 15.0. The [CiliumNetworkPolicy definition](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/blob/master/assets/auto-deploy-app/values.yaml#L175) that exists as part of the [GitLab Auto Deploy Helm chart](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app) was not removed as scheduled in GitLab 15.0. This policy is planned to be removed in the GitLab 15.8 release.
 
 If you want to preserve this functionality, you can follow one of these two paths:
@@ -719,6 +954,11 @@ If you want to preserve this functionality, you can follow one of these two path
 
 ### Exporting and importing groups in JSON format not supported
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.10</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/389888).
+</div>
+
 GitLab previously created group file exports in JSON format. In GitLab 13.10, NDJSON was added as the preferred format.
 
 To support transitions, importing JSON-formatted group file exports was still possible if you configured the
@@ -728,9 +968,11 @@ From GitLab 15.8, importing a JSON-formatted group file exports is not supported
 
 ### `artifacts:public` CI/CD keyword refactored
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.10</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/322454).
+</div>
 
 The [`artifacts:public` CI/CD keyword](https://docs.gitlab.com/ee/ci/yaml/#artifactspublic) was discovered to be not working properly since GitLab 15.8 and needed to be refactored. This feature is disabled on GitLab.com, and disabled by default on self-managed instances. If an administrator for an instance running GitLab 15.8 or 15.9 enabled this feature via the `non_public_artifacts` feature flag, it is likely that artifacts created with the `public:false` setting are being treated as `public:true`.
 
@@ -742,9 +984,11 @@ In GitLab 15.10, this feature's code was refactored. On instances with this feat
 
 ### File Type variable expansion in `.gitlab-ci.yml`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/29407).
+</div>
 
 Prior to this change, variables that referenced or applied alias file variables expanded the value of the `File` type variable. For example, the file contents. This behavior was incorrect because it did not comply with typical shell variable expansion rules. A user could run an $echo command with the variable as an input parameter to leak secrets or sensitive information stored in 'File' type variables.
 
@@ -752,12 +996,22 @@ In 15.7, we are removing file type variable expansion from GitLab. It is essenti
 
 ### Flowdock integration
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.7</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/379197).
+</div>
+
 As of December 22, 2022, we are removing the Flowdock integration because the service was shut down on August 15, 2022.
 
 ## Removed in 15.6
 
 ### NFS as Git repository storage is no longer supported
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.0</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/351243).
+</div>
+
 As of November 22, 2022, we have removed support for customers using NFS for Git repository storage. This was
 originally planned for May 22, 2022, but in an effort to allow continued maturity of Gitaly Cluster, we delayed
 our removal of support date until now. Please see our official [Statement of Support](https://about.gitlab.com/support/statement-of-support/#gitaly-and-nfs)
@@ -778,9 +1032,11 @@ We encourage customers currently using NFS for Git repositories to migrate as so
 
 ### SAST analyzer consolidation and CI/CD template changes
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352554).
+</div>
 
 We have replaced the GitLab SAST [analyzers](https://docs.gitlab.com/ee/user/application_security/sast/analyzers/) for certain languages in GitLab 15.4 as part of our long-term strategy to deliver a more consistent user experience, faster scan times, and reduced CI minute usage.
 
@@ -802,16 +1058,30 @@ If you changed the default GitLab SAST configuration, you may need to update you
 
 ### Support for Debian 9
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+</div>
+
 Long term service and support (LTSS) for [Debian 9 Stretch ended in July 2022](https://wiki.debian.org/LTS). Therefore, we will no longer support the Debian 9 distribution for the GitLab package. Users can upgrade to Debian 10 or Debian 11.
 
 ### Vulnerability Report sort by State
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.0</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/360516).
+</div>
+
 The ability to sort the Vulnerability Report by the `State` column was disabled and put behind a feature flag in GitLab 14.10 due to a refactor
 of the underlying data model. The feature flag has remained off by default as further refactoring will be required to ensure sorting
 by this value remains performant. Due to very low usage of the `State` column for sorting, the feature flag is instead removed in 15.3 to simplify the codebase and prevent any unwanted performance degradation.
 
 ### Vulnerability Report sort by Tool
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.1</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/363138).
+</div>
+
 The ability to sort the Vulnerability Report by the `Tool` column (scan type) was disabled and put behind a feature flag in GitLab 14.10 due to a refactor
 of the underlying data model. The feature flag has remained off by default as further refactoring will be required to ensure sorting
 by this value remains performant. Due to very low usage of the `Tool` column for sorting, the feature flag is instead removed in
@@ -821,6 +1091,10 @@ GitLab 15.3 to simplify the codebase and prevent any unwanted performance degrad
 
 ### Support for older browsers
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+</div>
+
 In GitLab 15.2, we are cleaning up and [removing old code](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86003) that was specific for browsers that we no longer support. This has no impact on users if they use one of our [supported web browsers](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers).
 
 Most notably, support for the following browsers has been removed:
@@ -840,9 +1114,11 @@ The minimum supported browser versions are:
 
 ### API: `stale` status returned instead of `offline` or `not_connected`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.6</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/347303).
+</div>
 
 The Runner [API](https://docs.gitlab.com/ee/api/runners.html#runners-api) endpoints have changed in 15.0.
 
@@ -853,9 +1129,11 @@ The `not_connected` status is no longer valid. It was replaced with `never_conta
 
 ### Audit events for repository push events
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.3</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/337993).
+</div>
 
 Audit events for [repository events](https://docs.gitlab.com/ee/administration/audit_events.html#removed-events) are removed as of GitLab 15.0.
 
@@ -866,9 +1144,11 @@ Please note that we will add high-volume audit events in the future as part of [
 
 ### Background upload for object storage
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26600).
+</div>
 
 To reduce the overall complexity and maintenance burden of GitLab's [object storage feature](https://docs.gitlab.com/ee/administration/object_storage.html), support for using `background_upload` has been removed in GitLab 15.0.
 By default [direct upload](https://docs.gitlab.com/ee/development/uploads/index.html#direct-upload) will be used.
@@ -912,9 +1192,11 @@ Support for setting `GITLAB_LEGACY_BACKGROUND_UPLOADS` will be removed in GitLab
 
 ### Container Network and Host Security
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/groups/gitlab-org/-/epics/7477).
+</div>
 
 All functionality related to the Container Network Security and Container Host Security categories was deprecated in GitLab 14.8 and is scheduled for removal in GitLab 15.0. Users who need a replacement for this functionality are encouraged to evaluate the following open source projects as potential solutions that can be installed and managed outside of GitLab: [AppArmor](https://gitlab.com/apparmor/apparmor), [Cilium](https://github.com/cilium/cilium), [Falco](https://github.com/falcosecurity/falco), [FluentD](https://github.com/fluent/fluentd), [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/). To integrate these technologies with GitLab, add the desired Helm charts in your copy of the [Cluster Management Project Template](https://docs.gitlab.com/ee/user/clusters/management_project_template.html). Deploy these Helm charts in production by calling commands through GitLab [CI/CD](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html).
 
@@ -929,9 +1211,10 @@ For additional context, or to provide feedback regarding this change, please ref
 
 ### Container registry authentication with htpasswd
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 The Container Registry supports [authentication](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#auth) with `htpasswd`. It relies on an [Apache `htpasswd` file](https://httpd.apache.org/docs/2.4/programs/htpasswd.html), with passwords hashed using `bcrypt`.
 
@@ -939,6 +1222,11 @@ Since it isn't used in the context of GitLab (the product), `htpasswd` authentic
 
 ### Custom `geo:db:*` Rake tasks are no longer available
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/351945).
+</div>
+
 In GitLab 14.8, we [deprecated the `geo:db:*` Rake tasks and replaced them with built-in tasks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77269/diffs) after [switching the Geo tracking database to use Rails' 6 support of multiple databases](https://gitlab.com/groups/gitlab-org/-/epics/6458).
 The following `geo:db:*` tasks have been removed from GitLab 15.0 and have been replaced with their corresponding `db:*:geo` tasks:
 
@@ -962,33 +1250,40 @@ The following `geo:db:*` tasks have been removed from GitLab 15.0 and have been
 
 ### DS_DEFAULT_ANALYZERS environment variable
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.0</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/333299).
+</div>
 
 We are removing the `DS_DEFAULT_ANALYZERS` environment variable from Dependency Scanning on May 22, 2022 in 15.0. After this removal, this variable's value will be ignored. To configure which analyzers to run with the default configuration, you should use the `DS_EXCLUDED_ANALYZERS` variable instead.
 
 ### Dependency Scanning default Java version changed to 17
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.10</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 For Dependency Scanning, the default version of Java that the scanner expects will be updated from 11 to 17. Java 17 is [the most up-to-date Long Term Support (LTS) version](https://en.wikipedia.org/wiki/Java_version_history). Dependency Scanning continues to support the same [range of versions (8, 11, 13, 14, 15, 16, 17)](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers), only the default version is changing. If your project uses the previous default of Java 11, be sure to [set the `DS_JAVA_VERSION` variable to match](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuring-specific-analyzers-used-by-dependency-scanning). Please note that consequently the default version of Gradle is now 7.3.3.
 
 ### ELK stack logging
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.7</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/346485).
+</div>
 
 The logging features in GitLab allow users to install the ELK stack (Elasticsearch, Logstash, and Kibana) to aggregate and manage application logs. Users could search for relevant logs in GitLab directly. However, since deprecating certificate-based integration with Kubernetes clusters and GitLab Managed Apps, this feature is no longer available. For more information on the future of logging and observability, you can follow the issue for [integrating Opstrace with GitLab](https://gitlab.com/groups/gitlab-org/-/epics/6976).
 
 ### Elasticsearch 6.8.x in GitLab 15.0
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/350275).
+</div>
 
 Elasticsearch 6.8 support has been removed in GitLab 15.0. Elasticsearch 6.8 has reached [end of life](https://www.elastic.co/support/eol).
 If you use Elasticsearch 6.8, **you must upgrade your Elasticsearch version to 7.x** prior to upgrading to GitLab 15.0.
@@ -998,17 +1293,21 @@ View the [version requirements](https://docs.gitlab.com/ee/integration/advanced_
 
 ### End of support for Python 3.6 in Dependency Scanning
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/351503).
+</div>
 
 For those using Dependency Scanning for Python projects, we are removing support for the default `gemnasium-python:2` image which uses Python 3.6, as well as the custom `gemnasium-python:2-python-3.9` image which uses Python 3.9. The new default image as of GitLab 15.0 will be for Python 3.9 as it is a [supported version](https://endoflife.date/python) and 3.6 [is no longer supported](https://endoflife.date/python).
 
 ### External status check API breaking changes
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/339039).
+</div>
 
 The [external status check API](https://docs.gitlab.com/ee/api/status_checks.html) was originally implemented to
 support pass-by-default requests to mark a status check as passing. Pass-by-default requests are now removed.
@@ -1028,9 +1327,11 @@ To align with this change, API calls to list external status checks also return
 
 ### GitLab Serverless
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.3</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/groups/gitlab-org/configure/-/epics/6).
+</div>
 
 All functionality related to GitLab Serverless was deprecated in GitLab 14.3 and is scheduled for removal in GitLab 15.0. Users who need a replacement for this functionality are encouraged to explore using the following technologies with GitLab CI/CD:
 
@@ -1041,17 +1342,19 @@ For additional context, or to provide feedback regarding this change, please ref
 
 ### Gitaly nodes in virtual storage
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">13.12</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Configuring the Gitaly nodes directly in the virtual storage's root configuration object has been deprecated in GitLab 13.12 and is no longer supported in GitLab 15.0. You must move the Gitaly nodes under the `'nodes'` key as described in [the Praefect configuration](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#praefect).
 
 ### GraphQL permissions change for Package settings
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 The GitLab Package stage offers a Package Registry, Container Registry, and Dependency Proxy to help you manage all of your dependencies using GitLab. Each of these product categories has a variety of settings that can be adjusted using the API.
 
@@ -1066,17 +1369,21 @@ The issue for this removal is [GitLab-#350682](https://gitlab.com/gitlab-org/git
 
 ### Jaeger integration
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.7</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/346540).
+</div>
 
 Tracing in GitLab is an integration with Jaeger, an open-source end-to-end distributed tracing system. GitLab users could previously navigate to their Jaeger instance to gain insight into the performance of a deployed application, tracking each function or microservice that handles a given request. Tracing in GitLab was deprecated in GitLab 14.7, and removed in 15.0. To track work on a possible replacement, see the issue for [Opstrace integration with GitLab](https://gitlab.com/groups/gitlab-org/-/epics/6976).
 
 ### Known host required for GitLab Runner SSH executor
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28192).
+</div>
 
 In [GitLab 14.3](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3074), we added a configuration setting in the GitLab Runner `config.toml`. This setting, [`[runners.ssh.disable_strict_host_key_checking]`](https://docs.gitlab.com/runner/executors/ssh.html#security), controls whether or not to use strict host key checking with the SSH executor.
 
@@ -1084,41 +1391,57 @@ In GitLab 15.0, the default value for this configuration option has changed from
 
 ### Legacy Geo Admin UI routes
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/351345).
+</div>
+
 In GitLab 13.0, we introduced new project and design replication details routes in the Geo Admin UI. These routes are `/admin/geo/replication/projects` and `/admin/geo/replication/designs`. We kept the legacy routes and redirected them to the new routes. These legacy routes `/admin/geo/projects` and `/admin/geo/designs` have been removed in GitLab 15.0. Please update any bookmarks or scripts that may use the legacy routes.
 
 ### Legacy approval status names in License Compliance API
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.6</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/345839).
+</div>
+
 We have now removed the deprecated legacy names for approval status of license policy (`blacklisted`, `approved`) in the API queries and responses. If you are using our License Compliance API you should stop using the `approved` and `blacklisted` query parameters, they are now `allowed` and `denied`. In 15.0 the responses will also stop using `approved` and `blacklisted` so you may need to adjust any of your custom tools.
 
 ### Move Gitaly Cluster Praefect `database_host_no_proxy` and `database_port_no_proxy configs`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.0</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6150).
+</div>
 
 The Gitaly Cluster configuration keys for `praefect['database_host_no_proxy']` and `praefect['database_port_no_proxy']` are replaced with `praefect['database_direct_host']` and `praefect['database_direct_port']`.
 
 ### Move `custom_hooks_dir` setting from GitLab Shell to Gitaly
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4208).
+</div>
 
 The [`custom_hooks_dir`](https://docs.gitlab.com/ee/administration/server_hooks.html#create-a-global-server-hook-for-all-repositories) setting is now configured in Gitaly, and is removed from GitLab Shell in GitLab 15.0.
 
 ### OAuth implicit grant
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.0</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 The OAuth implicit grant authorization flow is no longer supported. Any applications that use OAuth implicit grant must switch to alternative [supported OAuth flows](https://docs.gitlab.com/ee/api/oauth2.html).
 
 ### OAuth tokens without an expiration
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.3</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 GitLab no longer supports OAuth tokens [without an expiration](https://docs.gitlab.com/ee/integration/oauth_provider.html#expiring-access-tokens).
 
@@ -1126,9 +1449,11 @@ Any existing token without an expiration has one automatically generated and app
 
 ### Optional enforcement of SSH expiration
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/351963).
+</div>
 
 Disabling SSH expiration enforcement is unusual from a security perspective and could create unusual situations where an expired
 key is unintentionally able to be used. Unexpected behavior in a security feature is inherently dangerous and so now we enforce
@@ -1136,15 +1461,22 @@ expiration on all SSH keys.
 
 ### Optional enforcement of personal access token expiration
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/351962).
+</div>
 
 Allowing expired personal access tokens to be used is unusual from a security perspective and could create unusual situations where an
 expired key is unintentionally able to be used. Unexpected behavior in a security feature is inherently dangerous and so we now do not let expired personal access tokens be used.
 
 ### Out-of-the-box SAST (SpotBugs) support for Java 8
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352549).
+</div>
+
 The [GitLab SAST SpotBugs analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) scans [Java, Scala, Groovy, and Kotlin code](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) for security vulnerabilities.
 For technical reasons, the analyzer must first compile the code before scanning.
 Unless you use the [pre-compilation strategy](https://docs.gitlab.com/ee/user/application_security/sast/#pre-compilation), the analyzer attempts to automatically compile your project's code.
@@ -1161,9 +1493,11 @@ If you rely on Java 8 being present in the analyzer environment, you must take a
 
 ### Pipelines field from the version field
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/342882).
+</div>
 
 In GraphQL, there are two `pipelines` fields that you can use in a [`PackageDetailsType`](https://docs.gitlab.com/ee/api/graphql/reference/#packagedetailstype) to get the pipelines for package versions:
 
@@ -1174,18 +1508,22 @@ To mitigate possible performance problems, we will remove the `versions` field's
 
 ### Pseudonymizer
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.7</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/219952).
+</div>
 
 The Pseudonymizer feature is generally unused, can cause production issues with large databases, and can interfere with object storage development.
 It was removed in GitLab 15.0.
 
 ### Request profiling
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352488).
+</div>
 
 [Request profiling](https://docs.gitlab.com/ee/administration/monitoring/performance/index.html) has been removed in GitLab 15.0.
 
@@ -1197,9 +1535,10 @@ For more information, check the [summary section of the deprecation issue](https
 
 ### Required pipeline configurations in Premium tier
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 [Required pipeline configuration](https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#required-pipeline-configuration) helps to define and mandate organization-wide pipeline configurations and is a requirement at an executive and organizational level. To align better with our [pricing philosophy](https://about.gitlab.com/company/pricing/#three-tiers), this feature is removed from the Premium tier in GitLab 15.0. This feature continues to be available in the GitLab Ultimate tier.
 
@@ -1212,9 +1551,11 @@ This change also helps GitLab remain consistent in our tiering strategy with the
 
 ### Retire-JS Dependency Scanning tool
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/289830).
+</div>
 
 We have removed support for retire.js from Dependency Scanning as of May 22, 2022 in GitLab 15.0. JavaScript scanning functionality will not be affected as it is still being covered by Gemnasium.
 
@@ -1222,9 +1563,11 @@ If you have explicitly excluded retire.js using the `DS_EXCLUDED_ANALYZERS` vari
 
 ### Runner status `not_connected` API value
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.6</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/347305).
+</div>
 
 The GitLab Runner REST and GraphQL [API](https://docs.gitlab.com/ee/api/runners.html#runners-api) endpoints
 deprecated the `not_connected` status value in GitLab 14.6 and will start returning `never_contacted` in its place
@@ -1234,6 +1577,11 @@ Runners that have never contacted the GitLab instance will also return `stale` i
 
 ### SAST support for .NET 2.1
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352553).
+</div>
+
 The [GitLab SAST Security Code Scan analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan) scans .NET code for security vulnerabilities.
 For technical reasons, the analyzer must first build the code to scan it.
 
@@ -1255,14 +1603,20 @@ If you rely on .NET 2.1 support being present in the analyzer image by default,
 
 ### SUSE Linux Enterprise Server 12 SP2
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Long term service and support (LTSS) for SUSE Linux Enterprise Server (SLES) 12 SP2 [ended on March 31, 2021](https://www.suse.com/lifecycle/). The CA certificates on SP2 include the expired DST root certificate, and it's not getting new CA certificate package updates. We have implemented some [workarounds](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/merge_requests/191), but we will not be able to continue to keep the build running properly.
 
 ### Secret Detection configuration variables
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352565).
+</div>
+
 To make it simpler and more reliable to [customize GitLab Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/#customizing-settings), we've removed some of the variables that you could previously set in your CI/CD configuration.
 
 The following variables previously allowed you to customize the options for historical scanning, but interacted poorly with the [GitLab-managed CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Secret-Detection.gitlab-ci.yml) and are now removed:
@@ -1281,9 +1635,11 @@ For further details, see [the deprecation issue for this change](https://gitlab.
 
 ### Self-managed certificate-based integration with Kubernetes feature flagged
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
+</div>
 
 In 15.0 the certificate-based integration with Kubernetes will be disabled by default.
 
@@ -1291,15 +1647,17 @@ After 15.0, you should use the [agent for Kubernetes](https://docs.gitlab.com/ee
 
 If you need more time to migrate, you can enable the `certificate_based_clusters` [feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html), which re-enables the certificate-based integration.
 
-In GitLab 16.0, we will [remove the feature, its related code, and the feature flag](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/). GitLab will continue to fix any security or critical issues until 16.0.
+In GitLab 17.0, we will [remove the feature, its related code, and the feature flag](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/). GitLab will continue to fix any security or critical issues until 17.0.
 
 For updates and details, follow [this epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
 
 ### Sidekiq configuration for metrics and health checks
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.7</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/347509).
+</div>
 
 In GitLab 15.0, you can no longer serve Sidekiq metrics and health checks over a single address and port.
 
@@ -1317,21 +1675,30 @@ If you installed GitLab from source, verify manually that both servers are confi
 
 ### Static Site Editor
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.7</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/347137).
+</div>
+
 The Static Site Editor was deprecated in GitLab 14.7 and the feature is being removed in GitLab 15.0. Incoming requests to the Static Site Editor will be redirected and open the target file to edit in the Web IDE. Current users of the Static Site Editor can view the [documentation](https://docs.gitlab.com/ee/user/project/web_ide/index.html) for more information, including how to remove the configuration files from existing projects. We will continue investing in improvements to the Markdown editing experience by [maturing the Content Editor](https://gitlab.com/groups/gitlab-org/-/epics/5401) and making it available as a way to edit content across GitLab.
 
 ### Support for `gitaly['internal_socket_dir']`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.10</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6758).
+</div>
 
 Gitaly introduced a new directory that holds all runtime data Gitaly requires to operate correctly. This new directory replaces the old internal socket directory, and consequentially the usage of `gitaly['internal_socket_dir']` was deprecated in favor of `gitaly['runtime_dir']`.
 
 ### Support for legacy format of `config/database.yml`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.3</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338182).
+</div>
 
 The syntax of [GitLab's database](https://docs.gitlab.com/omnibus/settings/database.html)
 configuration located in `database.yml` has changed and the legacy format has been removed.
@@ -1343,9 +1710,10 @@ Instructions are available [in the source update documentation](https://docs.git
 
 ### Test coverage project CI/CD setting
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 To specify a test coverage pattern, in GitLab 15.0 the
 [project setting for test coverage parsing](https://docs.gitlab.com/ee/ci/pipelines/settings.html#add-test-coverage-results-to-a-merge-request-removed)
@@ -1356,17 +1724,21 @@ To set test coverage parsing, use the project’s `.gitlab-ci.yml` file by provi
 
 ### The `promote-db` command is no longer available from `gitlab-ctl`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/345207).
+</div>
 
 In GitLab 14.5, we introduced the command `gitlab-ctl promote` to promote any Geo secondary node to a primary during a failover. This command replaces `gitlab-ctl promote-db` which is used to promote database nodes in multi-node Geo secondary sites. The `gitlab-ctl promote-db` command has been removed in GitLab 15.0.
 
 ### Update to the Container Registry group-level API
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336912).
+</div>
 
 In GitLab 15.0, support for the `tags` and `tags_count` parameters will be removed from the Container Registry API that [gets registry repositories from a group](../api/container_registry.md#within-a-group).
 
@@ -1374,9 +1746,11 @@ The `GET /groups/:id/registry/repositories` endpoint will remain, but won't retu
 
 ### Versions from `PackageType`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/327453).
+</div>
 
 As part of the work to create a [Package Registry GraphQL API](https://gitlab.com/groups/gitlab-org/-/epics/6318), the Package group deprecated the `Version` type for the basic `PackageType` type and moved it to [`PackageDetailsType`](https://docs.gitlab.com/ee/api/graphql/reference/index.html#packagedetailstype).
 
@@ -1384,9 +1758,11 @@ In GitLab 15.0, we will completely remove `Version` from `PackageType`.
 
 ### Vulnerability Check
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/357300).
+</div>
 
 The vulnerability check feature was deprecated in GitLab 14.8 and is scheduled for removal in GitLab 15.0. We encourage you to migrate to the new security approvals feature instead. You can do so by navigating to **Security & Compliance > Policies** and creating a new Scan Result Policy.
 
@@ -1399,17 +1775,21 @@ The new security approvals feature is similar to vulnerability check. For exampl
 
 ### `Managed-Cluster-Applications.gitlab-ci.yml`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.0</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/333610).
+</div>
 
 The `Managed-Cluster-Applications.gitlab-ci.yml` CI/CD template is being removed. If you need an  alternative, try the [Cluster Management project template](https://gitlab.com/gitlab-org/gitlab/-/issues/333610) instead. If your are not ready to move, you can copy the [last released version](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/v14.10.1/lib/gitlab/ci/templates/Managed-Cluster-Applications.gitlab-ci.yml) of the template into your project.
 
 ### `artifacts:reports:cobertura` keyword
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.7</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/348980).
+</div>
 
 As of GitLab 15.0, the [`artifacts:reports:cobertura`](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscobertura-removed)
 keyword has been [replaced](https://gitlab.com/gitlab-org/gitlab/-/issues/344533) by
@@ -1418,17 +1798,21 @@ Cobertura is the only supported report file, but this is the first step towards
 
 ### `defaultMergeCommitMessageWithDescription` GraphQL API field
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/345451).
+</div>
 
 The GraphQL API field `defaultMergeCommitMessageWithDescription` has been removed in GitLab 15.0. For projects with a commit message template set, it will ignore the template.
 
 ### `dependency_proxy_for_private_groups` feature flag
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/276777).
+</div>
 
 A feature flag was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/11582) in GitLab 13.7 as part of the change to require authentication to use the Dependency Proxy. Before GitLab 13.7, you could use the Dependency Proxy without authentication.
 
@@ -1436,9 +1820,10 @@ In GitLab 15.0, we will remove the feature flag, and you must always authenticat
 
 ### `omniauth-kerberos` gem
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.3</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 The `omniauth-kerberos` gem is no longer supported. This gem has not been maintained and has very little usage. Therefore, we
 removed support for this authentication method and recommend using [SPEGNO](https://en.wikipedia.org/wiki/SPNEGO) instead. You can
@@ -1449,33 +1834,40 @@ We are not removing Kerberos SPNEGO integration. We are removing the old passwor
 
 ### `promote-to-primary-node` command from `gitlab-ctl`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.5</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/345207).
+</div>
 
 In GitLab 14.5, we introduced the command `gitlab-ctl promote` to promote any Geo secondary node to a primary during a failover. This command replaces `gitlab-ctl promote-to-primary-node` which was only usable for single-node Geo sites. `gitlab-ctl promote-to-primary-node` has been removed in GitLab 15.0.
 
 ### `push_rules_supersede_code_owners` feature flag
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/262019).
+</div>
 
 The `push_rules_supersede_code_owners` feature flag has been removed in GitLab 15.0. From now on, push rules will supersede the `CODEOWNERS` file. Even if Code Owner approval is required, a push rule that explicitly allows a specific user to push code supersedes the Code Owners setting.
 
 ### `type` and `types` keyword from CI/CD configuration
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.6</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 The `type` and `types` CI/CD keywords is removed in GitLab 15.0, so pipelines that use these keywords fail with a syntax error. Switch to `stage` and `stages`, which have the same behavior.
 
 ### bundler-audit Dependency Scanning tool
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.8</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/347491).
+</div>
 
 We are removing bundler-audit from Dependency Scanning on May 22, 2022 in 15.0. After this removal, Ruby scanning functionality will not be affected as it is still being covered by Gemnasium.
 
@@ -1485,9 +1877,10 @@ If you have explicitly excluded bundler-audit using the `DS_EXCLUDED_ANALYZERS`
 
 ### Permissions change for downloading Composer dependencies
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 The GitLab Composer repository can be used to push, search, fetch metadata about, and download PHP dependencies. All these actions require authentication, except for downloading dependencies.
 
@@ -1497,9 +1890,11 @@ Downloading Composer dependencies without authentication is deprecated in GitLab
 
 ### Integrated error tracking disabled by default
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">14.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/353639).
+</div>
 
 In GitLab 14.4, GitLab released an integrated error tracking backend that replaces Sentry. This feature caused database performance issues. In GitLab 14.9, integrated error tracking is removed from GitLab.com, and turned off by default in GitLab self-managed. While we explore the future development of this feature, please consider switching to the Sentry backend by [changing your error tracking to Sentry in your project settings](https://docs.gitlab.com/ee/operations/error_tracking.html#sentry-error-tracking).
 
@@ -1509,24 +1904,44 @@ For additional background on this removal, please reference [Disable Integrated
 
 ### Limit the number of triggered pipeline to 25K in free tier
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+</div>
+
 A large amount of triggered pipelines in a single project impacts the performance of GitLab.com. In GitLab 14.6, we are limiting the number of triggered pipelines in a single project on GitLab.com at any given moment to 25,000. This change applies to projects in the free tier only, Premium and Ultimate are not affected by this change.
 
 ### Release CLI distributed as a generic package
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+</div>
+
 The [release-cli](https://gitlab.com/gitlab-org/release-cli) will be released as a [generic package](https://gitlab.com/gitlab-org/release-cli/-/packages) starting in GitLab 14.2. We will continue to deploy it as a binary to S3 until GitLab 14.5 and stop distributing it in S3 in GitLab 14.6.
 
 ## Removed in 14.3
 
 ### Introduced limit of 50 tags for jobs
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+</div>
+
 GitLab values efficiency and is prioritizing reliability for [GitLab.com in FY22](https://about.gitlab.com/direction/#gitlab-hosted-first). In 14.3, GitLab CI/CD jobs must have less than 50 [tags](https://docs.gitlab.com/ee/ci/yaml/index.html#tags). If a pipeline contains a job with 50 or more tags, you will receive an error and the pipeline will not be created.
 
 ### List project pipelines API endpoint removes `name` support in 14.3
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+</div>
+
 In GitLab 14.3, we will remove the ability to filter by `name` in the [list project pipelines API endpoint](https://docs.gitlab.com/ee/api/pipelines.html#list-project-pipelines) to improve performance. If you currently use this parameter with this endpoint, you must switch to `username`.
 
 ### Use of legacy storage setting
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+</div>
+
 The support for [`gitlab_pages['use_legacy_storage']` setting](https://docs.gitlab.com/ee/administration/pages/index.html#domain-source-configuration-before-140) in Omnibus installations has been removed.
 
 In 14.0 we removed [`domain_config_source`](https://docs.gitlab.com/ee/administration/pages/index.html#domain-source-configuration-before-140) which had been previously deprecated, and allowed users to specify disk storage. In 14.0 we added `use_legacy_storage` as a **temporary** flag to unblock upgrades, and allow us to debug issues with our users and it was deprecated and communicated for removal in 14.3.
@@ -1535,6 +1950,10 @@ In 14.0 we removed [`domain_config_source`](https://docs.gitlab.com/ee/administr
 
 ### Max job log file size of 100 MB
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+</div>
+
 GitLab values efficiency for all users in our wider community of contributors, so we're always working hard to make sure the application performs at a high level with a lovable UX.
   In GitLab 14.2, we have introduced a [job log file size limit](https://docs.gitlab.com/ee/administration/instance_limits.html#maximum-file-size-for-job-logs), set to 100 megabytes by default. Administrators of self-managed GitLab instances can customize this to any value. All jobs that exceed this limit are dropped and marked as failed, helping prevent performance impacts or over-use of resources. This ensures that everyone using GitLab has the best possible experience.
 
@@ -1542,12 +1961,20 @@ GitLab values efficiency for all users in our wider community of contributors, s
 
 ### Remove support for `prometheus.listen_address` and `prometheus.enable`
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+</div>
+
 The support for `prometheus.listen_address` and `prometheus.enable` has been removed from `gitlab.yml`. Use `prometheus.enabled` and `prometheus.server_address` to set up Prometheus server that GitLab instance connects to. Refer to [our documentation](https://docs.gitlab.com/ee/install/installation.html#prometheus-server-setup) for details.
 
 This only affects new installations from source where users might use the old configurations.
 
 ### Remove support for older browsers
 
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+</div>
+
 In GitLab 14.1, we are cleaning up and [removing old code](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63994) that was specific for browsers that we no longer support. This has no impact on users when one of our [supported web browsers](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers) is used.
 
 Most notably, support for the following browsers has been removed:
@@ -1568,9 +1995,11 @@ The minimum supported browser versions are:
 
 ### Auto Deploy CI template v1
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/300862).
+</div>
 
 In GitLab 14.0, we will update the [Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-deploy) CI template to the latest version. This includes new features, bug fixes, and performance improvements with a dependency on the v2 [auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image). Auto Deploy CI template v1 is deprecated going forward.
 
@@ -1578,9 +2007,11 @@ Since the v1 and v2 versions are not backward-compatible, your project might enc
 
 ### Breaking changes to Terraform CI template
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/328500).
+</div>
 
 GitLab 14.0 renews the Terraform CI template to the latest version. The new template is set up for the GitLab Managed Terraform state, with a dependency on the GitLab `terraform-images` image, to provide a good user experience around GitLab's Infrastructure-as-Code features.
 
@@ -1588,9 +2019,10 @@ The current stable and latest templates are not compatible, and the current late
 
 ### Code Quality RuboCop support changed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 By default, the Code Quality feature has not provided support for Ruby 2.6+ if you're using the Code Quality template. To better support the latest versions of Ruby, the default RuboCop version is updated to add support for Ruby 2.4 through 3.0. As a result, support for Ruby 2.1, 2.2, and 2.3 is removed. You can re-enable support for older versions by [customizing your configuration](https://docs.gitlab.com/ee/ci/testing/code_quality.html#rubocop-errors).
 
@@ -1598,25 +2030,28 @@ Relevant Issue: [Default `codeclimate-rubocop` engine does not support Ruby 2.6+
 
 ### Container Scanning Engine Clair
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Clair, the default container scanning engine, was deprecated in GitLab 13.9 and is removed from GitLab 14.0 and replaced by Trivy. We advise customers who are customizing variables for their container scanning job to [follow these instructions](https://docs.gitlab.com/ee/user/application_security/container_scanning/#change-scanners) to ensure that their container scanning jobs continue to work.
 
 ### DAST default template stages
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In GitLab 14.0, we've removed the stages defined in the current `DAST.gitlab-ci.yml` template to avoid the situation where the template overrides manual changes made by DAST users. We're making this change in response to customer issues where the stages in the template cause problems when used with customized DAST configurations. Because of this removal, `gitlab-ci.yml` configurations that do not specify a `dast` stage must be updated to include this stage.
 
 ### DAST environment variable renaming and removal
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 GitLab 13.8 renamed multiple environment variables to support their broader usage in different workflows. In GitLab 14.0, the old variables have been permanently removed and will no longer work. Any configurations using these variables must be updated to the new variable names. Any scans using these variables in GitLab 14.0 and later will fail to be configured correctly. These variables are:
 
@@ -1631,9 +2066,10 @@ GitLab 13.8 renamed multiple environment variables to support their broader usag
 
 ### Default Browser Performance testing job renamed in GitLab 14.0
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Browser Performance Testing has run in a job named `performance` by default. With the introduction of [Load Performance Testing](https://docs.gitlab.com/ee/ci/testing/code_quality.html) in GitLab 13.2, this naming could be confusing. To make it clear which job is running [Browser Performance Testing](https://docs.gitlab.com/ee/ci/testing/browser_performance_testing.html), the default job name is changed from `performance` to `browser_performance` in the template in GitLab 14.0.
 
@@ -1641,17 +2077,19 @@ Relevant Issue: [Rename default Browser Performance Testing job](https://gitlab.
 
 ### Default DAST spider begins crawling at target URL
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In GitLab 14.0, DAST has removed the current method of resetting the scan to the hostname when starting to spider. Prior to GitLab 14.0, the spider would not begin at the specified target path for the URL but would instead reset the URL to begin crawling at the host root. GitLab 14.0 changes the default for the new variable `DAST_SPIDER_START_AT_HOST` to `false` to better support users' intention of beginning spidering and scanning at the specified target URL, rather than the host root URL. This change has an added benefit: scans can take less time, if the specified path does not contain links to the entire site. This enables easier scanning of smaller sections of an application, rather than crawling the entire app during every scan.
 
 ### Default branch name for new repositories now `main`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Every Git repository has an initial branch, which is named `master` by default. It's the first branch to be created automatically when you create a new repository. Future [Git versions](https://lore.kernel.org/git/pull.656.v4.git.1593009996.gitgitgadget@gmail.com/) will change the default branch name in Git from `master` to `main`. In coordination with the Git project and the broader community, [GitLab has changed the default branch name](https://gitlab.com/gitlab-org/gitlab/-/issues/223789) for new projects on both our SaaS (GitLab.com) and self-managed offerings starting with GitLab 14.0. This will not affect existing projects.
 
@@ -1661,9 +2099,10 @@ For more information, check out our [blog post](https://about.gitlab.com/blog/20
 
 ### Dependency Scanning
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 As mentioned in [13.9](https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-released/#deprecations-for-dependency-scanning) and [this blog post](https://about.gitlab.com/blog/2021/02/08/composition-analysis-14-deprecations-and-removals/) several removals for Dependency Scanning take effect.
 
@@ -1673,9 +2112,10 @@ Previously, to prevent the Gemnasium analyzers to fetch the advisory database at
 
 ### Deprecated GraphQL fields
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In accordance with our [GraphQL deprecation and removal process](https://docs.gitlab.com/ee/api/graphql/#deprecation-process), the following fields that were deprecated prior to 13.7 are [fully removed in 14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/267966):
 
@@ -1688,25 +2128,29 @@ In accordance with our [GraphQL deprecation and removal process](https://docs.gi
 
 ### DevOps Adoption API Segments
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 The first release of the DevOps Adoption report had a concept of **Segments**. Segments were [quickly removed from the report](https://gitlab.com/groups/gitlab-org/-/epics/5251) because they introduced an additional layer of complexity on top of **Groups** and **Projects**. Subsequent iterations of the DevOps Adoption report focus on comparing adoption across groups rather than segments. GitLab 14.0 removes all references to **Segments** [from the GraphQL API](https://gitlab.com/gitlab-org/gitlab/-/issues/324414) and replaces them with **Enabled groups**.
 
 ### Disk source configuration for GitLab Pages
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5993).
+</div>
 
 GitLab Pages [API-based configuration](https://docs.gitlab.com/ee/administration/pages/#gitlab-api-based-configuration) has been available since GitLab 13.0. It replaces the unsupported `disk` source configuration removed in GitLab 14.0, which can no longer be chosen. You should stop using `disk` source configuration, and move to `gitlab` for an API-based configuration. To migrate away from the 'disk' source configuration, set `gitlab_pages['domain_config_source'] = "gitlab"` in your `/etc/gitlab/gitlab.rb` file. We recommend you migrate before updating to GitLab 14.0, to identify and troubleshoot any potential problems before upgrading.
 
 ### Experimental prefix in Sidekiq queue selector options
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 GitLab supports a [queue selector](https://docs.gitlab.com/ee/administration/operations/extra_sidekiq_processes.html#queue-selector) to run only a subset of background jobs for a given process. When it was introduced, this option had an 'experimental' prefix (`experimental_queue_selector` in Omnibus, `experimentalQueueSelector` in Helm charts).
 
@@ -1714,17 +2158,19 @@ As announced in the [13.6 release post](https://about.gitlab.com/releases/2020/1
 
 ### External Pipeline Validation Service Code Changes
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 For self-managed instances using the experimental [external pipeline validation service](https://docs.gitlab.com/ee/administration/external_pipeline_validation.html), the range of error codes GitLab accepts will be reduced. Currently, pipelines are invalidated when the validation service returns a response code from `400` to `499`. In GitLab 14.0 and later, pipelines will be invalidated for the `406: Not Accepted` response code only.
 
 ### Geo Foreign Data Wrapper settings
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 As [announced in GitLab 13.3](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#geo-foreign-data-wrapper-settings-deprecated), the following configuration settings in `/etc/gitlab/gitlab.rb` have been removed in 14.0:
 
@@ -1735,9 +2181,11 @@ As [announced in GitLab 13.3](https://about.gitlab.com/releases/2020/08/22/gitla
 
 ### GitLab OAuth implicit grant
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/288516).
+</div>
 
 GitLab is deprecating the [OAuth 2 implicit grant flow](https://docs.gitlab.com/ee/api/oauth2.html#implicit-grant-flow) as it has been removed for [OAuth 2.1](https://oauth.net/2.1/).
 
@@ -1745,25 +2193,28 @@ Migrate your existing applications to other supported [OAuth2 flows](https://doc
 
 ### GitLab Runner helper image in GitLab.com Container Registry
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In 14.0, we are now pulling the GitLab Runner [helper image](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#helper-image) from the GitLab Container Registry instead of Docker Hub. Refer to [issue #27218](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27218) for details.
 
 ### GitLab Runner installation to ignore the `skel` directory
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In GitLab Runner 14.0, the installation process will ignore the `skel` directory by default when creating the user home directory. Refer to [issue #4845](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4845) for details.
 
 ### Gitaly Cluster SQL primary elector
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Now that Praefect supports a [primary election strategy](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#repository-specific-primary-nodes) for each repository, we have removed the `sql` election strategy.
 The `per_repository` election strategy is the new default, which is automatically used if no election strategy was specified.
@@ -1772,9 +2223,11 @@ If you had configured the `sql` election strategy, you must follow the [migratio
 
 ### Global `SAST_ANALYZER_IMAGE_TAG` in SAST CI template
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/301216).
+</div>
 
 With the maturity of GitLab Secure scanning tools, we've needed to add more granularity to our release process. Previously, GitLab shared a major version number for [all analyzers and tools](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks). This requires all tools to share a major version, and prevents the use of [semantic version numbering](https://semver.org/). In GitLab 14.0, SAST removes the `SAST_ANALYZER_IMAGE_TAG` global variable in our [managed `SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml) CI template, in favor of the analyzer job variable setting the `major.minor` tag in the SAST vendored template.
 
@@ -1784,17 +2237,19 @@ This deprecation and removal changes our [previously announced plan](https://abo
 
 ### Hardcoded `master` in CI/CD templates
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Our CI/CD templates have been updated to no longer use hard-coded references to a `master` branch. In 14.0, they all use a variable that points to your project's configured default branch instead. If your CI/CD pipeline relies on our built-in templates, verify that this change works with your current configuration. For example, if you have a `master` branch and a different default branch, the updates to the templates may cause changes to your pipeline behavior. For more information, [read the issue](https://gitlab.com/gitlab-org/gitlab/-/issues/324131).
 
 ### Helm v2 support
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Helm v2 was [officially deprecated](https://helm.sh/blog/helm-v2-deprecation-timeline/) in November of 2020, with the `stable` repository being [de-listed from the Helm Hub](https://about.gitlab.com/blog/2020/11/09/ensure-auto-devops-work-after-helm-stable-repo/) shortly thereafter. With the release of GitLab 14.0, which will include the 5.0 release of the [GitLab Helm chart](https://docs.gitlab.com/charts/), Helm v2 will no longer be supported.
 
@@ -1802,9 +2257,10 @@ Users of the chart should [upgrade to Helm v3](https://helm.sh/docs/topics/v2_v3
 
 ### Legacy DAST domain validation
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 The legacy method of DAST Domain Validation for CI/CD scans was deprecated in GitLab 13.8, and is removed in GitLab 14.0. This method of domain validation only disallows scans if the `DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED` environment variable is set to `true` in the `gitlab-ci.yml` file, and a `Gitlab-DAST-Permission` header on the site is not set to `allow`. This two-step method required users to opt in to using the variable before they could opt out from using the header.
 
@@ -1812,17 +2268,20 @@ For more information, see the [removal issue](https://gitlab.com/gitlab-org/gitl
 
 ### Legacy feature flags
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/254324).
+</div>
 
 Legacy feature flags became read-only in GitLab 13.4. GitLab 14.0 removes support for legacy feature flags, so you must migrate them to the [new version](https://docs.gitlab.com/ee/operations/feature_flags.html). You can do this by first taking a note (screenshot) of the legacy flag, then deleting the flag through the API or UI (you don't need to alter the code), and finally create a new Feature Flag with the same name as the legacy flag you deleted. Also, make sure the strategies and environments match the deleted flag. We created a [video tutorial](https://www.youtube.com/watch?v=CAJY2IGep7Y) to help with this migration.
 
 ### Legacy fields from DAST report
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 As a part of the migration to a common report format for all of the Secure scanners in GitLab, DAST is making changes to the DAST JSON report. Certain legacy fields were deprecated in 13.8 and have been completely removed in 14.0. These fields are `@generated`, `@version`, `site`, and `spider`. This should not affect any normal DAST operation, but does affect users who consume the JSON report in an automated way and use these fields. Anyone affected by these changes, and needs these fields for business reasons, is encouraged to open a new GitLab issue and explain the need.
 
@@ -1830,66 +2289,76 @@ For more information, see [the removal issue](https://gitlab.com/gitlab-org/gitl
 
 ### Legacy storage
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 As [announced in GitLab 13.0](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#planned-removal-of-legacy-storage-in-14.0), [legacy storage](https://docs.gitlab.com/ee/administration/repository_storage_types.html#legacy-storage) has been removed in GitLab 14.0.
 
 ### License Compliance
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In 13.0, we deprecated the License-Management CI template and renamed it License-Scanning. We have been providing backward compatibility by warning users of the old template to switch. Now in 14.0, we are completely removing the License-Management CI template. Read about it in [issue #216261](https://gitlab.com/gitlab-org/gitlab/-/issues/216261) or [this blog post](https://about.gitlab.com/blog/2021/02/08/composition-analysis-14-deprecations-and-removals/).
 
 ### Limit projects returned in `GET /groups/:id/`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/257829).
+</div>
 
 To improve performance, we are limiting the number of projects returned from the `GET /groups/:id/` API call to 100. A complete list of projects can still be retrieved with the `GET /groups/:id/projects` API call.
 
 ### Make `pwsh` the default shell for newly-registered Windows Runners
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In GitLab Runner 13.2, PowerShell Core support was added to the Shell executor. In 14.0, PowerShell Core, `pwsh` is now the default shell for newly-registered Windows runners. Windows `CMD` will still be available as a shell option for Windows runners. Refer to [issue #26419](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26419) for details.
 
 ### Migrate from `SAST_DEFAULT_ANALYZERS` to `SAST_EXCLUDED_ANALYZERS`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/229974).
+</div>
 
 Until GitLab 13.9, if you wanted to avoid running one particular GitLab SAST analyzer, you needed to remove it from the [long string of analyzers in the `SAST.gitlab-ci.yml` file](https://gitlab.com/gitlab-org/gitlab/-/blob/390afc431e7ce1ac253b35beb39f19e49c746bff/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L12) and use that to set the [`SAST_DEFAULT_ANALYZERS`](https://docs.gitlab.com/ee/user/application_security/sast/#docker-images) variable in your project's CI file. If you did this, it would exclude you from future new analyzers because this string hard codes the list of analyzers to execute. We avoid this problem by inverting this variable's logic to exclude, rather than choose default analyzers.
 Beginning with 13.9, [we migrated](https://gitlab.com/gitlab-org/gitlab/-/blob/14fed7a33bfdbd4663d8928e46002a5ef3e3282c/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L13) to `SAST_EXCLUDED_ANALYZERS` in our `SAST.gitlab-ci.yml` file. We encourage anyone who uses a [customized SAST configuration](https://docs.gitlab.com/ee/user/application_security/sast/#customizing-the-sast-settings) in their project CI file to migrate to this new variable. If you have not overridden `SAST_DEFAULT_ANALYZERS`, no action is needed. The CI/CD variable `SAST_DEFAULT_ANALYZERS` has been removed in GitLab 14.0, which released on June 22, 2021.
 
 ### Off peak time mode configuration for Docker Machine autoscaling
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In GitLab Runner 13.0, [issue #5069](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/5069), we introduced new timing options for the GitLab Docker Machine executor. In GitLab Runner 14.0, we have removed the old configuration option, [off peak time mode](https://docs.gitlab.com/runner/configuration/autoscale.html#off-peak-time-mode-configuration-deprecated).
 
 ### OpenSUSE Leap 15.1
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Support for [OpenSUSE Leap 15.1 is being deprecated](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5135). Support for 15.1 will be dropped in 14.0. We are now providing support for openSUSE Leap 15.2 packages.
 
 ### PostgreSQL 11 support
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 GitLab 14.0 requires PostgreSQL 12 or later. It offers [significant improvements](https://www.postgresql.org/about/news/postgresql-12-released-1976/) to indexing, partitioning, and general performance benefits.
 
@@ -1897,25 +2366,30 @@ Starting in GitLab 13.7, all new installations default to PostgreSQL version 12.
 
 ### Redundant timestamp field from DORA metrics API payload
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/325931).
+</div>
 
 The [deployment frequency project-level API](https://docs.gitlab.com/ee/api/dora/metrics.html#list-project-deployment-frequencies) endpoint has been deprecated in favor of the [DORA 4 API](https://docs.gitlab.com/ee/api/dora/metrics.html), which consolidates all the metrics under one API with the specific metric as a required field. As a result, the timestamp field, which doesn't allow adding future extensions and causes performance issues, will be removed. With the old API, an example response would be `{ "2021-03-01": 3, "date": "2021-03-01", "value": 3 }`. The first key/value (`"2021-03-01": 3`) will be removed and replaced by the last two (`"date": "2021-03-01", "value": 3`).
 
 ### Release description in the Tags API
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/300887).
+</div>
 
 GitLab 14.0 removes support for the release description in the Tags API. You can no longer add a release description when [creating a new tag](https://docs.gitlab.com/ee/api/tags.html#create-a-new-tag). You also can no longer [create](https://docs.gitlab.com/ee/api/tags.html#create-a-new-release) or [update](https://docs.gitlab.com/ee/api/tags.html#update-a-release) a release through the Tags API. Please migrate to use the [Releases API](https://docs.gitlab.com/ee/api/releases/#create-a-release) instead.
 
 ### Ruby version changed in `Ruby.gitlab-ci.yml`
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 By default, the `Ruby.gitlab-ci.yml` file has included Ruby 2.5.
 
@@ -1925,18 +2399,21 @@ Relevant Issue: [Updates Ruby version 2.5 to 3.0](https://gitlab.com/gitlab-org/
 
 ### SAST analyzer `SAST_GOSEC_CONFIG` variable
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/301215).
+</div>
 
 With the release of [SAST Custom Rulesets](https://docs.gitlab.com/ee/user/application_security/sast/#customize-rulesets) in GitLab 13.5 we allow greater flexibility in configuration options for our Go analyzer (GoSec). As a result we no longer plan to support our less flexible [`SAST_GOSEC_CONFIG`](https://docs.gitlab.com/ee/user/application_security/sast/#analyzer-settings) analyzer setting. This variable was deprecated in GitLab 13.10.
 GitLab 14.0 removes the old `SAST_GOSEC_CONFIG variable`. If you use or override `SAST_GOSEC_CONFIG` in your CI file, update your SAST CI configuration or pin to an older version of the GoSec analyzer. We strongly encourage [inheriting and overriding our managed CI templates](https://docs.gitlab.com/ee/user/application_security/sast/#overriding-sast-jobs) to future-proof your CI templates.
 
 ### Service Templates
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Service Templates are [removed in GitLab 14.0](https://gitlab.com/groups/gitlab-org/-/epics/5672). They were used to apply identical settings to a large number of projects, but they only did so at the time of project creation.
 
@@ -1944,17 +2421,20 @@ While they solved part of the problem, _updating_ those values later proved to b
 
 ### Success and failure for finished build metric conversion
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In GitLab Runner 13.5, we introduced `failed` and `success` states for a job. To support Prometheus rules, we chose to convert `success/failure` to `finished` for the metric. In 14.0, the conversion has now been removed. Refer to [issue #26900](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26900) for details.
 
 ### Terraform template version
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue]().
+</div>
 
 As we continuously [develop GitLab's Terraform integrations](https://gitlab.com/gitlab-org/gitlab/-/issues/325312), to minimize customer disruption, we maintain two GitLab CI/CD templates for Terraform:
 
@@ -1971,9 +2451,10 @@ To check the new changes, see the [new "major version" template](https://gitlab.
 
 ### Ubuntu 16.04 support
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Ubuntu 16.04 [reached end-of-life in April 2021](https://ubuntu.com/about/release-cycle), and no longer receives maintenance updates. We strongly recommend users to upgrade to a newer release, such as 20.04.
 
@@ -1981,73 +2462,82 @@ GitLab 13.12 will be the last release with Ubuntu 16.04 support.
 
 ### Ubuntu 19.10 (Eoan Ermine) package
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 Ubuntu 19.10 (Eoan Ermine) reached end of life on Friday, July 17, 2020. In GitLab Runner 14.0, Ubuntu 19.10 (Eoan Ermine) is no longer available from our package distribution. Refer to [issue #26036](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26036) for details.
 
 ### Unicorn in GitLab self-managed
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 [Support for Unicorn](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6078) has been removed in GitLab 14.0 in favor of Puma. [Puma has a multi-threaded architecture](https://docs.gitlab.com/ee/administration/operations/puma.html) which uses less memory than a multi-process application server like Unicorn. On GitLab.com, we saw a 40% reduction in memory consumption by using Puma.
 
 ### WIP merge requests renamed 'draft merge requests'
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 The WIP (work in progress) status for merge requests signaled to reviewers that the merge request in question wasn't ready to merge. We've renamed the WIP feature to **Draft**, a more inclusive and self-explanatory term. **Draft** clearly communicates the merge request in question isn't ready for review, and makes no assumptions about the progress being made toward it. **Draft** also reduces the cognitive load for new users, non-English speakers, and anyone unfamiliar with the WIP acronym.
 
 ### Web Application Firewall (WAF)
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 The Web Application Firewall (WAF) was deprecated in GitLab 13.6 and is removed from GitLab 14.0. The WAF had limitations inherent in the architectural design that made it difficult to meet the requirements traditionally expected of a WAF. By removing the WAF, GitLab is able to focus on improving other areas in the product where more value can be provided to users. Users who currently rely on the WAF can continue to use the free and open source [ModSecurity](https://github.com/SpiderLabs/ModSecurity) project, which is independent from GitLab. Additional details are available in the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/271276).
 
 ### Windows Server 1903 image support
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In 14.0, we have removed Windows Server 1903. Microsoft ended support for this version on 2020-08-12. Refer to [issue #27551](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27551) for details.
 
 ### Windows Server 1909 image support
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In 14.0, we have removed Windows Server 1909. Microsoft ended support for this version on 2021-05-11. Refer to [issue #27899](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27899) for details.
 
 ### `/usr/lib/gitlab-runner` symlink from package
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In GitLab Runner 13.3, a symlink was added from `/user/lib/gitlab-runner/gitlab-runner` to `/usr/bin/gitlab-runner`. In 14.0, the symlink has been removed and the runner is now installed in `/usr/bin/gitlab-runner`. Refer to [issue #26651](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26651) for details.
 
 ### `?w=1` URL parameter to ignore whitespace changes
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 To create a consistent experience for users based on their preferences, support for toggling whitespace changes via URL parameter has been removed in GitLab 14.0.
 
 ### `CI_PROJECT_CONFIG_PATH` variable
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 The `CI_PROJECT_CONFIG_PATH` [predefined project variable](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)
 has been removed in favor of `CI_CONFIG_PATH`, which is functionally the same.
@@ -2057,41 +2547,47 @@ please update them to use `CI_CONFIG_PATH` instead.
 
 ### `FF_RESET_HELPER_IMAGE_ENTRYPOINT` feature flag
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In 14.0, we have deactivated the `FF_RESET_HELPER_IMAGE_ENTRYPOINT` feature flag. Refer to issue [#26679](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26679) for details.
 
 ### `FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL` feature flag
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 In [GitLab Runner 13.1](https://docs.gitlab.com/runner/executors/shell.html#gitlab-131-and-later), [issue #3376](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3376), we introduced `sigterm` and then `sigkill` to a process in the Shell executor. We also introduced a new feature flag, `FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL`, so you can use the previous process termination sequence. In GitLab Runner 14.0, [issue #6413](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6413), the feature flag has been removed.
 
 ### `FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER` feature flag
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 GitLab Runner 14.0 removes the `FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER` feature flag. Refer to [issue #27175](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27175) for details.
 
 ### `secret_detection_default_branch` job
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/297269).
+</div>
 
 To ensure Secret Detection was scanning both default branches and feature branches, we introduced two separate secret detection CI jobs (`secret_detection_default_branch` and `secret_detection`) in our managed [`Secret-Detection.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Secret-Detection.gitlab-ci.yml) template. These two CI jobs created confusion and complexity in the CI rules logic. This deprecation moves the `rule` logic into the `script` section, which then determines how the `secret_detection` job is run (historic, on a branch, commits, etc).
 If you override or maintain custom versions of `SAST.gitlab-ci.yml` or `Secret-Detection.gitlab-ci.yml`, you must update your CI templates. We strongly encourage [inheriting and overriding our managed CI templates](https://docs.gitlab.com/ee/user/application_security/secret_detection/#custom-settings-example) to future-proof your CI templates. GitLab 14.0 no longer supports the old `secret_detection_default_branch` job.
 
 ### `trace` parameter in `jobs` API
 
-WARNING:
-This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
-Review the details carefully before upgrading.
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone"></span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+</div>
 
 GitLab Runner was updated in GitLab 13.4 to internally stop passing the `trace` parameter to the `/api/jobs/:id` endpoint. GitLab 14.0 deprecates the `trace` parameter entirely for all other requests of this endpoint. Make sure your [GitLab Runner version matches your GitLab version](https://docs.gitlab.com/runner/#gitlab-runner-versions) to ensure consistent behavior.
diff --git a/doc/update/terminology.md b/doc/update/terminology.md
new file mode 100644
index 00000000000..6babbdbc991
--- /dev/null
+++ b/doc/update/terminology.md
@@ -0,0 +1,47 @@
+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Deprecation terms
+
+## Deprecation
+
+- Required before ending support for a feature or removing a feature.
+- Feature not recommended for use.
+- Development restricted to Priority 1 / Severity 1 bug fixes.
+- Will be removed in a future major release.
+- Begins after a deprecation announcement outlining an end-of-support or removal date.
+- Ends after the end-of-support date or removal date has passed.
+
+## End of Support
+
+- Optional step before removal.
+- Feature usage strongly discouraged.
+- No support or fixes provided.
+- No longer tested internally.
+- Will be removed in a future major release.
+- Begins after an end-of-support date has passed.
+
+[Announcing an End of Support period](https://about.gitlab.com/handbook/marketing/blog/release-posts/#announcing-an-end-of-support-period)
+should only be used in special circumstances and is not recommended for general use.
+Most features should be deprecated and then removed.
+
+## Removal
+
+- Feature usage impossible.
+- Feature no longer supported (if End of Support period hasn't already been announced).
+- Happens in a major release in line with our
+  [semantic versioning policy](../policy/maintenance.md).
+- Begins after removal date has passed.
+
+## Breaking change
+
+A "breaking change" is any change that requires users to make a corresponding change to their code, settings, or workflow. "Users" might be humans, API clients, or even code classes that "use" another class. Examples of breaking changes include:
+
+- Removing a user-facing feature without a replacement/workaround.
+- Changing the definition of an existing API (by doing things like re-naming query parameters or changing routes).
+- Removing a public method from a code class.
+
+A breaking change can be considered major if it affects many users, or represents a significant change in behavior.
diff --git a/doc/update/upgrading_from_ce_to_ee.md b/doc/update/upgrading_from_ce_to_ee.md
index 8a66da507ec..acc2237f7a1 100644
--- a/doc/update/upgrading_from_ce_to_ee.md
+++ b/doc/update/upgrading_from_ce_to_ee.md
@@ -4,7 +4,7 @@ group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Upgrading from Community Edition to Enterprise Edition from source **(FREE SELF)**
+# Upgrading from Community Edition to Enterprise Edition for self-compiled installations **(FREE SELF)**
 
 NOTE:
 In the past we used separate documents for upgrading from
@@ -39,9 +39,6 @@ cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
 ```
 
-For installations using MySQL, this may require granting `LOCK TABLES`
-privileges to the GitLab user on the database version.
-
 ### 1. Stop server
 
 ```shell
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index 7e2c9bf53dd..c8bed431780 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -4,13 +4,13 @@ group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Upgrading Community Edition and Enterprise Edition from source **(FREE SELF)**
+# Upgrading self-compiled installations **(FREE SELF)**
 
 Make sure you view this upgrade guide from the branch (version) of GitLab you
-would like to install (for example, `11.8`). You can select the required version of documentation in the dropdown list in the upper-right corner of GitLab documentation page.
+would like to install (for example, `16.0`). You can select the required version of documentation in the dropdown list in the upper-right corner of GitLab documentation page.
 
-In each of the following examples, replace `BRANCH` with the branch of the version you upgrading to (for example, `11-8-stable` for `11.8`). Replace `PREVIOUS_BRANCH` with the
-branch for the version you are upgrading from (for example, `11-7-stable` for `11.7`).
+In each of the following examples, replace `BRANCH` with the branch of the version you upgrading to (for example, `16-0-stable` for `16.0`). Replace `PREVIOUS_BRANCH` with the
+branch for the version you are upgrading from (for example, `15-11-stable` for `15.11`).
 
 If the highest number stable branch is unclear check the
 [GitLab Blog](https://about.gitlab.com/blog/archives.html) for installation
@@ -38,7 +38,11 @@ specific guidelines (should there be any) are covered separately.
 
 ### 1. Backup
 
-If you installed GitLab from source, make sure `rsync` is installed.
+Prerequisites:
+
+- Make sure `rsync` is installed.
+
+Perform the backup:
 
 ```shell
 cd /home/git/gitlab
@@ -218,7 +222,7 @@ via [`/etc/default/gitlab`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/l
 
 #### SMTP configuration
 
-If you're installing from source and use SMTP to deliver mail, you must
+If you use SMTP to deliver mail, you must
 add the following line to `config/initializers/smtp_settings.rb`:
 
 ```ruby
@@ -400,7 +404,7 @@ see how to [upgrade to a later version](../administration/docs_self_host.md#upgr
 Upgrading versions might need some manual intervention. For more information,
 [check the version you are upgrading to](index.md#version-specific-upgrading-instructions)
 for additional steps required for all GitLab installations, and for
-steps that apply to self-compiled (source) installations.
+steps that apply to self-compiled installations.
 
 ## Troubleshooting
 
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index 0eb7a520850..c815087b0b3 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -94,7 +94,7 @@ meet the other online upgrade requirements mentioned above.
 
 WARNING:
 You can only upgrade one minor release at a time. So from 15.6 to 15.7, not to 15.8.
-If you attempt more than one minor release, the upgrade may fail. 
+If you attempt more than one minor release, the upgrade may fail.
 
 ### Use a load balancer in front of web (Puma) nodes
 
diff --git a/doc/user/admin_area/analytics/dev_ops_reports.md b/doc/user/admin_area/analytics/dev_ops_reports.md
index 31cc9825452..69bf4ff30f1 100644
--- a/doc/user/admin_area/analytics/dev_ops_reports.md
+++ b/doc/user/admin_area/analytics/dev_ops_reports.md
@@ -12,8 +12,9 @@ from planning to monitoring.
 
 To see DevOps Reports:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Analytics > DevOps Reports**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Analytics > DevOps Reports**.
 
 ## DevOps Score
 
@@ -39,7 +40,7 @@ feature is available.
 
 ## DevOps Adoption **(ULTIMATE SELF)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247112) in GitLab 13.7 as a [Beta feature](../../../policy/alpha-beta-support.md#beta).
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247112) in GitLab 13.7 as a [Beta feature](../../../policy/experiment-beta-support.md#beta).
 > - The Overview tab [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330401) in GitLab 14.1.
 > - DAST and SAST metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/328033) in GitLab 14.1.
 > - Fuzz Testing metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/330398) in GitLab 14.2.
diff --git a/doc/user/admin_area/analytics/index.md b/doc/user/admin_area/analytics/index.md
index 2ac8941b286..6441cd866c8 100644
--- a/doc/user/admin_area/analytics/index.md
+++ b/doc/user/admin_area/analytics/index.md
@@ -18,8 +18,9 @@ Prerequisite:
 
 To view instance-level analytics:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Analytics**, then one of the available analytics:
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Analytics**, then one of the available analytics:
 
    - [DevOps Reports](dev_ops_reports.md): Provides an overview of your entire instance's feature usage.
    - [Usage Trends](usage_trends.md): Shows how much data your instance contains, and how the data is changing.
diff --git a/doc/user/admin_area/analytics/usage_trends.md b/doc/user/admin_area/analytics/usage_trends.md
index a240a1ff524..49e82f71a3a 100644
--- a/doc/user/admin_area/analytics/usage_trends.md
+++ b/doc/user/admin_area/analytics/usage_trends.md
@@ -19,8 +19,9 @@ Usage Trends data refreshes daily.
 
 To view Usage Trends:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Analytics > Usage Trends**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Analytics > Usage Trends**.
 
 ## Total counts
 
diff --git a/doc/user/admin_area/appearance.md b/doc/user/admin_area/appearance.md
index a5311b083c3..99c2a453b07 100644
--- a/doc/user/admin_area/appearance.md
+++ b/doc/user/admin_area/appearance.md
@@ -9,12 +9,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Several options are available for customizing the appearance of a self-managed instance
 of GitLab. To access these settings:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Appearance**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Appearance**.
 
-## Top bar
+## Navigation bar
 
-By default, the **top bar** has the GitLab logo, but this can be customized with
+By default, the navigation bar has the GitLab logo, but this can be customized with
 any image desired. It is optimized for images 28px high (any width), but any image can be
 used (less than 1 MB) and it is automatically resized.
 
@@ -82,8 +83,9 @@ description, and icon.
 
 To configure the PWA settings:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Appearance**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Appearance**.
 1. Scroll to the **Progressive Web App (PWA)** section.
 1. Complete the fields.
    - **Icon**: If you use the standard GitLab icon, it is available in sizes 192x192 pixels,
diff --git a/doc/user/admin_area/broadcast_messages.md b/doc/user/admin_area/broadcast_messages.md
index acb3e92fff8..6fe82b3ae83 100644
--- a/doc/user/admin_area/broadcast_messages.md
+++ b/doc/user/admin_area/broadcast_messages.md
@@ -19,7 +19,7 @@ Broadcast messages can be managed using the [broadcast messages API](../../api/b
 
 ## Banners
 
-Banners are shown on the top of a page and in Git remote responses.
+Banners are shown on the top of a page and optionally in the command line as a Git remote response.
 
 ![Broadcast Message Banner](img/broadcast_messages_banner_v15_0.png)
 
@@ -32,7 +32,7 @@ remote:
 ...
 ```
 
-If more than one banner is active at one time, they are displayed in a stack in order of creation.
+If more than one banner is active at one time, they are displayed at the top of the page in order of creation. In the command line, only the latest banner is shown.
 
 ## Notifications
 
@@ -57,8 +57,9 @@ To display messages to users on your GitLab instance, add a broadcast message.
 
 To add a broadcast message:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Messages**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Messages**.
 1. Add the text for the message to the **Message** field. You can style a message's content using Markdown, emoji, and the `a` and `br` HTML tags.
    The `br` tag inserts a line break. The `a` HTML tag accepts `class` and `style` attributes with the following CSS properties:
     - `color`
@@ -69,6 +70,7 @@ To add a broadcast message:
     - `text-decoration`
 1. Select a **Theme**. The default theme is `indigo`.
 1. Select the **Dismissable** checkbox to enable users to dismiss the broadcast message.
+1. Optional. Clear the **Git remote responses** checkbox to prevent broadcast messages from being displayed in the command line as Git remote responses.
 1. Optional. Select **Target roles** to only show the broadcast message to users with the selected roles. The message displays on group, subgroup, and project pages, and does not display in Git remote responses.
 1. If required, add a **Target Path** to only show the broadcast message on URLs matching that path. You can use the wildcard character `*` to match multiple URLs, for example `mygroup/myproject*`.
 1. Select a date and time (UTC) for the message to start and end.
@@ -83,8 +85,9 @@ If you must make changes to a broadcast message, you can edit it.
 
 To edit a broadcast message:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Messages**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Messages**.
 1. From the list of broadcast messages, select the edit button for the message.
 1. After making the required changes, select **Update broadcast message**.
 
@@ -97,8 +100,9 @@ You can delete a broadcast message while it's active.
 
 To delete a broadcast message:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Messages**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Messages**.
 1. From the list of broadcast messages, select the delete button for the message.
 
 When a broadcast message is deleted, it's removed from the list of broadcast messages.
diff --git a/doc/user/admin_area/credentials_inventory.md b/doc/user/admin_area/credentials_inventory.md
index 5fee0c42a77..9bacd101c48 100644
--- a/doc/user/admin_area/credentials_inventory.md
+++ b/doc/user/admin_area/credentials_inventory.md
@@ -31,8 +31,9 @@ You can also [revoke](#revoke-a-users-personal-access-token) and [delete](#delet
 
 To access the Credentials inventory:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Credentials**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Credentials**.
 
 ## Revoke a user's personal access token
 
diff --git a/doc/user/admin_area/custom_project_templates.md b/doc/user/admin_area/custom_project_templates.md
index 9d360539595..0e0acf4af57 100644
--- a/doc/user/admin_area/custom_project_templates.md
+++ b/doc/user/admin_area/custom_project_templates.md
@@ -33,7 +33,9 @@ To set project templates at the group level, see [Custom group-level project tem
 
 To select the group to use as the source for the project templates:
 
-1. On the top bar, navigate to **Main menu > Admin > Settings > Templates**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Templates**.
 1. Expand **Custom project templates**.
 1. Select a group to use.
 1. Select **Save changes**.
diff --git a/doc/user/admin_area/diff_limits.md b/doc/user/admin_area/diff_limits.md
index 3d7c49c1f2b..72e8269e455 100644
--- a/doc/user/admin_area/diff_limits.md
+++ b/doc/user/admin_area/diff_limits.md
@@ -33,8 +33,9 @@ set values are presented as **Too large** are cannot be expanded in the UI.
 
 To configure these values:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **Diff limits**.
 1. Enter a value for the diff limit.
 1. Select **Save changes**.
diff --git a/doc/user/admin_area/email_from_gitlab.md b/doc/user/admin_area/email_from_gitlab.md
index ba465fbea29..fbdfe437719 100644
--- a/doc/user/admin_area/email_from_gitlab.md
+++ b/doc/user/admin_area/email_from_gitlab.md
@@ -22,8 +22,9 @@ For information about email notifications originating from GitLab, read
 
 ## Sending emails to users from GitLab
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select **Send email to users**.
 
    ![administrators](img/email1.png)
diff --git a/doc/user/admin_area/external_users.md b/doc/user/admin_area/external_users.md
index 5127630d65e..a63093deab0 100644
--- a/doc/user/admin_area/external_users.md
+++ b/doc/user/admin_area/external_users.md
@@ -40,7 +40,8 @@ An administrator can flag a user as external by either of the following methods:
 
 - [Through the API](../../api/users.md#user-modification).
 - Using the GitLab UI:
-  1. On the top bar, select **Main menu > Admin**.
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
   1. On the left sidebar, select **Overview > Users** to create a new user or edit an existing one.
      There, you can find the option to flag the user as external.
 
@@ -55,8 +56,9 @@ Additionally, users can be set as external users using:
 By default, new users are not set as external users. This behavior can be changed
 by an administrator:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Account and limit** section.
 
 If you change the default behavior of creating new users as external, you
diff --git a/doc/user/admin_area/geo_sites.md b/doc/user/admin_area/geo_sites.md
index 9fe36188dd0..3bae90aaec8 100644
--- a/doc/user/admin_area/geo_sites.md
+++ b/doc/user/admin_area/geo_sites.md
@@ -11,8 +11,9 @@ You can configure various settings for GitLab Geo sites. For more information, s
 
 On either the primary or secondary site:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Geo > Sites**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Geo > Sites**.
 
 ## Common settings
 
@@ -71,8 +72,9 @@ the primary uses the secondary's internal URL to contact it directly.
 
 The internal URL defaults to external URL. To change it:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Geo > Sites**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Geo > Sites**.
 1. Select **Edit** on the site you want to customize.
 1. Edit the internal URL.
 1. Select **Save changes**.
diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md
index 71c2468c97f..a59501f14ce 100644
--- a/doc/user/admin_area/index.md
+++ b/doc/user/admin_area/index.md
@@ -7,72 +7,24 @@ type: reference
 
 # GitLab Admin Area **(FREE SELF)**
 
-The Admin Area provides a web UI to manage and configure some features of GitLab
-self-managed instances. If you are an administrator, you can access the Admin Area
-by visiting `/admin` on your self-managed instance. You can also access it through
-the UI:
+The Admin Area provides a web UI to manage and configure features of GitLab
+self-managed instances. If you are an administrator,to access the Admin Area:
 
-- GitLab versions 14.0 and later: on the top bar, select **Main menu > Admin**.
-- GitLab versions 13.12 and earlier: on the top bar, select the Admin Area icon (**{admin}**).
+- In GitLab 16.1 and later: on the left sidebar, expand the top-most chevron (**{chevron-down}**), then select **Admin Area**.
+- In GitLab 16.0 and earlier: on the top bar, select **Main menu > Admin**.
 
 NOTE:
 Only administrators can access the Admin Area.
 
-## Admin Area sections
-
-The Admin Area is made up of the following sections:
-
-| Section                                        | Description |
-|:-----------------------------------------------|:------------|
-| **{overview}** [Overview](#overview-section)   | View your GitLab [Dashboard](#admin-area-dashboard), and administer [projects](#administering-projects), [users](#administering-users), [groups](#administering-groups), [topics](#administering-topics), [jobs](#administering-jobs), [runners](#administering-runners), and [Gitaly servers](#administering-gitaly-servers). |
-| **{monitor}** Monitoring                       | View GitLab [system information](#system-information), and information on [background jobs](#background-jobs), [logs](#logs), [health checks](monitoring/health_check.md), and [audit events](#audit-events). |
-| **{messages}** Messages                        | Send and manage [broadcast messages](broadcast_messages.md) for your users. |
-| **{hook}** System Hooks                        | Configure [system hooks](../../administration/system_hooks.md) for many events. |
-| **{applications}** Applications                | Create system [OAuth applications](../../integration/oauth_provider.md) for integrations with other services. |
-| **{slight-frown}** Abuse Reports               | Manage [abuse reports](review_abuse_reports.md) submitted by your users. |
-| **{license}** License                          | Add, display, and remove [licenses](license.md). |
-| **{cloud-gear}** Kubernetes                    | Create and manage instance-level [Kubernetes clusters](../instance/clusters/index.md). |
-| **{push-rules}** Push rules | Configure pre-defined Git [push rules](../project/repository/push_rules.md) for projects. Also, configure [merge requests approvers rules](merge_requests_approvals.md). |
-| **{location-dot}** Geo                         | Configure and maintain [Geo sites](geo_sites.md). |
-| **{key}** Deploy keys                          | Create instance-wide [SSH deploy keys](../project/deploy_keys/index.md). |
-| **{lock}** Credentials                         | View [credentials](credentials_inventory.md) that can be used to access your instance. |
-| **{template}** Integrations                    | Manage [instance-level default settings](settings/project_integration_management.md) for a project integration. |
-| **{labels}** Labels                            | Create and maintain [labels](labels.md) for your GitLab instance. |
-| **{appearance}** Appearance                    | Customize [GitLab appearance](appearance.md). |
-| **{settings}** Settings                        | Modify the [settings](settings/index.md) for your GitLab instance. |
-
-## Admin Area dashboard
-
-The Dashboard provides statistics and system information about the GitLab instance.
-
-To access the Dashboard, either:
-
-- On the top bar, select **Main menu > Admin**.
-- Visit `/admin` on your self-managed instance.
-
-The Dashboard is the default view of the Admin Area, and is made up of the following sections:
-
-| Section    | Description |
-|:-----------|:------------|
-| Projects   | The total number of projects, up to 10 of the latest projects, and the option of creating a new project. |
-| Users      | The total number of users, up to 10 of the latest users, the option of creating a new user, and a link to [**Users statistics**](#users-statistics). |
-| Groups     | The total number of groups, up to 10 of the latest groups, and the option of creating a new group. |
-| Statistics | Totals of all elements of the GitLab instance. |
-| Features   | All features available on the GitLab instance. Enabled features are marked with a green circle icon, and disabled features are marked with a power icon. |
-| Components | The major components of GitLab and the version number of each. A link to the Gitaly Servers is also included. |
-
-## Overview section
-
-The following topics document the **Overview** section of the Admin Area.
-
-### Administering Projects
+## Administering projects
 
 You can administer all projects in the GitLab instance from the Admin Area's Projects page.
 
 To access the Projects page:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Projects**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Projects**.
 1. Select the **All**, **Private**, **Internal**, or **Public** tab to list only
    projects of that criteria.
 
@@ -118,12 +70,13 @@ You can combine the filter options. For example, to list only public projects wi
 1. Select the **Public** tab.
 1. Enter `score` in the **Filter by name...** input box.
 
-### Administering Users
+## Administering users
 
 You can administer all users in the GitLab instance from the Admin Area's Users page:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 
 To list users matching a specific criteria, select one of the following tabs on the **Users** page:
 
@@ -159,14 +112,15 @@ To search for users, enter your criteria in the search field. The user search is
 insensitive, and applies partial matching to name and username. To search for an email address,
 you must provide the complete email address.
 
-#### User impersonation
+### User impersonation
 
 An administrator can "impersonate" any other user, including other administrators.
 This allows the administrator to "see what the user sees," and take actions on behalf of the user.
 You can impersonate a user in the following ways:
 
 - Through the UI:
-  1. On the top bar, select **Main menu > Admin**.
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
   1. On the left sidebar, select **Overview > Users**.
   1. From the list of users, select a user.
   1. Select **Impersonate**.
@@ -178,21 +132,22 @@ By default, impersonation is enabled. GitLab can be configured to [disable imper
 
 ![user impersonation button](img/impersonate_user_button_v13_8.png)
 
-#### User identities
+### User identities
 
 > The ability to see a user's SCIM identity was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/294608) in GitLab 15.3.
 
 When using authentication providers, administrators can see the identities for a user:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. From the list of users, select a user.
 1. Select **Identities**.
 
 This list shows the user's identities, including SCIM identities. Administrators can use this information to troubleshoot SCIM-related issues and confirm
 the identities being used for an account.
 
-#### User Permission Export **(PREMIUM SELF)**
+### User Permission Export **(PREMIUM SELF)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1772) in GitLab 13.8.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292436) in GitLab 13.9.
@@ -213,7 +168,7 @@ Only the first 100,000 user accounts are exported.
 
 ![user permission export button](img/export_permissions_v13_11.png)
 
-#### Users statistics
+### Users statistics
 
 The **Users statistics** page provides an overview of user accounts by role. These statistics are
 calculated daily, so user changes made since the last update are not reflected.
@@ -226,28 +181,30 @@ The following totals are also included:
 
 GitLab billing is based on the number of [**Billable users**](../../subscriptions/self_managed/index.md#billable-users).
 
-#### Add email to user
+### Add email to user
 
 You must be an administrator to manually add emails to users:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users** (`/admin/users`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Locate the user and select them.
 1. Select **Edit**.
 1. In **Email**, enter the new email address. This adds the new email address to the
    user and sets the previous email address to be a secondary.
 1. Select **Save changes**.
 
-### User cohorts
+## User cohorts
 
 The [Cohorts](user_cohorts.md) tab displays the monthly cohorts of new users and their activities over time.
 
-### Prevent a user from creating groups
+## Prevent a user from creating groups
 
 By default, users can create groups. To prevent a user from creating a top level group:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users** (`/admin/users`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Locate the user and select them.
 1. Select **Edit**.
 1. Clear the **Can create group** checkbox.
@@ -255,14 +212,15 @@ By default, users can create groups. To prevent a user from creating a top level
 
 It is also possible to [limit which roles can create a subgroup within a group](../group/subgroups/index.md#change-who-can-create-subgroups).
 
-### Administering Groups
+## Administering groups
 
 You can administer all groups in the GitLab instance from the Admin Area's Groups page.
 
 To access the Groups page:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Groups**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Groups**.
 
 For each group, the page displays their name, description, size, number of projects in the group,
 number of members, and whether the group is private, internal, or public. To edit a group, in the group's row, select **Edit**. To delete the group, in the group's row, select **Delete**.
@@ -273,9 +231,9 @@ sort order is by **Last created**.
 To search for groups by name, enter your criteria in the search field. The group search is case
 insensitive, and applies partial matching.
 
-To [Create a new group](../group/manage.md#create-a-group) select **New group**.
+To [Create a new group](../group/index.md#create-a-group) select **New group**.
 
-### Administering Topics
+## Administering topics
 
 - > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/340920) in GitLab 14.4.
 - > Merging topics [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/366884) in GitLab 15.5.
@@ -286,8 +244,9 @@ You can administer all topics in the GitLab instance from the Admin Area's Topic
 
 To access the Topics page:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Topics**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Topics**.
 
 For each topic, the page displays its name and the number of projects labeled with the topic.
 
@@ -307,15 +266,16 @@ The assigned topics are visible only to everyone with access to the project,
 but everyone can see which topics exist on the GitLab instance.
 Do not include sensitive information in the name of a topic.
 
-### Administering Gitaly servers
+## Administering Gitaly servers
 
 You can list all Gitaly servers in the GitLab instance from the Admin Area's **Gitaly Servers**
 page. For more details, see [Gitaly](../../administration/gitaly/index.md).
 
 To access the **Gitaly Servers** page:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Gitaly Servers**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Gitaly Servers**.
 
 For each Gitaly server, the following details are listed:
 
@@ -338,8 +298,9 @@ You can administer all runners in the GitLab instance from the Admin Area's **Ru
 
 To access the **Runners** page:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Runners**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Runners**.
 
 #### Search and filter runners
 
@@ -364,8 +325,9 @@ You can also filter runners by status, type, and tag. To filter:
 
 You can delete multiple runners at the same time.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Runners**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Runners**.
 1. To the left of the runners you want to delete, select the checkbox.
    To select all of the runners on the page, select the checkbox above
    the list.
@@ -394,8 +356,9 @@ You can administer all jobs in the GitLab instance from the Admin Area's Jobs pa
 
 To access the Jobs page:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **CI/CD > Jobs**. All jobs are listed, in descending order of job ID.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **CI/CD > Jobs**. All jobs are listed, in descending order of job ID.
 1. Select the **All** tab to list all jobs. Select the **Pending**, **Running**, or **Finished**
    tab to list only jobs of that status.
 
diff --git a/doc/user/admin_area/license.md b/doc/user/admin_area/license.md
index 823f876539f..be6478de2a0 100644
--- a/doc/user/admin_area/license.md
+++ b/doc/user/admin_area/license.md
@@ -28,8 +28,9 @@ To activate your instance with an activation code:
    - Your subscription confirmation email.
    - The [Customers Portal](https://customers.gitlab.com/customers/sign_in), on the **Manage Purchases** page.
 1. Sign in to your GitLab self-managed instance.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Subscription**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Subscription**.
 1. Paste the activation code in **Activation code**.
 1. Read and accept the terms of service.
 1. Select **Activate**.
diff --git a/doc/user/admin_area/license_file.md b/doc/user/admin_area/license_file.md
index 01d2c31dd10..12e908b4fe0 100644
--- a/doc/user/admin_area/license_file.md
+++ b/doc/user/admin_area/license_file.md
@@ -18,8 +18,9 @@ link to the **Add license** page should be displayed.
 Otherwise, to add your license:
 
 1. Sign in to GitLab as an administrator.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. In the **Add License** area, add a license by either uploading the file or entering the key.
 1. Select the **Terms of Service** checkbox.
 1. Select **Add license**.
@@ -42,7 +43,7 @@ export GITLAB_ACTIVATION_CODE=your_activation_code
 
 If you have a license, you can also import it when you install GitLab.
 
-- **For installations from source**
+- For self-compiled installations:
   - Place the `Gitlab.gitlab-license` file in the `config/` directory.
   - To specify a custom location and filename for the license, set the
     `GITLAB_LICENSE_FILE` environment variable with the path to the file:
@@ -51,7 +52,7 @@ If you have a license, you can also import it when you install GitLab.
     export GITLAB_LICENSE_FILE="/path/to/license/file"
     ```
 
-- **For Omnibus package**
+- For Linux package installations:
   - Place the `Gitlab.gitlab-license` file in the `/etc/gitlab/` directory.
   - To specify a custom location and filename for the license, add this entry to `gitlab.rb`:
 
@@ -95,8 +96,9 @@ To go back to Free features, [delete all expired licenses](#remove-a-license).
 
 To remove a license from a self-managed instance:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Subscription**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Subscription**.
 1. Select **Remove license**.
 
 Repeat these steps to remove all licenses, including those applied in the past.
@@ -105,8 +107,9 @@ Repeat these steps to remove all licenses, including those applied in the past.
 
 To view your license details:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Subscription**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Subscription**.
 
 You can add and view more than one license, but only the latest license in
 the current date range is the active license.
diff --git a/doc/user/admin_area/merge_requests_approvals.md b/doc/user/admin_area/merge_requests_approvals.md
index b2f24091d7c..58f54c399df 100644
--- a/doc/user/admin_area/merge_requests_approvals.md
+++ b/doc/user/admin_area/merge_requests_approvals.md
@@ -19,8 +19,10 @@ and can no longer be changed:
 
 To enable merge request approval settings for an instance:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **{push-rules}** **Push Rules**, and expand **Merge request approvals**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Push Rules**.
+1. Expand **Merge request approvals**.
 1. Choose the required options.
 1. Select **Save changes**.
 
diff --git a/doc/user/admin_area/moderate_users.md b/doc/user/admin_area/moderate_users.md
index b0e24559e47..ee6d360ac1d 100644
--- a/doc/user/admin_area/moderate_users.md
+++ b/doc/user/admin_area/moderate_users.md
@@ -42,8 +42,9 @@ sign in.
 
 To view user sign ups pending approval:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select the **Pending approval** tab.
 
 ### Approve or reject a user sign up
@@ -52,8 +53,9 @@ A user sign up pending approval can be approved or rejected from the Admin Area.
 
 To approve or reject a user sign up:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select the **Pending approval** tab.
 1. Optional. Select a user.
 1. Select the **{settings}** **User administration** dropdown list.
@@ -77,8 +79,9 @@ administrators can choose to block the user.
 Users can be blocked [via an abuse report](review_abuse_reports.md#blocking-users),
 by removing them in LDAP, or directly from the Admin Area. To do this:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Optional. Select a user.
 1. Select the **{settings}** **User administration** dropdown list.
 1. Select **Block**.
@@ -100,8 +103,9 @@ Users can also be blocked using the [GitLab API](../../api/users.md#block-user).
 
 A blocked user can be unblocked from the Admin Area. To do this:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select the **Blocked** tab.
 1. Optional. Select a user.
 1. Select the **{settings}** **User administration** dropdown list.
@@ -116,8 +120,9 @@ Users can also be unblocked using the [GitLab API](../../api/users.md#unblock-us
 The unblock option may be unavailable for LDAP users. To enable the unblock option,
 the LDAP identity first needs to be deleted:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select the **Blocked** tab.
 1. Select a user.
 1. Select the **Identities** tab.
@@ -155,8 +160,9 @@ Users are notified about account deactivation if
 
 A user can be deactivated from the Admin Area. To do this:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Optional. Select a user.
 1. Select the **{settings}** **User administration** dropdown list.
 1. Select **Deactivate**.
@@ -182,8 +188,9 @@ Administrators can enable automatic deactivation of users who either:
 
 To do this:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Account and limit** section.
 1. Under **Dormant users**, check **Deactivate dormant users after a period of inactivity**.
 1. Under **Days of inactivity before deactivation**, enter the number of days before deactivation. Minimum value is 90 days.
@@ -201,8 +208,9 @@ A deactivated user can be activated from the Admin Area.
 
 To do this:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select the **Deactivated** tab.
 1. Optional. Select a user.
 1. Select the **{settings}** **User administration** dropdown list.
@@ -218,14 +226,11 @@ Users can also be activated using the [GitLab API](../../api/users.md#activate-u
 ## Ban and unban users
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327353) in GitLab 14.2 [with a flag](../../administration/feature_flags.md) named `ban_user_feature_flag`. Disabled by default.
-> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/330667) in GitLab 14.8.
+> - Ban and unban users [generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/327353) in GitLab 14.8. Feature flag `ban_user_feature_flag` removed.
+> - Hiding merge requests of banned users [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107836) in GitLab 15.8 [with a flag](../../administration/feature_flags.md) named `hide_merge_requests_from_banned_users`. Disabled by default.
+> - Hiding comments of banned users [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112973) in GitLab 15.11 [with a flag](../../administration/feature_flags.md) named `hidden_notes`. Disabled by default.
 
-FLAG:
-On self-managed GitLab, by default this feature is available.
-On GitLab.com, this feature is available to GitLab.com administrators only.
-
-GitLab administrators can ban and unban users. Banned users are blocked, and their issues and merge requests are hidden.
-The banned user's comments are still displayed. Hiding a banned user's comments is [tracked in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/327356).
+GitLab administrators can ban and unban users. Banned users are blocked, and their issues, merge requests, and comments are hidden.
 
 ### Ban a user
 
@@ -233,8 +238,9 @@ To block a user and hide their contributions, administrators can ban the user.
 
 Users can be banned using the Admin Area. To do this:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Optional. Select a user.
 1. Select the **{settings}** **User administration** dropdown list.
 1. Select **Ban user**.
@@ -245,8 +251,9 @@ The banned user does not consume a [seat](../../subscriptions/self_managed/index
 
 A banned user can be unbanned using the Admin Area. To do this:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select the **Banned** tab.
 1. Optional. Select a user.
 1. Select the **{settings}** **User administration** dropdown list.
@@ -259,8 +266,9 @@ The user's state is set to active and they consume a
 
 Use the Admin Area to delete users.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select the **Banned** tab.
 1. Optional. Select a user.
 1. Select the **{settings}** **User administration** dropdown list.
@@ -273,8 +281,9 @@ You can only delete a user if there are inherited or direct owners of a group. Y
 
 You can also delete a user and their contributions, such as merge requests, issues, and groups of which they are the only group owner.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select the **Banned** tab.
 1. Optional. Select a user.
 1. Select the **{settings}** **User administration** dropdown list.
diff --git a/doc/user/admin_area/reporting/git_abuse_rate_limit.md b/doc/user/admin_area/reporting/git_abuse_rate_limit.md
index 83b28404714..38aaeb8eb55 100644
--- a/doc/user/admin_area/reporting/git_abuse_rate_limit.md
+++ b/doc/user/admin_area/reporting/git_abuse_rate_limit.md
@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Git abuse rate limit (administration) **(ULTIMATE SELF)**
 
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/8066) in GitLab 15.2 [with a flag](../../../administration/feature_flags.md) named `git_abuse_rate_limit_feature_flag`. Disabled by default.
-> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/394996) in GitLab 15.10. Feature flag `git_abuse_rate_limit_feature_flag` removed.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/394996) in GitLab 15.11. Feature flag `git_abuse_rate_limit_feature_flag` removed.
 
 This is the administration documentation. For information about Git abuse rate limiting at the group level, see the [group-level documentation](../../group/reporting/git_abuse_rate_limit.md).
 
@@ -15,10 +15,15 @@ Git abuse rate limiting is a feature to automatically [ban users](../moderate_us
 
 Git abuse rate limiting does not apply to instance administrators, [deploy tokens](../../../user/project/deploy_tokens/index.md), or [deploy keys](../../../user/project/deploy_keys/index.md).
 
+How GitLab determines a user's rate limit is under development.
+GitLab team members can view more information in this confidential epic:
+`https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14`.
+
 ## Configure Git abuse rate limiting
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Reporting**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Reporting**.
 1. Expand **Git abuse rate limit**.
 1. Update the Git abuse rate limit settings:
    1. Enter a number in the **Number of repositories** field, greater than or equal to `0` and less than or equal to `10,000`. This number specifies the maximum amount of unique repositories a user can download in the specified time period before they're banned. When set to `0`, Git abuse rate limiting is disabled.
@@ -36,8 +41,9 @@ If automatic banning is enabled, an email notification is sent when a user is ab
 
 ## Unban a user
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select the **Banned** tab and search for the account you want to unban.
 1. From the **User administration** dropdown list select **Unban user**.
 1. On the confirmation dialog, select **Unban user**.
diff --git a/doc/user/admin_area/reporting/ip_addr_restrictions.md b/doc/user/admin_area/reporting/ip_addr_restrictions.md
new file mode 100644
index 00000000000..5b749c62c30
--- /dev/null
+++ b/doc/user/admin_area/reporting/ip_addr_restrictions.md
@@ -0,0 +1,33 @@
+---
+stage: Anti-Abuse
+group: Anti-Abuse
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# IP address restrictions **(FREE SELF)**
+
+IP address restrictions help prevent malicious users hiding their activities behind multiple IP addresses.
+
+GitLab maintains a list of the unique IP addresses used by a user to make requests over a specified period. When the
+specified limit is reached, any requests made by the user from a new IP address are rejected with a `403 Forbidden` error.
+
+IP addresses are cleared from the list when no further requests have been made by the user from the IP address in the specified time period.
+
+NOTE:
+When a runner runs a CI/CD job as a particular user, the runner IP address is also stored against the user's list of
+unique IP addresses. Therefore, the IP addresses per user limit should take into account the number of configured active runners.
+
+## Configure IP address restrictions
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Reporting**.
+1. Expand **Spam and Anti-bot Protection**.
+1. Update the IP address restrictions settings:
+   1. Select the **Limit sign in from multiple IP addresses** checkbox to enable IP address restrictions.
+   1. Enter a number in the **IP addresses per user** field, greater than or equal to `1`. This number specifies the
+      maximum number of unique IP addresses a user can access GitLab from in the specified time period before requests
+      from a new IP address are rejected.
+   1. Enter a number in the **IP address expiration time** field, greater than or equal to `0`. This number specifies the
+      time in seconds an IP address counts towards the limit for a user, taken from the time the last request was made.
+1. Select **Save changes**.
diff --git a/doc/user/admin_area/reporting/spamcheck.md b/doc/user/admin_area/reporting/spamcheck.md
index 16c144d2469..e2508476c80 100644
--- a/doc/user/admin_area/reporting/spamcheck.md
+++ b/doc/user/admin_area/reporting/spamcheck.md
@@ -40,8 +40,9 @@ Spamcheck is only available for package-based installations:
 
 ## Configure GitLab to use Spamcheck
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Reporting**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Reporting**.
 1. Expand **Spam and Anti-bot Protection**.
 1. Update the Spam Check settings:
    1. Check the "Enable Spam Check via external API endpoint" checkbox.
diff --git a/doc/user/admin_area/review_abuse_reports.md b/doc/user/admin_area/review_abuse_reports.md
index 314e0c77f36..5cd63ec964c 100644
--- a/doc/user/admin_area/review_abuse_reports.md
+++ b/doc/user/admin_area/review_abuse_reports.md
@@ -16,8 +16,9 @@ reports in the Admin Area.
 
 To receive notifications of new abuse reports by email:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Reporting**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Reporting**.
 1. Expand the **Abuse reports** section.
 1. Provide an email address and select **Save changes**.
 
@@ -33,8 +34,9 @@ To find out more about reporting abuse, see
 
 To access abuse reports:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Abuse Reports**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Abuse Reports**.
 
 There are 3 ways to resolve an abuse report, with a button for each method:
 
diff --git a/doc/user/admin_area/settings/account_and_limit_settings.md b/doc/user/admin_area/settings/account_and_limit_settings.md
index 5c730375f98..293decc438e 100644
--- a/doc/user/admin_area/settings/account_and_limit_settings.md
+++ b/doc/user/admin_area/settings/account_and_limit_settings.md
@@ -16,8 +16,10 @@ the [project limits for existing users](#projects-limit-for-a-user).
 
 To configure the maximum number of projects in personal namespaces for new users:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, then expand **Account and limit**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **Account and limit**.
 1. Increase or decrease that **Default projects limit** value.
 
 If you set **Default projects limit** to 0, users are not allowed to create projects
@@ -28,8 +30,9 @@ in their users personal namespace. However, projects can still be created in a g
 You can edit a specific user, and change the maximum number of projects this user
 can create in their personal namespace:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview** > **Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview** > **Users**.
 1. From the list of users, select a user.
 1. Select **Edit**.
 1. Increase or decrease the **Projects limit** value.
@@ -41,8 +44,10 @@ can create in their personal namespace:
 The maximum file size for attachments in GitLab comments and replies is 100 MB.
 To change the maximum attachment size:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, then expand **Account and limit**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **Account and limit**.
 1. Increase or decrease by changing the value in **Maximum attachment size (MB)**.
 
 If you choose a size larger than the configured value for the web server,
@@ -55,8 +60,10 @@ For GitLab.com repository size limits, read [accounts and limit settings](../../
 
 You can change the maximum push size for your instance:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, then expand **Account and limit**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **Account and limit**.
 1. Increase or decrease by changing the value in **Maximum push size (MB)**.
 
 For GitLab.com push size limits, read [accounts and limit settings](../../gitlab_com/index.md#account-and-limit-settings).
@@ -74,8 +81,9 @@ Use [Git LFS](../../../topics/git/lfs/index.md) to add large files to a reposito
 
 To modify the maximum file size for exports in GitLab:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, then expand **Account and limit**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**, then expand **Account and limit**.
 1. Increase or decrease by changing the value in **Maximum export size (MB)**.
 
 ## Max import size
@@ -84,8 +92,10 @@ To modify the maximum file size for exports in GitLab:
 
 To modify the maximum file size for imports in GitLab:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, then expand **Account and limit**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **Account and limit**.
 1. Increase or decrease by changing the value in **Maximum import size (MB)**.
 
 This setting applies only to repositories
@@ -114,8 +124,9 @@ The default prefix is `glpat-` but administrators can change it.
 
 To change the default global prefix:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Account and limit** section.
 1. Fill in the **Personal Access Token prefix** field.
 1. Select **Save changes**.
@@ -160,8 +171,9 @@ These settings can be found in:
   1. Fill in the **Repository size limit (MB)** field in the **Naming, visibility** section.
   1. Select **Save changes**.
 - GitLab global settings:
-  1. On the top bar, select **Main menu > Admin**.
-  1. On the left sidebar, select **Settings > General**.
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
+  1. Select **Settings > General**.
   1. Expand the **Account and limit** section.
   1. Fill in the **Size limit per repository (MB)** field.
   1. Select **Save changes**.
@@ -182,8 +194,9 @@ For details on manually purging files, see [reducing the repository size using G
 
 You can change how long users can remain signed in without activity.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **Account and limit**. The set duration is in **Session duration (minutes)**.
 
 If [Remember me](#turn-remember-me-on-or-off) is enabled, users' sessions can remain active for an indefinite period of time.
@@ -196,8 +209,9 @@ For details, see [cookies used for sign-in](../../profile/index.md#cookies-used-
 
 Users can select the **Remember me** checkbox on sign-in, and their session will remain active for an indefinite period of time when accessed from that specific browser. You can turn off this setting if you need sessions to expire for security or compliance purposes. Turning off this setting will ensure users' sessions expire after the number of minutes of inactivity set when you [customize your session duration](#customize-the-default-session-duration).
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **Account and limit**.
 1. Select or clear the **Remember me** checkbox to turn this setting on or off.
 
@@ -213,8 +227,9 @@ GitLab administrators can choose to customize the session duration (in minutes)
 
 To set a limit on how long these sessions are valid:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Account and limit** section.
 1. Fill in the **Session duration for Git operations when 2FA is enabled (minutes)** field.
 1. Select **Save changes**.
@@ -240,8 +255,9 @@ there are no restrictions.
 
 To set a lifetime on how long SSH keys are valid:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Account and limit** section.
 1. Fill in the **Maximum allowable lifetime for SSH keys (days)** field.
 1. Select **Save changes**.
@@ -276,8 +292,9 @@ there are no restrictions.
 
 To set a lifetime on how long access tokens are valid:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Account and limit** section.
 1. Fill in the **Maximum allowable lifetime for access tokens (days)** field.
 1. Select **Save changes**.
@@ -298,8 +315,10 @@ To maintain integrity of user details in [Audit Events](../../../administration/
 
 To do this:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, then expand **Account and limit**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **Account and limit**.
 1. Select the **Prevent users from changing their profile name** checkbox.
 
 NOTE:
@@ -318,8 +337,10 @@ By default, new users can create top-level groups. GitLab administrators can pre
   - The [application setting API](../../../api/settings.md#change-application-settings).
 - In GitLab 15.4 and earlier, a [configuration file](../../../administration/user_settings.md#use-configuration-files-to-prevent-new-users-from-creating-top-level-groups).
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, then expand **Account and limit**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **Account and limit**.
 1. Clear the **Allow new users to create top-level groups** checkbox.
 
 ## Set profiles of new users to private by default
@@ -328,19 +349,23 @@ By default, new users can create top-level groups. GitLab administrators can pre
 
 By default, newly created users have a public profile. GitLab administrators can set new users to have a private profile by default:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, then expand **Account and limit**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **Account and limit**.
 1. Select the **Make new users' profiles private by default** checkbox.
 
 ## Prevent users from deleting their accounts **(PREMIUM SELF)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26053) in GitLab 16.0 [with a flag](../../../administration/feature_flags.md) named `deleting_account_disabled_for_users`. Disabled by default.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26053) in GitLab 16.1 [with a flag](../../../administration/feature_flags.md) named `deleting_account_disabled_for_users`. Enabled by default.
 
 By default, users can delete their own accounts. GitLab administrators can prevent
 users from deleting their own accounts:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, then expand **Account and limit**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **Account and limit**.
 1. Clear the **Allows users to delete their own accounts** checkbox.
 
 ## Troubleshooting
@@ -352,7 +377,7 @@ error, the [max attachment size](#max-attachment-size)
 is probably larger than the web server's allowed value.
 
 To increase the max attachment size to 200 MB in a
-[Omnibus GitLab](https://docs.gitlab.com/omnibus/) install, you may need to
+[Linux package](https://docs.gitlab.com/omnibus/) install, you may need to
 add the line below to `/etc/gitlab/gitlab.rb` before increasing the max attachment size:
 
 ```ruby
diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md
index 27af64cd0e8..853a299cdec 100644
--- a/doc/user/admin_area/settings/continuous_integration.md
+++ b/doc/user/admin_area/settings/continuous_integration.md
@@ -15,8 +15,9 @@ job artifacts.
 To enable (or disable) [Auto DevOps](../../../topics/autodevops/index.md)
 for all projects:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Check (or uncheck to disable) the box that says **Default to Auto DevOps pipeline for all projects**.
 1. Optionally, set up the [Auto DevOps base domain](../../../topics/autodevops/requirements.md#auto-devops-base-domain)
    which is used for Auto Deploy and Auto Review Apps.
@@ -32,17 +33,18 @@ If you want to disable it for a specific project, you can do so in
 
 You can set all new projects to have the instance's shared runners available by default.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand **Continuous Integration and Deployment**.
 1. Select the **Enable shared runners for new projects** checkbox.
 
 Any time a new project is created, the shared runners are available.
 
-## Shared runners CI/CD minutes
+## Shared runners compute quota
 
 As an administrator you can set either a global or namespace-specific
-limit on the number of [CI/CD minutes](../../../ci/pipelines/cicd_minutes.md) you can use.
+limit on the number of [units of compute](../../../ci/pipelines/cicd_minutes.md) you can use.
 
 ## Enable a project runner for multiple projects
 
@@ -51,7 +53,8 @@ you can assign that runner to other projects.
 
 To enable a project runner for more than one project:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. From the left sidebar, select **CI/CD > Runners**.
 1. Select the runner you want to edit.
 1. In the upper-right corner, select **Edit** (**{pencil}**).
@@ -64,8 +67,9 @@ To enable a project runner for more than one project:
 To display details about the instance's shared runners in all projects'
 runner settings:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand **Continuous Integration and Deployment**.
 1. Enter text, including Markdown if you want, in the **Shared runner details** field. For example:
 
@@ -73,10 +77,8 @@ runner settings:
 
 To view the rendered details:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 
 ![Shared runner details example](img/continuous_integration_shared_runner_details_v14_10.png)
@@ -95,7 +97,8 @@ The value is in MB and the default is 100 MB per job. To change it at the:
 
 - Instance level:
 
-  1. On the top bar, select **Main menu > Admin**.
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
   1. On the left sidebar, select **Settings > CI/CD > Continuous Integration and Deployment**.
   1. Change the value of **Maximum artifacts size (MB)**.
   1. Select **Save changes** for the changes to take effect.
@@ -122,8 +125,9 @@ can be set in the Admin Area of your GitLab instance. The syntax of duration is
 described in [`artifacts:expire_in`](../../../ci/yaml/index.md#artifactsexpire_in)
 and the default value is `30 days`.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Change the value of default expiration time.
 1. Select **Save changes** for the changes to take effect.
 
@@ -153,8 +157,9 @@ If disabled at the instance level, you cannot enable this per-project.
 
 To disable the setting:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand **Continuous Integration and Deployment**.
 1. Clear the **Keep the latest artifacts for all jobs in the latest successful pipelines** checkbox.
 1. Select **Save changes**
@@ -173,8 +178,9 @@ but persisting the traces and artifacts for auditing purposes.
 
 To set the duration for which the jobs are considered as old and expired:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand the **Continuous Integration and Deployment** section.
 1. Set the value of **Archive jobs**.
 1. Select **Save changes** for the changes to take effect.
@@ -190,17 +196,21 @@ For the value set for GitLab.com, see [Scheduled job archiving](../../gitlab_com
 To set all new [CI/CD variables](../../../ci/variables/index.md) as
 [protected](../../../ci/variables/index.md#protect-a-cicd-variable) by default:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Select **Protect CI/CD variables by default**.
 
 ## Maximum includes
 
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207270) in GitLab 16.0.
+
 The maximum number of [includes](../../../ci/yaml/includes.md) per pipeline can be set at the instance level.
 The default is `150`.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Change the value of **Maximum includes**.
 1. Select **Save changes** for the changes to take effect.
 
@@ -211,8 +221,9 @@ The default is `150`.
 The default CI/CD configuration file and path for new projects can be set in the Admin Area
 of your GitLab instance (`.gitlab-ci.yml` if not set):
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Input the new file and path in the **Default CI/CD configuration file** field.
 1. Select **Save changes** for the changes to take effect.
 
@@ -225,8 +236,9 @@ It is also possible to specify a [custom CI/CD configuration file for a specific
 You can configure some [CI/CD limits](../../../administration/instance_limits.md#cicd-limits)
 from the Admin Area:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand the **Continuous Integration and Deployment** section.
 1. In the **CI/CD limits** section, you can set the following limits:
    - **Maximum number of jobs in a single pipeline**
@@ -248,8 +260,9 @@ walkthrough on how to add one.
 
 To enable or disable the banner:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Select or clear the **Enable pipeline suggestion banner** checkbox.
 1. Select **Save changes**.
 
@@ -284,8 +297,9 @@ in the pipeline editor.
 
 To select a CI/CD template for the required pipeline configuration:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand the **Required pipeline configuration** section.
 1. Select a CI/CD template from the dropdown list.
 1. Select **Save changes**.
@@ -298,8 +312,9 @@ GitLab administrators can disable the forwarding of Maven requests to [Maven Cen
 
 To disable forwarding Maven requests:
 
-1. On the top bar, select **Menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand the **Package Registry** section.
 1. Clear the checkbox **Forward Maven package requests to the Maven Registry if the packages are not found in the GitLab Package Registry**.
 1. Select **Save changes**.
@@ -310,8 +325,9 @@ GitLab administrators can disable the forwarding of npm requests to [npmjs.com](
 
 To disable it:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand the **Package Registry** section.
 1. Clear the checkbox **Forward npm package requests to the npm Registry if the packages are not found in the GitLab Package Registry**.
 1. Select **Save changes**.
@@ -322,8 +338,9 @@ GitLab administrators can disable the forwarding of PyPI requests to [pypi.org](
 
 To disable it:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand the **Package Registry** section.
 1. Clear the checkbox **Forward PyPI package requests to the PyPI Registry if the packages are not found in the GitLab Package Registry**.
 1. Select **Save changes**.
@@ -334,8 +351,9 @@ GitLab administrators can adjust the maximum allowed file size for each package
 
 To set the maximum file size:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand the **Package Registry** section.
 1. Find the package type you would like to adjust.
 1. Enter the maximum file size, in bytes.
@@ -354,8 +372,9 @@ By default, all members of a project and group are able to register runners.
 
 To restrict all users in an instance from registering runners:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 1. In the **Runner registration** section, clear the **Members of the project can register runners** and
    **Members of the group can register runners** checkboxes to remove runner registration from the UI.
@@ -376,8 +395,9 @@ GitLab administrators can adjust group permissions to restrict runner registrati
 
 To restrict runner registration by members in a specific group:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Groups** and find your group.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Groups** and find your group.
 1. Select **Edit**.
 1. Clear the **New group runners can be registered** checkbox if you want to disable runner registration by all members in the group. If the setting is read-only, you must enable runner registration for the [instance](#restrict-runner-registration-by-all-users-in-an-instance).
 1. Select **Save changes**.
@@ -390,8 +410,9 @@ By default, GitLab instances periodically fetch official runner version data fro
 
 To disable your instance fetching this data:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > CI/CD**.
 1. Expand **Runners**.
 1. In the **Runner version management** section, clear the **Fetch GitLab Runner release version data from GitLab.com** checkbox.
 1. Select **Save changes**.
diff --git a/doc/user/admin_area/settings/deprecated_api_rate_limits.md b/doc/user/admin_area/settings/deprecated_api_rate_limits.md
index 13f8bc008e3..e813d8fe2b1 100644
--- a/doc/user/admin_area/settings/deprecated_api_rate_limits.md
+++ b/doc/user/admin_area/settings/deprecated_api_rate_limits.md
@@ -34,8 +34,9 @@ Prerequisite:
 
 To override the general user and IP rate limits for requests to deprecated API endpoints:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
 1. Expand **Deprecated API Rate Limits**.
 1. Select the checkboxes for the types of rate limits you want to enable:
    - **Unauthenticated API request rate limit**
diff --git a/doc/user/admin_area/settings/email.md b/doc/user/admin_area/settings/email.md
index 90852463e9d..1caa1728ea4 100644
--- a/doc/user/admin_area/settings/email.md
+++ b/doc/user/admin_area/settings/email.md
@@ -11,7 +11,7 @@ You can customize some of the content in emails sent from your GitLab instance.
 
 ## Custom logo
 
-The logo in the header of some emails can be customized, see the [logo customization section](../appearance.md#top-bar).
+The logo in the header of some emails can be customized, see the [logo customization section](../appearance.md#navigation-bar).
 
 ## Include author name in email notification email body **(PREMIUM SELF)**
 
@@ -21,8 +21,9 @@ address in the body of the email instead.
 
 To include the author's email address in the email body:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences** (`/admin/application_settings/preferences`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Email**.
 1. Select the **Include author name in email notification email body** checkbox.
 1. Select **Save changes**.
@@ -33,8 +34,9 @@ GitLab can send email in multipart format (HTML and plain text) or plain text on
 
 To enable multipart email:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences** (`/admin/application_settings/preferences`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Email**.
 1. Select **Enable multipart email**.
 1. Select **Save changes**.
@@ -48,8 +50,9 @@ This configuration option sets the email hostname for [private commit emails](..
 
 To change the hostname used in private commit emails:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences** (`/admin/application_settings/preferences`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Email**.
 1. Enter the desired hostname in the **Custom hostname (for private commit emails)** field.
 1. Select **Save changes**.
@@ -66,8 +69,9 @@ can be used for legal, auditing, or compliance reasons, for example.
 
 To add additional text to emails:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences** (`/admin/application_settings/preferences`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Email**.
 1. Enter your text in the **Additional text** field.
 1. Select **Save changes**.
@@ -78,8 +82,9 @@ GitLab sends email notifications to users when their account has been deactivate
 
 To disable these notifications:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences** (`/admin/application_settings/preferences`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Email**.
 1. Clear the **Enable user deactivation emails** checkbox.
 1. Select **Save changes**.
@@ -100,8 +105,9 @@ setting.
 
 To add additional text to deactivation emails:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences** (`/admin/application_settings/preferences`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Email**.
 1. Enter your text in the **Additional text for deactivation email** field.
 1. Select **Save changes**.
diff --git a/doc/user/admin_area/settings/external_authorization.md b/doc/user/admin_area/settings/external_authorization.md
index 072873ba7f6..c15062dd518 100644
--- a/doc/user/admin_area/settings/external_authorization.md
+++ b/doc/user/admin_area/settings/external_authorization.md
@@ -32,12 +32,12 @@ authorization service.
 
 Whenever access is granted or denied this is logged in a log file called
 `external-policy-access-control.log`. Read more about the logs GitLab keeps in
-the [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/logs.html).
+the [Linux package documentation](https://docs.gitlab.com/omnibus/settings/logs.html).
 
 When using TLS Authentication with a self signed certificate, the CA certificate
 needs to be trusted by the OpenSSL installation. When using GitLab installed
-using Omnibus, learn to install a custom CA in the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
+using the Linux package, learn to install a custom CA in the
+[Linux package documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
 Alternatively, learn where to install custom certificates by using
 `openssl version -d`.
 
@@ -45,8 +45,9 @@ Alternatively, learn where to install custom certificates by using
 
 The external authorization service can be enabled by an administrator:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **External authorization**.
 1. Complete the fields.
 1. Select **Save changes**.
@@ -65,8 +66,9 @@ Prerequisites:
 
 To allow authorization with deploy tokens and keys:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **External authorization**, and:
    - Leave the service URL field empty.
    - Select **Allow deploy tokens and deploy keys to be used with external authorization**.
diff --git a/doc/user/admin_area/settings/files_api_rate_limits.md b/doc/user/admin_area/settings/files_api_rate_limits.md
index 8677e3d86bf..9f7a2d13b8e 100644
--- a/doc/user/admin_area/settings/files_api_rate_limits.md
+++ b/doc/user/admin_area/settings/files_api_rate_limits.md
@@ -30,8 +30,9 @@ Prerequisite:
 
 To override the general user and IP rate limits for requests to the Repository files API:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
 1. Expand **Files API Rate Limits**.
 1. Select the checkboxes for the types of rate limits you want to enable:
    - **Unauthenticated API request rate limit**
diff --git a/doc/user/admin_area/settings/floc.md b/doc/user/admin_area/settings/floc.md
index 451acc07240..6bd5a6dfed4 100644
--- a/doc/user/admin_area/settings/floc.md
+++ b/doc/user/admin_area/settings/floc.md
@@ -22,8 +22,9 @@ Permissions-Policy: interest-cohort=()
 
 To enable it:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **Federated Learning of Cohorts (FLoC)**.
 1. Select the **Participate in FLoC** checkbox.
 1. Select **Save changes**.
diff --git a/doc/user/admin_area/settings/git_lfs_rate_limits.md b/doc/user/admin_area/settings/git_lfs_rate_limits.md
index e0476f1e333..c9b294417ee 100644
--- a/doc/user/admin_area/settings/git_lfs_rate_limits.md
+++ b/doc/user/admin_area/settings/git_lfs_rate_limits.md
@@ -21,8 +21,9 @@ rate limits.
 Git LFS rate limits are disabled by default. If enabled and configured, these limits
 supersede the [general user and IP rate limits](user_and_ip_rate_limits.md):
 
-1. On the top bar, select **Main menu >** **{admin}** **Admin**.
-1. On the left sidebar, select **Settings > Network**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
 1. Expand **Git LFS Rate Limits**.
 1. Select **Enable authenticated Git LFS request rate limit**.
 1. Enter a value for **Max authenticated Git LFS requests per period per user**.
diff --git a/doc/user/admin_area/settings/gitaly_timeouts.md b/doc/user/admin_area/settings/gitaly_timeouts.md
index d18fe0d74cd..d28e9ec0249 100644
--- a/doc/user/admin_area/settings/gitaly_timeouts.md
+++ b/doc/user/admin_area/settings/gitaly_timeouts.md
@@ -11,8 +11,9 @@ configured to make sure that long-running Gitaly calls don't needlessly take up
 
 To access Gitaly timeout settings:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand the **Gitaly timeouts** section.
 
 ## Available timeouts
diff --git a/doc/user/admin_area/settings/help_page.md b/doc/user/admin_area/settings/help_page.md
index 5d9fc23aaff..febd794b04c 100644
--- a/doc/user/admin_area/settings/help_page.md
+++ b/doc/user/admin_area/settings/help_page.md
@@ -16,8 +16,9 @@ the GitLab sign-in page.
 You can add a help message, which is shown at the top of the GitLab `/help` page (for example,
 <https://gitlab.com/help>):
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Sign-in and Help page**.
 1. In **Additional text to show on the Help page**, enter the information you want to display on `/help`.
 1. Select **Save changes**.
@@ -33,8 +34,9 @@ is restricted, `/help` is visible only to authenticated users.
 
 You can add a help message, which is shown on the GitLab sign-in page. The message appears on the sign-in page:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Sign-in and Help page**.
 1. In **Additional text to show on the sign-in page**, enter the information you want to
    display on the sign-in page.
@@ -46,8 +48,9 @@ You can now see the message on the sign-in page.
 
 GitLab marketing-related entries are occasionally shown on the Help page. To hide these entries:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Sign-in and Help page**.
 1. Select the **Hide marketing-related entries from the Help page** checkbox.
 1. Select **Save changes**.
@@ -59,8 +62,9 @@ You can specify a custom URL to which users are directed when they:
 - Select **Support** from the Help dropdown list.
 - Select **See our website for help** on the Help page.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Sign-in and Help page**.
 1. In the **Support page URL** field, enter the URL.
 1. Select **Save changes**.
@@ -73,8 +77,9 @@ You can specify a custom URL to which users are directed when they:
 
 You can redirect all `/help` links to a destination that meets the [necessary requirements](#destination-requirements).
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Sign-in and Help page**.
 1. In the **Documentation pages URL** field, enter the URL.
 1. Select **Save changes**.
diff --git a/doc/user/admin_area/settings/import_export_rate_limits.md b/doc/user/admin_area/settings/import_export_rate_limits.md
index 36a8b340957..99385c77cdf 100644
--- a/doc/user/admin_area/settings/import_export_rate_limits.md
+++ b/doc/user/admin_area/settings/import_export_rate_limits.md
@@ -12,8 +12,10 @@ You can configure the rate limits for imports and exports of projects and groups
 
 To change a rate limit:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**, then expand **Import and export rate limits**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **Import and export rate limits**.
 1. Change the value of any rate limit. The rate limits are per minute per user, not per IP address.
    Set to `0` to disable a rate limit.
 
diff --git a/doc/user/admin_area/settings/incident_management_rate_limits.md b/doc/user/admin_area/settings/incident_management_rate_limits.md
index 295569dafee..0b6e572837e 100644
--- a/doc/user/admin_area/settings/incident_management_rate_limits.md
+++ b/doc/user/admin_area/settings/incident_management_rate_limits.md
@@ -30,8 +30,9 @@ Requests that exceed the limit are logged into `auth.log`.
 
 To set inbound incident management alert limits:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
 1. Expand **Incident Management Limits**.
 1. Select the **Enable Incident Management inbound alert limit** checkbox.
 1. Optional. Input a custom value for **Maximum requests per project per rate limit period**. Default is 3600.
diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md
index 2091191b889..632adf273c4 100644
--- a/doc/user/admin_area/settings/index.md
+++ b/doc/user/admin_area/settings/index.md
@@ -19,8 +19,9 @@ read [GitLab.com settings](../../gitlab_com/index.md).
 To access the **Admin Area**:
 
 1. Sign in to your GitLab instance as an administrator.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings**, and the group of settings to view:
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings**, and the group of settings to view:
    - [General](#general)
    - [Geo](#geo)
    - [CI/CD](#cicd)
@@ -96,7 +97,7 @@ The **Integrations** settings contain:
   [available for self-managed instances in the future](https://gitlab.com/gitlab-org/gitlab/-/issues/28164).
 - [Customer experience improvement and third-party offers](third_party_offers.md) -
   Control the display of customer experience improvement content and third-party offers.
-- [Snowplow](../../../development/snowplow/index.md) - Configure the Snowplow integration.
+- [Snowplow](../../../development/internal_analytics/snowplow/index.md) - Configure the Snowplow integration.
 - [Google GKE](../../project/clusters/add_gke_clusters.md) - Google GKE integration enables
   you to provision GKE clusters from GitLab.
 - [Amazon EKS](../../project/clusters/add_eks_clusters.md) - Amazon EKS integration enables
@@ -108,7 +109,7 @@ The **Metrics and profiling** settings contain:
 
 - [Metrics - Prometheus](../../../administration/monitoring/prometheus/gitlab_metrics.md) -
   Enable and configure Prometheus metrics.
-- [Metrics - Grafana](../../../administration/monitoring/performance/grafana_configuration.md#integration-with-gitlab-ui) -
+- [Metrics - Grafana](../../../administration/monitoring/performance/grafana_configuration.md#integrate-with-gitlab-ui) -
   Enable and configure Grafana.
 - [Profiling - Performance bar](../../../administration/monitoring/performance/performance_bar.md#enable-the-performance-bar-for-non-administrators) -
   Enable access to the Performance Bar for non-administrator users in a given group.
@@ -161,8 +162,10 @@ The **Preferences** settings contain:
 
 The **Reporting** settings contain:
 
-- [Spam and Anti-bot Protection](../../../integration/recaptcha.md) -
-  Enable anti-spam services, like reCAPTCHA, Akismet, or [Spamcheck](../reporting/spamcheck.md), and set IP limits.
+- Spam and Anti-bot protection:
+  - Anti-spam services, such as [reCAPTCHA](../../../integration/recaptcha.md),
+    [Akismet](../../../integration/akismet.md), or [Spamcheck](../reporting/spamcheck.md).
+  - [IP address restrictions](../reporting/ip_addr_restrictions.md).
 - [Abuse reports](../review_abuse_reports.md) - Set notification email for abuse reports.
 - [Git abuse rate limit](../reporting/git_abuse_rate_limit.md) - Configure Git abuse rate limit settings. **(ULTIMATE SELF)**
 
@@ -199,8 +202,9 @@ The **Templates** settings contain:
 You can change the [Default first day of the week](../../profile/preferences.md)
 for the entire GitLab instance:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Scroll to the **Localization** section, and select your desired first day of the week.
 
 ## Default language
@@ -208,6 +212,7 @@ for the entire GitLab instance:
 You can change the [Default language](../../profile/preferences.md)
 for the entire GitLab instance:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Scroll to the **Localization** section, and select your desired default language.
diff --git a/doc/user/admin_area/settings/instance_template_repository.md b/doc/user/admin_area/settings/instance_template_repository.md
index 026782ae83b..a5148c41b74 100644
--- a/doc/user/admin_area/settings/instance_template_repository.md
+++ b/doc/user/admin_area/settings/instance_template_repository.md
@@ -20,8 +20,9 @@ while the project remains secure.
 
 To select a project to serve as the custom template repository:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Templates**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Templates**.
 1. Expand **Templates**
 1. From the dropdown list, select the project to use as the template repository.
 1. Select **Save changes**.
@@ -43,7 +44,6 @@ are supported:
 | `.gitignore`            | `gitignore`          | `.gitignore`  |
 | `.gitlab-ci.yml`        | `gitlab-ci`          | `.yml`        |
 | `LICENSE`               | `LICENSE`            | `.txt`        |
-| `metrics-dashboard.yml` | `metrics-dashboards` | `.yml`        |
 
 Each template must go in its respective subdirectory, have the correct
 extension and not be empty. So, the hierarchy should look like this:
@@ -62,9 +62,6 @@ extension and not be empty. So, the hierarchy should look like this:
 |-- LICENSE
     |-- custom_license.txt
     |-- another_license.txt
-|-- metrics-dashboards
-    |-- custom_metrics-dashboard.yml
-    |-- another_metrics-dashboard.yml
 ```
 
 Your custom templates are displayed on the dropdown list when a new file is added through the GitLab UI:
diff --git a/doc/user/admin_area/settings/package_registry_rate_limits.md b/doc/user/admin_area/settings/package_registry_rate_limits.md
index a5c5536f22d..a1bc339ddd9 100644
--- a/doc/user/admin_area/settings/package_registry_rate_limits.md
+++ b/doc/user/admin_area/settings/package_registry_rate_limits.md
@@ -30,8 +30,10 @@ no difference in functionality compared to the general user and IP rate limits.
 
 To enable the unauthenticated request rate limit:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**, and expand **Package registry rate limits**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **Package registry rate limits**.
 1. Select **Enable unauthenticated request rate limit**.
 
    - Optional. Update the **Maximum unauthenticated requests per rate limit period per IP** value.
@@ -43,8 +45,10 @@ To enable the unauthenticated request rate limit:
 
 To enable the authenticated API request rate limit:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**, and expand **Package registry rate limits**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**
+1. Expand **Package registry rate limits**.
 1. Select **Enable authenticated API request rate limit**.
 
    - Optional. Update the **Maximum authenticated API requests per rate limit period per user** value.
diff --git a/doc/user/admin_area/settings/project_integration_management.md b/doc/user/admin_area/settings/project_integration_management.md
index dd4349fca2e..1bb4465020c 100644
--- a/doc/user/admin_area/settings/project_integration_management.md
+++ b/doc/user/admin_area/settings/project_integration_management.md
@@ -22,8 +22,9 @@ Only the complete settings for an integration can be inherited. Per-field inheri
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2137) in GitLab 13.3 for project-level integrations.
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2543) in GitLab 13.6 for group-level integrations.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Integrations**.
 1. Select an integration.
 1. Enter configuration details and select **Save changes**.
 
@@ -54,8 +55,9 @@ integration on all non-configured groups and projects by default.
 
 ### Remove an instance-level default setting
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Integrations**.
 1. Select an integration.
 1. Select **Reset** and confirm.
 
@@ -68,8 +70,9 @@ Resetting an instance-level default setting removes the integration from all pro
 You can view which projects in your instance use custom settings that [override the instance-level default settings](#use-custom-settings-for-a-group-or-project-integration)
 for an integration.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Integrations**.
 1. Select an integration.
 1. Select the **Projects using custom settings** tab.
 
diff --git a/doc/user/admin_area/settings/push_event_activities_limit.md b/doc/user/admin_area/settings/push_event_activities_limit.md
index 0c3f299e9ec..56a2902f2d9 100644
--- a/doc/user/admin_area/settings/push_event_activities_limit.md
+++ b/doc/user/admin_area/settings/push_event_activities_limit.md
@@ -26,11 +26,13 @@ the activity feed.
 To modify this setting:
 
 - In the Admin Area:
-  1. On the top bar, select **Main menu > Admin**.
-  1. On the left sidebar, select **Settings > Network**, then expand **Performance optimization**.
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
+  1. Select **Settings > Network**.
+  1. Expand **Performance optimization**.
 - Through the [Application settings API](../../../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls)
   as `push_event_activities_limit`.
 
-The default value is 3, but it can be greater than or equal 0.
+The default value is `3`, but the value can be greater than or equal to `0`. Setting this value to `0` does not disable throttling.
 
 ![Push event activities limit](img/push_event_activities_limit_v12_4.png)
diff --git a/doc/user/admin_area/settings/rate_limit_on_issues_creation.md b/doc/user/admin_area/settings/rate_limit_on_issues_creation.md
index 547e543ab88..09a1e023c2b 100644
--- a/doc/user/admin_area/settings/rate_limit_on_issues_creation.md
+++ b/doc/user/admin_area/settings/rate_limit_on_issues_creation.md
@@ -12,8 +12,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 This setting allows you to rate limit the requests to the issue and epic creation endpoints.
 To can change its value:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
 1. Expand **Issues Rate Limits**.
 1. Under **Max requests per minute**, enter the new value.
 1. Select **Save changes**.
diff --git a/doc/user/admin_area/settings/rate_limit_on_notes_creation.md b/doc/user/admin_area/settings/rate_limit_on_notes_creation.md
index 8465dccdbf3..59548836e78 100644
--- a/doc/user/admin_area/settings/rate_limit_on_notes_creation.md
+++ b/doc/user/admin_area/settings/rate_limit_on_notes_creation.md
@@ -13,8 +13,9 @@ You can configure the per-user rate limit for requests to the note creation endp
 
 To change the note creation rate limit:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
 1. Expand **Notes rate limit**.
 1. In the **Maximum requests per minute** box, enter the new value.
 1. Optional. In the **Users to exclude from the rate limit** box, list users allowed to exceed the limit.
diff --git a/doc/user/admin_area/settings/rate_limit_on_pipelines_creation.md b/doc/user/admin_area/settings/rate_limit_on_pipelines_creation.md
index 152ef535ff8..2d0c4405211 100644
--- a/doc/user/admin_area/settings/rate_limit_on_pipelines_creation.md
+++ b/doc/user/admin_area/settings/rate_limit_on_pipelines_creation.md
@@ -26,8 +26,9 @@ Requests that exceed the limit are logged in the `application_json.log` file.
 
 To limit the number of pipeline requests:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
 1. Expand **Pipelines Rate Limits**.
 1. Under **Max requests per minute**, enter a value greater than `0`.
 1. Select **Save changes**.
diff --git a/doc/user/admin_area/settings/rate_limit_on_projects_api.md b/doc/user/admin_area/settings/rate_limit_on_projects_api.md
index 29e72daf579..326dd3b4706 100644
--- a/doc/user/admin_area/settings/rate_limit_on_projects_api.md
+++ b/doc/user/admin_area/settings/rate_limit_on_projects_api.md
@@ -16,8 +16,9 @@ You can configure the rate limit per IP address for unauthenticated requests to
 
 To change the rate limit:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
 1. Expand **Projects API rate limit**.
 1. In the **Maximum requests per 10 minutes per IP address** text box, enter the new value.
 1. Select **Save changes**.
diff --git a/doc/user/admin_area/settings/rate_limit_on_users_api.md b/doc/user/admin_area/settings/rate_limit_on_users_api.md
index f61c381a4fb..112518131bf 100644
--- a/doc/user/admin_area/settings/rate_limit_on_users_api.md
+++ b/doc/user/admin_area/settings/rate_limit_on_users_api.md
@@ -13,8 +13,9 @@ You can configure the per user rate limit for requests to [Users API](../../../a
 
 To change the rate limit:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
 1. Expand **Users API rate limit**.
 1. In the **Maximum requests per 10 minutes** text box, enter the new value.
 1. Optional. In the **Users to exclude from the rate limit** box, list users allowed to exceed the limit.
diff --git a/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md b/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md
index 7e262c45f48..78e65f7ba7b 100644
--- a/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md
+++ b/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md
@@ -11,8 +11,9 @@ type: reference
 
 This setting defaults to `300` requests per minute, and allows you to rate limit the requests to raw endpoints:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
 1. Expand **Performance optimization**.
 
 For example, requests over `300` per minute to `https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/controllers/application_controller.rb` are blocked. Access to the raw file is released after 1 minute.
diff --git a/doc/user/admin_area/settings/scim_setup.md b/doc/user/admin_area/settings/scim_setup.md
index fd6e3061140..0471dffe442 100644
--- a/doc/user/admin_area/settings/scim_setup.md
+++ b/doc/user/admin_area/settings/scim_setup.md
@@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 You can use the open standard System for Cross-domain Identity Management (SCIM) to automatically:
 
 - Create users.
-- Remove users (deactivate SCIM identity).
+- Block users.
 
 The [internal GitLab SCIM API](../../../development/internal_api/index.md#instance-scim-api) implements part of [the RFC7644 protocol](https://www.rfc-editor.org/rfc/rfc7644).
 
@@ -26,9 +26,18 @@ Prerequisites:
 
 To configure GitLab SCIM:
 
-1. On the top bar, select **Main menu > Admin area**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+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.
+
+## Remove access
+
+Removing or deactivating a user on the identity provider blocks the user on
+the GitLab instance, while the SCIM identity remains linked to the GitLab user.
+
+To update the user SCIM identity, use the
+[internal GitLab SCIM API](../../../development/internal_api/index.md#update-a-single-scim-provisioned-user-1).
diff --git a/doc/user/admin_area/settings/security_and_compliance.md b/doc/user/admin_area/settings/security_and_compliance.md
index c7f4d6a3ede..54fd04f6521 100644
--- a/doc/user/admin_area/settings/security_and_compliance.md
+++ b/doc/user/admin_area/settings/security_and_compliance.md
@@ -17,8 +17,9 @@ We are actively working on reducing this data size in [epic 10415](https://gitla
 
 To choose the packages you want to synchronize with the GitLab License Database for [License Compliance](../../compliance/license_scanning_of_cyclonedx_files/index.md):
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Security and Compliance**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Security and Compliance**.
 1. Expand **License Compliance**.
 1. Select or clear checkboxes for the package registries that you want to sync.
 1. Select **Save changes**.
diff --git a/doc/user/admin_area/settings/sidekiq_job_limits.md b/doc/user/admin_area/settings/sidekiq_job_limits.md
index a25bc0e85e4..08c3ced4c4e 100644
--- a/doc/user/admin_area/settings/sidekiq_job_limits.md
+++ b/doc/user/admin_area/settings/sidekiq_job_limits.md
@@ -17,8 +17,9 @@ Redis. To avoid excessive memory for Redis, we:
 
 To access Sidekiq job size limits:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Sidekiq job size limits**.
 1. Adjust the compression threshold or size limit. The compression can
    be disabled by selecting the **Track** mode.
diff --git a/doc/user/admin_area/settings/sign_in_restrictions.md b/doc/user/admin_area/settings/sign_in_restrictions.md
index 951e0784c88..3b79e55f998 100644
--- a/doc/user/admin_area/settings/sign_in_restrictions.md
+++ b/doc/user/admin_area/settings/sign_in_restrictions.md
@@ -12,8 +12,9 @@ You can use **Sign-in restrictions** to customize authentication restrictions fo
 
 To access sign-in restriction settings:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Sign-in restrictions** section.
 
 ## Password authentication enabled
@@ -32,13 +33,13 @@ In the event of an external authentication provider outage, use the [GitLab Rail
 
 > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2158) in GitLab 13.10.
 
-If you are an administrator, you might want to work in GitLab without the access that
-comes from being an administrator. While you could create a separate user account that
-doesn't have administrator access, a more secure solution is to use *Admin Mode*.
+If you're an administrator, you might want to work in GitLab without administrator access.
+You could either create a separate user account that does not have
+administrator access or use Admin Mode.
 
-With Admin Mode, your account does not have administrative access by default.
-You can continue to access groups and projects you are a member of, but to access
-administrative functionality, you must authenticate.
+With Admin Mode, your account does not have administrator access by default.
+You can continue to access groups and projects you're a member of. However, for administrative tasks,
+you must authenticate (except for [certain features](#limitations-of-admin-mode)).
 
 When Admin Mode is enabled, it applies to all administrators on the instance.
 
@@ -75,8 +76,9 @@ Open the [Rails console](../../../administration/operations/rails_console.md) an
 
 To enable Admin Mode through the UI:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **Sign-in restrictions**.
 1. In the **Admin Mode** section, select the **Require additional authentication for administrative tasks** checkbox.
 
@@ -84,7 +86,8 @@ To enable Admin Mode through the UI:
 
 To turn on Admin Mode for your current session and access potentially dangerous resources:
 
-1. On the top bar, select **Main menu > Enter Admin Mode**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Enter Admin Mode**.
 1. Try to access any part of the UI with `/admin` in the URL (which requires administrator access).
 
 When Admin Mode status is disabled or turned off, administrators cannot access resources unless
@@ -99,7 +102,10 @@ authentication are supported by Admin Mode. Admin Mode status is stored in the c
 
 ### Turn off Admin Mode for your session
 
-To turn off Admin Mode for your current session, on the top bar, select **Main menu > Leave Admin mode**.
+To turn off Admin Mode for your current session:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Leave Admin Mode**.
 
 ### Limitations of Admin Mode
 
@@ -173,8 +179,10 @@ For example, if you include the following information in the noted text box:
 
 To access this text box:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, and expand the **Sign-in restrictions** section.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand the **Sign-in restrictions** section.
 ```
 
 Your users see the **Custom sign-in text** when they navigate to the sign-in screen for your
diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md
index 3bf52bfe001..0dcca5e7518 100644
--- a/doc/user/admin_area/settings/sign_up_restrictions.md
+++ b/doc/user/admin_area/settings/sign_up_restrictions.md
@@ -22,8 +22,10 @@ you do not expect public users to sign up for an account.
 
 To disable sign ups:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand **Sign-up restrictions**.
 1. Clear the **Sign-up enabled** checkbox, then select **Save changes**.
 
 ## Require administrator approval for new sign ups
@@ -38,8 +40,10 @@ enabled by default for new GitLab instances. It is only applicable if sign ups a
 
 To require administrator approval for new sign ups:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand **Sign-up restrictions**.
 1. Select the **Require admin approval for new sign-ups** checkbox, then select **Save changes**.
 
 In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/273258), if an administrator disables this setting, the users in pending approval state are
@@ -50,6 +54,7 @@ This setting doesn't apply to LDAP or OmniAuth users. To enforce approvals for n
 signing up using OmniAuth or LDAP, set `block_auto_created_users` to `true` in the
 [OmniAuth configuration](../../../integration/omniauth.md#configure-common-settings) or
 [LDAP configuration](../../../administration/auth/ldap/index.md#basic-configuration-settings).
+A [user cap](#user-cap) can also be used to enforce approvals for new users.
 
 ## Confirm user email
 
@@ -61,8 +66,10 @@ their email address before they are allowed to sign in.
 
 For example, to enforce confirmation of the email address used for new sign ups:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand **Sign-up restrictions**.
 1. Under **Email confirmation settings**, select **Hard**.
 
 The following settings are available:
@@ -83,10 +90,22 @@ their account.
 If an administrator [increases](#set-the-user-cap-number) or [removes](#remove-the-user-cap) the
 user cap, the users in pending approval state are automatically approved in a background job.
 
+NOTE:
+The amount of billable users [is updated once a day](../../../subscriptions/self_managed/index.md#billable-users).
+This means the user cap might apply only retrospectively after the cap has already been exceeded.
+To ensure the cap is enabled immediately, set it to a low value below the current number of
+billable users, for example: `1`.
+
+On instances that use LDAP or OmniAuth, enabling and disabling
+[administrator approval for new sign ups](#require-administrator-approval-for-new-sign-ups)
+involves changing the Rails configuration, and may require downtime.
+User cap can be used instead. As noted above, set the cap to value that ensures it is enforced immediately.
+
 ### Set the user cap number
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **Sign-up restrictions**.
 1. Enter a number in **User cap**.
 1. Select **Save changes**.
@@ -95,8 +114,9 @@ New user sign ups are subject to the user cap restriction.
 
 ## Remove the user cap
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **Sign-up restrictions**.
 1. Remove the number from **User cap**.
 1. Select **Save changes**.
@@ -123,8 +143,9 @@ You can add additional complexity requirements. Changes to password complexity r
 
 Existing passwords are unaffected. To change password complexity requirements:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **Sign-up restrictions**.
 1. Under **Minimum password length (number of characters)**, select additional password complexity requirements. You can require numbers, uppercase letters, lowercase letters,
    and symbols.
@@ -152,8 +173,10 @@ reduce the risk of malicious users creating spam accounts with disposable email
 
 To create an email domain allowlist or denylist:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand **Sign-up restrictions**.
 1. For the allowlist, you must enter the list manually. For the denylist, you can enter the list
    manually or upload a `.txt` file that contains list entries.
 
diff --git a/doc/user/admin_area/settings/terms.md b/doc/user/admin_area/settings/terms.md
index 85927bad8ad..8563f778292 100644
--- a/doc/user/admin_area/settings/terms.md
+++ b/doc/user/admin_area/settings/terms.md
@@ -17,8 +17,9 @@ for example `https://gitlab.example.com/-/users/terms`.
 
 To enforce acceptance of a Terms of Service and Privacy Policy:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Terms of Service and Privacy Policy** section.
 1. Check the **All users must accept the Terms of Service and Privacy Policy to access GitLab** checkbox.
 1. Input the text of the **Terms of Service and Privacy Policy**. You can use [Markdown](../../markdown.md)
diff --git a/doc/user/admin_area/settings/terraform_limits.md b/doc/user/admin_area/settings/terraform_limits.md
index 05b1f2d8838..0e620bb84ce 100644
--- a/doc/user/admin_area/settings/terraform_limits.md
+++ b/doc/user/admin_area/settings/terraform_limits.md
@@ -15,8 +15,9 @@ state file version, and is checked whenever a new version is created.
 
 To add a storage limit:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Preferences**.
 1. Expand **Terraform limits**.
 1. Adjust the size limit.
 
diff --git a/doc/user/admin_area/settings/third_party_offers.md b/doc/user/admin_area/settings/third_party_offers.md
index 6037b24a294..39e2275f411 100644
--- a/doc/user/admin_area/settings/third_party_offers.md
+++ b/doc/user/admin_area/settings/third_party_offers.md
@@ -18,8 +18,10 @@ questions when creating a group.
 
 To toggle the display of customer experience improvement content and third-party offers:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings**, and expand **Customer experience improvement & third-party offers**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand **Customer experience improvement and third-party offers**.
 1. Select **Do not display content for customer experience improvement and offers from third parties**.
 1. Select **Save changes**.
 
diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md
index ba226e0f05b..ed0c8d21931 100644
--- a/doc/user/admin_area/settings/usage_statistics.md
+++ b/doc/user/admin_area/settings/usage_statistics.md
@@ -14,7 +14,7 @@ All usage statistics are [opt-out](#enable-or-disable-usage-statistics).
 ## Service Ping
 
 Service Ping is a process that collects and sends a weekly payload to GitLab Inc.
-For more information, see the [Service Ping guide](../../../development/service_ping/index.md). When Service Ping is enabled, GitLab gathers data from other instances and enables certain [instance-level analytics features](../analytics/index.md)
+For more information, see the [Service Ping guide](../../../development/internal_analytics/service_ping/index.md). When Service Ping is enabled, GitLab gathers data from other instances and enables certain [instance-level analytics features](../analytics/index.md)
 that are dependent on Service Ping.
 
 ### Why enable Service Ping?
@@ -64,8 +64,9 @@ Registration is not yet required for participation, but may be added in a future
 ### Enable registration features
 
 1. Sign in as a user with administrator access.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Metrics and profiling**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Metrics and profiling**.
 1. Expand the **Usage statistics** section.
 1. If not enabled, select the **Enable Service Ping** checkbox.
 1. Select the **Enable Registration Features** checkbox.
@@ -112,7 +113,7 @@ sequenceDiagram
 ## Configure your network
 
 To send usage statistics to GitLab Inc., you must allow network traffic from your
-GitLab instance to the IP address `104.196.17.203:443`.
+GitLab instance to the host `version.gitlab.com` on port `443`.
 
 If your GitLab instance is behind a proxy, set the appropriate
 [proxy configuration variables](https://docs.gitlab.com/omnibus/settings/environment-variables.html).
@@ -121,8 +122,9 @@ If your GitLab instance is behind a proxy, set the appropriate
 
 To enable or disable Service Ping and version check:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Metrics and profiling**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Metrics and profiling**.
 1. Expand **Usage statistics**.
 1. Select or clear the **Enable version check** and **Enable Service Ping** checkboxes.
 1. Select **Save changes**.
@@ -136,7 +138,7 @@ The payload is available in the [Service Usage data](#manually-upload-service-pi
 
 NOTE:
 The method to disable Service Ping in the GitLab configuration file does not work in
-GitLab versions 9.3 to 13.12.3. For more information about how to disable it, see [troubleshooting](../../../development/service_ping/troubleshooting.md#cannot-disable-service-ping-with-the-configuration-file).
+GitLab versions 9.3 to 13.12.3. For more information about how to disable it, see [troubleshooting](../../../development/internal_analytics/service_ping/troubleshooting.md#cannot-disable-service-ping-with-the-configuration-file).
 
 To disable Service Ping and prevent it from being configured in the future through
 the Admin Area:
@@ -178,12 +180,13 @@ the Admin Area:
 You can view the exact JSON payload sent to GitLab Inc. in the Admin Area. To view the payload:
 
 1. Sign in as a user with administrator access.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Metrics and profiling**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Metrics and profiling**.
 1. Expand the **Usage statistics** section.
 1. Select **Preview payload**.
 
-For an example payload, see [Example Service Ping payload](../../../development/service_ping/index.md#example-service-ping-payload).
+For an example payload, see [Example Service Ping payload](../../../development/internal_analytics/service_ping/index.md#example-service-ping-payload).
 
 ## Manually upload Service Ping payload
 
@@ -191,13 +194,14 @@ For an example payload, see [Example Service Ping payload](../../../development/
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83265) in GitLab 14.10.
 
 You can upload the Service Ping payload to GitLab even if your instance doesn't have internet access,
-or if the Service Ping [cron job](../../../development/service_ping/index.md#how-service-ping-works) is not enabled.
+or if the Service Ping [cron job](../../../development/internal_analytics/service_ping/index.md#how-service-ping-works) is not enabled.
 
 To upload the payload manually:
 
 1. Sign in as a user with administrator access.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Service** usage data.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Service** usage data.
 1. Select **Download payload**.
 1. Save the JSON file.
 1. Visit [Service usage data center](https://version.gitlab.com/usage_data/new).
@@ -211,7 +215,8 @@ If there are problems with the manual upload:
 
 1. Open a confidential issue in the [security fork of version app project](https://gitlab.com/gitlab-org/security/version.gitlab.com).
 1. Attach the JSON payload if possible.
-1. Tag `@gitlab-org/analytics-section/product-intelligence` who will triage the issue.
+1. Tag `@gitlab-org/analytics-section/analytics-instrumentation` who will triage the issue.
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/admin_area/settings/user_and_ip_rate_limits.md b/doc/user/admin_area/settings/user_and_ip_rate_limits.md
index 9b8718fc336..d145c351f3e 100644
--- a/doc/user/admin_area/settings/user_and_ip_rate_limits.md
+++ b/doc/user/admin_area/settings/user_and_ip_rate_limits.md
@@ -31,8 +31,10 @@ counted as web traffic.
 
 To enable the unauthenticated request rate limit:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**, and expand **User and IP rate limits**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **User and IP rate limits**.
 1. Select **Enable unauthenticated API request rate limit**.
 
    - Optional. Update the **Maximum unauthenticated API requests per rate limit period per IP** value.
@@ -44,8 +46,10 @@ To enable the unauthenticated request rate limit:
 
 To enable the unauthenticated request rate limit:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**, and expand **User and IP rate limits**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **User and IP rate limits**.
 1. Select **Enable unauthenticated web request rate limit**.
 
    - Optional. Update the **Maximum unauthenticated web requests per rate limit period per IP** value.
@@ -57,8 +61,10 @@ To enable the unauthenticated request rate limit:
 
 To enable the authenticated API request rate limit:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**, and expand **User and IP rate limits**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **User and IP rate limits**.
 1. Select **Enable authenticated API request rate limit**.
 
    - Optional. Update the **Maximum authenticated API requests per rate limit period per user** value.
@@ -70,8 +76,10 @@ To enable the authenticated API request rate limit:
 
 To enable the unauthenticated request rate limit:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**, and expand **User and IP rate limits**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **User and IP rate limits**.
 1. Select **Enable authenticated web request rate limit**.
 
    - Optional. Update the **Maximum authenticated web requests per rate limit period per user** value.
@@ -88,8 +96,10 @@ plain-text body, which by default is `Retry later`.
 
 To use a custom response:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Network**, and expand **User and IP rate limits**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **User and IP rate limits**.
 1. In the **Plain-text response to send to clients that hit a rate limit** text box,
    add the plain-text response message.
 
@@ -131,7 +141,7 @@ GitLab. For example:
    - Set `Gitlab-Bypass-Rate-Limiting` to a value other than `1` on all requests that
      should be affected by rate limiting.
 1. Set the environment variable  `GITLAB_THROTTLE_BYPASS_HEADER`.
-   - For [Omnibus](https://docs.gitlab.com/omnibus/settings/environment-variables.html),
+   - For [Linux package installations](https://docs.gitlab.com/omnibus/settings/environment-variables.html),
      set `'GITLAB_THROTTLE_BYPASS_HEADER' => 'Gitlab-Bypass-Rate-Limiting'` in `gitlab_rails['env']`.
    - For source installations, set `export GITLAB_THROTTLE_BYPASS_HEADER=Gitlab-Bypass-Rate-Limiting`
      in `/etc/default/gitlab`.
@@ -163,7 +173,7 @@ the `GITLAB_THROTTLE_USER_ALLOWLIST` environment variable. If you want
 users 1, 53 and 217 to bypass the authenticated request rate limiter,
 the allowlist configuration would be `1,53,217`.
 
-- For [Omnibus](https://docs.gitlab.com/omnibus/settings/environment-variables.html),
+- For [Linux package installations](https://docs.gitlab.com/omnibus/settings/environment-variables.html),
   set `'GITLAB_THROTTLE_USER_ALLOWLIST' => '1,53,217'` in `gitlab_rails['env']`.
 - For source installations, set `export GITLAB_THROTTLE_USER_ALLOWLIST=1,53,217`
   in `/etc/default/gitlab`.
diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md
index edcf1a80aca..dd53efaf518 100644
--- a/doc/user/admin_area/settings/visibility_and_access_controls.md
+++ b/doc/user/admin_area/settings/visibility_and_access_controls.md
@@ -13,19 +13,21 @@ specific controls on branches, projects, snippets, groups, and more.
 To access the visibility and access control options:
 
 1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 
 ## Define which roles can create projects
 
 Instance-level protections for project creation define which roles can
-[add projects to a group](../../group/manage.md#specify-who-can-add-projects-to-a-group)
+[add projects to a group](../../group/index.md#specify-who-can-add-projects-to-a-group)
 on the instance. To alter which roles have permission to create projects:
 
 1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. For **Default project creation protection**, select the desired roles:
    - No one.
@@ -40,8 +42,9 @@ on the instance. To alter which roles have permission to create projects:
 By default both administrators and anyone with the **Owner** role can delete a project. To restrict project deletion to only administrators:
 
 1. Sign in to GitLab as a user with administrator access.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. Scroll to:
    - (GitLab 15.1 and later) **Allowed to delete projects**, and select **Administrators**.
@@ -55,8 +58,7 @@ By default both administrators and anyone with the **Owner** role can delete a p
 > - [Enabled for projects in personal namespaces](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89466) in GitLab 15.1.
 > - [Disabled for projects in personal namespaces](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95495) in GitLab 15.3.
 > - [Removed option to delete immediately](https://gitlab.com/gitlab-org/gitlab/-/issues/389557) in GitLab 15.11 [with a flag](../../../administration/feature_flags.md) named `always_perform_delayed_deletion`. Disabled by default.
-> - Enabled delayed deletion by default and removed the option to delete immediately [on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622) on May 08, 2023.
-> - Enabled delayed deletion by default and removed the option to delete immediately [on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606) in GitLab 16.0.
+> - Enabled delayed deletion by default and removed the option to delete immediately [on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622) and [on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606) in GitLab 16.0.
 
 Instance-level protection against accidental deletion of groups and projects.
 
@@ -72,17 +74,15 @@ then it gets automatically changed to `1` while also disabling deletion protecti
 
 ### Delayed project deletion
 
-> User interface [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/352960) in GitLab 15.1.
-
-Administrators can enable [delayed project deletion](../../project/settings/index.md#delayed-project-deletion) by default for
-newly-created groups. Group owners can choose to disable this. When disabled, existing groups retain their existing setting. When enabled
-deleted groups remain restorable within a retention period.
+> - User interface [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/352960) in GitLab 15.1.
+> - Enabled delayed deletion by default and removed the option to delete immediately [on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622) and [on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606) in GitLab 16.0.
 
 To configure delayed project deletion:
 
 1. Sign in to GitLab as a user with administrator access.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. Scroll to:
    - (In GitLab 15.11 and later with `always_perform_delayed_deletion` feature flag enabled, or GitLab 16.0 and later) **Deletion protection** and set the retention period to a value between `1` and `90`.
@@ -97,7 +97,8 @@ In GitLab 15.1, and later this setting is enforced on groups when disabled and i
 
 ### Delayed group deletion
 
-> User interface [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/352960) in GitLab 15.1.
+> - User interface [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/352960) in GitLab 15.1.
+> - [Changed to default behavior](https://gitlab.com/gitlab-org/gitlab/-/issues/389557) on the Premium and Ultimate tier in GitLab 16.0.
 
 Groups remain restorable if the retention period is `1` or more days.
 
@@ -120,8 +121,9 @@ Alternatively, projects that are marked for removal can be deleted immediately.
 To set the default [visibility levels for new projects](../../public_access.md):
 
 1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. Select the desired default project visibility:
    - **Private** - Project access must be granted explicitly to each user. If this
@@ -135,8 +137,9 @@ To set the default [visibility levels for new projects](../../public_access.md):
 To set the default visibility levels for new [snippets](../../snippets.md):
 
 1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. Select the desired default snippet visibility.
 1. Select **Save changes**.
@@ -149,8 +152,9 @@ For more details on snippet visibility, read
 To set the default visibility levels for new groups:
 
 1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. Select the desired default group visibility:
    - **Private** - The group and its projects can only be viewed by members.
@@ -170,8 +174,9 @@ the item you're changing.
 To restrict visibility levels for groups, projects, snippets, and selected pages:
 
 1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. In the **Restricted visibility levels** section, select the desired visibility levels to restrict.
    - If you restrict the **Public** level:
@@ -195,8 +200,9 @@ Before you can import projects from other systems, you must enable the
 [import source](../../gitlab_com/index.md#default-import-sources) for that system.
 
 1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. Select each of **Import sources** to allow.
 1. Select **Save changes**.
@@ -207,8 +213,9 @@ To enable the export of
 [projects and their data](../../project/settings/import_export.md#export-a-project-and-its-data):
 
 1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. Scroll to **Project export**.
 1. Select the **Enabled** checkbox.
@@ -223,8 +230,9 @@ You can enable migration of groups by direct transfer using the UI.
 To enable migration of groups by direct transfer:
 
 1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. Scroll to **Allow migrating GitLab groups and projects by direct transfer**.
 1. Select the **Enabled** checkbox.
@@ -244,8 +252,9 @@ The GitLab restrictions apply at the application level.
 To specify the enabled Git access protocols:
 
 1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. Select the desired Git access protocols:
    - Both SSH and HTTP(S)
@@ -330,8 +339,9 @@ include the `10.0.0.0/24` range.
 To add a IP address range to the group-level allowlist:
 
 1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. In **Globally-allowed IP ranges**, provide a list of IP address ranges. This list:
    - Has no limit on the number of IP address ranges.
diff --git a/doc/user/admin_area/user_cohorts.md b/doc/user/admin_area/user_cohorts.md
index b47ae561689..6f2798f437c 100644
--- a/doc/user/admin_area/user_cohorts.md
+++ b/doc/user/admin_area/user_cohorts.md
@@ -34,6 +34,7 @@ How do we measure the activity of users? GitLab considers a user active if:
 
 To view user cohorts:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select the **Cohorts** tab.
diff --git a/doc/user/ai_features.md b/doc/user/ai_features.md
index 7c9480d308f..d5f7201556e 100644
--- a/doc/user/ai_features.md
+++ b/doc/user/ai_features.md
@@ -11,22 +11,25 @@ GitLab is creating AI-assisted features across our DevSecOps platform. These fea
 
 ## Enable AI/ML features
 
-> Introduced in GitLab 16.0 and is [actively being rolled out](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118222).
+> Introduced in GitLab 16.0 and [actively being rolled out](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118222).
 
 Prerequisites:
 
 - You must have the Owner role for the group.
 
-To enable AI/ML features:
+To enable AI/ML features for a top-level group:
 
-- Enable the [Experiment features setting](group/manage.md#group-experiment-features-setting).
-- The [third-party AI features setting](group/manage.md#group-third-party-ai-features-setting) is enabled by default. To disable AI features powered by third-party APIs, disable this setting.
+- Enable [Experiment features](group/manage.md#enable-experiment-features).
+- Enable [third-party AI features](group/manage.md#enable-third-party-ai-features) (enabled by default).
+  To disable AI features powered by third-party APIs, clear this setting.
 
-These settings give you control over which features are enabled. These settings work together so you can have a mix of both experimental and third-party AI features.
+These settings work together so you can have a mix of both experimental and third-party AI features.
 
 ## Generally Available AI features
 
-When a feature is [Generally Available](../policy/alpha-beta-support.md#generally-available-ga), it does not require the [group-level Experiment features setting](group/manage.md#group-experiment-features-setting) to be enabled. Some of these features might require the [group-level third-party AI features setting](group/manage.md#group-third-party-ai-features-setting).
+When a feature is [Generally Available](../policy/experiment-beta-support.md#generally-available-ga),
+it does not require [Experiment features to be enabled](group/manage.md#enable-experiment-features).
+Some of these features might require [third-party AI features to be enabled](group/manage.md#enable-third-party-ai-features).
 
 The following feature is Generally Available:
 
@@ -34,7 +37,8 @@ The following feature is Generally Available:
 
 ## Beta AI features
 
-[Beta features](../policy/alpha-beta-support.md#beta) do not require the [group-level Experiment features setting](group/manage.md#group-experiment-features-setting) to be enabled.
+[Beta features](../policy/experiment-beta-support.md#beta) do not require
+[Experiment features to be enabled](group/manage.md#enable-experiment-features).
 
 The following feature is in Beta:
 
@@ -42,17 +46,20 @@ The following feature is in Beta:
 
 ## Experiment AI features
 
-[Experiment features](../policy/alpha-beta-support.md#experiment) will soon require the [group-level Experiment features setting](group/manage.md#group-experiment-features-setting) to be enabled.
+[Experiment features](../policy/experiment-beta-support.md#experiment) will soon require
+[Experiment features to be enabled](group/manage.md#enable-experiment-features).
 
 ## Third-party AI features
 
-Third-party AI features require the [group-level third-party AI features setting](group/manage.md#group-third-party-ai-features-setting) to be enabled. Experiment third-party AI features also require the [Experiment features setting](group/manage.md#group-experiment-features-setting) to be enabled.
+Third-party AI features require [third-party AI services to be enabled](group/manage.md#enable-third-party-ai-features).
+
+For Experiment third-party AI features, [Experiment features must be enabled](group/manage.md#enable-experiment-features) as well.
 
 ### Explain Selected Code in the Web UI **(ULTIMATE SAAS)**
 
-> Introduced in GitLab 15.11 as an [Experiment](../policy/alpha-beta-support.md#experiment) on GitLab.com.
+> Introduced in GitLab 15.11 as an [Experiment](../policy/experiment-beta-support.md#experiment) on GitLab.com.
 
-This feature is an [Experiment](../policy/alpha-beta-support.md) on GitLab.com that is powered by OpenAI's GPT-3.
+This feature is an [Experiment](../policy/experiment-beta-support.md) on GitLab.com that is powered by OpenAI's GPT-3.
 
 GitLab can help you get up to speed faster if you:
 
@@ -69,8 +76,8 @@ Prerequisites:
 
 To explain your code:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests**, then select your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Code > Merge requests**, then select your merge request.
 1. On the secondary menu, select **Changes**.
 1. Go to the file, and select the lines that you want to have explained.
 1. On the left side, select the question mark (**{question}**). You might have to scroll to the first line of your selection to view it. This sends the selected code, together with a prompt, to provide an explanation to the large language model.
@@ -83,9 +90,9 @@ We cannot guarantee that the large language model produces results that are corr
 
 ### Explain this Vulnerability in the Web UI **(ULTIMATE SAAS)**
 
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10368) in GitLab 16.0 as an [Experiment](../policy/alpha-beta-support.md#experiment) on GitLab.com.
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10368) in GitLab 16.0 as an [Experiment](../policy/experiment-beta-support.md#experiment) on GitLab.com.
 
-This feature is an [Experiment](../policy/alpha-beta-support.md) on GitLab.com that is powered by Google AI.
+This feature is an [Experiment](../policy/experiment-beta-support.md) on GitLab.com that is powered by Google AI.
 
 GitLab can help you with your vulnerability by using a large language model to:
 
@@ -101,8 +108,8 @@ Prerequisites:
 
 To explain your vulnerability:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Vulnerability report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Secure > Vulnerability report**.
 1. Find a SAST vulnerability.
 1. Open the vulnerability.
 1. Select **Try it out**.
@@ -115,9 +122,9 @@ We cannot guarantee that the large language model produces results that are corr
 
 ### GitLab Chat **(ULTIMATE SAAS)**
 
-> Introduced in GitLab 16.0 as an [Experiment](../policy/alpha-beta-support.md#experiment).
+> Introduced in GitLab 16.0 as an [Experiment](../policy/experiment-beta-support.md#experiment).
 
-This feature is an [Experiment](../policy/alpha-beta-support.md) on GitLab.com that is powered by OpenAI's GPT-3. It requires the [group-level third-party AI features setting](group/manage.md#group-third-party-ai-features-setting) to be enabled.
+This feature is an [Experiment](../policy/experiment-beta-support.md) on GitLab.com that is powered by OpenAI's GPT-3. It requires the [group-level third-party AI features setting](group/manage.md#enable-third-party-ai-features) to be enabled.
 
 Getting help has never been easier. If you have a question about how the GitLab product works, you can ask product how-to questions and get AI generated support from GitLab Chat.
 
@@ -129,11 +136,15 @@ To give feedback, select the **Give Feedback** link.
 
 ### Summarize merge request changes **(ULTIMATE SAAS)**
 
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10400) in GitLab 16.0 as an [Experiment](../policy/alpha-beta-support.md#experiment).
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10400) in GitLab 16.0 as an [Experiment](../policy/experiment-beta-support.md#experiment).
+
+This feature is an [Experiment](../policy/experiment-beta-support.md) on GitLab.com that is powered by OpenAI's GPT-3. It requires the [group-level third-party AI features setting](group/manage.md#enable-third-party-ai-features) to be enabled.
 
-This feature is an [Experiment](../policy/alpha-beta-support.md) on GitLab.com that is powered by OpenAI's GPT-3. It requires the [group-level third-party AI features setting](group/manage.md#group-third-party-ai-features-setting) to be enabled.
+You can generate a merge request summary in a merge request comment.
 
-You can generate a merge request summary by using the `/summarize_diff` quick action in a merge request comment. This action posts a comment from a GitLab bot. The comment provides a summary of the changes and the related SHA for when that summary was generated.
+- In a comment, type `/summarize_diff`.
+
+This action posts a comment from a GitLab bot. The comment provides a summary of the changes and the related SHA for when that summary was generated.
 
 Provide feedback on this experimental feature in [issue 408726](https://gitlab.com/gitlab-org/gitlab/-/issues/408726).
 
@@ -142,16 +153,19 @@ and the target branch is sent to the large language model referenced above.
 
 ### Summarize my merge request review **(ULTIMATE SAAS)**
 
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10466) in GitLab 16.0 as an [Experiment](../policy/alpha-beta-support.md#experiment).
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10466) in GitLab 16.0 as an [Experiment](../policy/experiment-beta-support.md#experiment).
+
+This feature is an [Experiment](../policy/experiment-beta-support.md) on GitLab.com that is powered by OpenAI's GPT-3. It requires the [group-level third-party AI features setting](group/manage.md#enable-third-party-ai-features) to be enabled.
 
-This feature is an [Experiment](../policy/alpha-beta-support.md) on GitLab.com that is powered by OpenAI's GPT-3. It requires the [group-level third-party AI features setting](group/manage.md#group-third-party-ai-features-setting) to be enabled.
+When you've completed your review of a merge request and are ready to [submit your review](project/merge_requests/reviews/index.md#submit-a-review), you can have a summary generated for you.
 
-When you've completed your review of a merge request and are ready to [submit your review](project/merge_requests/reviews/index.md#submit-a-review) you can choose to have summary generated for you. To generate the summary:
+To generate the summary:
 
-1. Select the AI Actions dropdown list.
+1. When you are ready to submit your review, select **Finish review**.
+1. Select **AI Actions** (**{tanuki}**).
 1. Select **Summarize my code review**.
 
-The summary is generated and entered in to the comment box where you can edit and refine prior to submitting with your review.
+The summary is displayed in the comment box. You can edit and refine the summary prior to submitting your review.
 
 Provide feedback on this experimental feature in [issue 408991](https://gitlab.com/gitlab-org/gitlab/-/issues/408991).
 
@@ -162,16 +176,19 @@ Provide feedback on this experimental feature in [issue 408991](https://gitlab.c
 
 ### Generate suggested tests in merge requests **(ULTIMATE SAAS)**
 
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10366) in GitLab 16.0 as an [Experiment](../policy/alpha-beta-support.md#experiment).
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10366) in GitLab 16.0 as an [Experiment](../policy/experiment-beta-support.md#experiment).
 
-This feature is an [Experiment](../policy/alpha-beta-support.md) on GitLab.com that is powered by OpenAI's GPT-3. It requires the [group-level third-party AI features setting](group/manage.md#group-third-party-ai-features-setting) to be enabled.
+This feature is an [Experiment](../policy/experiment-beta-support.md) on GitLab.com that is powered by OpenAI's GPT-3. It requires the [group-level third-party AI features setting](group/manage.md#enable-third-party-ai-features) to be enabled.
 
-When in a merge request you can choose to have GitLab suggest tests for the file you are reviewing. This can help to determine if appropriate test coverage has been provided or help with writing tests to provide more coverage for your project. To generate a test suggestion:
+In a merge request, you can get a list of suggested tests for the file you are reviewing. This functionality can help determine if appropriate test coverage has been provided, or if you need more coverage for your project.
 
-1. Select the menu icon on the header of a file.
-1. Select **Generate test with AI**.
+To generate a test suggestion:
 
-A sidebar opens where the test suggestion is generated. From there you can choose to copy that suggestion in to your editor as the start of your tests.
+1. In a merge request, select the **Changes** tab.
+1. On the header for the file, in the upper-right corner, select **Options** (**{ellipsis_v}**).
+1. Select **Suggest test cases**.
+
+The test suggestion is generated in a sidebar. You can copy the suggestion to your editor and use it as the start of your tests.
 
 Feedback on this experimental feature can be provided in [issue 408995](https://gitlab.com/gitlab-org/gitlab/-/issues/408995).
 
@@ -180,17 +197,37 @@ Feedback on this experimental feature can be provided in [issue 408995](https://
 - Contents of the file
 - The file name
 
+### Summarize issue discussions **(ULTIMATE SAAS)**
+
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10344) in GitLab 16.0 as an [Experiment](../policy/experiment-beta-support.md#experiment).
+
+This feature is an [Experiment](../policy/experiment-beta-support.md) on GitLab.com that is powered by OpenAI's
+GPT-3. It requires the [group-level third-party AI features setting](group/manage.md#enable-third-party-ai-features) to be enabled.
+
+You can generate a summary of discussions on an issue:
+
+1. In an issue, scroll to the **Activity** section.
+1. Select **View summary**.
+
+The comments in the issue are summarized in as many as 10 list items.
+The summary is displayed only for you.
+
+Provide feedback on this experimental feature in [issue 407779](https://gitlab.com/gitlab-org/gitlab/-/issues/407779).
+
+**Data usage**: When you use this feature, the text of public comments on the issue are sent to the large
+language model referenced above.
+
 ## Data Usage
 
 GitLab AI features leverage generative AI to help increase velocity and aim to help make you more productive. Each feature operates independently of other features and is not required for other features to function.
 
 ### Progressive enhancement
 
-These features are designed as a progressive enhancement to existing GitLab features across our DevSecOps platform. They are designed to fail gracefully and should not prevent the core functionality of the underlying feature. Please note each feature is subject to its expected functionality as defined by the relevant [feature support policy](../policy/alpha-beta-support.md).
+These features are designed as a progressive enhancement to existing GitLab features across our DevSecOps platform. They are designed to fail gracefully and should not prevent the core functionality of the underlying feature. Please note each feature is subject to its expected functionality as defined by the relevant [feature support policy](../policy/experiment-beta-support.md).
 
 ### Stability and performance
 
-These features are in a variety of [feature support levels](../policy/alpha-beta-support.md#beta). Due to the nature of these features, there may be high demand for usage which may cause degraded performance or unexpected downtime of the feature. We have built these features to gracefully degrade and have controls in place to allow us to mitigate abuse or misuse. GitLab may disable **beta and experimental** features for any or all customers at any time at our discretion.
+These features are in a variety of [feature support levels](../policy/experiment-beta-support.md#beta). Due to the nature of these features, there may be high demand for usage which may cause degraded performance or unexpected downtime of the feature. We have built these features to gracefully degrade and have controls in place to allow us to mitigate abuse or misuse. GitLab may disable **beta and experimental** features for any or all customers at any time at our discretion.
 
 ## Third party services
 
@@ -198,7 +235,7 @@ These features are in a variety of [feature support levels](../policy/alpha-beta
 
 Some AI features require the use of third-party AI services models and APIs from: Google AI and OpenAI. The processing of any personal data is in accordance with our [Privacy Statement](https://about.gitlab.com/privacy/). You may also visit the [Sub-Processors page](https://about.gitlab.com/privacy/subprocessors/#third-party-sub-processors) to see the list of our Sub-Processors that we use in order to provide these features.
 
-Group owners can control which top-level groups have access to third-party AI features by using the [group level third-party AI features setting](group/manage.md#group-third-party-ai-features-setting).
+Group owners can control which top-level groups have access to third-party AI features by using the [group level third-party AI features setting](group/manage.md#enable-third-party-ai-features).
 
 ### Model accuracy and quality
 
diff --git a/doc/user/analytics/analytics_dashboards.md b/doc/user/analytics/analytics_dashboards.md
new file mode 100644
index 00000000000..e29e02c867f
--- /dev/null
+++ b/doc/user/analytics/analytics_dashboards.md
@@ -0,0 +1,177 @@
+---
+stage: Analyze
+group: Product Analytics
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Analytics dashboards (Experiment) **(ULTIMATE)**
+
+> Introduced in GitLab 15.9 as an [Experiment](../../policy/experiment-beta-support.md#experiment) feature [with a flag](../../administration/feature_flags.md) named `combined_analytics_dashboards`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `combined_analytics_dashboards`.
+On GitLab.com, this feature is not available.
+This feature is not ready for production use.
+
+## Dashboards
+
+Each project can have an unlimited number of dashboards, only limited by the instances [repository size limits](../project/repository/reducing_the_repo_size_using_git.md#storage-limits).
+These dashboards are defined using the GitLab YAML schema, and stored in the `.gitlab/analytics/dashboards/` directory of a project repository.
+The dashboard file name and containing directory should be the same, for example `my_dashboard/my_dashboard.yaml`. For more information see [defining a dashboard](#define-a-dashboard).
+Each dashboard can reference one or more [visualizations](#define-a-chart-visualization), which are shared across dashboards.
+
+Project maintainers can enforce approval rules on dashboard changes using features such as [code owners](../project/codeowners/index.md) and [approval rules](../project/merge_requests/approvals/rules.md).
+Your dashboard files are versioned in source control with the rest of a project's code.
+
+### Data sources
+
+A data source is a connection to a database or collection of data which can be used by your dashboard
+filters and visualizations to query and retrieve results.
+
+The following data sources are configured for analytics dashboards:
+
+- [Product analytics](../product_analytics/index.md)
+
+### View project dashboards
+
+To view a list of dashboards for a project:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > Dashboards**.
+1. From the list of available dashboards, select the dashboard you want to view.
+
+### Define a dashboard
+
+To define a dashboard:
+
+1. In `.gitlab/analytics/dashboards/`, create a directory named like the dashboard.
+
+   Each dashboard should have its own directory.
+1. In the new directory, create a `.yaml` file with the same name as the directory, for example `.gitlab/analytics/dashboards/my_dashboard/my_dashboard.yaml`.
+
+   This file contains the dashboard definition. It must conform to the JSON schema defined in `ee/app/validators/json_schemas/analytics_dashboard.json`.
+1. Optional. To create new visualizations to add to your dashboard see [defining a chart visualization](#define-a-chart-visualization).
+
+For [example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/analytics/product_analytics/dashboards/audience.yaml), if you want to create three dashboards (Conversion funnels, Demographic breakdown, and North star metrics)
+and one visualization (line chart) that applies to all dashboards, the file structure would be:
+
+```plaintext
+.gitlab/analytics/dashboards
+├── conversion_funnels
+│  └── conversion_funnels.yaml
+├── demographic_breakdown
+│  └── demographic_breakdown.yaml
+├── north_star_metrics
+|  └── north_star_metrics.yaml
+├── visualizations
+│  └── example_line_chart.yaml
+```
+
+### Define a chart visualization
+
+You can define different charts, and add visualization options to some of them:
+
+- Line chart, with the options listed in the [ECharts documentation](https://echarts.apache.org/en/option.html).
+- Column chart, with the options listed in the [ECharts documentation](https://echarts.apache.org/en/option.html).
+- Data table, with the only option to render `links` (array of objects, each with `text` and `href` properties to specify the dimensions to be used in links). See [example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_visualization.json?ref_type=heads#L112)).
+- Single stat, with the only option to set `decimalPlaces` (number, default value is 0).
+
+To define a chart for your dashboards:
+
+1. In the `.gitlab/analytics/dashboards/visualizations/` directory, create a `.yaml` file.
+   The filename should be descriptive of the visualization it defines.
+1. In the `.yaml` file, define the visualization configuration, according to the schema in
+   `ee/app/validators/json_schemas/analytics_visualization.json`.
+
+For [example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/analytics/product_analytics/visualizations/events_over_time.yaml), to create a line chart that illustrates event count over time, in the `visualizations` folder
+create a `line_chart.yaml` file with the following required fields:
+
+- version
+- type
+- data
+- options
+
+### Change the location of project dashboards
+
+Dashboards are usually defined in the project where analytics data is being retrieved.
+However, you can also have a separate project for dashboards.
+This is recommended if you want to enforce specific access rules to the dashboard definitions or share dashboards across multiple projects.
+
+NOTE:
+You can share dashboards only between projects that are located in the same group.
+
+To change the location of project dashboards:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project,
+   or select **Create new...** (**{plus}**) and **New project/repository**
+   to create the project to store your dashboard files.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) and find the project you want to use the dashboards for.
+1. Select **Settings > General**.
+1. Expand **Analytics**.
+1. In the **Analytics Dashboards** section, select the project that contains the dashboard files.
+1. Select **Save changes**.
+
+### Change the location of group dashboards
+
+NOTE:
+This feature will be connected to group-level dashboards in [issue 411572](https://gitlab.com/gitlab-org/gitlab/-/issues/411572).
+
+If you want to use dashboards for a group, you must store the dashboard files in a project that belongs to that group.
+You can change the source project of a group's dashboards at any time.
+
+To change the location of a group's dashboards:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
+1. Expand **Analytics**.
+1. In the **Analytics Dashboards** section, select the project that contains the dashboard files.
+1. Select **Save changes**.
+
+## Dashboards designer
+
+> Introduced in GitLab 16.1 [with a flag](../../administration/feature_flags.md) named `combined_analytics_dashboards_editor`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `combined_analytics_dashboards_editor`.
+On GitLab.com, this feature is not available.
+This feature is not ready for production use.
+
+NOTE:
+This feature does not work in conjunction with the `product_analytics_snowplow_support` feature flag.
+
+You can use the dashboards designer to:
+
+- Create custom dashboards
+- Rename custom dashboards
+- Add visualizations to new and existing custom dashboards
+- Resize or move panels within custom dashboards
+
+You cannot edit the built-in dashboards labeled as `By GitLab`.
+To edit these dashboards you should create a new custom dashboard which uses the same visualizations.
+
+### Create a custom dashboard
+
+To create a custom dashboard:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > Dashboards**.
+1. Select **New dashboard**.
+1. In the **New dashboard** input, enter the name of the dashboard.
+1. From the **Add visualizations** list on the right, select the visualizations to add to the dashboard.
+1. Optional. Drag or resize the selected panel how you prefer.
+1. Select **Save**.
+
+### Edit a custom dashboard
+
+You can edit your custom dashboard's title and add or resize visualizations within the dashboard designer.
+
+To edit an existing custom dashboard:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > Dashboards**.
+1. From the list of available dashboards, select a custom dashboard (one without the `By GitLab` label) you want to edit.
+1. Select **Edit**.
+1. Optional. Change the title of the dashboard.
+1. Optional. From the **Add visualizations** list on the right, select other visualizations to add to the dashboard.
+1. Optional. In the dashboard, select a panel and drag or resize it how you prefer.
+1. Select **Save**.
diff --git a/doc/user/analytics/ci_cd_analytics.md b/doc/user/analytics/ci_cd_analytics.md
index bde7fdc6c2d..daee21d2567 100644
--- a/doc/user/analytics/ci_cd_analytics.md
+++ b/doc/user/analytics/ci_cd_analytics.md
@@ -32,8 +32,8 @@ View pipeline duration history:
 
 To view CI/CD analytics:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > CI/CD Analytics**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > CI/CD analytics**.
 
 ## View DORA deployment frequency chart **(ULTIMATE)**
 
@@ -50,8 +50,8 @@ The deployment frequency chart is available for groups and projects.
 
 To view the deployment frequency chart:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > CI/CD Analytics**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > CI/CD analytics**.
 1. Select the **Deployment frequency** tab.
 
 ![Deployment frequency](img/deployment_frequency_charts_v13_12.png)
@@ -72,8 +72,8 @@ merge requests to be deployed to a production environment. This chart is availab
 
 To view the lead time for changes chart:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > CI/CD Analytics**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > CI/CD analytics**.
 1. Select the **Lead time** tab.
 
 ![Lead time](img/lead_time_chart_v13_11.png)
@@ -88,8 +88,8 @@ Time to restore service is one of the four DORA metrics that DevOps teams use fo
 
 To view the time to restore service chart:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > CI/CD Analytics**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > CI/CD analytics**.
 1. Select the **Time to restore service** tab.
 
 ![Lead time](img/time_to_restore_service_charts_v15_1.png)
@@ -104,6 +104,6 @@ Change failure rate is one of the four DORA metrics that DevOps teams use for me
 
 To view the change failure rate chart:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > CI/CD Analytics**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > CI/CD analytics**.
 1. Select the **Change failure rate** tab.
diff --git a/doc/user/analytics/code_review_analytics.md b/doc/user/analytics/code_review_analytics.md
index 2e76252f7d3..646a85fc7a2 100644
--- a/doc/user/analytics/code_review_analytics.md
+++ b/doc/user/analytics/code_review_analytics.md
@@ -34,8 +34,8 @@ Prerequisite:
 
 To view code review analytics:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > Code Review**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > Code review analytics**.
 1. Optional. Filter results:
    1. Select the filter bar.
    1. Select a parameter. You can filter merge requests by milestone and label.
diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md
index 44af9dc9dea..e78f55911e6 100644
--- a/doc/user/analytics/index.md
+++ b/doc/user/analytics/index.md
@@ -33,6 +33,8 @@ GitLab provides several analytics features at the group level. Some of these fea
 
 You can use GitLab to review analytics at the project level. Some of these features require you to use a higher tier than GitLab Free.
 
+- [Analytics dashboards](analytics_dashboards.md), enabled with the `combined_analytics_dashboards_editor`
+  [feature flag](../../development/feature_flags/index.md#enabling-a-feature-flag-locally-in-development)
 - [Application Security](../application_security/security_dashboard/index.md)
 - [CI/CD & DORA](ci_cd_analytics.md)
 - [Code Review](code_review_analytics.md)
@@ -43,6 +45,16 @@ You can use GitLab to review analytics at the project level. Some of these featu
 - [Repository](repository_analytics.md)
 - [Value Stream](value_stream_analytics.md)
 
+### Remove project analytics from the left sidebar
+
+By default, analytics for a project are displayed under the **Analyze** item in the left sidebar. To remove this item:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
+1. Expand **Visibility, project features, permissions**.
+1. Turn off the **Analytics** toggle.
+1. Select **Save changes**.
+
 ## User-configurable analytics
 
 The following analytics features are available for users to create personalized views:
diff --git a/doc/user/analytics/issue_analytics.md b/doc/user/analytics/issue_analytics.md
index 71ce13a725e..aaf33f48df2 100644
--- a/doc/user/analytics/issue_analytics.md
+++ b/doc/user/analytics/issue_analytics.md
@@ -15,8 +15,8 @@ prior.
 
 To access the chart:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > Issue**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > Issue analytics**.
 
 Hover over each bar to see the total number of issues.
 
diff --git a/doc/user/analytics/merge_request_analytics.md b/doc/user/analytics/merge_request_analytics.md
index 69ba5a67197..eeaa8271749 100644
--- a/doc/user/analytics/merge_request_analytics.md
+++ b/doc/user/analytics/merge_request_analytics.md
@@ -29,8 +29,8 @@ Prerequisite:
 
 To view merge request analytics:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > Merge request**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > Merge request analytics**.
 
 ## View the number of merge requests in a date range
 
@@ -39,8 +39,8 @@ To view merge request analytics:
 
 To view the number of merge requests merged during a specific date range:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > Merge request**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > Merge request analytics**.
 1. Optional. Filter results:
    1. Select the filter bar.
    1. Select a parameter.
@@ -73,6 +73,6 @@ created and when it's merged. Closed and not yet merged merge requests are not i
 
 To view **Mean time to merge**:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > Merge request**. The **Mean time to merge** number
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > Merge request analytics**. The **Mean time to merge** number
 is displayed on the dashboard.
diff --git a/doc/user/analytics/productivity_analytics.md b/doc/user/analytics/productivity_analytics.md
index 08bb579fd0a..f53b516dd0d 100644
--- a/doc/user/analytics/productivity_analytics.md
+++ b/doc/user/analytics/productivity_analytics.md
@@ -26,8 +26,8 @@ Prerequisite:
 
 - You must have at least the Reporter role for the group.
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Analytics > Productivity**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Analyze > Productivity analytics**.
 1. Optional. Filter results:
    1. Select a project from the dropdown list.
    1. To filter results by author, milestone, or label,
@@ -44,8 +44,8 @@ Use the following charts in productivity analytics to view the velocity of your
 merge requests to merge after they were created.
 - **Trendline**: number of merge requests that were merged in a specific time period.
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Analytics > Productivity**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Analyze > Productivity analytics**.
 
 To filter time metrics:
 
@@ -56,8 +56,8 @@ To filter time metrics:
 
 To view commit statistics for your group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Analytics > Productivity**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Analyze > Productivity analytics**.
 1. Under the **Trendline** scatterplot, view the commit statistics:
    - The left histogram shows the number of hours between commits, comments, and merges.
    - The right histogram shows the number of commits and changes per merge request.
diff --git a/doc/user/analytics/repository_analytics.md b/doc/user/analytics/repository_analytics.md
index b434221b887..e686d76eda2 100644
--- a/doc/user/analytics/repository_analytics.md
+++ b/doc/user/analytics/repository_analytics.md
@@ -30,8 +30,8 @@ Commits in a project's [wiki](../project/wiki/index.md#track-wiki-events) are no
 
 To review repository analytics for a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > Repository analytics**.
 
 ## How repository analytics chart data is updated
 
diff --git a/doc/user/analytics/value_streams_dashboard.md b/doc/user/analytics/value_streams_dashboard.md
index 384f4ce3455..9b332d78060 100644
--- a/doc/user/analytics/value_streams_dashboard.md
+++ b/doc/user/analytics/value_streams_dashboard.md
@@ -4,10 +4,10 @@ group: Optimize
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Value Streams Dashboard (Beta) **(ULTIMATE)**
+# Value Streams Dashboard **(ULTIMATE)**
 
-> - Introduced in GitLab 15.8 as a Closed [Beta](../../policy/alpha-beta-support.md#beta) feature [with a flag](../../administration/feature_flags.md) named `group_analytics_dashboards_page`. Disabled by default.
-> - Released in GitLab 15.11 as an Open [Beta](../../policy/alpha-beta-support.md#beta) feature [with a flag](../../administration/feature_flags.md) named `group_analytics_dashboards_page`. Enabled by default.
+> - Introduced in GitLab 15.8 as a Closed [Beta](../../policy/experiment-beta-support.md#beta) feature [with a flag](../../administration/feature_flags.md) named `group_analytics_dashboards_page`. Disabled by default.
+> - Released in GitLab 15.11 as an Open [Beta](../../policy/experiment-beta-support.md#beta) feature [with a flag](../../administration/feature_flags.md) named `group_analytics_dashboards_page`. Enabled by default.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/392734) in GitLab 16.0. Feature flag `group_analytics_dashboards_page` removed.
 
 You can leave feedback on dashboard bugs or functionality in [issue 381787](https://gitlab.com/gitlab-org/gitlab/-/issues/381787).
@@ -21,17 +21,18 @@ For more information, see the [Value Stream Management category direction page](
 Our initial use case is focused on providing the ability to compare software delivery metrics.
 This comparison can help decision-makers understand whether projects and groups are improving.
 
-The beta version of the Value Streams Dashboard includes the following metrics:
+The Value Streams Dashboard includes the following metrics:
 
 - [DORA metrics](dora_metrics.md)
 - [Value Stream Analytics (VSA) - flow metrics](../group/value_stream_analytics/index.md)
+- [Vulnerabilities](https://gitlab.com/gitlab-org/gitlab/-/security/vulnerability_report) metrics.
 
 The Value Streams Dashboard allows you to:
 
 - Aggregate data records from different APIs.
 - Track software performance (DORA) and flow of value (VSA) across the organization.
 
-## DevOps metrics comparison
+## DevOps metrics comparison panel
 
 The DevOps metrics comparison displays DORA4 and flow metrics for a group or project in the
 month-to-date, last month, the month before, and the past 180 days.
@@ -54,10 +55,8 @@ Prerequisite:
 
 To view the value streams dashboard:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Analytics > Value stream**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Analyze > Value stream analytics**.
 1. Below the **Filter results** text box, in the **Key metrics** row, select **Value Streams Dashboard / DORA**.
 1. Optional. To open the new page, append this path `/analytics/dashboards/value_streams_dashboard` to the group URL
 (for example, `https://gitlab.com/groups/gitlab-org/-/analytics/dashboards/value_streams_dashboard`).
@@ -88,15 +87,15 @@ Prerequisite:
 
 - You must have at least the Maintainer role for the group.
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
-1. Scroll to **Analytics Dashboards** and select **Expand**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
+1. Expand **Analytics**.
 1. Select the project where you would like to store your YAML configuration file.
 1. Select **Save changes**.
 
 After you have set up the project, set up the configuration file:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. In the default branch, create the configuration file: `.gitlab/analytics/dashboards/value_streams/value_streams.yaml`.
 1. In the `value_streams.yaml` configuration file, fill in the configuration options:
 
@@ -110,6 +109,7 @@ description: 'Custom description'
 # panels - List of panels that contain panel settings.
 #   title - Change the title of the panel. [optional]
 #   data.namespace - The Group or Project path to use for the chart panel.
+#   data.exclude_metrics - Hide rows by metric ID from the chart panel.
 panels:
   - title: 'My Custom Project'
     data:
@@ -119,6 +119,9 @@ panels:
   - title: 'My Custom Group'
     data:
       namespace: group/my-custom-group
+      exclude_metrics:
+        - deployment_frequency
+        - change_failure_rate
   - data:
       namespace: group/another-group
 ```
@@ -133,15 +136,17 @@ panels:
 
 ## Dashboard metrics and drill-down reports
 
-| Metric | Description | Drill-down report | Documentation page |
-| ------ | ----------- | --------------- | ------------------ |
-| Deployment frequency | Average number of deployments to production per day. This metric measures how often value is delivered to end users. | [Deployment frequency tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=deployment-frequency) | [Deployment frequency](dora_metrics.md#deployment-frequency) |
-| Lead time for changes | The time to successfully deliver a commit into production. This metric reflects the efficiency of CI/CD pipelines. | [Lead time tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=lead-time) | [Lead time for changes](dora_metrics.md#lead-time-for-changes) |
-| Time to restore service | The time it takes an organization to recover from a failure in production. | [Time to restore service tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=time-to-restore-service) | [Time to restore service](dora_metrics.md#time-to-restore-service) |
-| Change failure rate | Percentage of deployments that cause an incident in production. | [Change failure rate tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=change-failure-rate) | [Change failure rate](dora_metrics.md#change-failure-rate) |
-| Lead time | Median time from issue created to issue closed. | [Value Stream Analytics](https://gitlab.com/groups/gitlab-org/-/analytics/value_stream_analytics) | [View the lead time and cycle time for issues](../group/value_stream_analytics/index.md#key-metrics) |
-| Cycle time | Median time from the earliest commit of a linked issue's merge request to when that issue is closed. | [VSA overview](https://gitlab.com/groups/gitlab-org/-/analytics/value_stream_analytics) | [View the lead time and cycle time for issues](../group/value_stream_analytics/index.md#key-metrics) |
-| New issues | Number of new issues created. | [Issue Analytics](https://gitlab.com/groups/gitlab-org/-/issues_analytics) | Issue analytics [for projects](issue_analytics.md) and [for groups](../../user/group/issues_analytics/index.md) |
-| Number of deploys | Total number of deploys to production. | [Merge Request Analytics](https://gitlab.com/gitlab-org/gitlab/-/analytics/merge_request_analytics) | [Merge request analytics](merge_request_analytics.md) |
-| Critical vulnerabilities over time | Critical vulnerabilities over time in project or group | [Vulnerability report](https://gitlab.com/gitlab-org/gitlab/-/security/vulnerability_report) | [Vulnerability report](../application_security/vulnerability_report/index.md) |
-| High vulnerabilities over time | High vulnerabilities over time in project or group | [Vulnerability report](https://gitlab.com/gitlab-org/gitlab/-/security/vulnerability_report) | [Vulnerability report](../application_security/vulnerability_report/index.md) |
+| Metric | Description | Drill-down report | Documentation page | ID |
+| ------ | ----------- | --------------- | ------------------ | -- |
+| Deployment frequency | Average number of deployments to production per day. This metric measures how often value is delivered to end users. | [Deployment frequency tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=deployment-frequency) | [Deployment frequency](dora_metrics.md#deployment-frequency) | `deployment_frequency` |
+| Lead time for changes | The time to successfully deliver a commit into production. This metric reflects the efficiency of CI/CD pipelines. | [Lead time tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=lead-time) | [Lead time for changes](dora_metrics.md#lead-time-for-changes) | `lead_time_for_changes` |
+| Time to restore service | The time it takes an organization to recover from a failure in production. | [Time to restore service tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=time-to-restore-service) | [Time to restore service](dora_metrics.md#time-to-restore-service) | `time_to_restore_service` |
+| Change failure rate | Percentage of deployments that cause an incident in production. | [Change failure rate tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=change-failure-rate) | [Change failure rate](dora_metrics.md#change-failure-rate) | `change_failure_rate` |
+| Lead time | Median time from issue created to issue closed. | [Value Stream Analytics](https://gitlab.com/groups/gitlab-org/-/analytics/value_stream_analytics) | [View the lead time and cycle time for issues](../group/value_stream_analytics/index.md#key-metrics) | `lead_time` |
+| Cycle time | Median time from the earliest commit of a linked issue's merge request to when that issue is closed. | [VSA overview](https://gitlab.com/groups/gitlab-org/-/analytics/value_stream_analytics) | [View the lead time and cycle time for issues](../group/value_stream_analytics/index.md#key-metrics) | `cycle_time` |
+| New issues | Number of new issues created. | [Issue Analytics](https://gitlab.com/groups/gitlab-org/-/issues_analytics) | Issue analytics [for projects](issue_analytics.md) and [for groups](../../user/group/issues_analytics/index.md) | `issues` |
+| Closed issues | Number of issues closed by month. | [Value Stream Analytics](https://gitlab.com/groups/gitlab-org/-/analytics/value_stream_analytics) | [Value Stream Analytics](../group/value_stream_analytics/index.md)  | `issues_completed` |
+| Number of deploys | Total number of deploys to production. | [Merge Request Analytics](https://gitlab.com/gitlab-org/gitlab/-/analytics/merge_request_analytics) | [Merge request analytics](merge_request_analytics.md) | `deploys` |
+| Merge request throughput | The number of merge requests merged by month. | [Groups Productivity analytics](productivity_analytics.md), [Projects Merge Request Analytics](https://gitlab.com/gitlab-org/gitlab/-/analytics/merge_request_analytics)  | [Groups Productivity analytics](productivity_analytics.md) [Projects Merge request analytics](merge_request_analytics.md) | `merge_request_throughput` |
+| Critical vulnerabilities over time | Critical vulnerabilities over time in project or group | [Vulnerability report](https://gitlab.com/gitlab-org/gitlab/-/security/vulnerability_report) | [Vulnerability report](../application_security/vulnerability_report/index.md) | `vulnerability_critical` |
+| High vulnerabilities over time | High vulnerabilities over time in project or group | [Vulnerability report](https://gitlab.com/gitlab-org/gitlab/-/security/vulnerability_report) | [Vulnerability report](../application_security/vulnerability_report/index.md) | `vulnerability_high` |
diff --git a/doc/user/application_security/api_fuzzing/index.md b/doc/user/application_security/api_fuzzing/index.md
index b613b0cc33e..28e72816a99 100644
--- a/doc/user/application_security/api_fuzzing/index.md
+++ b/doc/user/application_security/api_fuzzing/index.md
@@ -101,8 +101,8 @@ a YAML snippet that you can paste in your GitLab CI/CD configuration.
 
 To generate an API Fuzzing configuration snippet:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. In the **API Fuzzing** row, select **Enable API Fuzzing**.
 1. Complete the fields. For details see [Available CI/CD variables](#available-cicd-variables).
 1. Select **Generate code snippet**.
@@ -2606,14 +2606,6 @@ deploy-test-target:
       - environment_url.txt
 ```
 
-<!--
-### Target Container
-
-The API Fuzzing template supports launching a docker container containing an API target using docker-in-docker.
-
-TODO
--->
-
 ### Use OpenAPI with an invalid schema
 
 There are cases where the document is autogenerated with an invalid schema or cannot be edited manually in a timely manner. In those scenarios, the API Fuzzing is able to perform a relaxed validation by setting the variable `FUZZAPI_OPENAPI_RELAXED_VALIDATION`. We recommend providing a fully compliant OpenAPI document to prevent unexpected behaviors.
diff --git a/doc/user/application_security/api_security/api_discovery/index.md b/doc/user/application_security/api_security/api_discovery/index.md
index 95b53249653..c7ae47a7083 100644
--- a/doc/user/application_security/api_security/api_discovery/index.md
+++ b/doc/user/application_security/api_security/api_discovery/index.md
@@ -7,7 +7,7 @@ type: reference, howto
 
 # API Discovery **(ULTIMATE)**
 
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/9302) in GitLab 15.9. The API Discovery feature is in [Beta](../../../../policy/alpha-beta-support.md).
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/9302) in GitLab 15.9. The API Discovery feature is in [Beta](../../../../policy/experiment-beta-support.md).
 
 API Discovery analyzes your application and produces an OpenAPI document describing the web APIs it exposes. This schema document can then be used by [DAST API](../../dast_api/index.md) or [API Fuzzing](../../api_fuzzing/index.md) to perform security scans of the web API.
 
diff --git a/doc/user/application_security/configuration/index.md b/doc/user/application_security/configuration/index.md
index d5a05477ddf..bbb7bf2f625 100644
--- a/doc/user/application_security/configuration/index.md
+++ b/doc/user/application_security/configuration/index.md
@@ -40,8 +40,8 @@ all security features are configured by default.
 
 To view a project's security configuration:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 
 Select **Configuration history** to see the `.gitlab-ci.yml` file's history.
 
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 7a82f98425a..042ed0190c4 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -220,7 +220,7 @@ The `CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN` CI/CD variable controls whether the
 findings related to programming languages. The languages supported depend on the
 [scanner used](#change-scanners):
 
-- [Trivy](https://aquasecurity.github.io/trivy/latest/docs/vulnerability/detection/language/).
+- [Trivy](https://aquasecurity.github.io/trivy/v0.41/docs/scanner/vulnerability/language/)
 - [Grype](https://github.com/anchore/grype#features).
 
 By default, the report only includes packages managed by the Operating System (OS) package manager
diff --git a/doc/user/application_security/coverage_fuzzing/index.md b/doc/user/application_security/coverage_fuzzing/index.md
index 09370a9a7f5..b0571c8a6ca 100644
--- a/doc/user/application_security/coverage_fuzzing/index.md
+++ b/doc/user/application_security/coverage_fuzzing/index.md
@@ -46,18 +46,20 @@ You can use the following fuzzing engines to test the specified languages.
 | Go                                          | [go-fuzz (libFuzzer support)](https://github.com/dvyukov/go-fuzz)                                    | [go-fuzzing-example](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/go-fuzzing-example)                 |
 | Swift                                       | [libFuzzer](https://github.com/apple/swift/blob/master/docs/libFuzzerIntegration.md)                 | [swift-fuzzing-example](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/swift-fuzzing-example)           |
 | Rust                                        | [cargo-fuzz (libFuzzer support)](https://github.com/rust-fuzz/cargo-fuzz)                            | [rust-fuzzing-example](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/rust-fuzzing-example)             |
-| Java                                        | [Javafuzz](https://gitlab.com/gitlab-org/security-products/analyzers/fuzzers/javafuzz) (recommended) | [javafuzz-fuzzing-example](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/javafuzz-fuzzing-example)     |
+| Java (Maven only)<sup>1</sup>               | [Javafuzz](https://gitlab.com/gitlab-org/security-products/analyzers/fuzzers/javafuzz) (recommended) | [javafuzz-fuzzing-example](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/javafuzz-fuzzing-example)     |
 | Java                                        | [JQF](https://github.com/rohanpadhye/JQF) (not preferred)                                            | [jqf-fuzzing-example](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/java-fuzzing-example)              |
 | JavaScript                                  | [`jsfuzz`](https://gitlab.com/gitlab-org/security-products/analyzers/fuzzers/jsfuzz)                 | [jsfuzz-fuzzing-example](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/jsfuzz-fuzzing-example)         |
 | Python                                      | [`pythonfuzz`](https://gitlab.com/gitlab-org/security-products/analyzers/fuzzers/pythonfuzz)         | [pythonfuzz-fuzzing-example](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/pythonfuzz-fuzzing-example) |
 | AFL (any language that works on top of AFL) | [AFL](https://lcamtuf.coredump.cx/afl/)                                                              | [afl-fuzzing-example](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/afl-fuzzing-example)               |
 
+1. Support for Gradle is planned in [issue 409764](https://gitlab.com/gitlab-org/gitlab/-/issues/409764).
+
 ## Confirm status of coverage-guided fuzz testing
 
 To confirm the status of coverage-guided fuzz testing:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. In the **Coverage Fuzzing** section the status is:
    - **Not configured**
    - **Enabled**
@@ -170,8 +172,8 @@ artifacts files you can download from the CI/CD pipeline. Also, a project member
 
 To view details of the corpus registry:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. In the **Coverage Fuzzing** section, select **Manage corpus**.
 
 ### Create a corpus in the corpus registry
@@ -198,8 +200,8 @@ provided by the `COVFUZZ_CORPUS_NAME` variable. The corpus is updated on every p
 
 To upload an existing corpus file:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. In the **Coverage Fuzzing** section, select **Manage corpus**.
 1. Select **New corpus**.
 1. Complete the fields.
@@ -225,7 +227,7 @@ Prerequisites:
 
 ## Coverage-guided fuzz testing report
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/220062) in GitLab 13.3 as an [Experiment](../../../policy/alpha-beta-support.md#experiment).
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/220062) in GitLab 13.3 as an [Experiment](../../../policy/experiment-beta-support.md#experiment).
 
 For detailed information about the `gl-coverage-fuzzing-report.json` file's format, read the
 [schema](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/coverage-fuzzing-report-format.json).
diff --git a/doc/user/application_security/dast/proxy-based.md b/doc/user/application_security/dast/proxy-based.md
index f65501712cc..499efd3f60d 100644
--- a/doc/user/application_security/dast/proxy-based.md
+++ b/doc/user/application_security/dast/proxy-based.md
@@ -89,8 +89,8 @@ In this method you manually edit the existing `.gitlab-ci.yml` file. Use this me
 
 To include the DAST template:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **CI/CD > Editor**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Build > Pipeline editor**.
 1. Copy and paste the following to the bottom of the `.gitlab-ci.yml` file.
 
    To use the DAST stable template:
@@ -156,8 +156,8 @@ snippet is created that you paste into the `.gitlab-ci.yml` file.
 
 To configure DAST using the UI:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security & Compliance > Configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. In the **Dynamic Application Security Testing (DAST)** section, select **Enable DAST** or
    **Configure DAST**.
 1. Select the desired **Scanner profile**, or select **Create scanner profile** and save a
@@ -548,8 +548,8 @@ The on-demand DAST scan runs and the project's dashboard shows the results.
 
 To run a saved on-demand scan:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security & Compliance > On-demand Scans**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > On-demand scans**.
 1. Select the **Scan library** tab.
 1. In the scan's row, select **Run scan**.
 
@@ -567,8 +567,8 @@ The on-demand DAST scan runs, and the project's dashboard shows the results.
 
 To schedule a scan:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security & Compliance > On-demand Scans**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > On-demand scans**.
 1. Select **New scan**.
 1. Complete the **Scan name** and **Description** text boxes.
 1. In GitLab 13.10 and later, from the **Branch** dropdown list, select the desired branch.
@@ -715,8 +715,8 @@ Validating a site is required to run an active scan.
 
 To validate a site profile:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security & Compliance > Configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. In the **Dynamic Application Security Testing (DAST)** section, select **Manage profiles**.
 1. Select the **Site Profiles** tab.
 1. In the profile's row, select **Validate**.
@@ -752,8 +752,8 @@ page.
 
 To retry a site profile's failed validation:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security & Compliance > Configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. In the **Dynamic Application Security Testing (DAST)** section, select **Manage profiles**.
 1. Select the **Site Profiles** tab.
 1. In the profile's row, select **Retry validation**.
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index c510be55981..df9e1d72dba 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -578,8 +578,8 @@ always take the latest dependency scanning artifact available.
 
 To enable Dependency Scanning in a project, you can create a merge request:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. In the **Dependency Scanning** row, select **Configure with a merge request**.
 1. Review and merge the merge request to enable Dependency Scanning.
 
@@ -864,7 +864,7 @@ Here's an example dependency scanning report:
 
 ### CycloneDX Software Bill of Materials
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/350509) in GitLab 14.8 in [Beta](../../../policy/alpha-beta-support.md#beta).
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/350509) in GitLab 14.8 in [Beta](../../../policy/experiment-beta-support.md#beta).
 > - Generally available in GitLab 15.7.
 
 In addition to the [JSON report file](#reports-json-format), the [Gemnasium](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium)
diff --git a/doc/user/application_security/iac_scanning/index.md b/doc/user/application_security/iac_scanning/index.md
index 48b2b8c1f1a..8e2f54fed44 100644
--- a/doc/user/application_security/iac_scanning/index.md
+++ b/doc/user/application_security/iac_scanning/index.md
@@ -116,10 +116,13 @@ that you can download and analyze.
 
 ### Enable IaC Scanning via an automatic merge request
 
+NOTE:
+The **Configure with a merge request** button been temporarily disabled due to a known issue. For details, see [merge request 83757](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83757).
+
 To enable IaC Scanning in a project, you can create a merge request:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. In the **Infrastructure as Code (IaC) Scanning** row, select **Configure with a merge request**.
 1. Review and merge the merge request to enable IaC Scanning.
 
diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md
index a3c512a813c..8bbe4db62a9 100644
--- a/doc/user/application_security/index.md
+++ b/doc/user/application_security/index.md
@@ -104,6 +104,7 @@ The following vulnerability scanners and their databases are regularly updated:
 | [Container Scanning](container_scanning/index.md)            | A job runs on a daily basis to build new images with the latest vulnerability database updates from the upstream scanner. GitLab monitors this job through an internal alert that tells the engineering team when the database becomes more than 48 hours old. For more information, see the [Vulnerabilities database update](container_scanning/index.md#vulnerabilities-database). |
 | [Dependency Scanning](dependency_scanning/index.md)          | Relies on the [GitLab Advisory Database](https://gitlab.com/gitlab-org/security-products/gemnasium-db). It is updated on a daily basis using [data from NVD, the `ruby-advisory-db` and the GitHub Advisory Database as data sources](https://gitlab.com/gitlab-org/security-products/gemnasium-db/-/blob/master/SOURCES.md). See our [current measurement of time from CVE being issued to our product being updated](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). |
 | [Dynamic Application Security Testing (DAST)](dast/index.md) | The scanning engine is updated on a periodic basis. See the [version of the underlying tool `zaproxy`](https://gitlab.com/gitlab-org/security-products/dast/blob/main/Dockerfile#L1). The scanning rules are downloaded at scan runtime. |
+| [Secret Detection](secret_detection/index.md#detected-secrets) | GitLab maintains the [detection rules](secret_detection/index.md#detected-secrets) and [accepts community contributions](secret_detection/index.md#adding-new-patterns). The scanning engine is updated at least once per month if a relevant update is available. |
 | [Static Application Security Testing (SAST)](sast/index.md)  | The source of scan rules depends on which [analyzer](sast/analyzers.md) is used for each [supported programming language](sast/index.md#supported-languages-and-frameworks). GitLab maintains a ruleset for the Semgrep-based analyzer and updates it regularly based on internal research and user feedback. For other analyzers, the ruleset is sourced from the upstream open-source scanner. Each analyzer is updated at least once per month if a relevant update is available. |
 
 In versions of GitLab that use the same major version of the analyzer, you do not have to update
@@ -498,14 +499,12 @@ GitLab provides two methods of accomplishing this, each with advantages and disa
   are recommended when:
 
   - Scan execution enforcement is required for DAST which uses a DAST site or scan profile.
-  - Scan execution enforcement is required for SAST, Secret Detection, Dependency Scanning, or Container Scanning with project-specific
+  - Scan execution enforcement is required for SAST, SAST IaC, Secret Detection, Dependency Scanning, or Container Scanning with project-specific
 variable customizations. To accomplish this, users must create a separate security policy per project.
   - Scans are required to run on a regular, scheduled cadence.
 
 - Either solution can be used equally well when:
 
-  - Scan execution enforcement is required for SAST or Secret Detection when custom rulesets are not
-    used.
   - Scan execution enforcement is required for Container Scanning with no project-specific variable
     customizations.
 
@@ -513,7 +512,7 @@ Additional details about the differences between the two solutions are outlined
 
 | | Compliance Framework Pipelines | Scan Execution Policies |
 | ------ | ------ | ------ |
-| **Flexibility** | Supports anything that can be done in a CI file. | Limited to only the items for which GitLab has explicitly added support. DAST, SAST, Secret Detection, Dependency Scanning, and Container Scanning scans are supported. |
+| **Flexibility** | Supports anything that can be done in a CI file. | Limited to only the items for which GitLab has explicitly added support. DAST, SAST, SAST IaC, Secret Detection, Dependency Scanning, and Container Scanning scans are supported. |
 | **Usability** | Requires knowledge of CI YAML. | Follows a `rules` and `actions`-based YAML structure. |
 | **Inclusion in CI pipeline** | The compliance pipeline is executed instead of the project's `.gitlab-ci.yml` file. To include the project's `.gitlab-ci.yml` file, use an `include` statement. Defined variables aren't allowed to be overwritten by the included project's YAML file. | Forced inclusion of a new job into the CI pipeline. DAST jobs that must be customized on a per-project basis can have project-level Site Profiles and Scan Profiles defined. To ensure separation of duties, these profiles are immutable when referenced in a scan execution policy. All jobs can be customized as part of the security policy itself with the same variables that are usually available to the CI job. |
 | **Schedulable** | Can be scheduled through a scheduled pipeline on the group. | Can be scheduled natively through the policy configuration itself. |
diff --git a/doc/user/application_security/policies/index.md b/doc/user/application_security/policies/index.md
index 0d821f8e47c..bd3da0b5913 100644
--- a/doc/user/application_security/policies/index.md
+++ b/doc/user/application_security/policies/index.md
@@ -58,8 +58,8 @@ to select, edit, and unlink a security policy project.
 As a project owner, take the following steps to create or edit an association between your current
 project and a project that you would like to designate as the security policy project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Policies**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Policies**.
 1. Select **Edit Policy Project**, and search for and select the
    project you would like to link from the dropdown list.
 1. Select **Save**.
@@ -82,8 +82,8 @@ policies for all available environments. You can check a
 policy's information (for example, description or enforcement
 status), and create and edit deployed policies:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Policies**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Policies**.
 
 ![Policies List Page](img/policies_list_v15_1.png)
 
@@ -93,8 +93,8 @@ status), and create and edit deployed policies:
 
 You can use the policy editor to create, edit, and delete policies:
 
-1. On the top bar, select **Main menu > Projects** and find your group.
-1. On the left sidebar, select **Security and Compliance > Policies**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Policies**.
    - To create a new policy, select **New policy** which is located in the **Policies** page's header.
      You can then select which type of policy to create.
    - To edit an existing policy, select **Edit policy** in the selected policy drawer.
@@ -150,5 +150,6 @@ The workaround is to amend your group or instance push rules to allow branches f
 - When scheduling pipelines, keep in mind that CRON scheduling is based on UTC on GitLab SaaS and is based on your server time for self managed instances. When testing new policies, it may appear pipelines are not running properly when in fact they are scheduled in your server's timezone.
 - When enforcing scan execution policies, the target project's pipeline is triggered by the user who last updated the security policy project's `policy.yml` file. The user must have permission to trigger the pipeline in the project for the policy to be enforced, and the pipeline to run. Work to address this is being tracked in [issue 394958](https://gitlab.com/gitlab-org/gitlab/-/issues/394958).
 - You should not link a security policy project to a development project and to the group or sub-group the development project belongs to at the same time. Linking this way will result in approval rules from the Scan Result Policy not being applied to merge requests in the development project.
+- When creating a Scan Result Policy, neither the array `severity_levels` nor the array `vulnerability_states` in the [scan_finding rule](../policies/scan-result-policies.md#scan_finding-rule-type) can be left empty; for a working rule, at least one entry must exist.
 
 If you are still experiencing issues, you can [view recent reported bugs](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=popularity&state=opened&label_name%5B%5D=group%3A%3Asecurity%20policies&label_name%5B%5D=type%3A%3Abug&first_page_size=20) and raise new unreported issues.
diff --git a/doc/user/application_security/policies/scan-execution-policies.md b/doc/user/application_security/policies/scan-execution-policies.md
index 61671efab63..e18d4d1787e 100644
--- a/doc/user/application_security/policies/scan-execution-policies.md
+++ b/doc/user/application_security/policies/scan-execution-policies.md
@@ -78,7 +78,8 @@ This rule enforces the defined actions whenever the pipeline runs for a selected
 | Field | Type | Possible values | Description |
 |-------|------|-----------------|-------------|
 | `type` | `string` | `pipeline` | The rule's type. |
-| `branches` | `array` of `string` | `*` or the branch's name | The branch the given policy applies to (supports wildcard). |
+| `branches` | `array` of `string` | `*` or the branch's name | The branch the given policy applies to (supports wildcard). Cannot be used with the `branch_type` field. |
+| `branch_type` | `string` | `default`, `protected` or `all` | The types of branches the given policy applies to. Cannot be used with the `branches` field. |
 
 ## `schedule` rule type
 
@@ -87,7 +88,8 @@ This rule enforces the defined actions and schedules a scan on the provided date
 | Field      | Type | Possible values | Description |
 |------------|------|-----------------|-------------|
 | `type`     | `string` | `schedule` | The rule's type. |
-| `branches` | `array` of `string` | `*` or the branch's name | The branch the given policy applies to (supports wildcard). This field is required if the `agents` field is not set. |
+| `branches` | `array` of `string` | `*` or the branch's name | The branch the given policy applies to (supports wildcard). This field is required if the `agents` field is not set. Cannot be used with the `branch_type` field. |
+| `branch_type` | `string` | `default`, `protected` or `all` | The types of branches the given policy applies to. Cannot be used with the `branches` field. |
 | `cadence`  | `string` | CRON expression (for example, `0 0 * * *`) | A whitespace-separated string containing five fields that represents the scheduled time. Minimum of 15 minute intervals when used together with the `branches` field. |
 | `agents`   | `object` | | The name of the [GitLab agents](../../clusters/agent/index.md) where [Operational Container Scanning](../../clusters/agent/vulnerabilities.md) runs. The object key is the name of the Kubernetes agent configured for your project in GitLab. This field is required if the `branches` field is not set. |
 
diff --git a/doc/user/application_security/policies/scan-result-policies.md b/doc/user/application_security/policies/scan-result-policies.md
index ecbbf4703b0..d8cd984ad40 100644
--- a/doc/user/application_security/policies/scan-result-policies.md
+++ b/doc/user/application_security/policies/scan-result-policies.md
@@ -15,6 +15,9 @@ findings of one or more security scan jobs. Scan result policies are evaluated a
 NOTE:
 Scan result policies are applicable only to [protected](../../project/protected_branches.md) target branches.
 
+NOTE:
+When a protected branch is created or deleted, the policy approval rules synchronize, with a delay of 1 minute.
+
 The following video gives you an overview of GitLab scan result policies:
 
 <div class="video-fallback">
diff --git a/doc/user/application_security/sast/analyzers.md b/doc/user/application_security/sast/analyzers.md
index f52ff7f9a55..fecadaa737d 100644
--- a/doc/user/application_security/sast/analyzers.md
+++ b/doc/user/application_security/sast/analyzers.md
@@ -77,7 +77,7 @@ Work to remove language-specific analyzers and replace them with the Semgrep-bas
 
 You can choose to disable the other analyzers early and use Semgrep-based scanning for supported languages before the default behavior changes. If you do so:
 
-- You enjoy significantly faster scanning, reduced CI minutes usage, and more customizable scanning rules.
+- You enjoy significantly faster scanning, reduced compute quota usage, and more customizable scanning rules.
 - However, vulnerabilities previously reported by language-specific analyzers are reported again under certain conditions, including if you've dismissed the vulnerabilities before. The system behavior depends on:
   - whether you've excluded the Semgrep-based analyzer from running in the past.
   - which analyzer first discovered the vulnerabilities shown in the project's [Vulnerability Report](../vulnerability_report/index.md).
diff --git a/doc/user/application_security/sast/customize_rulesets.md b/doc/user/application_security/sast/customize_rulesets.md
index ddf8db4e489..385c5ffbae1 100644
--- a/doc/user/application_security/sast/customize_rulesets.md
+++ b/doc/user/application_security/sast/customize_rulesets.md
@@ -79,6 +79,37 @@ To create the ruleset configuration file:
 1. Create a `.gitlab` directory at the root of your project, if one doesn't already exist.
 1. Create a file named `sast-ruleset.toml` in the `.gitlab` directory.
 
+## Specify a remote configuration file
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/393452) in 16.1.
+
+You can set a [CI/CD variable](../../../ci/variables/index.md) to use a ruleset configuration file that's stored outside of the current repository.
+This can help you apply the same rules across multiple projects.
+
+The `SAST_RULESET_GIT_REFERENCE` variable uses a format similar to
+[Git URLs](https://git-scm.com/docs/git-clone#_git_urls) for specifying a project URI,
+optional authentication, and optional Git SHA. The variable uses the following format:
+
+```plaintext
+[<AUTH_USER>[:<AUTH_PASSWORD>]@]<PROJECT_PATH>[@<GIT_SHA>]
+```
+
+NOTE:
+If a project has a `.gitlab/sast-ruleset.toml` file committed, that local configuration takes precedence and the file from `SAST_RULESET_GIT_REFERENCE` isn't used.
+
+The following example [enables SAST](index.md#configure-sast-in-your-cicd-yaml) and uses a shared ruleset customization file.
+In this example, the file is committed on the default branch of `example-ruleset-project` at the path `.gitlab/sast-ruleset.toml`.
+
+```yaml
+include:
+  - template: Jobs/SAST.gitlab-ci.yml
+
+variables:
+  SAST_RULESET_GIT_REFERENCE: "gitlab.com/example-group/example-ruleset-project"
+```
+
+See [specify a private remote configuration example](#specify-a-private-remote-configuration) for advanced usage.
+
 ## Schema
 
 ### The top-level section
@@ -352,23 +383,23 @@ The syntax used for the `value` follows the [njsscan config format](https://gith
 ---
 - nodejs-extensions:
   - .js
-  
+
   template-extensions:
   - .new
   - .hbs
   - ''
-  
+
   ignore-filenames:
   - skip.js
-  
+
   ignore-paths:
   - __MACOSX
   - skip_dir
   - node_modules
-  
+
   ignore-extensions:
   - .hbs
-  
+
   ignore-rules:
   - regex_injection_dos
   - pug_jade_template
@@ -560,3 +591,20 @@ rules:
   languages:
     - "go"
 ```
+
+### Specify a private remote configuration
+
+The following example [enables SAST](index.md#configure-sast-in-your-cicd-yaml) and uses a shared ruleset customization file. The file is:
+
+- Downloaded from a private project that requires authentication, by using a [Group Access Token](../../group/settings/group_access_tokens.md).
+- Checked out at a specific Git commit SHA instead of the default branch.
+
+See [group access tokens](../../group/settings/group_access_tokens.md#bot-users-for-groups) for how to find the username associated with a group token.
+
+```yaml
+include:
+  - template: Security/SAST.gitlab-ci.yml
+
+variables:
+  SAST_RULESET_GIT_REFERENCE: "group_2504721_bot_7c9311ffb83f2850e794d478ccee36f5:glpat-1234567@gitlab.com/example-group/example-ruleset-project@c8ea7e3ff126987fb4819cc35f2310755511c2ab"
+```
diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md
index 64c0f3440c5..2008375d2a2 100644
--- a/doc/user/application_security/sast/index.md
+++ b/doc/user/application_security/sast/index.md
@@ -301,8 +301,8 @@ successfully, and an error may occur.
 
 To enable and configure SAST with customizations:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. If the project does not have a `.gitlab-ci.yml` file, select **Enable SAST** in the Static
    Application Security Testing (SAST) row, otherwise select **Configure SAST**.
 1. Enter the custom SAST values.
@@ -328,8 +328,8 @@ successfully, and an error may occur.
 
 To enable and configure SAST with default settings:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance** > **Configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. In the SAST section, select **Configure with a merge request**.
 1. Review and merge the merge request to enable SAST.
 
@@ -617,6 +617,7 @@ flags are added to the scanner's CLI options.
 |------------------------------------------------------------------------------|--------------------|------------------------------------------------------------------------------|
 | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) | `--max-memory`     | Sets the maximum system memory to use when running a rule on a single file. Measured in MB. |
 | [Flawfinder](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) | `--neverignore` | Never ignore security issues, even if they have an “ignore” directive in a comment. Adding this option is likely to result in the analyzer detecting additional vulnerability findings which cannot be automatically resolved. |
+| [SpotBugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) | `-effort` | Sets the analysis effort level. Valid values are `min`, `less`, `more` and `max`, defined in increasing order of scan's precision and ability to detect more vulnerabilities. Default value is set to `max` which may require more memory and time to complete the scan, depending on the project's size. In case you face memory or performance issues, you may reduce the analysis effort level to a lower value. For example: `-effort less`. |
 
 #### Custom CI/CD variables
 
@@ -868,7 +869,7 @@ This occurs when Flawfinder encounters an invalid UTF-8 character. To fix this,
 
 ### Semgrep slowness, unexpected results, or other errors
 
-If Semgrep is slow, reports too many false positives or false negatives, crashes, fails, or is otherwise broken, see the Semgrep docs for [troubleshooting GitLab SAST](https://semgrep.dev/docs/troubleshooting/gitlab-sast/).
+If Semgrep is slow, reports too many false positives or false negatives, crashes, fails, or is otherwise broken, see the Semgrep docs for [troubleshooting GitLab SAST](https://semgrep.dev/docs/troubleshooting/semgrep-ci/#troubleshooting-gitlab-sast).
 
 ### SAST job fails with message `strconv.ParseUint: parsing "0.0": invalid syntax`
 
diff --git a/doc/user/application_security/secret_detection/automatic_response.md b/doc/user/application_security/secret_detection/automatic_response.md
index a898a63e33b..8f78d36976b 100644
--- a/doc/user/application_security/secret_detection/automatic_response.md
+++ b/doc/user/application_security/secret_detection/automatic_response.md
@@ -22,6 +22,7 @@ GitLab supports automatic response for the following types of secrets:
 | ----- | --- | --- | --- |
 | GitLab [Personal access tokens](../../profile/personal_access_tokens.md) | Immediately revoke token, send email to owner | ✅ | ✅ [15.9 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/371658) |
 | Amazon Web Services (AWS) [IAM access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) | Notify AWS | ✅ | ⚙ |
+| Google Cloud [service account keys](https://cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys), [API keys](https://cloud.google.com/docs/authentication/api-keys), and [OAuth client secrets](https://support.google.com/cloud/answer/6158849#rotate-client-secret) | Notify Google Cloud | ✅ | ⚙ |
 
 **Component legend**
 
diff --git a/doc/user/application_security/secret_detection/img/secret_detection_v13_2.png b/doc/user/application_security/secret_detection/img/secret_detection_v13_2.png
deleted file mode 100644
index 4aa7dd83c8d..00000000000
--- a/doc/user/application_security/secret_detection/img/secret_detection_v13_2.png
+++ /dev/null
diff --git a/doc/user/application_security/secret_detection/index.md b/doc/user/application_security/secret_detection/index.md
index 5a1dcc840ca..2e6de222ec3 100644
--- a/doc/user/application_security/secret_detection/index.md
+++ b/doc/user/application_security/secret_detection/index.md
@@ -107,7 +107,8 @@ Secret Detection can detect if a secret was added in one commit and removed in a
 
   In a merge request, Secret Detection scans every commit made on the source branch. To use this
   feature, you must use the [`latest` Secret Detection template](#templates), as it supports
-  [merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md).
+  [merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md). Secret Detection's
+  results are only available after the pipeline is completed.
 
 ## Templates
 
@@ -116,7 +117,7 @@ provided with GitLab upgrades, allowing you to benefit from any improvements and
 
 Available templates:
 
-- [`Secret-Detection.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml): Stable version of the Secret Detection CI/CD template.
+- [`Secret-Detection.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml): Stable, default version of the Secret Detection CI/CD template.
 - [`Secret-Detection.latest.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.latest.gitlab-ci.yml): Latest version of the Secret Detection template.
 
 WARNING:
@@ -154,13 +155,13 @@ To enable Secret Detection, either:
 This method requires you to manually edit the existing `.gitlab-ci.yml` file. Use this method if
 your GitLab CI/CD configuration file is complex.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **CI/CD > Editor**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Build > Pipeline editor**.
 1. Copy and paste the following to the bottom of the `.gitlab-ci.yml` file:
 
    ```yaml
    include:
-     - template: Jobs/Secret-Detection.gitlab-ci.yml
+     - template: Security/Secret-Detection.gitlab-ci.yml
    ```
 
 1. Select the **Validate** tab, then select **Validate pipeline**.
@@ -187,8 +188,8 @@ error may occur. In that case, use the [manual](#edit-the-gitlab-ciyml-file-manu
 
 To enable Secret Detection:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. In the **Secret Detection** row, select **Configure with a merge request**.
 1. Optional. Complete the fields.
 1. Select **Create merge request**.
@@ -495,6 +496,36 @@ path = "/gitleaks.toml"
   ]
 ```
 
+## Specify a remote configuration file
+
+Projects can be configured with a [CI/CD variable](../../../ci/variables/index.md) in order
+to specify a ruleset configuration outside of the current repository.
+
+The `SECRET_DETECTION_RULESET_GIT_REFERENCE` variable uses an SCP-style syntax for specifying a URI,
+optional authentication, and optional Git SHA. The variable uses the following format:
+
+```plaintext
+<AUTH_USER>:<AUTH_PASSWORD>@<PROJECT_PATH>@<GIT_SHA>
+```
+
+NOTE:
+Loading local project configuration takes precedence over `SECRET_DETECTION_RULESET_GIT_REFERENCE` values.
+
+The following example includes the Secret Detection template in a project to be scanned and specifies
+the `SECRET_DETECTION_RULESET_GIT_REFERENCE` variable for referencing a separate project configuration.
+
+```yaml
+include:
+  - template: Jobs/Secret-Detection.gitlab-ci.yml
+
+variables:
+  SECRET_DETECTION_RULESET_GIT_REFERENCE: "gitlab.com/example-group/example-ruleset-project"
+```
+
+For more information on the syntax of remote configurations, see the
+[specify a private remote configuration example](../sast/customize_rulesets.md#specify-a-private-remote-configuration)
+on the SAST customize rulesets page.
+
 ## Running Secret Detection in an offline environment **(PREMIUM SELF)**
 
 An offline environment has limited, restricted, or intermittent access to external resources through
@@ -575,7 +606,9 @@ variable, or as a CI/CD variable.
 
 ## Warnings for potential leaks in text content
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/368434) in GitLab 15.11.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/368434) in GitLab 15.11.
+> - Detection of personal access tokens with a custom prefix was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/411146)
+in GitLab 16.1. GitLab self-managed only.
 
 When you create an issue, propose a merge request, or write a comment, you might accidentally post a sensitive value.
 For example, you might paste in the details of an API request or an environment variable that contains an authentication token.
@@ -588,6 +621,7 @@ The check is always on; you don't have to set it up.
 Your text is checked for the following secret types:
 
 - GitLab [personal access tokens](../../../security/token_overview.md#personal-access-tokens)
+  - If a [personal access token prefix](../../../user/admin_area/settings/account_and_limit_settings.md#personal-access-token-prefix) has been configured, a token using this prefix is checked.
 - GitLab [feed tokens](../../../security/token_overview.md#feed-token)
 
 This feature is separate from Secret Detection scanning, which checks your Git repository for leaked secrets.
diff --git a/doc/user/application_security/security_dashboard/index.md b/doc/user/application_security/security_dashboard/index.md
index e6cb4cef4b2..e28c06236aa 100644
--- a/doc/user/application_security/security_dashboard/index.md
+++ b/doc/user/application_security/security_dashboard/index.md
@@ -66,8 +66,8 @@ Project Security Dashboards show statistics for all vulnerabilities with a curre
 
 To view total number of vulnerabilities over time:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security Dashboard**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security dashboard**.
 1. Filter and search for what you need.
    - To filter the chart by severity, select the legend name.
    - To view a specific time frame, use the time range handles (**{scroll-handle}**).
@@ -79,8 +79,8 @@ To view total number of vulnerabilities over time:
 
 To download an SVG image of the vulnerabilities chart:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security dashboard**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security dashboard**.
 1. Select **Save chart as an image** (**{download}**).
 
 ## View vulnerabilities over time for a group
@@ -90,8 +90,8 @@ branches of projects in a group and its subgroups.
 
 To view vulnerabilities over time for a group:
 
-1. On the top bar, select **Main menu > Groups** and select a group.
-1. Select **Security > Security Dashboard**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Security > Security dashboard**.
 1. Hover over the chart to get more details about vulnerabilities.
    - You can display the vulnerability trends over a 30, 60, or 90-day time frame (the default is 90 days).
    - To view aggregated data beyond a 90-day time frame, use the
@@ -104,8 +104,8 @@ Use the group Security Dashboard to view the security status of projects.
 
 To view project security status for a group:
 
-1. On the top bar, select **Main menu > Groups** and select a group.
-1. Select **Security > Security Dashboard**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Security dashboard**.
 
 Each project is assigned a letter [grade](#project-vulnerability-grades) according to the highest-severity open vulnerability.
 Dismissed or resolved vulnerabilities are excluded. Each project can receive only one letter grade and appears only once
@@ -140,14 +140,20 @@ The Security Center includes:
 
 ### View the Security Center
 
-To view the Security Center, on the top bar, select **Main menu > Security**.
+To view the Security Center:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Your work**.
+1. Select **Security > Security dashboard**.
 
 ### Add projects to the Security Center
 
 To add projects to the Security Center:
 
-1. On the top bar, select **Main menu > Security**.
-1. On the left sidebar, select **Settings**, or select **Add projects**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Your work**.
+1. Expand **Security**.
+1. Select **Settings**.
 1. Use the **Search your projects** text box to search for and select projects.
 1. Select **Add projects**.
 
diff --git a/doc/user/application_security/vulnerabilities/index.md b/doc/user/application_security/vulnerabilities/index.md
index 18485f83fe7..39d8e28e564 100644
--- a/doc/user/application_security/vulnerabilities/index.md
+++ b/doc/user/application_security/vulnerabilities/index.md
@@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Vulnerability Page **(ULTIMATE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13561) in GitLab 13.0.
-
 Each vulnerability in a project has a vulnerability page containing details of the vulnerability,
 including:
 
@@ -35,8 +33,9 @@ A vulnerability's status can be:
 - **Dismissed**: A user has seen this vulnerability and dismissed it because it is not accurate or
   otherwise not to be resolved. Dismissed vulnerabilities are ignored if detected in subsequent
   scans.
-- **Resolved**: The vulnerability has been fixed or is no longer present. Resolved vulnerabilities
-  that are reintroduced and detected by subsequent scans have a _new_ vulnerability record created.
+- **Resolved**: The vulnerability has been fixed or is no longer present. If a resolved
+  vulnerability is reintroduced and detected again, its record is reinstated and its status set to
+  detected.
 
 ## Vulnerability dismissal reasons
 
@@ -56,8 +55,8 @@ When dismissing a vulnerability, one of the following reasons must be chosen to
 
 To change a vulnerability's status from its Vulnerability Page:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Vulnerability report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Vulnerability report**.
 1. Select the vulnerability's description.
 1. From the **Status** dropdown list select a status, then select **Change status**.
 
@@ -86,8 +85,8 @@ that when Jira integration is enabled, the GitLab issue feature is not available
 
 To create a GitLab issue for a vulnerability:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Vulnerability report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Vulnerability report**.
 1. Select the vulnerability's description.
 1. Select **Create issue**.
 
@@ -96,9 +95,6 @@ The issue is then opened so you can take further action.
 
 ### Create a Jira issue for a vulnerability
 
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4677) in GitLab 13.9.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/283850) in GitLab 13.12.
-
 Prerequisites:
 
 - [Enable Jira integration](../../../integration/jira/index.md). The **Enable Jira issue creation
@@ -108,8 +104,8 @@ Prerequisites:
 
 To create a Jira issue for a vulnerability:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Vulnerability report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Vulnerability report**.
 1. Select the vulnerability's description.
 1. Select **Create Jira issue**.
 1. If you're not already logged in to Jira, sign in.
@@ -141,8 +137,8 @@ Be aware of the following conditions between a vulnerability and a linked issue:
 
 To link a vulnerability to existing issues:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Vulnerability report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Vulnerability report**.
 1. Select the vulnerability's description.
 1. In the **Linked issues** section, select the plus icon (**{plus}**).
 1. For each issue to be linked, either:
@@ -176,8 +172,8 @@ To resolve a vulnerability, you can either:
 
 To resolve the vulnerability with a merge request:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Vulnerability report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Vulnerability report**.
 1. Select the vulnerability's description.
 1. From the **Resolve with merge request** dropdown list, select **Resolve with merge request**.
 
@@ -188,8 +184,8 @@ Process the merge request according to your standard workflow.
 
 To manually apply the patch that GitLab generated for a vulnerability:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Vulnerability report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Vulnerability report**.
 1. Select the vulnerability's description.
 1. From the **Resolve with merge request** dropdown list, select **Download patch to resolve**.
 1. Ensure your local project has the same commit checked out that was used to generate the patch.
@@ -210,8 +206,8 @@ Security training helps your developers learn how to fix vulnerabilities. Develo
 
 To enable security training for vulnerabilities in your project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Security configuration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Security configuration**.
 1. On the tab bar, select **Vulnerability Management**.
 1. To enable a security training provider, turn on the toggle.
 
@@ -228,7 +224,7 @@ Vulnerabilities with a CWE are most likely to return a training result.
 
 To view the security training for a vulnerability:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Vulnerability report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Vulnerability report**.
 1. Select the vulnerability for which you want to view security training.
 1. Select **View training**.
diff --git a/doc/user/application_security/vulnerability_report/img/vulnerability_list_table_v13_9.png b/doc/user/application_security/vulnerability_report/img/vulnerability_list_table_v13_9.png
deleted file mode 100644
index bfde7cd6c80..00000000000
--- a/doc/user/application_security/vulnerability_report/img/vulnerability_list_table_v13_9.png
+++ /dev/null
diff --git a/doc/user/application_security/vulnerability_report/index.md b/doc/user/application_security/vulnerability_report/index.md
index 0826258de9e..78f8bbdb0c3 100644
--- a/doc/user/application_security/vulnerability_report/index.md
+++ b/doc/user/application_security/vulnerability_report/index.md
@@ -7,9 +7,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Vulnerability Report **(ULTIMATE)**
 
-The Vulnerability Report provides information about vulnerabilities from scans of the default branch. It contains cumulative results of all successful jobs, regardless of whether the pipeline was successful.
-
-The scan results from a pipeline are only ingested after all the jobs in the pipeline complete. Partial results for a pipeline with jobs in progress can be seen in the pipeline security tab.
+The Vulnerability Report provides information about vulnerabilities from scans of the default branch. It contains
+cumulative results of all successful jobs, regardless of whether the pipeline was successful. The scan results from a
+pipeline are only ingested after all the jobs in the pipeline complete.
 
 The report is available for users with the [correct role](../../permissions.md) on projects, groups, and the Security Center.
 
@@ -31,6 +31,11 @@ in that row:
 - False positive **{false-positive}**: The scanner determined this vulnerability to be a false
   positive.
 
+To open an issue created for a vulnerability, hover over the **Activity** entry, then select the link.
+The issue icon (**{issues}**) indicates the issue's status. If Jira issue support is enabled, the
+issue link found in the **Activity** entry links out to the issue in Jira. Unlike GitLab issues, the
+status of a Jira issue is not shown in the GitLab UI.
+
 ![Example project-level Vulnerability Report](img/project_level_vulnerability_report_v14_5.png)
 
 ## Project-level Vulnerability Report
@@ -47,8 +52,8 @@ At the project level, the Vulnerability Report also contains:
 
 To view the project-level vulnerability report:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Vulnerability report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Vulnerability report**.
 
 ## Vulnerability Report actions
 
@@ -57,7 +62,6 @@ From the Vulnerability Report you can:
 - [Filter the list of vulnerabilities](#filter-the-list-of-vulnerabilities).
 - [View more details about a vulnerability](#view-details-of-a-vulnerability).
 - [View vulnerable source location](#view-vulnerable-source-location) (if available).
-- [View an issue raised for a vulnerability](#view-issues-raised-for-a-vulnerability).
 - [Change the status of vulnerabilities](#change-status-of-vulnerabilities).
 - [Export details of vulnerabilities](#export-vulnerability-details).
 - [Sort vulnerabilities by date](#sort-vulnerabilities-by-date-detected).
@@ -72,7 +76,8 @@ The available filters are:
 
 <!-- vale gitlab.SubstitutionWarning = NO -->
 
-- **Status**: Detected, Confirmed, Dismissed, Resolved.
+- **Status**: Detected, Confirmed, Dismissed, Resolved. For details on what each status means, see
+  [vulnerability status values](../vulnerabilities/index.md#vulnerability-status-values).
 - **Severity**: Critical, High, Medium, Low, Info, Unknown.
 - **Tool**: For more details, see [Tool filter](#tool-filter).
 - **Project**: For more details, see [Project filter](#project-filter).
@@ -150,15 +155,6 @@ in the default branch.
 
 To view the relevant file, select the filename in the vulnerability's details.
 
-## View issues raised for a vulnerability
-
-The **Activity** column indicates the number of issues that have been created for the vulnerability.
-Hover over an **Activity** entry and select a link go to that issue. The status of whether the issue is open or closed also displays in the hover menu.
-
-![Display attached issues](img/vulnerability_list_table_v13_9.png)
-
-If Jira issue support is enabled, the issue link found in the Activity entry links out to the issue in Jira. Unlike GitLab issues, the status of whether a Jira issue is Open or Closed does not display in the GitLab UI.
-
 ## Change status of vulnerabilities
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292636) in GitLab 13.10, all statuses became selectable.
@@ -261,8 +257,8 @@ To undo this action, select a different status from the same menu.
 
 To add a new vulnerability finding from your project level Vulnerability Report page:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security and Compliance > Vulnerability Report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Vulnerability report**.
 1. Select **Submit vulnerability**.
 1. Complete the fields and submit the form.
 
diff --git a/doc/user/application_security/vulnerability_report/pipeline.md b/doc/user/application_security/vulnerability_report/pipeline.md
index 0e5bb5e10f7..a53e0a8970b 100644
--- a/doc/user/application_security/vulnerability_report/pipeline.md
+++ b/doc/user/application_security/vulnerability_report/pipeline.md
@@ -11,8 +11,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 To view vulnerabilities in a pipeline:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **CI/CD > Pipelines**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Build > Pipelines**.
 1. From the list, select the pipeline you want to check for vulnerabilities.
 1. Select the **Security** tab.
 
diff --git a/doc/user/asciidoc.md b/doc/user/asciidoc.md
index 6b642363dd6..f04fece7b76 100644
--- a/doc/user/asciidoc.md
+++ b/doc/user/asciidoc.md
@@ -244,9 +244,6 @@ pages, change the filename from `.adoc` to `.asciidoc`.
 
 ```plaintext
 include::basics.adoc[]
-
-// define -a allow-uri-read to allow content to be read from URI
-include::https://example.org/installation.adoc[]
 ```
 
 To guarantee good system performance and prevent malicious documents from causing
@@ -254,6 +251,14 @@ problems, GitLab enforces a maximum limit on the number of include directives
 processed in any one document. You can include up to 32 documents, which is
 inclusive of transitive dependencies.
 
+To use includes from separate pages or external URLs, enable the `allow-uri-read`
+in [application settings](../administration/wikis/index.md#allow-uri-includes-for-asciidoc).
+
+```plaintext
+// define application setting allow-uri-read to true to allow content to be read from URI
+include::https://example.org/installation.adoc[]
+```
+
 ### Blocks
 
 ```plaintext
diff --git a/doc/user/clusters/agent/ci_cd_workflow.md b/doc/user/clusters/agent/ci_cd_workflow.md
index 7a3f09f50ca..a0b42101dd5 100644
--- a/doc/user/clusters/agent/ci_cd_workflow.md
+++ b/doc/user/clusters/agent/ci_cd_workflow.md
@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) the `ci_access` attribute in GitLab 14.3.
 > - The ability to authorize groups was [introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) in GitLab 14.3.
 > - [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) to GitLab Free in 14.5.
-> - Support for Omnibus installations was [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5686) in GitLab 14.5.
+> - Support for Linux package installations was [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5686) in GitLab 14.5.
 > - The ability to switch between certificate-based clusters and agents was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335089) in GitLab 14.9. The certificate-based cluster context is always called `gitlab-deploy`.
 > - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80508) from _CI/CD tunnel_ to _CI/CD workflow_ in GitLab 14.9.
 
@@ -64,7 +64,7 @@ Authorization configuration can take one or two minutes to propagate.
 
 To authorize the agent to access the GitLab project where you keep Kubernetes manifests:
 
-1. On the top bar, select **Main menu > Projects** and find the project that contains the [agent configuration file](install/index.md#create-an-agent-configuration-file) (`config.yaml`).
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the project that contains the [agent configuration file](install/index.md#create-an-agent-configuration-file) (`config.yaml`).
 1. Edit the `config.yaml` file. Under the `ci_access` keyword, add the `projects` attribute.
 1. For the `id`, add the path to the project. Do not wrap the path in quotation marks.
 
@@ -89,7 +89,7 @@ Choose the context to run `kubectl` commands from your CI/CD scripts.
 
 To authorize the agent to access all of the GitLab projects in a group or subgroup:
 
-1. On the top bar, select **Main menu > Projects** and find the project that contains the [agent configuration file](install/index.md#create-an-agent-configuration-file) (`config.yaml`).
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the project that contains the [agent configuration file](install/index.md#create-an-agent-configuration-file) (`config.yaml`).
 1. Edit the `config.yaml` file. Under the `ci_access` keyword, add the `groups` attribute.
 1. For the `id`, add the path:
 
diff --git a/doc/user/clusters/agent/gitops/flux.md b/doc/user/clusters/agent/gitops/flux.md
index 98840080716..f0a681c1a5c 100644
--- a/doc/user/clusters/agent/gitops/flux.md
+++ b/doc/user/clusters/agent/gitops/flux.md
@@ -13,9 +13,13 @@ You can use Flux to:
 - Reconcile code changes with your deployments.
 - Manage your Flux installation itself with a bootstrap.
 
+You can use the agent for Kubernetes with Flux to:
+
+- Trigger immediate Git repository reconciliation.
+
 To get started, see the [Flux installation documentation](https://fluxcd.io/flux/installation).
 
-Support for Flux is in [Beta](../../../../policy/alpha-beta-support.md#beta).
+Support for Flux is in [Beta](../../../../policy/experiment-beta-support.md#beta).
 
 ## Bootstrap installation
 
@@ -34,3 +38,60 @@ write access to the source repositories.
 ## GitOps repository structure
 
 You should organize your repositories to meet the needs of your team. For detailed recommendations, see the Flux [repository structure documentation](https://fluxcd.io/flux/guides/repository-structure/).
+
+## Immediate Git repository reconciliation
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/392852) in GitLab 16.1.
+
+Usually, the Flux source controller reconciles Git repositories at configured intervals.
+This can cause delays between a `git push` and the reconciliation of the cluster state, and results in
+unnecessary pulls from GitLab.
+
+The agent for Kubernetes automatically detects Flux `GitRepository` objects that
+reference GitLab projects in the instance the agent is connected to,
+and configures a [`Receiver`](https://fluxcd.io/flux/components/notification/receiver/) for the instance.
+When the agent for Kubernetes detects a `git push`, the `Receiver` is triggered
+and Flux reconciles the cluster with any changes to the repository.
+
+To use immediate Git repository reconciliation, you must have a Kubernetes cluster that runs:
+
+- The agent for Kubernetes.
+- Flux `source-controller` and `notification-controller`.
+
+Immediate Git repository reconciliation can reduce the time between a push and reconciliation,
+but it doesn't guarantee that every `git push` event is received. You should still set
+[`GitRepository.spec.interval`](https://fluxcd.io/flux/components/source/gitrepositories/#interval)
+to an acceptable duration.
+
+### Custom webhook endpoints
+
+When the agent for Kubernetes calls the `Receiver` webhook,
+the agent defaults to `http://webhook-receiver.flux-system.svc.cluster.local`,
+which is also the default URL set by a Flux bootstrap installation. To configure a custom
+endpoint, set `flux.webhook_receiver_url` to a URL that the agent can resolve. For example:
+
+```yaml
+flux:
+  webhook_receiver_url: http://webhook-receiver.another-flux-namespace.svc.cluster.local
+```
+
+There is special handing for
+[service proxy URLs](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster-services/) configured
+in this format: `/api/v1/namespaces/[^/]+/services/[^/]+/proxy`. For example:
+
+```yaml
+flux:
+  webhook_receiver_url: /api/v1/namespaces/flux-system/services/http:webhook-receiver:80/proxy
+```
+
+In these cases, the agent for Kubernetes uses the available Kubernetes configuration
+and context to connect to the API endpoint.
+You can use this if you run an agent outside a cluster
+and you haven't [configured an `Ingress`](https://fluxcd.io/flux/guides/webhook-receivers/#expose-the-webhook-receiver)
+for the Flux notification controller.
+
+WARNING:
+You should configure only trusted service proxy URLs.
+When you provide a service proxy URL,
+the agent for Kubernetes sends typical Kubernetes API requests which include
+the credentials necessary to authenticate with the API service.
diff --git a/doc/user/clusters/agent/gitops/flux_tutorial.md b/doc/user/clusters/agent/gitops/flux_tutorial.md
index bdb772ac14e..c6c9ed9e373 100644
--- a/doc/user/clusters/agent/gitops/flux_tutorial.md
+++ b/doc/user/clusters/agent/gitops/flux_tutorial.md
@@ -6,31 +6,28 @@ info: A tutorial using Flux
 
 # Tutorial: Set up Flux for GitOps **(FREE)**
 
-This tutorial teaches you how to set up Flux for GitOps. You'll set up a sample project,
-complete a bootstrap Flux installation, and authenticate your installation with a
-[project deploy token](../../../project/deploy_tokens/index.md).
-
-You can find the fully configured tutorial project [in this GitLab repository](https://gitlab.com/gitlab-org/configure/examples/flux/flux-config).
-It works in conjunction with [this repository](https://gitlab.com/gitlab-org/configure/examples/flux/web-app-manifests/-/tree/main), which contains the example Kubernetes manifests.
+This tutorial teaches you how to set up Flux for GitOps. You'll complete a bootstrap installation,
+install `agentk` in your cluster, and deploy a simple `nginx` application.
 
 To set up Flux for GitOps:
 
 1. [Create a personal access token](#create-a-personal-access-token)
-1. [Create the Flux repository](#create-the-flux-repository)
-1. [Create the Kubernetes manifest repository](#create-the-kubernetes-manifest-repository)
-1. [Configure Flux to sync your manifests](#configure-flux-to-sync-your-manifests)
-1. [Verify your configuration](#verify-your-configuration)
+1. [Complete a bootstrap installation](#complete-a-bootstrap-installation)
+1. [Register `agentk`](#register-agentk)
+1. [Install `agentk`](#install-agentk)
+1. [Deploy an example project](#deploy-an-example-project)
 
 Prerequisites:
 
-- You must have a Kubernetes cluster running.
+- You must have a Kubernetes cluster you can access locally with `kubectl`.
+- You must [install the Flux CLI](https://fluxcd.io/flux/installation/#install-the-flux-cli). Be sure to install Flux v2 or higher.
 
 ## Create a personal access token
 
-To authenticate with the Flux CLI, you must create a personal access token
-with the `api` scope:
+To authenticate with the Flux CLI, create a personal access token with
+the `api` scope:
 
-1. In the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Access Tokens**.
 1. Enter a name and optional expiry date for the token.
@@ -39,154 +36,172 @@ with the `api` scope:
 
 You can also use a [project](../../../project/settings/project_access_tokens.md) or [group access token](../../../group/settings/group_access_tokens.md) with the `api` scope.
 
-## Create the Flux repository
+## Complete a bootstrap installation
 
-Create a Git repository, install Flux, and authenticate Flux with your repo:
+In this section, you'll bootstrap Flux into an empty GitLab repository with the
+[`flux bootstrap`](https://fluxcd.io/flux/installation/#gitlab-and-gitlab-enterprise)
+command.
 
-1. Make sure your `kubectl` is configured to access your cluster.
-1. [Install the Flux CLI](https://fluxcd.io/flux/installation/#install-the-flux-cli). You must install Flux v2 or higher.
-1. In GitLab, create a new empty project called `flux-config`.
-1. From your shell, export a `GITLAB_TOKEN` environment variable with the value of your personal access token.
-   For example, `export GITLAB_TOKEN=<personal-access-token>`.
-1. Run the `bootstrap` command. The exact command depends on whether you are
-   creating the Flux repository under a GitLab user, group, or subgroup. For more information,
-   see the [Flux bootstrap documentation](https://fluxcd.io/flux/installation/#gitlab-and-gitlab-enterprise).
+To bootstrap a Flux installation:
 
-   In this tutorial, you're working with a public project in a subgroup. The bootstrap command looks like this:
+- Run the `flux bootstrap gitlab` command. For example:
 
-   ```shell
-   flux bootstrap gitlab \
-     --owner=gitlab-org/configure/examples/flux \
-     --repository=flux-config \
-     --branch=main \
-     --path=clusters/my-cluster \
-     --deploy-token-auth
-   ```
+  ```shell
+  flux bootstrap gitlab \
+  --owner=example-org \
+  --repository=my-repository \
+  --branch=master \
+  --path=clusters/testing \
+  --deploy-token-auth
+  ```
 
-   This command installs Flux on the Kubernetes cluster and configures it to manage itself from the repository `flux-config`.
-   The command also automatically creates the project deploy token required to access the `flux-config` repository.
+The bootstrap script does the following:
 
-Great work! You now have a repository bootstrapped with a Flux configuration. Any updates to your repository are automatically synced to the cluster.
+1. Creates a deploy token and saves it as a Kubernetes `secret`.
+1. Creates an empty GitLab project, if the project specified by `--repository` doesn't exist.
+1. Generates Flux definition files for your project.
+1. Commits the definition files to the specified branch.
+1. Applies the definition files to your cluster.
 
-## Create the Kubernetes manifest repository
+After you run the script, Flux will be ready to manage itself and any other resources
+you add to the GitLab project and path.
 
-Next, create a repository for your Kubernetes manifests:
+The rest of this tutorial assumes your path is `clusters/testing`.
 
-1. In GitLab, create a new repository called `web-app-manifests`.
-1. Add a file to `web-app-manifests` named `nginx-deployment.yaml` with the following contents:
+### Upgrade Flux
 
-   ```yaml
-   apiVersion: apps/v1
+You might need to upgrade Flux some time after you install it. To do so:
+
+- Rerun the `flux bootstrap gitlab` command.
+
+## Register `agentk`
+
+You must register `agentk` before you install it in your cluster.
+
+To register `agentk`:
+
+- Complete the steps in [Register the agent with GitLab](../install/index.md#register-the-agent-with-gitlab).
+  Be sure to save the agent registration token and `kas` address.
+
+## Install `agentk`
+
+Next, use Flux to create a namespace for `agentk` and install it in your cluster.
+
+This tutorial uses the namespace `gitlab` for `agentk`.
 
-   kind: Deployment
+To install `agentk`:
 
+1. Commit and push the following file to `clusters/testing/namespace-gitlab.yaml`:
+
+   ```yaml
+   apiVersion: v1
+   kind: Namespace
    metadata:
-     name: nginx-deployment
-     labels:
-       app: nginx
-   spec:
-     replicas: 3
-     selector:
-       matchLabels:
-         app: nginx
-     template:
-       metadata:
-         labels:
-           app: nginx
-       spec:
-         containers:
-         - name: nginx
-           image: nginx:1.14.2
-           ports:
-           - containerPort: 80
+   name: gitlab
    ```
 
-1. In the new repository, [create a deploy token](../../../project/deploy_tokens/index.md#create-a-deploy-token) with only the `read_repository` scope.
-1. Store your deploy token username and password somewhere safe.
-1. In Flux CLI, create a secret with your deploy token and point the secret to the new repository. For example:
+1. Apply the agent registration token as a secret in the cluster:
 
    ```shell
-   flux create secret git flux-deploy-authentication \
-            --url=https://gitlab.com/gitlab-org/configure/examples/flux/web-app-manifests \
-            --namespace=default \
-            --username=<token-user-name> \
-            --password=<token-password>
+   kubectl create secret generic gitlab-agent-token -n gitlab --from-literal=token=YOUR-TOKEN-HERE
    ```
 
-1. To check if your secret was generated successfully, run:
+   Although this step does not follow GitOps principles, it simplifies configuration for new Flux users.
+   For a proper GitOps setup, you should use a secret management solution. See the [Flux documentation](https://fluxcd.io/flux/guides).
 
-   ```shell
-   kubectl -n default get secrets flux-deploy-authentication -o yaml
+1. Commit and push the following file to `clusters/testing/agentk.yaml`, replacing the values of
+   `.spec.values.config.kasAddress` and `.spec.values.config.secretName` with your saved `kas` address and secret `name`:
+
+   ```yaml
+   ---
+   apiVersion: source.toolkit.fluxcd.io/v1beta2
+   kind: HelmRepository
+   metadata:
+     labels:
+       app.kubernetes.io/component: agentk
+       app.kubernetes.io/created-by: gitlab
+       app.kubernetes.io/name: agentk
+       app.kubernetes.io/part-of: gitlab
+     name: gitlab-agent
+     namespace: gitlab
+   spec:
+     interval: 1h0m0s
+     url: https://charts.gitlab.io
+   ---
+   apiVersion: helm.toolkit.fluxcd.io/v2beta1
+   kind: HelmRelease
+   metadata:
+     name: gitlab-agent
+     namespace: gitlab
+   spec:
+     chart:
+       spec:
+         chart: gitlab-agent
+         sourceRef:
+           kind: HelmRepository
+           name: gitlab-agent
+           namespace: gitlab-agent
+     interval: 1h0m0s
+     values:
+       config:
+         kasAddress: "wss://kas.gitlab.example.com"
+         secretName: "gitlab-agent-token"
    ```
 
-   Under `data`, you should see base64-encoded values associated with your token username and password.
+1. To verify that `agentk` is installed and running in the cluster, run the following command:
 
-Congratulations! You now have a manifest repository, a deploy token, and a secret generated directly on your cluster.
+   ```shell
+   kubectl -n gitlab get pods
+   ```
+
+Great work! You've successfully set up Flux with `agentk`. You can repeat the steps from this section
+to deploy more applications from this project. In the next section, we'll discuss how to scale Flux across projects.
 
-## Configure Flux to sync your manifests
+## Deploy an example project
 
-Next, tell `flux-config` to sync with the `web-app-manifests` repository.
+You can scale Flux deployments across multiple GitLab projects by adding a Flux `GitRepository` and `Kustomization` that points to another project.
+You can use this feature to store manifests related to a particular GitLab group in that group.
 
-To do so, create a [`GitRepository`](https://fluxcd.io/flux/components/source/gitrepositories/) resource:
+To demonstrate, deploy an `nginx` application and point Flux at it:
 
-1. Clone the `flux-config` repo to your machine.
-1. In your local clone of `flux-config`, add the `GitRepository` file `clusters/my-cluster/web-app-manifests-source.yaml`:
+1. Commit and push the following file to `clusters/testing/example-nginx-app.yaml`:
 
    ```yaml
    ---
-   apiVersion: source.toolkit.fluxcd.io/v1beta2
+   apiVersion: source.toolkit.fluxcd.io/v1
    kind: GitRepository
    metadata:
-     name: web-app-manifests
-     namespace: default
+     name: example-nginx-app
+     namespace: flux-system
    spec:
      interval: 1m0s
      ref:
        branch: main
      secretRef:
-       name: flux-deploy-authentication
-     url: https://gitlab.com/gitlab-org/configure/examples/flux/web-app-manifests
-   ```
-
-   This file uses `secretRef` to refer back to the deploy token secret you created in the last step.
-
-1. In your local clone of `flux-config`, add the `GitRepository` file `clusters/my-cluster/web-app-manifests-kustomization.yaml`:
-
-   ```yaml
+       name: example-nginx-app
+     url: https://gitlab.com/gitlab-examples/ops/gitops-demo/example-mini-flux-deployment.git
    ---
-   apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+   apiVersion: kustomize.toolkit.fluxcd.io/v1
    kind: Kustomization
    metadata:
-     name: nginx-source-kustomization
-     namespace: default
+     name: example-nginx-app
+     namespace: flux-system
    spec:
-     interval: 1m0s
-     path: ./
+     interval: 10m0s
+     path: ./manifests
      prune: true
      sourceRef:
        kind: GitRepository
-       name: web-app-manifests
-       namespace: default
-     targetNamespace: default
+       name: example-nginx-app
    ```
 
-   This file adds a [`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomization/) resource that tells Flux to sync the manifests from
-   `web-app-manifests` with `kustomize`.
-
-1. Commit the new files and push.
+1. To verify that the application was deployed correctly and `agentk` is running, run the following command:
 
-## Verify your configuration
-
-You should see a newly created `nginx-deployment` pod in your cluster.
-
-To check whether the `nginx-deployment` pod is running in the default namespace, run the following:
-
-```shell
-kubectl -n default get pods -n default
-```
+   ```shell
+   kubectl -n example-nginx get pods
+   ```
 
-If you want to see the deployment sync again, try updating the number of replicas in the
-`nginx-deployment.yaml` file and push to your `main` branch. If all is working well, it
-should sync to the cluster.
+This tutorial deploys an application from a public project. If you want to add a non-public project, you should create a [project deploy token](../../../project/deploy_tokens/index.md)
+and save it as a Flux secret. Be sure to save the namespace and secret name.
 
-Excellent work! You've successfully set up a complete Flux project.
+Congratulations! You have successfully scaled Flux to multiple groups and projects.
diff --git a/doc/user/clusters/agent/index.md b/doc/user/clusters/agent/index.md
index ccb3a346903..8b1a55bc7bd 100644
--- a/doc/user/clusters/agent/index.md
+++ b/doc/user/clusters/agent/index.md
@@ -52,9 +52,12 @@ Use this workflow:
 
 This workflow has a weaker security model and is not recommended for production deployments.
 
-## GitLab agent for Kubernetes supported cluster versions
+## Supported Kubernetes versions for GitLab features
 
-The agent for Kubernetes supports the following Kubernetes versions. You can upgrade your
+GitLab supports the following Kubernetes versions. If you want to run
+GitLab in a Kubernetes cluster, you might need a different version of Kubernetes.
+GitLab in a Kubernetes cluster, you might need [a different version of Kubernetes](https://docs.gitlab.com/charts/installation/cloud/index.html).
+You can upgrade your
 Kubernetes version to a supported version at any time:
 
 - 1.26 (support ends on March 22, 2024 or when 1.29 becomes supported)
diff --git a/doc/user/clusters/agent/install/index.md b/doc/user/clusters/agent/install/index.md
index 1bcbb42fc8e..76fcc73504c 100644
--- a/doc/user/clusters/agent/install/index.md
+++ b/doc/user/clusters/agent/install/index.md
@@ -29,7 +29,7 @@ Before you can install the agent in your cluster, you need:
 
 To install the agent in your cluster:
 
-1. Optional. [Create an agent configuration file](#create-an-agent-configuration-file).
+1. [Create an agent configuration file](#create-an-agent-configuration-file).
 1. [Register the agent with GitLab](#register-the-agent-with-gitlab).
 1. [Install the agent in your cluster](#install-the-agent-in-the-cluster).
 
@@ -44,8 +44,7 @@ For configuration settings, the agent uses a YAML file in the GitLab project. Yo
 
 - You use [a GitOps workflow](../gitops.md#gitops-workflow-steps).
 - You use [a GitLab CI/CD workflow](../ci_cd_workflow.md#gitlab-cicd-workflow-steps) and want to authorize a different project to use the agent.
-
-Otherwise it is optional.
+- You [allow specific project or group members to access Kubernetes](../user_access.md).
 
 To create an agent configuration file:
 
@@ -58,14 +57,12 @@ To create an agent configuration file:
    - Start with an alphanumeric character.
    - End with an alphanumeric character.
 
-1. In the repository, in the default branch, create this directory at the root:
+1. In the repository, in the default branch, create an agent configuration file at the root:
 
    ```plaintext
-   .gitlab/agents/<agent-name>
+   .gitlab/agents/<agent-name>/config.yaml
    ```
 
-1. In the directory, create a `config.yaml` file. Ensure the filename ends in `.yaml`, not `.yml`.
-
 You can leave the file blank for now, and [configure it](#configure-your-agent) later.
 
 ### Register the agent with GitLab
@@ -83,10 +80,10 @@ Prerequisites:
 
 You must register an agent before you can install the agent in your cluster. To register an agent:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
    If you have an [agent configuration file](#create-an-agent-configuration-file),
    it must be in this project. Your cluster manifest files should also be in this project.
-1. From the left sidebar, select **Infrastructure > Kubernetes clusters**.
+1. Select **Operate > Kubernetes clusters**.
 1. Select **Connect a cluster (agent)**.
    - If you want to create a configuration with CI/CD defaults, type a name.
    - If you already have an [agent configuration file](#create-an-agent-configuration-file), select it from the list.
@@ -144,7 +141,7 @@ When [KAS](../../../../administration/clusters/kas.md) is behind a self-signed c
 you can set the value of `config.caCert` to the certificate. For example:
 
 ```shell
-helm update --install gitlab-agent gitlab/gitlab-agent \
+helm upgrade --install gitlab-agent gitlab/gitlab-agent \
   --set-file config.caCert=my-custom-ca.pem
 ```
 
diff --git a/doc/user/clusters/agent/troubleshooting.md b/doc/user/clusters/agent/troubleshooting.md
index 531dac20fb6..9c0733d66b7 100644
--- a/doc/user/clusters/agent/troubleshooting.md
+++ b/doc/user/clusters/agent/troubleshooting.md
@@ -239,4 +239,4 @@ When you install the agent, you might encounter an error that states:
 Error: parse error at (gitlab-agent/templates/observability-secret.yaml:1): unclosed action
 ```
 
-This error is typically caused by an incompatible version of Helm. To resolve the issue, ensure that you are using a version of Helm [compatible with your version of Kubernetes](index.md#gitlab-agent-for-kubernetes-supported-cluster-versions).
+This error is typically caused by an incompatible version of Helm. To resolve the issue, ensure that you are using a version of Helm [compatible with your version of Kubernetes](index.md#supported-kubernetes-versions-for-gitlab-features).
diff --git a/doc/user/clusters/agent/user_access.md b/doc/user/clusters/agent/user_access.md
new file mode 100644
index 00000000000..be3f88d072e
--- /dev/null
+++ b/doc/user/clusters/agent/user_access.md
@@ -0,0 +1,152 @@
+---
+stage: Deploy
+group: Environments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Grant users Kubernetes access (Beta) **(FREE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/390769) in GitLab 16.1, with [flags](../../../administration/feature_flags.md) named `environment_settings_to_graphql`, `kas_user_access`, `kas_user_access_project`, and `expose_authorized_cluster_agents`. This feature is in [Beta](../../../policy/experiment-beta-support.md#beta).
+
+As an administrator of Kubernetes clusters in an organization, you can grant Kubernetes access to members
+of a specific project or group.
+
+Granting access also activates the Dashboard for Kubernetes for a project or group.
+
+## Configure Kubernetes access
+
+Configure access when you want to grant users access
+to a Kubernetes cluster.
+
+Prerequisites:
+
+- The agent for Kubernetes is installed in the Kubernetes cluster.
+- You must have the Developer role or higher.
+
+To configure access:
+
+- In the agent configuration file, define a `user_access` keyword with the following parameters:
+
+  - `projects`: A list of projects whose members should have access.
+  - `groups`: A list of groups whose members should have access.
+  - `access_as`: Required. For plain access, the value is `{ agent: {...} }`.
+
+After you configure access, requests are forwarded to the API server using
+the agent service account.
+For example:
+
+```yaml
+# .gitlab/agents/my-agent/config.yaml
+
+user_access:
+  access_as:
+    agent: {}
+  projects:
+    - id: group-1/project-1
+    - id: group-2/project-2
+  groups:
+    - id: group-2
+    - id: group-3/subgroup
+```
+
+## Configure access with user impersonation **(PREMIUM)**
+
+You can grant access to a Kubernetes cluster and transform
+requests into impersonation requests for authenticated users.
+
+Prerequisites:
+
+- The agent for Kubernetes is installed in the Kubernetes cluster.
+- You must have the Developer role or higher.
+
+To configure access with user impersonation:
+
+- In the agent configuration file, define a `user_access` keyword with the following parameters:
+
+  - `projects`: A list of projects whose members should have access.
+  - `groups`: A list of groups whose members should have access.
+  - `access_as`: Required. For user impersonation, the value is `{ user: {...} }`.
+
+After you configure access, requests are transformed into impersonation requests for
+authenticated users.
+
+### User impersonation workflow
+
+The installed `agentk` impersonates the given users as follows:
+
+- `UserName` is `gitlab:user:<username>`
+- `Groups` is:
+  - `gitlab:user`: Common to all requests coming from GitLab users.
+  - `gitlab:project_role:<project_id>:<role>` for each role in each authorized project.
+  - `gitlab:group_role:<group_id>:<role>` for each role in each authorized group.
+- `Extra` carries additional information about the request:
+  - `agent.gitlab.com/id`: The agent ID.
+  - `agent.gitlab.com/username`: The username of the GitLab user.
+  - `agent.gitlab.com/config_project_id`: The agent configuration project ID.
+  - `agent.gitlab.com/access_type`: One of `personal_access_token`,
+    `oidc_id_token`, or `session_cookie`.
+
+Only projects and groups directly listed in the under `user_access` in the configuration
+file are impersonated. For example:
+
+```yaml
+# .gitlab/agents/my-agent/config.yaml
+
+user_access:
+  access_as:
+    user: {}
+  projects:
+    - id: group-1/project-1 # group_id=1, project_id=1
+    - id: group-2/project-2 # group_id=2, project_id=2
+  groups:
+    - id: group-2 # group_id=2
+    - id: group-3/subgroup # group_id=3, group_id=4
+```
+
+In this configuration:
+
+- If a user is a member of only `group-1`, they receive
+  only the Kubernetes RBAC groups `gitlab:project_role:1:<role>`.
+- If a user is a member of `group-2`, they receive both Kubernetes RBAC groups:
+  - `gitlab:project_role:2:<role>`,
+  - `gitlab:group_role:2:<role>`.
+
+### RBAC authorization
+
+Impersonated requests require `ClusterRoleBinding` or `RoleBinding` to identify the resource permissions
+inside Kubernetes. See [RBAC authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+for the appropriate configuration.
+
+For example, if you allow maintainers in `awesome-org/deployment` project (ID: 123) to read the Kubernetes workloads,
+you must add a `ClusterRoleBinding` resource to your Kubernetes configuration:
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: my-cluster-role-binding
+roleRef:
+  name: view
+  kind: ClusterRole
+  apiGroup: rbac.authorization.k8s.io
+subjects:
+  - name: gitlab:project_role:123:maintainer
+    kind: Group
+```
+
+## Related topics
+
+- [Architectural blueprint](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/kubernetes_user_access.md)
+- [Dashboard for Kubernetes](https://gitlab.com/groups/gitlab-org/-/epics/2493)
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/user/clusters/agent/vulnerabilities.md b/doc/user/clusters/agent/vulnerabilities.md
index a71eea82df5..74676e31d22 100644
--- a/doc/user/clusters/agent/vulnerabilities.md
+++ b/doc/user/clusters/agent/vulnerabilities.md
@@ -15,11 +15,11 @@ You can also configure your agent so the vulnerabilities are displayed with othe
 ## Enable operational container scanning
 
 You can use operational container scanning to scan container images in your cluster for security vulnerabilities. You
-can enable the scanner to run on a cadence as configured via the agent, or setup scan execution policies within a
+can enable the scanner to run on a cadence as configured via the `agent config`, or setup `scan execution policies` within a
 project that houses the agent.
 
 NOTE:
-In GitLab 15.0 and later, you do not need to install Starboard operator in the Kubernetes cluster.
+If both `agent config` and `scan execution policies` are configured, the configuration from `scan execution policy` takes precedence.
 
 ### Enable via agent configuration
 
@@ -56,7 +56,7 @@ container_scanning:
       - kube-system
 ```
 
-## Enable via scan execution policies
+### Enable via scan execution policies
 
 To enable scanning of all images within your Kubernetes cluster via scan execution policies, we can use the
 [scan execution policy editor](../../application_security/policies/scan-execution-policies.md#scan-execution-policy-editor)
@@ -96,12 +96,41 @@ The CRON expression is evaluated in [UTC](https://www.timeanddate.com/worldclock
 
 You can view the complete schema within the [scan execution policy documentation](../../application_security/policies/scan-execution-policies.md#scan-execution-policies-schema).
 
+## Configure scanner resource requirements
+
+By default the scanner pod's default resource requirements are:
+
+```yaml
+requests:
+  cpu: 100m
+  memory: 100Mi
+limits:
+  cpu: 500m
+  memory: 500Mi
+```
+
+You can customize it with a `resource_requirements` field.
+
+```yaml
+container_scanning:
+  resource_requirements:
+    requests:
+      cpu: 200m
+      memory: 200Mi
+    limits:
+      cpu: 700m
+      memory: 700Mi
+```
+
+NOTE:
+Resource requirements can only be set up using the agent configuration. If you enabled `Operational Container Scanning` through `scan execution policies`, you would need to define the resource requirements within the agent configuration file.
+
 ## View cluster vulnerabilities
 
 To view vulnerability information in GitLab:
 
-1. On the top bar, select **Main menu > Projects** and find the project that contains the agent configuration file.
-1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the project that contains the agent configuration file.
+1. Select **Operate > Kubernetes clusters**.
 1. Select the **Agent** tab.
 1. Select an agent to view the cluster vulnerabilities.
 
diff --git a/doc/user/clusters/agent/work_with_agent.md b/doc/user/clusters/agent/work_with_agent.md
index 2d54f67724e..8bf9ac7cf06 100644
--- a/doc/user/clusters/agent/work_with_agent.md
+++ b/doc/user/clusters/agent/work_with_agent.md
@@ -18,9 +18,9 @@ Prerequisite:
 
 To view the list of agents:
 
-1. On the top bar, select **Main menu > Projects** and find the project that contains your agent configuration file.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the project that contains your agent configuration file.
    You cannot view registered agents from a project that does not contain the agent configuration file.
-1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
+1. Select **Operate > Kubernetes clusters**.
 1. Select **Agent** tab to view clusters connected to GitLab through the agent.
 
 On this page, you can view:
@@ -30,6 +30,22 @@ On this page, you can view:
 - The version of `agentk` installed on your cluster.
 - The path to each agent configuration file.
 
+## View shared agents
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/395498) in GitLab 16.1.
+
+In addition to the agents owned by your project, you can also view agents shared with the
+[`ci_access`](ci_cd_workflow.md) and [`user_access`](user_access.md) keywords. Once an agent
+is shared with a project, it automatically appears in the project agent tab.
+
+To view the list of shared agents:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Kubernetes clusters**.
+1. Select the **Agent** tab.
+
+The list of shared agents and their clusters are displayed.
+
 ## View an agent's activity information
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/277323) in GitLab 14.6.
@@ -38,8 +54,8 @@ The activity logs help you to identify problems and get the information
 you need for troubleshooting. You can see events from a week before the
 current date. To view an agent's activity:
 
-1. On the top bar, select **Main menu > Projects** and find the project that contains your agent configuration file.
-1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the project that contains your agent configuration file.
+1. Select **Operate > Kubernetes clusters**.
 1. Select the agent you want to see activity for.
 
 The activity list includes:
@@ -91,12 +107,15 @@ For more information about debugging, see [troubleshooting documentation](troubl
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327152) in GitLab 14.9.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/336641) in GitLab 14.10, the agent token can be revoked from the UI.
+> - Two-token limit [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/361030) in GitLab 16.1.
+
+An agent can have only two active tokens at one time.
 
 To reset the agent token without downtime:
 
 1. Create a new token:
-   1. On the top bar, select **Main menu > Projects** and find your project.
-   1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
+   1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+   1. Select **Operate > Kubernetes clusters**.
    1. Select the agent you want to create a token for.
    1. On the **Access tokens** tab, select **Create token**.
    1. Enter token's name and description (optional) and select **Create token**.
@@ -117,8 +136,8 @@ clean up those resources manually.
 
 To remove an agent from the UI:
 
-1. On the top bar, select **Main menu > Projects** and find the project that contains the agent configuration file.
-1. From the left sidebar, select **Infrastructure > Kubernetes clusters**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the project that contains the agent configuration file.
+1. Select **Operate > Kubernetes clusters**.
 1. In the table, in the row for your agent, in the **Options** column, select the vertical ellipsis (**{ellipsis_v}**).
 1. Select **Delete agent**.
 
diff --git a/doc/user/clusters/img/kubecost_v13_5.png b/doc/user/clusters/img/kubecost_v13_5.png
deleted file mode 100644
index a93e2531b16..00000000000
--- a/doc/user/clusters/img/kubecost_v13_5.png
+++ /dev/null
diff --git a/doc/user/clusters/management_project.md b/doc/user/clusters/management_project.md
index 0ad3fdbef2e..ff6cf6bb1a8 100644
--- a/doc/user/clusters/management_project.md
+++ b/doc/user/clusters/management_project.md
@@ -61,7 +61,10 @@ To associate a cluster management project with your cluster:
      **Infrastructure > Kubernetes clusters** page.
    - [Group-level cluster](../group/clusters/index.md), go to your group's **Kubernetes**
      page.
-   - [Instance-level cluster](../instance/clusters/index.md), on the top bar, select **Main menu > Admin > Kubernetes**.
+   - [Instance-level cluster](../instance/clusters/index.md):
+     1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+     1. Select **Admin Area**.
+     1. Select **Kubernetes**.
 1. Expand **Advanced settings**.
 1. From the **Cluster management project** dropdown list, select the cluster management project
 you created in the previous step.
diff --git a/doc/user/clusters/management_project_template.md b/doc/user/clusters/management_project_template.md
index 4b6c8dcac4c..f6bcff0481a 100644
--- a/doc/user/clusters/management_project_template.md
+++ b/doc/user/clusters/management_project_template.md
@@ -45,8 +45,7 @@ If you have already configured the agent and connected a cluster with GitLab:
 
 To create a project from the cluster management project template:
 
-1. In GitLab, on the top bar, select **Main menu > Projects > View all projects**.
-1. On the right of the page, select **New project**.
+1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New project/repository**.
 1. Select **Create from template**.
 1. From the list of templates, next to **GitLab Cluster Management**, select **Use template**.
 1. Enter the project details.
diff --git a/doc/user/compliance/compliance_report/index.md b/doc/user/compliance/compliance_report/index.md
index d04aeec066f..ab80fbbba8e 100644
--- a/doc/user/compliance/compliance_report/index.md
+++ b/doc/user/compliance/compliance_report/index.md
@@ -35,14 +35,16 @@ When you select a row in the compliance report, a drawer appears that provides:
 
 ### View the compliance violations report for a group
 
+> Target branch search [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/358414) in GitLab 16.0.
+
 Prerequisites:
 
 - You must be an administrator or have the Owner role for the group.
 
 To view the compliance violations report:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Compliance report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Secure > Compliance report**.
 
 You can sort the compliance report on:
 
@@ -50,6 +52,12 @@ You can sort the compliance report on:
 - Type of violation.
 - Merge request title.
 
+You can filter the compliance violations report on:
+
+- Project.
+- Date range of merge.
+- Target branch.
+
 Select a row to see details of the compliance violation.
 
 #### Severity levels
@@ -142,8 +150,8 @@ If the commit has a related merge commit, then the following are also included:
 
 To generate the Chain of Custody report:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Compliance report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Secure > Compliance report**.
 1. Select **List of all merge commits**.
 
 Depending on your version of GitLab, the Chain of Custody report is either sent through email or available for download.
@@ -158,8 +166,8 @@ details for the provided commit SHA.
 
 To generate a commit-specific Chain of Custody report:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Compliance report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Secure > Compliance report**.
 1. At the top of the compliance report, to the right of **List of all commits**, select the down arrow
    (**{chevron-lg-down}**).
 1. Enter the commit SHA, and then select **Export commit custody report**.
@@ -189,8 +197,8 @@ Prerequisites:
 
 To view the compliance frameworks report:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security & Compliance > Compliance report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Secure > Compliance report**.
 1. On the page, select the **Frameworks** tab.
 
 ### Apply a compliance framework to projects in a group
@@ -206,16 +214,16 @@ Prerequisites:
 
 To apply a compliance framework to one project in a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Compliance report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Secure > Compliance report**.
 1. On the page, select the **Frameworks** tab.
 1. Next to the project you want to add the compliance framework to, select **{plus}** **Add framework**.
 1. Select an existing compliance framework or create a new one.
 
 To apply a compliance framework to multiple projects in a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Compliance report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Secure > Compliance report**.
 1. On the page, select the **Frameworks** tab.
 1. Select multiple projects.
 1. From the **Choose one bulk action** dropdown list, select **Apply framework to selected projects**.
@@ -235,15 +243,15 @@ Prerequisites:
 
 To remove a compliance framework from one project in a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Compliance report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Secure > Compliance report**.
 1. On the page, select the **Frameworks** tab.
 1. Next to the compliance framework to remove from the project, select **{close}** on the framework label.
 
 To remove a compliance framework from multiple projects in a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Compliance report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Secure > Compliance report**.
 1. On the page, select the **Frameworks** tab.
 1. Select multiple projects.
 1. From the **Choose one bulk action** dropdown list, select **Remove framework from selected projects**.
@@ -264,8 +272,8 @@ Prerequisites:
 
 To export a report of compliance frameworks on projects in a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security and Compliance > Compliance report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Secure > Compliance report**.
 1. On the page, select the **Frameworks** tab.
 1. On the Frameworks tab, select the **Export as CSV** action in the top right corner
 
@@ -277,8 +285,8 @@ A report is compiled and delivered to your email inbox as an attachment.
 
 To filter the list of compliance frameworks:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Security & Compliance > Compliance report**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Secure > Compliance report**.
 1. On the page, select the **Frameworks** tab.
 1. In the search field:
    1. Select the attribute you want to filter by.
diff --git a/doc/user/compliance/license_approval_policies.md b/doc/user/compliance/license_approval_policies.md
index 860c2008021..96a4a08249a 100644
--- a/doc/user/compliance/license_approval_policies.md
+++ b/doc/user/compliance/license_approval_policies.md
@@ -24,6 +24,16 @@ The following video provides an overview of these policies.
   <iframe src="https://www.youtube-nocookie.com/embed/34qBQ9t8qO8" frameborder="0" allowfullscreen> </iframe>
 </figure>
 
+## Prerequisites to creating a new license approval policy
+
+License approval policies rely on the output of a dependency scanning job to verify that requirements have been met. If dependency scanning has not been properly configured, and therefore no dependency scanning jobs ran related to an open MR, the policy has no data with which to verify the requirements. When security policies are missing data for evaluation, they fail closed and assume the merge request could contain vulnerabilities.
+
+To ensure enforcement of your policies, you should enable dependency scanning on your target development projects. You can achieve this a few different ways:
+
+- Create a global [scan execution policy](../application_security/policies/scan-execution-policies.md) that enforces Dependency Scanning to run in all target development projects.
+- Use a [Compliance Pipeline](../../user/group/compliance_frameworks.md#compliance-frameworks) to define a Dependency Scanning job that is enforced on projects enforced by a given Compliance Framework.
+- Work with development teams to configure [Dependency Scanning](../../user/application_security/dependency_scanning/index.md) in each of their project's `.gitlab-ci.yml` files or enable by using the [Security Configuration panel](../application_security/configuration/index.md).
+
 ## Create a new license approval policy
 
 Create a license approval policy to enforce license compliance.
@@ -31,8 +41,8 @@ Create a license approval policy to enforce license compliance.
 To create a license approval policy:
 
 1. [Link a security policy project](../application_security/policies/index.md#managing-the-linked-security-policy-project) to your development group, subgroup, or project (the Owner role is required).
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Security & Compliance > Policies**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Secure > Policies**.
 1. Create a new [Scan Result Policy](../application_security/policies/scan-result-policies.md).
 1. In your policy rule, select **License scanning**.
 
diff --git a/doc/user/compliance/license_scanning_of_cyclonedx_files/index.md b/doc/user/compliance/license_scanning_of_cyclonedx_files/index.md
index 832f1007a91..22defd593cd 100644
--- a/doc/user/compliance/license_scanning_of_cyclonedx_files/index.md
+++ b/doc/user/compliance/license_scanning_of_cyclonedx_files/index.md
@@ -23,7 +23,7 @@ Licenses not in the SPDX list are reported as "Unknown". License information can
 
 Prerequisites:
 
-- Enable [Synchronization with the GitLab License Database](../../admin_area/settings/security_and_compliance.md#choose-package-registry-metadata-to-sync) in Admin Area for the GitLab instance.
+- On GitLab self-managed only, enable [Synchronization with the GitLab License Database](../../admin_area/settings/security_and_compliance.md#choose-package-registry-metadata-to-sync) in Admin Area for the GitLab instance. On GitLab SaaS this step has already been completed.
 - Enable [Dependency Scanning](../../application_security/dependency_scanning/index.md#configuration)
   and ensure that its prerequisites are met.
 
diff --git a/doc/user/crm/index.md b/doc/user/crm/index.md
index 54e87118361..c81cf6762e3 100644
--- a/doc/user/crm/index.md
+++ b/doc/user/crm/index.md
@@ -36,8 +36,8 @@ you must enable CRM features for the subgroup.
 
 To enable customer relations management in a group or subgroup:
 
-1. On the top bar, select **Main menu > Groups** and find your group or subgroup.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group or subgroup.
+1. Select **Settings > General**.
 1. Expand the **Permissions and group features** section.
 1. Select **Customer relations is enabled**.
 1. Select **Save changes**.
@@ -52,8 +52,8 @@ Prerequisites:
 
 To view a group's contacts:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Customer relations > Contacts**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Customer contacts**.
 
 ![Contacts list](crm_contacts_v14_10.png)
 
@@ -65,8 +65,8 @@ Prerequisites:
 
 To create a contact:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Customer relations > Contacts**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Customer contacts**.
 1. Select **New contact**.
 1. Complete all required fields.
 1. Select **Create new contact**.
@@ -82,8 +82,8 @@ Prerequisites:
 
 To edit an existing contact:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Customer relations > Contacts**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Customer contacts**.
 1. Next to the contact you wish to edit, select **Edit** (**{pencil}**).
 1. Edit the required fields.
 1. Select **Save changes**.
@@ -100,8 +100,8 @@ Each contact can be in one of two states:
 
 To change the state of a contact:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Customer relations > Contacts**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Customer contacts**.
 1. Next to the contact you wish to edit, select **Edit** (**{pencil}**).
 1. Select or clear the **Active** checkbox.
 1. Select **Save changes**.
@@ -116,8 +116,8 @@ Prerequisites:
 
 To view a group's organizations:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Customer relations > Organizations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Customer organizations**.
 
 ![Organizations list](crm_organizations_v14_10.png)
 
@@ -129,8 +129,8 @@ Prerequisites:
 
 To create an organization:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Customer relations > Organizations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Customer organizations**.
 1. Select **New organization**.
 1. Complete all required fields.
 1. Select **Create new organization**.
@@ -146,8 +146,8 @@ Prerequisites:
 
 To edit an existing organization:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Customer relations > Organizations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Customer organizations**.
 1. Next to the organization you wish to edit, select **Edit** (**{pencil}**).
 1. Edit the required fields.
 1. Select **Save changes**.
@@ -168,8 +168,8 @@ Prerequisites:
 
 To view a contact's issues, select a contact from the issue sidebar, or:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Customer relations > Contacts**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Customer contacts**.
 1. Next to the contact whose issues you wish to view, select **View issues** (**{issues}**).
 
 ### View issues linked to an organization
@@ -180,8 +180,8 @@ Prerequisites:
 
 To view an organization's issues:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Customer relations > Organizations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Customer organizations**.
 1. Next to the organization whose issues you wish to view, select **View issues** (**{issues}**).
 
 ### View contacts linked to an issue
diff --git a/doc/user/discussions/img/reply_to_comment_button.png b/doc/user/discussions/img/reply_to_comment_button.png
deleted file mode 100644
index d327d1c3e27..00000000000
--- a/doc/user/discussions/img/reply_to_comment_button.png
+++ /dev/null
diff --git a/doc/user/discussions/index.md b/doc/user/discussions/index.md
index 096b4dc2cc5..03b48fd42b6 100644
--- a/doc/user/discussions/index.md
+++ b/doc/user/discussions/index.md
@@ -18,7 +18,7 @@ GitLab encourages communication through comments, threads, and
 Two types of comments are available:
 
 - A standard comment.
-- A comment in a thread, which can be [resolved](#resolve-a-thread).
+- A comment in a thread, which can be [resolved](../project/merge_requests/index.md#resolve-a-thread).
 
 In a comment, you can enter [Markdown](../markdown.md) and use [quick actions](../project/quick_actions.md).
 
@@ -51,9 +51,25 @@ You can quickly see which comments involve you, because
 mentions for yourself (the user who is signed in) are highlighted
 in a different color.
 
-Avoid mentioning `@all` in issues and merge requests. It sends an email notification
-to all members of that project's parent group, not only the participants of the project.
-It might be interpreted as spam.
+### Mentioning all members
+
+> [Flag](../../administration/feature_flags.md) named `disable_all_mention` [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110586) in GitLab 16.1. Disabled by default. [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/18442).
+
+FLAG:
+On self-managed GitLab, by default this flag is not enabled. To make it available, ask an administrator to [enable the feature flag](../../administration/feature_flags.md)
+named `disable_all_mention`.
+On GitLab.com, this flag is enabled.
+
+When this feature flag is enabled, typing `@all` in comments and descriptions
+results in plain text instead of a mention.
+When you disable this feature, existing `@all` mentions in the Markdown texts are not affected
+and remain as links. Only future `@all` mentions appear as plain text.
+
+Avoid mentioning `@all` in comments and descriptions.
+When you do it, you don't only mention the participants of the project, issue, or merge request,
+but to all members of that project's parent group.
+All these users receive an email notification and a to-do item. It might be interpreted as spam.
+
 Notifications and mentions can be disabled in
 [a group's settings](../group/manage.md#disable-email-notifications).
 
@@ -95,29 +111,6 @@ it's converted to a link in the context of the merge request.
 For example, `28719b171a056960dfdc0012b625d0b47b123196` becomes `28719b17` that links to
 `https://gitlab.example.com/example-group/example-project/-/merge_requests/12345/diffs?commit_id=28719b171a056960dfdc0012b625d0b47b123196`.
 
-## Add a comment to a commit
-
-You can add comments and threads to a particular commit.
-
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Commits**.
-1. Below the commits, in the **Comment** field, enter a comment.
-1. Select **Comment** or select the down arrow (**{chevron-down}**) to select **Start thread**.
-
-WARNING:
-Threads created this way are lost if the commit ID changes after a
-force push.
-
-## Add a comment to an image
-
-In merge requests and commit detail views, you can add a comment to an image.
-This comment can also be a thread.
-
-1. Hover your mouse over the image.
-1. Select the location where you want to comment.
-
-An icon is displayed on the image and a comment field is displayed.
-
 ## Reply to a comment by sending email
 
 If you have ["reply by email"](../../administration/reply_by_email.md) configured,
@@ -236,8 +229,6 @@ To compare the changes, select **Compare with previous version**.
 
 ## Assign an issue to the commenting user
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/191455) in GitLab 13.1.
-
 You can assign an issue to a user who made a comment.
 
 1. In the comment, select the **More Actions** (**{ellipsis_v}**) menu.
@@ -256,9 +247,7 @@ Prerequisites:
 
 To create a thread by replying to a comment:
 
-1. In the upper-right corner of the comment, select **Reply to comment** (**{comment}**).
-
-   ![Reply to comment button](img/reply_to_comment_button.png)
+1. In the upper-right corner of the comment, select **Reply to comment** (**{reply}**).
 
    The reply section is displayed.
 
@@ -286,75 +275,3 @@ To create a thread:
 A threaded comment is created.
 
 ![Thread comment](img/discussion_comment.png)
-
-## Resolve a thread
-
-> Resolving comments individually was [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/28750) in GitLab 13.6.
-
-In a merge request, you can resolve a thread when you want to finish a conversation.
-
-Prerequisites:
-
-- You must have at least the Developer role
-  or be the author of the change being reviewed.
-- Resolvable threads can be added only to merge requests. It doesn't work
-  for comments in issues, commits, or snippets.
-
-To resolve a thread:
-
-1. Go to the thread.
-1. Do one of the following:
-   - In the upper-right corner of the original comment, select **Resolve thread** (**{check-circle}**).
-   - Below the last reply, in the **Reply** field, select **Resolve thread**.
-   - Below the last reply, in the **Reply** field, enter text, select the **Resolve thread** checkbox, and select **Add comment now**.
-
-At the top of the page, the number of unresolved threads is updated:
-
-![Count of unresolved threads](img/unresolved_threads_v15_4.png)
-
-### Move all unresolved threads in a merge request to an issue
-
-If you have multiple unresolved threads in a merge request, you can
-create an issue to resolve them separately. In the merge request, at the top of the page,
-select the ellipsis icon button (**{ellipsis_v}**) in the threads control and then select **Resolve all with new issue**:
-
-![Open new issue for all unresolved threads](img/create_new_issue_v15_4.png)
-
-All threads are marked as resolved, and a link is added from the merge request to
-the newly created issue.
-
-### Move one unresolved thread in a merge request to an issue
-
-If you have one specific unresolved thread in a merge request, you can
-create an issue to resolve it separately. In the merge request, under the last reply
-to the thread, next to **Resolve thread**, select **Create issue to resolve thread** (**{issue-new}**):
-
-![Create issue for thread](img/new-issue-one-thread_v14_3.png)
-
-The thread is marked as resolved, and a link is added from the merge request to
-the newly created issue.
-
-### Prevent merge unless all threads are resolved
-
-You can prevent merge requests from being merged until all threads are
-resolved. When this setting is enabled, the **Unresolved threads** counter in a merge request
-is shown in orange when at least one thread remains unresolved.
-
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
-1. In the **Merge checks** section, select the **All threads must be resolved** checkbox.
-1. Select **Save changes**.
-
-### Automatically resolve threads in a merge request when they become outdated
-
-You can set merge requests to automatically resolve threads when lines are modified
-with a new push.
-
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
-1. In the **Merge options** section, select
-   **Automatically resolve merge request diff threads when they become outdated**.
-1. Select **Save changes**.
-
-Threads are now resolved if a push makes a diff section outdated.
-Threads on lines that don't change and top-level resolvable threads are not resolved.
diff --git a/doc/user/enterprise_user/index.md b/doc/user/enterprise_user/index.md
index ffeaaa8c591..36f698daf81 100644
--- a/doc/user/enterprise_user/index.md
+++ b/doc/user/enterprise_user/index.md
@@ -11,7 +11,7 @@ Enterprise users have user accounts that are administered by an organization tha
 has purchased a [GitLab subscription](../../subscriptions/index.md).
 
 Enterprise users are identified by the [**Enterprise** badge](../project/badges.md)
-next to their names on the [Members list](../group/manage.md#filter-and-sort-members-in-a-group).
+next to their names on the [Members list](../group/index.md#filter-and-sort-members-in-a-group).
 
 ## Provision an enterprise user
 
@@ -25,7 +25,8 @@ A user account is considered an enterprise account when:
 A user can also [manually connect an identity provider (IdP) to a GitLab account whose email address matches the subscribing organization's domain](../group/saml_sso/index.md#link-saml-to-your-existing-gitlabcom-account).
 By selecting **Authorize** when connecting these two accounts, the user account
 with the matching email address is classified as an enterprise user. However, this
-user account does not have an **Enterprise** badge in GitLab.
+user account does not have an **Enterprise** badge in GitLab, and a group Owner cannot
+disable the user's two-factor authentication.
 
 Although a user can be a member of more than one group, each user account can be
 provisioned by only one group. As a result, a user is considered an enterprise
@@ -43,11 +44,18 @@ Prerequisites:
 
 - A custom domain name `example.com` or subdomain `subdomain.example.com`.
 - Access to your domain's server control panel to set up a DNS `TXT` record to verify your domain's ownership.
+- A project in the group.
+- You must have the Owner role in the top-level group.
 
 Setting up a verified domain is similar to [setting up a custom domain on GitLab Pages](../project/pages/custom_domains_ssl_tls_certification/index.md). However, you must:
 
-- Link the domain to a project. For more information on group-level domain verification, see [issue 5299](https://gitlab.com/groups/gitlab-org/-/epics/5299).
-- Configure the DNS `TXT` record to verify the domain's ownership.
+- Link the domain to a single project.
+- Configure the `TXT` only in the DNS record to verify the domain's ownership.
+
+Domain verification is tied to the project you choose. A project is required because domain verification reuses the GitLab Pages verification feature, which requires a project. Domain verification applies at the top-level group and to all subgroups and projects nested under that top-level parent group.
+A member in the chosen project with [at least the Maintainer role](../permissions.md#project-members-permissions) can modify or remove the domain verification.
+If needed, you can create a new project to set up domain verification directly under your top-level group. This limits the ability to modify the domain verification to members with at least the Maintainer role.
+For more information on group-level domain verification, see [epic 5299](https://gitlab.com/groups/gitlab-org/-/epics/5299).
 
 Steps:
 
@@ -55,15 +63,21 @@ Steps:
 
 The custom domain must match the email domain exactly. For example, if your email is `username@example.com`, verify the `example.com` domain.
 
-1. On the top bar, select **Main menu > Groups** and find your top group.
-1. On the left sidebar, select **Settings > Domain Verification**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your top-level group.
+1. Select **Settings > Domain Verification**.
 1. In the upper-right corner, select **Add Domain**.
 1. In **Domain**, enter the domain name.
 1. In **Project**, link to a project.
-1. Optional. In **Certificate**, switch the **Manually enter certificate information** toggle to add an SSL/TLS
-   certificate. You can also add the certificate and key later.
+1. In **Certificate**:
+   - If you do not have or do not want to use an SSL certificate, leave **Automatic certificate management using Let's
+     Encrypt** selected.
+   - Optional. Turn on the **Manually enter certificate information** toggle to add an SSL/TLS certificate. You can also
+     add the certificate and key later.
 1. Select **Add Domain**.
 
+NOTE:
+A valid certificate is not required for domain verification. You can ignore error messages regarding the certificate if you are not using GitLab Pages.
+
 #### 2. Get a verification code
 
 After you create a new domain, the verification code prompts you. Copy the values from GitLab
@@ -75,8 +89,8 @@ and paste them in your domain's control panel as a `TXT` record.
 
 After you have added all the DNS records:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Domain Verification**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Domain Verification**.
 1. On the domain table row, Select **Retry verification** (**{retry}**).
 
 ![Verify your domain](../img/retry_domain_verification_v16_0.png)
@@ -97,13 +111,14 @@ from the GitLab project.
 > - Once your domain has been verified, leave the verification record
   in place. Your domain is periodically reverified, and may be
   disabled if the record is removed.
+> - A valid certificate is not required for domain verification.
 
 ### View domains in group
 
 To view all configured domains in your group:
 
-1. On the top bar, select **Main menu > Groups** and find your top-level group.
-1. On the left sidebar, select **Settings > Domain Verification**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your top-level group.
+1. Select **Settings > Domain Verification**.
 
 You then see:
 
@@ -127,8 +142,8 @@ Top-level group Owners can disable two-factor authentication (2FA) for enterpris
 
 To disable 2FA:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Group information > Members**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Members**.
 1. Find a user with the **Enterprise** and **2FA** badges.
 1. Select **More actions** (**{ellipsis_v}**) and select **Disable two-factor authentication**.
 
@@ -149,3 +164,9 @@ A top-level group Owner can [set up verified domains to bypass confirmation emai
 
 A top-level group Owner can use the [group and project members API](../../api/members.md)
 to access users' information, including email addresses.
+
+## Troubleshooting
+
+### Cannot disable two-factor authentication for an enterprise user
+
+If an enterprise user does not have an **Enterprise** badge, a top-level group Owner cannot [disable or reset 2FA](#disable-two-factor-authentication) for that user. Instead, the Owner should tell the enterprise user to consider available [recovery options](../profile/account/two_factor_authentication.md#recovery-options).
diff --git a/doc/user/free_user_limit.md b/doc/user/free_user_limit.md
index 181eb00bb50..410bdc4b5f5 100644
--- a/doc/user/free_user_limit.md
+++ b/doc/user/free_user_limit.md
@@ -27,7 +27,7 @@ Prerequisite:
 
 - You must have the Owner role for the group.
 
-1. On the top bar, select **Main menu > Groups > View all groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. On the left sidebar, select **Settings > Usage Quotas**.
 1. To view all members, select the **Seats** tab.
 1. To remove a member, select **Remove user**.
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index fae45e4b2d3..82d0bfb035a 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -438,6 +438,12 @@ See [non-configurable limits](../../security/rate_limits.md#non-configurable-lim
 for information on rate limits that are not configurable, and therefore also
 used on GitLab.com.
 
+## GitLab.com-specific Gitaly RPC concurrency limits
+
+Per-repository Gitaly RPC concurrency and queuing limits are configured for different types of Git operations such as `git clone`. When these limits are exceeded, a `fatal: remote error: GitLab is currently unable to handle this request due to load` message is returned to the client.
+
+For administrator documentation, see [limit RPC concurrency](../../administration/gitaly/configure_gitaly.md#limit-rpc-concurrency).
+
 ## GitLab.com logging
 
 We use [Fluentd](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#fluentd)
@@ -462,7 +468,7 @@ and can't be configured on GitLab.com to expire. You can erase job logs
 
 ## GitLab.com at scale
 
-In addition to the GitLab Enterprise Edition Omnibus install, GitLab.com uses
+In addition to the GitLab Enterprise Edition Linux package install, GitLab.com uses
 the following applications and settings to achieve scale. All settings are
 publicly available, as [Kubernetes configuration](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com)
 or [Chef cookbooks](https://gitlab.com/gitlab-cookbooks).
diff --git a/doc/user/group/access_and_permissions.md b/doc/user/group/access_and_permissions.md
index 50506d005b0..b7acded6720 100644
--- a/doc/user/group/access_and_permissions.md
+++ b/doc/user/group/access_and_permissions.md
@@ -46,8 +46,8 @@ configured by an administrator.
 
 To change the permitted Git access protocols for a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Permissions and group features** section.
 1. Choose the permitted protocols from **Enabled Git access protocols**.
 1. Select **Save changes**.
@@ -58,7 +58,7 @@ To change the permitted Git access protocols for a group:
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/215410) from GitLab Ultimate to GitLab Premium in 13.1.
 
 To ensure only people from your organization can access particular resources, you can restrict access to groups by IP
-address. This group-level setting applies to:
+address. This top-level group setting applies to:
 
 - The GitLab UI, including subgroups, projects, and issues. It does not apply to GitLab Pages.
 - [In GitLab 12.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/12874), the API.
@@ -71,8 +71,8 @@ Administrators can combine restricted access by IP address with
 
 To restrict group access by IP address:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Permissions and group features** section.
 1. In the **Restrict access by IP address** text box, enter a list of IPv4 or IPv6
    address ranges in CIDR notation. This list:
@@ -112,8 +112,8 @@ You can prevent users with email addresses in specific domains from being added
 
 To restrict group access by domain:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Permissions and group features** section.
 1. In the **Restrict membership by email** field, enter the domain names.
 1. Select **Save changes**.
@@ -156,8 +156,8 @@ If you prevent group sharing outside the hierarchy for the **Animals** group:
 
 To prevent sharing outside of the group's hierarchy:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand **Permissions and group features**.
 1. Select **Members cannot invite groups outside of `<group_name>` and its subgroups**.
 1. Select **Save changes**.
@@ -172,8 +172,8 @@ which can be confusing and difficult to control.
 To restrict the permission to invite project members to a single source,
 prevent a project from being shared with other groups:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Permissions and group features** section.
 1. Select **Projects in `<group_name>` cannot be shared with other groups**.
 1. Select **Save changes**.
@@ -186,10 +186,8 @@ added to a project lose access when the setting is enabled.
 As a group Owner, you can prevent non-members from requesting access to
 your group.
 
-1. On the top bar, **Main menu > Groups** and find your group.
-1. Select **Your Groups**.
-1. Find the group and select it.
-1. From the left menu, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Permissions and group features** section.
 1. Clear the **Allow users to request access** checkbox.
 1. Select **Save changes**.
@@ -208,8 +206,8 @@ If even one is set to `true`, then the group does not allow outside forks.
 
 To prevent projects from being forked outside the group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Permissions and group features** section.
 1. Check **Prevent project forking outside current group**.
 1. Select **Save changes**.
@@ -233,8 +231,9 @@ The setting does not cascade. Projects in subgroups observe the subgroup configu
 
 To prevent members from being added to projects in a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
+1. Expand the **Permissions and group features** section.
 1. Under **Membership**, select **Users cannot be added to projects in this group**.
 1. Select **Save changes**.
 
@@ -282,15 +281,15 @@ To create group links via filter:
 
 LDAP user permissions can be manually overridden by an administrator. To override a user's permissions:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Group information > Members**. If LDAP synchronization
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Manage > Members**. If LDAP synchronization
    has granted a user a role with:
    - More permissions than the parent group membership, that user is displayed as having
      [direct membership](../project/members/index.md#display-direct-members) of the group.
    - The same or fewer permissions than the parent group membership, that user is displayed as having
      [inherited membership](../project/members/index.md#display-inherited-members) of the group.
 1. Optional. If the user you want to edit is displayed as having inherited membership,
-   [filter the subgroup to show direct members](manage.md#filter-a-group) before
+   [filter the subgroup to show direct members](index.md#filter-a-group) before
    overriding LDAP user permissions.
 1. In the row for the user you are editing, select the pencil (**{pencil}**) icon.
 1. Select **Edit permissions** in the modal.
@@ -318,6 +317,6 @@ If a parent group membership has the same or higher role than a subgroup, the
 listed on the subgroup members page, even if a [direct membership](../project/members/index.md#membership-types)
 on the group exists.
 
-To view and update direct memberships, [filter the group to show direct members](manage.md#filter-a-group).
+To view and update direct memberships, [filter the group to show direct members](index.md#filter-a-group).
 
 The need to filter members by type through a redesigned members page that lists both direct and inherited memberships is proposed in [issue 337539](https://gitlab.com/gitlab-org/gitlab/-/issues/337539#note_1277786161).
diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md
index 4c448d8e5c2..15fa5941dc2 100644
--- a/doc/user/group/clusters/index.md
+++ b/doc/user/group/clusters/index.md
@@ -21,8 +21,8 @@ your group, enabling you to use the same cluster across multiple projects.
 
 To view your group-level Kubernetes clusters:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Kubernetes**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Operate > Kubernetes**.
 
 ## Cluster management project
 
@@ -89,8 +89,8 @@ your cluster, which can cause deployment jobs to fail.
 
 To clear the cache:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Kubernetes**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Operate > Kubernetes**.
 1. Select your cluster.
 1. Expand **Advanced settings**.
 1. Select **Clear cluster cache**.
diff --git a/doc/user/group/compliance_frameworks.md b/doc/user/group/compliance_frameworks.md
index 2fca8b7b678..47764b0c915 100644
--- a/doc/user/group/compliance_frameworks.md
+++ b/doc/user/group/compliance_frameworks.md
@@ -16,8 +16,8 @@ requirements or needs additional oversight. The label can optionally enforce
 
 Compliance frameworks are created on top-level groups. Group owners can create, edit, and delete compliance frameworks:
 
-1. On the top bar, select **Main menu > Groups > View all groups** and find your group.
-1. On the left sidebar, select **Settings** > **General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings** > **General**.
 1. Expand the **Compliance frameworks** section.
 1. Create, edit, or delete compliance frameworks.
 
@@ -40,8 +40,8 @@ A compliance framework that is set to default has a **default** label.
 
 Group owners can set a compliance framework as default (or remove the setting):
 
-1. On the top bar, select **Main menu > Groups > View all groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Compliance frameworks** section and locate the compliance framework to set (or remove) as default.
 1. Select the vertical ellipsis (**{ellipsis_v}**) for the compliance frame and then select **Set default** (or
    **Remove default**).
@@ -125,8 +125,8 @@ Therefore, communicate with project users about compliance pipeline configuratio
 
 To configure a compliance pipeline:
 
-1. On the top bar, select **Main menu > Groups > View all groups** and find your group.
-1. On the left sidebar, select **Settings** > **General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings** > **General**.
 1. Expand the **Compliance frameworks** section.
 1. In **Compliance pipeline configuration (optional)**, add the path to the compliance framework configuration. Use the
    `path/file.y[a]ml@group-name/project-name` format. For example:
@@ -397,3 +397,22 @@ You could also have the following `.gitlab-ci.yml` configuration:
 
 This configuration doesn't overwrite the compliance pipeline and you get the following message:
 `take compliance action`.
+
+### Prefilled variables are not shown
+
+Because of a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/382857),
+compliance pipelines in GitLab 15.3 and later can prevent
+[prefilled variables](../../ci/pipelines/index.md#prefill-variables-in-manual-pipelines)
+from appearing when manually starting a pipeline.
+
+To workaround this issue, use `ref: '$CI_COMMIT_SHA'` instead of `ref: '$CI_COMMIT_REF_NAME'`
+in the `include:` statement that executes the individual project's configuration.
+
+The [example configuration](#example-configuration) has been updated with this change:
+
+```yaml
+include:
+  - project: '$CI_PROJECT_PATH'
+    file: '$CI_CONFIG_PATH'
+    ref: '$CI_COMMIT_SHA'
+```
diff --git a/doc/user/group/contribution_analytics/index.md b/doc/user/group/contribution_analytics/index.md
index b0347ba5caa..02f1e7f21e2 100644
--- a/doc/user/group/contribution_analytics/index.md
+++ b/doc/user/group/contribution_analytics/index.md
@@ -20,8 +20,8 @@ Use contribution analytics data visualizations to:
 
 To view contribution analytics:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Analytics > Contribution**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Analyze > Contribution analytics**.
 
 Three bar charts and a table illustrate the number of contributions made by each group member:
 
diff --git a/doc/user/group/custom_project_templates.md b/doc/user/group/custom_project_templates.md
index 95d7ddb056e..cbab83dd61e 100644
--- a/doc/user/group/custom_project_templates.md
+++ b/doc/user/group/custom_project_templates.md
@@ -29,7 +29,7 @@ To set up custom project templates in a group, add the subgroup that contains th
 project templates to the group settings:
 
 1. In the group, create a [subgroup](subgroups/index.md).
-1. [Add projects to the new subgroup](manage.md#add-projects-to-a-group) as your templates.
+1. [Add projects to the new subgroup](index.md#add-projects-to-a-group) as your templates.
 1. In the left menu for the group, select **Settings > General**.
 1. Expand **Custom project templates** and select the subgroup.
 
diff --git a/doc/user/group/devops_adoption/index.md b/doc/user/group/devops_adoption/index.md
index 7105318e5df..7aa4695e58b 100644
--- a/doc/user/group/devops_adoption/index.md
+++ b/doc/user/group/devops_adoption/index.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Group DevOps Adoption **(ULTIMATE)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321083) in GitLab 13.11 as a [Beta feature](../../../policy/alpha-beta-support.md#beta).
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321083) in GitLab 13.11 as a [Beta feature](../../../policy/experiment-beta-support.md#beta).
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/333556) in GitLab 14.1.
 > - The Overview tab [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330401) in GitLab 14.1.
 > - DAST and SAST metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/328033) in GitLab 14.1.
@@ -36,8 +36,8 @@ Prerequisite:
 
 To view DevOps Adoption:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Analytics > DevOps adoption**
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Analyze > DevOps adoption**
 
 ## DevOps Adoption categories
 
@@ -80,8 +80,8 @@ twelve months. The chart only shows data from when you enabled DevOps Adoption f
 
 To view feature adoption over time:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Analytics > DevOps adoption**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Analyze > DevOps adoption**.
 1. Select the **Overview** tab.
 
 Tooltips display information about the features tracked for individual months.
diff --git a/doc/user/group/epics/epic_boards.md b/doc/user/group/epics/epic_boards.md
index 6783e89779b..4a913c385a0 100644
--- a/doc/user/group/epics/epic_boards.md
+++ b/doc/user/group/epics/epic_boards.md
@@ -25,8 +25,8 @@ On the top of each list, you can see the number of epics in the list (**{epic}**
 
 To view an epic board:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Epics > Boards**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Epic boards**.
 
 ![GitLab epic board - Premium](img/epic_board_v15_10.png)
 
@@ -38,8 +38,8 @@ Prerequisites:
 
 To create a new epic board:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Epics > Boards**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Epic boards**.
 1. In the upper-left corner, select the dropdown list with the current board name.
 1. Select **Create new board**.
 1. Enter the new board's title.
@@ -87,8 +87,8 @@ Prerequisites:
 
 To create a new list:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Epics > Boards**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Epic boards**.
 1. In the upper-right corner, select **Create list**.
 1. In the **New list** column expand the **Select a label** dropdown list and select the label to use as
    list scope.
diff --git a/doc/user/group/epics/index.md b/doc/user/group/epics/index.md
index 32454693d71..5d3bac4f895 100644
--- a/doc/user/group/epics/index.md
+++ b/doc/user/group/epics/index.md
@@ -19,6 +19,13 @@ Use epics:
 - To track when the work for the group of issues is targeted to begin and end.
 - To discuss and collaborate on feature ideas and scope at a high level.
 
+<div class="video-fallback">
+  See the video: <a href="https://www.youtube.com/watch?v=kdE-yb6Puuo">GitLab Epics - Setting up your Organization with GitLab</a>.
+</div>
+<figure class="video-container">
+  <iframe src="https://www.youtube-nocookie.com/embed/kdE-yb6Puuo" frameborder="0" allowfullscreen> </iframe>
+</figure>
+
 ## Relationships between epics and issues
 
 The possible relationships between epics and issues are:
diff --git a/doc/user/group/epics/manage_epics.md b/doc/user/group/epics/manage_epics.md
index 98316188496..9436ff317a7 100644
--- a/doc/user/group/epics/manage_epics.md
+++ b/doc/user/group/epics/manage_epics.md
@@ -205,8 +205,8 @@ Prerequisites:
 
 To view epics in a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Epics**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Epics**.
 
 ### Who can view an epic
 
@@ -250,8 +250,8 @@ You can filter the list of epics by:
 
 To filter:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Epics**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Epics**.
 1. Select the field **Search or filter results**.
 1. From the dropdown list, select the scope or enter plain text to search by epic title or description.
 1. Press <kbd>Enter</kbd> on your keyboard. The list is filtered.
diff --git a/doc/user/group/import/index.md b/doc/user/group/import/index.md
index 7f55bf56102..0b9a1552281 100644
--- a/doc/user/group/import/index.md
+++ b/doc/user/group/import/index.md
@@ -40,7 +40,7 @@ Migrating groups by direct transfer copies the groups from one place to another.
   - The subgroup of any existing top-level group.
   - Another GitLab instance, including GitLab.com.
 - In the [API](../../../api/bulk_imports.md), copy top-level groups and subgroups to these locations.
-- Copy groups with projects (in [Beta](../../../policy/alpha-beta-support.md#beta) and not ready for production
+- Copy groups with projects (in [Beta](../../../policy/experiment-beta-support.md#beta) and not ready for production
   use) or without projects. Copying projects with groups is available:
   - On GitLab.com by default.
 
@@ -50,7 +50,7 @@ Not all group and project resources are copied. See list of copied resources bel
 - [Migrated project items](#migrated-project-items-beta).
 
 WARNING:
-Importing groups with projects is in [Beta](../../../policy/alpha-beta-support.md#beta). This feature is not
+Importing groups with projects is in [Beta](../../../policy/experiment-beta-support.md#beta). This feature is not
 ready for production use.
 
 We invite you to leave your feedback about migrating by direct transfer in
@@ -77,6 +77,13 @@ transfer.
 | 8 hours     | Time until migration times out.                                                                                                                                                 |
 | 90 minutes  | Time the destination is waiting for export to complete.                                                                                                                         |
 
+You can test the maximum relation size limit using these APIs:
+
+- [Group relations export API](../../../api/group_relations_export.md).
+- [Project relations export API](../../../api/project_relations_export.md)
+
+If either API produces files larger than the maximum relation size limit, group migration by direct transfer fails.
+
 ### Visibility rules
 
 After migration:
@@ -86,7 +93,7 @@ After migration:
   - Stay public when copied into a public group.
   - Become private when copied into a private group.
 
-If used a private network on your source instance to hide content from the general public,
+If you used a private network on your source instance to hide content from the general public,
 make sure to have a similar setup on the destination instance, or to import into a private group.
 
 ### Prerequisites
@@ -129,10 +136,10 @@ To ensure GitLab maps users and their contributions correctly:
 Create the group you want to import to and connect the source GitLab instance:
 
 1. Create either:
-   - A new group. On the top bar, select **{plus-square}**, then **New group**, and select **Import group**.
+   - A new group. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New group**. Then select **Import group**.
    - A new subgroup. On existing group's page, either:
      - Select **New subgroup**.
-     - On the top bar, Select **{plus-square}** and then **New subgroup**. Then on the left sidebar, select the **import an existing group** link.
+     - On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New subgroup**. Then select the **import an existing group** link.
 1. Enter the URL of a GitLab instance running GitLab 14.0 or later.
 1. Enter the [personal access token](../../../user/profile/personal_access_tokens.md) for your source GitLab instance.
 1. Select **Connect instance**.
@@ -153,7 +160,7 @@ role.
 1. After a group has been imported, select its GitLab path to open its GitLab URL.
 
 WARNING:
-Importing groups with projects is in [Beta](../../../policy/alpha-beta-support.md#beta). This feature is not
+Importing groups with projects is in [Beta](../../../policy/experiment-beta-support.md#beta). This feature is not
 ready for production use.
 
 ### Group import history
@@ -169,8 +176,7 @@ You can view all groups migrated by you by direct transfer listed on the group i
 To view group import history:
 
 1. Sign in to GitLab.
-1. On the top bar, select **Create new…** (**{plus-square}**).
-1. Select **New group**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New group**.
 1. Select **Import group**.
 1. In the upper-right corner, select **History**.
 1. If there are any errors for a particular import, you can see them by selecting **Details**.
@@ -220,6 +226,13 @@ Group items that are migrated to the destination GitLab instance include:
    - Already exists in the destination GitLab instance.
    - Has a public email in the source GitLab instance that matches a confirmed email in the destination GitLab instance.
 
+#### Excluded items
+
+Some group items are excluded from migration because they either:
+
+- May contain sensitive information: CI/CD variables, webhooks, and deploy tokens.
+- Are not supported: push rules.
+
 ### Migrated project items (Beta)
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/267945) in GitLab 14.4 [with a flag](../../feature_flags.md) named `bulk_import_projects`. Disabled by default.
@@ -251,7 +264,7 @@ If you choose not to migrate projects along with groups or if you want to retry
 initiate project-only migrations using the [API](../../../api/bulk_imports.md).
 
 WARNING:
-Migrating projects when migrating groups by direct transfer is in [Beta](../../../policy/alpha-beta-support.md#beta)
+Migrating projects when migrating groups by direct transfer is in [Beta](../../../policy/experiment-beta-support.md#beta)
 and is not ready for production use.
 
 Project items that are migrated to the destination GitLab instance include:
@@ -325,9 +338,24 @@ Setting-related project items that are migrated to the destination GitLab instan
 
 #### Excluded items
 
-Project items excluded from migration because they contain sensitive information:
-
-- Pipeline triggers.
+Some project items are excluded from migration because they either:
+
+- May contain sensitive information:
+  - CI/CD variables
+  - Deploy keys
+  - Deploy tokens
+  - Pipeline schedule variables
+  - Pipeline triggers
+  - Webhooks
+- Are not supported:
+  - Agents
+  - Container Registry
+  - Environments
+  - Feature flags
+  - Infrastructure Registry
+  - Package Registry
+  - Pages domains
+  - Remote mirrors
 
 ### Troubleshooting
 
@@ -378,8 +406,8 @@ To solve this, you must change the source group path to include a non-numerical
 
 - The GitLab UI:
 
-  1. On the top bar, select **Main menu > Groups** and find your group.
-  1. On the left sidebar, select **Settings > General**.
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+  1. Select **Settings > General**.
   1. Expand **Advanced**.
   1. Under **Change group URL**, change the group URL to include non-numeric characters.
 
@@ -493,7 +521,8 @@ Prerequisite:
 
 To enable import and export for a group:
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Visibility and access controls**.
 1. In the **Import sources** section, select the checkboxes for the sources you want.
@@ -506,9 +535,9 @@ Prerequisites:
 
 To export the contents of a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
-1. In the **Advanced** section, select **Export Group**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
+1. In the **Advanced** section, select **Export group**.
 1. After the export is generated, you should receive an email with a link to the [exported contents](#exported-contents)
    in a compressed tar archive, with contents in NDJSON format.
 1. Alternatively, you can download the export from the UI:
@@ -521,15 +550,13 @@ You can also export a group [using the API](../../../api/group_import_export.md)
 
 ### Import the group
 
-1. Create a new group:
-   - On the top bar, select **Create new…** (**{plus-square}**) and then **New group**.
-   - On an existing group's page, select **New subgroup**.
-1. Select **Import group**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New subgroup**.
+1. Select the **import an existing group** link.
 1. Enter your group name.
 1. Accept or modify the associated group URL.
-1. Select **Choose file**.
+1. Select **Choose file...**.
 1. Select the file that you exported in the [Export a group](#export-a-group) section.
-1. To begin importing, select **Import group**.
+1. To begin importing, select **Import**.
 
 Your newly imported group page appears after the operation completes.
 
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index 7e093ccb01b..322cefc71d9 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -21,10 +21,10 @@ For larger organizations, you can also create [subgroups](subgroups/index.md).
 For more information about creating and managing your groups, see [Manage groups](manage.md).
 
 NOTE:
-Self-managed customers should create a top-level group so you can see an overview of
-your organization. For more information about efforts to create an
+For self-managed customers it could be beneficial to create one single top-level group, so you can see an overview of
+your entire organization. For more information about efforts to create an
 organization view of all groups, [see epic 9266](https://gitlab.com/groups/gitlab-org/-/epics/9266).
-A top-level group can also have one complete
+A single top-level group provides insights in your entire organization via a complete
 [Security Dashboard and Center](../application_security/security_dashboard/index.md),
 [Vulnerability](../application_security/vulnerability_report/index.md#vulnerability-report) and
 [Compliance Report](../compliance/compliance_report/index.md), and
@@ -45,29 +45,242 @@ empty for anonymous users. The group page has a visibility level icon.
 Administrator users cannot create a subgroup or project with a higher visibility level than that of
 the immediate parent group.
 
-## Related topics
-
-- [Group wikis](../project/wiki/index.md)
-- [Maximum artifacts size](../admin_area/settings/continuous_integration.md#maximum-artifacts-size).
-- [Repositories analytics](repositories_analytics/index.md): View overall activity of all projects with code coverage.
-- [Contribution analytics](contribution_analytics/index.md): View the contributions (pushes, merge requests,
-  and issues) of group members.
-- [Issue analytics](issues_analytics/index.md): View a bar chart of your group's number of issues per month.
-- Use GitLab as a [dependency proxy](../packages/dependency_proxy/index.md) for upstream Docker images.
-- [Epics](epics/index.md): Track groups of issues that share a theme.
-- [Security Dashboard](../application_security/security_dashboard/index.md): View the vulnerabilities of all
-  the projects in a group and its subgroups.
-- [Insights](insights/index.md): Configure insights like triage hygiene, issues created/closed per a given period, and
-  average time for merge requests to be merged.
-- [Webhooks](../project/integrations/webhooks.md).
-- [Kubernetes cluster integration](clusters/index.md).
-- [Audit Events](../../administration/audit_events.md#group-events).
-- [CI/CD minutes quota](../../ci/pipelines/cicd_minutes.md): Keep track of the CI/CD minute quota for the group.
-- [Integrations](../admin_area/settings/project_integration_management.md).
-- [Transfer a project into a group](../project/settings/index.md#transfer-a-project-to-another-namespace).
-- [Share a project with a group](../project/members/share_project_with_groups.md): Give all group members access to the project at once.
-- [Lock the sharing with group feature](access_and_permissions.md#prevent-a-project-from-being-shared-with-groups).
-- [Enforce two-factor authentication (2FA)](../../security/two_factor_authentication.md#enforce-2fa-for-all-users-in-a-group): Enforce 2FA
-  for all group members.
-- Namespaces [API](../../api/namespaces.md) and [Rake tasks](../../raketasks/index.md).
-- [Control access and visibility](../admin_area/settings/visibility_and_access_controls.md).
+## View groups
+
+To explore all public groups:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your groups**.
+1. At the top right, select **Explore groups**.
+
+To view groups where you have a direct or indirect membership:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your groups**.
+
+This page shows groups that you are a member of:
+
+- Through membership of a subgroup's parent group.
+- Through direct or inherited membership of a project in the group or subgroup.
+
+## Create a group
+
+To create a group:
+
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New group**.
+1. Select **Create group**.
+1. Enter a name for the group in **Group name**. For a list of words that cannot be used as group names, see
+   [reserved names](../reserved_names.md).
+1. Enter a path for the group in **Group URL**, which is used for the [namespace](../namespace/index.md).
+1. Choose the [visibility level](../public_access.md).
+1. Personalize your GitLab experience by answering the following questions:
+   - What is your role?
+   - Who is using this group?
+   - What are you using this group for?
+1. Invite GitLab members or other users to join the group.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For details about groups, watch [GitLab Namespaces (users, groups and subgroups)](https://youtu.be/r0sJgjR2f5A).
+
+## Remove a group
+
+> Enabled delayed deletion by default and removed the option to delete immediately [on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622) and [on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606) in GitLab 16.0.
+
+To remove a group and its contents:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Settings > General**.
+1. Expand the **Advanced** section.
+1. In the **Remove group** section, select **Remove group**.
+1. Type the group name.
+1. Select **Confirm**.
+
+A group can also be removed from the groups dashboard:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your groups**.
+1. Select (**{ellipsis_v}**) for the group you want to delete.
+1. Select **Delete**.
+1. In the Remove group section, select **Remove group**.
+1. Type the group name.
+1. Select **Confirm**.
+
+This action removes the group. It also adds a background job to delete all projects in the group.
+
+In [GitLab 12.8 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on GitLab [Premium](https://about.gitlab.com/pricing/premium/) and [Ultimate](https://about.gitlab.com/pricing/ultimate/), this action adds a background job to mark a group for deletion. By default, the job schedules the deletion seven days in the future. You can modify this retention period through the [instance settings](../admin_area/settings/visibility_and_access_controls.md#deletion-protection).
+
+In [GitLab 13.6 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/39504), if the user who sets up the deletion is removed from the group before the deletion happens, the job is cancelled, and the group is no longer scheduled for deletion.
+
+## Remove a group immediately **(PREMIUM)**
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/336985) in GitLab 14.2.
+> - Enabled delayed deletion by default and removed the option to delete immediately [on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622) and [on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606) in GitLab 16.0.
+
+If you don't want to wait, you can remove a group immediately.
+
+Prerequisites:
+
+- You must have the Owner role for a group.
+- You have [marked the group for deletion](#remove-a-group).
+
+To immediately remove a group marked for deletion:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
+1. Expand **Advanced**.
+1. In the "Permanently remove group" section, select **Remove group**.
+1. Confirm the action when asked to.
+
+Your group, its subgroups, projects, and all related resources, including issues and merge requests,
+are deleted.
+
+## Restore a group **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33257) in GitLab 12.8.
+
+To restore a group that is marked for deletion:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
+1. Expand the **Advanced** section.
+1. In the Restore group section, select **Restore group**.
+
+## Request access to a group
+
+As a user, you can request to be a member of a group, if an administrator allows it.
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your groups**.
+1. At the top right side, select **Explore groups**.
+1. Under the group name, select **Request Access**.
+
+As many as ten of the most-recently-active group owners receive an email with your request.
+Any group owner can approve or decline the request.
+
+If you change your mind before your request is approved, select
+**Withdraw Access Request**.
+
+## Filter and sort members in a group
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/21727) in GitLab 12.6.
+> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/228675) in GitLab 13.7.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/289911) in GitLab 13.8.
+
+To find members in a group, you can sort, filter, or search.
+
+### Filter a group
+
+Filter a group to find members. By default, all members in the group and subgroups are displayed.
+
+In lists of group members, entries can display the following badges:
+
+- **SAML**, to indicate the member has a [SAML account](saml_sso/index.md) connected to them.
+- **Enterprise**, to indicate that the member is an [enterprise user](../enterprise_user/index.md).
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Members**.
+1. Above the list of members, in the **Filter members** box, enter filter criteria.
+   - To view members in the group only, select **Membership = Direct**.
+   - To view members of the group and its subgroups, select **Membership = Inherited**.
+   - To view members with two-factor authentication enabled or disabled, select **2FA = Enabled** or **Disabled**.
+   - [In GitLab 14.0 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/349887), to view GitLab users created by [SAML SSO](saml_sso/index.md) or [SCIM provisioning](saml_sso/scim_setup.md) select **Enterprise = true**.
+
+### Search a group
+
+You can search for members by name, username, or email.
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Members**.
+1. Above the list of members, in the **Filter members** box, enter search criteria.
+1. To the right of the **Filter members** box, select the magnifying glass (**{search}**).
+
+### Sort members in a group
+
+You can sort members by **Account**, **Access granted**, **Max role**, or **Last sign-in**.
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Members**.
+1. Above the list of members, in the upper-right corner, from the **Account** list, select
+   the criteria to filter by.
+1. To switch the sort between ascending and descending, to the right of the **Account** list, select the
+   arrow (**{sort-lowest}** or **{sort-highest}**).
+
+## Add users to a group
+
+You can give a user access to all projects in a group.
+
+Prerequisite:
+
+- You must have the Owner role.
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Members**.
+1. Select **Invite members**.
+1. Fill in the fields.
+   - The role applies to all projects in the group. For more information, see [permissions](../permissions.md).
+   - On the **Access expiration date**, the user can no longer access projects in the group.
+1. Select **Invite**.
+
+Members that are not automatically added are displayed on the **Invited** tab.
+Users can be on this tab because they:
+
+- Have not yet accepted the invitation.
+- Are waiting for [approval from an administrator](../admin_area/moderate_users.md).
+- [Exceed the group user cap](manage.md#user-cap-for-groups).
+
+## Remove a member from the group
+
+Prerequisites:
+
+- You must have the Owner role.
+- The member must have direct membership in the group. If
+  membership is inherited from a parent group, then the member can be removed
+  from the parent group only.
+
+To remove a member from a group:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Members**.
+1. Next to the member you want to remove, select the vertical ellipsis (**{ellipsis_v}**).
+1. Select **Remove member**.
+1. Optional. On the **Remove member** confirmation box:
+   - To remove direct user membership from subgroups and projects, select the **Also remove direct user membership from subgroups and projects** checkbox.
+   - To unassign the user from linked issues and merge requests, select the **Also unassign this user from linked issues and merge requests** checkbox.
+1. Select **Remove member**.
+
+## Ensure removed users cannot invite themselves back
+
+Malicious users with the Maintainer or Owner role could exploit a race condition that allows
+them to invite themselves back to a group or project that a GitLab administrator has removed them from.
+
+To avoid this problem, GitLab administrators can [ensure removed users cannot invite themselves back](../project/members/index.md#ensure-removed-users-cannot-invite-themselves-back).
+
+## Add projects to a group
+
+There are two different ways to add a new project to a group:
+
+- Select a group, and then select **New project**. You can then continue [creating your project](../../user/project/index.md#create-a-project).
+- While you are creating a project, select a group from the dropdown list.
+
+  ![Select group](img/select_group_dropdown_13_10.png)
+
+### Specify who can add projects to a group
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/2534) in GitLab 10.5.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/25975) from GitLab Premium to GitLab Free in 11.10.
+
+By default, users with:
+
+- At least the Developer role can create projects under a group. This default can be changed.
+- At least the Maintainer role can fork projects into a group. This default prevents users with the Developer role from forking projects that
+  contain protected branches and cannot be changed.
+
+To change the role that can create projects under a group:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
+1. Expand the **Permissions and group features** section.
+1. Select the desired option in the **Roles allowed to create projects** dropdown list.
+1. Select **Save changes**.
+
+To change this setting globally, see [Default project creation protection](../admin_area/settings/visibility_and_access_controls.md#define-which-roles-can-create-projects).
diff --git a/doc/user/group/insights/index.md b/doc/user/group/insights/index.md
index 17aa6cb9655..ab967c8b12c 100644
--- a/doc/user/group/insights/index.md
+++ b/doc/user/group/insights/index.md
@@ -23,8 +23,8 @@ Prerequisites:
 
 To access your group's insights:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Analytics > Insights**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Analyze > Insights**.
 
 ## Interact with insights charts
 
@@ -65,9 +65,9 @@ To configure group insights:
 
 1. Create a new file [`.gitlab/insights.yml`](../../project/insights/index.md#configure-project-insights)
 in a project that belongs to your group.
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Analytics** tab and find the **Insights** section.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
+1. Expand **Analytics** and find the **Insights** section.
 1. Select the project that contains your `.gitlab/insights.yml` configuration file.
 1. Select **Save changes**.
 
diff --git a/doc/user/group/issues_analytics/index.md b/doc/user/group/issues_analytics/index.md
index dbade014ec2..cc43ca80801 100644
--- a/doc/user/group/issues_analytics/index.md
+++ b/doc/user/group/issues_analytics/index.md
@@ -15,8 +15,8 @@ prior.
 
 To access the chart:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Analytics > Issue Analytics**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Analyze > Issue analytics**.
 
 Hover over each bar to see the total number of issues.
 
diff --git a/doc/user/group/iterations/index.md b/doc/user/group/iterations/index.md
index 9b246e6ad47..a4677182bb0 100644
--- a/doc/user/group/iterations/index.md
+++ b/doc/user/group/iterations/index.md
@@ -50,8 +50,8 @@ Prerequisites:
 
 To create an iteration cadence:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Issues > Iterations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Iterations**.
 1. Select **New iteration cadence**.
 1. Enter the title and description of the iteration cadence.
 1. To manually manage the iteration cadence, clear the **Enable automatic scheduling** checkbox and skip the next step.
@@ -70,8 +70,8 @@ If you want to manually manage the created cadence, read [Manual Iteration Manag
 
 ### View the iterations list
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. Select **Issues > Iterations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Iterations**.
 
 To view all the iterations in a cadence, ordered by descending date, select that iteration cadence.
 From there you can create a new iteration or select an iteration to get a more detailed view.
@@ -91,8 +91,8 @@ Prerequisites:
 
 To edit an iteration cadence:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Issues > Iterations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Iterations**.
 1. Select **Edit iteration cadence**.
 
 When you use automatic scheduling and edit the **Automation start date** field,
@@ -105,8 +105,8 @@ doesn't delete the eight existing upcoming iterations.
 
 #### Turn on and off automatic scheduling for an iteration cadence
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Issues > Iterations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Iterations**.
 1. Next to the cadence for which you want to turn on or off automatic scheduling, select the
    three-dot menu (**{ellipsis_v}**) **> Edit cadence**.
 1. Select or clear the **Enable automatic scheduling** checkbox.
@@ -157,8 +157,8 @@ Deleting an iteration cadence also deletes all iterations within that cadence.
 
 To delete an iteration cadence:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Issues > Iterations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Iterations**.
 1. Select the three-dot menu (**{ellipsis_v}**) > **Delete cadence** for the cadence you want to delete.
 1. Select **Delete cadence**.
 
@@ -178,8 +178,8 @@ Prerequisites:
 
 To create an iteration:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Issues > Iterations** and select an iteration cadence.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Plan > Iterations** and select an iteration cadence.
 1. Select **New iteration**.
 1. Enter the title, a description (optional), a start date, and a due date.
 1. Select **Create iteration**. The iteration details page opens.
@@ -277,8 +277,8 @@ and get a more accurate understanding of scope attributable to each label.
 
 To group issues by label:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Issues > Iterations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Iterations**.
 1. In the **Group by** dropdown list, select **Label**.
 1. Select the **Filter by label** dropdown list.
 1. Select the labels you want to group by in the labels dropdown list.
diff --git a/doc/user/group/manage.md b/doc/user/group/manage.md
index 7c2c2eaa211..284fb8b3d7c 100644
--- a/doc/user/group/manage.md
+++ b/doc/user/group/manage.md
@@ -9,245 +9,16 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Use groups to manage one or more related projects at the same time.
 
 NOTE:
-Self-managed customers should create a top-level group so you can see an overview of
-your organization. For more information about efforts to create an
+For self-managed customers it could be beneficial to create one single top-level group, so you can see an overview of
+your entire organization. For more information about efforts to create an
 organization view of all groups, [see epic 9266](https://gitlab.com/groups/gitlab-org/-/epics/9266).
-A top-level group can also have one complete
+A single top-level group provides insights in your entire organization via a complete
 [Security Dashboard and Center](../application_security/security_dashboard/index.md),
 [Vulnerability](../application_security/vulnerability_report/index.md#vulnerability-report) and
 [Compliance Report](../compliance/compliance_report/index.md), and
 [Value stream analytics](../group/value_stream_analytics/index.md).
 
-## View groups
-
-To view groups, on the top bar, select **Main menu > Groups > View all groups**.
-
-The **Groups** page shows a list of groups, sorted by last updated date.
-
-- To explore all public groups, select **Explore groups**.
-- To view groups where you have a direct or indirect membership, select **Your groups**. This tab shows groups that you are a member of:
-  - Through membership of a subgroup's parent group.
-  - Through direct or inherited membership of a project in the group or subgroup.
-
-## Create a group
-
-To create a group:
-
-1. On the top bar, either:
-   - Select **Main menu > Groups > View all groups**, and on the right, select **New group**.
-   - To the left of the search box, select the plus sign and then **New group**.
-1. Select **Create group**.
-1. Enter a name for the group in **Group name**. For a list of words that cannot be used as group names, see
-   [reserved names](../reserved_names.md).
-1. Enter a path for the group in **Group URL**, which is used for the [namespace](../namespace/index.md).
-1. Choose the [visibility level](../public_access.md).
-1. Personalize your GitLab experience by answering the following questions:
-   - What is your role?
-   - Who is using this group?
-   - What are you using this group for?
-1. Invite GitLab members or other users to join the group.
-
-<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For details about groups, watch [GitLab Namespaces (users, groups and subgroups)](https://youtu.be/r0sJgjR2f5A).
-
-## Remove a group
-
-To remove a group and its contents:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Advanced** section.
-1. In the **Remove group** section, select **Remove group**.
-1. Type the group name.
-1. Select **Confirm**.
-
-A group can also be removed from the groups dashboard:
-
-1. On the top bar, select **Main menu > Groups > View all groups**.
-1. Select **Your Groups**.
-1. Select (**{ellipsis_v}**) for the group you want to delete.
-1. Select **Delete**.
-1. In the Remove group section, select **Remove group**.
-1. Type the group name.
-1. Select **Confirm**.
-
-This action removes the group. It also adds a background job to delete all projects in the group.
-
-Specifically:
-
-- In [GitLab 12.8 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [GitLab Premium or Ultimate tiers](https://about.gitlab.com/pricing/premium/), this action adds a background job to mark a group for deletion. By default, the job schedules the deletion 7 days in the future. You can modify this waiting period through the [instance settings](../admin_area/settings/visibility_and_access_controls.md#deletion-protection).
-
-- In [GitLab 13.6 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/39504), if the user who sets up the deletion is removed from the group before the
-  deletion happens, the job is cancelled, and the group is no longer scheduled for deletion.
-
-## Remove a group immediately **(PREMIUM)**
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/336985) in GitLab 14.2.
-
-If you don't want to wait, you can remove a group immediately.
-
-Prerequisites:
-
-- You must have the Owner role for a group.
-- You have [marked the group for deletion](#remove-a-group).
-
-To immediately remove a group marked for deletion:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Advanced**.
-1. In the "Permanently remove group" section, select **Remove group**.
-1. Confirm the action when asked to.
-
-Your group, its subgroups, projects, and all related resources, including issues and merge requests,
-are deleted.
-
-## Restore a group **(PREMIUM)**
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33257) in GitLab 12.8.
-
-To restore a group that is marked for deletion:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. Select **Settings > General**.
-1. Expand the **Path, transfer, remove** section.
-1. In the Restore group section, select **Restore group**.
-
-## Request access to a group
-
-As a user, you can request to be a member of a group, if an administrator allows it.
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. Under the group name, select **Request Access**.
-
-As many as ten of the most-recently-active group owners receive an email with your request.
-Any group owner can approve or decline the request.
-
-If you change your mind before your request is approved, select
-**Withdraw Access Request**.
-
-## Filter and sort members in a group
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/21727) in GitLab 12.6.
-> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/228675) in GitLab 13.7.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/289911) in GitLab 13.8.
-
-To find members in a group, you can sort, filter, or search.
-
-### Filter a group
-
-Filter a group to find members. By default, all members in the group and subgroups are displayed.
-
-In lists of group members, entries can display the following badges:
-
-- **SAML**, to indicate the member has a [SAML account](saml_sso/index.md) connected to them.
-- **Enterprise**, to indicate that the member is an [enterprise user](../enterprise_user/index.md).
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. Above the list of members, in the **Filter members** box, enter filter criteria.
-   - To view members in the group only, select **Membership = Direct**.
-   - To view members of the group and its subgroups, select **Membership = Inherited**.
-   - To view members with two-factor authentication enabled or disabled, select **2FA = Enabled** or **Disabled**.
-   - [In GitLab 14.0 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/349887), to view GitLab users created by [SAML SSO](saml_sso/index.md) or [SCIM provisioning](saml_sso/scim_setup.md) select **Enterprise = true**.
-
-### Search a group
-
-You can search for members by name, username, or email.
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Group information > Members**.
-1. Above the list of members, in the **Filter members** box, enter search criteria.
-1. To the right of the **Filter members** box, select the magnifying glass (**{search}**).
-
-### Sort members in a group
-
-You can sort members by **Account**, **Access granted**, **Max role**, or **Last sign-in**.
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Group information > Members**.
-1. Above the list of members, in the upper-right corner, from the **Account** list, select
-   the criteria to filter by.
-1. To switch the sort between ascending and descending, to the right of the **Account** list, select the
-   arrow (**{sort-lowest}** or **{sort-highest}**).
-
-## Add users to a group
-
-You can give a user access to all projects in a group.
-
-Prerequisite:
-
-- You must have the Owner role.
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Group information > Members**.
-1. Select **Invite members**.
-1. Fill in the fields.
-   - The role applies to all projects in the group. For more information, see [permissions](../permissions.md).
-   - On the **Access expiration date**, the user can no longer access projects in the group.
-1. Select **Invite**.
-
-Members that are not automatically added are displayed on the **Invited** tab.
-Users can be on this tab because they:
-
-- Have not yet accepted the invitation.
-- Are waiting for [approval from an administrator](../admin_area/moderate_users.md).
-- [Exceed the group user cap](#user-cap-for-groups).
-
-## Remove a member from the group
-
-Prerequisites:
-
-- You must have the Owner role.
-- The member must have direct membership in the group. If
-  membership is inherited from a parent group, then the member can be removed
-  from the parent group only.
-
-To remove a member from a group:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Group information > Members**.
-1. Next to the member you want to remove, select **Remove member**.
-1. Optional. On the **Remove member** confirmation box:
-   - To remove direct user membership from subgroups and projects, select the **Also remove direct user membership from subgroups and projects** checkbox.
-   - To unassign the user from linked issues and merge requests, select the **Also unassign this user from linked issues and merge requests** checkbox.
-1. Select **Remove member**.
-
-## Ensure removed users cannot invite themselves back
-
-Malicious users with the Maintainer or Owner role could exploit a race condition that allows
-them to invite themselves back to a group or project that a GitLab administrator has removed them from.
-
-To avoid this problem, GitLab administrators can [ensure removed users cannot invite themselves back](../project/members/index.md#ensure-removed-users-cannot-invite-themselves-back).
-
-## Add projects to a group
-
-There are two different ways to add a new project to a group:
-
-- Select a group, and then select **New project**. You can then continue [creating your project](../../user/project/index.md#create-a-project).
-- While you are creating a project, select a group from the dropdown list.
-
-  ![Select group](img/select_group_dropdown_13_10.png)
-
-### Specify who can add projects to a group
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/2534) in GitLab 10.5.
-> - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/25975) from GitLab Premium to GitLab Free in 11.10.
-
-By default, users with at least the Developer role can create projects under a group.
-
-To change this setting for a specific group:
-
-1. On the top bar, select **Main menu > Groups > View all groups**.
-1. Select **Your Groups**.
-1. Find the group and select it.
-1. From the left menu, select **Settings > General**.
-1. Expand the **Permissions and group features** section.
-1. Select the desired option in the **Roles allowed to create projects** dropdown list.
-1. Select **Save changes**.
-
-To change this setting globally, see [Default project creation protection](../admin_area/settings/visibility_and_access_controls.md#define-which-roles-can-create-projects).
-
-## Add Group README
+## Add a group README
 
 As a group owner or member, you can use a README to provide more information about your team, and invite users to contribute to your projects.
 The README is displayed on the group overview page, and can be changed in the group settings. All group members can edit the README.
@@ -258,8 +29,8 @@ Prerequisite:
 
 To add a group README:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. In the **Group README** section, select **Add README**. This action creates a new project `gitlab-profile` that contains the `README.md` file.
 1. On the prompt for creating a README, select **Create and add README**. You're redirected to the Web IDE, where a README file is created.
 1. In the Web IDE, edit and commit the `README.md` file.
@@ -270,13 +41,13 @@ You can change the owner of a group. Each group must always have at least one
 member with the Owner role.
 
 - As an administrator:
-  1. On the top bar, select **Main menu > Groups** and find your group.
-  1. On the left sidebar, select **Group information > Members**.
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+  1. Select **Manage > Members**.
   1. Give a different member the **Owner** role.
   1. Refresh the page. You can now remove the **Owner** role from the original owner.
 - As the current group's owner:
-  1. On the top bar, select **Main menu > Groups** and find your group.
-  1. On the left sidebar, select **Group information > Members**.
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+  1. Select **Manage > Members**.
   1. Give a different member the **Owner** role.
   1. Have the new owner sign in and remove the **Owner** role from you.
 
@@ -301,8 +72,8 @@ create a new group and transfer projects to it instead.
 
 To change your group path (group URL):
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General** page.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Advanced** section.
 1. Under **Change group URL**, enter a new name.
 1. Select **Change group URL**.
@@ -349,7 +120,7 @@ To share a given group, for example, `Frontend` with another group, for example,
 `Engineering`:
 
 1. Go to the `Frontend` group.
-1. On the left sidebar, select **Group information > Members**.
+1. Select **Manage > Members**.
 1. Select **Invite a group**.
 1. In the **Select a group to invite** list, select `Engineering`.
 1. Select a [role](../permissions.md) as maximum access level.
@@ -360,6 +131,22 @@ After sharing the `Frontend` group with the `Engineering` group:
 - The **Groups** tab lists the `Engineering` group.
 - The **Groups** tab lists a group regardless of whether it is a public or private group.
 - All direct members of the `Engineering` group have access to the `Frontend` group. Direct members of `Engineering` that gain access to the `Frontend` group keep their same access level as in `Engineering`, but up to the maximum access level selected when sharing the group. Inherited members of the `Engineering` group do not gain access to the `Frontend` group.
+- All direct members of the `Engineering` group count towards the billable members of the `Frontend` group.
+
+## Remove a shared group
+
+To unshare a group:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Members**.
+1. Select the **Groups** tab.
+1. To the right of the account you want to remove, select **Remove group** (**{remove}**).
+
+For example, if the `Engineering` group is shared with the `Frontend` group, when
+you unshare the `Engineering` group:
+
+- All direct members of the `Engineering` group no longer have access to the `Frontend` group.
+- Members of the `Engineering` group no longer count towards the billable members of the `Frontend` group.
 
 ## Transfer a group
 
@@ -387,55 +174,13 @@ When transferring groups, note:
 
 To transfer a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Advanced** section.
 1. In the **Remove group** section, select **Transfer group**.
 1. Select the group name in the drop down menu.
 1. Select **Transfer group**.
 
-## Enable delayed project deletion **(PREMIUM)**
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2.
-> - [Inheritance and enforcement added](https://gitlab.com/gitlab-org/gitlab/-/issues/321724) in GitLab 13.11.
-> - [Instance setting to enable by default added](https://gitlab.com/gitlab-org/gitlab/-/issues/255449) in GitLab 14.2.
-> - [Instance setting is inherited and enforced when disabled](https://gitlab.com/gitlab-org/gitlab/-/issues/352960) in GitLab 15.1.
-> - [User interface changed](https://gitlab.com/gitlab-org/gitlab/-/issues/352961) in GitLab 15.1.
-> - [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/389557) in GitLab 15.11 [with a flag](../../administration/feature_flags.md) named `always_perform_delayed_deletion`. Disabled by default.
-> - Enabled delayed deletion by default and removed the option to delete immediately [on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622) on May 08, 2023.
-> - Enabled delayed deletion by default and removed the option to delete immediately [on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606) in GitLab 16.0.
-
-[Delayed project deletion](../project/settings/index.md#delayed-project-deletion) is locked and disabled unless the instance-level settings for
-[deletion protection](../admin_area/settings/visibility_and_access_controls.md#deletion-protection) are enabled for either groups only or groups and projects.
-When enabled on groups, projects in the group are deleted after a period of delay. During this period, projects are in a read-only state and can be restored.
-The default period is seven days but [is configurable at the instance level](../admin_area/settings/visibility_and_access_controls.md#retention-period).
-
-On self-managed GitLab, projects are deleted immediately by default.
-In GitLab 14.2 and later, an administrator can
-[change the default setting](../admin_area/settings/visibility_and_access_controls.md#deletion-protection)
-for projects in newly-created groups.
-
-On GitLab.com, see the [GitLab.com settings page](../gitlab_com/index.md#delayed-project-deletion) for
-the default setting.
-
-To enable delayed deletion of projects in a group:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Permissions and group features** section.
-1. Scroll to:
-   - (GitLab 15.1 and later) **Deletion protection** and select **Keep deleted projects**.
-   - (GitLab 15.0 and earlier) **Enable delayed project deletion** and tick the checkbox.
-1. Optional. To prevent subgroups from changing this setting, select:
-   - (GitLab 15.1 and later), **Enforce deletion protection for all subgroups**
-   - (GitLab 15.0 and earlier), **Enforce for all subgroups**.
-1. Select **Save changes**.
-
-In GitLab 13.11 and later, the group setting for delayed project deletion is inherited by subgroups. As discussed in [Cascading settings](../../development/cascading_settings.md), inheritance can be overridden unless enforced by an ancestor.
-
-In GitLab 15.11 with the `always_perform_delayed_deletion` feature flag enabled, this setting is removed
-and all projects are deleted after the [retention period defined by the admin](../admin_area/settings/visibility_and_access_controls.md#retention-period). This will be the default behavior in GitLab 16.0 and later.
-
 ## Disable email notifications
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/23585) in GitLab 12.2.
@@ -444,8 +189,8 @@ You can disable all email notifications related to the group, which includes its
 
 To disable email notifications:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Permissions and group features** section.
 1. Select **Email notifications are disabled**.
 1. Select **Save changes**.
@@ -464,8 +209,8 @@ This is particularly helpful for groups with a large number of users.
 
 To disable group mentions:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Permissions and group features** section.
 1. Select **Group mentions are disabled**.
 1. Select **Save changes**.
@@ -477,8 +222,8 @@ To disable group mentions:
 
 You can export a list of members in a group or subgroup as a CSV.
 
-1. On the top bar, select **Main menu > Groups** and find your group or subgroup.
-1. On the left sidebar, select either **Group information > Members** or **Subgroup information > Members**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group or subgroup.
+1. On the left sidebar,  **Manage > Members**.
 1. Select **Export as CSV**.
 1. After the CSV file has been generated, it is emailed as an attachment to the user that requested it.
 
@@ -508,9 +253,9 @@ Prerequisite:
 
 To specify a user cap:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
    You can set a cap on the top-level group only.
-1. On the left sidebar, select **Settings > General**.
+1. Select **Settings > General**.
 1. Expand **Permissions and group features**.
 1. In the **User cap** box, enter the desired number of users.
 1. Select **Save changes**.
@@ -530,8 +275,8 @@ Prerequisite:
 
 To remove the user cap:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand **Permissions and group features**.
 1. In the **User cap** box, delete the value.
 1. Select **Save changes**.
@@ -551,7 +296,7 @@ Prerequisite:
 
 To approve members that are pending because they've exceeded the user cap:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. On the left sidebar, select **Settings > Usage Quotas**.
 1. On the **Seats** tab, under the alert, select **View pending approvals**.
 1. For each member you want to approve, select **Approve**.
@@ -582,8 +327,8 @@ For more information, see [group-level project templates](custom_project_templat
 
 To enable group file templates:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Templates** section.
 1. Choose a project to act as the template repository.
 1. Select **Save changes**.
@@ -615,8 +360,8 @@ Prerequisites:
 
 To enable this setting:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand **Merge requests**.
 1. Under **Merge checks**, select **Pipelines must succeed**.
    This setting also prevents merge requests from being merged if there is no pipeline.
@@ -634,8 +379,8 @@ Prerequisite:
 
 To change this behavior:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand **Merge requests**.
 1. Under **Merge checks**:
    - Select **Pipelines must succeed**.
@@ -653,8 +398,8 @@ Prerequisite:
 
 To enable this setting:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand **Merge requests**.
 1. Under **Merge checks**, select **All threads must be resolved**.
 1. Select **Save changes**.
@@ -666,91 +411,94 @@ To enable this setting:
 > - [Feature flag `group_merge_request_approval_settings_feature_flag`](https://gitlab.com/gitlab-org/gitlab/-/issues/343872) removed in GitLab 14.9.
 
 Group approval settings manage [project merge request approval settings](../project/merge_requests/approvals/settings.md)
-at the top-level group level. These settings [cascade to all projects](../project/merge_requests/approvals/settings.md#settings-cascading)
+for all projects in a top-level group. These settings [cascade to all projects](../project/merge_requests/approvals/settings.md#settings-cascading)
 that belong to the group.
 
 To view the merge request approval settings for a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand the **Merge request approvals** section.
 1. Select the settings you want.
 1. Select **Save changes**.
 
-Support for group-level settings for merge request approval rules is tracked in this [epic](https://gitlab.com/groups/gitlab-org/-/epics/4367).
+Approval settings should not be confused with [approval rules](../project/merge_requests/approvals/rules.md). Support
+for the ability to set merge request approval rules for groups is tracked in
+[epic 4367](https://gitlab.com/groups/gitlab-org/-/epics/4367).
 
-## Group Code Suggestions **(FREE SAAS)**
+## Enable Code Suggestions **(FREE SAAS)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/405126) in GitLab 15.11.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/408158) from GitLab Ultimate to GitLab Premium in 16.0.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/410801) from GitLab Premium to GitLab Free in 16.0.
 
 WARNING:
-This feature is in [Beta](../../policy/alpha-beta-support.md#beta).
-Code Suggestions use generative AI to suggest code while you're developing.
-Due to high demand, this feature will have unscheduled downtime and code suggestions in VS Code may be delayed.
+This feature is in [Beta](../../policy/experiment-beta-support.md#beta).
+Due to high demand, this feature may have unscheduled downtime and Code Suggestions in IDEs may be delayed.
 Code Suggestions may produce
 [low-quality or incomplete suggestions](../project/repository/code_suggestions.md#model-accuracy-and-quality).
 Beta users should read about the [known limitations](../project/repository/code_suggestions.md#known-limitations).
 We look forward to hearing your feedback.
 
-This setting enables users in the group to access [Code Suggestions](../project/repository/code_suggestions.md).
-This setting [cascades to all projects](../project/merge_requests/approvals/settings.md#settings-cascading)
-that belong to the group.
+You can give all users in a group and its subgroups access to [Code Suggestions](../project/repository/code_suggestions.md).
+
+- This setting
+  [cascades to all projects](../project/merge_requests/approvals/settings.md#settings-cascading) in the group.
+- Each user can
+  [enable or disable Code Suggestions for themselves](../project/repository/code_suggestions.md#enable-code-suggestions-for-an-individual-user).
 
 To enable Code Suggestions for a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Permissions and group features** section.
-1. Find the **Code Suggestions** settings.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
+1. Expand **Permissions and group features**.
+1. Under **Code Suggestions**, select the **Projects in this group can use Code Suggestions** checkbox.
 1. Select **Save changes**.
 
-## Group Experiment features setting **(ULTIMATE SAAS)**
+## Enable Experiment features **(ULTIMATE SAAS)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404856) in GitLab 16.0.
 
-You can give all users in the group access to Experiment features.
-
 WARNING:
-[Experiment features](../../policy/alpha-beta-support.md#experiment) may produce unexpected results
+[Experiment features](../../policy/experiment-beta-support.md#experiment) may produce unexpected results
 (for example, the results might be low-quality, incomplete, incoherent, offensive, or insensitive,
 and might include insecure code or failed pipelines).
 
+You can give all users in a top-level group access to Experiment features.
 This setting [cascades to all projects](../project/merge_requests/approvals/settings.md#settings-cascading)
 that belong to the group.
 
-To enable Experiment features for a group:
+To enable Experiment features for a top-level group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Permissions and group features** section.
-1. Find the **Experiment features** settings.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
+1. Expand **Permissions and group features**.
+1. Under **Experiment features**, select the **Use Experiment features** checkbox.
 1. Select **Save changes**.
 
-## Group third-party AI features setting **(ULTIMATE SAAS)**
+## Enable third-party AI features **(ULTIMATE SAAS)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404856) in GitLab 16.0.
 
 WARNING:
-These Artifical Intelligence (AI) features use [third-party services](../ai_features.md#data-usage)
+These AI features use [third-party services](../ai_features.md#data-usage)
 and require transmission of data, including personal data.
 
-You can give all users in the group access to third-party AI features.
+All users in the group have third-party AI features enabled by default.
 This setting [cascades to all projects](../project/merge_requests/approvals/settings.md#settings-cascading)
 that belong to the group.
 
-To enable third-party AI features for a group:
+To disable third-party AI features for a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Permissions and group features** section.
-1. Find the **Third-party Artificial Intelligence (AI) features** settings.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
+1. Expand **Permissions and group features**.
+1. Under **Third-party AI services**, uncheck the **Use third-party AI services** checkbox.
 1. Select **Save changes**.
 
 ## Group activity analytics **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207164) in GitLab 12.10 as a [Beta feature](../../policy/alpha-beta-support.md#beta).
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207164) in GitLab 12.10 as a [Beta feature](../../policy/experiment-beta-support.md#beta).
 
 For a group, you can view how many merge requests, issues, and members were created in the last 90 days.
 
@@ -764,105 +512,8 @@ Changes to [group wikis](../project/wiki/group.md) do not appear in group activi
 
 You can view the most recent actions taken in a group, either in your browser or in an RSS feed:
 
-1. On the top bar, select **Main menu > Groups > View all groups** and find your group.
-1. On the left sidebar, select **Group information > Activity**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. On the left sidebar, select **Manage > Activity**.
 
 To view the activity feed in Atom format, select the
 **RSS** (**{rss}**) icon.
-
-## Troubleshooting
-
-### Validation errors on namespaces and groups
-
-[GitLab 14.4 and later](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/70365) performs
-the following checks when creating or updating namespaces or groups:
-
-- Namespaces must not have parents.
-- Group parents must be groups and not namespaces.
-
-In the unlikely event that you see these errors in your GitLab installation,
-[contact Support](https://about.gitlab.com/support/) so that we can improve this validation.
-
-### Find groups using an SQL query
-
-To find and store an array of groups based on an SQL query in the [rails console](../../administration/operations/rails_console.md):
-
-```ruby
-# Finds groups and subgroups that end with '%oup'
-Group.find_by_sql("SELECT * FROM namespaces WHERE name LIKE '%oup'")
-=> [#<Group id:3 @test-group>, #<Group id:4 @template-group/template-subgroup>]
-```
-
-### Transfer subgroup to another location using Rails console
-
-If transferring a group doesn't work through the UI or API, you may want to attempt the transfer in a [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session):
-
-WARNING:
-Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
-
-```ruby
-user = User.find_by_username('<username>')
-group = Group.find_by_name("<group_name>")
-## Set parent_group = nil to make the subgroup a top-level group
-parent_group = Group.find_by(id: "<group_id>")
-service = ::Groups::TransferService.new(group, user)
-service.execute(parent_group)
-```
-
-### Find groups pending deletion using Rails console
-
-If you need to find all the groups that are pending deletion, you can use the following command in a [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session):
-
-```ruby
-Group.all.each do |g|
- if g.marked_for_deletion?
-    puts "Group ID: #{g.id}"
-    puts "Group name: #{g.name}"
-    puts "Group path: #{g.full_path}"
- end
-end
-```
-
-### Delete a group using Rails console
-
-At times, a group deletion may get stuck. If needed, in a [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session),
-you can attempt to delete a group using the following command:
-
-WARNING:
-Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
-
-```ruby
-GroupDestroyWorker.new.perform(group_id, user_id)
-```
-
-### Find a user's maximum permissions for a group or project
-
-Administrators can find a user's maximum permissions for a group or project.
-
-1. Start a [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session).
-1. Run the following commands:
-
-   ```ruby
-   user = User.find_by_username 'username'
-   project = Project.find_by_full_path 'group/project'
-   user.max_member_access_for_project project.id
-   ```
-
-   ```ruby
-   user = User.find_by_username 'username'
-   group = Group.find_by_full_path 'group'
-   user.max_member_access_for_group group.id
-   ```
-
-### Unable to remove billable members with badge `Project Invite/Group Invite`
-
-```plaintext
-Members who were invited via a group invitation cannot be removed. You can either remove the entire group, or ask an Owner of the invited group to remove the member.
-```
-
-This error typically occurs when the user you're trying to remove is part of an external group that has been [shared with one or more of your projects](../project/members/share_project_with_groups.md) or [groups](#share-a-group-with-another-group). To remove the user as a billable member, follow one of the options:
-
-- Remove the invited group membership from your project or group members page.
-- Recommended. Remove the user directly from the invited group, if you have access to the group.
-
-The feature request to **Update billable_members endpoint to include invited group** is currently being worked on. For more information, see [issue 386583](https://gitlab.com/gitlab-org/gitlab/-/issues/386583)
diff --git a/doc/user/group/moderate_users.md b/doc/user/group/moderate_users.md
index 4ec86893524..1dde36c5c70 100644
--- a/doc/user/group/moderate_users.md
+++ b/doc/user/group/moderate_users.md
@@ -26,7 +26,7 @@ Prerequisites:
 To unban a user:
 
 1. Go to the top-level group.
-1. On the left sidebar, select **Group information > Members**.
+1. On the left sidebar, select **Manage > Members**.
 1. Select the **Banned** tab.
 1. For the account you want to unban, select **Unban**.
 
@@ -43,6 +43,6 @@ Prerequisites:
 To manually ban a user:
 
 1. Go to the top-level group.
-1. On the left sidebar, select **Group information > Members**.
+1. On the left sidebar, select **Manage > Members**.
 1. Next to the member you want to ban, select the vertical ellipsis (**{ellipsis_v}**).
 1. From the dropdown list, select **Ban member**.
diff --git a/doc/user/group/reporting/git_abuse_rate_limit.md b/doc/user/group/reporting/git_abuse_rate_limit.md
index d5c44f4e245..ee8ac50f021 100644
--- a/doc/user/group/reporting/git_abuse_rate_limit.md
+++ b/doc/user/group/reporting/git_abuse_rate_limit.md
@@ -17,6 +17,10 @@ Git abuse rate limiting is a feature to automatically ban users who download, cl
 
 Git abuse rate limiting does not apply to top-level group owners, [deploy tokens](../../../user/project/deploy_tokens/index.md), or [deploy keys](../../../user/project/deploy_keys/index.md).
 
+How GitLab determines a user's rate limit is under development.
+GitLab team members can view more information in this confidential epic:
+`https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/14`.
+
 ## Automatic ban notifications
 
 If the `limit_unique_project_downloads_per_namespace_user` feature flag is enabled, selected users receive an email when a user is about to be banned.
diff --git a/doc/user/group/repositories_analytics/index.md b/doc/user/group/repositories_analytics/index.md
index c2a4d8175b3..e5ca41accfc 100644
--- a/doc/user/group/repositories_analytics/index.md
+++ b/doc/user/group/repositories_analytics/index.md
@@ -37,8 +37,8 @@ The **Analytics > Repositories** group page displays the average test coverage o
 
 To see the latest code coverage for each project in your group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Analytics > Repositories**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Analyze > Repository analytics**.
 1. In the **Latest test coverage results** section, from the **Select projects** dropdown list, choose the projects you want to check.
 
 You can download code coverage data for specific projects using
@@ -52,8 +52,8 @@ You can get a CSV of the code coverage data for all of the projects in your grou
 
 To get the report:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Analytics > Repositories**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Analyze > Repository analytics**.
 1. Select **Download historic test coverage data (.csv)**.
 1. Select the projects and date range you want to include in the report.
 1. Select **Download test coverage data (.csv)**.
diff --git a/doc/user/group/saml_sso/example_saml_config.md b/doc/user/group/saml_sso/example_saml_config.md
index 524a5d5a9bd..f2db36e80b1 100644
--- a/doc/user/group/saml_sso/example_saml_config.md
+++ b/doc/user/group/saml_sso/example_saml_config.md
@@ -58,7 +58,7 @@ Attribute mapping:
 NOTE:
 Using the **Group ID** source attribute requires users to enter the group ID or object ID when configuring SAML group links. If available, use the **sAMAccountName** source attribute for the friendly group name instead.
 
-[Azure AD limits the number of groups that can be sent in a SAML response to 150](https://support.esri.com/en-us/knowledge-base/000022190'). If a user is a member of more than 150 groups, Azure does not include that user's group claim in the SAML response.
+[Azure AD limits the number of groups that can be sent in a SAML response to 150](https://support.esri.com/en-us/knowledge-base/000022190). If a user is a member of more than 150 groups, Azure does not include that user's group claim in the SAML response.
 
 ## Google Workspace
 
diff --git a/doc/user/group/saml_sso/group_sync.md b/doc/user/group/saml_sso/group_sync.md
index ee59eeb98db..dd455944bf8 100644
--- a/doc/user/group/saml_sso/group_sync.md
+++ b/doc/user/group/saml_sso/group_sync.md
@@ -125,7 +125,8 @@ When global group memberships lock is enabled:
 To enable global group memberships lock:
 
 1. [Configure SAML](../../../integration/saml.md) for your self-managed GitLab instance.
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 1. Ensure the **Lock memberships to SAML synchronization** checkbox is selected.
@@ -225,7 +226,7 @@ in the user's SAML assertion.
 With an Azure AD premium subscription, you can allow up to 500 group IDs to be sent in a SAML token using the
 [Azure AD documentation configuration steps](https://support.esri.com/en/technical-article/000022190).
 
-Otherwise, you can work around this issue by changing the [group claims](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims#configure-the-azure-ad-application-registration-for-group-attributes) to use the `Groups assigned to the application` option instead.
+Otherwise, you can work around this issue by changing the [group claims](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/how-to-connect-fed-group-claims#configure-the-azure-ad-application-registration-for-group-attributes) to use the `Groups assigned to the application` option instead.
 
 ![Manage Group Claims](img/Azure-manage-group-claims.png).
 
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index a54b3fea53e..5838b9821de 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -38,8 +38,8 @@ If you are having issues setting up your identity provider, see the
 
 To set up SSO with Azure as your identity provider:
 
-1. In GitLab, on the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > SAML SSO**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > SAML SSO**.
 1. Note the information on this page.
 1. Go to Azure and [follow the instructions for configuring SSO for an application](https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/add-application-portal-setup-sso). The following GitLab settings correspond to the Azure fields.
 
@@ -71,8 +71,8 @@ For more information, see an [example configuration page](example_saml_config.md
 
 To set up Google Workspace as your identity provider:
 
-1. In GitLab, on the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > SAML SSO**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > SAML SSO**.
 1. Note the information on this page.
 1. Follow the instructions for [setting up SSO with Google as your identity provider](https://support.google.com/a/answer/6087519?hl=en). The following GitLab settings correspond to the Google Workspace fields.
 
@@ -115,8 +115,8 @@ View a demo of [how to configure SAML with Google Workspaces and set up Group Sy
 
 To set up SSO with Okta as your identity provider:
 
-1. In GitLab, on the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > SAML SSO**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > SAML SSO**.
 1. Note the information on this page.
 1. Follow the instructions for [setting up a SAML application in Okta](https://developer.okta.com/docs/guides/build-sso-integration/saml2/main/).
 
@@ -152,8 +152,8 @@ OneLogin supports its own [GitLab (SaaS) application](https://onelogin.service-n
 
 To set up OneLogin as your identity provider:
 
-1. In GitLab, on the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > SAML SSO**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > SAML SSO**.
 1. Note the information on this page.
 1. If you use the OneLogin generic
    [SAML Test Connector (Advanced)](https://onelogin.service-now.com/support?id=kb_article&sys_id=b2c19353dbde7b8024c780c74b9619fb&kb_category=93e869b0db185340d5505eea4b961934),
@@ -179,8 +179,8 @@ To set up OneLogin as your identity provider:
 To configure some identity providers, you need a GitLab metadata URL.
 To find this URL:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > SAML SSO**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > SAML SSO**.
 1. Copy the provided **GitLab metadata URL**.
 1. Follow your identity provider's documentation and paste the metadata URL when it's requested.
 
@@ -208,7 +208,7 @@ To change identity providers:
 
 To migrate users to a new email domain, tell users to:
 
-1. Add their new email as the primary email to their accounts and verify it.
+1. [Add their new email](../../profile/index.md#change-your-primary-email) as the primary email to their accounts and verify it.
 1. Optional. Remove their old email from the account.
 
 If the **NameID** is configured with the email address, [change the **NameID** for users](#manage-user-saml-identity).
@@ -217,8 +217,8 @@ If the **NameID** is configured with the email address, [change the **NameID** f
 
 After you set up your identity provider to work with GitLab, you must configure GitLab to use it for authentication:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > SAML SSO**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > SAML SSO**.
 1. Complete the fields:
    - In the **Identity provider single sign-on URL** field, enter the SSO URL from your identity provider.
    - In the **Certificate fingerprint** field, enter the fingerprint for the SAML token signing certificate.
@@ -432,7 +432,7 @@ group owner, and then you can unlink the account.
 
 For example, to unlink the `MyOrg` account:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Account**.
 1. In the **Service sign-in** section, select **Disconnect** next to the connected account.
diff --git a/doc/user/group/saml_sso/scim_setup.md b/doc/user/group/saml_sso/scim_setup.md
index 38a1c4125aa..e5d6c86a5ac 100644
--- a/doc/user/group/saml_sso/scim_setup.md
+++ b/doc/user/group/saml_sso/scim_setup.md
@@ -25,8 +25,8 @@ Prerequisites:
 
 To configure GitLab SAML SSO SCIM:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > SAML SSO**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > SAML SSO**.
 1. Select **Generate a SCIM token**.
 1. For configuration of your identity provider, save the:
    - Token from the **Your SCIM token** field.
@@ -190,8 +190,7 @@ During provisioning:
 
 - Both primary and secondary emails are considered when checking whether a GitLab user account exists.
 - Duplicate usernames are handled by adding suffix `1` when creating the user. For example, if `test_user` already
-  exists, `test_user1` is used. If `test_user1` already exists, GitLab increments the suffix until an unused username
-  is found.
+  exists, `test_user1` is used. If `test_user1` already exists, GitLab increments the suffix to find an unused username. If no unused username is found after 4 tries, a random string is attached to the username.
 
 On subsequent visits, new and existing users can access groups either:
 
diff --git a/doc/user/group/settings/group_access_tokens.md b/doc/user/group/settings/group_access_tokens.md
index 4a2bfd4c4b4..e264778062b 100644
--- a/doc/user/group/settings/group_access_tokens.md
+++ b/doc/user/group/settings/group_access_tokens.md
@@ -57,8 +57,8 @@ all projects that have visibility level set to [Internal](../../public_access.md
 
 To create a group access token:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Access Tokens**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Access Tokens**.
 1. Enter a name. The token name is visible to any user with permissions to view the group.
 1. Enter an expiry date for the token:
    - The token expires on that date at midnight UTC.
@@ -119,8 +119,8 @@ or API. However, administrators can use a workaround:
 
 To revoke a group access token:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Access Tokens**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Access Tokens**.
 1. Next to the group access token to revoke, select **Revoke**.
 
 ## Revoke a group access token using Rails console
@@ -153,8 +153,8 @@ The scope determines the actions you can perform when you authenticate with a gr
 
 To enable or disable group access token creation for all subgroups in a top-level group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand **Permissions and group features**.
 1. Under **Permissions**, turn on or off **Users can create project access tokens and group access tokens in this group**.
 
@@ -168,7 +168,7 @@ These bot users are similar to
 [bot users for projects](../../project/settings/project_access_tokens.md#bot-users-for-projects), except they are added
 to groups instead of projects. Bot users for groups:
 
-- Do not count as licensed seats.
+- Is not a billable user, so it does not count toward the license limit.
 - Can have a maximum role of Owner for a group. For more information, see
   [Create a group access token](../../../api/group_access_tokens.md#create-a-group-access-token).
 - Have a username set to `group_{group_id}_bot_{random_string}`. For example, `group_123_bot_4ffca233d8298ea1`.
diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md
index 63ffbf62981..81e972bf73b 100644
--- a/doc/user/group/subgroups/index.md
+++ b/doc/user/group/subgroups/index.md
@@ -56,7 +56,7 @@ the private subgroup.
 
 To view the subgroups of a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. Select the **Subgroups and projects** tab.
 1. To view a nested subgroup, expand a subgroup in the hierarchy list.
 
@@ -84,7 +84,7 @@ You cannot host a GitLab Pages subgroup website with a top-level domain name. Fo
 
 To create a subgroup:
 
-1. On the top bar, select **Main menu > Groups** and find and select the parent group to add a subgroup to.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find a parent group for the subgroup.
 1. On the parent group's overview page, in the upper-right corner, select **New subgroup**.
 1. Select **Create group**.
 1. Fill in the fields. View a list of [reserved names](../../reserved_names.md) that cannot be used as group names.
@@ -99,13 +99,14 @@ Prerequisite:
 To change who can create subgroups on a group:
 
 - As a user with the Owner role on the group:
-  1. On the top bar, select **Main menu > Groups** and find your group.
-  1. On the left sidebar, select **Settings > General**.
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+  1. Select **Settings > General**.
   1. Expand **Permissions and group features**.
   1. Select a role from **Roles allowed to create subgroups**.
   1. Select **Save changes**.
 - As an administrator:
-  1. On the top bar, select **Main menu > Admin**.
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
   1. On the left sidebar, select **Overview > Groups**.
   1. In the group's row select **Edit**.
   1. Select a role from **Allowed to create subgroups**.
@@ -160,8 +161,8 @@ Group permissions for a member can be changed only by:
 
 To see if a member has inherited the permissions from a parent group:
 
-1. On the top bar, select **Main menu > Groups** and find the group.
-1. Select **Group information > Members**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Members**.
 
 Members list for an example subgroup _Four_:
 
@@ -184,7 +185,7 @@ In the screenshot above:
 - Administrator has the Owner role on group _Four_ and is a member of all subgroups. For that reason, as with User 3,
   the **Source** column indicates they are a direct member.
 
-Members can be [filtered by inherited or direct membership](../manage.md#filter-a-group).
+Members can be [filtered by inherited or direct membership](../index.md#filter-a-group).
 
 ### Override ancestor group membership
 
diff --git a/doc/user/group/troubleshooting.md b/doc/user/group/troubleshooting.md
new file mode 100644
index 00000000000..6de90053c21
--- /dev/null
+++ b/doc/user/group/troubleshooting.md
@@ -0,0 +1,102 @@
+---
+stage: Data Stores
+group: Tenant Scale
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Troubleshooting groups
+
+## Validation errors on namespaces and groups
+
+[GitLab 14.4 and later](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/70365) performs
+the following checks when creating or updating namespaces or groups:
+
+- Namespaces must not have parents.
+- Group parents must be groups and not namespaces.
+
+In the unlikely event that you see these errors in your GitLab installation,
+[contact Support](https://about.gitlab.com/support/) so that we can improve this validation.
+
+## Find groups using an SQL query
+
+To find and store an array of groups based on an SQL query in the [rails console](../../administration/operations/rails_console.md):
+
+```ruby
+# Finds groups and subgroups that end with '%oup'
+Group.find_by_sql("SELECT * FROM namespaces WHERE name LIKE '%oup'")
+=> [#<Group id:3 @test-group>, #<Group id:4 @template-group/template-subgroup>]
+```
+
+## Transfer subgroup to another location using Rails console
+
+If transferring a group doesn't work through the UI or API, you may want to attempt the transfer in a [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session):
+
+WARNING:
+Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
+
+```ruby
+user = User.find_by_username('<username>')
+group = Group.find_by_name("<group_name>")
+## Set parent_group = nil to make the subgroup a top-level group
+parent_group = Group.find_by(id: "<group_id>")
+service = ::Groups::TransferService.new(group, user)
+service.execute(parent_group)
+```
+
+## Find groups pending deletion using Rails console
+
+If you need to find all the groups that are pending deletion, you can use the following command in a [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session):
+
+```ruby
+Group.all.each do |g|
+ if g.marked_for_deletion?
+    puts "Group ID: #{g.id}"
+    puts "Group name: #{g.name}"
+    puts "Group path: #{g.full_path}"
+ end
+end
+```
+
+## Delete a group using Rails console
+
+At times, a group deletion may get stuck. If needed, in a [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session),
+you can attempt to delete a group using the following command:
+
+WARNING:
+Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
+
+```ruby
+GroupDestroyWorker.new.perform(group_id, user_id)
+```
+
+## Find a user's maximum permissions for a group or project
+
+Administrators can find a user's maximum permissions for a group or project.
+
+1. Start a [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session).
+1. Run the following commands:
+
+   ```ruby
+   user = User.find_by_username 'username'
+   project = Project.find_by_full_path 'group/project'
+   user.max_member_access_for_project project.id
+   ```
+
+   ```ruby
+   user = User.find_by_username 'username'
+   group = Group.find_by_full_path 'group'
+   user.max_member_access_for_group group.id
+   ```
+
+## Unable to remove billable members with badge `Project Invite/Group Invite`
+
+```plaintext
+Members who were invited via a group invitation cannot be removed. You can either remove the entire group, or ask an Owner of the invited group to remove the member.
+```
+
+This error typically occurs when the user you're trying to remove is part of an external group that has been [shared with one or more of your projects](../project/members/share_project_with_groups.md) or [groups](manage.md#share-a-group-with-another-group). To remove the user as a billable member, follow one of the options:
+
+- Remove the invited group membership from your project or group members page.
+- Recommended. Remove the user directly from the invited group, if you have access to the group.
+
+The feature request to **Update billable_members endpoint to include invited group** is currently being worked on. For more information, see [issue 386583](https://gitlab.com/gitlab-org/gitlab/-/issues/386583)
diff --git a/doc/user/group/value_stream_analytics/index.md b/doc/user/group/value_stream_analytics/index.md
index bc48c1050fb..952552fc648 100644
--- a/doc/user/group/value_stream_analytics/index.md
+++ b/doc/user/group/value_stream_analytics/index.md
@@ -51,6 +51,9 @@ Value stream analytics offers different features at the project and group level
 |Date filter behavior|Filters items [finished within the date range](https://gitlab.com/groups/gitlab-org/-/epics/6046)|Filters items by creation date.|Filters items by creation date.|
 |Authorization|At least reporter|At least reporter|Can be public|
 
+NOTE:
+Feature parity of project-level with group-level value stream analytics is achieved by using the new record `ProjectNamespace`. For details about this consolidation initiative, see the [Organization documentation](../../../development/organization/index.md).
+
 ## How value stream analytics works
 
 Value stream analytics calculates the duration of every stage of your software development process.
@@ -206,10 +209,8 @@ Prerequisites:
 
 To view value stream analytics for your group or project:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Analytics > Value stream**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Analyze > Value stream analytics**.
 1. To view metrics for a particular stage, select a stage below the **Filter results** text box.
 1. Optional. Filter the results:
    1. Select the **Filter results** text box.
@@ -298,10 +299,8 @@ Prerequisite:
 
 To view key lifecycle metrics:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Analytics > Value stream**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Analyze > Value stream analytics**.
    Key metrics display below the **Filter results** text box.
 1. Optional. Filter the results:
    1. Select the **Filter results** text box.
@@ -314,10 +313,8 @@ To view key lifecycle metrics:
 
 To view the [Value Streams Dashboard](../../analytics/value_streams_dashboard.md) and [DORA metrics](../../analytics/dora_metrics.md):
 
-1. On the top bar, select **Main menu**, and:
-    - For a project, select **Projects** and find your project.
-    - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Analytics > Value stream**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Analyze > Value stream analytics**.
 1. Below the **Filter results** text box, in the **Key metrics** row, select **Value Streams Dashboard / DORA**.
 1. Optional. To open the new page, append this path `/analytics/dashboards/value_streams_dashboard` to the group URL
    (for example, `https://gitlab.com/groups/gitlab-org/-/analytics/dashboards/value_streams_dashboard`).
@@ -331,10 +328,8 @@ Value stream analytics shows the median time spent by issues or merge requests i
 
 To view the median time spent in each stage by a group:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Analytics > Value stream**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Analyze > Value stream analytics**.
 1. Optional. Filter the results:
    1. Select the **Filter results** text box.
    1. Select a parameter.
@@ -357,8 +352,8 @@ group and time frame.
 
 To view tasks by type:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Analytics > Value stream**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Analyze > Value stream analytics**.
 1. Below the **Filter results** text box, select **Overview**. The **Tasks by type** chart displays below the **Total time** chart.
 1. To switch between the task type, select the **Settings** (**{settings}**) dropdown list
    and select **Issues** or **Merge Requests**.
@@ -374,10 +369,8 @@ To view tasks by type:
 When you create a value stream, you can use GitLab default stages and hide or re-order them. You can also
 create custom stages in addition to those provided in the default template.
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Analytics > Value Stream**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Analyze > Value Stream analytics**.
 1. Select **Create new Value Stream**.
 1. Enter a name for the value stream.
 1. Select **Create from default template**.
@@ -400,10 +393,8 @@ If you have recently upgraded to GitLab Premium, it can take up to 30 minutes fo
 
 When you create a value stream, you can create and add custom stages that align with your own development workflows.
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Analytics > Value Stream**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Analyze > Value Stream analytics**.
 1. Select **Create value stream**.
 1. For each stage:
    - Enter a name for the stage.
@@ -436,10 +427,8 @@ The first value stream uses standard timestamp-based events for defining the sta
 
 After you create a value stream, you can customize it to suit your purposes. To edit a value stream:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Analytics > Value Stream**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Analyze > Value Stream analytics**.
 1. In the upper-right corner, select the dropdown list, then select a value stream.
 1. Next to the value stream dropdown list, select **Edit**.
 1. Optional:
@@ -457,9 +446,7 @@ After you create a value stream, you can customize it to suit your purposes. To
 
 To delete a custom value stream:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
 1. In the upper-right corner, select the dropdown list, then select the value stream you would like to delete.
 1. Select **Delete (name of value stream)**.
 1. To confirm, select **Delete**.
@@ -474,10 +461,8 @@ To delete a custom value stream:
 The **Total time chart** shows the average number of days it takes for development cycles to complete.
 The chart shows data for the last 500 workflow items.
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Analytics > Value stream**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Analyze > Value stream analytics**.
 1. Above the **Filter results** box, select a stage:
    - To view a summary of the cycle time for all stages, select **Overview**.
    - To view the cycle time for specific stage, select a stage.
diff --git a/doc/user/img/explain_this_vulnerability.png b/doc/user/img/explain_this_vulnerability.png
index 0880ad5f875..bb938241911 100644
--- a/doc/user/img/explain_this_vulnerability.png
+++ b/doc/user/img/explain_this_vulnerability.png
diff --git a/doc/user/infrastructure/clusters/connect/index.md b/doc/user/infrastructure/clusters/connect/index.md
index b571a65b50a..01911f2b889 100644
--- a/doc/user/infrastructure/clusters/connect/index.md
+++ b/doc/user/infrastructure/clusters/connect/index.md
@@ -34,17 +34,18 @@ your cluster's level.
 
 **Project-level clusters:**
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Kubernetes clusters**.
 
 **Group-level clusters:**
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Kubernetes**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Operate > Kubernetes clusters**.
 
 **Instance-level clusters:**
 
-1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
 1. On the left sidebar, select **Kubernetes**.
 
 ## Security implications for clusters connected with certificates
diff --git a/doc/user/infrastructure/clusters/connect/new_civo_cluster.md b/doc/user/infrastructure/clusters/connect/new_civo_cluster.md
index 45445c0a0f5..7c8065b6143 100644
--- a/doc/user/infrastructure/clusters/connect/new_civo_cluster.md
+++ b/doc/user/infrastructure/clusters/connect/new_civo_cluster.md
@@ -35,7 +35,8 @@ Start by [importing the example project by URL](../../../project/import/repo_by_
 
 To import the project:
 
-1. In GitLab, on the top bar, select **Main menu > Projects > View all projects**.
+1. In GitLab, on the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your projects**..
 1. On the right of the page, select **New project**.
 1. Select **Import project**.
 1. Select **Repository by URL**.
diff --git a/doc/user/infrastructure/clusters/connect/new_eks_cluster.md b/doc/user/infrastructure/clusters/connect/new_eks_cluster.md
index 4516ea538a9..19bcce581e9 100644
--- a/doc/user/infrastructure/clusters/connect/new_eks_cluster.md
+++ b/doc/user/infrastructure/clusters/connect/new_eks_cluster.md
@@ -34,7 +34,8 @@ Start by [importing the example project by URL](../../../project/import/repo_by_
 
 To import the project:
 
-1. In GitLab, on the top bar, select **Main menu > Projects > View all projects**.
+1. In GitLab, on the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your projects**.
 1. On the right of the page, select **New project**.
 1. Select **Import project**.
 1. Select **Repository by URL**.
diff --git a/doc/user/infrastructure/clusters/connect/new_gke_cluster.md b/doc/user/infrastructure/clusters/connect/new_gke_cluster.md
index c8d2fb674b2..25a0a7149e0 100644
--- a/doc/user/infrastructure/clusters/connect/new_gke_cluster.md
+++ b/doc/user/infrastructure/clusters/connect/new_gke_cluster.md
@@ -41,7 +41,8 @@ Start by [importing the example project by URL](../../../project/import/repo_by_
 
 To import the project:
 
-1. In GitLab, on the top bar, select **Main menu > Projects > View all projects**.
+1. In GitLab, on the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your projects**.
 1. On the right of the page, select **New project**.
 1. Select **Import project**.
 1. Select **Repository by URL**.
diff --git a/doc/user/infrastructure/iac/index.md b/doc/user/infrastructure/iac/index.md
index d4fc345f494..12ad207e4f8 100644
--- a/doc/user/infrastructure/iac/index.md
+++ b/doc/user/infrastructure/iac/index.md
@@ -64,8 +64,8 @@ In each GitLab major release (for example, 15.0), the latest templates replace t
 
 To use a Terraform template:
 
-1. On the top bar, select **Main menu > Projects** and find the project you want to integrate with Terraform.
-1. On the left sidebar, select **Repository > Files**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project you want to integrate with Terraform.
+1. Select **Code > Repository**.
 1. Edit your `.gitlab-ci.yml` file, use the `include` attribute to fetch the Terraform template:
 
    ```yaml
@@ -73,7 +73,7 @@ To use a Terraform template:
     # To fetch the latest template, use:
      - template: Terraform.latest.gitlab-ci.yml
     # To fetch the advanced latest template, use:
-     - template: Terraform/Base.latest.gitlab-ci.yml 
+     - template: Terraform/Base.latest.gitlab-ci.yml
     # To fetch the stable template, use:
      - template: Terraform.gitlab-ci.yml
     # To fetch the advanced stable template, use:
diff --git a/doc/user/infrastructure/iac/terraform_state.md b/doc/user/infrastructure/iac/terraform_state.md
index 1b0065fd165..455f2ce19e8 100644
--- a/doc/user/infrastructure/iac/terraform_state.md
+++ b/doc/user/infrastructure/iac/terraform_state.md
@@ -116,8 +116,8 @@ inconsistent. Instead, use a remote storage resource.
    [initialized for CI/CD](#initialize-a-terraform-state-as-a-backend-by-using-gitlab-cicd).
 1. Copy a pre-populated Terraform `init` command:
 
-   1. On the top bar, select **Main menu > Projects** and find your project.
-   1. On the left sidebar, select **Infrastructure > Terraform states**.
+   1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+   1. Select **Operate > Terraform states**.
    1. Next to the environment you want to use, select **Actions**
       (**{ellipsis_v}**) and select **Copy Terraform init command**.
 
@@ -294,8 +294,8 @@ To read the Terraform state in the target project, you need at least the Develop
 
 To view Terraform state files:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Infrastructure > Terraform states**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Terraform states**.
 
 [An epic exists](https://gitlab.com/groups/gitlab-org/-/epics/4563) to track improvements to this UI.
 
diff --git a/doc/user/instance/clusters/index.md b/doc/user/instance/clusters/index.md
index dc5d402d04b..51a4499d716 100644
--- a/doc/user/instance/clusters/index.md
+++ b/doc/user/instance/clusters/index.md
@@ -21,8 +21,9 @@ projects.
 
 To view the instance level Kubernetes clusters:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Kubernetes**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Kubernetes**.
 
 ## Cluster precedence
 
diff --git a/doc/user/markdown.md b/doc/user/markdown.md
index b8ed1c06324..401fe0bcb09 100644
--- a/doc/user/markdown.md
+++ b/doc/user/markdown.md
@@ -567,13 +567,12 @@ This example links to `<wiki_root>/miscellaneous.md`:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/322174) in GitLab 15.10.
 
-NOTE:
-Use of the diagrams.net editor is not available on offline environments.
-
 In wikis, you can use the [diagrams.net](https://www.diagrams.net/) editor to create diagrams. You
 can also edit diagrams created with the diagrams.net editor. The diagram editor is available in both
 the Markdown editor and the content editor.
 
+For more information, see [Diagrams.net](../administration/integration/diagrams_net.md).
+
 ##### Markdown editor
 
 To create a diagram in the Markdown editor:
@@ -631,7 +630,7 @@ GitLab Flavored Markdown recognizes the following:
 |:----------------------------------------------------------------------------|:------------------------------|:----------------------------------------|:-------------------------------|
 | specific user                                                               | `@user_name`                  |                                         |                                |
 | specific group                                                              | `@group_name`                 |                                         |                                |
-| entire team                                                                 | `@all`                        |                                         |                                |
+| entire team                                                                 | [`@all`](discussions/index.md#mentioning-all-members)                        |                                         |                                |
 | project                                                                     | `namespace/project>`          |                                         |                                |
 | issue                                                                       | ``#123``                      | `namespace/project#123`                 | `project#123`                  |
 | merge request                                                               | `!123`                        | `namespace/project!123`                 | `project!123`                  |
diff --git a/doc/user/okrs.md b/doc/user/okrs.md
index 030f6eb82ef..2abaf9f8008 100644
--- a/doc/user/okrs.md
+++ b/doc/user/okrs.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/103355) in GitLab 15.6 [with a flag](../administration/feature_flags.md) named `okrs_mvc`. Disabled by default.
 
-OKRs are an [Experiment](../policy/alpha-beta-support.md#experiment).
+OKRs are an [Experiment](../policy/experiment-beta-support.md#experiment).
 For the OKR feature roadmap, see [epic 7864](https://gitlab.com/groups/gitlab-org/-/epics/7864).
 
 FLAG:
@@ -60,8 +60,8 @@ Prerequisites:
 
 To create an objective:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Plan > Issues**.
 1. In the upper-right corner, next to **New issue**, select the down arrow **{chevron-lg-down}** and then select **New objective**.
 1. Select **New objective** again.
 1. Enter the objective title.
@@ -77,8 +77,8 @@ Prerequisites:
 
 To view an objective:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Plan > Issues**.
 1. [Filter the list of issues](project/issues/managing_issues.md#filter-the-list-of-issues)
 for `Type = objective`.
 1. Select the title of an objective from the list.
@@ -91,8 +91,8 @@ Prerequisites:
 
 To view a key result:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Plan > Issues**.
 1. [Filter the list of issues](project/issues/managing_issues.md#filter-the-list-of-issues)
 for `Type = key_result`.
 1. Select the title of a key result from the list.
@@ -222,7 +222,8 @@ To set health status of an OKR:
 
 ## Promote a key result to an objective
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/386877) in GitLab 16.0.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/386877) in GitLab 16.0.
+> - Quick action `/promote_to` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/412534) in GitLab 16.1.
 
 Prerequisites:
 
@@ -234,6 +235,41 @@ To promote a key result:
 1. In the top right corner, select the vertical ellipsis (**{ellipsis_v}**)..
 1. Select **Promote to objective**.
 
+Alternatively, use the `/promote_to objective` [quick action](../user/project/quick_actions.md).
+
+## Copy objective or key result reference
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/396553) in GitLab 16.1.
+
+To refer to an objective or key result elsewhere in GitLab, you can use its full URL or a short reference, which looks like
+`namespace/project-name#123`, where `namespace` is either a group or a username.
+
+To copy the objective or key result reference to your clipboard:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your objective or key result to view it.
+1. In the top right corner, select the vertical ellipsis (**{ellipsis_v}**), then select **Copy Reference**.
+
+You can now paste the reference into another description or comment.
+
+Read more about objective or key result references in [GitLab-Flavored Markdown](markdown.md#gitlab-specific-references).
+
+## Copy objective or key result email address
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/396553) in GitLab 16.1.
+
+You can create a comment in an objective or key result by sending an email.
+Sending an email to this address creates a comment that contains the email body.
+
+For more information about creating comments by sending an email and the necessary configuration, see
+[Reply to a comment by sending email](discussions/index.md#reply-to-a-comment-by-sending-email).
+
+To copy the objective's or key result's email address:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your issue to view it.
+1. In the top right corner, select the vertical ellipsis (**{ellipsis_v}**), then select **Copy objective email address** or **Copy key result email address**.
+
 ## Close an OKR
 
 When an OKR is achieved, you can close it.
diff --git a/doc/user/operations_dashboard/index.md b/doc/user/operations_dashboard/index.md
index d013e2813f7..3239467ceb6 100644
--- a/doc/user/operations_dashboard/index.md
+++ b/doc/user/operations_dashboard/index.md
@@ -9,7 +9,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 The Operations Dashboard provides a summary of each project's operational health,
 including pipeline and alert status.
 
-To access the dashboard, on the top bar, select **Main menu > Operations**.
+To access the dashboard:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Your work**.
+1. Select **Operations**.
 
 ## Adding a project to the dashboard
 
diff --git a/doc/user/packages/container_registry/delete_container_registry_images.md b/doc/user/packages/container_registry/delete_container_registry_images.md
index 9adb9313f09..b645dc3a3e6 100644
--- a/doc/user/packages/container_registry/delete_container_registry_images.md
+++ b/doc/user/packages/container_registry/delete_container_registry_images.md
@@ -12,27 +12,30 @@ WARNING:
 Deleting container images is a destructive action and can't be undone. To restore
 a deleted container image, you must rebuild and re-upload it.
 
+## Garbage collection
+
 Deleting a container image on self-managed instances doesn't free up storage space, it only marks the image
 as eligible for deletion. To actually delete unreferenced container images and recover storage space, administrators
 must run [garbage collection](../../../administration/packages/container_registry.md#container-registry-garbage-collection).
 
 On GitLab.com, the latest version of the Container Registry includes an automatic online garbage
 collector. For more information, see [this blog post](https://about.gitlab.com/blog/2021/10/25/gitlab-com-container-registry-update/).
-The automatic online garbage collector is an instance-wide feature, rolling out gradually to a subset
-of the user base. Some new container image repositories created from GitLab 14.5 onward are served by this
-new version of the Container Registry. In this new version of the Container Registry, layers that aren't
-referenced by any image manifest, and image manifests that have no tags and aren't referenced by another
-manifest (such as multi-architecture images), are automatically scheduled for deletion after 24 hours if
-left unreferenced.
+In this new version of the Container Registry, the following are automatically scheduled
+for deletion in 24 hours if left unreferenced:
+
+- Layers that aren't referenced by any image manifest.
+- Image manifests that have no tags and aren't referenced by another manifest (like multi-architecture images).
+
+The online garbage collector is an instance-wide feature, and applies to all namespaces.
 
 ## Use the GitLab UI
 
 To delete container images using the GitLab UI:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Packages and registries > Container Registry**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. For:
+   - A group, select **Operate > Container Registry**.
+   - A project, select **Deploy > Container Registry**.
 1. From the **Container Registry** page, you can select what you want to delete,
    by either:
 
diff --git a/doc/user/packages/container_registry/index.md b/doc/user/packages/container_registry/index.md
index c27265ccc3f..f9b1138ed84 100644
--- a/doc/user/packages/container_registry/index.md
+++ b/doc/user/packages/container_registry/index.md
@@ -21,10 +21,10 @@ rate limits and speed up your pipelines. For more information about the Docker R
 
 You can view the Container Registry for a project or group.
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Packages and registries > Container Registry**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. For:
+   - A group, select **Operate > Container Registry**.
+   - A project, select **Deploy > Container Registry**.
 
 You can search, sort, filter, and [delete](delete_container_registry_images.md#use-the-gitlab-ui)
  your container images. You can share a filtered view by copying the URL from your browser.
@@ -38,10 +38,10 @@ If a project is public, the Container Registry is also public.
 
 You can use the Container Registry **Tag Details** page to view a list of tags associated with a given container image:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Packages and registries > Container Registry**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. For:
+   - A group, select **Operate > Container Registry**.
+   - A project, select **Deploy > Container Registry**.
 1. Select your container image.
 
 You can view details about each tag, such as when it was published, how much storage it consumes,
@@ -54,10 +54,10 @@ tags on this page. You can share a filtered view by copying the URL from your br
 
 To download and run a container image hosted in the Container Registry:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
-1. On the left sidebar, select **Packages and registries > Container Registry**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. For:
+   - A group, select **Operate > Container Registry**.
+   - A project, select **Deploy > Container Registry**.
 1. Find the container image you want to work with and select **Copy**.
 
     ![Container Registry image URL](img/container_registry_hover_path_13_4.png)
@@ -115,13 +115,13 @@ The Container Registry is enabled by default.
 
 You can, however, remove the Container Registry for a project:
 
-1. On the top bar, select **Main menu > Projects**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand the **Visibility, project features, permissions** section
    and disable **Container Registry**.
 1. Select **Save changes**.
 
-The **Packages and registries > Container Registry** entry is removed from the project's sidebar.
+The **Deploy > Container Registry** entry is removed from the project's sidebar.
 
 ## Change visibility of the Container Registry
 
@@ -133,8 +133,8 @@ You can, however, change the visibility of the Container Registry for a project.
 For more information about the permissions that this setting grants to users,
 see [Container Registry visibility permissions](#container-registry-visibility-permissions).
 
-1. On the top bar, select **Main menu > Projects**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand the section **Visibility, project features, permissions**.
 1. Under **Container Registry**, select an option from the dropdown list:
 
diff --git a/doc/user/packages/container_registry/reduce_container_registry_storage.md b/doc/user/packages/container_registry/reduce_container_registry_storage.md
index f873453e049..e3ca78becf1 100644
--- a/doc/user/packages/container_registry/reduce_container_registry_storage.md
+++ b/doc/user/packages/container_registry/reduce_container_registry_storage.md
@@ -18,30 +18,10 @@ to automatically manage your container registry usage.
 ## Check Container Registry storage use
 
 The Usage Quotas page (**Settings > Usage Quotas > Storage**) displays storage usage for Packages.
-This page includes the Container Registry usage, which is only available on GitLab.com.
+This page includes the [Container Registry usage](../../usage_quotas.md#container-registry-usage), which is only available on GitLab.com.
 Measuring usage is only possible on the new version of the GitLab Container Registry backed by a
-metadata database. Support for improvements is proposed in epic [5523](https://gitlab.com/groups/gitlab-org/-/epics/5523).
-On self-managed instances, you cannot use the Container Registry with a metadata database. For the plan to change this behavior, see [epic 5521](https://gitlab.com/groups/gitlab-org/-/epics/5521).
-
-Image layers stored in the Container Registry are deduplicated at the root namespace level.
-
-An image is only counted once if:
-
-- You tag the same image more than once in the same repository.
-- You tag the same image across distinct repositories under the same root namespace.
-
-An image layer is only counted once if:
-
-- You share the image layer across multiple images in the same container repository, project, or group.
-- You share the image layer across different repositories.
-
-Only layers that are referenced by tagged images are accounted for. Untagged images and any layers
-referenced exclusively by them are subject to [online garbage collection](delete_container_registry_images.md).
-Untagged images are automatically deleted after 24 hours if they remain unreferenced during that period.
-
-Image layers are stored on the storage backend in the original (usually compressed) format. This
-means that the measured size for any given image layer should match the size displayed on the
-corresponding [image manifest](https://github.com/opencontainers/image-spec/blob/main/manifest.md#example-image-manifest).
+metadata database, which is [available on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/5523) since GitLab 15.7.
+For information on the planned availability for self-managed instances, see [epic 5521](https://gitlab.com/groups/gitlab-org/-/epics/5521).
 
 ## Cleanup policy
 
@@ -249,8 +229,10 @@ For self-managed instances, those settings can be updated in the [Rails console]
 
 They are also available in the [administrator area](../../admin_area/index.md):
 
-1. On the top bar, select **Main menu > Admin**.
-1. Go to **Settings > CI/CD > Container Registry**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > CI/CD**
+1. Expand **Container Registry**.
 
 ### Use the cleanup policy API
 
diff --git a/doc/user/packages/container_registry/troubleshoot_container_registry.md b/doc/user/packages/container_registry/troubleshoot_container_registry.md
index 68fe430e531..729f4919188 100644
--- a/doc/user/packages/container_registry/troubleshoot_container_registry.md
+++ b/doc/user/packages/container_registry/troubleshoot_container_registry.md
@@ -91,8 +91,8 @@ The following procedure uses these sample project names:
    There may be a delay while the images are queued and deleted.
 1. Change the path or transfer the project:
 
-   1. On the top bar, select **Main menu > Projects** and find your project.
-   1. On the left sidebar, select **Settings > General**.
+   1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+   1. Select **Settings > General**.
    1. Expand the **Advanced** section.
    1. In the **Change path** text box, edit the path.
    1. Select **Change path**.
diff --git a/doc/user/packages/dependency_proxy/index.md b/doc/user/packages/dependency_proxy/index.md
index d7cf33cc2a4..ebe87332948 100644
--- a/doc/user/packages/dependency_proxy/index.md
+++ b/doc/user/packages/dependency_proxy/index.md
@@ -35,10 +35,12 @@ For a list of planned additions, view the
 
 ## Enable or turn off the Dependency Proxy for a group
 
+> Required role [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/350682) from Developer to Maintainer in GitLab 15.0.
+
 To enable or turn off the Dependency Proxy for a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Packages and registries**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Packages and registries**.
 1. Expand the **Dependency Proxy** section.
 1. To enable the proxy, turn on **Enable Proxy**. To turn it off, turn the toggle off.
 
@@ -50,8 +52,8 @@ for the entire GitLab instance.
 
 To view the Dependency Proxy:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Packages and registries > Dependency Proxy**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Operate > Dependency Proxy**.
 
 The Dependency Proxy is not available for projects.
 
@@ -175,8 +177,8 @@ You can also use [custom CI/CD variables](../../../ci/variables/index.md#for-a-p
 
 To store a Docker image in Dependency Proxy storage:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Packages and registries > Dependency Proxy**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Operate > Dependency Proxy**.
 1. Copy the **Dependency Proxy image prefix**.
 1. Use one of these commands. In these examples, the image is `alpine:latest`.
 1. You can also pull images by digest to specify exactly which version of an image to pull.
@@ -360,3 +362,19 @@ a minimum of the Guest role in the Dependency Proxy group:
 
 For more information about the work to improve the error messages in similar cases to `Access denied`,
 see [issue 354826](https://gitlab.com/gitlab-org/gitlab/-/issues/354826).
+
+### `exec format error` when running images from the dependency proxy
+
+This error occurs if you try to use the dependency proxy on an ARM-based Docker install.
+The dependency proxy only supports the x86_64 architecture when pulling an image with a specific tag.
+
+As a workaround, you can specify the SHA256 of the image to force the dependency proxy
+to pull a different architecture:
+
+```shell
+docker pull ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/library/docker:20.10.3@sha256:bc9dcf5c8e5908845acc6d34ab8824bca496d6d47d1b08af3baf4b3adb1bd8fe
+```
+
+In this example, `bc9dcf5c8e5908845acc6d34ab8824bca496d6d47d1b08af3baf4b3adb1bd8fe` is the SHA256 of the ARM based image.
+
+For more information about the work to add support for other architectures, see [issue 325669](https://gitlab.com/gitlab-org/gitlab/-/issues/325669).
diff --git a/doc/user/packages/dependency_proxy/reduce_dependency_proxy_storage.md b/doc/user/packages/dependency_proxy/reduce_dependency_proxy_storage.md
index 3aaaf0c0186..4c625499d07 100644
--- a/doc/user/packages/dependency_proxy/reduce_dependency_proxy_storage.md
+++ b/doc/user/packages/dependency_proxy/reduce_dependency_proxy_storage.md
@@ -26,7 +26,7 @@ image or tag from Docker Hub.
 
 ## Cleanup policies
 
-> [Required permissions](https://gitlab.com/gitlab-org/gitlab/-/issues/350682) changed from developer to maintainer in GitLab 15.0.
+> Required role [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/350682) from Developer to Maintainer in GitLab 15.0.
 
 ### Enable cleanup policies from within GitLab
 
diff --git a/doc/user/packages/generic_packages/index.md b/doc/user/packages/generic_packages/index.md
index bad099e6733..d24808674dc 100644
--- a/doc/user/packages/generic_packages/index.md
+++ b/doc/user/packages/generic_packages/index.md
@@ -118,7 +118,7 @@ API or the UI.
 #### Do not allow duplicate Generic packages
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/293755) in GitLab 13.12.
-> - [Required permissions](https://gitlab.com/gitlab-org/gitlab/-/issues/350682) changed from developer to maintainer in GitLab 15.0.
+> - Required role [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/350682) from Developer to Maintainer in GitLab 15.0.
 
 To prevent users from publishing duplicate generic packages, you can use the [GraphQL API](../../../api/graphql/reference/index.md#packagesettings)
 or the UI.
@@ -225,12 +225,12 @@ If you are receiving `HTTP 500: Internal Server Error` responses when publishing
 # Consolidated Object Storage settings
 gitlab_rails['object_store']['connection'] = {
   # Other connection settings
-  `aws_signature_version` => '4'
+  'aws_signature_version' => '4'
 }
 # OR 
 # Storage-specific form settings
 gitlab_rails['packages_object_store_connection'] = {
   # Other connection settings
-  `aws_signature_version` => '4'
+  'aws_signature_version' => '4'
 }
 ```
diff --git a/doc/user/packages/harbor_container_registry/index.md b/doc/user/packages/harbor_container_registry/index.md
index 6cea541a55d..2bff6f79a27 100644
--- a/doc/user/packages/harbor_container_registry/index.md
+++ b/doc/user/packages/harbor_container_registry/index.md
@@ -12,9 +12,8 @@ You can integrate the [Harbor container registry](../../../user/project/integrat
 
 You can view the Harbor Registry for a project or group.
 
-1. On the top bar, select **Main menu > Projects/Groups**.
-1. Go to the project or group that you are interested in.
-1. On the left sidebar, select **Packages and registries > Harbor Registry**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Operate > Harbor Registry**.
 
 You can search, sort, and filter images on this page. You can share a filtered view by copying the URL from your browser.
 
@@ -30,7 +29,8 @@ Default settings for the Harbor integration at the project level are inherited f
 To download and run a Harbor image hosted in the GitLab Harbor Registry:
 
 1. Copy the link to your container image:
-    1. Go to your project or group's **Packages and registries > Harbor Registry** and find the image you want.
+    1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+    1. Select **Operate > Harbor Registry** and find the image you want.
     1. Select the **Copy** icon next to the image name.
 
 1. Use the command to run the container image you want.
@@ -39,8 +39,8 @@ To download and run a Harbor image hosted in the GitLab Harbor Registry:
 
 To view the list of tags associated with a specific artifact:
 
-1. Go to your project or group.
-1. Go to **Packages and registries > Harbor Registry**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Go to **Operate > Harbor Registry**.
 1. Select the image name to view its artifacts.
 1. Select the artifact you want.
 
@@ -55,13 +55,18 @@ To build and push to the Harbor Registry:
 1. Authenticate with the Harbor Registry.
 1. Run the command to build or push.
 
-To view these commands, go to your project's **Packages and registries > Harbor Registry > CLI Commands**.
+To view these commands:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Operate > Harbor Registry**.
+1. Select **CLI Commands**.
 
 ## Disable the Harbor Registry for a project
 
 To remove the Harbor Registry for a project:
 
-1. Go to your project/group's **Settings > Integrations** page.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Settings > Integrations**.
 1. Select **Harbor** under **Active integrations**.
 1. Clear the **Active** checkbox under **Enable integration**.
 1. Select **Save changes**.
diff --git a/doc/user/packages/infrastructure_registry/index.md b/doc/user/packages/infrastructure_registry/index.md
deleted file mode 100644
index 8c1e8a2ad8a..00000000000
--- a/doc/user/packages/infrastructure_registry/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: '../terraform_module_registry/index.md'
-remove_date: '2023-06-13'
----
-
-This document was moved to [another location](../terraform_module_registry/index.md).
-
-<!-- This redirect file can be deleted after <2023-06-13>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/packages/maven_repository/index.md b/doc/user/packages/maven_repository/index.md
index fd8049d9b75..bcc55af65bc 100644
--- a/doc/user/packages/maven_repository/index.md
+++ b/doc/user/packages/maven_repository/index.md
@@ -474,6 +474,8 @@ To delete older package versions, consider using the Packages API or the UI.
 
 ### Do not allow duplicate Maven packages
 
+> Required role [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/350682) from Developer to Maintainer in GitLab 15.0.
+
 To prevent users from publishing duplicate Maven packages, you can use the [GraphQl API](../../../api/graphql/reference/index.md#packagesettings) or the UI.
 
 In the UI:
diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md
index 52fdda0d523..0fe2b39a591 100644
--- a/doc/user/packages/npm_registry/index.md
+++ b/doc/user/packages/npm_registry/index.md
@@ -119,15 +119,16 @@ Your package should now publish to the Package Registry when the pipeline runs.
 
 If multiple packages have the same name and version, when you install a package, the most recently-published package is retrieved.
 
-You can install a package from a GitLab project or instance:
+You can install a package from a GitLab project, group, or instance:
 
 - **Instance-level**: Use when you have many npm packages in different GitLab groups or in their own namespace.
+- **Group-level**: Use when you have many npm packages in different projects in the same GitLab group.
 - **Project-level**: Use when you have few npm packages and they are not in the same GitLab group.
 
 ### Authenticate to the Package Registry
 
-You must authenticate to the Package Registry to install a package from a private project.
-No authentication is needed if the project is public.
+You must authenticate to the Package Registry to install a package from a private project or a private group.
+No authentication is needed if the project or the group is public.
 
 To authenticate with `npm`:
 
@@ -145,7 +146,13 @@ If you're installing:
   npm config set -- //your_domain_name/api/v4/packages/npm/:_authToken=your_token
   ```
 
-  From the project level:
+- From the group level:
+
+  ```shell
+  npm config set -- //your_domain_name/api/v4/groups/your_group_id/-/packages/npm/:_authToken=your_token
+  ```
+
+- From the project level:
 
   ```shell
   npm config set -- //your_domain_name/api/v4/projects/your_project_id/packages/npm/:_authToken=your_token
@@ -154,6 +161,7 @@ If you're installing:
 In these examples:
 
 - Replace `your_domain_name` with your domain name, for example, `gitlab.com`.
+- Replace `your_group_id` with your group ID, found on the group's home page.
 - Replace `your_project_id` is your project ID, found on the project's home page.
 - Replace `your_token` with a deploy token, group access token, project access token, or personal access token.
 
@@ -185,6 +193,29 @@ To install a package from the instance level, the package must have been publish
    npm install @scope/my-package
    ```
 
+### Install from the group level
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/299834) in GitLab 16.0 [with a flag](../../../administration/feature_flags.md) named `npm_group_level_endpoints`. Disabled by default.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121837) in GitLab 16.1. Feature flag `npm_group_level_endpoints` removed.
+
+1. [Authenticate to the Package Registry](#authenticate-to-the-package-registry).
+
+1. Set the registry
+
+   ```shell
+   npm config set @scope:registry=https://your_domain_name/api/v4/groups/your_group_id/-/packages/npm/
+   ```
+
+   - Replace `@scope` with the [root level group](#naming-convention) of the group you're installing to the package from.
+   - Replace `your_domain_name` with your domain name, for example, `gitlab.com`.
+   - Replace `your_group_id` is your group ID, found on the group's home page.
+
+1. Install the package
+
+   ```shell
+   npm install @scope/my-package
+   ```
+
 ### Install from the project level
 
 1. [Authenticate to the Package Registry](#authenticate-to-the-package-registry).
diff --git a/doc/user/packages/nuget_repository/index.md b/doc/user/packages/nuget_repository/index.md
index c97ce9ec593..ea9bfd7defb 100644
--- a/doc/user/packages/nuget_repository/index.md
+++ b/doc/user/packages/nuget_repository/index.md
@@ -316,6 +316,8 @@ nuget push <package_file> -Source <source_name>
 
 ### Publish a package with the .NET CLI
 
+> Publishing a package with `--api-key` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214674) in GitLab 16.1.
+
 Prerequisites:
 
 - [A NuGet package created with .NET CLI](https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package-dotnet-cli).
@@ -336,6 +338,21 @@ For example:
 dotnet nuget push MyPackage.1.0.0.nupkg --source gitlab
 ```
 
+You can publish a package using the `--api-key` option instead of `username` and `password`:
+
+```shell
+dotnet nuget push <package_file> --source <source_url> --api-key <gitlab_personal_access_token, deploy_token or job token>
+```
+
+- `<package_file>` is your package filename, ending in `.nupkg`.
+- `<source_url>` is the URL of the NuGet Package Registry.
+
+For example:
+
+```shell
+dotnet nuget push MyPackage.1.0.0.nupkg --source https://gitlab.example.com/api/v4/projects/<your_project_id>/packages/nuget/index.json --api-key <gitlab_personal_access_token, deploy_token or job token>
+```
+
 ### Publish a NuGet package by using CI/CD
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/36424) in GitLab 13.3.
diff --git a/doc/user/packages/package_registry/supported_package_managers.md b/doc/user/packages/package_registry/supported_package_managers.md
index cd2b288094b..94e5af7cc04 100644
--- a/doc/user/packages/package_registry/supported_package_managers.md
+++ b/doc/user/packages/package_registry/supported_package_managers.md
@@ -25,6 +25,6 @@ The Package Registry supports the following package manager types:
 | [Go](../go_proxy/index.md)                       | 13.1+          | [Experiment](https://gitlab.com/groups/gitlab-org/-/epics/3043) |
 | [Ruby gems](../rubygems_registry/index.md)       | 13.10+         | [Experiment](https://gitlab.com/groups/gitlab-org/-/epics/3200) |
 
-[View what each status means](../../../policy/alpha-beta-support.md).
+[View what each status means](../../../policy/experiment-beta-support.md).
 
 You can also use the [API](../../../api/packages.md) to administer the Package Registry.
diff --git a/doc/user/packages/workflows/project_registry.md b/doc/user/packages/workflows/project_registry.md
index 371ab83a4fb..7bff6cf8234 100644
--- a/doc/user/packages/workflows/project_registry.md
+++ b/doc/user/packages/workflows/project_registry.md
@@ -32,13 +32,19 @@ of each package management system to publish different package types to the same
 
 ## Store different package types in one GitLab project
 
-Let's take a look at how you might create a public place to hold all of your public packages.
+Let's take a look at how you might create one project to host all of your packages:
 
 1. Create a new project in GitLab. The project doesn't require any code or content.
 1. On the left sidebar, select **Project information**, and note the project ID.
-1. Create an access token. All package types in the Package Registry are accessible by using
-   [GitLab personal access tokens](../../profile/personal_access_tokens.md).
-   If you're using CI/CD, you can use CI job tokens (`CI_JOB_TOKEN`) to authenticate.
+1. Create an access token for authentication. All package types in the Package Registry can be published by using:
+
+   - A [personal access token](../../profile/personal_access_tokens.md).
+   - A [CI/CD job token](../../../ci/jobs/ci_job_token.md) (`CI_JOB_TOKEN`) in a CI/CD job.
+     Any projects publishing packages to this project's registry should be listed
+     in this project's [job token allowlist](../../../ci/jobs/ci_job_token.md#allow-access-to-your-project-with-a-job-token).
+
+   If the project is private, downloading packages requires authentication as well.
+
 1. Configure your local project and publish the package.
 
 You can upload all types of packages to the same project, or
diff --git a/doc/user/packages/yarn_repository/index.md b/doc/user/packages/yarn_repository/index.md
index c8f4985a518..262e15fe240 100644
--- a/doc/user/packages/yarn_repository/index.md
+++ b/doc/user/packages/yarn_repository/index.md
@@ -80,11 +80,9 @@ Third party images such as `node:latest` or `node:current` do not have direct ac
 to the `CI_JOB_TOKEN` when operating in a shared runner. You must configure an
 authentication token or use a private runner.
 
-To create a authentication token:
+To create an authentication token for your project or group:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project, select **Projects** and find your project.
-   - For a group, select **Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
 1. On the left sidebar, select **Settings > Repository > Deploy Tokens**.
 1. Create a deployment token with `read_package_registry` and `write_package_registry` scopes and copy the generated token.
 1. On the left sidebar, select **Settings > CI/CD > Variables**.
diff --git a/doc/user/permissions.md b/doc/user/permissions.md
index 418c01cd851..0b02de59ab4 100644
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -129,7 +129,7 @@ The following table lists project permissions available for each role:
 | [Merge requests](project/merge_requests/index.md):<br>Add labels                                                                                                                     |          |          | ✓         | ✓          | ✓        |
 | [Merge requests](project/merge_requests/index.md):<br>Lock threads                                                                                                                   |          |          | ✓         | ✓          | ✓        |
 | [Merge requests](project/merge_requests/index.md):<br>Manage or accept                                                                                                               |          |          | ✓         | ✓          | ✓        |
-| [Merge requests](project/merge_requests/index.md):<br>[Resolve a thread](discussions/index.md#resolve-a-thread)                                                                      |          |          | ✓         | ✓          | ✓        |
+| [Merge requests](project/merge_requests/index.md):<br>[Resolve a thread](project/merge_requests/index.md#resolve-a-thread)                                                                      |          |          | ✓         | ✓          | ✓        |
 | [Merge requests](project/merge_requests/index.md):<br>Manage [merge approval rules](project/merge_requests/approvals/settings.md) (project settings)                                 |          |          |           | ✓          | ✓        |
 | [Merge requests](project/merge_requests/index.md):<br>Delete                                                                                                                         |          |          |           |            | ✓        |
 | [Metrics dashboards](../operations/metrics/dashboards/index.md):<br>Manage user-starred metrics dashboards (6)                                                                     | ✓        | ✓        | ✓         | ✓          | ✓        |
@@ -369,6 +369,7 @@ The following table lists group permissions available for each role:
 | View [Productivity analytics](analytics/productivity_analytics.md)                      |       | ✓        | ✓         | ✓          | ✓     |
 | Create and edit [group wiki](project/wiki/group.md) pages                               |       |          | ✓         | ✓          | ✓     |
 | Create project in group                                                                 |       |          | ✓ (2)(4)  | ✓ (2)      | ✓ (2) |
+| Fork project into a group                                                               |       |          |           | ✓          | ✓     |
 | Create/edit/delete group milestones                                                     |       | ✓        | ✓         | ✓          | ✓     |
 | Create/edit/delete iterations                                                           |       | ✓        | ✓         | ✓          | ✓     |
 | Create/edit/delete metrics dashboard annotations                                        |       |          | ✓         | ✓          | ✓     |
@@ -400,14 +401,14 @@ The following table lists group permissions available for each role:
 | View group [Usage Quotas](usage_quotas.md) page                                         |       |          |           |            | ✓ (3) |
 | Manage group runners                                                                    |       |          |           |            | ✓     |
 | [Migrate groups](group/import/index.md)                                                 |       |          |           |            | ✓     |
-| Manage [subscriptions, and purchase CI/CD minutes and storage](../subscriptions/gitlab_com/index.md)         |       |          |           |            | ✓     |
+| Manage [subscriptions, and purchase storage and units of compute](../subscriptions/gitlab_com/index.md) |    |    |    |            | ✓     |
 
 <!-- markdownlint-disable MD029 -->
 
 1. Groups can be set to allow either Owners, or Owners and users with the Maintainer role, to [create subgroups](group/subgroups/index.md#create-a-subgroup).
 2. Default project creation role can be changed at:
    - The [instance level](admin_area/settings/visibility_and_access_controls.md#define-which-roles-can-create-projects).
-   - The [group level](group/manage.md#specify-who-can-add-projects-to-a-group).
+   - The [group level](group/index.md#specify-who-can-add-projects-to-a-group).
 3. Does not apply to subgroups.
 4. Developers can push commits to the default branch of a new project only if the [default branch protection](group/manage.md#change-the-default-branch-protection-of-a-group) is set to "Partially protected" or "Not protected".
 5. In addition, if your group is public or internal, all users who can see the group can also see group wiki pages.
@@ -463,12 +464,14 @@ To work around the issue, give these users the Guest role or higher to any proje
 - [Confidential issues](project/issues/confidential_issues.md)
 - [Container Registry permissions](packages/container_registry/index.md#container-registry-visibility-permissions)
 - [Release permissions](project/releases/index.md#release-permissions)
+- [Read-only namespaces](../user/read_only_namespaces.md)
 
 ## Custom roles **(ULTIMATE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106256) in GitLab 15.7 [with a flag](../administration/feature_flags.md) named `customizable_roles`.
 > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110810) in GitLab 15.9.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114524) in GitLab 15.10.
+> - The ability for a custom role to view a vulnerability report [introduced](https://gitlab.com/groups/gitlab-org/-/epics/10160) in GitLab 16.1.
 
 Custom roles allow group members who are assigned the Owner role to create roles
 specific to the needs of their organization.
@@ -476,6 +479,13 @@ specific to the needs of their organization.
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 For a demo of the custom roles feature, see [[Demo] Ultimate Guest can view code on private repositories via custom role](https://www.youtube.com/watch?v=46cp_-Rtxps).
 
+The following custom roles are available:
+
+- The Guest+1 role, which allows users with the Guest role to view code.
+- In GitLab 16.1 and later, you can create a custom role that can view vulnerability reports and update (change status) of the vulnerabilities.
+
+You can discuss individual custom role and permission requests in [issue 391760](https://gitlab.com/gitlab-org/gitlab/-/issues/391760).
+
 ### Create a custom role
 
 To enable custom roles for your group, a group member with the Owner role:
@@ -483,7 +493,21 @@ To enable custom roles for your group, a group member with the Owner role:
 1. Makes sure that there is at least one private project in this group or one of
    its subgroups, so that you can see the effect of giving a Guest a custom role.
 1. Creates a personal access token with the API scope.
-1. Uses [the API](../api/member_roles.md#add-a-member-role-to-a-group) to create the Guest+1 role for the root group.
+1. Uses [the API](../api/member_roles.md#add-a-member-role-to-a-group) to create a custom role for the root group.
+
+#### Custom role requirements
+
+For every ability, a minimal access level is defined. To be able to create a custom role which enables a certain ability, the `member_roles` table record has to have the associated minimal access level. For all abilities, the minimal access level is Guest. Only users who have at least the Guest role can be assigned to a custom role.
+
+Some roles and abilities require having other abilities enabled. For example, a custom role can only have administration of vulnerabilities (`admin_vulnerability`) enabled if reading vulnerabilities (`read_vulnerability`) is also enabled.
+
+You can see the required minimal access levels and abilities requirements in the following table.
+
+| Ability | Minimal access level | Required ability |
+| -- | -- | -- |
+| `read_code` | Guest    | - |
+| `read_vulnerability` | Guest | - |
+| `admin_vulnerability` | Guest | `read_vulnerability` |
 
 ### Associate a custom role with an existing group member
 
diff --git a/doc/user/product_analytics/index.md b/doc/user/product_analytics/index.md
index b5f936e7848..0d97c008561 100644
--- a/doc/user/product_analytics/index.md
+++ b/doc/user/product_analytics/index.md
@@ -6,16 +6,22 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Product analytics (Experiment) **(ULTIMATE)**
 
-> - Introduced in GitLab 15.4 as an [Experiment](../../policy/alpha-beta-support.md#experiment) feature [with a flag](../../administration/feature_flags.md) named `cube_api_proxy`. Disabled by default.
+> - Introduced in GitLab 15.4 as an [Experiment](../../policy/experiment-beta-support.md#experiment) feature [with a flag](../../administration/feature_flags.md) named `cube_api_proxy`. Disabled by default.
 > - `cube_api_proxy` revised to only reference the [Product Analytics API](../../api/product_analytics.md) in GitLab 15.6.
 > - `cube_api_proxy` removed and replaced with `product_analytics_internal_preview` in GitLab 15.10.
 > - `product_analytics_internal_preview` replaced with `product_analytics_dashboards` in GitLab 15.11.
+> - Snowplow integration introduced in GitLab 15.11 [with a flag](../../administration/feature_flags.md) named `product_analytics_snowplow_support`. Disabled by default.
 
 FLAG:
 On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `product_analytics_dashboards`.
 On GitLab.com, this feature is not available.
 This feature is not ready for production use.
 
+FLAG:
+On self-managed GitLab, by default the Snowplow integration is not available. To make it available per project or for your entire instance, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `product_analytics_snowplow_support`.
+On GitLab.com, this feature is not available.
+This feature is not ready for production use.
+
 This page is a work in progress, and we're updating the information as we add more features.
 For more information, see the [group direction page](https://about.gitlab.com/direction/analytics/product-analytics/).
 
@@ -23,9 +29,9 @@ For more information, see the [group direction page](https://about.gitlab.com/di
 
 Product analytics uses several tools:
 
-- [**Jitsu**](https://jitsu.com/docs) - A web and app event collection platform that provides a consistent API to collect user data and pass it through to ClickHouse.
+- [**Snowplow**](https://docs.snowplow.io/docs) - A developer-first engine for collecting behavioral data, and passing it through to ClickHouse.
 - [**ClickHouse**](https://clickhouse.com/docs) - A database suited to store, query, and retrieve analytical data.
-- [**Cube.js**](https://cube.dev/docs/) - An analytical graphing library that provides an API to run queries against the data stored in Clickhouse.
+- [**Cube**](https://cube.dev/docs/) - An analytical graphing library that provides an API to run queries against the data stored in Clickhouse.
 
 The following diagram illustrates the product analytics flow:
 
@@ -34,19 +40,21 @@ The following diagram illustrates the product analytics flow:
 title: Product Analytics flow
 ---
 flowchart TB
-    subgraph Adding data
-        A([SDK]) --Send user data--> B[Analytics Proxy]
-        B --Transform data and pass it through--> C[Snowplow]
-        C --Pass the data to the associated database--> D([Clickhouse])
+    subgraph Event collection
+        A([SDK]) --Send user data--> B[Snowplow Collector]
+        B --Pass data through--> C[Snowplow Enricher]
+    end
+    subgraph Data warehouse
+        C --Transform and enrich data--> D([Clickhouse])
     end
-    subgraph Showing dashboards
-        E([Dashboards]) --Generated from the YAML definition--> F[Dashboard]
+    subgraph Data visualization with dashboards
+        E([Dashboards]) --Generated from the YAML definition--> F[Panels/Visualizations]
         F --Request data--> G[Product Analytics API]
-        G --Run Cube queries with pre-aggregations--> H[Cube.js]
+        G --Run Cube queries with pre-aggregations--> H[Cube]
         H --Get data from database--> D
         D --Return results--> H
-        H --> G
-        G --Transform data to be rendered--> F
+        H --Transform data to be rendered--> G
+        G --Return data--> F
     end
 ```
 
@@ -69,113 +77,53 @@ Prerequisite:
 
 - You must be an administrator of a self-managed GitLab instance.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand the **Analytics** tab and find the **Product analytics** section.
 1. Select **Enable product analytics** and enter the configuration values.
-   The following table shows the required configuration parameters and example values:
-
-    | Name                           | Value                                                      |
-    |--------------------------------|------------------------------------------------------------|
-    | Configurator connection string | `https://test:test@configurator.gitlab.com`                |
-    | Jitsu host                     | `https://jitsu.gitlab.com`                                 |
-    | Jitsu project ID               | `g0maofw84gx5sjxgse2k`                                     |
-    | Jitsu administrator email      | `jitsu.admin@gitlab.com`                                   |
-    | Jitsu administrator password   | `<your_password>`                                          |
-    | Collector host                 | `https://collector.gitlab.com`                             |
-    | ClickHouse URL                 | `https://<username>:<password>@clickhouse.gitlab.com:8123` |
-    | Cube API URL                   | `https://cube.gitlab.com`                                  |
-    | Cube API key                   | `25718201b3e9...ae6bbdc62dbb`                              |
-
 1. Select **Save changes**.
 
-## Product analytics dashboards
+### Project-level settings
 
-> - Introduced in GitLab 15.5 behind the [feature flag](../../administration/feature_flags.md) named `product_analytics_internal_preview`. Disabled by default.
-> - `product_analytics_internal_preview` replaced with `product_analytics_dashboards` in GitLab 15.11.
+You can override the instance-level settings defined by the administrator on a per-project basis. This allows you to
+have a different configured product analytics instance for your project.
 
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `product_analytics_dashboards`.
-On GitLab.com, this feature is not available.
-This feature is not ready for production use.
-
-Each project can have an unlimited number of dashboards.
-These dashboards are defined using the GitLab YAML schema, and stored in the `.gitlab/analytics/dashboards/` directory of a project repository.
-The name of the file is the name of the dashboard.
-Each dashboard can contain one or more visualizations (charts), which are shared across dashboards.
-
-Project maintainers can enforce approval rules on dashboard changes using features such as code owners and approval rules.
-Dashboards are versioned in source control with the rest of a project's code.
+Prerequisites:
 
-### View project dashboards
+- Product analytics must be enabled at the instance-level.
+- You must have at least the Maintainer role for the project or group the project belongs to.
 
-> Introduced in GitLab 15.9 behind the [feature flag](../../administration/feature_flags.md) named `combined_analytics_dashboards`. Disabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `combined_analytics_dashboards`.
-On GitLab.com, this feature is not available.
-This feature is not ready for production use.
-
-To view a list of product analytics dashboards for a project:
-
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > Dashboards**.
-1. From the list of available dashboards, select the dashboard you want to view.
-
-### Define a dashboard
-
-To define a dashboard:
-
-1. In `.gitlab/analytics/dashboards/`, create a directory named like the dashboard.
-
-    Each dashboard should have its own directory.
-1. In the new directory, create a `.yaml` file with the same name as the directory.
-
-    This file contains the dashboard definition. It must conform to the JSON schema defined in `ee/app/validators/json_schemas/product_analytics_dashboard.json`.
-1. In the `.gitlab/analytics/dashboards/visualizations/` directory, create a `.yaml` file.
-
-    This file defines the visualization type for the dashboard. It must conform to the schema in
- `ee/app/validators/json_schemas/product_analytics_visualization.json`.
-
-For example, if you want to create three dashboards (Conversion funnels, Demographic breakdown, and North star metrics)
-and one visualization (line chart) that applies to all dashboards, the file structure would be:
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**
+1. Expand **Product Analytics**.
+1. In the **Connect to your instance** section, enter the configuration values.
+1. Select **Save changes**.
 
-```plaintext
-.gitlab/analytics/dashboards
-├── conversion_funnels
-│  └── conversion_funnels.yaml
-├── demographic_breakdown
-│  └── demographic_breakdown.yaml
-├── north_star_metrics
-|  └── north_star_metrics.yaml
-├── visualizations
-│  └── example_line_chart.yaml
-```
+## Instrument a GitLab project
 
-### Define a chart visualization
+To instrument code to collect data, use one or more of the existing SDKs:
 
-You can define different charts, and add visualization options to some of them:
+- [Browser SDK](https://gitlab.com/gitlab-org/analytics-section/product-analytics/gl-application-sdk-browser)
+- [Ruby SDK](https://gitlab.com/gitlab-org/analytics-section/product-analytics/gl-application-sdk-rb)
 
-- Line chart, with the options listed in the [ECharts documentation](https://echarts.apache.org/en/option.html).
-- Column chart, with the options listed in the [ECharts documentation](https://echarts.apache.org/en/option.html).
-- Data table, with the only option to render `links` (array of objects, each with `text` and `href` properties to specify the dimensions to be used in links). See [example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_visualization.json?ref_type=heads#L112)).
-- Single stat, with the only option to set `decimalPlaces` (number, default value is 0).
+## Product analytics dashboards
 
-To define a chart for your dashboards:
+> - Introduced in GitLab 15.5 behind the [feature flag](../../administration/feature_flags.md) named `product_analytics_internal_preview`. Disabled by default.
+> - `product_analytics_internal_preview` replaced with `product_analytics_dashboards` in GitLab 15.11.
 
-1. In the `.gitlab/product_analytics/dashboards/visualizations/` directory, create a `.yaml` file.
-The filename should be descriptive of the visualization it defines.
-1. In the `.yaml` file, define the visualization options, according to the schema in
-`ee/app/validators/json_schemas/analytics_visualization.json`.
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `product_analytics_dashboards`.
+On GitLab.com, this feature is not available.
+This feature is not ready for production use.
 
-For [example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/gl_dashboards/product_analytics/visualizations/events_over_time.json), to create a line chart that illustrates event count over time, in the `visualizations` folder
-create a `line_chart.yaml` file with the following required fields:
+Product analytics dashboards are a subset of dashboards under [Analytics dashboards](../analytics/analytics_dashboards.md).
 
-- version
-- title
-- type
-- data
-- options
+Specifically product analytics dashboards and visualizations make use of the `cube_analytics` data type.
+The `cube_analytics` data type connects to the Cube instance defined when [product analytics was enabled](#enable-product-analytics).
+All filters and queries are sent to the Cube instance and the returned data is processed by the
+product analytics data source to be rendered by the appropriate visualizations.
 
 ## Funnel analysis
 
diff --git a/doc/user/profile/account/create_accounts.md b/doc/user/profile/account/create_accounts.md
index f405dc42f46..f2f1921f0bb 100644
--- a/doc/user/profile/account/create_accounts.md
+++ b/doc/user/profile/account/create_accounts.md
@@ -33,8 +33,9 @@ Prerequisite:
 
 To create a user manually:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users** (`/admin/users`).
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select **New user**.
 1. Complete the required fields, such as name, username, and email.
 1. Select **Create user**.
diff --git a/doc/user/profile/account/delete_account.md b/doc/user/profile/account/delete_account.md
index a2c82fdeadf..c367498f66e 100644
--- a/doc/user/profile/account/delete_account.md
+++ b/doc/user/profile/account/delete_account.md
@@ -17,19 +17,30 @@ Deleting a user deletes all projects in that user namespace.
 
 ## Delete your own account
 
+> Delay between a user deleting their own account and deletion of the user record introduced in GitLab 16.0 [with a flag](../../../administration/feature_flags.md) named `delay_delete_own_user`. Enabled by default on GitLab.com.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `delay_delete_own_user`. On GitLab.com, this feature is available.
+
 As a user, to delete your own account:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Account**.
 1. Select **Delete account**.
 
+NOTE:
+On GitLab.com, there is a seven day delay between a user deleting their own account and deletion of the user record. During this time, that user is [blocked](../../admin_area/moderate_users.md#block-a-user) and a new account with the same email address or username cannot be created.
+
+Unblocking the account does not undo the deletion because the account will still be in the deletion queue, and there is no quick method to reverse this process.
+
 ## Delete users and user contributions **(FREE SELF)**
 
 As an administrator, to delete a user account:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Overview > Users**.
 1. Select a user.
 1. Under the **Account** tab, select:
    - **Delete user** to delete only the user but maintain their [associated records](#associated-records). You can't use this option if
diff --git a/doc/user/profile/account/two_factor_authentication.md b/doc/user/profile/account/two_factor_authentication.md
index 8827e1e27c5..b856366bb58 100644
--- a/doc/user/profile/account/two_factor_authentication.md
+++ b/doc/user/profile/account/two_factor_authentication.md
@@ -108,7 +108,7 @@ Configure FortiAuthenticator in GitLab. On your GitLab server:
 
 1. Open the configuration file.
 
-   For Omnibus GitLab:
+   For Linux package installations:
 
    ```shell
    sudo editor /etc/gitlab/gitlab.rb
@@ -123,7 +123,7 @@ Configure FortiAuthenticator in GitLab. On your GitLab server:
 
 1. Add the provider configuration:
 
-   For Omnibus package:
+   For Linux package installations:
 
    ```ruby
    gitlab_rails['forti_authenticator_enabled'] = true
@@ -145,8 +145,9 @@ Configure FortiAuthenticator in GitLab. On your GitLab server:
    ```
 
 1. Save the configuration file.
-1. [Reconfigure](../../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) (Omnibus GitLab) or
-   [restart](../../../administration/restart_gitlab.md#installations-from-source) (GitLab installed from source).
+1. [Reconfigure](../../../administration/restart_gitlab.md#reconfigure-a-linux-package-installation)
+   (Linux package installations) or [restart](../../../administration/restart_gitlab.md#installations-from-source)
+   (self-compiled installations).
 
 ### Enable one-time password using Duo
 
@@ -174,7 +175,7 @@ On your GitLab server:
 
 1. Open the configuration file.
 
-   For Omnibus GitLab:
+   For Linux package installations:
 
    ```shell
    sudo editor /etc/gitlab/gitlab.rb
@@ -189,7 +190,7 @@ On your GitLab server:
 
 1. Add the provider configuration:
 
-   For Omnibus package:
+   For Linux package installations:
 
    ```ruby
     gitlab_rails['duo_auth_enabled'] = false
@@ -209,7 +210,7 @@ On your GitLab server:
    ```
 
 1. Save the configuration file.
-1. For Omnibus GitLab, [reconfigure GitLab](../../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. For Linux package installations, [reconfigure GitLab](../../../administration/restart_gitlab.md#reconfigure-a-linux-package-installation).
    For installations from source, [restart GitLab](../../../administration/restart_gitlab.md#installations-from-source).
 
 ### Enable one-time password using FortiToken Cloud
@@ -233,7 +234,7 @@ Configure FortiToken Cloud in GitLab. On your GitLab server:
 
 1. Open the configuration file.
 
-   For Omnibus GitLab:
+   For Linux package installations:
 
    ```shell
    sudo editor /etc/gitlab/gitlab.rb
@@ -248,7 +249,7 @@ Configure FortiToken Cloud in GitLab. On your GitLab server:
 
 1. Add the provider configuration:
 
-   For Omnibus package:
+   For Linux package installations:
 
    ```ruby
    gitlab_rails['forti_token_cloud_enabled'] = true
@@ -266,8 +267,8 @@ Configure FortiToken Cloud in GitLab. On your GitLab server:
    ```
 
 1. Save the configuration file.
-1. [Reconfigure](../../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) (Omnibus GitLab) or
-   [restart](../../../administration/restart_gitlab.md#installations-from-source) (GitLab installed from source).
+1. [Reconfigure](../../../administration/restart_gitlab.md#reconfigure-a-linux-package-installation) (Linux package installations) or
+   [restart](../../../administration/restart_gitlab.md#installations-from-source) (self-compiled installations).
 
 ### Set up a WebAuthn device
 
diff --git a/doc/user/profile/achievements.md b/doc/user/profile/achievements.md
index 1313c714dd0..4e3248ceb10 100644
--- a/doc/user/profile/achievements.md
+++ b/doc/user/profile/achievements.md
@@ -202,6 +202,36 @@ mutation {
 }
 ```
 
+## Delete an awarded achievement
+
+If you awarded an achievement to a user by mistake, you can delete it.
+
+Prerequisites:
+
+- You must have the Owner role for the namespace.
+
+To delete an awarded achievement, call the [`userAchievementsDelete` GraphQL mutation](../../api/graphql/reference/index.md#mutationuserachievementsdelete).
+
+```graphql
+mutation {
+  userAchievementsDelete(input: {
+    userAchievementId: "gid://gitlab/Achievements::UserAchievement/<user achievement id>" }) {
+    userAchievement {
+      id
+      achievement {
+        id
+        name
+      }
+      user {
+        id
+        username
+      }
+    }
+    errors
+  }
+}
+```
+
 ## Delete an achievement
 
 If you consider you no longer need an achievement, you can delete it.
@@ -230,7 +260,7 @@ mutation {
 
 If you don't want to display achievements on your profile, you can opt out. To do this:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. In the **Main settings** section, clear the **Display achievements on your profile** checkbox.
 1. Select **Update profile settings**.
diff --git a/doc/user/profile/active_sessions.md b/doc/user/profile/active_sessions.md
index f22accf2ff5..cb56aa8a07a 100644
--- a/doc/user/profile/active_sessions.md
+++ b/doc/user/profile/active_sessions.md
@@ -16,7 +16,7 @@ review the sessions, and revoke any you don't recognize.
 
 To list all active sessions:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Active Sessions**.
 
@@ -33,7 +33,7 @@ exceeds 100, the oldest ones are deleted.
 
 To revoke an active session:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Active Sessions**.
 1. Select **Revoke** next to a session. The current session cannot be revoked, as this would sign you out of GitLab.
diff --git a/doc/user/profile/comment_templates.md b/doc/user/profile/comment_templates.md
index 8a94aff44fe..4157fc852b7 100644
--- a/doc/user/profile/comment_templates.md
+++ b/doc/user/profile/comment_templates.md
@@ -9,11 +9,11 @@ type: howto
 
 > - GraphQL support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/352956) in GitLab 14.9 [with a flag](../../administration/feature_flags.md) named `saved_replies`. Disabled by default.
 > - User interface [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113232) in GitLab 15.10 [with a flag](../../administration/feature_flags.md) named `saved_replies`. Disabled by default. Enabled for GitLab team members only.
-> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119468) in GitLab 16.0.
+> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119468) in GitLab 16.0.
 
 FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `saved_replies`.
-On GitLab.com, this feature is not available by default, but enabled for GitLab team members.
+On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../../administration/feature_flags.md) named `saved_replies`.
+On GitLab.com, this feature is available.
 
 With comment templates, create and reuse text for any text area in:
 
@@ -25,24 +25,22 @@ With comment templates, create and reuse text for any text area in:
 Comment templates can be small, like approving a merge request and unassigning yourself from it,
 or large, like chunks of boilerplate text you use frequently:
 
-![Comment templates dropdown list](img/saved_replies_dropdown_v15_10.png)
-
-For more information about the rollout plan for this feature, see [issue 352956](https://gitlab.com/gitlab-org/gitlab/-/issues/352956).
+![Comment templates dropdown list](img/saved_replies_dropdown_v16_0.png)
 
 ## Use comment templates in a text area
 
 To include the text of a comment template in your comment:
 
-1. In the editor toolbar for your comment, select **Comment templates** (**{symlink}**).
+1. In the editor toolbar for your comment, select **Comment templates** (**{comment-lines}**).
 1. Select your desired comment template.
 
 ## Create comment templates
 
 To create a comment template for future use:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. From the dropdown list, select **Preferences**.
-1. On the left sidebar, select **Comment templates** (**{symlink}**).
+1. On the left sidebar, select **Comment templates** (**{comment-lines}**).
 1. Provide a **Name** for your comment template.
 1. Enter the **Content** of your reply. You can use any formatting you use in
    other GitLab text areas.
@@ -52,18 +50,18 @@ To create a comment template for future use:
 
 To go to your comment templates:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. From the dropdown list, select **Preferences**.
-1. On the left sidebar, select **Comment templates** (**{symlink}**).
+1. On the left sidebar, select **Comment templates** (**{comment-lines}**).
 1. Scroll to **My comment templates**.
 
 ## Edit or delete comment templates
 
 To edit or delete a previously comment template:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. From the dropdown list, select **Preferences**.
-1. On the left sidebar, select **Comment templates** (**{symlink}**).
+1. On the left sidebar, select **Comment templates** (**{comment-lines}**).
 1. Scroll to **My comment templates**, and identify the comment template you want to edit.
 1. To edit, select **Edit** (**{pencil}**).
 1. To delete, select **Delete** (**{remove}**), then select **Delete** again from the modal window.
diff --git a/doc/user/profile/contributions_calendar.md b/doc/user/profile/contributions_calendar.md
index 7b5691e1ee5..7adf653606e 100644
--- a/doc/user/profile/contributions_calendar.md
+++ b/doc/user/profile/contributions_calendar.md
@@ -40,7 +40,7 @@ GitLab tracks the following contribution events:
 
 To view your daily contributions:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select your name from the dropdown list.
 1. In the contributions calendar:
    - To view the number of contributions for a specific day, hover over a tile.
@@ -53,7 +53,7 @@ The contributions calendar graph and recent activity list displays your
 
 To view private contributions:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. In the **Main settings** section, select the **Include private contributions on my profile** checkbox.
 1. Select **Update profile settings**.
@@ -96,7 +96,7 @@ If you think your feed token has been exposed, you should reset it.
 
 To reset your feed token:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Access Tokens**.
 1. Scroll down. In the **Feed token** section, select the
diff --git a/doc/user/profile/img/saved_replies_dropdown_v15_10.png b/doc/user/profile/img/saved_replies_dropdown_v15_10.png
deleted file mode 100644
index 50313f71f4a..00000000000
--- a/doc/user/profile/img/saved_replies_dropdown_v15_10.png
+++ /dev/null
diff --git a/doc/user/profile/img/saved_replies_dropdown_v16_0.png b/doc/user/profile/img/saved_replies_dropdown_v16_0.png
new file mode 100644
index 00000000000..4608484a496
--- /dev/null
+++ b/doc/user/profile/img/saved_replies_dropdown_v16_0.png
diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md
index b7d8f6aba58..958acaa61a9 100644
--- a/doc/user/profile/index.md
+++ b/doc/user/profile/index.md
@@ -15,14 +15,14 @@ Your profile also includes settings, which you use to customize your GitLab expe
 
 To access your profile:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select your name or username.
 
 ## Access your user settings
 
 To access your user settings:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 
 ## Change your username
@@ -44,7 +44,7 @@ Prerequisites:
 
 To change your username:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Account**.
 1. In the **Change username** section, enter a new username as the path.
@@ -54,7 +54,7 @@ To change your username:
 
 To add new email to your account:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Emails**.
 1. In the **Email** text box, enter the new email.
@@ -67,7 +67,7 @@ You can make your user profile visible to only you and GitLab administrators.
 
 To make your profile private:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. Select the **Private profile** checkbox.
 1. Select **Update profile settings**.
@@ -104,8 +104,7 @@ the README file with information, it's included on your profile page.
 
 To create a new project and add its README to your profile:
 
-1. On the top bar, select **Main menu > Projects > View all projects**.
-1. On the right of the page, select **New project**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New project/repository**.
 1. Select **Create blank project**.
 1. Enter the project details:
    - In the **Project name** field, enter the name for your new project.
@@ -133,7 +132,7 @@ They can help other users connect with you on other platforms.
 
 To add links to other accounts:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. In the **Main settings** section, add your:
    - Discord [user ID](https://support.discord.com/hc/en-us/articles/206346498-Where-can-I-find-my-User-Server-Message-ID-).
@@ -150,7 +149,7 @@ In the user contribution calendar graph and recent activity list, you can see yo
 
 To show private contributions:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. In the **Main settings** section, select the **Include private contributions on my profile** checkbox.
 1. Select **Update profile settings**.
@@ -164,7 +163,7 @@ your name in your profile.
 
 To specify your pronouns:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. In the **Pronouns** text box, enter your pronouns. The text must be 50 characters or less.
 1. Select **Update profile settings**.
@@ -178,7 +177,7 @@ your name.
 
 To add your name pronunciation:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. In the **Pronunciation** text box, enter how your name is pronounced. The pronunciation must be plain text and 255 characters or less.
 1. Select **Update profile settings**.
@@ -194,7 +193,7 @@ Your status is publicly visible even if your [profile is private](#make-your-use
 
 To set your current status:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Set status** or, if you have already set a status, **Edit status**.
 1. Set the desired emoji and status message. Status messages must be plain text and 100 characters or less.
    They can also contain emoji codes like, `I'm on vacation :palm_tree:`.
@@ -217,12 +216,12 @@ To indicate to others that you are busy, you can set an indicator.
 To set the busy status indicator, either:
 
 - Set it directly:
-  1. On the top bar, in the upper-right corner, select your avatar.
+  1. On the left sidebar, select your avatar.
   1. Select **Set status** or, if you have already set a status, **Edit status**.
   1. Select the **Set yourself as busy** checkbox.
 
 - Set it on your profile:
-  1. On the top bar, in the upper-right corner, select your avatar.
+  1. On the left sidebar, select your avatar.
   1. Select **Edit profile**.
   1. In the **Current status** section, select the **Set yourself as busy** checkbox.
 
@@ -238,7 +237,7 @@ You can set your local time zone to:
 
 To set your time zone:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. In the **Time settings** section, select your time zone from the dropdown list.
 
@@ -284,7 +283,7 @@ so you can keep your email information private.
 
 To use a private commit email:
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. In the **Commit email** dropdown list, select **Use a private email**.
 1. Select **Update profile settings**.
@@ -315,7 +314,7 @@ the maximum number of users you can follow is 300.
 
 You can disable following and being followed by other users.
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. Select **Preferences**.
 1. Clear the **Enable follow users** checkbox.
@@ -324,6 +323,20 @@ You can disable following and being followed by other users.
 NOTE:
 When this feature is being disabled, all current followed/following connections are deleted.
 
+## Advanced code search with zoekt
+
+### Disable searching code with zoekt
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/388519) as a beta feature [with a flag](../feature_flags.md) named `search_code_with_zoekt`. Enabled by default.
+
+You can disable searching with Zoekt and use Elasticsearch instead.
+
+1. On the left sidebar, select your avatar.
+1. Select **Edit profile**.
+1. Select **Preferences**.
+1. Clear the **Enable advanced code search** checkbox.
+1. Select **Save changes**.
+
 ## View your activity
 
 GitLab tracks [user contribution activity](contributions_calendar.md).
@@ -363,7 +376,7 @@ When you sign in, three cookies are set:
 
 - A session cookie called `_gitlab_session`.
   This cookie has no set expiration date. However, it expires based on its `session_expire_delay`.
-- A session cookied called `about_gitlab_active_user`.
+- A session cookie called `about_gitlab_active_user`.
   This cookie is used by the [marketing site](https://about.gitlab.com/) to determine if a user has an active GitLab session. No user information is passed to the cookie and it expires with the session.
 - A persistent cookie called `remember_user_token`, which is set only if you selected **Remember me** on the sign-in page.
 
diff --git a/doc/user/profile/notifications.md b/doc/user/profile/notifications.md
index b60ff8471bf..cc0b67eed52 100644
--- a/doc/user/profile/notifications.md
+++ b/doc/user/profile/notifications.md
@@ -107,7 +107,7 @@ To select a notification level for a group, use either of these methods:
 
 Or:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. Select the notification dropdown list, next to the bell icon (**{notifications}**).
 1. Select the desired [notification level](#notification-levels).
 
@@ -138,7 +138,7 @@ To select a notification level for a project, use either of these methods:
 
 Or:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Select the notification dropdown list, next to the bell icon (**{notifications}**).
 1. Select the desired [notification level](#notification-levels).
 
@@ -263,7 +263,7 @@ epics:
 | Issue | Reassigned | Participants, Watchers, Subscribers, Custom notification level with this event selected, and the old assignee. |
 | Issue | Reopened | Subscribers and participants. |
 | Merge Request | Closed | Subscribers and participants. |
-| Merge Request | Conflict | Author and any user that has set the merge request to automatically merge when pipeline succeeds. |
+| Merge Request | Conflict | Author and any user that has set the merge request to auto-merge. |
 | Merge Request | [Marked as ready](../project/merge_requests/drafts.md) | Watchers and participants. _[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15332) in GitLab 13.10._ |
 | Merge Request | Merged | Subscribers and participants. |
 | Merge Request | Merged when pipeline succeeds | Author, Participants, Watchers, Subscribers, and Custom notification level with this event selected. Custom notification level is ignored for Author, Watchers and Subscribers. _[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211961) in GitLab 13.4._ |
diff --git a/doc/user/profile/personal_access_tokens.md b/doc/user/profile/personal_access_tokens.md
index e59d7313281..bda92ce8388 100644
--- a/doc/user/profile/personal_access_tokens.md
+++ b/doc/user/profile/personal_access_tokens.md
@@ -86,7 +86,12 @@ At any time, you can revoke a personal access token.
 
 ## View the last time a token was used
 
-Token usage information is updated every 24 hours. GitLab considers a token used when the token is used to:
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/414945) in GitLab 16.1 [with a flag](../../administration/feature_flags.md) named `update_personal_access_token_usage_information_every_10_minutes`. Enabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../../administration/feature_flags.md) named `update_personal_access_token_usage_information_every_10_minutes`. On GitLab.com, this feature is available.
+
+Token usage information is updated every 10 minutes. GitLab considers a token used when the token is used to:
 
 - Authenticate with the [REST](../../api/rest/index.md) or [GraphQL](../../api/graphql/index.md) APIs.
 - Perform a Git operation.
diff --git a/doc/user/profile/preferences.md b/doc/user/profile/preferences.md
index da4d2da70fe..bcfe323a5fe 100644
--- a/doc/user/profile/preferences.md
+++ b/doc/user/profile/preferences.md
@@ -39,11 +39,11 @@ The default theme is Indigo. You can choose between 10 themes:
 
 ## Dark mode
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28252) in GitLab 13.1 as an [Experiment](../../policy/alpha-beta-support.md#experiment) release.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28252) in GitLab 13.1 as an [Experiment](../../policy/experiment-beta-support.md#experiment) release.
 
 GitLab has started work on dark mode! The dark mode Experiment release is available in the
 spirit of iteration and the lower expectations of
-[Experiment features](../../policy/alpha-beta-support.md#experiment).
+[Experiment features](../../policy/experiment-beta-support.md#experiment).
 
 Progress on dark mode is tracked in the [Dark theme epic](https://gitlab.com/groups/gitlab-org/-/epics/2902).
 See the epic for:
@@ -129,6 +129,8 @@ You can choose between 2 options:
 The **Project overview content** setting allows you to choose what content you want to
 see on a project's home page.
 
+If **Files and Readme** is selected, you can show or hide the shortcut buttons above the file list on the project overview with the **Show shortcut buttons above files on project overview** setting.
+
 ### Tab width
 
 You can set the displayed width of tab characters across various parts of
@@ -182,6 +184,13 @@ NOTE:
 This feature is experimental, and choosing absolute times might break certain layouts.
 Open an issue if you notice that using absolute times breaks a layout.
 
+## User identities in CI job JSON web tokens
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/387537) in GitLab 16.0. False by default.
+
+You can select to include the list of your external identities in the JSON Web Token information that is generated for a CI job.
+For more information and examples, see [Token Payload](../../ci/secrets/id_token_authentication.md#token-payload).
+
 ## Integrations
 
 Configure your preferences with third-party services which provide enhancements to your GitLab experience.
diff --git a/doc/user/profile/user_passwords.md b/doc/user/profile/user_passwords.md
index eac3db3c71c..50624a43893 100644
--- a/doc/user/profile/user_passwords.md
+++ b/doc/user/profile/user_passwords.md
@@ -23,18 +23,29 @@ authorization provider, you do not need to choose a password. GitLab
 
 ## Change your password
 
+> Password reset emails sent to any verified email address [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16311) in GitLab 16.1.
+
 You can change your password. GitLab enforces [password requirements](#password-requirements) when you choose your new
 password.
 
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Password**.
 1. In the **Current password** text box, enter your current password.
 1. In the **New password** and **Password confirmation** text box, enter your new password.
 1. Select **Save password**.
 
-If you don't know your current password, select the **I forgot my password** link. A password reset email is sent to the
-account's **primary** email address.
+If you do not know your current password, select **I forgot my password**
+and complete the form. A password reset email is sent to the email address you
+enter into this form, provided that the email address is verified. If you enter an
+unverified email address into this form, no email is sent, and you see the following
+message:
+
+> "If your email address exists in our database, you will receive a password recovery link at your email address in a few minutes."
+
+NOTE:
+Your account can have more than one verified email address, and any email address
+associated with your account can be verified.
 
 ## Password requirements
 
diff --git a/doc/user/project/badges.md b/doc/user/project/badges.md
index 26708dece50..be47d6f18bd 100644
--- a/doc/user/project/badges.md
+++ b/doc/user/project/badges.md
@@ -130,8 +130,8 @@ If you find that you have to add the same badges to several projects, you may wa
 
 To add a new badge to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Badges**.
 1. Under **Link**, enter the URL that the badges should point to.
 1. Under **Badge image URL**, enter the URL of the image that should be displayed.
@@ -151,8 +151,8 @@ A common project badge presents the GitLab CI pipeline status.
 
 To add this badge to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Badges**.
 1. Under **Name**, enter _Pipeline Status_.
 1. Under **Link**, enter the following URL:
@@ -180,8 +180,8 @@ If you need individual badges for each project, either:
 
 To add a new badge to a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand **Badges**.
 1. Under "Link", enter the URL that the badges should point to and under
    "Badge image URL" the URL of the image that should be displayed.
@@ -202,8 +202,8 @@ Badges associated with a group can be edited or deleted only at the [group level
 You can view the exact link for your badges.
 Then you can use the link to embed the badge in your HTML or Markdown pages.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > CI/CD**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > CI/CD**.
 1. Expand **General pipelines**.
 1. In the **Pipeline status**, **Coverage report**, or **Latest release** sections, view the URLs for the images.
 
@@ -269,8 +269,9 @@ https://gitlab.example.com/<project_path>/-/raw/<default_branch>/my-image.svg
 
 To add a new badge with a custom image to a group or project:
 
-1. On the top bar, select **Main menu** and find your group or project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or
+   group.
+1. Select **Settings > General**.
 1. Expand **Badges**.
 1. Under **Name**, enter the name for the badge.
 1. Under **Link**, enter the URL that the badge should point to.
diff --git a/doc/user/project/changelogs.md b/doc/user/project/changelogs.md
index 7e622110291..0c12f7d476b 100644
--- a/doc/user/project/changelogs.md
+++ b/doc/user/project/changelogs.md
@@ -56,41 +56,56 @@ Changelog: feature
 
 ## Create a changelog
 
-To generate changelog data based on commits in a repository, see
+Changelogs are generated from the command line, using either the API or the
+GitLab CLI. The changelog output is formatted in Markdown, and
+[you can customize it](#customize-the-changelog-output).
+
+### From the API
+
+To generate changelogs via the API with a `curl` command, see
 [Add changelog data to a changelog file](../../api/repositories.md#add-changelog-data-to-a-changelog-file)
 in the API documentation.
 
-The changelog output is formatted in Markdown, and [you can customize it](#customize-the-changelog-output).
+### From the GitLab CLI
 
-### Reverted commits
+> [Introduced](https://gitlab.com/gitlab-org/cli/-/merge_requests/1222) in `glab` version 1.30.0.
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55537) in GitLab 13.10.
+Prerequisites:
 
-To be treated as a revert commit, the commit message must contain the string
-`This reverts commit <SHA>`, where `SHA` is the SHA of the commit to be reverted.
+- You have installed and configured the [GitLab CLI](../../integration/glab/index.md),
+  version 1.30.0 or later.
+- Your repository's tag naming schema matches
+  [the expected tag naming format](#customize-the-tag-format-when-extracting-versions).
+- Commits include [changelog trailers](../../development/changelog.md).
 
-When generating a changelog for a range, GitLab ignores commits both added and
-reverted in that range. In this example, commit C reverts commit B. Because
-commit C has no other trailer, only commit A is added to the changelog:
+To generate the changelog:
 
-```mermaid
-graph LR
-    A[Commit A<br>Changelog: changed] --> B[Commit B<br>Changelog: changed]
-    B --> C[Commit C<br>Reverts commit B]
-```
+1. Update your local copy of your repository with `git fetch`.
+1. To generate a changelog for the current version (as determined by `git describe --tags`)
+   with the default options:
+   - Run the command `glab changelog generate`.
+   - To save the output to a file, run the command `glab changelog generate > <filename>.md`.
+1. To generate a changelog with customized options, run the command `glab changelog generate`
+   and append your desired options. Some options include:
 
-However, if the revert commit (commit C) _also_ contains a changelog trailer,
-both commits A and C are included in the changelog:
-
-```mermaid
-graph LR
-    A[Commit A<br><br>Changelog: changed] --> B[Commit B<br><br>Changelog: changed]
-    B --> C[Commit C<br>Reverts commit B<br>Changelog: changed]
-```
+   - `--config-file [string]`: The path to the changelog configuration file in your project's
+     Git repository. Defaults to `.gitlab/changelog_config.yml`.
+   - Commit range:
+     - `--from [string]`: The start of the range of commits (as a SHA) to use for
+       generating the changelog. This commit itself isn't included in the changelog.
+     - `--to [string]`: The end of the range of commits (as a SHA) to use for
+       generating the changelog. This commit _is_ included in the list. Defaults to the `HEAD`
+       of the default project branch.
+   - `--date [string]`: The date and time of the release, in ISO 8601 (`2016-03-11T03:45:40Z`)
+     format. Defaults to the current time.
+   - `--trailer [string]`: The Git trailer to use for including commits. Defaults to `Changelog`.
+   - `--version [string]`: The version to generate the changelog for.
 
-Commit B is skipped.
+To learn more about the parameters available in GitLab CLI, run `glab changelog generate --help`. See the
+[API documentation](../../api/repositories.md#add-changelog-data-to-a-changelog-file)
+for definitions and usage.
 
-### Customize the changelog output
+## Customize the changelog output
 
 To customize the changelog output, edit the changelog configuration file. The default
 location for this configuration is `.gitlab/changelog_config.yml`. The file supports
@@ -311,6 +326,34 @@ To test if your regular expression is working, you can use websites such as
 [regex101](https://regex101.com/). If the regular expression syntax is invalid,
 an error is produced when generating a changelog.
 
+## Reverted commit handling
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55537) in GitLab 13.10.
+
+To be treated as a revert commit, the commit message must contain the string
+`This reverts commit <SHA>`, where `SHA` is the SHA of the commit to be reverted.
+
+When generating a changelog for a range, GitLab ignores commits both added and
+reverted in that range. In this example, commit C reverts commit B. Because
+commit C has no other trailer, only commit A is added to the changelog:
+
+```mermaid
+graph LR
+    A[Commit A<br>Changelog: changed] --> B[Commit B<br>Changelog: changed]
+    B --> C[Commit C<br>Reverts commit B]
+```
+
+However, if the revert commit (commit C) _also_ contains a changelog trailer,
+both commits A and C are included in the changelog:
+
+```mermaid
+graph LR
+    A[Commit A<br><br>Changelog: changed] --> B[Commit B<br><br>Changelog: changed]
+    B --> C[Commit C<br>Reverts commit B<br>Changelog: changed]
+```
+
+Commit B is skipped.
+
 ## Related topics
 
 - [Changelog-related endpoints](../../api/repositories.md) in the Repositories API
diff --git a/doc/user/project/clusters/add_eks_clusters.md b/doc/user/project/clusters/add_eks_clusters.md
index 6c8edb8c3e5..87554e786ab 100644
--- a/doc/user/project/clusters/add_eks_clusters.md
+++ b/doc/user/project/clusters/add_eks_clusters.md
@@ -174,7 +174,7 @@ When you create a new cluster, you have the following settings:
 | Kubernetes cluster name | Your cluster's name. |
 | Environment scope       | The [associated environment](multiple_kubernetes_clusters.md#setting-the-environment-scope). |
 | Service role            | The **EKS IAM role** (**role A**). |
-| Kubernetes version      | The [Kubernetes version](../../clusters/agent/index.md#gitlab-agent-for-kubernetes-supported-cluster-versions) for your cluster. |
+| Kubernetes version      | The [Kubernetes version](../../clusters/agent/index.md#supported-kubernetes-versions-for-gitlab-features) for your cluster. |
 | Key pair name           | The [key pair](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) that you can use to connect to your worker nodes. |
 | VPC                     | The [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) to use for your EKS Cluster resources. |
 | Subnets                 | The [subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html) in your VPC where your worker nodes run. Two are required. |
@@ -248,7 +248,10 @@ For example, the following policy document allows assuming a role whose name sta
 To configure Amazon authentication in GitLab, generate an access key for the
 IAM user in the Amazon AWS console, and follow these steps:
 
-1. In GitLab, on the top bar, select **Main menu > Admin > Settings > General** and expand the **Amazon EKS** section.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand **Amazon EKS**.
 1. Check **Enable Amazon EKS integration**.
 1. Enter your **Account ID**.
 1. Enter your [access key and ID](#eks-access-key-and-id).
diff --git a/doc/user/project/clusters/deploy_to_cluster.md b/doc/user/project/clusters/deploy_to_cluster.md
index 31d5a73757a..2ea7ac0f1fd 100644
--- a/doc/user/project/clusters/deploy_to_cluster.md
+++ b/doc/user/project/clusters/deploy_to_cluster.md
@@ -78,7 +78,7 @@ You can customize the deployment namespace in a few ways:
 - For **non-managed** clusters, the auto-generated namespace is set in the `KUBECONFIG`,
   but the user is responsible for ensuring its existence. You can fully customize
   this value using
-  [`environment:kubernetes:namespace`](../../../ci/environments/index.md#configure-kubernetes-deployments-deprecated)
+  [`environment:kubernetes:namespace`](../../../ci/environments/configure_kubernetes_deployments.md)
   in `.gitlab-ci.yml`.
 
 When you customize the namespace, existing environments remain linked to their current
diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md
index 5ce1994ba36..ab6084acd5e 100644
--- a/doc/user/project/clusters/index.md
+++ b/doc/user/project/clusters/index.md
@@ -24,5 +24,5 @@ to a single project.
 
 To view project-level Kubernetes clusters:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Operate > Kubernetes clusters**.
diff --git a/doc/user/project/codeowners/index.md b/doc/user/project/codeowners/index.md
index e69dba6f977..272d59bd6a4 100644
--- a/doc/user/project/codeowners/index.md
+++ b/doc/user/project/codeowners/index.md
@@ -48,8 +48,8 @@ For example:
 
 To view the Code Owners of a file or directory:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Files**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Repository**.
 1. Go to the file or directory you want to see the Code Owners for.
 1. Optional. Select a branch or tag.
 
diff --git a/doc/user/project/deploy_keys/index.md b/doc/user/project/deploy_keys/index.md
index 13ee07097e1..5bd19fec0ba 100644
--- a/doc/user/project/deploy_keys/index.md
+++ b/doc/user/project/deploy_keys/index.md
@@ -56,14 +56,14 @@ As with all sensitive information, you should ensure only those who need access
 For human interactions, use credentials tied to users such as Personal Access Tokens.
 
 To help detect a potential secret leak, you can use the
-[Audit Event](../../../administration/audit_event_streaming.md#example-payloads-for-ssh-events-with-deploy-key) feature.
+[Audit Event](../../../administration/audit_event_streaming/examples.md#example-payloads-for-ssh-events-with-deploy-key) feature.
 
 ## View deploy keys
 
 To view the deploy keys available to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Deploy keys**.
 
 The deploy keys available are listed:
@@ -80,8 +80,8 @@ Prerequisites:
 - [Generate an SSH key pair](../../ssh.md#generate-an-ssh-key-pair). Put the private SSH
   key on the host that requires access to the repository.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Deploy keys**.
 1. Complete the fields.
 1. Optional. To grant `read-write` permission, select the **Grant write permissions to this key**
@@ -101,8 +101,9 @@ Prerequisites:
 
 To create a public deploy key:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Deploy Keys**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Deploy Keys**.
 1. Select **New deploy key**.
 1. Complete the fields.
    - Use a meaningful description for **Name**. For example, include the name of the external host
@@ -118,8 +119,8 @@ Prerequisites:
 
 To grant a public deploy key access to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Deploy keys**.
 1. Select **Publicly accessible deploy keys**.
 1. In the key's row, select **Enable**.
@@ -138,8 +139,8 @@ Prerequisites:
 
 To disable a deploy key:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Deploy keys**.
 1. Select **Disable** (**{cancel}**).
 
@@ -160,7 +161,7 @@ There are a few scenarios where a deploy key fails to push to a
 
 - The owner associated to a deploy key does not have access to the protected branch.
 - The owner associated to a deploy key does not have [membership](../members/index.md) to the project of the protected branch.
-- **No one** is selected in [the **Allowed to push and merge** section](../protected_branches.md#configure-a-protected-branch) of the protected branch.
+- **No one** is selected in [the **Allowed to push and merge** section](../protected_branches.md#add-protection-to-existing-branches) of the protected branch.
 
 All deploy keys are associated to an account. Since the permissions for an account can change, this might lead to scenarios where a deploy key that was working is suddenly unable to push to a protected branch.
 
diff --git a/doc/user/project/deploy_tokens/index.md b/doc/user/project/deploy_tokens/index.md
index a81ccd043bd..0b9c42f2a60 100644
--- a/doc/user/project/deploy_tokens/index.md
+++ b/doc/user/project/deploy_tokens/index.md
@@ -92,10 +92,8 @@ Prerequisites:
 
 - You must have at least the Maintainer role for the project or group.
 
-1. On the top bar, select **Main menu**, and:
-   - For a project deploy token, select **Projects** and find your project.
-   - For a group deploy token, select **Groups** and find your group.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Settings > Repository**.
 1. Expand **Deploy tokens**.
 1. Complete the fields, and select the desired [scopes](#scope).
 1. Select **Create deploy token**.
@@ -113,10 +111,8 @@ Prerequisites:
 
 To revoke a deploy token:
 
-1. On the top bar, select **Main menu**, and:
-   - For a project deploy token, select **Projects** and find your project.
-   - For a group deploy token, select **Groups** and find your group.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Settings > Repository**.
 1. Expand **Deploy tokens**.
 1. In the **Active Deploy Tokens** section, by the token you want to revoke, select **Revoke**.
 
diff --git a/doc/user/project/description_templates.md b/doc/user/project/description_templates.md
index f0ced95c8eb..11e538964a2 100644
--- a/doc/user/project/description_templates.md
+++ b/doc/user/project/description_templates.md
@@ -32,8 +32,8 @@ directory in your repository.
 
 To create an issue description template:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Repository**.
 1. Next to the default branch, select **{plus}**.
 1. Select **New file**.
 1. Next to the default branch, in the **File name** text box, enter `.gitlab/issue_templates/mytemplate.md`,
@@ -52,8 +52,8 @@ that depend on the contents of commit messages and branch names.
 
 To create a merge request description template for a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Repository**.
 1. Next to the default branch, select **{plus}**.
 1. Select **New file**.
 1. Next to the default branch, in the **File name** text box, enter `.gitlab/merge_request_templates/mytemplate.md`,
@@ -118,14 +118,14 @@ that you can use when creating a new project in the instance.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52360) in GitLab 13.9.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/321247) in GitLab 14.0.
 
-With **group-level** description templates, you can store your templates in a single repository and
-configure the group file templates setting to point to that repository.
+With **group-level** description templates, you can select a repository within the group to store
+your templates. Then, you can access these templates from other projects in the group.
 As a result, you can use the same templates in issues and merge requests in all the group's projects.
 
 To re-use templates [you've created](../project/description_templates.md#create-an-issue-template):
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand **Templates**.
 1. From the dropdown list, select your template project as the template repository at group level.
 1. Select **Save changes**.
@@ -155,8 +155,8 @@ To set a default description template for merge requests, either:
   This [doesn't overwrite](#priority-of-default-description-templates) the default template if one has been set in the project settings.
 - Users on GitLab Premium and Ultimate: set the default template in project settings:
 
-  1. On the top bar, select **Main menu > Projects** and find your project.
-  1. On the left sidebar, select **Settings > Merge requests**.
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+  1. Select **Settings > Merge requests**.
   1. In the **Default description template for merge requests** section, fill in the text area.
   1. Select **Save changes**.
 
@@ -167,8 +167,8 @@ To set a default description template for issues, either:
   This [doesn't overwrite](#priority-of-default-description-templates) the default template if one has been set in the project settings.
 - Users on GitLab Premium and Ultimate: set the default template in project settings:
 
-  1. On the top bar, select **Main menu > Projects** and find your project.
-  1. On the left sidebar, select **Settings > General**.
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+  1. Select **Settings > General**.
   1. Expand **Default description template for issues**.
   1. Fill in the text area.
   1. Select **Save changes**.
diff --git a/doc/user/project/file_lock.md b/doc/user/project/file_lock.md
index c81ba4b7dd3..71b4bff41d1 100644
--- a/doc/user/project/file_lock.md
+++ b/doc/user/project/file_lock.md
@@ -219,8 +219,8 @@ To view the user who locked the file (if it was not you), hover over the button.
 
 To view and remove file locks:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Locked files**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Locked files**.
 
 This list shows all the files locked either through LFS or GitLab UI.
 
diff --git a/doc/user/project/import/bitbucket.md b/doc/user/project/import/bitbucket.md
index b523e007f0e..dc17a3646a8 100644
--- a/doc/user/project/import/bitbucket.md
+++ b/doc/user/project/import/bitbucket.md
@@ -70,8 +70,7 @@ For user contributions to be mapped, each user must complete the following befor
 > Ability to re-import projects [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/23905) in GitLab 15.9.
 
 1. Sign in to GitLab.
-1. On the top bar, select **New** (**{plus}**).
-1. Select **New project/repository**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New project/repository**.
 1. Select **Import project**.
 1. Select **Bitbucket Cloud**.
 1. Log in to Bitbucket and grant GitLab access to your Bitbucket account.
diff --git a/doc/user/project/import/bitbucket_server.md b/doc/user/project/import/bitbucket_server.md
index 4d3a6eb87e0..fce9ca7d147 100644
--- a/doc/user/project/import/bitbucket_server.md
+++ b/doc/user/project/import/bitbucket_server.md
@@ -41,8 +41,7 @@ You can import Bitbucket repositories to GitLab.
 To import your Bitbucket repositories:
 
 1. Sign in to GitLab.
-1. On the top bar, select **New** (**{plus}**).
-1. Select **New project/repository**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New project/repository**.
 1. Select **Import project**.
 1. Select **Bitbucket Server**.
 1. Log in to Bitbucket and grant GitLab access to your Bitbucket account.
diff --git a/doc/user/project/import/fogbugz.md b/doc/user/project/import/fogbugz.md
index 692ec1390d2..30c4249e0d6 100644
--- a/doc/user/project/import/fogbugz.md
+++ b/doc/user/project/import/fogbugz.md
@@ -29,8 +29,7 @@ users.
 To import your project from FogBugz:
 
 1. Sign in to GitLab.
-1. On the top bar, select **New** (**{plus}**).
-1. Select **New project/repository**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New project/repository**.
 1. Select **Import project**.
 1. Select **FogBugz**.
 1. Enter your FogBugz URL, email address, and password.
diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md
index b2b1ede12d4..509029a3099 100644
--- a/doc/user/project/import/github.md
+++ b/doc/user/project/import/github.md
@@ -17,9 +17,11 @@ The namespace is a user or group in GitLab, such as `gitlab.com/sidney-jones` or
 `gitlab.com/customer-success`. You can use bulk actions in the rails console to move projects to
 different namespaces.
 
-If you are importing to a self-managed GitLab instance, you can use the
-[GitHub Rake task](../../../administration/raketasks/github_import.md) instead. This allows you to import projects
-without the constraints of a [Sidekiq](../../../development/sidekiq/index.md) worker.
+- If you are importing to a self-managed GitLab instance, you can use the [GitHub Rake task](../../../administration/raketasks/github_import.md) instead. The
+  Rake task imports projects without the constraints of a [Sidekiq](../../../development/sidekiq/index.md) worker.
+- If you are importing from GitHub Enterprise to GitLab.com, use the
+  [GitLab Import API](../../../api/import.md#import-repository-from-github) GitHub endpoint instead. This allows you to provide a different domain to import the project from.
+  Using the UI, the GitHub importer always imports from the `github.com` domain.
 
 When importing projects:
 
@@ -30,6 +32,7 @@ When importing projects:
 - The importer also imports branches on forks of projects related to open pull requests. These branches are
   imported with a naming scheme similar to `GH-SHA-username/pull-request-number/fork-name/branch`. This may lead to
   a discrepancy in branches compared to those of the GitHub repository.
+- The organization the repository belongs to must not impose restrictions of a [third-party application access policy](https://docs.github.com/en/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictions) on the GitLab instance you import to.
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 For an overview of the import process, see [Migrating from GitHub to GitLab](https://youtu.be/VYOXuOg9tQI).
@@ -137,11 +140,12 @@ Use one of the following tabs to filter the list of repositories:
 - **Collaborated**: Filter the list to the repositories that you have contributed to.
 - **Organization**: Filter the list to the repositories that belong to an organization you are a member of.
 
-When the **Organization** tab is selected, you can further narrow down your search by selecting an available GitHub organization from a dropdown.
+When the **Organization** tab is selected, you can further narrow down your search by selecting an available GitHub organization from a dropdown list.
 
 ### Select additional items to import
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/373705) in GitLab 15.5.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/373705) in GitLab 15.5.
+> - Importing collaborators as an additional item was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/398154) in GitLab 16.0.
 
 To make imports as fast as possible, the following items aren't imported from GitHub by default:
 
@@ -183,17 +187,17 @@ To open an repository in GitLab URL after it has been imported, select its GitLa
 
 Completed imports can be re-imported by selecting **Re-import** and specifying new name. This creates a new copy of the source project.
 
-![GitHub importer page](img/import_projects_from_github_importer_v12_3.png)
+![GitHub importer page](img/import_projects_from_github_importer_v16_0.png)
 
 ### Check status of imports
 
-> Details of partially completed imports with a list of entities that failed to import [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/386748) in GitLab 16.0.
+> Details of partially completed imports with a list of entities that failed to import [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/386748) in GitLab 16.1.
 
 After imports are completed, they can be in one of three states:
 
-- **Completed**: GitLab imported all repository entities.
+- **Complete**: GitLab imported all repository entities.
 - **Partially completed**: GitLab failed to import some repository entities.
-- **Failed**: GitLab imported no repository entities.
+- **Failed**: GitLab aborted the import after a critical error occurred.
 
 Expand **Details** to see a list of [repository entities](#imported-data) that failed to import.
 
@@ -280,12 +284,12 @@ When they are imported, supported GitHub branch protection rules are mapped to e
 
 | GitHub rule                                                                         | GitLab rule                                                                                                                                                 | Introduced in                                                       |
 | :---------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------ |
-| **Require conversation resolution before merging** for the project's default branch                 | **All threads must be resolved** [project setting](../../discussions/index.md#prevent-merge-unless-all-threads-are-resolved)                                | [GitLab 15.5](https://gitlab.com/gitlab-org/gitlab/-/issues/371110) |
-| **Require a pull request before merging**                                                           | **No one** option in the **Allowed to push and merge** list of [branch protection settings](../protected_branches.md#configure-a-protected-branch)                    | [GitLab 15.5](https://gitlab.com/gitlab-org/gitlab/-/issues/370951) |
+| **Require conversation resolution before merging** for the project's default branch                 | **All threads must be resolved** [project setting](../merge_requests/index.md#prevent-merge-unless-all-threads-are-resolved)                                | [GitLab 15.5](https://gitlab.com/gitlab-org/gitlab/-/issues/371110) |
+| **Require a pull request before merging**                                                           | **No one** option in the **Allowed to push and merge** list of [branch protection settings](../protected_branches.md#add-protection-to-existing-branches)                    | [GitLab 15.5](https://gitlab.com/gitlab-org/gitlab/-/issues/370951) |
 | **Require signed commits** for the project's default branch                                         | **Reject unsigned commits** GitLab [push rule](../repository/push_rules.md#prevent-unintended-consequences) **(PREMIUM)**                                   | [GitLab 15.5](https://gitlab.com/gitlab-org/gitlab/-/issues/370949) |
 | **Allow force pushes - Everyone**                                                                   | **Allowed to force push** [branch protection setting](../protected_branches.md#allow-force-push-on-a-protected-branch)                                      | [GitLab 15.6](https://gitlab.com/gitlab-org/gitlab/-/issues/370943) |
 | **Require a pull request before merging - Require review from Code Owners**                         | **Require approval from code owners** [branch protection setting](../protected_branches.md#require-code-owner-approval-on-a-protected-branch) **(PREMIUM)** | [GitLab 15.6](https://gitlab.com/gitlab-org/gitlab/-/issues/376683) |
-| **Require a pull request before merging - Allow specified actors to bypass required pull requests** | List of users in the **Allowed to push and merge** list of [branch protection settings](../protected_branches.md#configure-a-protected-branch) **(PREMIUM)**. Without a **Premium** subscription, the list of users that are allowed to push and merge is limited to roles. | [GitLab 15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/384939) |
+| **Require a pull request before merging - Allow specified actors to bypass required pull requests** | List of users in the **Allowed to push and merge** list of [branch protection settings](../protected_branches.md#add-protection-to-existing-branches) **(PREMIUM)**. Without a **Premium** subscription, the list of users that are allowed to push and merge is limited to roles. | [GitLab 15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/384939) |
 
 Mapping GitHub rule **Require status checks to pass before merging** to
 [external status checks](../merge_requests/status_checks.md) was considered in issue
diff --git a/doc/user/project/import/img/import_projects_from_github_importer_v12_3.png b/doc/user/project/import/img/import_projects_from_github_importer_v12_3.png
deleted file mode 100644
index 3ac03c0ecc5..00000000000
--- a/doc/user/project/import/img/import_projects_from_github_importer_v12_3.png
+++ /dev/null
diff --git a/doc/user/project/import/img/import_projects_from_github_importer_v16_0.png b/doc/user/project/import/img/import_projects_from_github_importer_v16_0.png
new file mode 100644
index 00000000000..190474c4d89
--- /dev/null
+++ b/doc/user/project/import/img/import_projects_from_github_importer_v16_0.png
diff --git a/doc/user/project/import/index.md b/doc/user/project/import/index.md
index 1265b8534d0..9fdb8eed5aa 100644
--- a/doc/user/project/import/index.md
+++ b/doc/user/project/import/index.md
@@ -18,7 +18,7 @@ For any type of source and target, you can migrate GitLab projects:
 
 - When [migrating groups by direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended),
   which allows you to migrate all projects in a group simultaneously. Migrating projects by direct transfer is in
-  [Beta](../../../policy/alpha-beta-support.md#beta). The feature is not ready for production use.
+  [Beta](../../../policy/experiment-beta-support.md#beta). The feature is not ready for production use.
 - Using [file exports](../settings/import_export.md). With this method you can migrate projects one by one. No network
   connection between instances is required.
 
@@ -26,7 +26,7 @@ If you only need to migrate Git repositories, you can [import each project by UR
 import issues and merge requests this way. To retain metadata like issues and merge requests, either:
 
 - [Migrate projects with groups by direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended).
-  This feature is in [Beta](../../../policy/alpha-beta-support.md#beta). It is not ready for production use.
+  This feature is in [Beta](../../../policy/experiment-beta-support.md#beta). It is not ready for production use.
 - Use [file exports](../settings/import_export.md) to import projects.
 
 Keep in mind the limitations of [migrating using file exports](../settings/import_export.md#items-that-are-exported).
@@ -41,8 +41,9 @@ with a malicious `.gitlab-ci.yml` file could allow an attacker to exfiltrate gro
 
 GitLab self-managed administrators can reduce their attack surface by disabling import sources they don't need:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **Visibility and access controls**.
 1. Scroll to **Import sources**.
 1. Clear checkboxes for importers that are not required.
@@ -113,8 +114,7 @@ You can view all project imports created by you. This list includes the followin
 To view project import history:
 
 1. Sign in to GitLab.
-1. On the top bar, select **Create new...** (**{plus-square}**).
-1. Select **New project/repository**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New project/repository**.
 1. Select **Import project**.
 1. In the upper-right corner, select **History**.
 1. If there are any errors for a particular import, you can see them by selecting **Details**.
diff --git a/doc/user/project/import/repo_by_url.md b/doc/user/project/import/repo_by_url.md
index 4ad51ccb97f..230113581f8 100644
--- a/doc/user/project/import/repo_by_url.md
+++ b/doc/user/project/import/repo_by_url.md
@@ -19,7 +19,8 @@ You can import your existing repositories by providing the Git URL.
 
 ## Import project by URL
 
-1. In GitLab, on the top bar, select **Main menu > Projects > View all projects**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your projects**.
 1. On the right of the page, select **New project**.
 1. Select the **Import project** tab.
 1. Select **Repository by URL**.
diff --git a/doc/user/project/index.md b/doc/user/project/index.md
index 1512039fb25..67b96efe9a4 100644
--- a/doc/user/project/index.md
+++ b/doc/user/project/index.md
@@ -12,8 +12,7 @@ You can create a project in many ways in GitLab.
 
 To create a blank project:
 
-1. On the top bar, select **Main menu > Projects > View all projects**.
-1. On the right of the page, select **New project**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New project/repository**.
 1. Select **Create blank project**.
 1. Enter the project details:
    - In the **Project name** field, enter the name of your project. The name must start with a lowercase or uppercase letter (`a-zA-Z`), digit (`0-9`), emoji, or underscore (`_`). It can also contain dots (`.`), pluses (`+`), dashes (`-`), or spaces.
@@ -42,8 +41,7 @@ Anyone can [contribute a built-in template](../../development/project_templates.
 
 To create a project from a built-in template:
 
-1. On the top bar, select **Main menu > Projects > View all projects**.
-1. On the right of the page, select **New project**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New project/repository**.
 1. Select **Create from template**.
 1. Select the **Built-in** tab.
 1. From the list of templates:
@@ -73,8 +71,7 @@ Custom project templates are available at:
 - The [instance-level](../../user/admin_area/custom_project_templates.md)
 - The [group-level](../../user/group/custom_project_templates.md)
 
-1. On the top bar, select **Main menu > Projects > View all projects**.
-1. On the right of the page, select **New project**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New project/repository**.
 1. Select **Create from template**.
 1. Select the **Instance** or **Group** tab.
 1. From the list of templates:
@@ -99,8 +96,7 @@ HIPAA Audit Protocol published by the U.S Department of Health and Human Service
 
 To create a project from the HIPAA Audit Protocol template:
 
-1. On the top bar, select **Main menu > Projects > View all projects**.
-1. On the right of the page, select **New project**.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**) and **New project/repository**.
 1. Select **Create from template**.
 1. Select the **Built-in** tab.
 1. Locate the **HIPAA Audit Protocol** template:
@@ -138,7 +134,7 @@ Prerequisites:
   [added to your GitLab account](../ssh.md#add-an-ssh-key-to-your-gitlab-account).
 - You must have permission to add new projects to a namespace. To check if you have permission:
 
-  1. On the top bar, select **Main menu > Groups** and find your group.
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
   1. In the upper-right corner, confirm that **New project** is visible.
      Contact your GitLab administrator if you require permission.
 
diff --git a/doc/user/project/insights/index.md b/doc/user/project/insights/index.md
index 2874bf98736..5ca6fcebdd6 100644
--- a/doc/user/project/insights/index.md
+++ b/doc/user/project/insights/index.md
@@ -24,8 +24,8 @@ Prerequisites:
 
 To view project insights:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > Insights**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Analyze > Insights**.
 1. To view a report, select the **Select report** dropdown list.
 
 ## Configure project insights
@@ -45,7 +45,7 @@ To configure project insights, either:
 
 - Create a `.gitlab/insights.yml` file locally in the root directory of your project, and push your changes.
 - Create a `.gitlab/insights.yml` file in the UI:
-  1. On the top bar, select **Main menu > Projects** and find your project.
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
   1. Above the file list, select the branch you want to commit to, select the plus icon, then select **New file**.
   1. In the **File name** text box, enter `.gitlab/insights.yml`.
   1. In the large text box, update the file contents.
diff --git a/doc/user/project/integrations/apple_app_store.md b/doc/user/project/integrations/apple_app_store.md
index 633d565064c..405531abd0d 100644
--- a/doc/user/project/integrations/apple_app_store.md
+++ b/doc/user/project/integrations/apple_app_store.md
@@ -29,14 +29,15 @@ An Apple ID enrolled in the [Apple Developer Program](https://developer.apple.co
 GitLab supports enabling the Apple App Store integration at the project level. Complete these steps in GitLab:
 
 1. In the Apple App Store Connect portal, generate a new private key for your project by following [these instructions](https://developer.apple.com/documentation/appstoreconnectapi/creating_api_keys_for_app_store_connect_api).
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
-1. Select **Apple App Store**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
+1. Select **Apple App Store Connect**.
 1. Turn on the **Active** toggle under **Enable Integration**.
 1. Provide the Apple App Store Connect configuration information:
    - **Issuer ID**: The Apple App Store Connect issuer ID.
    - **Key ID**: The key ID of the generated private key.
    - **Private Key**: The generated private key. You can download this key only once.
+   - **Protected branches and tags only**: Enable to only set variables on protected branches and tags.
 
 1. Select **Save changes**.
 
diff --git a/doc/user/project/integrations/asana.md b/doc/user/project/integrations/asana.md
index b1a4d2a2f78..edd08f1e3d3 100644
--- a/doc/user/project/integrations/asana.md
+++ b/doc/user/project/integrations/asana.md
@@ -32,13 +32,14 @@ In Asana, create a Personal Access Token.
 
 Complete these steps in GitLab:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Asana**.
 1. Ensure that the **Active** toggle is enabled.
 1. Paste the token you generated in Asana.
 1. Optional. To restrict this setting to specific branches, list them in the **Restrict to branch**
    field, separated with commas.
-1. Select **Save changes** or optionally select **Test settings**.
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
 
 <!-- ## Troubleshooting -->
diff --git a/doc/user/project/integrations/bamboo.md b/doc/user/project/integrations/bamboo.md
index 23990036f4e..8394687d8f5 100644
--- a/doc/user/project/integrations/bamboo.md
+++ b/doc/user/project/integrations/bamboo.md
@@ -36,8 +36,8 @@ integration in GitLab.
 
 ## Configure GitLab
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Atlassian Bamboo**.
 1. Ensure the **Active** checkbox is selected.
 1. Enter the base URL of your Bamboo server. For example, `https://bamboo.example.com`.
@@ -47,8 +47,7 @@ integration in GitLab.
 1. If necessary, enter a username and password for a Bamboo user that has
    access to trigger the build plan. Leave these fields blank if you do not require
    authentication.
-1. Optional. To test the configuration and trigger a build in Bamboo,
-   select **Test Settings**.
+1. Optional. Select **Test settings**.
 1. Select **Save changes**.
 
 ### Identify the Bamboo build plan build key
diff --git a/doc/user/project/integrations/bugzilla.md b/doc/user/project/integrations/bugzilla.md
index f2af4dc6e4d..1796e674b00 100644
--- a/doc/user/project/integrations/bugzilla.md
+++ b/doc/user/project/integrations/bugzilla.md
@@ -14,8 +14,8 @@ You can configure Bugzilla as an
 
 To enable the Bugzilla integration in a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Bugzilla**.
 1. Select the checkbox under **Enable integration**.
 1. Fill in the required fields:
@@ -31,7 +31,8 @@ To enable the Bugzilla integration in a project:
      For example, for a project named "My Cool App":
      `https://bugzilla.example.org/enter_bug.cgi#h=dupes%7CMy+Cool+App`.
 
-1. Select **Save changes** or optionally select **Test settings**.
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
 
 After you configure and enable Bugzilla, a link appears on the GitLab
 project pages. This link takes you to the appropriate Bugzilla project.
diff --git a/doc/user/project/integrations/clickup.md b/doc/user/project/integrations/clickup.md
new file mode 100644
index 00000000000..bf2c738049c
--- /dev/null
+++ b/doc/user/project/integrations/clickup.md
@@ -0,0 +1,54 @@
+---
+stage: Manage
+group: Import and Integrate
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# ClickUp **(FREE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120732) in GitLab 16.1.
+
+You can use [ClickUp](https://clickup.com/) as an external issue tracker.
+To enable the ClickUp integration in a project:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
+1. Select **ClickUp**.
+1. Select the checkbox under **Enable integration**.
+1. Fill in the required fields:
+
+   - **Project URL**: The URL to the ClickUp project to link to this GitLab project.
+   - **Issue URL**: The URL to the ClickUp project issue to link to this GitLab project.
+     The URL must contain `:id`. GitLab replaces this ID with the issue number.
+
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
+
+After you have configured and enabled ClickUp, you see the ClickUp link on the GitLab project pages,
+which takes you to your ClickUp project.
+
+For example, this is a configuration for a project named `gitlab-ci`:
+
+- Project URL: `https://app.clickup.com/1234567`
+- Issue URL: `https://app.clickup.com/t/:id`
+
+You can also disable [GitLab internal issue tracking](../issues/index.md) in this project.
+For more information about the steps and consequences of disabling GitLab issues, see
+[Configure project visibility, features, and permissions](../settings/index.md#configure-project-visibility-features-and-permissions).
+
+## Reference ClickUp issues in GitLab
+
+You can reference your ClickUp issues using:
+
+- `#<ID>`, where `<ID>` is a alphanumerical string (example `#8wrtcd932`).
+- `CU-<ID>`, where `<ID>` is a alphanumerical string (example `CU-8wrtcd932`).
+- `<PROJECT>-<ID>`, for example `API_32-143`, where:
+  - `<PROJECT>` is a ClickUp list custom prefix ID.
+  - `<ID>` is a number.
+
+In links, the `CU-` part is ignored and it links to the global URL of the issue. When a custom
+prefix is used in a ClickUp list, the prefix part is part of the link.
+
+We suggest using the `CU-` format (`CU-<ID>`) if you have both internal and external issue
+trackers enabled. If you use the shorter format, and an issue with the same ID exists in the
+internal issue tracker, the internal issue is linked.
diff --git a/doc/user/project/integrations/custom_issue_tracker.md b/doc/user/project/integrations/custom_issue_tracker.md
index b529d728e3b..9580c924fd1 100644
--- a/doc/user/project/integrations/custom_issue_tracker.md
+++ b/doc/user/project/integrations/custom_issue_tracker.md
@@ -20,8 +20,8 @@ on the left sidebar in your project.
 
 To enable a custom issue tracker in a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Custom issue tracker**.
 1. Select the checkbox under **Enable integration**.
 1. Fill in the required fields:
diff --git a/doc/user/project/integrations/discord_notifications.md b/doc/user/project/integrations/discord_notifications.md
index 60b37f07bb5..180e39e3254 100644
--- a/doc/user/project/integrations/discord_notifications.md
+++ b/doc/user/project/integrations/discord_notifications.md
@@ -26,8 +26,8 @@ and configure it in GitLab.
 
 With the webhook URL created in the Discord channel, you can set up the Discord Notifications integration in GitLab.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Discord Notifications**.
 1. Ensure that the **Active** toggle is enabled.
 1. Check the checkboxes corresponding to the GitLab events for which you want to send notifications to Discord.
diff --git a/doc/user/project/integrations/emails_on_push.md b/doc/user/project/integrations/emails_on_push.md
index 7f8755f1114..eb3eecaa656 100644
--- a/doc/user/project/integrations/emails_on_push.md
+++ b/doc/user/project/integrations/emails_on_push.md
@@ -11,8 +11,8 @@ that is pushed to your project.
 
 To enable emails on push:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Emails on push**.
 1. In the **Recipients** section, provide a list of emails separated by spaces or newlines.
 1. Configure the following options:
diff --git a/doc/user/project/integrations/ewm.md b/doc/user/project/integrations/ewm.md
index 39dd548e7ca..d96558579d1 100644
--- a/doc/user/project/integrations/ewm.md
+++ b/doc/user/project/integrations/ewm.md
@@ -14,8 +14,8 @@ This IBM product was [formerly named Rational Team Concert (RTC)](https://jazz.n
 
 To enable the EWM integration, in a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **EWM**.
 1. Select the checkbox under **Enable integration**.
 1. Fill in the required fields:
@@ -35,7 +35,8 @@ To enable the EWM integration, in a project:
      Append the following fragment to your project area URL: `#action=com.ibm.team.workitem.newWorkItem`.
      For example, `https://example.com/ccm/web/projects/JKE%20Banking#action=com.ibm.team.workitem.newWorkItem`.
 
-1. Select **Save changes** or optionally select **Test settings**.
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
 
 ## Reference EWM work items in commit messages
 
diff --git a/doc/user/project/integrations/github.md b/doc/user/project/integrations/github.md
index 3e75106a9bc..98654a3b59f 100644
--- a/doc/user/project/integrations/github.md
+++ b/doc/user/project/integrations/github.md
@@ -29,8 +29,8 @@ Complete these steps on GitHub:
 
 Complete these steps in GitLab:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **GitHub**.
 1. Ensure the **Active** checkbox is selected.
 1. In **Token**, paste the token you generated on GitHub.
diff --git a/doc/user/project/integrations/gitlab_slack_application.md b/doc/user/project/integrations/gitlab_slack_application.md
index fabdf07f76f..8790c7213e5 100644
--- a/doc/user/project/integrations/gitlab_slack_application.md
+++ b/doc/user/project/integrations/gitlab_slack_application.md
@@ -107,8 +107,9 @@ With Slack notifications, GitLab can send messages to Slack workspace channels f
 
 To configure Slack notifications:
 
-1. On the top bar, select **Main menu > Projects** and find a project for which the GitLab for Slack app has been [installed](#installation).
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find a project for
+   which the GitLab for Slack app has been [installed](#installation).
+1. Select **Settings > Integrations**.
 1. Select **GitLab for Slack app**.
 1. In the **Trigger** section, select the checkbox for each GitLab
    event you want to receive a notification for in Slack. For a full list, see
@@ -162,8 +163,9 @@ New releases of the app might require permissions to be authorized before some f
 
 To update your GitLab for Slack app:
 
-1. On the top bar, select **Main menu > Projects** and find a project for which the GitLab for Slack app has been configured.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find a project for
+   which the GitLab for Slack app has been configured.
+1. Select **Settings > Integrations**.
 1. Select **GitLab for Slack app**.
 1. Select **Reinstall GitLab for Slack app**.
 
diff --git a/doc/user/project/integrations/google_play.md b/doc/user/project/integrations/google_play.md
index 2ae5a504e06..4b0f4fe205a 100644
--- a/doc/user/project/integrations/google_play.md
+++ b/doc/user/project/integrations/google_play.md
@@ -29,8 +29,8 @@ Prerequisites:
 
 To enable the Google Play integration in GitLab:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Google Play**.
 1. In **Enable integration**, select the **Active** checkbox.
 1. In **Package name**, enter the package name of the app (for example, `com.gitlab.app_name`).
diff --git a/doc/user/project/integrations/hangouts_chat.md b/doc/user/project/integrations/hangouts_chat.md
index 3470d11b983..4046869072d 100644
--- a/doc/user/project/integrations/hangouts_chat.md
+++ b/doc/user/project/integrations/hangouts_chat.md
@@ -12,11 +12,11 @@ Hangouts).
 
 ## Integration workflow
 
-To enable this integration, first you need to create a webhook for the room in
+To enable this integration, you must first create a webhook for the space in
 Google Chat where you want to receive the notifications from your project.
 
 After that, enable the integration in GitLab and choose the events you want to
-be notified about in your Google Chat room.
+be notified about in your Google Chat space.
 
 For every selected event in your project, GitLab acts like a bot sending
 notifications to Google Chat:
@@ -27,9 +27,9 @@ notifications to Google Chat:
 
 To enable the integration in Google Chat:
 
-1. Enter the room where you want to receive notifications from GitLab.
-1. In the upper-left corner, from the room dropdown list, select **Manage webhooks**.
-1. Enter the name for your webhook, for example "GitLab integration".
+1. Enter the space where you want to receive notifications from GitLab.
+1. In the upper-left corner, from the space dropdown list, select **Apps and Integrations > Manage webhooks**.
+1. Enter the name for your webhook (for example, `GitLab integration`).
 1. Optional. Add an avatar for your bot.
 1. Select **Save**.
 1. Copy the webhook URL.
@@ -40,6 +40,10 @@ For further details, see [the Google Chat documentation for configuring webhooks
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27823) in GitLab 15.4.
 
+WARNING:
+In March 2023, Google [deprecated threaded replies in Google Chat](https://workspaceupdates.googleblog.com/2023/02/new-google-chat-spaces-will-be-in-line-threaded.html).
+This feature does not work for new Google Chat spaces. You can still use this feature in existing Google Chat spaces where threaded replies are already enabled.
+
 To enable threaded notifications for the same GitLab object (for example, an issue or merge request):
 
 1. Go to [Google Chat](https://chat.google.com/).
@@ -56,9 +60,9 @@ To enable the integration in GitLab:
 1. In your project, go to **Settings > Integrations** and select **Google Chat**.
 1. Scroll down to the end of the page where you find a **Webhook** field.
 1. Enter the webhook URL you copied from Google Chat.
-1. Select the events you want to be notified about in your Google Chat room.
-1. Optional. Select **Test settings** to verify the connection.
+1. Select the events you want to be notified about in your Google Chat space.
+1. Optional. Select **Test settings**.
 1. Select **Save changes**.
 
 To test the integration, make a change based on the events you selected and
-see the notification in your Google Chat room.
+see the notification in your Google Chat space.
diff --git a/doc/user/project/integrations/harbor.md b/doc/user/project/integrations/harbor.md
index 4a586054aee..12986cba555 100644
--- a/doc/user/project/integrations/harbor.md
+++ b/doc/user/project/integrations/harbor.md
@@ -25,8 +25,8 @@ In the Harbor instance, ensure that:
 
 GitLab supports integrating Harbor projects at the group or project level. Complete these steps in GitLab:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Harbor**.
 1. Turn on the **Active** toggle under **Enable Integration**.
 1. Provide the Harbor configuration information:
diff --git a/doc/user/project/integrations/img/merge_request_performance.png b/doc/user/project/integrations/img/merge_request_performance.png
deleted file mode 100644
index a9cd761cdcb..00000000000
--- a/doc/user/project/integrations/img/merge_request_performance.png
+++ /dev/null
diff --git a/doc/user/project/integrations/img/prometheus_dashboard.png b/doc/user/project/integrations/img/prometheus_dashboard.png
deleted file mode 100644
index 24d855eb50c..00000000000
--- a/doc/user/project/integrations/img/prometheus_dashboard.png
+++ /dev/null
diff --git a/doc/user/project/integrations/img/prometheus_manual_configuration_v13_2.png b/doc/user/project/integrations/img/prometheus_manual_configuration_v13_2.png
deleted file mode 100644
index b6ec08f492d..00000000000
--- a/doc/user/project/integrations/img/prometheus_manual_configuration_v13_2.png
+++ /dev/null
diff --git a/doc/user/project/integrations/index.md b/doc/user/project/integrations/index.md
index f7019b2eeb2..c70a58a24d2 100644
--- a/doc/user/project/integrations/index.md
+++ b/doc/user/project/integrations/index.md
@@ -18,8 +18,8 @@ Prerequisites:
 
 To view the available integrations for your project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 
 You can also view and manage integration settings across [all projects in an instance or group](../../admin_area/settings/project_integration_management.md).
 For a single project, you can choose to inherit the instance or group configuration,
@@ -50,6 +50,7 @@ You can configure the following integrations.
 | [Bugzilla](bugzilla.md)                                                     | Use Bugzilla as the issue tracker.                                    | **{dotted-circle}** No |
 | Buildkite                                                                   | Run CI/CD pipelines with Buildkite.                                   | **{check-circle}** Yes |
 | Campfire                                                                    | Connect to chat.                                                      | **{dotted-circle}** No |
+| [ClickUp](clickup.md)                                                       | Use ClickUp as the issue tracker.                                    | **{dotted-circle}** No |
 | [Confluence Workspace](../../../api/integrations.md#confluence-integration) | Use Confluence Cloud Workspace as an internal wiki.                   | **{dotted-circle}** No |
 | [Custom issue tracker](custom_issue_tracker.md)                             | Use a custom issue tracker.                                           | **{dotted-circle}** No |
 | [Datadog](../../../integration/datadog.md)                                  | Trace your GitLab pipelines with Datadog.                             | **{check-circle}** Yes |
@@ -80,6 +81,7 @@ You can configure the following integrations.
 | [Slack notifications](slack.md)                                             | Send notifications about project events to Slack.                     | **{dotted-circle}** No |
 | [Slack slash commands](slack_slash_commands.md)                             | Enable slash commands in a workspace.                                 | **{dotted-circle}** No |
 | [Squash TM](squash_tm.md)                                                   | Update Squash TM requirements when GitLab issues are modified.        | **{check-circle}** Yes |
+| [Telegram](telegram.md)                                                     | Send notifications about project events to Telegram.                  | **{dotted-circle}** No |
 | [Unify Circuit](unify_circuit.md)                                           | Send notifications about project events to Unify Circuit.             | **{dotted-circle}** No |
 | [Webex Teams](webex_teams.md)                                               | Receive events notifications.                                         | **{dotted-circle}** No |
 | [YouTrack](youtrack.md)                                                     | Use YouTrack as the issue tracker.                                    | **{dotted-circle}** No |
diff --git a/doc/user/project/integrations/irker.md b/doc/user/project/integrations/irker.md
index df11ed3e57c..7d3c85b2c62 100644
--- a/doc/user/project/integrations/irker.md
+++ b/doc/user/project/integrations/irker.md
@@ -39,8 +39,8 @@ network. For more details, read
 
 ## Complete these steps in GitLab
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **irker (IRC gateway)**.
 1. Ensure that the **Active** toggle is enabled.
 1. Optional. Under **Server host**, enter the server host address where `irkerd` runs. If empty,
@@ -50,8 +50,9 @@ network. For more details, read
    It's prepended to every channel or user provided under **Recipients**, which is not a full URI.
 1. Under **Recipients**, enter the users or channels to receive updates, separated by spaces
    (for example, `#channel1 user1`). For more details, see [Enter irker recipients](#enter-irker-recipients).
-1. Optional. Under **Colorize messages**, select the checkbox. irker will highlight your messages.
-1. Select **Save changes** or optionally select **Test Settings**.
+1. Optional. To highlight messages, select the **Colorize messages** checkbox.
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
 
 ## Enter irker recipients
 
diff --git a/doc/user/project/integrations/mattermost.md b/doc/user/project/integrations/mattermost.md
index a50d341c38e..a73c0f001f3 100644
--- a/doc/user/project/integrations/mattermost.md
+++ b/doc/user/project/integrations/mattermost.md
@@ -41,8 +41,8 @@ Display name override is not enabled by default, you need to ask your administra
 After the Mattermost instance has an incoming webhook set up, you can set up GitLab
 to send the notifications:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Mattermost notifications**.
 1. Select the GitLab events to generate notifications for. For each event you select, input the Mattermost channel
    to receive the notification. You do not need to add the hash sign (`#`).
diff --git a/doc/user/project/integrations/mattermost_slash_commands.md b/doc/user/project/integrations/mattermost_slash_commands.md
index 3b5e4030487..a8d8323a651 100644
--- a/doc/user/project/integrations/mattermost_slash_commands.md
+++ b/doc/user/project/integrations/mattermost_slash_commands.md
@@ -17,9 +17,9 @@ separately configured [Mattermost notifications](mattermost.md).
 GitLab provides different ways to configure Mattermost slash commands. For any of these options,
 you must have Mattermost [3.4 or later](https://mattermost.com/blog/category/platform/releases/).
 
-- **Omnibus GitLab installations**: Mattermost is bundled with
-  [Omnibus GitLab](https://docs.gitlab.com/omnibus/). To configure Mattermost for Omnibus GitLab,
-  read the [Omnibus GitLab Mattermost documentation](../../../integration/mattermost/index.md).
+- **Linux package installations**: Mattermost is bundled with
+  [Linux package](https://docs.gitlab.com/omnibus/). To configure Mattermost for Linux package
+  installations, read the [Linux package Mattermost documentation](../../../integration/mattermost/index.md).
 - **If Mattermost is installed on the same server as GitLab**, use the
   [automated configuration](#configure-automatically).
 - **For all other installations**, use the [manual configuration](#configure-manually).
@@ -29,9 +29,9 @@ you must have Mattermost [3.4 or later](https://mattermost.com/blog/category/pla
 If Mattermost is installed on the same server as GitLab,
 you can automatically configure Mattermost slash commands:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
-1. In **Add an integration**, select **Mattermost slash commands**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
+1. Select **Mattermost slash commands**.
 1. In **Enable integration**, ensure the **Active** checkbox is selected.
 1. Select **Add to Mattermost**, and select **Save changes**.
 
@@ -65,8 +65,9 @@ To get configuration values from GitLab:
 
 1. In a different browser tab, sign in to
    GitLab as a user with administrator access.
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Integrations**.
 1. Select **Mattermost slash commands**. GitLab displays potential values for Mattermost settings.
 1. Copy the **Request URL** value. All other values are suggestions.
 1. Do not close this browser tab. You need it in a later step.
@@ -133,7 +134,7 @@ The available slash commands for Mattermost are:
 ## Related topics
 
 - [Mattermost slash commands](https://developers.mattermost.com/integrate/slash-commands/)
-- [Omnibus GitLab Mattermost](../../../integration/mattermost/index.md)
+- [Linux package Mattermost](../../../integration/mattermost/index.md)
 
 ## Troubleshooting
 
diff --git a/doc/user/project/integrations/microsoft_teams.md b/doc/user/project/integrations/microsoft_teams.md
index 5d2c27fc2a4..3d0b77069a3 100644
--- a/doc/user/project/integrations/microsoft_teams.md
+++ b/doc/user/project/integrations/microsoft_teams.md
@@ -35,8 +35,8 @@ After you configure Microsoft Teams to receive notifications, you must configure
 GitLab to send the notifications:
 
 1. Sign in to GitLab as an administrator.
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Microsoft Teams notifications**.
 1. To enable the integration, select **Active**.
 1. In the **Trigger** section, select the checkbox next to each event to enable it:
diff --git a/doc/user/project/integrations/mlflow_client.md b/doc/user/project/integrations/mlflow_client.md
index 75fae4647d0..cffa2649cc8 100644
--- a/doc/user/project/integrations/mlflow_client.md
+++ b/doc/user/project/integrations/mlflow_client.md
@@ -6,10 +6,10 @@ info: Machine Learning Experiment Tracking is a GitLab Incubation Engineering pr
 
 # MLflow client integration **(FREE)**
 
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/8560) in GitLab 15.11 as an [Experiment](../../../policy/alpha-beta-support.md#experiment) release [with a flag](../../../administration/feature_flags.md) named `ml_experiment_tracking`. Disabled by default.
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/8560) in GitLab 15.11 as an [Experiment](../../../policy/experiment-beta-support.md#experiment) release [with a flag](../../../administration/feature_flags.md) named `ml_experiment_tracking`. Disabled by default.
 
 NOTE:
-Model experiment tracking is an [experimental feature](../../../policy/alpha-beta-support.md).
+Model experiment tracking is an [experimental feature](../../../policy/experiment-beta-support.md).
 Refer to <https://gitlab.com/gitlab-org/gitlab/-/issues/381660> for feedback and feature requests.
 
 [MLflow](https://mlflow.org/) is a popular open source tool for Machine Learning Experiment Tracking.
@@ -23,7 +23,9 @@ GitLab plays the role of a MLflow server. Running `mlflow server` is not necessa
 Prerequisites:
 
 - A [personal access token](../../../user/profile/personal_access_tokens.md) for the project, with minimum access level of `api`.
-- The project ID. To find the project ID, on the top bar, select **Main menu > Projects** and find your project. On the left sidebar, select **Settings > General**.
+- The project ID. To find the project ID:
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+  1. Select **Settings > General**.
 
 To enable MLflow client integration:
 
diff --git a/doc/user/project/integrations/pivotal_tracker.md b/doc/user/project/integrations/pivotal_tracker.md
index e1d48037ba8..7f53f08e808 100644
--- a/doc/user/project/integrations/pivotal_tracker.md
+++ b/doc/user/project/integrations/pivotal_tracker.md
@@ -37,11 +37,12 @@ In Pivotal Tracker, [create an API token](https://www.pivotaltracker.com/help/ar
 
 Complete these steps in GitLab:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Pivotal Tracker**.
 1. Ensure that the **Active** toggle is enabled.
 1. Paste the token you generated in Pivotal Tracker.
 1. Optional. To restrict this setting to specific branches, list them in the **Restrict to branch**
    field, separated with commas.
-1. Select **Save changes** or optionally select **Test settings**.
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
diff --git a/doc/user/project/integrations/pumble.md b/doc/user/project/integrations/pumble.md
index e05ff9489ca..62703ebfad9 100644
--- a/doc/user/project/integrations/pumble.md
+++ b/doc/user/project/integrations/pumble.md
@@ -26,14 +26,15 @@ notifications:
 1. To enable the integration for your group or project:
    1. In your group or project, on the left sidebar, select **Settings > Integrations**.
 1. To enable the integration for your instance:
-   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
    1. On the left sidebar, select **Settings > Integrations**.
 1. Select the **Pumble** integration.
 1. Ensure that the **Active** toggle is enabled.
 1. Select the checkboxes corresponding to the GitLab events you want to receive in Pumble.
 1. Paste the **Webhook** URL for the Pumble channel.
 1. Configure the remaining options.
-1. Optional. To test the integration, select **Test settings**.
+1. Optional. Select **Test settings**.
 1. Select **Save changes**.
 
 The Pumble channel begins to receive all applicable GitLab events.
diff --git a/doc/user/project/integrations/redmine.md b/doc/user/project/integrations/redmine.md
index df8a6681e2b..9cb93c2d082 100644
--- a/doc/user/project/integrations/redmine.md
+++ b/doc/user/project/integrations/redmine.md
@@ -9,8 +9,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 You can use [Redmine](https://www.redmine.org/) as an external issue tracker.
 To enable the Redmine integration in a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Redmine**.
 1. Select the checkbox under **Enable integration**.
 1. Fill in the required fields:
@@ -24,7 +24,8 @@ To enable the Redmine integration in a project:
      **This URL is not used and removal is planned in a future release.**
      For more information, see [issue 327503](https://gitlab.com/gitlab-org/gitlab/-/issues/327503).
 
-1. Select **Save changes** or optionally select **Test settings**.
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
 
 After you have configured and enabled Redmine, you see the Redmine link on the GitLab project pages,
 which takes you to your Redmine project.
diff --git a/doc/user/project/integrations/shimo.md b/doc/user/project/integrations/shimo.md
index cf9745929a1..6fbd246d7f4 100644
--- a/doc/user/project/integrations/shimo.md
+++ b/doc/user/project/integrations/shimo.md
@@ -21,11 +21,11 @@ This change is a breaking change.
 
 ## Configure settings in GitLab
 
-To enable the Shimo integration for your group or project:
+To enable the Shimo integration for your project:
 
-1. On the top bar, select **Main menu** and find your group or project.
-1. On the left sidebar, select **Settings > Integrations**.
-1. In **Add an integration**, select **Shimo**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
+1. Select **Shimo**.
 1. In **Enable integration**, ensure the **Active** checkbox is selected.
 1. Provide the **Shimo Workspace URL** you want to link to your group or project (for example, `https://shimo.im/space/aBAYV6VvajUP873j`).
 1. Select **Save changes**.
@@ -36,8 +36,8 @@ On the left sidebar, **Shimo** now appears instead of **Wiki**.
 
 To view the Shimo Workspace from your group or project:
 
-1. On the top bar, select **Main menu** and find your group or project.
-1. On the left sidebar, select **Shimo**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Shimo**.
 1. On the **Shimo Workspace** page, select **Go to Shimo Workspace**.
 
 <!--- end_remove -->
diff --git a/doc/user/project/integrations/slack.md b/doc/user/project/integrations/slack.md
index 5b769b84663..14183a47625 100644
--- a/doc/user/project/integrations/slack.md
+++ b/doc/user/project/integrations/slack.md
@@ -32,8 +32,8 @@ to control GitLab from Slack. Slash commands are configured separately.
 
 > [Changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106760) in GitLab 15.9 to limit Slack channels to 10 per event.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Slack notifications**.
 1. In the **Enable integration** section, select the **Active** checkbox.
 1. In the **Trigger** section, select the checkboxes for each type of GitLab
@@ -56,8 +56,8 @@ to control GitLab from Slack. Slash commands are configured separately.
 1. Leave the **Labels to be notified** field blank to get all notifications, or
    add labels that the issue or merge request must have to trigger a
    notification.
-1. Select **Test settings** to verify your information, and then select
-   **Save changes**.
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
 
 Your Slack team now starts receiving GitLab event notifications as configured.
 
diff --git a/doc/user/project/integrations/slack_slash_commands.md b/doc/user/project/integrations/slack_slash_commands.md
index 4fa4b75422e..74bd12561fb 100644
--- a/doc/user/project/integrations/slack_slash_commands.md
+++ b/doc/user/project/integrations/slack_slash_commands.md
@@ -19,11 +19,10 @@ The [Slack notifications integration](slack.md) is configured separately.
 
 ## Configure GitLab and Slack
 
-Slack slash command integrations
-are scoped to a project.
+Slack slash command integrations are scoped to a project.
 
-1. In GitLab, on the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Slack slash commands**. Leave this browser tab open.
 1. Open a new browser tab, sign in to your Slack team, and [start a new Slash Commands integration](https://my.slack.com/services/new/slash-commands).
 1. Enter a trigger command. We suggest you use the project name.
diff --git a/doc/user/project/integrations/squash_tm.md b/doc/user/project/integrations/squash_tm.md
index 2a1106edb0c..ff633783e83 100644
--- a/doc/user/project/integrations/squash_tm.md
+++ b/doc/user/project/integrations/squash_tm.md
@@ -26,8 +26,8 @@ are synchronized as requirements in Squash TM and test progress is reported in G
 
 ## Configure GitLab
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Squash TM**.
 1. Ensure that the **Active** toggle is enabled.
 1. In the **Trigger** section, indicate which type of issue is concerned by the real-time synchronization.
diff --git a/doc/user/project/integrations/telegram.md b/doc/user/project/integrations/telegram.md
new file mode 100644
index 00000000000..9d36a16f5fc
--- /dev/null
+++ b/doc/user/project/integrations/telegram.md
@@ -0,0 +1,57 @@
+---
+stage: Manage
+group: Import and Integrate
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Telegram **(FREE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122879) in GitLab 16.1.
+
+You can configure GitLab to send notifications to a Telegram chat or channel.
+To set up the Telegram integration, you must:
+
+1. [Create a Telegram bot](#create-a-telegram-bot).
+1. [Configure the Telegram bot](#configure-the-telegram-bot).
+1. [Set up the Telegram integration in GitLab](#set-up-the-telegram-integration-in-gitlab).
+
+## Create a Telegram bot
+
+To create a bot in Telegram:
+
+1. Start a new chat with `@BotFather`.
+1. [Create a new bot](https://core.telegram.org/bots/features#creating-a-new-bot) as described in the Telegram documentation.
+
+When you create a bot, `BotFather` provides you with an API token. Keep this token secure as you need it to authenticate the bot in Telegram.
+
+## Configure the Telegram bot
+
+To configure the bot in Telegram:
+
+1. Add the bot as an administrator to a new or existing channel.
+1. Assign the bot `Post Messages` rights to receive events.
+1. Create an identifier for the channel.
+   - For public channels, enter a public link and copy the channel identifier (for example, `https:/t.me/MY_IDENTIFIER`).
+   - For private channels, use the [`getUpdates`](https://telegram-bot-sdk.readme.io/reference/getupdates) method with your API token and copy the channel identifier.
+
+## Set up the Telegram integration in GitLab
+
+After you invite the bot to a Telegram channel, you can configure GitLab to send notifications:
+
+1. To enable the integration:
+   - **For your group or project:**
+     1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+     1. Select **Settings > Integrations**.
+   - **For your instance:**
+     1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+     1. Select **Admin Area**.
+     1. Select **Settings > Integrations**.
+1. Select **Telegram**.
+1. In **Enable integration**, select the **Active** checkbox.
+1. In **New token**, [paste the token value from the Telegram bot](#create-a-telegram-bot).
+1. In the **Trigger** section, select the checkboxes for the GitLab events you want to receive in Telegram.
+1. In **Channel identifier**, [paste the Telegram channel identifier](#configure-the-telegram-bot).
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
+
+The Telegram channel can now receive all selected GitLab events.
diff --git a/doc/user/project/integrations/unify_circuit.md b/doc/user/project/integrations/unify_circuit.md
index d20b19a3aaa..7d0dd6d2af3 100644
--- a/doc/user/project/integrations/unify_circuit.md
+++ b/doc/user/project/integrations/unify_circuit.md
@@ -15,14 +15,15 @@ copy its URL.
 
 In GitLab:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **Unify Circuit**.
 1. Turn on the **Active** toggle.
 1. Select the checkboxes corresponding to the GitLab events you want to receive in Unify Circuit.
 1. Paste the **Webhook URL** that you copied from the Unify Circuit configuration step.
 1. Select the **Notify only broken pipelines** checkbox to notify only on failures.
 1. In the **Branches for which notifications are to be sent** dropdown list, select which types of branches to send notifications for.
-1. Select `Save changes` or optionally select **Test settings**.
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
 
 Your Unify Circuit conversation now starts receiving GitLab event notifications.
diff --git a/doc/user/project/integrations/webex_teams.md b/doc/user/project/integrations/webex_teams.md
index c755c7a5c17..3ba05476e63 100644
--- a/doc/user/project/integrations/webex_teams.md
+++ b/doc/user/project/integrations/webex_teams.md
@@ -21,18 +21,22 @@ You can configure GitLab to send notifications to a Webex Teams space:
 
 ## Configure settings in GitLab
 
-Once you have a webhook URL for your Webex Teams space, you can configure GitLab to send
+After you have a webhook URL for your Webex Teams space, you can configure GitLab to send
 notifications:
 
-1. Navigate to:
-   - **Settings > Integrations** in a project to enable the integration at the project level.
-   - **Settings > Integrations** in a group to enable the integration at the group level.
-   - On the top bar, select **Main menu > Admin**. Then, in the left sidebar,
-     select **Settings > Integrations** to enable an instance-level integration.
+1. To enable integration:
+   - At the project or group level:
+     1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+     1. Select **Settings > Integrations**.
+   - At the instance level:
+     1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+     1. Select **Admin Area**.
+     1. Select **Settings > Integrations**.
 1. Select the **Webex Teams** integration.
 1. Ensure that the **Active** toggle is enabled.
 1. Select the checkboxes corresponding to the GitLab events you want to receive in Webex Teams.
 1. Paste the **Webhook** URL for the Webex Teams space.
-1. Configure the remaining options and then select **Test settings and save changes**.
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
 
 The Webex Teams space begins to receive all applicable GitLab events.
diff --git a/doc/user/project/integrations/webhook_events.md b/doc/user/project/integrations/webhook_events.md
index fda778aa167..dfff537e4a1 100644
--- a/doc/user/project/integrations/webhook_events.md
+++ b/doc/user/project/integrations/webhook_events.md
@@ -786,7 +786,7 @@ Payload example:
     "noteable_id": 53,
     "system": false,
     "st_diff": null,
-    "url": "http://example.com/gitlab-org/gitlab-test/snippets/53#note_1245"
+    "url": "http://example.com/gitlab-org/gitlab-test/-/snippets/53#note_1245"
   },
   "snippet": {
     "id": 53,
@@ -799,7 +799,8 @@ Payload example:
     "file_name": "test.rb",
     "expires_at": null,
     "type": "ProjectSnippet",
-    "visibility_level": 0
+    "visibility_level": 0,
+    "url": "http://example.com/gitlab-org/gitlab-test/-/snippets/53"
   }
 }
 ```
@@ -1109,6 +1110,9 @@ and later, the pipeline webhook returns only the latest jobs.
 In [GitLab 15.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89546)
 and later, pipeline webhooks triggered by blocked users are not processed.
 
+In [GitLab 16.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123639)
+and later, pipeline webhooks started to expose `object_attributes.name`.
+
 Request header:
 
 ```plaintext
@@ -1123,6 +1127,7 @@ Payload example:
    "object_attributes":{
       "id": 31,
       "iid": 3,
+      "name": "Pipeline for branch: master",
       "ref": "master",
       "tag": false,
       "sha": "bcbb5ec396a2c0f828686f14fac9b80b780504f2",
@@ -1142,7 +1147,8 @@ Payload example:
           "key": "NESTOR_PROD_ENVIRONMENT",
           "value": "us-west-1"
         }
-      ]
+      ],
+      "url": "http://example.com/gitlab-org/gitlab-test/-/pipelines/31"
    },
     "merge_request": {
       "id": 1,
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index 7fcb2680504..5c8fc5703dd 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -136,10 +136,25 @@ intermittently and are temporarily disabled. These webhooks are initially disabl
 for one minute, which is extended on each subsequent failure up to a maximum of 24 hours.
 
 Project or group webhooks that return response codes in the `4xx` range are understood to be
-misconfigured and are permanently disabled until you manually re-enable
-them yourself.
+misconfigured and are permanently disabled until you [manually re-enable](#re-enable-disabled-webhooks)
+the webhooks yourself.
 
-For more information about disabled webhooks, see [troubleshooting](#troubleshooting).
+### Re-enable disabled webhooks
+
+> - Introduced in GitLab 15.2 [with a flag](../../../administration/feature_flags.md) named `webhooks_failed_callout`. Disabled by default.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/365535) in GitLab 15.7. Feature flag `webhooks_failed_callout` removed.
+
+If a webhook is failing, a banner displays at the top of the edit page explaining
+why the webhook is disabled and when it is automatically re-enabled. For example:
+
+![A banner for a failing webhook, warning it has failed to connect and is retrying in 60 minutes](img/failed_banner.png)
+
+In the case of a failed webhook, an error banner is displayed:
+
+![A banner for a failed webhook, showing an error state, and explaining how to re-enable it](img/failed_banner_error.png)
+
+To re-enable a failing or failed webhook, [send a test request](#test-a-webhook). If the test
+request succeeds, the webhook is re-enabled.
 
 ## Test a webhook
 
@@ -274,6 +289,33 @@ Webhook requests to your endpoint include the following headers:
 | `X-Gitlab-Event` | Name of the webhook type. Corresponds to [event types](webhook_events.md) but in the format `"<EVENT> Hook"`. | `"Push Hook"` |
 | `X-Gitlab-Event-UUID` | Unique ID per webhook that is not recursive. A hook is recursive if triggered by an earlier webhook that hit the GitLab instance. Recursive webhooks have the same value for this header. | `"13792a34-cac6-4fda-95a8-c58e00a3954e"` |
 
+## Develop webhooks
+
+If you don't have an existing HTTPS endpoint or URL for your webhook setup, you must deploy one on a server. This HTTPS endpoint is used in configuration. To develop against GitLab webhooks and capture the payloads, you can use:
+
+- [Public webhook inspection and testing tools](#public-webhook-inspection-and-testing-tools)
+- [The GitLab Development Kit (GDK)](#gitlab-development-kit-gdk)
+- [Recently triggered webhook payloads in GitLab settings](#recently-triggered-webhook-payloads-in-gitlab-settings)
+
+### Public webhook inspection and testing tools
+
+You can use public tools to inspect and test webhook payloads. These tools act as catch-all endpoints for HTTP requests and respond with a `200 OK` HTTP status code. You can use these payloads to develop your webhook services.
+
+You should exercise caution when using these tools as you might be sending sensitive data to external tools. You should use test tokens with these tools and rotate any secrets inadvertently sent to a third party.
+
+These public tools include:
+
+- [Beeceptor](https://beeceptor.com) to create a temporary HTTPS endpoint and inspect incoming payloads
+- [Webhook.site](https://webhook.site) to review incoming payloads
+
+### GitLab Development Kit (GDK)
+
+For a safer development environment, you can use the [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) to develop against GitLab webhooks locally. With the GDK, you can send webhooks from your local GitLab instance to a webhook receiver running locally on your machine. To use this approach, you must install and configure the GDK.
+
+### Recently triggered webhook payloads in GitLab settings
+
+You can [review recently triggered webhook payloads](#troubleshooting) in GitLab settings. For each webhook event, a detail page exists with information about the data GitLab sends and receives from the webhook endpoint.
+
 ## Troubleshooting
 
 > **Recent events** for group webhooks [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/325642) in GitLab 15.3.
@@ -334,19 +376,4 @@ If you're receiving multiple webhook requests, the webhook might have timed out.
 
 GitLab expects a response in [10 seconds](../../../user/gitlab_com/index.md#other-limits). On self-managed GitLab instances, you can [change the webhook timeout limit](../../../administration/instance_limits.md#webhook-timeout).
 
-### Re-enable disabled webhooks
-
-> - Introduced in GitLab 15.2 [with a flag](../../../administration/feature_flags.md) named `webhooks_failed_callout`. Disabled by default.
-> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/365535) in GitLab 15.7. Feature flag `webhooks_failed_callout` removed.
-
-If a webhook is failing, a banner displays at the top of the edit page explaining
-why it is disabled, and when it is automatically re-enabled. For example:
-
-![A banner for a failing webhook, warning it has failed to connect and is retrying in 60 minutes](img/failed_banner.png)
-
-In the case of a failed webhook, an error banner is displayed:
-
-![A banner for a failed webhook, showing an error state, and explaining how to re-enable it](img/failed_banner_error.png)
-
-To re-enable a failing or failed webhook, [send a test request](#test-a-webhook). If the test
-request succeeds, the webhook is re-enabled.
+If a webhook is not triggered, the webhook might be [automatically disabled](#failing-webhooks).
diff --git a/doc/user/project/integrations/youtrack.md b/doc/user/project/integrations/youtrack.md
index ee5ca8eca78..8845aa8fdfd 100644
--- a/doc/user/project/integrations/youtrack.md
+++ b/doc/user/project/integrations/youtrack.md
@@ -14,15 +14,16 @@ You can configure YouTrack as an
 
 To enable the YouTrack integration in a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **YouTrack**.
 1. Select the checkbox under **Enable integration**.
 1. Fill in the required fields:
    - **Project URL**: The URL to the project in YouTrack.
    - **Issue URL**: The URL to view an issue in the YouTrack project.
      The URL must contain `:id`. GitLab replaces `:id` with the issue number.
-1. Select **Save changes** or optionally select **Test settings**.
+1. Optional. Select **Test settings**.
+1. Select **Save changes**.
 
 After you configure and enable YouTrack, a link appears on the GitLab
 project pages. This link takes you to the appropriate YouTrack project.
diff --git a/doc/user/project/integrations/zentao.md b/doc/user/project/integrations/zentao.md
index 19f6a3e315c..b14b9eac9da 100644
--- a/doc/user/project/integrations/zentao.md
+++ b/doc/user/project/integrations/zentao.md
@@ -52,7 +52,7 @@ Complete these steps in GitLab:
 
    ![ZenTao settings page](img/zentao_product_id.png)
 
-1. To verify the ZenTao connection is working, select **Test settings**.
+1. Optional. Select **Test settings**.
 1. Select **Save changes**.
 
 <!--- end_remove -->
diff --git a/doc/user/project/issues/confidential_issues.md b/doc/user/project/issues/confidential_issues.md
index 79278d1b3ad..7e5f26d3526 100644
--- a/doc/user/project/issues/confidential_issues.md
+++ b/doc/user/project/issues/confidential_issues.md
@@ -15,36 +15,36 @@ keep security vulnerabilities private or prevent surprises from leaking out.
 
 You can make an issue confidential when you create or edit an issue.
 
+### In a new issue
+
 When you create a new issue, a checkbox right below the text area is available
 to mark the issue as confidential. Check that box and select **Create issue**
-to create the issue. For existing issues, edit them, check the
-confidential checkbox and select **Save changes**.
+to create the issue.
 
 When you create a confidential issue in a project, the project becomes listed in the **Contributed projects** section in your [profile](../../profile/index.md). **Contributed projects** does not show information about the confidential issue; it only shows the project name.
 
-![Creating a new confidential issue](img/confidential_issues_create_v15_4.png)
-
-## Modify issue confidentiality
+To create a confidential issue:
 
-There are two ways to change an issue's confidentiality.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, at the top, select **Create new...** (**{plus}**).
+1. From the dropdown list, select **New issue**.
+1. Complete the [fields](create_issues.md#fields-in-the-new-issue-form).
+   - Select the **This issue is confidential...** checkbox.
+1. Select **Create issue**.
 
-The first way is to edit the issue and toggle the confidentiality checkbox.
-After you save the issue, the confidentiality of the issue is updated.
+### In an existing issue
 
-The second way is to locate the **Confidentiality** section in the sidebar and select
-**Edit**. A popup should appear and give you the option to turn on or turn off confidentiality.
+To change the confidentiality of an existing issue:
 
-| Turn off confidentiality | Turn on confidentiality |
-| :-----------: | :----------: |
-| ![Turn off confidentiality](img/turn_off_confidentiality_v15_1.png) | ![Turn on confidentiality](img/turn_on_confidentiality_v15_1.png) |
-
-Every change from regular to confidential and vice versa, is indicated by a
-system note in the issue's comments:
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**.
+1. Select the title of your issue to view it.
+1. On the right sidebar, next to **Confidentiality**, select **Edit**.
+1. Select **Turn on** (or **Turn off** to make the issue non-confidential).
 
-![Confidential issues system notes](img/confidential_issues_system_notes_v15_4.png)
+Alternatively, you can use the `/confidential` [quick action](../quick_actions.md#issues-merge-requests-and-epics).
 
-- **{eye-slash}** The issue is made confidential.
-- **{eye}** The issue is made public.
+## Who can see confidential issues
 
 When an issue is made confidential, only users with at least the Reporter role
 for the project have access to the issue.
@@ -53,8 +53,8 @@ the issue even if they were actively participating before the change.
 
 ## Confidential issue indicators
 
-There are a few things that visually separate a confidential issue from a
-regular one. In the issues index page view, you can see the confidential (**{eye-slash}**) icon
+Confidential issues are visually different from regular issues in a few ways.
+In the issues index page view, you can see the confidential (**{eye-slash}**) icon
 next to the issues that are marked as confidential:
 
 ![Confidential issues index page](img/confidential_issues_index_page.png)
@@ -62,8 +62,6 @@ next to the issues that are marked as confidential:
 If you don't have [enough permissions](#permissions-and-access-to-confidential-issues),
 you cannot see confidential issues at all.
 
----
-
 Likewise, while inside the issue, you can see the confidential (**{eye-slash}**) icon right next to
 the issue number. There is also an indicator in the comment area that the
 issue you are commenting on is confidential.
@@ -76,6 +74,14 @@ There is also an indicator on the sidebar denoting confidentiality.
 | :-----------: | :----------: |
 | ![Sidebar confidential issue](img/sidebar_confidential_issue.png) | ![Sidebar not confidential issue](img/sidebar_not_confidential_issue.png) |
 
+Every change from regular to confidential and vice versa, is indicated by a
+system note in the issue's comments:
+
+- **{eye-slash}** The issue is made confidential.
+- **{eye}** The issue is made public.
+
+![Confidential issues system notes](img/confidential_issues_system_notes_v15_4.png)
+
 ## Merge requests for confidential issues
 
 Although you can create confidential issues (and make existing issues confidential) in a public project, you cannot make confidential merge requests.
@@ -83,7 +89,7 @@ Learn how to create [merge requests for confidential issues](../merge_requests/c
 
 ## Permissions and access to confidential issues
 
-There are two kinds of level access for confidential issues. The general rule
+Access to confidential issues is by one of two routes. The general rule
 is that confidential issues are visible only to members of a project with at
 least the **Reporter role**.
 
diff --git a/doc/user/project/issues/create_issues.md b/doc/user/project/issues/create_issues.md
index 4511c89b0ff..3e7cfc12da7 100644
--- a/doc/user/project/issues/create_issues.md
+++ b/doc/user/project/issues/create_issues.md
@@ -28,11 +28,11 @@ Prerequisites:
 
 To create an issue:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Either:
 
-   - On the left sidebar, select **Issues**, and then, in the upper-right corner, select **New issue**.
-   - On the top bar, select the plus sign (**{plus-square}**) and then, under **This project**,
+   - On the left sidebar, select **Plan > Issues**, and then, in the upper-right corner, select **New issue**.
+   - On the left sidebar, at the top, select the plus sign (**{plus}**) and then, under **In this project**,
      select **New issue**.
 
 1. Complete the [fields](#fields-in-the-new-issue-form).
@@ -51,8 +51,8 @@ Prerequisites:
 
 To create an issue from a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Issues**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Issues**.
 1. In the upper-right corner, select **Select project to create issue**.
 1. Select the project you'd like to create an issue for. The button now reflects the selected
    project.
@@ -98,7 +98,7 @@ Prerequisites:
 
 To create an issue from a project issue board:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Select **Issues > Boards**.
 1. At the top of a board list, select **List actions** (**{ellipsis_v}**) **> Create new issue**.
 1. Enter the issue's title.
@@ -106,7 +106,7 @@ To create an issue from a project issue board:
 
 To create an issue from a group issue board:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. Select **Issues > Boards**.
 1. At the top of a board list, select **List actions** (**{ellipsis_v}**) **> Create new issue**.
 1. Enter the issue's title.
@@ -130,8 +130,8 @@ Prerequisites:
 
 To email an issue to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. Select **Issues**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**.
 1. At the bottom of the page, select **Email a new issue to this project**.
 1. To copy the email address, select **Copy** (**{copy-to-clipboard}**).
 1. From your email client, send an email to this address.
@@ -197,7 +197,7 @@ To offer email support, enable [Service Desk](../service_desk.md) for your proje
 Now, when your customer sends a new email, a new issue can be created in
 the appropriate project and followed up from there.
 
-### Fields in the new issue form
+## Fields in the new issue form
 
 > - Adding the new issue to an epic [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13847) in GitLab 13.1.
 > - Iteration field [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/233517) in GitLab 15.6.
diff --git a/doc/user/project/issues/design_management.md b/doc/user/project/issues/design_management.md
index 10b29feb072..9c04a40cb32 100644
--- a/doc/user/project/issues/design_management.md
+++ b/doc/user/project/issues/design_management.md
@@ -70,7 +70,7 @@ Support for PDF files is tracked in [issue 32811](https://gitlab.com/gitlab-org/
   - [A project is destroyed](https://gitlab.com/gitlab-org/gitlab/-/issues/13429).
   - [An issue is deleted](https://gitlab.com/gitlab-org/gitlab/-/issues/13427).
 - In GitLab 12.7 and later, Design Management data [can be replicated](../../../administration/geo/replication/datatypes.md#limitations-on-replicationverification)
-  by Geo but [not verified](https://gitlab.com/gitlab-org/gitlab/-/issues/32467).
+  and in GitLab 16.1 and later it can be [verified by Geo as well](https://gitlab.com/gitlab-org/gitlab/-/issues/355660).
 
 ## View a design
 
@@ -119,9 +119,7 @@ To move around the image while zoomed in, drag the image.
 
 ## Add a design to an issue
 
-> - Drag and drop uploads [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34353) in GitLab 12.9.
-> - New version creation on upload [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34353) in GitLab 12.9.
-> - Copy and paste uploads [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202634) in GitLab 12.10.
+> Ability to edit the description [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/388449) in GitLab 16.1.
 
 Prerequisites:
 
@@ -199,6 +197,21 @@ Only the latest version of the designs can be archived.
 Archived designs are not permanently lost. You can browse
 [previous versions](#add-a-new-version-of-a-design).
 
+<!-- When content_editor_on_issues flag is removed, move version notes
+     to "Add a design to an issue", update that topic, and delete the one below. -->
+
+## Markdown and rich text editors for descriptions
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/388449) in GitLab 16.1 [with a flag](../../../administration/feature_flags.md) named `content_editor_on_issues`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `content_editor_on_issues`.
+On GitLab.com, this feature is not available.
+This feature is not ready for production use.
+
+When this feature is enabled, you can use the Markdown and rich text editor in design descriptions.
+It's the same editor you use for comments across GitLab.
+
 ## Reorder designs
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34382) in GitLab 13.3.
diff --git a/doc/user/project/issues/img/confidential_issues_create_v15_4.png b/doc/user/project/issues/img/confidential_issues_create_v15_4.png
deleted file mode 100644
index ff489ad8605..00000000000
--- a/doc/user/project/issues/img/confidential_issues_create_v15_4.png
+++ /dev/null
diff --git a/doc/user/project/issues/img/turn_off_confidentiality_v15_1.png b/doc/user/project/issues/img/turn_off_confidentiality_v15_1.png
deleted file mode 100644
index e6050aec0de..00000000000
--- a/doc/user/project/issues/img/turn_off_confidentiality_v15_1.png
+++ /dev/null
diff --git a/doc/user/project/issues/img/turn_on_confidentiality_v15_1.png b/doc/user/project/issues/img/turn_on_confidentiality_v15_1.png
deleted file mode 100644
index c81ac85ab13..00000000000
--- a/doc/user/project/issues/img/turn_on_confidentiality_v15_1.png
+++ /dev/null
diff --git a/doc/user/project/issues/index.md b/doc/user/project/issues/index.md
index 6c9a645d817..a43dd65ed74 100644
--- a/doc/user/project/issues/index.md
+++ b/doc/user/project/issues/index.md
@@ -22,6 +22,13 @@ For more information about using issues, see the GitLab blog post:
 Issues are always associated with a specific project. If you have multiple
 projects in a group, you can view all of the projects' issues at once.
 
+<div class="video-fallback">
+  See the video: <a href="https://www.youtube.com/watch?v=tTE6omrBBZI">Issues - Setting up your Organization with GitLab</a>.
+</div>
+<figure class="video-container">
+  <iframe src="https://www.youtube-nocookie.com/embed/tTE6omrBBZI" frameborder="0" allowfullscreen> </iframe>
+</figure>
+
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 To learn how the GitLab Strategic Marketing department uses GitLab issues with [labels](../labels.md) and
 [issue boards](../issue_board.md), see the video on
diff --git a/doc/user/project/issues/managing_issues.md b/doc/user/project/issues/managing_issues.md
index 276cc3bc7a5..6f1c14b2b80 100644
--- a/doc/user/project/issues/managing_issues.md
+++ b/doc/user/project/issues/managing_issues.md
@@ -18,6 +18,8 @@ Prerequisites:
 
 To edit an issue:
 
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select the title of your issue to view it.
 1. To the right of the title, select **Edit title and description** (**{pencil}**).
 1. Edit the available fields.
 1. Select **Save changes**.
@@ -52,8 +54,8 @@ Prerequisites:
 
 To edit multiple issues at the same time:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**.
 1. Select **Bulk edit**. A sidebar on the right of your screen appears.
 1. Select the checkboxes next to each issue you want to edit.
 1. From the sidebar, edit the available fields.
@@ -85,8 +87,8 @@ Prerequisites:
 
 To edit multiple issues at the same time:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Issues**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Plan > Issues**.
 1. Select **Bulk edit**. A sidebar on the right of your screen appears.
 1. Select the checkboxes next to each issue you want to edit.
 1. From the sidebar, edit the available fields.
@@ -114,7 +116,8 @@ Prerequisites:
 
 To move an issue:
 
-1. Go to the issue.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your issue to view it.
 1. On the right sidebar, select **Move issue**.
 1. Search for a project to move the issue to.
 1. Select **Move**.
@@ -125,7 +128,7 @@ To move an issue:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15991) in GitLab 15.6.
 
-You can move multiple issues at the same time when you’re in a project.
+You can move multiple issues at the same time when you're in a project.
 You can't move tasks or test cases.
 
 Prerequisite:
@@ -134,8 +137,8 @@ Prerequisite:
 
 To move multiple issues at the same time:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**.
 1. Select **Bulk edit**. A sidebar on the right of your screen appears.
 1. Select the checkboxes next to each issue you want to move.
 1. From the right sidebar, select **Move selected**.
@@ -204,10 +207,13 @@ Prerequisites:
 
 - You must have at least the Reporter role for the project, be the author of the issue, or be assigned to the issue.
 
-To close an issue, you can do the following:
+To close an issue, you can either:
 
-- At the top of the issue, select **Close issue**.
 - In an [issue board](../issue_board.md), drag an issue card from its list into the **Closed** list.
+- From any other page in the GitLab UI:
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+  1. Select **Plan > Issues**, then select your issue to view it.
+  1. At the top of the issue, select **Close issue**.
 
 <!-- Delete when the `moved_mr_sidebar` feature flag is removed -->
 If you don't see this action at the top of an issue, your project or instance might have
@@ -300,8 +306,8 @@ Prerequisites:
 
 To disable automatic issue closing:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Branch defaults**.
 1. Clear the **Auto-close referenced issues on default branch** checkbox.
 1. Select **Save changes**.
@@ -330,6 +336,8 @@ Prerequisites:
 
 To change issue type:
 
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your issue to view it.
 1. To the right of the title, select **Edit title and description** (**{pencil}**).
 1. Edit the issue and select an issue type from the **Issue type** dropdown list:
 
@@ -348,12 +356,16 @@ Prerequisites:
 
 To delete an issue:
 
-1. In an issue, select **Issue actions** (**{ellipsis_v}**).
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your issue to view it.
+1. On the top right corner, select **Issue actions** (**{ellipsis_v}**).
 1. Select **Delete issue**.
 
 Alternatively:
 
-1. In an issue, select **Edit title and description** (**{pencil}**).
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select the title of your issue to view it.
+1. Select **Edit title and description** (**{pencil}**).
 1. Select **Delete issue**.
 
 ## Promote an issue to an epic **(PREMIUM)**
@@ -366,7 +378,9 @@ You can promote an issue to an [epic](../../group/epics/index.md) in the immedia
 
 To promote an issue to an epic:
 
-1. In an issue, select **Issue actions** (**{ellipsis_v}**).
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your issue to view it.
+1. On the top right corner, select **Issue actions** (**{ellipsis_v}**).
 1. Select **Promote to epic**.
 
 Alternatively, you can use the `/promote` [quick action](../quick_actions.md#issues-merge-requests-and-epics).
@@ -387,7 +401,8 @@ You can use the `/promote_to_incident` [quick action](../quick_actions.md) to pr
 
 To add an issue to an [iteration](../../group/iterations/index.md):
 
-1. Go to the issue.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your issue to view it.
 1. On the right sidebar, in the **Iteration** section, select **Edit**.
 1. From the dropdown list, select the iteration to associate this issue with.
 1. Select any area outside the dropdown list.
@@ -398,13 +413,13 @@ Alternatively, you can use the `/iteration` [quick action](../quick_actions.md#i
 
 To view all issues assigned to you:
 
-1. On the top bar, put your cursor in the **Search** box.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**).
 1. From the dropdown list, select **Issues assigned to me**.
 
 Or:
 
 - To use a [keyboard shortcut](../../shortcuts.md), press <kbd>Shift</kbd> + <kbd>i</kbd>.
-- On the top bar, in the upper-right corner, select **Issues** (**{issues}**).
+- On the left sidebar, at the top, select **Issues** (**{issues}**).
 
 ## Filter the list of issues
 
@@ -417,6 +432,8 @@ Or:
 
 To filter the list of issues:
 
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**.
 1. Above the list of issues, select **Search or filter results...**.
 1. In the dropdown list that appears, select the attribute you want to filter by.
 1. Select or type the operator to use for filtering the attribute. The following operators are
@@ -456,8 +473,8 @@ when you [filter the list of issues](#filter-the-list-of-issues) by:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/39908) in GitLab 12.1.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues > List**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**.
 1. In the **Search** box, type the issue ID. For example, enter filter `#10` to return only issue 10.
 
 ![filter issues by specific ID](img/issue_search_by_id_v15_0.png)
@@ -469,7 +486,8 @@ To refer to an issue elsewhere in GitLab, you can use its full URL or a short re
 
 To copy the issue reference to your clipboard:
 
-1. Go to the issue.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your issue to view it.
 1. On the right sidebar, next to **Reference**, select **Copy Reference** (**{copy-to-clipboard}**).
 
 You can now paste the reference into another description or comment.
@@ -492,7 +510,8 @@ For more information about creating comments by sending an email and the necessa
 
 To copy the issue's email address:
 
-1. Go to the issue.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your issue to view it.
 1. On the right sidebar, next to **Issue email**, select **Copy Reference** (**{copy-to-clipboard}**).
 
 ## Assignee
@@ -508,7 +527,8 @@ themselves or another project member assigns them.
 
 To change the assignee on an issue:
 
-1. Go to your issue.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your issue to view it.
 1. On the right sidebar, in the **Assignee** section, select **Edit**.
 1. From the dropdown list, select the user to add as an assignee.
 1. Select any area outside the dropdown list.
@@ -548,7 +568,8 @@ Prerequisites:
 
 To edit health status of an issue:
 
-1. Go to the issue.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your issue to view it.
 1. On the right sidebar, in the **Health status** section, select **Edit**.
 1. From the dropdown list, select the status to add to this issue:
 
@@ -556,7 +577,7 @@ To edit health status of an issue:
    - Needs attention (amber)
    - At risk (red)
 
-You can see the issue’s health status in:
+You can see the issue's health status in:
 
 - Issues list
 - Epic tree
diff --git a/doc/user/project/labels.md b/doc/user/project/labels.md
index 2af15e06b98..7f98b62cabf 100644
--- a/doc/user/project/labels.md
+++ b/doc/user/project/labels.md
@@ -69,8 +69,8 @@ You can also assign and unassign labels with [quick actions](quick_actions.md):
 
 To view the **project's labels**:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Labels**.
 
 Or:
 
@@ -86,8 +86,8 @@ project or group path where it was created.
 
 To view the **group's labels**:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Group information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Labels**.
 
 Or:
 
@@ -108,8 +108,8 @@ Prerequisites:
 
 To create a project label:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Labels**.
 1. Select **New label**.
 1. In the **Title** field, enter a short, descriptive name for the label. You
    can also use this field to create [scoped, mutually exclusive labels](#scoped-labels).
@@ -142,8 +142,8 @@ To do so:
 
 To create a group label:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Group information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Labels**.
 1. Select **New label**.
 1. In the **Title** field, enter a short, descriptive name for the label. You
    can also use this field to create [scoped, mutually exclusive labels](#scoped-labels).
@@ -182,16 +182,16 @@ Prerequisites:
 
 To edit a **project** label:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Labels**.
 1. Next to the label you want to edit, select **Edit** (**{pencil}**).
 
 ### Edit a group label
 
 To edit a **group** label:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Group information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Labels**.
 1. Next to the label you want to edit, select **Edit** (**{pencil}**).
 
 ## Delete a label
@@ -208,8 +208,8 @@ Prerequisites:
 
 To delete a **project** label:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Labels**.
 1. Either:
 
    - Next to the **Subscribe** button, select (**{ellipsis_v}**).
@@ -221,8 +221,8 @@ To delete a **project** label:
 
 To delete a **group** label:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Group information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Manage > Labels**.
 1. Either:
 
    - Next to the **Subscribe** button, select (**{ellipsis_v}**).
@@ -251,8 +251,8 @@ Prerequisites:
 
 To promote a project label to a group label:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Labels**.
 1. Next to the **Subscribe** button, select the three dots (**{ellipsis_v}**) and
    select **Promote to group label**.
 
@@ -302,8 +302,8 @@ Prerequisites:
 
 To add the default labels to the project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Labels**.
 1. Select **Generate a default set of labels**.
 
 The following labels are created:
@@ -441,8 +441,8 @@ Prerequisites:
 
 To prioritize a label:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Labels**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Labels**.
 1. Next to a label you want to prioritize, select the star (**{star-o}**).
 
 ![Labels prioritized](img/labels_prioritized_v13_5.png)
diff --git a/doc/user/project/members/index.md b/doc/user/project/members/index.md
index 8b2cacf084e..7a1d9d6e6e3 100644
--- a/doc/user/project/members/index.md
+++ b/doc/user/project/members/index.md
@@ -118,8 +118,8 @@ Prerequisite:
 
 To add a user to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Members**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Members**.
 1. Select **Invite members**.
 1. If the user:
 
@@ -176,8 +176,8 @@ Prerequisites:
 
 To add a group to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Members**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Members**.
 1. Select **Invite a group**.
 1. Select a group.
 1. Select the highest [role](../../permissions.md) for users in the group.
@@ -207,8 +207,8 @@ If the importing member's role in the target project is:
 
 To import users:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Members**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Members**.
 1. Select **Import from a project**.
 1. Select the project. You can view only the projects for which you're a maintainer.
 1. Select **Import project members**.
@@ -232,8 +232,8 @@ Prerequisites:
 
 To remove a member from a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Members**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Members**.
 1. Next to the project member you want to remove, select **Remove member**.
 1. Optional. In the confirmation box, select the
    **Also unassign this user from related issues and merge requests** checkbox.
@@ -269,8 +269,8 @@ You can filter and sort members in a project.
 
 ### Display inherited members
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Members**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Members**.
 1. In the **Filter members** box, select `Membership` `=` `Inherited`.
 1. Press <kbd>Enter</kbd>.
 
@@ -278,8 +278,8 @@ You can filter and sort members in a project.
 
 ### Display direct members
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Members**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Members**.
 1. In the **Filter members** box, select `Membership` `=` `Direct`.
 1. Press <kbd>Enter</kbd>.
 
@@ -301,8 +301,8 @@ You can sort members by **Account**, **Access granted**, **Max role**, or **Last
 
 GitLab users can request to become a member of a project.
 
-1. On the top bar, select **Main menu > Projects** and find the project you want to be a member of.
-1. By the project name, select **Request Access**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find the project you want to be a member of.
+1. By the project's name, select **Request Access**.
 
 ![Request access button](img/request_access_button.png)
 
@@ -325,8 +325,8 @@ Prerequisite:
 
 - You must be the project owner.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. Under **Project visibility**, select **Users can request access**.
 1. Select **Save changes**.
diff --git a/doc/user/project/members/share_project_with_groups.md b/doc/user/project/members/share_project_with_groups.md
index 452363c3d9a..aadc27fb2d3 100644
--- a/doc/user/project/members/share_project_with_groups.md
+++ b/doc/user/project/members/share_project_with_groups.md
@@ -57,16 +57,21 @@ You can share a project with a group by inviting that group to the project.
 
 To invite a group to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Members**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Members**.
 1. Select **Invite a group**.
 1. **Select a group** you want to add to the project.
 1. **Select a role** you want to assign to the group.
 1. Optional. Select an **Access expiration date**.
 1. Select **Invite**.
 
-All group members, members of subgroups, and members of other projects the group has access to
-are given access to the project. In addition:
+The following members are given access to the project:
+
+- All direct group members.
+- Inherited group members.
+- Members of other groups that have access to the group being invited (by [group share](../../group/manage.md#share-a-group-with-another-group))
+
+In addition:
 
 - On the group's page, the project is listed on the **Shared projects** tab.
 - On the project's **Members** page, the group is listed on the **Groups** tab.
@@ -93,8 +98,8 @@ For example, if a group member has the role of Developer, and the group is invit
 
 To view the maximum role assigned to a member:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Project information > Members**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Members**.
 1. In the **Max role** column, view the user's maximum assigned role.
 
 ## View a group's shared projects
@@ -103,7 +108,7 @@ In a group, a shared project is a project to which the group members gained acce
 
 To view a group's shared projects:
 
-1. On the top bar, select **Main menu > Group** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. On the group page, select the **Shared projects** tab.
 
 A list of shared projects is displayed.
diff --git a/doc/user/project/merge_requests/approvals/img/approvals_premium_mr_widget_16_0.png b/doc/user/project/merge_requests/approvals/img/approvals_premium_mr_widget_16_0.png
new file mode 100644
index 00000000000..727dac0916b
--- /dev/null
+++ b/doc/user/project/merge_requests/approvals/img/approvals_premium_mr_widget_16_0.png
diff --git a/doc/user/project/merge_requests/approvals/img/approvals_premium_mr_widget_v13_3.png b/doc/user/project/merge_requests/approvals/img/approvals_premium_mr_widget_v13_3.png
deleted file mode 100644
index 306bf57354d..00000000000
--- a/doc/user/project/merge_requests/approvals/img/approvals_premium_mr_widget_v13_3.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/approvals/index.md b/doc/user/project/merge_requests/approvals/index.md
index 717358df9f3..68d5665139a 100644
--- a/doc/user/project/merge_requests/approvals/index.md
+++ b/doc/user/project/merge_requests/approvals/index.md
@@ -67,7 +67,7 @@ if a user approves a merge request and is shown in the reviewer list, a green ch
 
 After a merge request receives the [number and type of approvals](rules.md) you configure, it can merge
 unless it's blocked for another reason. Merge requests can be blocked by other problems,
-such as merge conflicts, [unresolved threads](../../../discussions/index.md#prevent-merge-unless-all-threads-are-resolved),
+such as merge conflicts, [unresolved threads](../index.md#prevent-merge-unless-all-threads-are-resolved),
 or a [failed CI/CD pipeline](../merge_when_pipeline_succeeds.md).
 
 To prevent merge request authors from approving their own merge requests,
@@ -109,11 +109,11 @@ Without the approvals, the work cannot merge. Required approvals enable multiple
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/334698) in GitLab 15.1.
 > - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/389905) in GitLab 15.11 [with a flag](../../../../administration/feature_flags.md) named `invalid_scan_result_policy_prevents_merge`. Disabled by default.
+> - [Enabled by default on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/405023) in GitLab 16.1.
 
 FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance,
-ask an administrator to [enable the feature flag](../../../../administration/feature_flags.md) named `invalid_scan_result_policy_prevents_merge`.
-On GitLab.com, this feature is available but can be configured by GitLab.com administrators only.
+On self-managed GitLab, by default this feature is available. To hide the feature,
+ask an administrator to [disable the feature flag](../../../../administration/feature_flags.md) named `invalid_scan_result_policy_prevents_merge`.
 
 Whenever an approval rule cannot be satisfied, the rule is displayed as **(!) Auto approved**. This applies to the following conditions:
 
diff --git a/doc/user/project/merge_requests/approvals/rules.md b/doc/user/project/merge_requests/approvals/rules.md
index d55ca5dff04..bc5d4353ffc 100644
--- a/doc/user/project/merge_requests/approvals/rules.md
+++ b/doc/user/project/merge_requests/approvals/rules.md
@@ -104,7 +104,7 @@ supports multiple default rules:
 When an [eligible approver](#eligible-approvers) approves a merge request, it
 reduces the number of approvals left (the **Approvals** column) for all rules that the approver belongs to:
 
-![Approvals premium merge request widget](img/approvals_premium_mr_widget_v13_3.png)
+![Approvals premium merge request widget](img/approvals_premium_mr_widget_16_0.png)
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 For an overview, see [Multiple Approvers](https://www.youtube.com/watch?v=8JQJ5821FrA).
@@ -186,8 +186,8 @@ oversight on proposed work. To enable approval permissions for these users witho
 granting them push access:
 
 1. [Create a protected branch](../../protected_branches.md)
-1. [Create a new group](../../../group/manage.md#create-a-group).
-1. [Add the user to the group](../../../group/manage.md#add-users-to-a-group),
+1. [Create a new group](../../../group/index.md#create-a-group).
+1. [Add the user to the group](../../../group/index.md#add-users-to-a-group),
    and select the Reporter role for the user.
 1. [Share the project with your group](../../members/share_project_with_groups.md#share-a-project-with-a-group),
    based on the Reporter role.
@@ -195,7 +195,7 @@ granting them push access:
 1. In the **Merge request approvals** section, scroll to **Approval rules**, and either:
    - For a new rule, select **Add approval rule** and target the protected branch.
    - For an existing rule, select **Edit** and target the protected branch.
-1. [Add the group](../../../group/manage.md#create-a-group) to the permission list.
+1. [Add the group](../../../group/index.md#create-a-group) to the permission list.
 
    ![Update approval rule](img/update_approval_rule_v13_10.png)
 
@@ -217,6 +217,14 @@ on a merge request, you can either add or remove approvers:
 Administrators can change the [merge request approvals settings](settings.md#prevent-editing-approval-rules-in-merge-requests)
 to prevent users from overriding approval rules for merge requests.
 
+## Require multiple approvals for a rule
+
+To create an approval rule which requires more than one approval:
+
+- When you [create or edit a rule](#edit-an-approval-rule), set **Approvals required** to `2` or more.
+- Use the [Merge requests approvals API](../../../../api/merge_request_approvals.md#update-merge-request-level-rule)
+  to set the `approvals_required` attribute to `2` or more.
+
 ## Configure optional approval rules
 
 Merge request approvals can be optional for projects where approvals are
diff --git a/doc/user/project/merge_requests/changes.md b/doc/user/project/merge_requests/changes.md
index 8f6b1a32424..94f506ba556 100644
--- a/doc/user/project/merge_requests/changes.md
+++ b/doc/user/project/merge_requests/changes.md
@@ -27,23 +27,17 @@ To view the diff of changes included in a merge request:
    1. Select the file you want to view.
    1. To hide the file browser, select **Show file browser** again.
 
-In [GitLab 13.4](https://gitlab.com/gitlab-org/gitlab/-/issues/232820) and later, files
-with many changes are collapsed to improve performance. GitLab displays the message:
+Files with many changes are collapsed to improve performance. GitLab displays the message:
 **Some changes are not shown**. To view the changes for that file, select **Expand file**.
 
 ## Show one file at a time
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/222790) in GitLab 13.2.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/229848) in GitLab 13.7.
-
 For larger merge requests, you can review one file at a time. You can change this setting
 [temporarily in a merge request](#in-a-merge-request-show-only-one-file-at-a-time), or
 so it [applies to all merge requests](#in-all-merge-requests-show-only-one-file-at-a-time).
 
 ### In a merge request, show only one file at a time
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/233898) in GitLab 13.7.
-
 To temporarily change your viewing preferences for a specific merge request:
 
 1. Go to your merge request, and below the merge request title, select **Changes**.
@@ -149,3 +143,31 @@ When there are conflicts between the source and target branch, we show an alert
 per conflicted file on the merge request diff:
 
 ![Example of a conflict alert shown in a merge request diff](img/conflict_ui_v15_6.png)
+
+## Add a comment to a merge request file
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121429) in GitLab 16.1 [with a flag](../../../administration/feature_flags.md) named `comment_on_files`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `comment_on_files`.
+On GitLab.com, this feature is not available.
+
+You can add comments to a merge request diff file. These comments persist across
+rebases and file changes.
+
+To add a comment to a merge request file:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and find your merge request.
+1. Select **Changes**.
+1. In the header for the file you want to comment on, select **Comment** (**{comment}**).
+
+## Add a comment to an image
+
+In merge requests and commit detail views, you can add a comment to an image.
+This comment can also be a thread.
+
+1. Hover your mouse over the image.
+1. Select the location where you want to comment.
+
+An icon is displayed on the image and a comment field is displayed.
diff --git a/doc/user/project/merge_requests/cherry_pick_changes.md b/doc/user/project/merge_requests/cherry_pick_changes.md
index 004d24778b7..6669b2883a4 100644
--- a/doc/user/project/merge_requests/cherry_pick_changes.md
+++ b/doc/user/project/merge_requests/cherry_pick_changes.md
@@ -52,8 +52,8 @@ Commit `G` is added after the cherry-pick.
 After a merge request is merged, you can cherry-pick all changes introduced
 by the merge request:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests**, and find your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**, and find your merge request.
 1. Scroll to the merge request reports section, and find the **Merged by** report.
 1. In the upper-right corner, select **Cherry-pick**:
 
@@ -70,8 +70,8 @@ You can cherry-pick a single commit from multiple locations in your GitLab proje
 
 To cherry-pick a commit from the list of all commits for a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Commits**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Commits**.
 1. Select the [title](https://git-scm.com/docs/git-commit#_discussion) of the commit you want to cherry-pick.
 1. In the upper-right corner, select **Options > Cherry-pick** to show the cherry-pick modal.
 1. In the modal window, select the project and branch to cherry-pick into.
@@ -84,8 +84,8 @@ You can cherry-pick commits from any merge request in your project, regardless o
 whether the merge request is open or closed. To cherry-pick a commit from the
 list of commits included in a merge request:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests**, and find your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**, and find your merge request.
 1. In the merge request's secondary menu, select **Commits** to display the commit details page.
 1. Select the [title](https://git-scm.com/docs/git-commit#_discussion) of the commit you want to cherry-pick.
 1. In the upper-right corner, select **Options > Cherry-pick** to show the cherry-pick modal.
@@ -98,8 +98,8 @@ list of commits included in a merge request:
 You can cherry-pick from the list of previous commits affecting an individual file
 when you view that file in your project's Git repository:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Files** and go to the file
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Repository** and go to the file
    changed by the commit.
 1. Select **History**, then select the [title](https://git-scm.com/docs/git-commit#_discussion)
    of the commit you want to cherry-pick.
diff --git a/doc/user/project/merge_requests/commit_templates.md b/doc/user/project/merge_requests/commit_templates.md
index f8c24e4067b..c930c5c6f7f 100644
--- a/doc/user/project/merge_requests/commit_templates.md
+++ b/doc/user/project/merge_requests/commit_templates.md
@@ -29,8 +29,8 @@ Prerequisite:
 
 To do this:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. Depending on the type of template you want to create, scroll to either
    [**Merge commit message template**](#default-template-for-merge-commits) or
    [**Squash commit message template**](#default-template-for-squash-commits).
@@ -71,6 +71,7 @@ GitLab creates a squash commit message with this template:
 > - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/20421) `co_authored_by` variable in GitLab 14.7.
 > - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/26303) `all_commits` variable in GitLab 14.9.
 > - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/378352) `reviewed_by` variable in GitLab 15.7.
+> - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/199823) `local_reference` variable in GitLab 16.1.
 
 Commit message templates support these variables:
 
@@ -82,6 +83,7 @@ Commit message templates support these variables:
 | `%{issues}`        | String with phrase `Closes <issue numbers>`. Contains all issues mentioned in the merge request description that match [issue closing patterns](../issues/managing_issues.md#closing-issues-automatically). Empty if no issues are mentioned. | `Closes #465, #190 and #400` |
 | `%{description}`   | Description of the merge request. | `Merge request description.`<br>`Can be multiline.` |
 | `%{reference}`     | Reference to the merge request. | `group-name/project-name!72359` |
+| `%{local_reference}` | Local reference to the merge request. | `!72359` |
 | `%{first_commit}`  | Full message of the first commit in merge request diff. | `Update README.md` |
 | `%{first_multiline_commit}` | Full message of the first commit that's not a merge commit and has more than one line in message body. Merge request title if all commits aren't multiline. | `Update README.md`<br><br>`Improved project description in readme file.` |
 | `%{url}`           | Full URL to the merge request. | `https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1` |
diff --git a/doc/user/project/merge_requests/commits.md b/doc/user/project/merge_requests/commits.md
index cc6ecd8398f..a36e45d159a 100644
--- a/doc/user/project/merge_requests/commits.md
+++ b/doc/user/project/merge_requests/commits.md
@@ -14,46 +14,72 @@ These commits are displayed on the merge request's **Commits** tab.
 From this tab, you can review commit messages and copy a commit's SHA when you need to
 [cherry-pick changes](cherry_pick_changes.md).
 
-## Navigate merge request commits
+## View commits in a merge request
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18140) in GitLab 13.0.
+To see the commits included in a merge request:
 
-To navigate commits in a merge request:
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**, then select your merge request.
+1. To show a list of the commits in the merge request, newest first, select **Commits** .
+   To read more about the commit, select **Toggle commit description** (**{ellipsis_h}**)
+   on any commit.
+1. To view the changes in the commit, select the title of the commit link.
+1. To view other commits in the merge request, either:
 
-1. Select the **Commits** tab.
-1. Select the commit link. The most recent commit is displayed.
-1. Navigate through the commits by either:
+   - Select **Prev** or **Next**.
+   - Use keyboard shortcuts: <kbd>X</kbd> (previous commit) and <kbd>C</kbd> (next commit).
 
-   - Selecting **Prev** and **Next** buttons below the tab buttons.
-   - Using the <kbd>X</kbd> and <kbd>C</kbd> keyboard shortcuts.
+If your merge request builds upon a previous merge request, you might
+need to [include more commits for context](#show-commits-from-previous-merge-requests).
 
-![Merge requests commit navigation](img/commit_nav_v16_0.png)
+### Show commits from previous merge requests
 
-## View merge request commits in context
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29274) in GitLab 13.12 [with a flag](../../../administration/feature_flags.md) named `context_commits`. Enabled by default.
 > - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/320757) in GitLab 14.8.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/320757) in GitLab 14.9. [Feature flag `context_commits`](https://gitlab.com/gitlab-org/gitlab/-/issues/320757) removed.
 
-When reviewing a merge request, it helps to have more context about the changes
-made. That includes unchanged lines in unchanged files, and previous commits
-that have already merged that the change is built on.
+When you review a merge request, you might need information from previous commits
+to help understand the commits you're reviewing. You might need more context
+if another merge request:
+
+- Changed files your current merge request doesn't modify, so those files aren't shown
+  in your current merge request's diff.
+- Changed files that you're modifying in your current merge request, and you need
+  to see the progression of work.
 
 To add previously merged commits to a merge request for more context:
 
-1. Go to your merge request.
-1. Select the **Commits** tab.
-1. Scroll to the end of the list of commits, and select **Add previously merged commits**:
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**, then select your merge request.
+1. Select **Commits**.
+1. Scroll to the end of the list of commits, and select **Add previously merged commits**.
 1. Select the commits that you want to add.
 1. Select **Save changes**.
 
+## Add a comment to a commit
+
+WARNING:
+Threads created this way are lost if the commit ID changes after a
+force push.
+
+To add discussion to a specific commit:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Commits**.
+1. Below the commits, in the **Comment** field, enter a comment.
+1. Save your comment as either a standalone comment, or a thread:
+   - To add a comment, select **Comment**.
+   - To start a thread, select the down arrow (**{chevron-down}**), then select **Start thread**.
+
 ## View diffs between commits
 
 To view the changes between previously merged commits:
 
-1. On your merge request, select the **Changes** tab.
-1. By **Compare**, select the commit you want to view:
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**, then select your merge request.
+1. Select **Changes**.
+1. By **Compare** (**{file-tree}**), select the commits to compare:
 
    ![Previously merged commits](img/previously_merged_commits_v16_0.png)
 
-If you selected to add previously merged commits, they are displayed in the list.
+If you selected to add previously merged commits for context, those commits are
+also shown in the list.
diff --git a/doc/user/project/merge_requests/conflicts.md b/doc/user/project/merge_requests/conflicts.md
index cc8f8cb2fe6..44cef4d63e5 100644
--- a/doc/user/project/merge_requests/conflicts.md
+++ b/doc/user/project/merge_requests/conflicts.md
@@ -59,8 +59,8 @@ in the user interface, and you can also resolve conflicts locally through the co
 
 To resolve less-complex conflicts from the GitLab user interface:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and find the merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and find the merge request.
 1. Select **Overview**, and scroll to the merge request reports section.
 1. Find the merge conflicts message, and select **Resolve conflicts**.
    GitLab shows a list of files with merge conflicts. The conflicts are
@@ -84,8 +84,8 @@ Some merge conflicts are more complex, requiring you to manually modify lines to
 resolve their conflicts. Use the merge conflict resolution editor to resolve complex
 conflicts in the GitLab interface:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and find the merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and find the merge request.
 1. Select **Overview**, and scroll to the merge request reports section.
 1. Find the merge conflicts message, and select **Resolve conflicts**.
    GitLab shows a list of files with merge conflicts.
diff --git a/doc/user/project/merge_requests/creating_merge_requests.md b/doc/user/project/merge_requests/creating_merge_requests.md
index a91d324016a..4eb4476422f 100644
--- a/doc/user/project/merge_requests/creating_merge_requests.md
+++ b/doc/user/project/merge_requests/creating_merge_requests.md
@@ -19,8 +19,8 @@ to streamline merge request creation.
 
 You can create a merge request from the list of merge requests.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left menu, select **Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**.
 1. In the upper-right corner, select **New merge request**.
 1. Select a source and target branch and then **Compare branches and continue**.
 1. Fill out the fields and select **Create merge request**.
@@ -95,8 +95,8 @@ You can create a merge request when you add, edit, or upload a file to a reposit
 
 You can create a merge request when you create a branch.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left menu, select **Repository > Branches**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Branches**.
 1. Type a branch name and select **New branch**.
 1. Above the file list, on the right side, select **Create merge request**.
    A merge request is created. The default branch is the target.
@@ -142,9 +142,9 @@ to reduce the need for editing merge requests manually through the UI.
 
 You can create a merge request from your fork to contribute back to the main project.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Select your fork of the repository.
-1. On the left menu, go to **Merge requests**, and select **New merge request**.
+1. On the left sidebar, select **Code > Merge requests**, and select **New merge request**.
 1. In the **Source branch** dropdown list box, select the branch in your forked repository as the source branch.
 1. In the **Target branch** dropdown list box, select the branch from the upstream repository as the target branch.
    You can set a [default target project](#set-the-default-target-project) to
@@ -171,8 +171,8 @@ Prerequisites:
 
 To create a merge request by sending an email:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left menu, select **Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**.
 1. In the upper-right corner, select **Email a new merge request to this project**.
    An email address is displayed. Copy this address.
    Ensure you keep this address private.
@@ -216,8 +216,8 @@ scenarios when you create a new merge request:
 To have merge requests from a fork by default target your own fork
 (instead of the upstream project), you can change the default.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left menu, select **Settings > General > Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. In the **Target project** section, select the option you want to use for
    your default target project.
 1. Select **Save changes**.
diff --git a/doc/user/project/merge_requests/csv_export.md b/doc/user/project/merge_requests/csv_export.md
index f40b82a6280..f8988ae7bd7 100644
--- a/doc/user/project/merge_requests/csv_export.md
+++ b/doc/user/project/merge_requests/csv_export.md
@@ -12,8 +12,8 @@ Export all the data collected from a project's merge requests into a comma-separ
 
 To export merge requests to a CSV file:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** .
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**.
 1. Add any searches or filters. This can help you keep the size of the CSV file under the 15 MB limit. The limit ensures
    the file can be emailed to a variety of email providers.
 1. Select **Actions** (**{ellipsis_v}**) **> Export as CSV**.
diff --git a/doc/user/project/merge_requests/dependencies.md b/doc/user/project/merge_requests/dependencies.md
index 3d92fc9a91e..1cd81e2aac2 100644
--- a/doc/user/project/merge_requests/dependencies.md
+++ b/doc/user/project/merge_requests/dependencies.md
@@ -57,8 +57,8 @@ information about the dependency:
 
 To view dependency information on a merge request:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and identify your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and identify your merge request.
 1. Scroll to the merge request reports area. Dependent merge requests display information
    about the total number of dependencies set, such as
    **(status-warning)** **Depends on 1 merge request being merged**.
@@ -105,8 +105,8 @@ Prerequisite:
 
 To do this:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and identify your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and identify your merge request.
 1. Select **Edit**.
 1. In **Merge request dependencies**, paste either the reference or the full URL
    to the merge requests that should merge before this work merges. References
@@ -120,8 +120,8 @@ Prerequisite:
 
 - You must have a role in the project that allows you to edit merge requests.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and identify your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and identify your merge request.
 1. Select **Edit**.
 1. Scroll to **Merge request dependencies** and select **Remove** next to the reference
    for each dependency you want to remove.
diff --git a/doc/user/project/merge_requests/drafts.md b/doc/user/project/merge_requests/drafts.md
index 88e5e4a6283..6f309d2db24 100644
--- a/doc/user/project/merge_requests/drafts.md
+++ b/doc/user/project/merge_requests/drafts.md
@@ -12,7 +12,7 @@ or open threads, you can prevent it from being accepted before you
 [mark it as ready](#mark-merge-requests-as-ready). Flag it as a draft to disable
 the **Merge** button until you remove the **Draft** flag:
 
-![Blocked Merge Button](img/draft_blocked_merge_button_v13_10.png)
+![Blocked Merge Button](img/merge_request_draft_blocked_v16_0.png)
 
 ## Mark merge requests as drafts
 
@@ -42,10 +42,7 @@ When a merge request is ready to be merged, you can remove the `Draft` flag in s
 
 - **Viewing a merge request**: In the upper-right corner of the merge request, select **Mark as ready**.
   Users with at least the Developer role
-  can also scroll to the bottom of the merge request description and select **Mark as ready**:
-
-  ![Mark as ready](img/draft_blocked_merge_button_v13_10.png)
-
+  can also scroll to the bottom of the merge request description and select **Mark as ready**.
 - **Editing an existing merge request**: Remove `[Draft]`, `Draft:` or `(Draft)`
   from the beginning of the title, or clear **Mark as draft**
   below the **Title** field.
@@ -71,7 +68,7 @@ draft merge requests:
 1. Select **Yes** to include drafts, or **No** to exclude, and press **Return**
    to update the list of merge requests:
 
-   ![Filter draft merge requests](img/filter_draft_merge_requests_v13_10.png)
+   ![Filter draft merge requests](img/filter_draft_merge_requests_v16_0.png)
 
 ## Pipelines for drafts
 
diff --git a/doc/user/project/merge_requests/img/auto_merge_ready_v16_0.png b/doc/user/project/merge_requests/img/auto_merge_ready_v16_0.png
new file mode 100644
index 00000000000..e68057e73a0
--- /dev/null
+++ b/doc/user/project/merge_requests/img/auto_merge_ready_v16_0.png
diff --git a/doc/user/project/merge_requests/img/commit_nav_v16_0.png b/doc/user/project/merge_requests/img/commit_nav_v16_0.png
deleted file mode 100644
index 6005e516fff..00000000000
--- a/doc/user/project/merge_requests/img/commit_nav_v16_0.png
+++ /dev/null
diff --git a/doc/user/discussions/img/create_new_issue_v15_4.png b/doc/user/project/merge_requests/img/create_new_issue_v15_4.png
index 3720b601cc5..3720b601cc5 100644
--- a/doc/user/discussions/img/create_new_issue_v15_4.png
+++ b/doc/user/project/merge_requests/img/create_new_issue_v15_4.png
diff --git a/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_10.png b/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_10.png
deleted file mode 100644
index 3bac9f7fee8..00000000000
--- a/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_10.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/filter_draft_merge_requests_v13_10.png b/doc/user/project/merge_requests/img/filter_draft_merge_requests_v13_10.png
deleted file mode 100644
index 4458df987d6..00000000000
--- a/doc/user/project/merge_requests/img/filter_draft_merge_requests_v13_10.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/filter_draft_merge_requests_v16_0.png b/doc/user/project/merge_requests/img/filter_draft_merge_requests_v16_0.png
new file mode 100644
index 00000000000..f4356aade16
--- /dev/null
+++ b/doc/user/project/merge_requests/img/filter_draft_merge_requests_v16_0.png
diff --git a/doc/user/project/merge_requests/img/filtering_merge_requests_by_date_v14_6.png b/doc/user/project/merge_requests/img/filtering_merge_requests_by_date_v14_6.png
deleted file mode 100644
index 398820f7864..00000000000
--- a/doc/user/project/merge_requests/img/filtering_merge_requests_by_date_v14_6.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/filtering_merge_requests_by_environment_v14_6.png b/doc/user/project/merge_requests/img/filtering_merge_requests_by_environment_v14_6.png
deleted file mode 100644
index c35f2c8a58b..00000000000
--- a/doc/user/project/merge_requests/img/filtering_merge_requests_by_environment_v14_6.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/merge_request_assignees_v16_0.png b/doc/user/project/merge_requests/img/merge_request_assignees_v16_0.png
new file mode 100644
index 00000000000..114ddf612e0
--- /dev/null
+++ b/doc/user/project/merge_requests/img/merge_request_assignees_v16_0.png
diff --git a/doc/user/project/merge_requests/img/merge_request_draft_blocked_v16_0.png b/doc/user/project/merge_requests/img/merge_request_draft_blocked_v16_0.png
new file mode 100644
index 00000000000..88fe1ec34c0
--- /dev/null
+++ b/doc/user/project/merge_requests/img/merge_request_draft_blocked_v16_0.png
diff --git a/doc/user/project/merge_requests/img/merge_request_pipeline.png b/doc/user/project/merge_requests/img/merge_request_pipeline.png
deleted file mode 100644
index ce1d6bab536..00000000000
--- a/doc/user/project/merge_requests/img/merge_request_pipeline.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/multiple_assignees_for_merge_requests_sidebar.png b/doc/user/project/merge_requests/img/multiple_assignees_for_merge_requests_sidebar.png
deleted file mode 100644
index dde2680ed74..00000000000
--- a/doc/user/project/merge_requests/img/multiple_assignees_for_merge_requests_sidebar.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/mwps_v15_4.png b/doc/user/project/merge_requests/img/mwps_v15_4.png
deleted file mode 100644
index f042912d470..00000000000
--- a/doc/user/project/merge_requests/img/mwps_v15_4.png
+++ /dev/null
diff --git a/doc/user/discussions/img/new-issue-one-thread_v14_3.png b/doc/user/project/merge_requests/img/new-issue-one-thread_v14_3.png
index 34d3a3be0a7..34d3a3be0a7 100644
--- a/doc/user/discussions/img/new-issue-one-thread_v14_3.png
+++ b/doc/user/project/merge_requests/img/new-issue-one-thread_v14_3.png
diff --git a/doc/user/project/merge_requests/img/post_merge_pipeline_v16_0.png b/doc/user/project/merge_requests/img/post_merge_pipeline_v16_0.png
new file mode 100644
index 00000000000..b14ce645850
--- /dev/null
+++ b/doc/user/project/merge_requests/img/post_merge_pipeline_v16_0.png
diff --git a/doc/user/discussions/img/unresolved_threads_v15_4.png b/doc/user/project/merge_requests/img/unresolved_threads_v15_4.png
index 1d1669de0f1..1d1669de0f1 100644
--- a/doc/user/discussions/img/unresolved_threads_v15_4.png
+++ b/doc/user/project/merge_requests/img/unresolved_threads_v15_4.png
diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md
index a65c5518658..38125f623eb 100644
--- a/doc/user/project/merge_requests/index.md
+++ b/doc/user/project/merge_requests/index.md
@@ -50,8 +50,8 @@ You can view merge requests for your project, group, or yourself.
 
 To view all merge requests for a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**.
 
 Or, to use a [keyboard shortcut](../../shortcuts.md), press <kbd>g</kbd> + <kbd>m</kbd>.
 
@@ -59,8 +59,8 @@ Or, to use a [keyboard shortcut](../../shortcuts.md), press <kbd>g</kbd> + <kbd>
 
 To view merge requests for all projects in a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Code > Merge requests**.
 
 If your group contains subgroups, this view also displays merge requests from the subgroup projects.
 
@@ -68,21 +68,17 @@ If your group contains subgroups, this view also displays merge requests from th
 
 To view all merge requests assigned to you:
 
-<!-- vale gitlab.FirstPerson = NO -->
-
-1. On the top bar, put your cursor in the **Search** box.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**).
 1. From the dropdown list, select **Merge requests assigned to me**.
 
-<!-- vale gitlab.FirstPerson = YES -->
-
 or:
 
 - To use a [keyboard shortcut](../../shortcuts.md), press <kbd>Shift</kbd> + <kbd>m</kbd>.
 
 or:
 
-1. On the top bar, in the upper-right corner, select **Merge requests** (**{merge-request-open}**).
-1. From the dropdown list, select **Assigned to you**.
+1. On the left sidebar, at the top, select **Merge requests** (**{merge-request}**).
+1. From the dropdown list, select **Assigned**.
 
 ## Filter the list of merge requests
 
@@ -93,6 +89,8 @@ or:
 
 To filter the list of merge requests:
 
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**.
 1. Above the list of merge requests, select **Search or filter results...**.
 1. From the dropdown list, select the attribute you wish to filter by. Some examples:
    - [**By environment or deployment date**](#by-environment-or-deployment-date).
@@ -132,17 +130,15 @@ Projects using a [fast-forward merge method](methods/index.md#fast-forward-merge
 do not return results, as this method does not create a merge commit.
 
 When filtering by an environment, a dropdown list presents all environments that
-you can choose from:
+you can choose from.
 
-![Filter MRs by their environment](img/filtering_merge_requests_by_environment_v14_6.png)
+When filtering by `Deployed-before` or `Deployed-after`:
 
-When filtering by `Deployed-before` or `Deployed-after`, the date refers to when
-the deployment to an environment (triggered by the merge commit) completed successfully.
-You must enter the deploy date manually. Deploy dates
-use the format `YYYY-MM-DD`, and must be quoted if you wish to specify
-both a date and time (`"YYYY-MM-DD HH:MM"`):
-
-![Filter MRs by a deploy date](img/filtering_merge_requests_by_date_v14_6.png)
+- The date refers to when the deployment to an environment (triggered by the
+  merge commit) completed successfully.
+- You must enter the deploy date manually.
+- Deploy dates use the format `YYYY-MM-DD`, and must be wrapped in double quotes (`"`)
+  if you want to specify both a date and time (`"YYYY-MM-DD HH:MM"`).
 
 ## Add changes to a merge request
 
@@ -167,8 +163,8 @@ To assign the merge request to a user, use the `/assign @user`
 [quick action](../quick_actions.md#issues-merge-requests-and-epics) in a text area in
 a merge request, or:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and find your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and find your merge request.
 1. On the right sidebar, expand the right sidebar and locate the **Assignees** section.
 1. Select **Edit**.
 1. Search for the user you want to assign, and select the user.
@@ -182,13 +178,13 @@ The merge request is added to the user's assigned merge request list.
 GitLab enables multiple assignees for merge requests, if multiple people are
 accountable for it:
 
-![multiple assignees for merge requests sidebar](img/multiple_assignees_for_merge_requests_sidebar.png)
+![multiple assignees for merge requests sidebar](img/merge_request_assignees_v16_0.png)
 
 To assign multiple assignees to a merge request, use the `/assign @user`
 [quick action](../quick_actions.md#issues-merge-requests-and-epics) in a text area, or:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and find your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and find your merge request.
 1. On the right sidebar, expand the right sidebar and locate the **Assignees** section.
 1. Select **Edit** and, from the dropdown list, select all users you want
    to assign the merge request to.
@@ -300,7 +296,7 @@ For a software developer working in a team:
 1. Your manager:
    1. Pushes a commit with their final review.
    1. [Approves the merge request](approvals/index.md).
-   1. Sets it to [merge when pipeline succeeds](merge_when_pipeline_succeeds.md).
+   1. Sets it to [auto-merge](merge_when_pipeline_succeeds.md) (formerly **Merge when pipeline succeeds**).
 1. Your changes get deployed to production with [manual jobs](../../../ci/jobs/job_control.md#create-a-job-that-must-be-run-manually) for GitLab CI/CD.
 1. Your implementations were successfully shipped to your customer.
 
@@ -316,18 +312,19 @@ For a web developer writing a webpage for your company's website:
 
 ## Filter activity in a merge request
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115383) in GitLab 15.11 [with a flag](../../../administration/feature_flags.md) named `mr_activity_filters`. Disabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115383) in GitLab 15.11 [with a flag](../../../administration/feature_flags.md) named `mr_activity_filters`. Disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/387070) in GitLab 16.0. Available to GitLab team members only.
 
 FLAG:
 On self-managed GitLab, by default this feature is not available.
 To make it available per user, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `mr_activity_filters` for individual or groups of users.
-On GitLab.com, this feature unavailable.
+On GitLab.com, this feature is enabled for GitLab team members only.
 
 To understand the history of a merge request, filter its activity feed to show you
 only the items that are relevant to you.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**.
 1. Select a merge request.
 1. Scroll to **Activity**.
 1. On the right side of the page, select **Activity filter** to show the filter options.
@@ -351,6 +348,78 @@ only the items that are relevant to you.
 Your selection persists across all merge requests. You can also change the
 sort order by clicking the sort button on the right.
 
+## Resolve a thread
+
+> Resolving comments individually was [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/28750) in GitLab 13.6.
+
+In a merge request, you can resolve a thread when you want to finish a conversation.
+
+Prerequisites:
+
+- You must have at least the Developer role
+  or be the author of the change being reviewed.
+- Resolvable threads can be added only to merge requests. It doesn't work
+  for comments in issues, commits, or snippets.
+
+To resolve a thread:
+
+1. Go to the thread.
+1. Do one of the following:
+   - In the upper-right corner of the original comment, select **Resolve thread** (**{check-circle}**).
+   - Below the last reply, in the **Reply** field, select **Resolve thread**.
+   - Below the last reply, in the **Reply** field, enter text, select the **Resolve thread** checkbox, and select **Add comment now**.
+
+At the top of the page, the number of unresolved threads is updated:
+
+![Count of unresolved threads](img/unresolved_threads_v15_4.png)
+
+### Move all unresolved threads in a merge request to an issue
+
+If you have multiple unresolved threads in a merge request, you can
+create an issue to resolve them separately. In the merge request, at the top of the page,
+select the ellipsis icon button (**{ellipsis_v}**) in the threads control and then select **Resolve all with new issue**:
+
+![Open new issue for all unresolved threads](img/create_new_issue_v15_4.png)
+
+All threads are marked as resolved, and a link is added from the merge request to
+the newly created issue.
+
+### Move one unresolved thread in a merge request to an issue
+
+If you have one specific unresolved thread in a merge request, you can
+create an issue to resolve it separately. In the merge request, under the last reply
+to the thread, next to **Resolve thread**, select **Create issue to resolve thread** (**{issue-new}**):
+
+![Create issue for thread](img/new-issue-one-thread_v14_3.png)
+
+The thread is marked as resolved, and a link is added from the merge request to
+the newly created issue.
+
+### Prevent merge unless all threads are resolved
+
+You can prevent merge requests from being merged until all threads are
+resolved. When this setting is enabled, the **Unresolved threads** counter in a merge request
+is shown in orange when at least one thread remains unresolved.
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
+1. In the **Merge checks** section, select the **All threads must be resolved** checkbox.
+1. Select **Save changes**.
+
+### Automatically resolve threads in a merge request when they become outdated
+
+You can set merge requests to automatically resolve threads when lines are modified
+with a new push.
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
+1. In the **Merge options** section, select
+   **Automatically resolve merge request diff threads when they become outdated**.
+1. Select **Save changes**.
+
+Threads are now resolved if a push makes a diff section outdated.
+Threads on lines that don't change and top-level resolvable threads are not resolved.
+
 ## Related topics
 
 - [Create a merge request](creating_merge_requests.md)
diff --git a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
index 7588af70bd4..66c3b1fda74 100644
--- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
+++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
@@ -9,29 +9,29 @@ type: reference, concepts
 
 > **Merge when pipeline succeeds** and **Add to merge train when pipeline succeeds** [renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/409530) to **Auto-merge** in GitLab 16.0 [with a flag](../../../administration/feature_flags.md) named `auto_merge_labels_mr_widget`. Enabled by default.
 
-NOTE:
-[In GitLab 16.0 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/359057), **Merge when pipeline succeeds** and **Add to merge train when pipeline succeeds** become **Set to auto-merge**.
-
 If you review a merge request and it's ready to merge, but the pipeline hasn't
-completed yet, you can set it to merge when the pipeline succeeds (MWPS). You don't
+completed yet, you can set it to auto-merge. You don't
 have to remember later to merge the work manually:
 
-![Enable MWPS on a merge request](img/mwps_v15_4.png)
+![Auto-merge is ready](img/auto_merge_ready_v16_0.png)
+
+NOTE:
+[In GitLab 16.0 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/359057), **Merge when pipeline succeeds** and **Add to merge train when pipeline succeeds** are renamed **Set to auto-merge**.
 
 If the pipeline succeeds, the merge request is merged. If the pipeline fails, the
 author can either retry any failed jobs, or push new commits to fix the failure:
 
 - If a retried job succeeds on the second try, the merge request is merged.
-- If new commits are added to the merge request, GitLab cancels the MWPS request
+- If new commits are added to the merge request, GitLab cancels the request
   to ensure the new changes are reviewed before merge.
 
-## Set a merge request to MWPS
+## Auto-merge a merge request
 
 Prerequisites:
 
 - You must have at least the Developer role in the project.
 - If the project is configured to require it, all threads in the
-  merge request [must be resolved](../../discussions/index.md#resolve-a-thread).
+  merge request [must be resolved](index.md#resolve-a-thread).
 - The merge request must have received all required approvals.
 
 To do this when pushing from the command line, use the `merge_request.merge_when_pipeline_succeeds`
@@ -39,20 +39,20 @@ To do this when pushing from the command line, use the `merge_request.merge_when
 
 To do this from the GitLab user interface:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**.
 1. Scroll to the merge request reports section.
 1. Optional. Select your desired merge options, such as **Delete source branch**,
    **Squash commits**, or **Edit commit message**.
-1. Select **Merge when pipeline succeeds**.
+1. Select **Auto-merge**.
 
-If a new comment is added to the merge request after you select **Merge when pipeline succeeds**,
+If a new comment is added to the merge request after you select **Auto-merge**,
 but before the pipeline completes, GitLab blocks the merge until you
 resolve all existing threads.
 
 ## Cancel an auto-merge
 
-If a merge request is set to MWPS, you can cancel it.
+If a merge request is set to auto-merge, you can cancel it.
 
 Prerequisites:
 
@@ -62,8 +62,8 @@ Prerequisites:
 
 To do this:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**.
 1. Scroll to the merge request reports section.
 1. Select **Cancel auto-merge**.
 
@@ -88,8 +88,8 @@ Prerequisites:
 
 To enable this setting:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. Scroll to **Merge checks**, and select **Pipelines must succeed**.
    This setting also prevents merge requests from being merged if there is no pipeline,
    which can [conflict with some rules](#merge-requests-dont-merge-when-successful-pipeline-is-required).
@@ -109,9 +109,8 @@ Prerequisite:
 
 To change this behavior:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. Under **Merge checks**:
    - Select **Pipelines must succeed**.
    - Select **Skipped pipelines are considered successful**.
diff --git a/doc/user/project/merge_requests/methods/index.md b/doc/user/project/merge_requests/methods/index.md
index 02bd4ed0502..7bb10303d7e 100644
--- a/doc/user/project/merge_requests/methods/index.md
+++ b/doc/user/project/merge_requests/methods/index.md
@@ -26,8 +26,8 @@ gitGraph
 
 ## Configure a project's merge method
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. Select your desired **Merge method** from these options:
    - Merge commit
    - Merge commit with semi-linear history
diff --git a/doc/user/project/merge_requests/revert_changes.md b/doc/user/project/merge_requests/revert_changes.md
index 77fd78ee0d0..c4288a7793c 100644
--- a/doc/user/project/merge_requests/revert_changes.md
+++ b/doc/user/project/merge_requests/revert_changes.md
@@ -30,8 +30,8 @@ Prerequisites:
 
 To do this:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and identify your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and identify your merge request.
 1. Scroll to the merge request reports area, and find the report showing when the
    merge request was merged.
 1. Select **Revert**.
@@ -55,13 +55,13 @@ Prerequisites:
 
 To do this:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. If you know the merge request that contains the commit:
-   1. On the left sidebar, select **Merge requests** and identify your merge request.
+   1. Select **Code > Merge requests**, then identify and select your merge request.
    1. Select **Commits**, then select the title of the commit you want to revert. This displays the commit in the **Changes** tab of your merge request.
    1. Select the commit hash you want to revert. GitLab displays the contents of the commit.
 1. If you don't know the merge request the commit originated from:
-   1. On the left sidebar, select **Repository > Commits**.
+   1. Select **Code > Commits**.
    1. Select the title of the commit to display full information about the commit.
 1. In the upper-right corner, select **Options**, then select **Revert**.
 1. In **Revert in branch**, select the branch to revert your changes into.
diff --git a/doc/user/project/merge_requests/reviews/index.md b/doc/user/project/merge_requests/reviews/index.md
index 0de38874304..86468af06a2 100644
--- a/doc/user/project/merge_requests/reviews/index.md
+++ b/doc/user/project/merge_requests/reviews/index.md
@@ -7,9 +7,6 @@ type: index, reference
 
 # Merge request reviews **(FREE)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216054) in GitLab 13.5.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/245190) in GitLab 13.9.
-
 [Merge requests](../index.md) are the primary method of making changes to files in a
 GitLab project. [Create and submit a merge request](../creating_merge_requests.md)
 to propose changes. Your team leaves [comments](../../../discussions/index.md) on
@@ -26,7 +23,7 @@ For an overview, see [Merge request review](https://www.youtube.com/watch?v=2May
 
 ## Suggested reviewers **(ULTIMATE SAAS)**
 
-> - [Introduced](https://gitlab.com/groups/gitlab-org/modelops/applied-ml/review-recommender/-/epics/3) in GitLab 15.4 as a [Beta](../../../../policy/alpha-beta-support.md#beta) feature [with a flag](../../../../administration/feature_flags.md) named `suggested_reviewers_control`. Disabled by default.
+> - [Introduced](https://gitlab.com/groups/gitlab-org/modelops/applied-ml/review-recommender/-/epics/3) in GitLab 15.4 as a [Beta](../../../../policy/experiment-beta-support.md#beta) feature [with a flag](../../../../administration/feature_flags.md) named `suggested_reviewers_control`. Disabled by default.
 > - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/368356) in GitLab 15.6.
 > - Beta designation [removed from the UI](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113058) in GitLab 15.10.
 
@@ -52,9 +49,6 @@ of a merge request with new commits.
 
 ## Review a merge request
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4213) in GitLab 11.4.
-> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/28154) from GitLab Premium to GitLab Free in 13.1.
-
 When you review a merge request, you can create comments that are visible only
 to you. When you're ready, you can publish them together in a single action.
 To start your review:
@@ -62,7 +56,7 @@ To start your review:
 1. Go to the merge request you want to review, and select the **Changes** tab.
    For more information about navigating the diffs displayed in this tab, see
    [Changes in merge requests](../changes.md).
-1. Select the **{comment}** **comment** icon in the gutter to expand the diff lines
+1. Select **Add a comment to this line** (**{comment}**) in the gutter to expand the diff lines
    and display a comment box. In GitLab version 13.2 and later, you can
    [select multiple lines](#comment-on-multiple-lines).
 1. In the text area, write your first comment, then select **Start a review** below your comment.
@@ -75,8 +69,7 @@ To start your review:
    are now visible, and any [quick actions](../../quick_actions.md) included in
    your comments are performed.
 
-[In GitLab 13.10 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/292936),
-if you [approve a merge request](../approvals/index.md#approve-a-merge-request) and
+If you [approve a merge request](../approvals/index.md#approve-a-merge-request) and
 are shown in the reviewer list, a green check mark **{check-circle-filled}**
 displays next to your name.
 
@@ -84,8 +77,8 @@ displays next to your name.
 
 To download the changes included in a merge request as a diff:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**.
 1. Select your merge request.
 1. In the upper-right corner, select **Code > Plain diff**.
 
@@ -107,8 +100,8 @@ curl "https://gitlab.com/gitlab-org/gitlab/-/merge_requests/000000.diff" | git a
 
 To download the changes included in a merge request as a patch file:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests**.
 1. Select your merge request.
 1. In the upper-right corner, select **Code > Patches**.
 
@@ -147,7 +140,7 @@ When you submit your review, GitLab:
 
 ### Resolve or unresolve thread with a comment
 
-Review comments can also resolve or unresolve [resolvable threads](../../../discussions/index.md#resolve-a-thread).
+Review comments can also resolve or unresolve [resolvable threads](../index.md#resolve-a-thread).
 To resolve or unresolve a thread when replying to a comment:
 
 1. In the comment text area, write your comment.
@@ -161,8 +154,6 @@ Pending comments display information about the action to be taken when the comme
 
 ### Add a new comment
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8225) in GitLab 13.10.
-
 If you have a review in progress, you can also add a comment from the **Overview** tab by selecting
  **Add to review**:
 
@@ -170,9 +161,6 @@ If you have a review in progress, you can also add a comment from the **Overview
 
 ### Approval Rule information for Reviewers **(PREMIUM)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/233736) in GitLab 13.8.
-> - [Feature flag `reviewer_approval_rules` removed](https://gitlab.com/gitlab-org/gitlab/-/issues/293742) in GitLab 13.9.
-
 When editing the **Reviewers** field in a new or existing merge request, GitLab
 displays the name of the matching [approval rule](../approvals/rules.md)
 below the name of each suggested reviewer. [Code Owners](../../codeowners/index.md) are displayed as `Codeowner` without group detail.
@@ -187,8 +175,6 @@ This example shows reviewers and approval rules in a merge request sidebar:
 
 ### Request a new review
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/293933) in GitLab 13.9.
-
 After a reviewer completes their [merge request reviews](../../../discussions/index.md),
 the author of the merge request can request a new review from the reviewer:
 
@@ -202,18 +188,14 @@ them a notification email.
 
 ## Comment on multiple lines
 
-> - [Introduced](https://gitlab.com/gitlab-org/ux-research/-/issues/870) in GitLab 13.2.
-> - [Added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49875) select-and-drag features in GitLab 13.8.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/299121) in GitLab 13.9.
-
 When commenting on a diff, you can select which lines of code your comment refers
 to by either:
 
 ![Comment on any diff file line](img/comment-on-any-diff-line_v13_10.png)
 
-- Dragging the **{comment}** **comment** icon in the gutter to highlight
+- Dragging **Add a comment to this line** (**{comment}**) in the gutter to highlight
   lines in the diff. GitLab expands the diff lines and displays a comment box.
-- After starting a comment by selecting the **{comment}** **comment** icon in the
+- After starting a comment by selecting **Add a comment to this line** (**{comment}**) in the
   gutter, select the first line number your comment refers to in the **Commenting on lines**
   select box. New comments default to single-line comments, unless you select
   a different starting line.
@@ -245,8 +227,6 @@ To update multiple project merge requests at the same time:
 
 ## Bulk edit merge requests at the group level **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12719) in GitLab 12.2.
-
 Users with at least the Developer role can manage merge requests.
 
 When bulk editing merge requests in a group, you can edit the following attributes:
@@ -315,8 +295,6 @@ the command line.
 
 ### Copy the branch name for local checkout
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/23767) in GitLab 13.4.
-
 The merge request sidebar contains the branch reference for the source branch
 used to contribute changes for this merge request.
 
@@ -418,9 +396,6 @@ All the above can be done with the [`git-mr`](https://gitlab.com/glensc/git-mr)
 
 ## Cached merge request count
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/299542) in GitLab 13.11.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/327319) in GitLab 14.0.
-
 In a group, the sidebar displays the total count of open merge requests. This value is cached if it's greater than
 than 1000. The cached value is rounded to thousands (or millions) and updated every 24 hours.
 
diff --git a/doc/user/project/merge_requests/reviews/suggestions.md b/doc/user/project/merge_requests/reviews/suggestions.md
index 9187c5fad44..24197c5c313 100644
--- a/doc/user/project/merge_requests/reviews/suggestions.md
+++ b/doc/user/project/merge_requests/reviews/suggestions.md
@@ -17,8 +17,8 @@ merge request, authored by the user who suggested the changes.
 
 ## Create suggestions
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and find your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and find your merge request.
 1. On the secondary menu, select **Changes**.
 1. Find the lines of code you want to change.
    - To select a single line:
@@ -80,8 +80,8 @@ Prerequisites:
 
 To apply suggested changes directly from the merge request:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and find your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and find your merge request.
 1. Find the comment containing the suggestion you want to apply.
    - To apply suggestions individually, select **Apply suggestion**.
    - To apply multiple suggestions in a single commit, select **Add suggestion to batch**.
@@ -128,8 +128,8 @@ Merge requests created from forks use the template defined in the target project
 To meet your project's needs, you can customize these messages and include other
 placeholder variables:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. Scroll to **Merge suggestions**, and alter the text to meet your needs.
    See [Supported variables](#supported-variables) for a list of placeholders
    you can use in this message.
@@ -155,7 +155,7 @@ For example, to customize the commit message to output
 
 ## Batch suggestions
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25486) in GitLab 13.1 as an [Experiment](../../../../policy/alpha-beta-support.md#experiment) with a flag named `batch_suggestions`, disabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25486) in GitLab 13.1 as an [Experiment](../../../../policy/experiment-beta-support.md#experiment) with a flag named `batch_suggestions`, disabled by default.
 > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/227799) in GitLab 13.2.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/320755) in GitLab 13.11. [Feature flag `batch_suggestions`](https://gitlab.com/gitlab-org/gitlab/-/issues/320755) removed.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/326168) custom commit messages for batch suggestions in GitLab 14.4.
@@ -163,8 +163,8 @@ For example, to customize the commit message to output
 To reduce the number of commits added to your branch, you can apply multiple
 suggestions in a single commit.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and find your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and find your merge request.
 1. For each suggestion you want to apply, and select **Add suggestion to batch**.
 1. Optional. To remove a suggestion, select **Remove from batch**.
 1. After you add your desired suggestions, select **Apply suggestions**.
diff --git a/doc/user/project/merge_requests/squash_and_merge.md b/doc/user/project/merge_requests/squash_and_merge.md
index 075716e90c8..b9b8485021b 100644
--- a/doc/user/project/merge_requests/squash_and_merge.md
+++ b/doc/user/project/merge_requests/squash_and_merge.md
@@ -71,8 +71,8 @@ Prerequisites:
 
 To configure the default squashing behavior for all merge requests in your project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. In the **Squash commits when merging** section, select your desired behavior:
    - **Do not allow**: Squashing is never performed, and the option is not displayed.
    - **Allow**: Squashing is allowed, but cleared by default.
diff --git a/doc/user/project/merge_requests/status_checks.md b/doc/user/project/merge_requests/status_checks.md
index 0e339c65ed5..a151a7cbf1b 100644
--- a/doc/user/project/merge_requests/status_checks.md
+++ b/doc/user/project/merge_requests/status_checks.md
@@ -36,8 +36,8 @@ see [epic 3869](https://gitlab.com/groups/gitlab-org/-/epics/3869).
 
 By default, merge requests in projects can be merged even if external status checks fail. To block the merging of merge requests when external checks fail:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. Select the **Status checks must succeed** checkbox.
 1. Select **Save changes**.
 
diff --git a/doc/user/project/merge_requests/widgets.md b/doc/user/project/merge_requests/widgets.md
index a7aa86a16d4..639552ca75a 100644
--- a/doc/user/project/merge_requests/widgets.md
+++ b/doc/user/project/merge_requests/widgets.md
@@ -41,11 +41,11 @@ for environments. If it's the first time the branch is deployed, the link
 returns a `404` error until done. During the deployment, the stop button is
 disabled. If the pipeline fails to deploy, the deployment information is hidden.
 
-![Merge request pipeline](img/merge_request_pipeline.png)
+![Merge request pipeline](img/post_merge_pipeline_v16_0.png)
 
 For more information, [read about pipelines](../../../ci/pipelines/index.md).
 
-## Merge when pipeline succeeds (MWPS)
+## Set auto-merge
 
 Set a merge request that looks ready to merge to
 [merge automatically when CI pipeline succeeds](merge_when_pipeline_succeeds.md).
@@ -65,7 +65,7 @@ faster to preview proposed modifications.
 
 ## License compliance **(ULTIMATE)**
 
-If you have configured [License Compliance](../../compliance/license_compliance/index.md) for your project, then you can view a list of licenses that are detected for your project's dependencies.
+If you have configured [License Compliance](../../compliance/license_scanning_of_cyclonedx_files/index.md) for your project, then you can view a list of licenses that are detected for your project's dependencies.
 
 ![Merge request pipeline](img/license_compliance_widget_v15_3.png)
 
diff --git a/doc/user/project/milestones/index.md b/doc/user/project/milestones/index.md
index 4641af262ca..47325ee7c90 100644
--- a/doc/user/project/milestones/index.md
+++ b/doc/user/project/milestones/index.md
@@ -37,9 +37,8 @@ For information about project and group milestones API, see:
 
 To view the milestone list:
 
-1. On the top bar, select **Main menu > Projects** and find your project or
-   **Main menu > Groups** and find your group.
-1. Select **Issues > Milestones**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Milestones**.
 
 In a project, GitLab displays milestones that belong to the project.
 In a group, GitLab displays milestones that belong to the group and all projects in the group.
@@ -67,7 +66,8 @@ You might not see some milestones because they're in projects or groups you're n
 
 To do so:
 
-1. On the top bar select **Main menu > Your work**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Your work**.
 1. On the left sidebar, select **Milestones**.
 
 ### View milestone details
@@ -121,8 +121,8 @@ Prerequisites:
 
 To create a milestone:
 
-1. On the top bar, select **Main menu > Projects** and find your project or **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Issues > Milestones**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Milestones**.
 1. Select **New milestone**.
 1. Enter the title.
 1. Optional. Enter description, start date, and due date.
@@ -140,7 +140,8 @@ Prerequisites:
 
 To edit a milestone:
 
-1. On the top bar, select **Main menu > Projects** and find your project or **Main menu > Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Milestones**.
 1. Select a milestone's title.
 1. In the top right corner, select **Milestone actions** (**{ellipsis_v}**) and then select **Edit**.
 1. Edit the title, start date, due date, or description.
@@ -156,7 +157,8 @@ Prerequisites:
 
 To edit a milestone:
 
-1. On the top bar, select **Main menu > Projects** and find your project or **Main menu > Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Milestones**.
 1. Select a milestone's title.
 1. In the top right corner, select **Milestone actions** (**{ellipsis_v}**) and then select **Delete**.
 1. Select **Delete milestone**.
@@ -181,8 +183,8 @@ Prerequisites:
 
 To promote a project milestone:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues > Milestones**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Milestones**.
 1. Either:
    - Select **Promote to Group Milestone** (**{level-up}**) next to the milestone you want to promote.
    - Select the milestone title, and then select **Milestone actions** (**{ellipsis_v}**) > **Promote**.
diff --git a/doc/user/project/ml/experiment_tracking/index.md b/doc/user/project/ml/experiment_tracking/index.md
index a2c2ab0cc40..81c4bc20301 100644
--- a/doc/user/project/ml/experiment_tracking/index.md
+++ b/doc/user/project/ml/experiment_tracking/index.md
@@ -12,7 +12,7 @@ To enable the feature, ask an administrator to [enable the feature flag](../../.
 On GitLab.com, this feature is in private testing only.
 
 NOTE:
-Model experiment tracking is an [experimental feature](../../../../policy/alpha-beta-support.md). Refer to <https://gitlab.com/gitlab-org/gitlab/-/issues/381660> for feedback and feature requests.
+Model experiment tracking is an [experimental feature](../../../../policy/experiment-beta-support.md). Refer to <https://gitlab.com/gitlab-org/gitlab/-/issues/381660> for feedback and feature requests.
 
 When creating machine learning models, data scientists often experiment with different parameters, configurations, and feature
 engineering to improve the performance of the model. Keeping track of all this metadata and the associated
@@ -70,8 +70,8 @@ Prerequisites:
 
 To list the current active experiments, either go to `https/-/ml/experiments` or:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Packages & registries > Model experiments**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Deploy > Model experiments**.
 1. To display all candidates that have been logged, along with their metrics, parameters, and metadata, select an experiment.
 1. To display details for a candidate, select **Details**.
 
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
index a97fc1171fc..606f0474cb1 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
@@ -53,8 +53,8 @@ this document for an [overview on DNS records](dns_concepts.md).
 
 To add your custom domain to GitLab Pages:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Pages**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Pages**.
 
    If this path is not visible, select **Deployments > Pages**.
    [This location is part of an experiment](../index.md#menu-position-test).
@@ -165,10 +165,10 @@ If you're using Cloudflare, check
 
 #### 4. Verify the domain's ownership
 
-Once you have added all the DNS records:
+After you have added all the DNS records:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Pages**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Pages**.
 
    If this path is not visible, select **Deployments > Pages**.
    [This location is part of an experiment](../index.md#menu-position-test).
@@ -262,8 +262,8 @@ meet these requirements.
 
 - To add the certificate at the time you add a new domain:
 
-  1. On the top bar, select **Main menu > Projects** and find your project.
-  1. On the left sidebar, select **Settings > Pages**.
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+  1. Select **Settings > Pages**.
 
      If this path is not visible, select **Deployments > Pages**.
      [This location is part of an experiment](../index.md#menu-position-test).
@@ -274,8 +274,8 @@ meet these requirements.
 
 - To add the certificate to a domain previously added:
 
-  1. On the top bar, select **Main menu > Projects** and find your project.
-  1. On the left sidebar, select **Settings > Pages**.
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+  1. Select **Settings > Pages**.
 
      If this path is not visible, select **Deployments > Pages**.
      [This location is part of an experiment](../index.md#menu-position-test).
@@ -308,8 +308,8 @@ domain (as long as you've set a valid certificate for it).
 
 To enable this setting:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Pages**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Pages**.
 
    If this path is not visible, select **Deployments > Pages**.
    [This location is part of an experiment](../index.md#menu-position-test).
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
index 91633e01ad2..15152efb80c 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
@@ -42,8 +42,8 @@ For **self-managed** GitLab instances, make sure your administrator has
 
 Once you've met the requirements, enable Let's Encrypt integration:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Pages**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Pages**.
 
    If this path is not visible, select **Deployments > Pages**.
    [This location is part of an experiment](../index.md#menu-position-test).
@@ -72,8 +72,8 @@ associated Pages domain. GitLab also renews it automatically.
 
 If you get an error **Something went wrong while obtaining the Let's Encrypt certificate**, first, make sure that your pages site is set to "Everyone" in your project's **Settings > General > Visibility**. This allows the Let's Encrypt Servers reach your pages site. Once this is confirmed, you can try obtaining the certificate again by following these steps:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Pages**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Pages**.
 
    If this path is not visible, select **Deployments > Pages**.
    [This location is part of an experiment](../index.md#menu-position-test).
@@ -90,8 +90,8 @@ If you get an error **Something went wrong while obtaining the Let's Encrypt cer
 
 If you've enabled Let's Encrypt integration, but a certificate is absent after an hour and you see the message, "GitLab is obtaining a Let's Encrypt SSL certificate for this domain. This process can take some time. Please try again later.", try to remove and add the domain for GitLab Pages again by following these steps:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Pages**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Pages**.
 
    If this path is not visible, select **Deployments > Pages**.
    [This location is part of an experiment](../index.md#menu-position-test).
diff --git a/doc/user/project/pages/getting_started/pages_ci_cd_template.md b/doc/user/project/pages/getting_started/pages_ci_cd_template.md
index 17618146350..167c72fdc89 100644
--- a/doc/user/project/pages/getting_started/pages_ci_cd_template.md
+++ b/doc/user/project/pages/getting_started/pages_ci_cd_template.md
@@ -16,8 +16,7 @@ Use a `.gitlab-ci.yml` template when you have an existing project that you want
 Your GitLab repository should contain files specific to an SSG, or plain HTML. After you complete
 these steps, you may have to do additional configuration for the Pages site to generate properly.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select the project's name.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. From the **Add** (**{plus}**) dropdown list, select **New file**.
 1. From the **Select a template type** dropdown list, select `.gitlab-ci.yml`.
 1. From the **Apply a template** dropdown list, in the **Pages** section, select the name of your SSG.
diff --git a/doc/user/project/pages/getting_started/pages_ui.md b/doc/user/project/pages/getting_started/pages_ui.md
index 00635fe6db2..16d5cfcca4a 100644
--- a/doc/user/project/pages/getting_started/pages_ui.md
+++ b/doc/user/project/pages/getting_started/pages_ui.md
@@ -1,6 +1,6 @@
 ---
-stage: Create
-group: Incubation
+stage: Plan
+group: Knowledge
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
@@ -33,8 +33,8 @@ a pipeline deploys your Pages website.
 
 To complete the setup and generate a GitLab Pages deployment:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Pages**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Pages**.
 
    If this path is not visible, select **Deployments > Pages**.
    [This location is part of an experiment](../index.md#menu-position-test).
diff --git a/doc/user/project/pages/index.md b/doc/user/project/pages/index.md
index a68ad604989..9b299b46f75 100644
--- a/doc/user/project/pages/index.md
+++ b/doc/user/project/pages/index.md
@@ -129,12 +129,14 @@ If you are running a self-managed instance of GitLab,
 ### Configure GitLab Pages in a Helm Chart (Kubernetes) instance
 
 To configure GitLab Pages on instances deployed via Helm chart (Kubernetes), use either:
- 
-- [The `gitlab-pages` subchart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-pages/). 
-- [An external GitLab Pages instance](https://docs.gitlab.com/charts/advanced/external-gitlab-pages/). 
+
+- [The `gitlab-pages` subchart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-pages/).
+- [An external GitLab Pages instance](https://docs.gitlab.com/charts/advanced/external-gitlab-pages/).
 
 ## Security for GitLab Pages
 
+### Namespaces that contain `.`
+
 If your username is `example`, your GitLab Pages website is located at `example.gitlab.io`.
 GitLab allows usernames to contain a `.`, so a user named `bar.example` could create
 a GitLab Pages website `bar.example.gitlab.io` that effectively is a subdomain of your
@@ -153,3 +155,9 @@ document.cookie = "key=value;domain=example.gitlab.io";
 
 This issue doesn't affect users with a custom domain, or users who don't set any
 cookies manually with JavaScript.
+
+### Shared cookies
+
+By default, every project in a group shares the same domain, for example, `group.gitlab.io`. This means that cookies are also shared for all projects in a group.
+
+To ensure each project uses different cookies, enable the Pages [unique domains](introduction.md#enable-unique-domains) feature for your project.
diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md
index 05d0b461fea..73bfe018a7d 100644
--- a/doc/user/project/pages/introduction.md
+++ b/doc/user/project/pages/introduction.md
@@ -66,8 +66,8 @@ You can configure redirects for your site using a `_redirects` file. For more in
 
 To remove your pages:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Pages**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Pages**.
 
    If this path is not visible, select **Deployments > Pages**.
    [This location is part of an experiment](index.md#menu-position-test).
@@ -94,6 +94,25 @@ the group must be at the top level and not a subgroup.
 For [project websites](../../project/pages/getting_started_part_one.md#project-website-examples),
 you can create your project first and access it under `http(s)://namespace.example.io/projectname`.
 
+## Enable unique domains
+
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/9347) in GitLab 15.9 [with a flag](../../../administration/feature_flags.md) named `pages_unique_domain`. Disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/388151) in GitLab 15.11.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available,
+ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `pages_unique_domain`.
+On GitLab.com, by default this feature is available.
+
+By default, every project in a group shares the same domain, for example, `group.gitlab.io`. This means that cookies are also shared for all projects in a group.
+
+To ensure your project uses a unique Pages domain, enable the unique domains feature for the project:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Pages**.
+1. Select the **Use unique domain** checkbox.
+1. Select **Save changes**.
+
 ## Specific configuration options for Pages
 
 Learn how to set up GitLab CI/CD for specific use cases.
diff --git a/doc/user/project/protected_branches.md b/doc/user/project/protected_branches.md
index 1d279436d2c..6958b69061a 100644
--- a/doc/user/project/protected_branches.md
+++ b/doc/user/project/protected_branches.md
@@ -30,19 +30,23 @@ When a branch is protected, the default behavior enforces these restrictions on
 |:-------------------------|:------------------------------------------------------------------|
 | Protect a branch         | At least the Maintainer role.                                     |
 | Push to the branch       | Anyone with **Allowed** permission. (1) |
-| Force push to the branch | No one.                                                           |
+| Force push to the branch | No one. (3)                                                       |
 | Delete the branch        | No one. (2)                                                       |
 
 1. Users with the Developer role can create a project in a group, but might not be allowed to
    initially push to the [default branch](repository/branches/default.md).
 1. No one can delete a protected branch using Git commands, however, users with at least Maintainer
    role can [delete a protected branch from the UI or API](#delete-a-protected-branch).
+1. If the `group_protected_branches` feature flag is enabled _and_ the same branch is
+   protected at both the group and project levels, force push settings configured
+   for that branch at the project level are ignored. All other protections continue
+   to use project level settings.
 
 ### When a branch matches multiple rules
 
 When a branch matches multiple rules, the **most permissive rule** determines the
 level of protection for the branch. For example, consider these rules, which include
-[wildcards](#configure-multiple-protected-branches-by-using-a-wildcard):
+[wildcards](#protect-multiple-branches-with-wildcard-rules):
 
 | Branch name pattern | Allowed to merge       | Allowed to push and merge |
 |---------------------|------------------------|-----------------|
@@ -77,29 +81,59 @@ that matches `v1.x` must set `Allowed to push and merge` to `No one`, like this:
 Administrators can set a default branch protection level in the
 [Admin Area](../project/repository/branches/default.md#instance-level-default-branch-protection).
 
-## Configure a protected branch
+## Add protection to existing branches
 
 Configure protected branches for all projects in a group, or just for a project.
 
-### For all projects in a group **(PREMIUM)**
+### For one project
+
+Prerequisites:
+
+- You must have at least the Maintainer role.
+- When granting a group **Allowed to merge** or **Allowed to push and merge** permissions
+  on a protected branch, the group must be added to the project.
+
+To protect a branch:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
+1. Expand **Protected branches**.
+1. From the **Branch** dropdown list, select the branch you want to protect.
+1. From the **Allowed to merge** list, select a role that can merge into this branch.
+1. From the **Allowed to push and merge** list, select a role that can push to this branch.
+
+   NOTE:
+   In GitLab Premium and Ultimate, you can also add groups or individual users
+   to **Allowed to merge** and **Allowed to push and merge**.
+
+1. Select **Protect**.
+
+The protected branch displays in the list of protected branches.
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106532) in GitLab 15.9 behind a feature flag, disabled by default.
+### For all projects in a group **(PREMIUM)**
 
-Group owners can create protected branches for a group. These settings are inherited by all projects in the group and can't be overridden by project settings.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106532) in GitLab 15.9 [with a flag](../../administration/feature_flags.md) named `group_protected_branches`. Disabled by default.
 
 FLAG:
 On self-managed GitLab, by default this feature is not available.
-To make it available, ask an administrator to [enable the feature flag](../../administration/feature_flags.md)
+To make it available, ask an administrator to
+[enable the feature flag](../../administration/feature_flags.md)
 named `group_protected_branches`. On GitLab.com, this feature is not available.
 
+Group owners can create protected branches for a group. These settings are inherited
+by all projects in the group and can't be overridden by project settings. If a
+specific branch is configured with **Allowed to force push** settings at both the
+group and project levels, the **Allowed to force push** setting at the _project_ level
+is ignored in favor of the group level setting.
+
 Prerequisite:
 
 - You must have the Owner role in the group.
 
 To protect a branch for all the projects in a group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Repository**.
 1. Expand **Protected branches**.
 1. In the **Branch** text box, type the branch name or a wildcard.
 1. From the **Allowed to merge** list, select a role that can merge into this branch.
@@ -108,31 +142,12 @@ To protect a branch for all the projects in a group:
 
 The protected branch is added to the list of protected branches.
 
-### For a project
-
-Prerequisite:
-
-- You must have at least the Maintainer role.
-- When granting a group **Allowed to merge** or **Allowed to push and merge** permissions
-  on a protected branch, the group must be added to the project.
-
-To protect a branch:
-
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
-1. Expand **Protected branches**.
-1. From the **Branch** dropdown list, select the branch you want to protect.
-1. From the **Allowed to merge** list, select a role, or group that can merge into this branch. In GitLab Premium, you can also add users.
-1. From the **Allowed to push and merge** list, select a role, group, or user that can push to this branch. In GitLab Premium, you can also add users.
-1. Select **Protect**.
-
-The protected branch displays in the list of protected branches.
-
-## Configure multiple protected branches by using a wildcard
+## Protect multiple branches with wildcard rules
 
-If both a specific rule and a wildcard rule apply to the same branch, the most
-permissive rule controls how the branch behaves. For merge controls to work properly,
-set **Allowed to push and merge** to a broader set of users than **Allowed to merge**.
+When using wildcards, multiple rules can apply to a single branch.
+If more than one rule applies to a branch, the _most permissive_ rule controls
+how the branch behaves. For merge controls to work properly, set
+**Allowed to push and merge** to a broader set of users than **Allowed to merge**.
 
 Prerequisite:
 
@@ -140,8 +155,8 @@ Prerequisite:
 
 To protect multiple branches at the same time:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Protected branches**.
 1. From the **Branch** dropdown list, type the branch name and a wildcard.
    For example:
@@ -152,19 +167,21 @@ To protect multiple branches at the same time:
    | `production/*`            | `production/app-server`, `production/load-balancer`    |
    | `*gitlab*`                | `gitlab`, `gitlab/staging`, `master/gitlab/production` |
 
-1. From the **Allowed to merge** list, select a role, or group that can merge into this branch. In GitLab Premium, you can also add users.
-1. From the **Allowed to push and merge** list, select a role, group, or user that can push to this branch. In GitLab Premium, you can also add users.
+1. From the **Allowed to merge** list, select a role that can merge into
+   this branch.
+1. From the **Allowed to push and merge** list, select a role that can
+   push to this branch. In GitLab Premium or Ultimate, you can also add groups or individual users.
 1. Select **Protect**.
 
 The protected branch displays in the list of protected branches.
 
-## Create a protected branch
+## Create a new branch with protections
 
-Users with at least the Developer role can create a protected branch.
+Users with at least the Developer role can create new protected branches.
 
 Prerequisites:
 
-- **Allowed to push and merge** is set to **No one**
+- **Allowed to push and merge** is set to **No one**.
 - **Allowed to merge** is set to **Developers**.
 
 You can create a protected branch by using the UI or API only.
@@ -173,8 +190,8 @@ from the command line or from a Git client application.
 
 To create a new branch through the user interface:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Branches**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Branches**.
 1. Select **New branch**.
 1. Fill in the branch name and select an existing branch, tag, or commit to
    base the new branch on. Only existing protected branches and commits
@@ -186,8 +203,8 @@ You can force everyone to submit a merge request, rather than allowing them to
 check in directly to a protected branch. This setting is compatible with workflows
 like the [GitLab workflow](../../topics/gitlab_flow.md).
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Protected branches**.
 1. From the **Branch** dropdown list, select the branch you want to protect.
 1. From the **Allowed to merge** list, select **Developers + Maintainers**.
@@ -198,8 +215,8 @@ like the [GitLab workflow](../../topics/gitlab_flow.md).
 
 You can allow everyone with write access to push to the protected branch.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Protected branches**.
 1. From the **Branch** dropdown list, select the branch you want to protect.
 1. From the **Allowed to push and merge** list, select **Developers + Maintainers**.
@@ -226,8 +243,8 @@ Prerequisites:
 
 To allow a deploy key to push to a protected branch:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Protected branches**.
 1. From the **Branch** dropdown list, select the branch you want to protect.
 1. From the **Allowed to push and merge** list, select the deploy key.
@@ -245,8 +262,8 @@ protected branches.
 
 To protect a new branch and enable force push:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Protected branches**.
 1. From the **Branch** dropdown list, select the branch you want to protect.
 1. From the **Allowed to push and merge** and **Allowed to merge** lists, select the settings you want.
@@ -257,23 +274,49 @@ To protect a new branch and enable force push:
 
 To enable force pushes on branches that are already protected:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Protected branches**.
 1. In the list of protected branches, next to the branch, turn on the **Allowed to force push** toggle.
 
 Members who can push to this branch can now also force push.
 
+### When a branch matches multiple rules
+
+When a branch matches multiple rules, the **most permissive rule** determines the
+level of protection for the branch. For example, consider these rules, which include
+[wildcards](#protect-multiple-branches-with-wildcard-rules):
+
+| Branch name pattern | Allow force push |
+|---------------------|------------------|
+| `v1.x`              | Yes              |
+| `v1.*`              | No               |
+| `v*`                | No               |
+
+A branch named `v1.x` matches all three branch name patterns: `v1.x`, `v1.*`, and `v*`.
+As the most permissive option determines the behavior, the resulting permissions for branch `v1.x` are:
+
+- **Allow force push:** Of the three settings, `Yes` is most permissive,
+  and controls branch behavior as a result. Even though the branch also matched `v1.x` and `v*`
+  (which each have stricter permissions), any user that can push to this branch can also force push.
+
+NOTE:
+Force push settings for a branch at the project level are overridden by group level settings
+if the `group_protected_branches` feature flag is enabled and a group owner has set
+[group level protection for the same branch](#for-all-projects-in-a-group).
+
 ## Require Code Owner approval on a protected branch **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35097) in GitLab 13.5, users and groups who can push to protected branches do not have to use a merge request to merge their feature branches. This means they can skip merge request approval rules.
 
 For a protected branch, you can require at least one approval by a [Code Owner](codeowners/index.md).
+If a branch is protected by multiple rules, code owner approval is required if _any_ of
+the applicable rules have **Required approval from code owners** enabled.
 
 To protect a new branch and enable Code Owner's approval:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Protected branches**.
 1. From the **Branch** dropdown list, select the branch you want to protect.
 1. From the **Allowed to push and merge** and **Allowed to merge** lists, select the settings you want.
@@ -282,8 +325,8 @@ To protect a new branch and enable Code Owner's approval:
 
 To enable Code Owner's approval on branches that are already protected:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Protected branches**.
 1. In the list of protected branches, next to the branch, turn on the **Code owner approval** toggle.
 
@@ -314,8 +357,8 @@ for details about the pipelines security model.
 Users with at least the Maintainer role can manually delete protected
 branches by using the GitLab web interface:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Branches**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Branches**.
 1. Next to the branch you want to delete, select **Delete** (**{remove}**).
 1. On the confirmation dialog, type the branch name.
 1. Select **Yes, delete protected branch**.
diff --git a/doc/user/project/protected_tags.md b/doc/user/project/protected_tags.md
index 3af475afa4f..0449c9867e2 100644
--- a/doc/user/project/protected_tags.md
+++ b/doc/user/project/protected_tags.md
@@ -31,15 +31,20 @@ Prerequisites:
 
 - You must have at least the Maintainer role for the project.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Protected tags**.
 1. To protect a single tag, select **Tag**, then choose your tag from the dropdown list.
 1. To protect all tags with names matching a string:
    1. Select **Tag**.
    1. Enter the string to use for tag matching. Wildcards (`*`) are supported.
    1. Select **Create wildcard**.
-1. In **Allowed to create** , select either the users or roles that may create protected tags.
+1. In **Allowed to create** , select roles that may create protected tags.
+
+   NOTE:
+   In GitLab Premium and Ultimate, you can also add groups or individual users
+   to **Allowed to create**.
+
 1. Select **Protect**.
 
 The protected tag (or wildcard) displays in the **Protected tags** list.
@@ -105,8 +110,8 @@ Prerequisites:
 
 To allow a deploy key to create a protected tag:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Protected tags**.
 1. From the **Tag** dropdown list, select the tag you want to protect.
 1. From the **Allowed to create** list, select the deploy key.
@@ -123,8 +128,8 @@ Prerequisite:
 
 To do this:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Tags**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Tags**.
 1. Next to the tag you want to delete, select **Delete** (**{remove}**).
 1. On the confirmation dialog, enter the tag name and select **Yes, delete protected tag**.
 
diff --git a/doc/user/project/push_options.md b/doc/user/project/push_options.md
index 1f85490795f..368a59e69b0 100644
--- a/doc/user/project/push_options.md
+++ b/doc/user/project/push_options.md
@@ -35,7 +35,7 @@ You can use push options to skip a CI/CD pipeline, or pass CI/CD variables.
 
 | Push option                    | Description                                                                                 | Introduced in version |
 | ------------------------------ | ------------------------------------------------------------------------------------------- |---------------------- |
-| `ci.skip`                      | Do not create a CI pipeline for the latest push. Only skips branch pipelines and not [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md). | [11.7](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15643) |
+| `ci.skip`                      | Do not create a CI pipeline for the latest push. Only skips branch pipelines and not [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md). This does not skip pipelines for CI integrations, such as Jenkins. | [11.7](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15643) |
 | `ci.variable="<name>=<value>"` | Provide [CI/CD variables](../../ci/variables/index.md) to be used in a CI pipeline, if one is created due to the push. Only passes variables to branch pipelines and not [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md). | [12.6](https://gitlab.com/gitlab-org/gitlab/-/issues/27983) |
 
 An example of using `ci.skip`:
diff --git a/doc/user/project/quick_actions.md b/doc/user/project/quick_actions.md
index 2c52a5d743a..3e8ce009740 100644
--- a/doc/user/project/quick_actions.md
+++ b/doc/user/project/quick_actions.md
@@ -129,8 +129,9 @@ threads. Some quick actions might not be available to all subscription tiers.
 | `/unsubscribe`                                                                                   | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | Unsubscribe from notifications.
 | `/weight <value>`                                                                                | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Set weight. Valid options for `<value>` include `0`, `1`, `2`, and so on.
 | `/zoom <Zoom URL>`                                                                               | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Add a Zoom meeting to this issue or incident. In [GitLab 15.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/230853) users on GitLab Premium can add a short description when [adding a Zoom link to an incident](../../operations/incident_management/linked_resources.md#link-zoom-meetings-from-an-incident).
-| `/blocks <issue1> <issue2>`                                                                          | **{check-circle}** Yes | **{check-circle}** No | **{dotted-circle}** No | Mark the issue as blocking other issues. The `<issue>` value should be in the format of `#issue`, `group/project#issue`, or the full issue URL. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214232) in GitLab 16.0).
-| `/blocked_by <issue1> <issue2>`                                                                      | **{check-circle}** Yes | **{check-circle}** No | **{dotted-circle}** No | Mark the issue as blocked by other issues. The `<issue>` value should be in the format of `#issue`, `group/project#issue`, or the full issue URL. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214232) in GitLab 16.0).
+| `/blocks <issue1> <issue2>`                                                                          | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Mark the issue as blocking other issues. The `<issue>` value should be in the format of `#issue`, `group/project#issue`, or the full issue URL. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214232) in GitLab 16.0).
+| `/blocked_by <issue1> <issue2>`                                                                      | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Mark the issue as blocked by other issues. The `<issue>` value should be in the format of `#issue`, `group/project#issue`, or the full issue URL. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214232) in GitLab 16.0).
+| `/unlink <issue>`                                                                             | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Remove link with to the provided issue. The `<issue>` value should be in the format of `#issue`, `group/project#issue`, or the full issue URL. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/414400) in GitLab 16.1).
 
 ## Work items
 
@@ -162,7 +163,8 @@ The following quick actions can be applied through the description field when ed
 | `/clear_health_status`                                                                           | **{check-circle}** Yes | **{dotted-circle}** Yes | **{dotted-circle}** Yes | Clear [health status](issues/managing_issues.md#health-status).
 | `/weight <value>`                                                                                | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Set weight. Valid options for `<value>` include `0`, `1`, and `2`.
 | `/clear_weight`                                                                                  | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Clear weight.
-| `/type`                                                                                          | **{check-circle}** Yes | **{dotted-circle}** Yes | **{dotted-circle}** Yes | Converts work item to specified type. Available options for `<type>` include `Issue`, `Task`, `Objective` and `Key Result`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/385227) in GitLab 16.0 [with a flag](../../administration/feature_flags.md) named `work_items_mvc_2`. Disabled by default.
+| `/type`                                                                                          | **{check-circle}** Yes | **{dotted-circle}** Yes | **{dotted-circle}** Yes | Converts work item to specified type. Available options for `<type>` include `Issue`, `Task`, `Objective` and `Key Result`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/385227) in GitLab 16.0.
+| `/promote_to <type>`                                                                                          | **{check-circle}** Yes | **{dotted-circle}** No | **{check-circle}** Yes | Promotes work item to specified type. Available options for `<type>`: `issue` (promote a task) and `objective` (promote a key result). [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/412534) in GitLab 16.1.
 
 ## Commit messages
 
diff --git a/doc/user/project/releases/index.md b/doc/user/project/releases/index.md
index d0c44b7e837..6bcc57d5916 100644
--- a/doc/user/project/releases/index.md
+++ b/doc/user/project/releases/index.md
@@ -74,8 +74,8 @@ Prerequisites:
 
 To create a release in the Releases page:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Releases** and select **New release**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Build > Releases** and select **New release**.
 1. From the [**Tag name**](release_fields.md#tag-name) dropdown list, either:
    - Select an existing Git tag. Selecting an existing tag that is already associated with a release
      results in a validation error.
@@ -215,8 +215,8 @@ To delete a release, use either the
 
 In the UI:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Deployments > Releases**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Deploy > Releases**.
 1. In the upper-right corner of the release you want to delete, select **Edit this release**
    (**{pencil}**).
 1. On the **Edit Release** page, select **Delete**.
diff --git a/doc/user/project/releases/release_cli.md b/doc/user/project/releases/release_cli.md
index bd3cfd26f1b..c5fb3838b11 100644
--- a/doc/user/project/releases/release_cli.md
+++ b/doc/user/project/releases/release_cli.md
@@ -23,7 +23,7 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description \
   "Created using the release-cli $EXTRA_DESCRIPTION" \
   --tag-name "v${MAJOR}.${MINOR}.${REVISION}" --ref "$CI_COMMIT_SHA" \
   --released-at "2020-07-15T08:00:00Z" --milestone "m1" --milestone "m2" --milestone "m3" \
-  --assets-link "{\"name\":\"asset1\",\"url\":\"https://example.com/assets/1\",\"link_type\":\"other\"}
+  --assets-link "{\"name\":\"asset1\",\"url\":\"https://example.com/assets/1\",\"link_type\":\"other\"}"
 ```
 
 ## Install the `release-cli` for the Shell executor **(FREE)**
@@ -37,13 +37,8 @@ Once installed, [the `release` keyword](../../../ci/yaml/index.md#release) is av
 
 ### Install on Unix/Linux
 
-1. Download the binary for your system from S3, in the following example for amd64 systems:
-
-   ```shell
-   curl --location --output /usr/local/bin/release-cli "https://release-cli-downloads.s3.amazonaws.com/latest/release-cli-linux-amd64"
-   ```
-
-   Or from the GitLab Package Registry:
+1. Download the binary for your system from the GitLab Package Registry.
+   For example, if you use an amd64 system:
 
    ```shell
    curl --location --output /usr/local/bin/release-cli "https://gitlab.com/api/v4/projects/gitlab-org%2Frelease-cli/packages/generic/release-cli/latest/release-cli-linux-amd64"
@@ -60,7 +55,7 @@ Once installed, [the `release` keyword](../../../ci/yaml/index.md#release) is av
    ```shell
    $ release-cli -v
 
-   release-cli version 0.6.0
+   release-cli version 0.15.0
    ```
 
 ### Install on Windows PowerShell
@@ -74,7 +69,7 @@ Once installed, [the `release` keyword](../../../ci/yaml/index.md#release) is av
 1. Download the executable file:
 
    ```shell
-   PS C:\> Invoke-WebRequest -Uri "https://release-cli-downloads.s3.amazonaws.com/latest/release-cli-windows-amd64.exe" -OutFile "C:\GitLab\Release-CLI\bin\release-cli.exe"
+   PS C:\> Invoke-WebRequest -Uri "https://gitlab.com/api/v4/projects/gitlab-org%2Frelease-cli/packages/generic/release-cli/latest/release-cli-windows-amd64.exe" -OutFile "C:\GitLab\Release-CLI\bin\release-cli.exe"
 
        Directory: C:\GitLab\Release-CLI
    Mode                LastWriteTime         Length Name
@@ -93,5 +88,5 @@ Once installed, [the `release` keyword](../../../ci/yaml/index.md#release) is av
    ```shell
    PS C:\> release-cli -v
 
-   release-cli version 0.6.0
+   release-cli version 0.15.0
    ```
diff --git a/doc/user/project/remote_development/index.md b/doc/user/project/remote_development/index.md
index d4156de2ebe..6a9d0c73e9a 100644
--- a/doc/user/project/remote_development/index.md
+++ b/doc/user/project/remote_development/index.md
@@ -14,7 +14,7 @@ FLAG:
 On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../../../administration/feature_flags.md) named `vscode_web_ide`. On GitLab.com, this feature is available. The feature is not ready for production use.
 
 WARNING:
-This feature is in [Beta](../../../policy/alpha-beta-support.md#beta) and subject to change without notice.
+This feature is in [Beta](../../../policy/experiment-beta-support.md#beta) and subject to change without notice.
 
 You can use remote development to write and compile code hosted on GitLab. With remote development, you can:
 
diff --git a/doc/user/project/repository/branches/default.md b/doc/user/project/repository/branches/default.md
index e58cc0bf6a4..100450aefe7 100644
--- a/doc/user/project/repository/branches/default.md
+++ b/doc/user/project/repository/branches/default.md
@@ -42,8 +42,8 @@ Prerequisites:
 
 To update the default branch for an individual [project](../../index.md):
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. In the left navigation menu, go to **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Branch defaults**. For **Default branch**, select a new default branch.
 1. Optional. Select the **Auto-close referenced issues on default branch** checkbox to close
    issues when a merge request
@@ -68,8 +68,9 @@ GitLab [administrators](../../../permissions.md) of self-managed instances can
 customize the initial branch for projects hosted on that instance. Individual
 groups and subgroups can override this instance-wide setting for their projects.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Repository**.
 1. Expand **Default branch**.
 1. For **Initial default branch name**, select a new default branch.
 1. Select **Save changes**.
@@ -84,8 +85,8 @@ overrides it.
 
 Users with the Owner role of groups and subgroups can configure the default branch name for a group:
 
-1. On the top bar, select **Main menu > Group** and find your group.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Repository**.
 1. Expand **Default branch**.
 1. For **Initial default branch name**, select a new default branch.
 1. Select **Save changes**.
@@ -95,6 +96,8 @@ unless a subgroup configuration overrides it.
 
 ## Protect initial default branches **(FREE SELF)**
 
+> Full protection after initial push [added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118729) in GitLab 16.0.
+
 GitLab administrators and group owners can define [branch protections](../../../project/protected_branches.md)
 to apply to every repository's [default branch](#default-branch)
 at the [instance level](#instance-level-default-branch-protection) and
@@ -108,6 +111,8 @@ at the [instance level](#instance-level-default-branch-protection) and
    but cannot force push.
 - **Fully protected** - Developers cannot push new commits, but maintainers can.
    No one can force push.
+- **Fully protected after initial push** - Developers can push the initial commit
+  to a repository, but none afterward. Maintainers can always push. No one can force push.
 
 ### Instance-level default branch protection **(FREE SELF)**
 
@@ -120,8 +125,9 @@ you must either:
 Administrators of self-managed instances can customize the initial default branch protection for projects hosted on that instance. Individual
 groups and subgroups can override this instance-wide setting for their projects.
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Repository**.
 1. Expand **Default branch**.
 1. Select [**Initial default branch protection**](#protect-initial-default-branches).
 1. To allow group owners to override the instance's default branch protection, select
@@ -137,8 +143,9 @@ can be overridden on a per-group basis by the group's owner. In
 [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/), GitLab administrators can
 disable this privilege for group owners, enforcing the instance-level protection rule:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Repository**.
 1. Expand the **Default branch** section.
 1. Clear the **Allow owners to manage default branch protection per group** checkbox.
 1. Select **Save changes**.
@@ -157,8 +164,8 @@ can be overridden on a per-group basis by the group's owner. In
 [enforce protection of initial default branches](#prevent-overrides-of-default-branch-protection)
 which locks this setting for group owners.
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Repository**.
 1. Expand **Default branch**.
 1. Select [**Initial default branch protection**](#protect-initial-default-branches).
 1. Select **Save changes**.
diff --git a/doc/user/project/repository/branches/img/delete_merged_branches.png b/doc/user/project/repository/branches/img/delete_merged_branches.png
deleted file mode 100644
index 649a758b95f..00000000000
--- a/doc/user/project/repository/branches/img/delete_merged_branches.png
+++ /dev/null
diff --git a/doc/user/project/repository/branches/index.md b/doc/user/project/repository/branches/index.md
index 7c09ce5c580..e43efca600a 100644
--- a/doc/user/project/repository/branches/index.md
+++ b/doc/user/project/repository/branches/index.md
@@ -29,8 +29,8 @@ Branches are the foundation of development in a project:
 
 To create a new branch from the GitLab UI:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Branches**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Branches**.
 1. On the top right, select **New branch**.
 1. Enter a **Branch name**.
 1. In **Create from**, select the base of your branch: an existing branch, an existing
@@ -52,7 +52,7 @@ Prerequisites:
 
 To add a [default branch](default.md) to an empty project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Scroll to **The repository for this project is empty** and select the type of
    file you want to add.
 1. In the Web IDE, make any desired changes to this file, then select **Create commit**.
@@ -62,7 +62,14 @@ GitLab creates a default branch and adds your file to it.
 
 ### From an issue
 
+Prerequisites:
+
+- You must have at least the Developer role in the project.
+
 When viewing an issue, you can create an associated branch directly from that page.
+Branches created this way use the
+[default pattern for branch names from issues](#configure-default-pattern-for-branch-names-from-issues),
+including variables.
 
 Prerequisites:
 
@@ -70,8 +77,8 @@ Prerequisites:
 
 To create a branch from an issue:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues** (**{issues}**) and find your issue.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues** and find your issue.
 1. Below the issue description, find the **Create merge request** dropdown list, and select
    **{chevron-down}** to display the dropdown list.
 1. Select **Create branch**. A default **Branch name** is provided, based on the
@@ -104,8 +111,8 @@ You can manage your branches:
 
 To view and manage your branches in the GitLab user interface:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Branches**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Branches**.
 
 On this page, you can:
 
@@ -142,8 +149,8 @@ Prerequisites:
 
 To view the **Branch rules overview** list:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Branch Rules** to view all branches with protections.
    - To add protections to a new branch:
      1. Select **Add branch rule**.
@@ -193,8 +200,9 @@ Prerequisites:
 
 To change the default pattern for branches created from issues:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository** and expand **Branch defaults**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
+1. Expand **Branch defaults**.
 1. Scroll to **Branch name template** and enter a value. The field supports these variables:
    - `%{id}`: The numeric ID of the issue.
    - `%{title}`: The title of the issue, modified to use only characters acceptable in Git branch names.
@@ -230,8 +238,8 @@ new changes. It uses the merge base, not the actual commit content, to compare b
 
 To compare branches in a repository:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Compare revisions**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Compare revisions**.
 1. Select the **Source** branch to search for your desired branch. Exact matches are
    shown first. You can refine your search with operators:
    - `^` matches the beginning of the branch name: `^feat` matches `feat/user-authentication`.
@@ -244,15 +252,22 @@ To compare branches in a repository:
 
 ## Delete merged branches
 
-![Delete merged branches](img/delete_merged_branches.png)
+Merged branches can be deleted in bulk if they meet all of these criteria:
+
+- They are not [protected branches](../../protected_branches.md).
+- They have been merged into the project's default branch.
+
+Prerequisites:
+
+- You must have at least the Developer role in the project.
 
-This feature allows merged branches to be deleted in bulk. Only branches that
-have been merged into the project's default branch and
-[are not protected](../../protected_branches.md) are deleted as part of
-this operation.
+To do this:
 
-It's particularly useful to clean up old branches that were not deleted
-automatically when a merge request was merged.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Branches**.
+1. On the upper right corner of the page, select **More** **{ellipsis_v}**.
+1. Select **Delete merged branches**.
+1. In the modal window, enter the word `delete` to confirm, then select **Delete merged branches**.
 
 ## Related topics
 
@@ -308,8 +323,8 @@ Error: Could not set the default branch. Do you have a branch named 'HEAD' in yo
 
 To fix this problem:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Branches**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Branches**.
 1. Search for a branch named `HEAD`.
 1. Make sure the branch has no uncommitted changes.
 1. Select **Delete branch**, then **Yes, delete branch**.
diff --git a/doc/user/project/repository/code_suggestions.md b/doc/user/project/repository/code_suggestions.md
index 5de55db5ad4..dd1fa3f4c8b 100644
--- a/doc/user/project/repository/code_suggestions.md
+++ b/doc/user/project/repository/code_suggestions.md
@@ -7,19 +7,21 @@ type: index, reference
 
 # Code Suggestions (Beta) **(FREE SAAS)**
 
-> - [Introduced](https://about.gitlab.com/releases/2023/02/22/gitlab-15-9-released/#code-suggestions-available-in-closed-beta) in GitLab 15.9 as [Beta](/ee/policy/alpha-beta-support.md#beta) for early access Ultimate customers.
-> - [Enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/408104) as opt-in with GitLab 15.11 as [Beta](/ee/policy/alpha-beta-support.md#beta).
+> - [Introduced](https://about.gitlab.com/releases/2023/02/22/gitlab-15-9-released/#code-suggestions-available-in-closed-beta) in GitLab 15.9 as [Beta](/ee/policy/experiment-beta-support.md#beta) for early access Ultimate customers.
+> - [Enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/408104) as opt-in with GitLab 15.11 as [Beta](/ee/policy/experiment-beta-support.md#beta).
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/408158) from GitLab Ultimate to GitLab Premium in 16.0.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/410801) from GitLab Premium to GitLab Free in 16.0.
+> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121079) in GitLab 16.1.
+> - [Default to third-party AI services](https://gitlab.com/groups/gitlab-org/-/epics/10562) in GitLab 16.1.
 
 WARNING:
-This feature is in [Beta](/ee/policy/alpha-beta-support.md#beta).
-Code Suggestions use generative AI to suggest code while you're developing.
-Due to high demand, this feature will have unscheduled downtime and code suggestions in VS Code may be delayed.
+This feature is in [Beta](/ee/policy/experiment-beta-support.md#beta).
+Due to high demand, this feature may have unscheduled downtime and Code Suggestions in IDEs may be delayed.
 Code Suggestions may produce [low-quality or incomplete suggestions](#model-accuracy-and-quality).
 Beta users should read about the [known limitations](#known-limitations). We look forward to hearing your feedback.
 
-Use Code Suggestions to write code more efficiently by viewing code suggestions
+Code Suggestions use generative AI to suggest code while you're developing.
+Use Code Suggestions to write code more efficiently by viewing Code Suggestions
 as you type. Depending on the cursor position, the extension either:
 
 - Provides entire code snippets, like generating functions.
@@ -27,47 +29,68 @@ as you type. Depending on the cursor position, the extension either:
 
 To accept a suggestion, press <kbd>Tab</kbd>.
 
-Code Suggestions are available in Visual Studio Code when you have the GitLab Workflow extension installed.
+Code Suggestions are available in Visual Studio Code when you have the GitLab Workflow extension installed. [Additional IDE extension support](https://gitlab.com/groups/gitlab-org/-/epics/10542) is planned for the near future.
 
 ## Supported languages
 
-Code Suggestions may produce [low-quality or incomplete suggestions](#model-accuracy-and-quality). The best results from Code Suggestions are expected for these languages:
+Code Suggestions may produce [low-quality or incomplete suggestions](#model-accuracy-and-quality).
+
+Language support varies depending on which AI model serves Code Suggestions. To use Code Suggestions entirely within GitLab cloud infrastructure, disable third-party AI services. To receive higher quality suggestions, [enable third-party AI services](#third-party-ai-services-controls).
 
-- C/C++
-- C#
-- Go
-- Java
-- JavaScript
-- Python
-- PHP
-- Ruby
-- Rust
-- Scala
-- TypeScript
+The best results from Code Suggestions are expected for these languages:
+
+- **Third-party AI services (Google Codey)**: Go, Google Cloud CLI, Google SQL, Java, JavaScript, Kubernetes Resource Model (KRM), Python, Terraform, TypeScript.
+- **GitLab first-party AI model**: C/C++, C#, Go, Java, JavaScript, Python, PHP, Ruby, Rust, Scala, TypeScript.
 
 Suggestions may be mixed for other languages. Using natural language code comments to request completions may also not function as expected.
 
-GitLab is continuously improving the model and expects to support an additional seven languages soon, as well as natural language code comments.
+Suggestions are best when writing new code. Editing existing functions or 'fill in the middle' of a function may not perform as expected.
+
+We are making improvements to the Code Suggestions underlying AI model weekly to improve the quality of suggestions. Please remember that AI is non-deterministic, so you may not get the same suggestion week to week.
 
 Usage of Code Suggestions is governed by the [GitLab Testing Agreement](https://about.gitlab.com/handbook/legal/testing-agreement/). Learn about [data usage when using Code Suggestions](#code-suggestions-data-usage).
 
+## Enable Code Suggestions for an individual user
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121079) in GitLab 16.1 as [Beta](/ee/policy/experiment-beta-support.md#beta).
+
+Each user can enable Code Suggestions for themselves:
+
+1. On the left sidebar, select your avatar.
+1. On the left sidebar, select **Preferences**.
+1. In the **Code Suggestions** section, select **Enable Code Suggestions**.
+1. Select **Save changes**.
+
+NOTE:
+If Code Suggestions is [enabled for the group](../../group/manage.md#enable-code-suggestions), the group setting overrides the user setting.
+
+## Enable Code Suggestions in WebIDE
+
+Prerequisites:
+
+- Code Suggestions must be [enabled for the top-level group](../../group/manage.md#enable-code-suggestions).
+- Code Suggestions must be [enabled for your user account](#enable-code-suggestions-for-an-individual-user).
+- You must be a GitLab team member.
+
+Code Suggestions work automatically in the [GitLab WebIDE](../../project/web_ide/index.md) if the above prerequisites are met. To disable Code Suggestions in the WebIDE, disable the user account setting.
+
+NOTE:
+Disabling in the WebIDE will also disable in any other IDEs you use locally like VS Code. Support for [more granular control per IDE](https://gitlab.com/groups/gitlab-org/-/epics/10624) is proposed.
+
 ## Enable Code Suggestions in VS Code
 
 Prerequisites:
 
-- Your group owner must enable the [group level code suggestions setting](../../group/manage.md#group-code-suggestions).
-- You must have [a personal access token](../../profile/personal_access_tokens.md#create-a-personal-access-token) with the `read_api` and `read_user` scopes.
+- Code Suggestions must be [enabled for the top-level group](../../group/manage.md#enable-code-suggestions).
+- Code Suggestions must be [enabled for your user account](#enable-code-suggestions-for-an-individual-user).
+- Completed the [setup instructions](https://gitlab.com/gitlab-org/gitlab-vscode-extension#setup) for the GitLab Visual Studio Code Extension.
 
 To enable Code Suggestions in VS Code:
 
-1. Download and configure the
+1. Download and install the
    [GitLab Workflow extension](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow)
    for Visual Studio Code.
-1. In **GitLab: Add Account to VS Code on Mac**, add your GitLab work account to the VS Code extension:
-   - In macOS, press <kbd>Shift</kbd> + <kbd>Command</kbd> + <kbd>P</kbd>.
-   - In Windows, press <kbd>Shift</kbd> + <kbd>Control</kbd> + <kbd>P</kbd>.
-1. Provide your GitLab instance URL. A default is provided.
-1. Provide your personal access token.
+1. Complete the [setup instructions](https://gitlab.com/gitlab-org/gitlab-vscode-extension#setup) for the extension.
 1. After your GitLab account connects successfully, in the left sidebar, select **Extensions**.
 1. Find the **GitLab workflow** extension, select **Settings** (**{settings}**), and select **Extension Settings**.
 1. Enable **GitLab > AI Assisted Code Suggestions**.
@@ -81,6 +104,51 @@ Start typing and receive suggestions for your GitLab projects.
   <iframe src="https://www.youtube-nocookie.com/embed/WnxBYxN2-p4" frameborder="0" allowfullscreen> </iframe>
 </figure>
 
+## Enable Code Suggestions in other IDEs and editors
+
+We have experimental support for Code Suggestions in Visual Studio, JetBrains, Neovim, Emacs, Sublime, etc.
+
+More details in this [blog](https://about.gitlab.com/blog/2023/06/01/extending-code-suggestions/).
+
+## Why aren't Code Suggestions displayed?
+
+If Code Suggestions are not displayed, try the following troubleshooting steps.
+
+In GitLab, ensure Code Suggestions is enabled:
+
+- [For your user account](#enable-code-suggestions-for-an-individual-user).
+- [For *all* top-level groups your account belongs to](../../group/manage.md#enable-code-suggestions). If you don't have a role that lets you view the top-level group's settings, contact a group owner.
+
+In VS Code:
+
+- Ensure [your IDE is configured properly](#enable-code-suggestions-in-vs-code).
+
+To confirm that your account is enabled, go to [https://gitlab.com/api/v4/ml/ai-assist](https://gitlab.com/api/v4/ml/ai-assist). A response of `user_is_allowed` should return `true`.
+
+### Authentication troubleshooting
+
+If the above steps do not solve your issue, the problem may be related to the recent changes in authentication, specifically the token system. To resolve the issue, please follow these troubleshooting steps:
+
+- Remove the existing PAT from your GitLab account settings.
+- Reauthorize your GitLab account in VSCode using OAuth.
+- Test the code suggestions feature with different file extensions to verify if the issue is resolved.
+
+## Third-party AI services controls
+
+Organizations can opt to use Code Suggestions entirely within GitLab cloud infrastructure. This option can be controlled with the top-level group [Third-party AI setting](../../group/manage.md#enable-third-party-ai-features).
+
+Having the third-party AI setting enabled will allow Code Suggestions to use third-party AI services, which is likely to produce higher quality results. Please note that language support varies between the two options and will change over time.
+
+To use Code Suggestions entirely within GitLab’s cloud infrastructure, disable third-party AI services. You can disable Code Suggestions entirely in [your user profile settings](#enable-code-suggestions-for-an-individual-user).
+
+## Stability and performance
+
+This feature is currently in [Beta](/ee/policy/experiment-beta-support.md#beta).
+While the Code Suggestions inference API operates completely within the GitLab.com enterprise infrastructure,
+we expect a high demand for this Beta feature, which may cause degraded performance or unexpected downtime
+of the feature. We have built this feature to gracefully degrade and have controls in place to allow us to
+mitigate abuse or misuse. GitLab may disable this feature for any or all customers at any time at our discretion.
+
 ## Code Suggestions data usage
 
 Code Suggestions is a generative artificial intelligence (AI) model hosted on GitLab.com.
@@ -89,8 +157,12 @@ Your personal access token enables a secure API connection to GitLab.com.
 This API connection securely transmits a context window from VS Code to the Code Suggestions ML model for inference,
 and the generated suggestion is transmitted back to VS Code.
 
+Depending on your settings, different ML models will be used to provide Code Suggestions. GitLab currently leverages [Google Cloud's Vertex AI Codey API models](https://cloud.google.com/vertex-ai/docs/generative-ai/code/code-models-overview) for third-party AI powered Code Suggestions. The sections below refer only to GitLab first-party AI Model.
+
 ### Data privacy
 
+This section applies only to customers who have third-party AI services disabled.
+
 Code Suggestions operate completely in the GitLab.com infrastructure, providing the same level of
 [security](https://about.gitlab.com/security/) as any other feature of GitLab.com, and processing any personal
 data in accordance with our [Privacy Statement](https://about.gitlab.com/privacy/).
@@ -103,6 +175,8 @@ Your data also never leaves GitLab.com. All training and inference is done in Gi
 
 ### Training data
 
+This section applies only to customers who have third-party AI services disabled.
+
 Code Suggestions uses open source pre-trained base models from the
 [CodeGen family](https://openreview.net/forum?id=iaYcJKpY2B_) including CodeGen-MULTI and CodeGen-NL.
 We then re-train and fine-tune these base models with a customized open source dataset to enable multi-language
@@ -111,41 +185,29 @@ programming languages from [The Pile](https://pile.eleuther.ai/) and the
 [Google BigQuery source code dataset](https://cloud.google.com/blog/topics/public-datasets/github-on-bigquery-analyze-all-the-open-source-code).
 We then process this raw dataset against heuristics that aim to increase the quality of the dataset.
 
-The Code Suggestions model is not trained on GitLab customer data.
-
-### Off by default
-
-Code Suggestions are off by default and require a group owner to enable the feature with a group-level setting.
-
-After the group-level setting is enabled, developers using Visual Studio Code with the
-[GitLab Workflow extension](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) can connect
-to GitLab.com by using a GitLab
-[personal access token](../../profile/personal_access_tokens.md#create-a-personal-access-token) with the `read_api`
-and `read_user` scopes.
+The Code Suggestions model is not trained on GitLab customer or user data.
 
 ## Progressive enhancement
 
-This feature is designed as a progressive enhancement to the existing VS Code GitLab Workflow plugin.
+This feature is designed as a progressive enhancement to developers IDEs.
 Code Suggestions offer a completion if the machine learning engine can generate a recommendation.
 In the event of a connection issue or model inference failure, the feature gracefully degrades.
-Code Suggestions do not prevent you from writing code in VS Code.
+Code Suggestions do not prevent you from writing code in your IDE.
 
 ### Internet connectivity
 
-Code Suggestions only work when you have internet connectivity and can access GitLab.com.
-Code Suggestions are not available for self-managed customers, nor customers operating within an offline environment.
+Code Suggestions does not work with offline environments.
 
-### Stability and performance
+To use Code Suggestions:
 
-This feature is currently in [Beta](/ee/policy/alpha-beta-support.md#beta).
-While the Code Suggestions inference API operates completely within the GitLab.com enterprise infrastructure,
-we expect a high demand for this Beta feature, which may cause degraded performance or unexpected downtime
-of the feature. We have built this feature to gracefully degrade and have controls in place to allow us to
-mitigate abuse or misuse. GitLab may disable this feature for any or all customers at any time at our discretion.
+- On GitLab.com, you must have an internet connection and be able to access GitLab.
+- In GitLab 16.1 and later, on self-managed GitLab, you must have an internet connection.
+
+[Self-managed support via a proxy to GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/10528) has been proposed.
 
 ### Model accuracy and quality
 
-While in Beta, Code Suggestions can generate low-quality, incomplete, and possibly insecure code.
+Regardless of whether third-party AI services are enabled, while in Beta, Code Suggestions can generate low-quality, incomplete, and possibly insecure code.
 We strongly encourage all beta users to leverage GitLab native
 [Code Quality Scanning](../../../ci/testing/code_quality.md) and
 [Security Scanning](../../application_security/index.md) capabilities.
@@ -174,6 +236,7 @@ However, Code Suggestions may generate suggestions that are:
 
 We are also aware of specific situations that can produce unexpected or incoherent results including:
 
+- Suggestions written in the middle of existing functions, or "fill in the middle."
 - Suggestions based on natural language code comments.
 - Suggestions that mixed programming languages in unexpected ways.
 
diff --git a/doc/user/project/repository/file_finder.md b/doc/user/project/repository/file_finder.md
index e22dc549a4a..dece959bdc9 100644
--- a/doc/user/project/repository/file_finder.md
+++ b/doc/user/project/repository/file_finder.md
@@ -14,8 +14,8 @@ File finder is powered by the [`fuzzaldrin-plus`](https://github.com/jeancroy/fu
 
 To search for a file:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Files**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Repository**.
 1. In the upper right, select **Find file**.
 1. In the search box, start typing the filename.
 1. From the dropdown list, select the file.
diff --git a/doc/user/project/repository/forking_workflow.md b/doc/user/project/repository/forking_workflow.md
index 74d765fa7fe..a6bb02989a3 100644
--- a/doc/user/project/repository/forking_workflow.md
+++ b/doc/user/project/repository/forking_workflow.md
@@ -54,17 +54,13 @@ or the command line. GitLab Premium and Ultimate tiers can also automate updates
 
 ### From the UI
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330243) in GitLab 15.11 [with a flag](../../../administration/feature_flags.md) named `synchronize_fork`. Disabled by default, but enabled for projects in the `gitlab-org/gitlab` and `gitlab-com/www-gitlab-com` namespaces only.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available,
-ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `synchronize_fork`.
-On GitLab.com, this feature is available for projects in the `gitlab-org/gitlab` and `gitlab-com/www-gitlab-com` namespaces.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330243) in GitLab 15.11 [with a flag](../../../administration/feature_flags.md) named `synchronize_fork`. Disabled by default, but enabled for projects in the `gitlab-org/gitlab` and `gitlab-com/www-gitlab-com` namespaces only.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/330243) in GitLab 16.0. Feature flag `synchronize_fork` removed.
 
 To update your fork from the GitLab UI:
 
-1. On the top bar, select **Main menu > Projects > View all projects**.
-1. On the secondary menu, select **Personal**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your projects**.
 1. Select the fork you want to update.
 1. Below the dropdown list for branch name, find the **Forked from** (**{fork}**)
    information box to determine if your fork is ahead, behind, or both. In this example,
@@ -185,8 +181,8 @@ To restore the fork relationship, [use the API](../../../api/projects.md#create-
 
 To remove a fork relationship:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Advanced**.
 1. In the **Remove fork relationship** section, select **Remove fork relationship**.
 1. To confirm, enter the project path and select **Confirm**.
@@ -199,7 +195,6 @@ to share objects with another repository:
 
 ## Related topics
 
-- GitLab blog post: [Keep your fork up to date with its origin](https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/)
 - GitLab community forum: [Refreshing a fork](https://forum.gitlab.com/t/refreshing-a-fork/32469)
 
 ## Troubleshooting
diff --git a/doc/user/project/repository/geojson.md b/doc/user/project/repository/geojson.md
new file mode 100644
index 00000000000..723121bc923
--- /dev/null
+++ b/doc/user/project/repository/geojson.md
@@ -0,0 +1,19 @@
+---
+stage: Create
+group: Source Code
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+type: reference
+---
+
+# GeoJSON files **(FREE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14134) in GitLab 16.1.
+
+A GeoJSON file is a format for encoding geographical data structures using JavaScript Object Notation (JSON).
+It is commonly used for representing geographic features, such as points, lines, and polygons, along with their associated attributes.
+
+When added to a repository, files with a `.geojson` extension are rendered as a map containing the GeoJSON data when viewed in GitLab.
+
+Map data comes from [OpenStreetMap](https://www.openstreetmap.org/) under the [Open Database License](https://www.openstreetmap.org/copyright).
+
+![GeoJSON file rendered as a map](img/geo_json_file_rendered_v16_1.png)
diff --git a/doc/user/project/repository/git_blame.md b/doc/user/project/repository/git_blame.md
index fbf29bddd46..baac2a788be 100644
--- a/doc/user/project/repository/git_blame.md
+++ b/doc/user/project/repository/git_blame.md
@@ -10,7 +10,16 @@ description: "Documentation on Git file blame."
 
 [Git blame](https://git-scm.com/docs/git-blame) provides more information
 about every line in a file, including the last modified time, author, and
-commit hash. To view it for a file:
+commit hash.
+
+## View blame for a file
+
+Prerequisites:
+
+- The file type must be text-based. The GitLab UI does not display
+  `git blame` results for binary files.
+
+To view the blame for a file:
 
 1. Go to your project's **Repository > Files**.
 1. Select the file you want to review.
diff --git a/doc/user/project/repository/gpg_signed_commits/index.md b/doc/user/project/repository/gpg_signed_commits/index.md
index a2dd2488961..839ab33808b 100644
--- a/doc/user/project/repository/gpg_signed_commits/index.md
+++ b/doc/user/project/repository/gpg_signed_commits/index.md
@@ -121,7 +121,7 @@ To add a GPG key to your user settings:
 1. Sign in to GitLab.
 1. In the upper-right corner, select your avatar.
 1. Select **Edit profile**.
-1. On the left sidebar, select **GPG Keys** (**{key}**).
+1. Select **GPG Keys** (**{key}**).
 1. In **Key**, paste your _public_ key.
 1. To add the key to your account, select **Add key**. GitLab shows the key's
    fingerprint, email address, and creation date:
@@ -226,11 +226,11 @@ Prerequisites:
 You can review commits for a merge request, or for an entire project:
 
 1. To review commits for a project:
-   1. On the top bar, select **Main menu > Projects** and find your project.
-   1. On the left sidebar, select **Repository > Commits**.
+   1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+   1. Select **Code > Commits**.
 1. To review commits for a merge request:
-   1. On the top bar, select **Main menu > Projects** and find your project.
-   1. On the left sidebar, select **Merge requests**, then select your merge request.
+   1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+   1. Select **Merge requests**, then select your merge request.
    1. Select **Commits**.
 1. Identify the commit you want to review. Signed commits show either a **Verified**
    or **Unverified** badge, depending on the verification status of the GPG
@@ -255,7 +255,7 @@ To revoke a GPG key:
 
 1. In the upper-right corner, select your avatar.
 1. Select **Edit profile**.
-1. On the left sidebar, select **GPG Keys** (**{key}**).
+1. Select **GPG Keys** (**{key}**).
 1. Select **Revoke** next to the GPG key you want to delete.
 
 ## Remove a GPG key
@@ -270,7 +270,7 @@ To remove a GPG key from your account:
 
 1. In the upper-right corner, select your avatar.
 1. Select **Edit profile**.
-1. On the left sidebar, select **GPG Keys** (**{key}**).
+1. Select **GPG Keys** (**{key}**).
 1. Select **Remove** (**{remove}**) next to the GPG key you want to delete.
 
 If you must unverify both future and past commits,
diff --git a/doc/user/project/repository/img/geo_json_file_rendered_v16_1.png b/doc/user/project/repository/img/geo_json_file_rendered_v16_1.png
new file mode 100644
index 00000000000..b67a7bc3fda
--- /dev/null
+++ b/doc/user/project/repository/img/geo_json_file_rendered_v16_1.png
diff --git a/doc/user/project/repository/jupyter_notebooks/index.md b/doc/user/project/repository/jupyter_notebooks/index.md
index 1526c7b4dc2..d3d9b202e63 100644
--- a/doc/user/project/repository/jupyter_notebooks/index.md
+++ b/doc/user/project/repository/jupyter_notebooks/index.md
@@ -25,7 +25,7 @@ GitLab.
 
 ## Cleaner diffs and raw diffs
 
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6589) in GitLab 14.5 as an [Experiment](../../../../policy/alpha-beta-support.md#experiment) release [with a flag](../../../../administration/feature_flags.md) named `jupyter_clean_diffs`. Enabled by default.
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6589) in GitLab 14.5 as an [Experiment](../../../../policy/experiment-beta-support.md#experiment) release [with a flag](../../../../administration/feature_flags.md) named `jupyter_clean_diffs`. Enabled by default.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75500) in GitLab 14.9. Feature flag `jupyter_clean_diffs` removed.
 > - [Reintroduced toggle](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85079) in GitLab 15.0 [with a flag](../../../../administration/feature_flags.md) named `ipynb_semantic_diff`. Enabled by default.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95373) in GitLab 15.6. Feature flag `ipynb_semantic_diff` removed.
diff --git a/doc/user/project/repository/mirror/bidirectional.md b/doc/user/project/repository/mirror/bidirectional.md
index 0563f747e8d..550d4535adb 100644
--- a/doc/user/project/repository/mirror/bidirectional.md
+++ b/doc/user/project/repository/mirror/bidirectional.md
@@ -44,7 +44,7 @@ and [pull](pull.md#pull-from-a-remote-repository) mirrors in the upstream GitLab
 To create the webhook in the downstream instance:
 
 1. Create a [personal access token](../../../profile/personal_access_tokens.md) with `API` scope.
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. On the left sidebar, select **Settings > Webhooks**.
 1. Add the webhook **URL**, which (in this case) uses the
    [Pull Mirror API](../../../../api/projects.md#start-the-pull-mirroring-process-for-a-project)
diff --git a/doc/user/project/repository/mirror/index.md b/doc/user/project/repository/mirror/index.md
index 9f72b8f29b2..733310a0b4d 100644
--- a/doc/user/project/repository/mirror/index.md
+++ b/doc/user/project/repository/mirror/index.md
@@ -34,14 +34,14 @@ Mirror a repository when:
 
 ## Create a repository mirror
 
-Prerequisite:
+Prerequisites:
 
 - You must have at least the Maintainer role for the project.
 - If your mirror connects with `ssh://`, the host key must be detectable on the server,
   or you must have a local copy of the key.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Mirroring repositories**.
 1. Enter a **Git repository URL**. For security reasons, the URL to the original
    repository is only displayed to users with the Maintainer role
@@ -59,13 +59,38 @@ Prerequisite:
 1. If you authenticate with SSH host keys, [verify the host key](#verify-a-host-key)
    to ensure it is correct.
 1. To prevent force-pushing over diverged refs, select [**Keep divergent refs**](push.md#keep-divergent-refs).
-1. Optional. Select [**Mirror only protected branches**](#mirror-only-protected-branches).
+1. Optional. To limit the number of branches mirrored, select
+   **Mirror only protected branches** or enter a regex in **Mirror specific branches**.
 1. Select **Mirror repository**.
 
 If you select `SSH public key` as your authentication method, GitLab generates a
 public key for your GitLab repository. You must provide this key to the non-GitLab server.
 For more information, see [Get your SSH public key](#get-your-ssh-public-key).
 
+### Mirror only protected branches
+
+You can choose to mirror only the
+[protected branches](../../protected_branches.md) in the mirroring project,
+either from or to your remote repository. For [pull mirroring](pull.md),
+non-protected branches in the mirroring project are not mirrored and can diverge.
+
+To use this option, select **Only mirror protected branches** when you create a repository mirror.
+
+### Mirror specific branches **(PREMIUM)**
+
+> - Mirroring branches matching a regex [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/102608) in GitLab 15.8 [with a flag](../../../../administration/feature_flags.md) named `mirror_only_branches_match_regex`. Disabled by default.
+> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/381667) in GitLab 16.0.
+
+FLAG:
+On self-managed GitLab, by default the field `mirror_branch_regex` is available.
+To hide the feature, ask an administrator to [disable the feature flag](../../../../administration/feature_flags.md)
+named `mirror_only_branches_match_regex`.
+On GitLab.com, this feature is available.
+
+To mirror only branches with names matching an [re2 regular expression](https://github.com/google/re2/wiki/Syntax),
+enter a regular expression into the **Mirror specific branches** field. Branches with names that
+do not match the regular expression are not mirrored.
+
 ## Update a mirror
 
 When the mirror repository is updated, all new branches, tags, and commits are visible in the
@@ -88,37 +113,13 @@ Prerequisite:
 
 - You must have at least the Maintainer role for the project.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Mirroring repositories**.
 1. Scroll to **Mirrored repositories** and identify the mirror to update.
 1. Select **Update now** (**{retry}**):
    ![Repository mirroring force update user interface](img/repository_mirroring_force_update.png)
 
-## Mirror only protected branches
-
-You can choose to mirror only the
-[protected branches](../../protected_branches.md) in the mirroring project,
-either from or to your remote repository. For [pull mirroring](pull.md),
-non-protected branches in the mirroring project are not mirrored and can diverge.
-
-To use this option, select **Only mirror protected branches** when you create a repository mirror.
-
-## Mirror specific branches
-
-> - Mirroring branches matching a regex [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/102608) in GitLab 15.8 [with a flag](../../../../administration/feature_flags.md) named `mirror_only_branches_match_regex`. Disabled by default.
-> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/381667) in GitLab 16.0.
-
-FLAG:
-On self-managed GitLab, by default the field `mirror_branch_regex` is available.
-To hide the feature, ask an administrator to [disable the feature flag](../../../../administration/feature_flags.md)
-named `mirror_only_branches_match_regex`.
-On GitLab.com, this feature is available.
-
-To mirror only branches with names matching an [re2 regular expression](https://github.com/google/re2/wiki/Syntax),
-enter a regular expression into the **Mirror specific branches** field. Branches with names that
-do not match the regular expression are not mirrored.
-
 ## Authentication methods for mirrors
 
 When you create a mirror, you must configure the authentication method for it.
@@ -155,8 +156,8 @@ When you mirror a repository and select the **SSH public key** as your
 authentication method, GitLab generates a public key for you. The non-GitLab server
 needs this key to establish trust with your GitLab repository. To copy your SSH public key:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Mirroring repositories**.
 1. Scroll to **Mirrored repositories**.
 1. Identify the correct repository, and select **Copy SSH public key** (**{copy-to-clipboard}**).
@@ -183,6 +184,7 @@ for you to check:
 
 - [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/regions.html#regions-fingerprints)
 - [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/configure-ssh-and-two-step-verification/)
+- [Codeberg](https://docs.codeberg.org/security/ssh-fingerprint/)
 - [GitHub](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints)
 - [GitLab.com](../../../gitlab_com/index.md#ssh-host-keys-fingerprints)
 - [Launchpad](https://help.launchpad.net/SSHFingerprints)
@@ -263,8 +265,8 @@ If you receive this error after creating a new project using
 
 Check if the repository owner is specified in the URL of your mirrored repository:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Mirroring repositories**.
 1. If no repository owner is specified, delete and add the URL again in this format,
    replacing `OWNER`, `ACCOUNTNAME`, `PATH_TO_REPO`, and `REPONAME` with your values:
@@ -344,8 +346,8 @@ Prerequisites:
 To resolve the issue:
 
 1. [Verify the host key](#verify-a-host-key).
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Mirroring repositories**.
 1. To refresh the keys, either:
 
diff --git a/doc/user/project/repository/mirror/pull.md b/doc/user/project/repository/mirror/pull.md
index 2b8470b9e3d..1463e0de0f1 100644
--- a/doc/user/project/repository/mirror/pull.md
+++ b/doc/user/project/repository/mirror/pull.md
@@ -60,8 +60,8 @@ Prerequisite:
   with the `repo` scope. If 2FA is enabled, this personal access
   token serves as your GitHub password.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Mirroring repositories**.
 1. Enter the **Git repository URL**. Include the username
    in the URL, if required: `https://MYUSERNAME@gitlab.com/GROUPNAME/PROJECTNAME.git`
diff --git a/doc/user/project/repository/mirror/push.md b/doc/user/project/repository/mirror/push.md
index 11093958650..9da8ce7acc5 100644
--- a/doc/user/project/repository/mirror/push.md
+++ b/doc/user/project/repository/mirror/push.md
@@ -34,8 +34,8 @@ displays an error.
 
 To set up push mirroring for an existing project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Mirroring repositories**.
 1. Enter a repository URL.
 1. In the **Mirror direction** dropdown list, select **Push**.
@@ -79,8 +79,15 @@ To configure a mirror from GitLab to GitHub:
 
 1. Create a [GitHub personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)
    with `public_repo` selected.
-1. Enter a **Git repository URL** with this format:
-   `https://<your_access_token>@github.com/<github_group>/<github_project>.git`.
+1. Enter a **Git repository URL** with this format, changing the variables as needed:
+
+   ```plaintext
+   https://USERNAME@github.com/GROUP/PROJECT.git
+   ```
+
+   - `USERNAME`: The username of the owner of the personal access token.
+   - `GROUP`: The group on GitHub.
+   - `PROJECT`: The project on GitHub.
 1. For **Password**, enter your GitHub personal access token.
 1. Select **Mirror repository**.
 
@@ -149,7 +156,7 @@ To set up a mirror from GitLab to AWS CodeCommit:
 1. In the AWS CodeCommit console, create a new repository to mirror from your GitLab repository.
 1. Open your new repository, and then select **Clone URL > Clone HTTPS** (not **Clone HTTPS (GRC)**).
 1. In GitLab, open the repository to be push-mirrored.
-1. On the left sidebar, select **Settings > Repository**, and then expand **Mirroring repositories**.
+1. Select **Settings > Repository**, and then expand **Mirroring repositories**.
 1. Fill in the **Git repository URL** field using this format:
 
    ```plaintext
diff --git a/doc/user/project/repository/push_rules.md b/doc/user/project/repository/push_rules.md
index 28afba375fc..fbadc9b84a3 100644
--- a/doc/user/project/repository/push_rules.md
+++ b/doc/user/project/repository/push_rules.md
@@ -19,6 +19,7 @@ can and can't be pushed to your repository. While GitLab offers
 
 GitLab uses [RE2 syntax](https://github.com/google/re2/wiki/Syntax) for regular expressions
 in push rules. You can test them at the [regex101 regex tester](https://regex101.com/).
+Each regular expression is limited to 255 characters.
 
 For custom push rules use [server hooks](../../../administration/server_hooks.md).
 
@@ -36,8 +37,9 @@ Prerequisite:
 
 To create global push rules:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Push Rules**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Push Rules**.
 1. Expand **Push rules**.
 1. Set the rule you want.
 1. Select **Save push rules**.
@@ -48,8 +50,8 @@ The push rule of an individual project overrides the global push rule.
 To override global push rules for a specific project, or to update the rules
 for an existing project to match new global push rules:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Repository**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Repository**.
 1. Expand **Push rules**.
 1. Set the rule you want.
 1. Select **Save push rules**.
diff --git a/doc/user/project/repository/reducing_the_repo_size_using_git.md b/doc/user/project/repository/reducing_the_repo_size_using_git.md
index 4bebe4c1a97..ce3a5ee9916 100644
--- a/doc/user/project/repository/reducing_the_repo_size_using_git.md
+++ b/doc/user/project/repository/reducing_the_repo_size_using_git.md
@@ -1,6 +1,6 @@
 ---
-stage: Systems
-group: Gitaly
+stage: Create
+group: Source Code
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
@@ -74,7 +74,7 @@ To purge files from a GitLab repository:
 1. Clone a fresh copy of the repository from the bundle using  `--bare` and `--mirror` options:
 
    ```shell
-   git clone --bare /path/to/project.bundle
+   git clone --bare --mirror /path/to/project.bundle
    ```
 
 1. Go to the `project.git` directory:
@@ -134,6 +134,12 @@ To purge files from a GitLab repository:
    Repeat this step and all following steps (including the [repository cleanup](#repository-cleanup) step)
    every time you run any `git filter-repo` command.
 
+1. To allow you to force push the changes you need to unset the mirror flag:
+
+   ```shell
+    git config --unset remote.origin.mirror
+   ```
+
 1. Force push your changes to overwrite all branches on GitLab:
 
    ```shell
@@ -160,13 +166,13 @@ To purge files from a GitLab repository:
 
    Refer to the Git [`replace`](https://git-scm.com/book/en/v2/Git-Tools-Replace) documentation for information on how this works.
 
-1. Wait at least 30 minutes, because the repository cleanup process only processes object older than 30 minutes.
-1. Run [repository cleanup](#repository-cleanup).
+1. Wait at least 30 minutes before attempting the next step.
+1. Run [repository cleanup](#repository-cleanup). This process only cleans up objects
+   that are more than 30 minutes old. See [Space not being freed](#space-not-being-freed)
+   for more information.
 
 ## Repository cleanup
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/19376) in GitLab 11.6.
-
 Repository cleanup allows you to upload a text file of objects and GitLab removes internal Git
 references to these objects. You can use
 [`git filter-repo`](https://github.com/newren/git-filter-repo) to produce a list of objects (in a
@@ -178,6 +184,10 @@ of the operation. This happens automatically, but submitting the cleanup request
 fails if any writes are ongoing, so cancel any outstanding `git push`
 operations before continuing.
 
+WARNING:
+Removing internal Git references results in associated merge request commits, pipelines, and changes details
+no longer being available.
+
 To clean up a repository:
 
 1. Go to the project for the repository.
@@ -300,3 +310,17 @@ end
 
 puts "#{artifact_storage} bytes"
 ```
+
+### Space not being freed
+
+The process defined on this page can decrease the size of repository exports
+decreasing, but the usage in the file system appearing unchanged in both the Web UI and terminal.
+
+The process leaves many unreachable objects remaining in the repository.
+Because they are unreachable, they are not included in the export, but they are
+still stored in the file system. These files are pruned after a grace period of
+two weeks. Pruning deletes these files and ensures your storage usage statistics
+are accurate.
+
+To expedite this process, see the
+['Prune Unreachable Objects' housekeeping task](../../../administration/housekeeping.md).
diff --git a/doc/user/project/repository/ssh_signed_commits/index.md b/doc/user/project/repository/ssh_signed_commits/index.md
index f2ce80263c8..8f29845fd9b 100644
--- a/doc/user/project/repository/ssh_signed_commits/index.md
+++ b/doc/user/project/repository/ssh_signed_commits/index.md
@@ -93,10 +93,10 @@ You can review commits for a merge request, or for an entire project, to confirm
 they are signed:
 
 1. To review commits for a project:
-   1. On the top bar, select **Main menu > Projects** and find your project.
-   1. On the left sidebar, select **Repository > Commits**.
+   1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+   1. Select **Code > Commits**.
 1. To review commits for a merge request:
-   1. On the top bar, select **Main menu > Projects** and find your project.
+   1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
    1. On the left sidebar, select **Merge requests**, then select your merge request.
    1. Select **Commits**.
 1. Identify the commit you want to review. Signed commits show either a **Verified**
diff --git a/doc/user/project/repository/tags/index.md b/doc/user/project/repository/tags/index.md
index e252a9a433b..8c6774408e6 100644
--- a/doc/user/project/repository/tags/index.md
+++ b/doc/user/project/repository/tags/index.md
@@ -44,15 +44,15 @@ In the GitLab UI, each tag displays:
 
 To view all existing tags for a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Tags**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Tags**.
 
 ## View tagged commits in the commits list
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18795) in GitLab 15.10.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Commits**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Commits**.
 1. Commits with a tag are labeled with a tag icon (**{tag}**) and the name of the tag.
    This example shows a commit tagged `v1.26.0`:
 
@@ -88,8 +88,8 @@ To create either a lightweight or annotated tag from the command line, and push
 
 To create a tag from the GitLab UI:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Tags**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Tags**.
 1. Select **New tag**.
 1. Provide a **Tag name**.
 1. For **Create from**, select an existing branch name, tag, or commit SHA.
diff --git a/doc/user/project/repository/web_editor.md b/doc/user/project/repository/web_editor.md
index dc988846676..7b2dcd04982 100644
--- a/doc/user/project/repository/web_editor.md
+++ b/doc/user/project/repository/web_editor.md
@@ -25,7 +25,7 @@ for any change you commit through the Web Editor.
 
 To create a text file in the Web Editor:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. From the project dashboard or repository, next to the branch name,
    select the plus icon (**{plus}**).
 1. From the dropdown list, select **New file**.
@@ -35,8 +35,8 @@ To create a text file in the Web Editor:
 
 ### Create a file from a template
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Repository > Files**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Repository**.
 1. Next to the project name, select the plus icon (**{plus}**) to display a
    dropdown list, then select **New file** from the list.
 1. For **Filename**, provide one of the filenames that GitLab provides a template for:
@@ -56,15 +56,9 @@ To create a text file in the Web Editor:
 
 To edit a text file in the Web Editor:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Go to your file.
-1. In the upper-right corner of the file, select **Edit**.
-
-   If **Edit** is not visible:
-
-   1. Next to **Open in Web IDE** or **Open in Gitpod**, select the down arrow (**{chevron-lg-down}**).
-   1. From the dropdown list, select **Edit** as your default setting.
-   1. Select **Edit**.
+1. In the upper right, select **Edit > Edit single file**.
 
 ### Keyboard shortcuts
 
@@ -111,7 +105,7 @@ To upload a binary file in the Web Editor:
 <!-- This list is duplicated at doc/gitlab-basics/add-file.md#from-the-ui -->
 <!-- For why we duplicated the info, see https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111072#note_1267429478 -->
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. From the project dashboard or repository, next to the branch name, select the plus icon (**{plus}**).
 1. From the dropdown list, select **Upload file**.
 1. Complete the fields. To create a merge request with the uploaded file, ensure the **Start a new merge request with these changes** toggle is turned on.
@@ -121,7 +115,7 @@ To upload a binary file in the Web Editor:
 
 To create a directory in the Web Editor:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. From the project dashboard or repository, next to the branch name, select the plus icon (**{plus}**).
 1. From the dropdown list, select **New directory**.
 1. Complete the fields. To create a merge request with the new directory, ensure the **Start a new merge request with these changes** toggle is turned on.
@@ -131,7 +125,7 @@ To create a directory in the Web Editor:
 
 To create a [branch](branches/index.md) in the Web Editor:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. From the project dashboard or repository, next to the branch name, select the plus icon (**{plus}**).
 1. From the dropdown list, select **New branch**.
 1. Complete the fields.
@@ -142,7 +136,7 @@ To create a [branch](branches/index.md) in the Web Editor:
 You can create [tags](tags/index.md) to mark milestones such as
 production releases and release candidates. To create a tag in the Web Editor:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. From the project dashboard or repository, next to the branch name, select the plus icon (**{plus}**).
 1. From the dropdown list, select **New tag**.
 1. Complete the fields.
diff --git a/doc/user/project/service_desk.md b/doc/user/project/service_desk.md
index bd5c8214e68..8d525965f96 100644
--- a/doc/user/project/service_desk.md
+++ b/doc/user/project/service_desk.md
@@ -54,11 +54,13 @@ Prerequisites:
   [email sub-addressing](../../administration/incoming_email.md#email-sub-addressing),
   but you can also use [catch-all mailboxes](../../administration/incoming_email.md#catch-all-mailbox).
   To do this, you must have administrator access.
+- You must have enabled [issue](settings/index.md#configure-project-visibility-features-and-permissions)
+  tracker for the project.
 
 To enable Service Desk in your project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Service Desk**.
 1. Turn on the **Activate Service Desk** toggle.
 1. Optional. Complete the fields.
@@ -101,7 +103,8 @@ visible in the email template. For more information, see
 
 #### Thank you email
 
-> `%{ISSUE_DESCRIPTION}` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223751) in GitLab 16.0.
+> - `%{ISSUE_DESCRIPTION}` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223751) in GitLab 16.0.
+> - `%{ISSUE_URL}` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/408793) in GitLab 16.1.
 
 When a user submits an issue through Service Desk, GitLab sends a **thank you email**.
 
@@ -110,20 +113,23 @@ directory in your repository, create a file named `thank_you.md`.
 
 You can use these placeholders to be automatically replaced in each email:
 
-- `%{ISSUE_ID}`: issue IID
-- `%{ISSUE_PATH}`: project path appended with the issue IID
-- `%{ISSUE_DESCRIPTION}`: issue description based on the original email
-- `%{UNSUBSCRIBE_URL}`: unsubscribe URL
-- `%{SYSTEM_HEADER}`: [system header message](../admin_area/appearance.md#system-header-and-footer-messages)
-- `%{SYSTEM_FOOTER}`: [system footer message](../admin_area/appearance.md#system-header-and-footer-messages)
-- `%{ADDITIONAL_TEXT}`: [custom additional text](../admin_area/settings/email.md#custom-additional-text)
+- `%{ISSUE_ID}`: Issue IID.
+- `%{ISSUE_PATH}`: Project path appended with the issue IID.
+- `%{ISSUE_URL}`: URL to the issue. External participants can only view the issue if the project is public
+   and issue is not confidential (Service Desk issues are confidential by default).
+- `%{ISSUE_DESCRIPTION}`: Issue description based on the original email.
+- `%{UNSUBSCRIBE_URL}`: Unsubscribe URL.
+- `%{SYSTEM_HEADER}`: [System header message](../admin_area/appearance.md#system-header-and-footer-messages).
+- `%{SYSTEM_FOOTER}`: [System footer message](../admin_area/appearance.md#system-header-and-footer-messages).
+- `%{ADDITIONAL_TEXT}`: [Custom additional text](../admin_area/settings/email.md#custom-additional-text).
 
 Because Service Desk issues are created as [confidential](issues/confidential_issues.md) (only project members can see them),
 the response email does not contain the issue link.
 
 #### New note email
 
-> `%{ISSUE_DESCRIPTION}` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223751) in GitLab 16.0.
+> - `%{ISSUE_DESCRIPTION}` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223751) in GitLab 16.0.
+> - `%{ISSUE_URL}` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/408793) in GitLab 16.1.
 
 When a user-submitted issue receives a new comment, GitLab sends a **new note email**.
 
@@ -132,17 +138,19 @@ directory in your repository, create a file named `new_note.md`.
 
 You can use these placeholders to be automatically replaced in each email:
 
-- `%{ISSUE_ID}`: issue IID
-- `%{ISSUE_PATH}`: project path appended with the issue IID
-- `%{ISSUE_DESCRIPTION}`: issue description at the time email is generated.
+- `%{ISSUE_ID}`: Issue IID.
+- `%{ISSUE_PATH}`: Project path appended with the issue IID.
+- `%{ISSUE_URL}`: URL to the issue. External participants can only view the issue if the project is public
+   and issue is not confidential (Service Desk issues are confidential by default).
+- `%{ISSUE_DESCRIPTION}`: Issue description at the time email is generated.
   If a user has edited the description, it might contain sensitive information that is not intended
   to be delivered to external participants. Use this placeholder only if you never modify
   descriptions or your team is aware of the template design.
-- `%{NOTE_TEXT}`: note text
-- `%{UNSUBSCRIBE_URL}`: unsubscribe URL
-- `%{SYSTEM_HEADER}`: [system header message](../admin_area/appearance.md#system-header-and-footer-messages)
-- `%{SYSTEM_FOOTER}`: [system footer message](../admin_area/appearance.md#system-header-and-footer-messages)
-- `%{ADDITIONAL_TEXT}`: [custom additional text](../admin_area/settings/email.md#custom-additional-text)
+- `%{NOTE_TEXT}`: Note text.
+- `%{UNSUBSCRIBE_URL}`: Unsubscribe URL.
+- `%{SYSTEM_HEADER}`: [System header message](../admin_area/appearance.md#system-header-and-footer-messages).
+- `%{SYSTEM_FOOTER}`: [System footer message](../admin_area/appearance.md#system-header-and-footer-messages).
+- `%{ADDITIONAL_TEXT}`: [Custom additional text](../admin_area/settings/email.md#custom-additional-text).
 
 ### Use a custom template for Service Desk issues
 
@@ -163,8 +171,8 @@ Prerequisite:
 
 To use a custom description template with Service Desk:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Service Desk**.
 1. From the dropdown list **Template to append to all Service Desk issues**, search or select your template.
 
@@ -174,6 +182,11 @@ Behind the scenes, Service Desk works by the special Support Bot user creating i
 This user isn't a [billable user](../../subscriptions/self_managed/index.md#billable-users),
 so it does not count toward the license limit count.
 
+In GitLab 16.0 and earlier, comments generated from Service Desk emails show `GitLab Support Bot`
+as the author. In [GitLab 16.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/226995),
+these comments show the email of the user who sent the email.
+This feature only applies to comments made in GitLab 16.1 and later.
+
 #### Change the Support Bot's display name
 
 You can change the display name of the Support Bot user. Emails sent from Service Desk have
@@ -181,8 +194,8 @@ this name in the `From` header. The default display name is `GitLab Support Bot`
 
 To edit the custom email display name:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Service Desk**.
 1. Below **Email display name**, enter a new name.
 1. Select **Save changes**.
@@ -225,9 +238,10 @@ To configure a custom mailbox for Service Desk with IMAP, add the following snip
 
 NOTE:
 In GitLab 15.3 and later, Service Desk uses `webhook` (internal API call) by default instead of enqueuing a Sidekiq job.
-To use `webhook` on an Omnibus installation running GitLab 15.3, you must generate a secret file.
+To use `webhook` on a Linux package installation running GitLab 15.3, you must generate a secret file.
 For more information, see [merge request 5927](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5927).
-In GitLab 15.4, reconfiguring an Omnibus installation generates this secret file automatically, so no secret file configuration setting is needed.
+In GitLab 15.4, reconfiguring a Linux package installation generates this secret file automatically, so no
+secret file configuration setting is needed.
 For more information, see [issue 1462](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1462).
 
 ```ruby
@@ -406,7 +420,7 @@ Service Desk can be configured to read Microsoft Exchange Online mailboxes with
 Graph API instead of IMAP. Set up an OAuth 2.0 application for Microsoft Graph
 [the same way as for incoming email](../../administration/incoming_email.md#microsoft-graph).
 
-- Example for Omnibus GitLab installations:
+- Example for Linux package installations:
 
   ```ruby
   gitlab_rails['service_desk_email_enabled'] = true
@@ -455,8 +469,8 @@ Prerequisites:
 
 - You must have configured a [custom mailbox](#configure-a-custom-mailbox).
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Service Desk**.
 1. Below **Email address suffix**, enter the suffix to use.
 1. Select **Save changes**.
@@ -472,6 +486,138 @@ The [incoming email](../../administration/incoming_email.md) address still works
 If you don't configure a custom suffix, the default project identification is used for identifying
 the project.
 
+### Configure email ingestion in multi-node environments
+
+A multi-node environment is a setup where GitLab is run across multiple servers
+for scalability, fault tolerance, and performance reasons.
+
+GitLab uses a separate process called `mail_room` to ingest new unread emails
+from the `incoming_email` and `service_desk_email` mailboxes.
+
+#### Helm chart (Kubernetes)
+
+The [GitLab Helm chart](https://docs.gitlab.com/charts/) is made up of multiple subcharts, and one of them is
+the [Mailroom subchart](https://docs.gitlab.com/charts/charts/gitlab/mailroom/index.html). Configure the
+[common settings for `incoming_email`](https://docs.gitlab.com/charts/installation/command-line-options.html#incoming-email-configuration)
+and the [common settings for `service_desk_email`](https://docs.gitlab.com/charts/installation/command-line-options.html#service-desk-email-configuration).
+
+#### Linux package (Omnibus)
+
+In multi-node Linux package installation environments, run `mail_room` only on one node. Run it either on a single
+`rails` node (for example, `application_role`)
+or completely separately.
+
+##### Set up all nodes
+
+1. Add basic configuration for `incoming_email` and `service_desk_email` on every node
+   to render email addresses in the web UI and in generated emails.
+
+   Find the `incoming_email` or `service_desk_email` section in `/etc/gitlab/gitlab.rb`:
+
+   ::Tabs
+
+   :::TabTitle `incoming_email`
+
+   ```ruby
+   gitlab_rails['incoming_email_enabled'] = true
+   gitlab_rails['incoming_email_address'] = "incoming+%{key}@example.com"
+   ```
+
+   :::TabTitle `service_desk_email`
+
+   ```ruby
+   gitlab_rails['service_desk_email_enabled'] = true
+   gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.com"
+   ```
+
+   ::EndTabs
+
+1. GitLab offers two methods to transport emails from `mail_room` to the GitLab
+application. You can configure the `delivery_method` for each email setting individually:
+   1. Recommended: `webhook` (default in GitLab 15.3 and later) sends the email payload via an API POST request to your GitLab
+      application. It uses a shared token to authenticate. If you choose this method,
+      make sure the `mail_room` process can access the API endpoint and distribute the shared
+      token across all application nodes.
+
+      ::Tabs
+
+      :::TabTitle `incoming_email`
+
+      ```ruby
+      gitlab_rails['incoming_email_delivery_method'] = "webhook"
+
+      # The URL that mail_room can contact. You can also use an internal URL or IP,
+      # just make sure mail_room can access the GitLab API via that address.
+      # Do not end with "/".
+      gitlab_rails['incoming_email_gitlab_url'] = "https://gitlab.example.com"
+
+      # The shared secret file that should contain a random token. Make sure it's the same on every node.
+      gitlab_rails['incoming_email_secret_file'] = ".gitlab_mailroom_secret"
+      ```
+
+      :::TabTitle `service_desk_email`
+
+      ```ruby
+      gitlab_rails['service_desk_email_delivery_method'] = "webhook"
+
+      # The URL that mail_room can contact. You can also use an internal URL or IP,
+      # just make sure mail_room can access the GitLab API via that address.
+      # Do not end with "/".
+
+      gitlab_rails['service_desk_email_gitlab_url'] = "https://gitlab.example.com"
+
+      # The shared secret file that should contain a random token. Make sure it's the same on every node.
+      gitlab_rails['service_desk_email_secret_file'] = ".gitlab_mailroom_secret"
+      ```
+
+      ::EndTabs
+
+   1. [Deprecated in GitLab 16.0 and planned for removal in 17.0)](../../update/deprecations.md#sidekiq-delivery-method-for-incoming_email-and-service_desk_email-is-deprecated):
+      If you experience issues with the `webhook` setup, use `sidekiq` to deliver the email payload directly to GitLab Sidekiq using Redis.
+
+      ::Tabs
+
+      :::TabTitle `incoming_email`
+
+      ```ruby
+      # It uses the Redis configuration to directly add Sidekiq jobs
+      gitlab_rails['incoming_email_delivery_method'] = "sidekiq"
+      ```
+
+      :::TabTitle `service_desk_email`
+
+      ```ruby
+      # It uses the Redis configuration to directly add Sidekiq jobs
+      gitlab_rails['service_desk_email_delivery_method'] = "sidekiq"
+      ```
+
+      ::EndTabs
+
+1. Disable `mail_room` on all nodes that should not run email ingestion. For example, in `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   mailroom['enabled'] = false
+   ```
+
+1. [Reconfigure GitLab](../../administration/restart_gitlab.md) for the changes to take effect.
+
+##### Set up a single email ingestion node
+
+After setting up all nodes and disabling the `mail_room` process, enable `mail_room` on a single node.
+This node polls the mailboxes for `incoming_email` and `service_desk_email` on a regular basis and
+move new unread emails to GitLab.
+
+1. Choose an existing node that additionally handles email ingestion.
+1. Add [full configuration and credentials](../../administration/incoming_email.md#configuration-examples)
+   for `incoming_email` and `service_desk_email`.
+1. Enable `mail_room` on this node. For example, in `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   mailroom['enabled'] = true
+   ```
+
+1. [Reconfigure GitLab](../../administration/restart_gitlab.md) on this node for the changes to take effect.
+
 ## Use Service Desk
 
 You can use Service Desk to [create an issue](#as-an-end-user-issue-creator) or [respond to one](#as-a-responder-to-the-issue).
@@ -481,8 +627,8 @@ In these issues, you can also see our friendly neighborhood [Support Bot](#suppo
 
 To check what the Service Desk email address is for your project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues > Service Desk**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Service Desk**.
 
 The email address is available at the top of the issue list.
 
@@ -533,8 +679,8 @@ Prerequisites:
 
 To view Service Desk issues:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues > Service Desk**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Monitor > Service Desk**.
 
 ### Email contents and formatting
 
@@ -570,7 +716,7 @@ In GitLab 15.9 and earlier, uploads to a comment are sent as links in the email.
 
 Service Desk issues are [confidential](issues/confidential_issues.md), so they are
 only visible to project members. The project owner can
-[make an issue public](issues/confidential_issues.md#modify-issue-confidentiality).
+[make an issue public](issues/confidential_issues.md#in-an-existing-issue).
 When a Service Desk issue becomes public, the issue creator's and participants' email addresses are
 visible to signed-in users with at least the Reporter role for the project.
 
diff --git a/doc/user/project/settings/import_export.md b/doc/user/project/settings/import_export.md
index 958246908bc..6cc2b51f077 100644
--- a/doc/user/project/settings/import_export.md
+++ b/doc/user/project/settings/import_export.md
@@ -86,8 +86,9 @@ Before you can migrate projects on a self-managed GitLab instance using file exp
 
 To enable file exports as an import source for the destination instance:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
 1. Expand **Visibility and access controls**.
 1. Scroll to **Import sources**.
 1. Select the **GitLab export** checkbox.
@@ -112,8 +113,8 @@ Prerequisites:
 
 To export a project and its data, follow these steps:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Advanced**.
 1. Select **Export project**.
 1. After the export is generated, you should receive an email with a link to download the file.
@@ -181,6 +182,8 @@ Items that are **not** exported include:
 - Secure files
 - [Activity logs for Git-related events](https://gitlab.com/gitlab-org/gitlab/-/issues/214700) (for example, pushing and creating tags)
 - Security policies associated with your project
+- Links between issues and linked items
+- Links to related merge requests
 
 Migrating projects with file exports uses the same export and import mechanisms as creating projects from templates at the [group](../../group/custom_project_templates.md) and
 [instance](../../admin_area/custom_project_templates.md) levels. Therefore, the list of exported items is the same.
diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md
index f89c2a1eaaa..8deb05c45ef 100644
--- a/doc/user/project/settings/index.md
+++ b/doc/user/project/settings/index.md
@@ -13,8 +13,8 @@ Use the **Settings** page to manage the configuration options in your [project](
 
 You must have at least the Maintainer role to view project settings.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. To display all settings in a section, select **Expand**.
 1. Optional. Use the search box to find a setting.
 
@@ -23,8 +23,8 @@ You must have at least the Maintainer role to view project settings.
 Use the project general settings to edit your project details.
 
 1. Sign in to GitLab with at least the Maintainer role.
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. In the **Project name** text box, enter your project name.
 1. In the **Project description** text box, enter your project description.
 1. Under **Project avatar**, to change your project avatar, select **Choose file**.
@@ -35,8 +35,8 @@ Use topics to categorize projects and find similar new projects.
 
 To assign topics to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings** > **General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings** > **General**.
 1. In the **Topics** text box, enter the project topics. Popular topics are suggested as you type.
 1. Select **Save changes**.
 
@@ -49,9 +49,9 @@ If you're an instance administrator, you can administer all project topics from
 compliance framework using either:
 
 - The GitLab UI:
-  1. On the top bar, select **Main menu > Projects > View all projects** and find your project.
-  1. On the left sidebar, select **Settings** > **General**.
-  1. Expand the **Compliance frameworks** section.
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+  1. Select **Settings** > **General**.
+  1. Expand **Compliance frameworks**.
   1. Select a compliance framework.
   1. Select **Save changes**.
 - In [GitLab 14.2](https://gitlab.com/gitlab-org/gitlab/-/issues/333249) and later, using the
@@ -59,13 +59,16 @@ compliance framework using either:
   compliance frameworks on subgroups with GraphQL, the framework is created on the root ancestor if the user has the
   correct permissions. The GitLab UI presents a read-only view to discourage this behavior.
 
+NOTE:
+Frameworks can not be added to projects in personal namespaces.
+
 ## Configure project visibility, features, and permissions
 
 To configure visibility, features, and permissions for a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Visibility, project features, permissions** section.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
+1. Expand **Visibility, project features, permissions**.
 1. To change the project visibility, select the dropdown list. If you select to **Public**, you limit access to some features to **Only Project Members**.
 1. To allow users to request access to the project, select the **Users can request access** checkbox.
 1. Use the [toggles](#project-feature-settings) to enable or disable features in the project.
@@ -130,9 +133,9 @@ In some environments, users can submit a [CVE identifier request](../../applicat
 
 To disable the CVE identifier request option in issues in your project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Visibility, project features, permissions** section.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
+1. Expand **Visibility, project features, permissions**.
 1. Under **Issues**, turn off the **CVE ID requests in the issue sidebar** toggle.
 1. Select **Save changes**.
 
@@ -142,9 +145,9 @@ Prerequisites:
 
 - You must be an Owner of the project to disable email notifications related to the project.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Visibility, project features, permissions** section.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
+1. Expand **Visibility, project features, permissions**.
 1. Clear the **Disable email notifications** checkbox.
 
 ## Configure merge request settings for a project
@@ -156,7 +159,7 @@ Configure your project's merge request settings:
 - Enable [merge request approvals](../merge_requests/approvals/index.md).
 - Enable [status checks](../merge_requests/status_checks.md).
 - Enable [merge only if pipeline succeeds](../merge_requests/merge_when_pipeline_succeeds.md).
-- Enable [merge only when all threads are resolved](../../discussions/index.md#prevent-merge-unless-all-threads-are-resolved).
+- Enable [merge only when all threads are resolved](../merge_requests/index.md#prevent-merge-unless-all-threads-are-resolved).
 - Enable [require an associated issue from Jira](../../../integration/jira/issues.md#require-associated-jira-issue-for-merge-requests-to-be-merged).
 - Enable [**Delete source branch when merge request is accepted** option by default](#delete-the-source-branch-on-merge-by-default).
 - Configure [suggested changes commit messages](../merge_requests/reviews/suggestions.md#configure-the-commit-message-for-applied-suggestions).
@@ -184,8 +187,8 @@ other features are read-only. Archived projects are also hidden from project lis
 
 To archive a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Advanced**.
 1. In the **Archive project** section, select **Archive project**.
 1. To confirm, select **OK**.
@@ -200,7 +203,8 @@ Prerequisites:
 - To unarchive a project, you must be an administrator or a project Owner.
 
 1. Find the archived project.
-   1. On the top bar, select **Main menu > Projects > View all projects**.
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **View all your projects**.
    1. Select **Explore projects**.
    1. In the **Sort projects** dropdown list, select **Show archived projects**.
    1. In the **Filter by name** field, enter the project name.
@@ -225,9 +229,9 @@ When you change the repository path, users may experience issues if they push to
 
 To rename a repository:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Advanced** section.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
+1. Expand **Advanced**.
 1. In the **Change path** text box, edit the path.
 1. Select **Change path**.
 
@@ -238,8 +242,8 @@ In merge requests, you can change the default behavior so that the
 
 To set this default:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Merge requests**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Merge requests**.
 1. Select **Enable "Delete source branch" option by default**.
 1. Select **Save changes**.
 
@@ -249,7 +253,7 @@ When you transfer a project to another namespace, you move the project to a diff
 
 Prerequisites:
 
-- You must have at least the Maintainer role for the [group](../../group/manage.md#create-a-group) to which you are transferring.
+- You must have at least the Maintainer role for the [group](../../group/index.md#create-a-group) to which you are transferring.
 - You must be the Owner of the project you transfer.
 - The group must allow creation of new projects.
 - The project must not contain any [container images](../../packages/container_registry/index.md#move-or-rename-container-registry-repositories).
@@ -258,8 +262,8 @@ Prerequisites:
 
 To transfer a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Advanced**.
 1. Under **Transfer project**, choose the namespace to transfer the project to.
 1. Select **Transfer project**.
@@ -281,6 +285,11 @@ When you transfer a project from a namespace licensed for GitLab SaaS Premium or
 
 ## Delete a project
 
+> - Default deletion behavior for projects changed to [delayed project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6.
+> - Default deletion behavior for projects changed to [immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2.
+> - Default deletion behavior for projects on the Premium and Ultimate tier changed to [delayed project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/389557) in GitLab 16.0.
+> - Default deletion behavior changed to delayed deletion on the Premium and Ultimate tier [on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622) and [on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606) in GitLab 16.0.
+
 You can mark a project to be deleted.
 
 Prerequisite:
@@ -289,37 +298,34 @@ Prerequisite:
 
 To delete a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Advanced**.
-1. In the "Delete project" section, select **Delete project**.
-1. Confirm the action when asked to.
+1. In the **Delete this project** section, select **Delete project**.
+1. In the confirmation message text field, enter the name of the project as instructed, and select **Yes, delete project**.
 
-This action deletes a project including all associated resources (such as issues and merge requests).
-
-WARNING:
-The default deletion behavior for projects was changed to [delayed project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935)
-in GitLab 12.6, and then to [immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2.
+This action deletes the project and all associated resources (such as issues and merge requests).
 
 ### Delayed project deletion **(PREMIUM)**
 
 > - [Enabled for projects in personal namespaces](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89466) in GitLab 15.1.
 > - [Disabled for projects in personal namespaces](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95495) in GitLab 15.3.
+> - Enabled delayed deletion by default and removed the option to delete immediately [on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622) and [on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606) in GitLab 16.0.
 
-Projects in a group (not a personal namespace) can be deleted after a delay period. Multiple settings can affect whether
-delayed project deletion is enabled for a particular project:
+Projects in a group (not a personal namespace) can be deleted after a delay period.
 
-- Self-managed instance [settings](../../admin_area/settings/visibility_and_access_controls.md#delayed-project-deletion).
-  You can enable delayed project deletion as the default setting for new groups, and configure the number of days for the
-  delay. For GitLab.com, see the [GitLab.com settings](../../gitlab_com/index.md#delayed-project-deletion).
-- Group [settings](../../group/manage.md#enable-delayed-project-deletion) to enabled delayed project deletion for all
-  projects in the group.
+On self-managed instances, group administrators can define a deletion delay period of between 1 and 90 days.
+On SaaS, there is a non-adjustable default retention period of seven days.
 
 ### Delete a project immediately
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/191367) in GitLab 14.1.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/191367) in GitLab 14.1.
+> - Option to delete projects immediately from the Admin Area and as a group setting removed [on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622) and [on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606) in GitLab 16.0.
+
+If you don't want to wait for delayed deletion, you can delete a project immediately. To do this, perform the steps for [deleting a projects](#delete-a-project) again.
 
-If you don't want to wait, you can delete a project immediately.
+In the first cycle of deleting a project, the project is moved to the delayed deletion queue and automatically deleted after the retention period has passed.
+If during this delayed deletion time you run a second deletion cycle, the project is deleted immediately.
 
 Prerequisites:
 
@@ -328,16 +334,11 @@ Prerequisites:
 
 To immediately delete a project marked for deletion:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Advanced**.
-1. In the "Permanently delete project" section, select **Delete project**.
-1. Confirm the action when asked to.
-
-The following are deleted:
-
-- Your project and its repository.
-- All related resources including issues and merge requests.
+1. In the **Delete this project** section, select **Delete project**.
+1. In the confirmation message text field, enter the name of the project as instructed, as select **Yes, delete project**.
 
 ## Restore a project **(PREMIUM)**
 
@@ -345,7 +346,9 @@ The following are deleted:
 
 To restore a project marked for deletion:
 
-1. Navigate to your project, and select **Settings > General > Advanced**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
+1. Expand **Advanced**.
 1. In the Restore project section, select **Restore project**.
 
 ## Monitor settings
diff --git a/doc/user/project/settings/project_access_tokens.md b/doc/user/project/settings/project_access_tokens.md
index 178500093e2..7fd8fdf3a00 100644
--- a/doc/user/project/settings/project_access_tokens.md
+++ b/doc/user/project/settings/project_access_tokens.md
@@ -11,6 +11,7 @@ type: reference, howto
 > - [Became available on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/235765) in GitLab 13.5 for paid groups only.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/235765) in GitLab 13.5.
 > - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/342327) in GitLab 14.5. Default prefix added.
+> - [Became available in trial subscriptions](https://gitlab.com/gitlab-org/gitlab/-/issues/386041) in GitLab 16.1. Default prefix added.
 
 Project access tokens are similar to passwords, except you can [limit access to resources](#scopes-for-a-project-access-token),
 select a limited role, and provide an expiry date.
@@ -32,12 +33,9 @@ The ability to create project access tokens without expiry was [deprecated](http
 
 You can use project access tokens:
 
-- On GitLab SaaS: If you have the Premium or Ultimate license tier. Project access tokens are not available with a [trial license](https://about.gitlab.com/free-trial/).
-- On self-managed instances of GitLab: With any license tier. If you have the Free tier:
-  - Review your security and compliance policies around
-    [user self-enrollment](../../admin_area/settings/sign_up_restrictions.md#disable-new-sign-ups).
-  - Consider [disabling project access tokens](#enable-or-disable-project-access-token-creation) to
-    lower potential abuse.
+- On GitLab SaaS: If you have the Premium or Ultimate license tier, only one project access token is available with a [trial license](https://about.gitlab.com/free-trial/).
+- On self-managed instances of GitLab: With any license tier. If you have the Free tier,
+  consider [disabling project access tokens](#enable-or-disable-project-access-token-creation) to lower potential abuse.
 
 You cannot use project access tokens to create other group, project, or personal access tokens.
 
@@ -57,8 +55,8 @@ all projects that have visibility level set to [Internal](../../public_access.md
 
 To create a project access token:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Access Tokens**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Access Tokens**.
 1. Enter a name. The token name is visible to any user with permissions to view the project.
 1. Enter an expiry date for the token.
    - The token expires on that date at midnight UTC.
@@ -75,8 +73,8 @@ A project access token is displayed. Save the project access token somewhere saf
 
 To revoke a project access token:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Access Tokens**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Access Tokens**.
 1. Next to the project access token to revoke, select **Revoke**.
 
 ## Scopes for a project access token
@@ -98,8 +96,8 @@ The scope determines the actions you can perform when you authenticate with a pr
 
 To enable or disable project access token creation for all projects in a top-level group:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand **Permissions and group features**.
 1. Under **Permissions**, turn on or off **Allow project and group access token creation**.
 
@@ -112,7 +110,7 @@ Even when creation is disabled, you can still use and revoke existing project ac
 
 Bot users for projects are [GitLab-created service accounts](../../../subscriptions/self_managed/index.md#billable-users).
 Each time you create a project access token, a bot user is created and added to the project.
-These bot users do not count as licensed seats.
+This user is not a billable user, so it does not count toward the license limit.
 
 The bot users for projects have [permissions](../../permissions.md#project-members-permissions) that correspond with the
 selected role and [scope](#scopes-for-a-project-access-token) of the project access token.
@@ -139,4 +137,4 @@ See also [Bot users for groups](../../group/settings/group_access_tokens.md#bot-
 
 ## Token availability
 
-Project access tokens are only available in paid subscriptions, and not available in trial subscriptions. For more information, see the ["What is included" section of the GitLab Trial FAQ](https://about.gitlab.com/free-trial/#what-is-included-in-my-free-trial-what-is-excluded).
+More than one project access token is only available in paid subscriptions. In Premium and Ultimate trial subscriptions, only one project access token is included. For more information, see the ["What is included" section of the GitLab Trial FAQ](https://about.gitlab.com/free-trial/#what-is-included-in-my-free-trial-what-is-excluded).
diff --git a/doc/user/project/system_notes.md b/doc/user/project/system_notes.md
index 1eee4364d95..56873c328fa 100644
--- a/doc/user/project/system_notes.md
+++ b/doc/user/project/system_notes.md
@@ -31,23 +31,23 @@ The filtering options are:
 
 ### On an epic
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Epics** (**{epic}**).
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Epics**.
 1. Identify your desired epic, and select its title.
 1. Go to the **Activity** section.
 1. For **Sort or filter**, select **Show all activity**.
 
 ### On an issue
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Issues** and find your issue.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues** and find your issue.
 1. Go to **Activity**.
 1. For **Sort or filter**, select **Show all activity**.
 
 ### On a merge request
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Merge requests** and find your merge request.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Code > Merge requests** and find your merge request.
 1. Go to **Activity**.
 1. For **Sort or filter**, select **Show all activity**.
 
diff --git a/doc/user/project/time_tracking.md b/doc/user/project/time_tracking.md
index bd935db6f02..9b5469f6cec 100644
--- a/doc/user/project/time_tracking.md
+++ b/doc/user/project/time_tracking.md
@@ -185,8 +185,8 @@ The following time units are available:
 In GitLab self-managed instances, you can limit the display of time units to hours.
 To do so:
 
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Settings > Preferences**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Settings > Preferences**.
 1. Expand **Localization**.
 1. Under **Time tracking**, select the **Limit display of time tracking units to hours** checkbox.
 1. Select **Save changes**.
diff --git a/doc/user/project/web_ide/index.md b/doc/user/project/web_ide/index.md
index bb1609a74e5..481eca5a890 100644
--- a/doc/user/project/web_ide/index.md
+++ b/doc/user/project/web_ide/index.md
@@ -23,7 +23,7 @@ To pair the Web IDE with a remote development environment, see [remote developme
 
 To open the Web IDE from the GitLab UI:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Use the <kbd>.</kbd> keyboard shortcut.
 
 You can also open the Web IDE from:
@@ -36,13 +36,7 @@ You can also open the Web IDE from:
 
 To open the Web IDE from a file or the repository file list:
 
-- In the upper-right corner of the page, select **Open in Web IDE**.
-
-If **Open in Web IDE** is not visible:
-
-1. Next to **Edit** or **Gitpod**, select the down arrow (**{chevron-lg-down}**).
-1. From the dropdown list, select **Open in Web IDE**.
-1. Select **Open in Web IDE**.
+- In the upper right, select **Edit > Open in Web IDE**.
 
 ### From a merge request
 
@@ -89,17 +83,17 @@ For more information, see the [VS Code documentation](https://code.visualstudio.
 
 ## Upload a new file
 
-To upload a new file and add it to the Git repository:
+To upload a new file in the Web IDE:
 
-1. In the **Explorer** file tree, navigate to the directory where you want to upload the file.
-1. Optional. If the directory does not exist yet, select the directory path where you want to have a new directory and either:
-   - Right-click on the directory path, and select **New Folder...**. You can create a nested directory path with the `/` separator, for example `parentdir/subdir1/subdir2`.
-   - In the **Explorer** panel, in the upper-right corner, select the new folder (**{folder-new}**) icon.
-1. Enter the name of the new directory, and press <kbd>Enter/Return</kbd> to create it. 
-1. Right-click on the directory path and select `Upload...`.
-1. Select the file you want to upload, then select `Open`. You can select and add multiple files at once.
+1. On the activity bar on the left, select **Explorer** and go to the directory where you want to upload the file.
+1. Optional. For a new directory, go to the path where you want to have the directory and do one of the following:
+   - Right-click the path, and select **New Folder...**. You can create a nested path with `/` (for example, `parentdir/subdir1/subdir2`).
+   - In the upper right of the **Explorer** panel, select **New Folder...** (**{folder-new}**).
+1. Enter the name of the new directory, and press <kbd>Enter</kbd>.
+1. Right-click the path, and select **Upload...**.
+1. Select the file you want to upload, then select **Open**. You can upload multiple files at once.
 
-The file is uploaded and automatically added as a new file to the Git repository.
+The new file is uploaded and automatically added to the repository.
 
 ## Switch branches
 
@@ -129,7 +123,17 @@ To commit changes in the Web IDE:
    or press <kbd>Control</kbd>+<kbd>Shift</kbd>+<kbd>G</kbd>.
 1. Enter your commit message.
 1. Select **Commit & Push**.
-1. Commit to the current branch, or create a new branch.
+1. Commit to the current branch, or [create a new branch](#create-a-branch).
+
+## Create a merge request
+
+To create a merge request in the Web IDE:
+
+1. [Commit the changes](#commit-changes).
+1. In the pop-up notification in the lower-right corner, select **Create Merge Request**.
+   A new window opens for you to create the [merge request](../merge_requests/index.md).
+
+To access missed notifications, see [Access notifications](#access-notifications).
 
 ## Use the command palette
 
@@ -178,6 +182,13 @@ To change the Web IDE theme:
 
 The active color theme is stored in the [user settings](#edit-settings).
 
+## Access notifications
+
+When you perform actions in the Web IDE, notifications appear in the lower-right corner. To access missed notifications:
+
+1. On the status bar, in the lower-right corner, select the bell (**{notifications}**) for a list of notifications.
+1. Select the notification you want to access.
+
 <!-- ## Privacy and data collection for extensions
 
 The Web IDE Extension Marketplace is based on Open VSX. Open VSX does not collect any
@@ -194,6 +205,9 @@ To protect your privacy and data:
 
 ## Interactive web terminals for the Web IDE (Beta)
 
+WARNING:
+This feature is in [Beta](../../../policy/experiment-beta-support.md#beta) and subject to change without notice.
+
 When you set up a remote development server in the Web IDE, you can use interactive web terminals to:
 
 - Access a remote shell on the server.
diff --git a/doc/user/project/wiki/group.md b/doc/user/project/wiki/group.md
index 9327ce53b3f..2271c33b5b4 100644
--- a/doc/user/project/wiki/group.md
+++ b/doc/user/project/wiki/group.md
@@ -27,10 +27,10 @@ can edit group wikis. Group wiki repositories can be moved using the
 
 To access a group wiki:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. To display the wiki, either:
-   - On the left sidebar, select **Wiki**.
-   - On any page in the project, use the <kbd>g</kbd> + <kbd>w</kbd>
+   - On the left sidebar, select **Plan > Wiki**.
+   - On any page in the group, use the <kbd>g</kbd> + <kbd>w</kbd>
      [wiki keyboard shortcut](../../shortcuts.md).
 
 ## Export a group wiki
@@ -67,8 +67,8 @@ can enable or disable a group wiki through the group settings.
 
 To open group settings:
 
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > General**.
 1. Expand **Permissions and group features**.
 1. Scroll to **Wiki** and select one of these options:
    - **Enabled**: For public groups, everyone can access the wiki. For internal groups, only authenticated users can access the wiki.
diff --git a/doc/user/project/wiki/index.md b/doc/user/project/wiki/index.md
index eb13814f2ad..0d3782cfd09 100644
--- a/doc/user/project/wiki/index.md
+++ b/doc/user/project/wiki/index.md
@@ -31,9 +31,9 @@ with sibling pages listed in alphabetical order. To view a list of all pages, se
 
 To access a project wiki:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. To display the wiki, either:
-   - On the left sidebar, select **Wiki**.
+   - On the left sidebar, select **Plan > Wiki**.
    - On any page in the project, use the <kbd>g</kbd> + <kbd>w</kbd>
      [wiki keyboard shortcut](../../shortcuts.md).
 
@@ -61,10 +61,8 @@ When a wiki is created, it is empty. On your first visit, you can create the
 home page users see when viewing the wiki. This page requires a specific title
 to be used as your wiki's home page. To create it:
 
-1. On the top bar, select **Main menu**.
-   - For project wikis, select **Projects** and find your project.
-   - For group wikis, select **Groups** and find your group.
-1. On the left sidebar, select **Wiki**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Wiki**.
 1. Select **Create your first page**.
 1. GitLab requires this first page be titled `home`. The page with this
    title serves as the front page for your wiki.
@@ -79,10 +77,8 @@ to be used as your wiki's home page. To create it:
 
 Users with at least the Developer role can create new wiki pages:
 
-1. On the top bar, select **Main menu**.
-   - For project wikis, select **Projects** and find your project.
-   - For group wikis, select **Groups** and find your group.
-1. On the left sidebar, select **Wiki**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Wiki**.
 1. Select **New page** on this page, or any other wiki page.
 1. Select a content format.
 1. Add a title for your new page. Page titles use
@@ -142,10 +138,8 @@ may not be able to check out the wiki locally afterward.
 
 You need at least the Developer role to edit a wiki page:
 
-1. On the top bar, select **Main menu**.
-   - For project wikis, select **Projects** and find your project.
-   - For group wikis, select **Groups** and find your group.
-1. On the left sidebar, select **Wiki**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Wiki**.
 1. Go to the page you want to edit, and either:
    - Use the <kbd>e</kbd> wiki [keyboard shortcut](../../shortcuts.md#wiki-pages).
    - Select the edit icon (**{pencil}**).
@@ -163,10 +157,8 @@ For an example, read [Table of contents](../../markdown.md#table-of-contents).
 
 You need at least the Developer role to delete a wiki page:
 
-1. On the top bar, select **Main menu**.
-   - For project wikis, select **Projects** and find your project.
-   - For group wikis, select **Groups** and find your group.
-1. On the left sidebar, select **Wiki**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Wiki**.
 1. Go to the page you want to delete.
 1. Select the edit icon (**{pencil}**).
 1. Select **Delete page**.
@@ -176,10 +168,8 @@ You need at least the Developer role to delete a wiki page:
 
 You need at least the Developer role to move a wiki page:
 
-1. On the top bar, select **Main menu**.
-   - For project wikis, select **Projects** and find your project.
-   - For group wikis, select **Groups** and find your group.
-1. On the left sidebar, select **Wiki**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Wiki**.
 1. Go to the page you want to move.
 1. Select the edit icon (**{pencil}**).
 1. Add the new path to the **Title** field. For example, if you have a wiki page
@@ -202,10 +192,8 @@ The history page shows:
 
 To view the changes for a wiki page:
 
-1. On the top bar, select **Main menu**.
-   - For project wikis, select **Projects** and find your project.
-   - For group wikis, select **Groups** and find your group.
-1. On the left sidebar, select **Wiki**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Wiki**.
 1. Go to the page you want to view history for.
 1. Select **Page history**.
 
@@ -215,10 +203,8 @@ To view the changes for a wiki page:
 
 You can see the changes made in a version of a wiki page, similar to versioned diff file views:
 
-1. On the top bar, select **Main menu**.
-   - For project wikis, select **Projects** and find your project.
-   - For group wikis, select **Groups** and find your group.
-1. On the left sidebar, select **Wiki**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Wiki**.
 1. Go to the wiki page you're interested in.
 1. Select **Page history** to see all page versions.
 1. Select the commit message in the **Changes** column for the version you're interested in.
@@ -248,10 +234,8 @@ You need at least the Developer role to customize the wiki
 navigation sidebar. This process creates a wiki page named `_sidebar` which fully
 replaces the default sidebar navigation:
 
-1. On the top bar, select **Main menu**.
-   - For project wikis, select **Projects** and find your project.
-   - For group wikis, select **Groups** and find your group.
-1. On the left sidebar, select **Wiki**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Plan > Wiki**.
 1. In the upper-right corner of the page, select **Edit sidebar**.
 1. When complete, select **Save changes**.
 
@@ -284,11 +268,11 @@ You can disable group wikis from the [group settings](group.md#configure-group-w
 
 To add a link to an external wiki from a project's left sidebar:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **External wiki**.
 1. Add the URL to your external wiki.
-1. Optional. To verify the connection, select **Test settings**.
+1. Optional. Select **Test settings**.
 1. Select **Save changes**.
 
 You can now see the **External wiki** option from your project's
@@ -300,8 +284,8 @@ To hide the internal wiki from the sidebar, [disable the project's wiki](#disabl
 
 To hide the link to an external wiki:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
 1. Select **External wiki**.
 1. In the **Enable integration** section, clear the **Active** checkbox.
 1. Select **Save changes**.
@@ -310,8 +294,8 @@ To hide the link to an external wiki:
 
 To disable a project's internal wiki:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. Go to your project and select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. Scroll down to find **Wiki** and toggle it off (in gray).
 1. Select **Save changes**.
diff --git a/doc/user/project/working_with_projects.md b/doc/user/project/working_with_projects.md
index 69087791a3e..5bd7c12ed31 100644
--- a/doc/user/project/working_with_projects.md
+++ b/doc/user/project/working_with_projects.md
@@ -11,9 +11,15 @@ code are saved in projects, and most features are in the scope of projects.
 
 ## View projects
 
-To view all your projects, on the top bar, select **Main menu > Projects > View all projects**.
+To view all your projects:
 
-To browse all public projects, select **Main menu > Explore > Projects**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your projects**.
+
+To browse all projects you can access:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Explore**.
 
 ### Who can view the Projects page
 
@@ -42,11 +48,12 @@ visit the `/projects/:id` URL in your browser or other tool accessing the projec
 
 To explore project topics:
 
-1. On the top bar, select **Main menu > Projects > View all projects**.
-1. Select the **Explore topics** tab.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Explore**.
+1. On the left sidebar, select **Topics**.
 1. To view projects associated with a topic, select a topic.
 
-The **Explore topics** tab shows a list of topics sorted by the number of associated projects.
+The **Explore topics** page shows a list of topics, sorted by the number of associated projects.
 
 You can assign topics to a project on the [Project Settings page](settings/index.md#assign-topics-to-a-project).
 
@@ -59,13 +66,14 @@ You can add a star to projects you use frequently to make them easier to find.
 
 To add a star to a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. In the upper-right corner of the page, select **Star**.
 
 ## View starred projects
 
-1. On the top bar, select **Main menu > Projects > View all projects**.
-1. Select the **Starred projects** tab.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your projects**.
+1. Select the **Starred** tab.
 1. GitLab displays information about your starred projects, including:
 
    - Project description, including name, description, and icon.
@@ -83,17 +91,20 @@ called `my-project` under your username, the project is created at `https://gitl
 
 To view your personal projects:
 
-1. On the top bar, select **Main menu > Projects > View all projects**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your projects**.
 1. In the **Yours** tab, select **Personal**.
 
 ## Delete a project
 
-After you delete a project, projects in personal namespaces are deleted immediately. To delay deletion of projects in a group
-you can [enable delayed project removal](../group/manage.md#enable-delayed-project-deletion).
+After you delete a project:
+
+- Projects in personal namespaces are deleted immediately.
+- Projects in groups are [deleted after a retention period](../project/settings/index.md#delayed-project-deletion).
 
 To delete a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Select **Settings > General**.
 1. Expand the **Advanced** section.
 1. Scroll down to the **Delete project** section.
@@ -107,12 +118,10 @@ To delete a project:
 > - [Available to all users](https://gitlab.com/gitlab-org/gitlab/-/issues/346976) in GitLab 14.8 [with a flag](../../administration/feature_flags.md) named `project_owners_list_project_pending_deletion`. Enabled by default.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/351556) in GitLab 14.9. [Feature flag `project_owners_list_project_pending_deletion`](https://gitlab.com/gitlab-org/gitlab/-/issues/351556) removed.
 
-When delayed project deletion is [enabled for a group](../group/manage.md#enable-delayed-project-deletion),
-projects within that group are not deleted immediately, but only after a delay.
-
 To view a list of all projects that are pending deletion:
 
-1. On the top bar, select **Main menu > Projects > View all projects**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **View all your projects**.
 1. Based on your GitLab version:
    - GitLab 14.6 and later: select the **Pending deletion** tab.
    - GitLab 14.5 and earlier: select the **Deleted projects** tab.
@@ -127,18 +136,14 @@ Each project in the list shows:
 
 To view the activity of a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project..
-1. On the left sidebar, select **Project information > Activity**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Manage > Activity**.
 1. Select a tab to view the type of project activity.
 
 ## Search in projects
 
-You can search through your projects.
-
-1. On the top bar, select **Main menu**.
-1. In **Search your projects**, type the project name.
-
-GitLab filters as you type.
+To search through your projects, on the left sidebar, at the top, select **Search GitLab**
+(**{search}**). GitLab filters as you type.
 
 You can also look for the projects you [starred](#star-a-project) (**Starred projects**).
 
@@ -161,7 +166,10 @@ You can also choose to hide or show archived projects.
 
 You can filter projects by the programming language they use. To do this:
 
-1. On the top bar, select **Main menu > Projects > View all projects**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select either:
+   - **View all your projects**, to filter your projects.
+   - **Explore**, to filter all projects you can access.
 1. From the **Language** dropdown list, select the language you want to filter projects by.
 
 A list of projects that use the selected language is displayed.
@@ -174,8 +182,8 @@ Prerequisite:
 
 - You must have the Owner role for the project.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. Use the toggle by each feature you want to turn on or off, or change access for.
 1. Select **Save changes**.
@@ -190,7 +198,7 @@ When you leave a project:
 
 To leave a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Select **Leave project**. The **Leave project** option only displays
 on the project dashboard when a project is part of a group under a
 [group namespace](../namespace/index.md).
diff --git a/doc/user/public_access.md b/doc/user/public_access.md
index 58eebc16d74..002cb97dd93 100644
--- a/doc/user/public_access.md
+++ b/doc/user/public_access.md
@@ -59,7 +59,7 @@ Prerequisite:
 
 - You must have the Owner role for a project.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. Change **Project visibility** to either **Private**, **Internal**, or **Public**.
@@ -78,7 +78,7 @@ Prerequisites:
   restrictive as the new setting of the parent group. For example, you cannot set a group
   to private if a subgroup or project in that group is public.
 
-1. On the top bar, select **Main menu > Groups** and find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Naming, visibility**.
 1. Under **Visibility level** select either **Private**, **Internal**, or **Public**.
diff --git a/doc/user/read_only_namespaces.md b/doc/user/read_only_namespaces.md
index 63d7f18f70c..5b302d976dd 100644
--- a/doc/user/read_only_namespaces.md
+++ b/doc/user/read_only_namespaces.md
@@ -40,6 +40,8 @@ To restore a namespace to its standard state, you can:
 | CI/CD | Create, edit, admin, and run pipelines <br>  Create, edit, admin, and run builds <br>  Create and edit admin environments <br> Create and edit admin deployments <br>  Create and edit admin clusters <br> Create and edit admin releases |
 | Namespaces | **For exceeded free user limits:** Invite new users |
 
+When you try to execute a restricted action in a read-only namespace, you might get a `404` error.
+
 ## Related topics
 
 - [Frequently Asked Questions - GitLab SaaS Free Tier](https://about.gitlab.com/pricing/faq-efficient-free-tier/)
diff --git a/doc/user/search/index.md b/doc/user/search/index.md
index f6733abd305..2278da9a714 100644
--- a/doc/user/search/index.md
+++ b/doc/user/search/index.md
@@ -64,8 +64,8 @@ search, or choose a specific group or project.
 
 To search through code or other documents in a project:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the top bar, in the search field, type the string you want to search for.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) and type the string you want to search for.
 1. Press **Enter**.
 
 Code search shows only the first result in the file.
@@ -96,8 +96,6 @@ To filter code search results by one or more languages:
 ## Search for projects by full path
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108906) in GitLab 15.9 [with a flag](../../administration/feature_flags.md) named `full_path_project_search`. Disabled by default.
-> - [Enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/388473) on GitLab.com in GitLab 15.9.
-> - [Enabled](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111808) on self-managed GitLab 15.10.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114932) in GitLab 15.11. Feature flag `full_path_project_search` removed.
 
 You can search for a project by entering its full path (including the namespace it belongs to) in the search box.
@@ -108,12 +106,24 @@ For example, the search query:
 - `gitlab-org/gitlab` searches for the `gitlab` project in the `gitlab-org` namespace.
 - `gitlab-org/` displays autocomplete suggestions for projects that belong to the `gitlab-org` namespace.
 
+### Exclude archived projects from project search results
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121981) in GitLab 16.1 [with a flag](../../administration/feature_flags.md) named `search_projects_hide_archived`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available,
+ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `search_projects_hide_archived`. On GitLab.com, this feature is not available.
+
+Archived projects are included in project search results by default. To exclude archived projects, ensure the `search_projects_hide_archived` flag is enabled.
+
+To include archived projects with `search_projects_hide_archived` enabled, you must add the parameter `include_archived=true` to the URL.
+
 ## Search for a SHA
 
 You can search for a commit SHA.
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the top bar, in the search field, type the SHA.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) and type the SHA.
 
 If a single result is returned, GitLab redirects to the commit result
 and gives you the option to return to the search results page.
diff --git a/doc/user/shortcuts.md b/doc/user/shortcuts.md
index 3b6c6105315..e195be5586a 100644
--- a/doc/user/shortcuts.md
+++ b/doc/user/shortcuts.md
@@ -310,18 +310,6 @@ These shortcuts are available when viewing [epics](group/epics/index.md):
 | <kbd>e</kbd>      | Edit description. |
 | <kbd>l</kbd>      | Change label.     |
 
-## Metrics
-
-These shortcuts are available when using metrics:
-
-| Keyboard shortcut | Description         |
-|-------------------|---------------------|
-| <kbd>e</kbd>      | Expand panel.       |
-| <kbd>l</kbd>      | View logs.          |
-| <kbd>d</kbd>      | Download CSV.       |
-| <kbd>c</kbd>      | Copy link to chart. |
-| <kbd>a</kbd>      | Alerts.             |
-
 ## Disable keyboard shortcuts
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22113) in GitLab 12.8.
@@ -336,7 +324,7 @@ press <kbd>?</kbd> to display the list of shortcuts.
 
 To enable keyboard shortcuts:
 
-1. On the top bar, select the Help menu (**{question}**), then **Keyboard shortcuts**.
+1. On the left sidebar, at the bottom, select **Help** (**{question}**), then **Keyboard shortcuts**.
 1. Select **Toggle shortcuts**.
 
 ## Troubleshooting
diff --git a/doc/user/snippets.md b/doc/user/snippets.md
index 7ca897288e1..3ad003e4f4c 100644
--- a/doc/user/snippets.md
+++ b/doc/user/snippets.md
@@ -66,14 +66,22 @@ In GitLab versions 13.0 and later, snippets are [versioned by default](#versione
 
 To discover all snippets visible to you in GitLab, you can:
 
-- **View all snippets visible to you**: On the top bar of your GitLab
-  instance, select **Main menu > Your work** and then **Snippets** to view your snippets dashboard.
-- **Visit [GitLab snippets](https://gitlab.com/dashboard/snippets)** for your snippets on GitLab.com.
-- **Explore all public snippets**: On the top bar of your GitLab
-  instance, select **Main menu > Explore** and select **Snippets** to view
-  [all public snippets](https://gitlab.com/explore/snippets).
-- **View a project's snippets**: In your project,
-  go to **Snippets**.
+- **View a project's snippets**:
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+  1. Select **Code > Snippets**.
+- **View all the snippets you created**:
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Your work**.
+  1. Select **Snippets**.
+
+  On GitLab.com, you can also visit your [snippets directly](https://gitlab.com/dashboard/snippets).
+
+- **Explore all public snippets**:
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Explore**.
+  1. Select **Snippets**.
+
+  On GitLab.com, you can also visit [all public snippets directly](https://gitlab.com/explore/snippets).
 
 ## Change default visibility of snippets
 
@@ -225,8 +233,8 @@ Prerequisites:
 
 To do this task:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. On the left sidebar, select **Snippets**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. On the left sidebar, select **Code > Snippets**.
 1. Select the snippet you want to report as spam.
 1. Select **Submit as spam**.
 
diff --git a/doc/user/ssh.md b/doc/user/ssh.md
index b698f5a3edc..a11f3c4dbd6 100644
--- a/doc/user/ssh.md
+++ b/doc/user/ssh.md
@@ -277,7 +277,7 @@ You can use [1Password](https://1password.com/) and the [1Password browser exten
 - Use an existing SSH in your 1Password vault to authenticate with GitLab.
 
 1. Sign in to GitLab.
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **SSH Keys**.
 1. Select **Key**, and you should see the 1Password helper appear.
@@ -322,7 +322,7 @@ To use SSH with GitLab, copy your public key to your GitLab account:
    Replace `id_ed25519.pub` with your filename. For example, use `id_rsa.pub` for RSA.
 
 1. Sign in to GitLab.
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **SSH Keys**.
 1. In the **Key** box, paste the contents of your public key.
@@ -395,7 +395,7 @@ on `ssh` command options, see the `man` pages for both `ssh` and `ssh_config`.
 ## View your account's SSH keys
 
 1. Sign in to GitLab.
-1. On the top bar, in the upper-right corner, select your avatar.
+1. On the left sidebar, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **SSH Keys**.
 
diff --git a/doc/user/tasks.md b/doc/user/tasks.md
index fc232ee298e..b14f4acca36 100644
--- a/doc/user/tasks.md
+++ b/doc/user/tasks.md
@@ -130,6 +130,16 @@ To edit the description of a task:
 1. Above the text box, select **Rich text**.
 1. Make your changes, and select **Save**.
 
+## Promote a task to an issue
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/412534) in GitLab 16.1.
+
+Prerequisites:
+
+- You must have at least the Reporter role for the project.
+
+To promote a task to an issue, use the `/promote_to issue` [quick action](../user/project/quick_actions.md).
+
 ## Remove a task from an issue
 
 Prerequisites:
@@ -316,3 +326,36 @@ You can also filter activity by **Comments only** and **History only** in additi
 ## Comments and threads
 
 You can add [comments](discussions/index.md) and reply to threads in tasks.
+
+## Copy task reference
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/396553) in GitLab 16.1.
+
+To refer to a task elsewhere in GitLab, you can use its full URL or a short reference, which looks like
+`namespace/project-name#123`, where `namespace` is either a group or a username.
+
+To copy the task reference to your clipboard:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your task to view it.
+1. In the top right corner, select the vertical ellipsis (**{ellipsis_v}**), then select **Copy Reference**.
+
+You can now paste the reference into another description or comment.
+
+For more information about task references, see [GitLab-Flavored Markdown](markdown.md#gitlab-specific-references).
+
+## Copy task email address
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/396553) in GitLab 16.1.
+
+You can create a comment in a task by sending an email.
+Sending an email to this address creates a comment that contains the email body.
+
+For more information about creating comments by sending an email and the necessary configuration, see
+[Reply to a comment by sending email](discussions/index.md#reply-to-a-comment-by-sending-email).
+
+To copy the task's email address:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Plan > Issues**, then select your issue to view it.
+1. In the top right corner, select the vertical ellipsis (**{ellipsis_v}**), then select **Copy task email address**.
diff --git a/doc/user/todos.md b/doc/user/todos.md
index 8f67311b559..95bc8a553c1 100644
--- a/doc/user/todos.md
+++ b/doc/user/todos.md
@@ -20,7 +20,7 @@ You can use the To-Do List to track [actions](#actions-that-create-to-do-items)
 
 To access your To-Do List:
 
-On the top bar, in the upper-right corner, select the To-Do List (**{task-done}**).
+On the left sidebar, at the top, select To-Do list (**{task-done}**).
 
 ## Search the To-Do List
 
diff --git a/doc/user/usage_quotas.md b/doc/user/usage_quotas.md
index 822f169c2a3..5c6c64a3485 100644
--- a/doc/user/usage_quotas.md
+++ b/doc/user/usage_quotas.md
@@ -23,10 +23,8 @@ Prerequisites:
 - To view storage usage for a project, you must have at least the Maintainer role for the project or Owner role for the namespace.
 - To view storage usage for a namespace, you must have the Owner role for the namespace.
 
-1. Go to your project or namespace:
-   - For a project, on the top bar, select **Main menu > Projects** and find your project.
-   - For a namespace, enter the URL in your browser's toolbar.
-1. From the left sidebar, select **Settings > Usage Quotas**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. On the left sidebar, select **Settings > Usage Quotas**.
 1. Select the **Storage** tab.
 
 Select any title to view details. The information on this page
@@ -42,6 +40,54 @@ Container Registry usage is available only for GitLab.com. This feature requires
 of the GitLab Container Registry. To learn about the proposed release for self-managed
 installations, see [epic 5521](https://gitlab.com/groups/gitlab-org/-/epics/5521).
 
+#### How container registry usage is calculated
+
+Image layers stored in the Container Registry are deduplicated at the root namespace level.
+
+An image is only counted once if:
+
+- You tag the same image more than once in the same repository.
+- You tag the same image across distinct repositories under the same root namespace.
+
+An image layer is only counted once if:
+
+- You share the image layer across multiple images in the same container repository, project, or group.
+- You share the image layer across different repositories.
+
+Only layers that are referenced by tagged images are accounted for. Untagged images and any layers
+referenced exclusively by them are subject to [online garbage collection](packages/container_registry/delete_container_registry_images.md#garbage-collection).
+Untagged image layers are automatically deleted after 24 hours if they remain unreferenced during that period.
+
+Image layers are stored on the storage backend in the original (usually compressed) format. This
+means that the measured size for any given image layer should match the size displayed on the
+corresponding [image manifest](https://github.com/opencontainers/image-spec/blob/main/manifest.md#example-image-manifest).
+
+Namespace usage is refreshed a few minutes after a tag is pushed or deleted from any container repository under the namespace.
+
+#### Delayed refresh
+
+It is not possible to calculate [container registry usage](#container-registry-usage)
+with maximum precision in real time for extremely large namespaces (about 1% of namespaces).
+To enable maintainers of these namespaces to see their usage, there is a delayed fallback mechanism.
+See [epic 9413](https://gitlab.com/groups/gitlab-org/-/epics/9413) for more details.
+
+If the usage for a namespace cannot be calculated with precision, GitLab falls back to the delayed method.
+In the delayed method, the displayed usage size is the sum of **all** unique image layers
+in the namespace. Untagged image layers are not ignored. As a result,
+the displayed usage size might not change significantly after deleting tags. Instead,
+the size value only changes when:
+
+- An automated [garbage collection process](packages/container_registry/delete_container_registry_images.md#garbage-collection)
+  runs and deletes untagged image layers. After a user deletes a tag, a garbage collection run
+  is scheduled to start 24 hours later. During that run, images that were previously tagged
+  are analyzed and their layers deleted if not referenced by any other tagged image.
+  If any layers are deleted, the namespace usage is updated.
+- The namespace's registry usage shrinks enough that GitLab can measure it with maximum precision.
+  As usage for namespaces shrinks to be under the [limits](#namespace-storage-limit),
+  the measurement switches automatically from delayed to precise usage measurement.
+  There is no place in the UI to determine which measurement method is being used,
+  but [issue 386468](https://gitlab.com/gitlab-org/gitlab/-/issues/386468) proposes to improve this.
+
 ### Storage usage statistics
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68898) project-level graph in GitLab 14.4 [with a flag](../administration/feature_flags.md) named `project_storage_ui`. Disabled by default.
diff --git a/doc/user/workspace/index.md b/doc/user/workspace/index.md
index 922ce8e1354..eb3ce1c5aff 100644
--- a/doc/user/workspace/index.md
+++ b/doc/user/workspace/index.md
@@ -13,7 +13,7 @@ FLAG:
 On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../../administration/feature_flags.md) named `remote_development_feature_flag`. On GitLab.com, this feature is available. The feature is not ready for production use.
 
 WARNING:
-This feature is in [Beta](../../policy/alpha-beta-support.md#beta) and subject to change without notice. To leave feedback, see the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/410031).
+This feature is in [Beta](../../policy/experiment-beta-support.md#beta) and subject to change without notice. To leave feedback, see the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/410031).
 
 A workspace is a virtual sandbox environment for your code in GitLab. You can use workspaces to create and manage isolated development environments for your GitLab projects. These environments ensure that different projects don't interfere with each other.
 
@@ -23,33 +23,36 @@ Each workspace includes its own set of dependencies, libraries, and tools, which
 
 ### Prerequisites
 
-- Set up a Kubernetes cluster that the GitLab agent for Kubernetes supports. See the [supported Kubernetes versions](../clusters/agent/index.md#gitlab-agent-for-kubernetes-supported-cluster-versions).
+- Set up a Kubernetes cluster that the GitLab agent for Kubernetes supports. See the [supported Kubernetes versions](../clusters/agent/index.md#supported-kubernetes-versions-for-gitlab-features).
 - Ensure autoscaling for the Kubernetes cluster is enabled.
 - In the Kubernetes cluster, verify that a [default storage class](https://kubernetes.io/docs/concepts/storage/storage-classes/) is defined so that volumes can be dynamically provisioned for each workspace.
 - In the Kubernetes cluster, install an Ingress controller of your choice (for example, `ingress-nginx`), and make that controller accessible over a domain. For example, point `*.workspaces.example.dev` and `workspaces.example.dev` to the load balancer exposed by the Ingress controller.
 - In the Kubernetes cluster, [install `gitlab-workspaces-proxy`](https://gitlab.com/gitlab-org/remote-development/gitlab-workspaces-proxy#installation-instructions).
 - In the Kubernetes cluster, [install the GitLab agent for Kubernetes](../clusters/agent/install/index.md).
-- Configure remote development settings for the GitLab agent with this snippet:
+- Configure remote development settings for the GitLab agent with this snippet, and update `dns_zone` as needed:
 
-   ```yaml
-   remote_development:
-     enabled: true
-     dns_zone: "workspaces.example.dev"
-   ```
+  ```yaml
+  remote_development:
+    enabled: true
+    dns_zone: "workspaces.example.dev"
+  ```
 
-   Update `dns_zone` as needed.
-
-- In each public project you want to use this feature for, define a [devfile](#devfile). Ensure the container images used in the devfile support [arbitrary user IDs](#arbitrary-user-ids).
+  You can use any agent defined under the root group of your project, provided that remote development is properly configured for that agent.
+- You must have at least the Developer role in the root group.
+- In each public project you want to use this feature for, create a [devfile](#devfile):
+  1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project
+  1. In the root directory of your project, create a file named `.devfile.yaml`. You can use one of the [example configurations](#example-configurations).
+- Ensure the container images used in the devfile support [arbitrary user IDs](#arbitrary-user-ids).
 
 ### Create a workspace
 
-To create a workspace in GitLab:
+To create a workspace:
 
-1. On the top bar, select **Main menu > Projects** and find your project.
-1. In the root directory of your project, create a file named `.devfile.yaml`.
-1. On the left sidebar, select **Workspaces**.
-1. In the upper right, select **New workspace**.
-1. From the **Select project** dropdown list, select a project with a `.devfile.yaml` file. You can only create workspaces for public projects.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Your work**.
+1. Select **Workspaces**.
+1. Select **New workspace**.
+1. From the **Select project** dropdown list, [select a project with a `.devfile.yaml` file](#prerequisites). You can only create workspaces for public projects.
 1. From the **Select cluster agent** dropdown list, select a cluster agent owned by the group the project belongs to.
 1. In **Time before automatic termination**, enter the number of hours until the workspace automatically terminates. This timeout is a safety measure to prevent a workspace from consuming excessive resources or running indefinitely.
 1. Select **Create workspace**.
@@ -84,9 +87,9 @@ Only these properties are relevant to the GitLab implementation of the `containe
 | `endpoints`    | Port mappings to expose from the container.                                       |
 | `volumeMounts` | Storage volume to mount in the container.                                         |
 
-### Example definition
+### Example configurations
 
-The following is an example devfile:
+The following is an example devfile configuration:
 
 ```yaml
 schemaVersion: 2.2.0
@@ -153,6 +156,6 @@ If you already have running workspaces, an administrator must manually delete th
 ## Arbitrary user IDs
 
 You can provide your own container image, which can run as any Linux user ID. It's not possible for GitLab to predict the Linux user ID for a container image.
-GitLab uses the Linux root group ID permission to create, update, or delete files in the container. CRI-O, the container runtime interface used by Kubernetes, has a default group ID of `0` for all containers.
+GitLab uses the Linux root group ID permission to create, update, or delete files in a container. The container runtime used by the Kubernetes cluster must ensure all containers have a default Linux group ID of `0`.
 
 If you have a container image that does not support arbitrary user IDs, you cannot create, update, or delete files in a workspace. To create a container image that supports arbitrary user IDs, see the [OpenShift documentation](https://docs.openshift.com/container-platform/4.12/openshift_images/create-images.html#use-uid_create-images).