diff --git a/.gitlab/ci/qa-common/main.gitlab-ci.yml b/.gitlab/ci/qa-common/main.gitlab-ci.yml
index e4646314c89..56616363ef6 100644
--- a/.gitlab/ci/qa-common/main.gitlab-ci.yml
+++ b/.gitlab/ci/qa-common/main.gitlab-ci.yml
@@ -5,7 +5,7 @@ workflow:
   name: $PIPELINE_NAME
 
 include:
-  - component: "gitlab.com/gitlab-org/quality/pipeline-common/allure-report@8.6.1"
+  - component: "gitlab.com/gitlab-org/quality/pipeline-common/allure-report@8.7.0"
     inputs:
       job_name: "e2e-test-report"
       job_stage: "report"
@@ -15,7 +15,7 @@ include:
       gitlab_auth_token_variable_name: "PROJECT_TOKEN_FOR_CI_SCRIPTS_API_USAGE"
       allure_job_name: "${QA_RUN_TYPE}"
   - project: gitlab-org/quality/pipeline-common
-    ref: 8.6.1
+    ref: 8.7.0
     file:
       - /ci/base.gitlab-ci.yml
       - /ci/knapsack-report.yml
diff --git a/.rubocop_todo/layout/line_length.yml b/.rubocop_todo/layout/line_length.yml
index 47027f55f72..65c36a16a58 100644
--- a/.rubocop_todo/layout/line_length.yml
+++ b/.rubocop_todo/layout/line_length.yml
@@ -776,7 +776,6 @@ Layout/LineLength:
     - 'ee/app/graphql/types/security_report_summary_section_type.rb'
     - 'ee/app/graphql/types/vulnerabilities_count_by_day_type.rb'
     - 'ee/app/graphql/types/vulnerability/external_issue_link_external_tracker_enum.rb'
-    - 'ee/app/graphql/types/vulnerability_confidence_enum.rb'
     - 'ee/app/graphql/types/vulnerability_detail_type.rb'
     - 'ee/app/graphql/types/vulnerability_type.rb'
     - 'ee/app/helpers/admin/emails_helper.rb'
diff --git a/.rubocop_todo/rspec/feature_category.yml b/.rubocop_todo/rspec/feature_category.yml
index a3cfd737843..6baa1cbeba2 100644
--- a/.rubocop_todo/rspec/feature_category.yml
+++ b/.rubocop_todo/rspec/feature_category.yml
@@ -357,7 +357,6 @@ RSpec/FeatureCategory:
     - 'ee/spec/graphql/types/vulnerability/external_issue_link_type_spec.rb'
     - 'ee/spec/graphql/types/vulnerability/issue_link_type_enum_spec.rb'
     - 'ee/spec/graphql/types/vulnerability/issue_link_type_spec.rb'
-    - 'ee/spec/graphql/types/vulnerability_confidence_enum_spec.rb'
     - 'ee/spec/graphql/types/vulnerability_detail_type_spec.rb'
     - 'ee/spec/graphql/types/vulnerability_details/base_type_spec.rb'
     - 'ee/spec/graphql/types/vulnerability_details/boolean_type_spec.rb'
diff --git a/.rubocop_todo/style/hash_each_methods.yml b/.rubocop_todo/style/hash_each_methods.yml
index 97e2cb8645a..03be8f07ee7 100644
--- a/.rubocop_todo/style/hash_each_methods.yml
+++ b/.rubocop_todo/style/hash_each_methods.yml
@@ -39,7 +39,6 @@ Style/HashEachMethods:
     - 'ee/app/graphql/types/vulnerability/external_issue_link_external_tracker_enum.rb'
     - 'ee/app/graphql/types/vulnerability/external_issue_link_type_enum.rb'
     - 'ee/app/graphql/types/vulnerability/issue_link_type_enum.rb'
-    - 'ee/app/graphql/types/vulnerability_confidence_enum.rb'
     - 'ee/app/graphql/types/vulnerability_grade_enum.rb'
     - 'ee/app/graphql/types/vulnerability_report_type_enum.rb'
     - 'ee/app/graphql/types/vulnerability_severities_count_type.rb'
diff --git a/Gemfile b/Gemfile
index 8cc5d88688d..9f0cf100646 100644
--- a/Gemfile
+++ b/Gemfile
@@ -207,9 +207,9 @@ gem 'seed-fu', '~> 2.3.7' # rubocop:todo Gemfile/MissingFeatureCategory
 gem 'elasticsearch-model', '~> 7.2' # rubocop:todo Gemfile/MissingFeatureCategory
 gem 'elasticsearch-rails', '~> 7.2', require: 'elasticsearch/rails/instrumentation' # rubocop:todo Gemfile/MissingFeatureCategory
 gem 'elasticsearch-api',   '7.13.3' # rubocop:todo Gemfile/MissingFeatureCategory
-gem 'aws-sdk-core', '~> 3.191.6' # rubocop:todo Gemfile/MissingFeatureCategory
+gem 'aws-sdk-core', '~> 3.192.0' # rubocop:todo Gemfile/MissingFeatureCategory
 gem 'aws-sdk-cloudformation', '~> 1' # rubocop:todo Gemfile/MissingFeatureCategory
-gem 'aws-sdk-s3', '~> 1.146.1' # rubocop:todo Gemfile/MissingFeatureCategory
+gem 'aws-sdk-s3', '~> 1.147.0' # rubocop:todo Gemfile/MissingFeatureCategory
 gem 'faraday_middleware-aws-sigv4', '~>0.3.0' # rubocop:todo Gemfile/MissingFeatureCategory
 gem 'typhoeus', '~> 1.4.0' # Used with Elasticsearch to support http keep-alive connections # rubocop:todo Gemfile/MissingFeatureCategory
 
diff --git a/Gemfile.checksum b/Gemfile.checksum
index 87a456429b6..6434343b65c 100644
--- a/Gemfile.checksum
+++ b/Gemfile.checksum
@@ -36,9 +36,9 @@
 {"name":"aws-eventstream","version":"1.3.0","platform":"ruby","checksum":"f1434cc03ab2248756eb02cfa45e900e59a061d7fbdc4a9fd82a5dd23d796d3f"},
 {"name":"aws-partitions","version":"1.877.0","platform":"ruby","checksum":"9552ed7bbd3700ed1eeb0121c160ceaf64fa5dbaff5a1ff5fe6fd8481ecd9cfd"},
 {"name":"aws-sdk-cloudformation","version":"1.41.0","platform":"ruby","checksum":"31e47539719734413671edf9b1a31f8673fbf9688549f50c41affabbcb1c6b26"},
-{"name":"aws-sdk-core","version":"3.191.6","platform":"ruby","checksum":"d3afd9e59992b84e3fe1a6c8e5ec07e5103d4d89448672dea44e09dbfa550922"},
+{"name":"aws-sdk-core","version":"3.192.0","platform":"ruby","checksum":"106b391d232f64475e048ce35d54ab22487744e2e78d6256905689ed83cca3b2"},
 {"name":"aws-sdk-kms","version":"1.76.0","platform":"ruby","checksum":"e7f75013cba9ba357144f66bbc600631c192e2cda9dd572794be239654e2cf49"},
-{"name":"aws-sdk-s3","version":"1.146.1","platform":"ruby","checksum":"384f95e11fb543fbb7446f319fb37b1d035720a2011f90ade33c75f2e10588aa"},
+{"name":"aws-sdk-s3","version":"1.147.0","platform":"ruby","checksum":"367753c25d98b8019932d403d3ec56def51e70be917a2612d762a369ca167c45"},
 {"name":"aws-sigv4","version":"1.8.0","platform":"ruby","checksum":"84dd99768b91b93b63d1d8e53ee837cfd06ab402812772a7899a78f9f9117cbc"},
 {"name":"axe-core-api","version":"4.8.0","platform":"ruby","checksum":"88cf44fdbd5d501ae429f9ca6b37c4a46ba27ac673d478ab688eea3e353da62f"},
 {"name":"axe-core-rspec","version":"4.9.0","platform":"ruby","checksum":"e5f81fa55af0c421254c98476511c4511e193c5659996f184541f74a1359df3a"},
diff --git a/Gemfile.lock b/Gemfile.lock
index 9f4f63bba06..0e5a5797a54 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -311,7 +311,7 @@ GEM
     aws-sdk-cloudformation (1.41.0)
       aws-sdk-core (~> 3, >= 3.99.0)
       aws-sigv4 (~> 1.1)
-    aws-sdk-core (3.191.6)
+    aws-sdk-core (3.192.0)
       aws-eventstream (~> 1, >= 1.3.0)
       aws-partitions (~> 1, >= 1.651.0)
       aws-sigv4 (~> 1.8)
@@ -319,8 +319,8 @@ GEM
     aws-sdk-kms (1.76.0)
       aws-sdk-core (~> 3, >= 3.188.0)
       aws-sigv4 (~> 1.1)
-    aws-sdk-s3 (1.146.1)
-      aws-sdk-core (~> 3, >= 3.191.0)
+    aws-sdk-s3 (1.147.0)
+      aws-sdk-core (~> 3, >= 3.192.0)
       aws-sdk-kms (~> 1)
       aws-sigv4 (~> 1.8)
     aws-sigv4 (1.8.0)
@@ -1837,8 +1837,8 @@ DEPENDENCIES
   attr_encrypted (~> 3.2.4)!
   awesome_print
   aws-sdk-cloudformation (~> 1)
-  aws-sdk-core (~> 3.191.6)
-  aws-sdk-s3 (~> 1.146.1)
+  aws-sdk-core (~> 3.192.0)
+  aws-sdk-s3 (~> 1.147.0)
   axe-core-rspec (~> 4.9.0)
   babosa (~> 2.0)
   base32 (~> 0.3.0)
diff --git a/app/assets/javascripts/persistent_user_callouts.js b/app/assets/javascripts/persistent_user_callouts.js
index 120c71273fa..7e996223f9e 100644
--- a/app/assets/javascripts/persistent_user_callouts.js
+++ b/app/assets/javascripts/persistent_user_callouts.js
@@ -26,6 +26,7 @@ const PERSISTENT_USER_CALLOUTS = [
   '.js-joining-a-project-alert',
   '.js-duo-pro-trial-alert',
   '.js-duo-chat-ga-alert',
+  '.js-all-seats-used',
 ];
 
 const initCallouts = () => {
diff --git a/app/assets/javascripts/work_items/components/shared/work_item_link_child_contents.vue b/app/assets/javascripts/work_items/components/shared/work_item_link_child_contents.vue
index 9606cf33c0a..1e73a4c690f 100644
--- a/app/assets/javascripts/work_items/components/shared/work_item_link_child_contents.vue
+++ b/app/assets/javascripts/work_items/components/shared/work_item_link_child_contents.vue
@@ -241,7 +241,7 @@ export default {
       <gl-button
         v-gl-tooltip
         :class="{ 'gl-visibility-visible': showRemove }"
-        class="gl-visibility-hidden gl-mt-n2"
+        class="gl-visibility-hidden gl-mt-n2 gl-mr-n2"
         category="tertiary"
         size="small"
         icon="close"
diff --git a/app/assets/javascripts/work_items/components/work_item_links/work_item_links.vue b/app/assets/javascripts/work_items/components/work_item_links/work_item_links.vue
index efdf2a3d6af..234d6b8a98c 100644
--- a/app/assets/javascripts/work_items/components/work_item_links/work_item_links.vue
+++ b/app/assets/javascripts/work_items/components/work_item_links/work_item_links.vue
@@ -270,7 +270,7 @@ export default {
       </gl-disclosure-dropdown>
     </template>
     <template #body>
-      <div class="gl-new-card-content">
+      <div class="gl-new-card-content gl-px-0">
         <gl-loading-icon v-if="isLoading" color="dark" class="gl-my-2" />
         <template v-else>
           <div v-if="isChildrenEmpty && !isShownAddForm && !error" data-testid="links-empty">
diff --git a/app/assets/javascripts/work_items/components/work_item_links/work_item_tree.vue b/app/assets/javascripts/work_items/components/work_item_links/work_item_tree.vue
index 615579eb14e..48d50d88df9 100644
--- a/app/assets/javascripts/work_items/components/work_item_links/work_item_tree.vue
+++ b/app/assets/javascripts/work_items/components/work_item_links/work_item_tree.vue
@@ -182,7 +182,7 @@ export default {
       <work-item-actions-split-button v-if="canUpdate" :actions="addItemsActions" />
     </template>
     <template #body>
-      <div class="gl-new-card-content">
+      <div class="gl-new-card-content gl-px-0">
         <div v-if="!isShownAddForm && children.length === 0" data-testid="tree-empty">
           <p class="gl-new-card-empty">
             {{ $options.WORK_ITEMS_TREE_TEXT_MAP[workItemType].empty }}
diff --git a/app/assets/javascripts/work_items/components/work_item_relationships/work_item_relationship_list.vue b/app/assets/javascripts/work_items/components/work_item_relationships/work_item_relationship_list.vue
index 1b76e5a3ef3..4584eebecb6 100644
--- a/app/assets/javascripts/work_items/components/work_item_relationships/work_item_relationship_list.vue
+++ b/app/assets/javascripts/work_items/components/work_item_relationships/work_item_relationship_list.vue
@@ -36,7 +36,7 @@ export default {
     <h4
       v-if="heading"
       data-testid="work-items-list-heading"
-      class="gl-font-sm gl-font-weight-semibold gl-text-gray-700 gl-mt-3 gl-mb-0!"
+      class="gl-font-sm gl-font-weight-semibold gl-text-gray-700 gl-mt-3 gl-mb-2 gl-ml-3"
     >
       {{ heading }}
     </h4>
diff --git a/app/assets/javascripts/work_items/components/work_item_relationships/work_item_relationships.vue b/app/assets/javascripts/work_items/components/work_item_relationships/work_item_relationships.vue
index db85f0de3dd..0f998121cad 100644
--- a/app/assets/javascripts/work_items/components/work_item_relationships/work_item_relationships.vue
+++ b/app/assets/javascripts/work_items/components/work_item_relationships/work_item_relationships.vue
@@ -245,7 +245,7 @@ export default {
       </gl-button>
     </template>
     <template #body>
-      <div class="gl-new-card-content">
+      <div class="gl-new-card-content gl-px-0">
         <work-item-add-relationship-form
           v-if="isShownLinkItemForm"
           :work-item-id="workItemId"
@@ -270,7 +270,7 @@ export default {
             <work-item-relationship-list
               v-if="linksBlocks.length"
               :class="{
-                'gl-pb-3 gl-border-b-1 gl-border-b-solid gl-border-b-gray-100':
+                'gl-pb-3 gl-mb-5 gl-border-b-1 gl-border-b-solid gl-border-b-gray-100':
                   linksIsBlockedBy.length,
               }"
               :linked-items="linksBlocks"
@@ -290,7 +290,7 @@ export default {
             <work-item-relationship-list
               v-if="linksIsBlockedBy.length"
               :class="{
-                'gl-pb-3 gl-border-b-1 gl-border-b-solid gl-border-b-gray-100':
+                'gl-pb-3 gl-mb-5 gl-border-b-1 gl-border-b-solid gl-border-b-gray-100':
                   linksRelatesTo.length,
               }"
               :linked-items="linksIsBlockedBy"
diff --git a/app/models/users/group_callout.rb b/app/models/users/group_callout.rb
index 74b653b5777..5dc5140f386 100644
--- a/app/models/users/group_callout.rb
+++ b/app/models/users/group_callout.rb
@@ -30,7 +30,8 @@ module Users
       project_repository_limit_alert_warning_threshold: 20, # EE-only
       project_repository_limit_alert_alert_threshold: 21, # EE-only
       project_repository_limit_alert_error_threshold: 22, # EE-only
-      namespace_over_storage_users_combined_alert: 23 # EE-only
+      namespace_over_storage_users_combined_alert: 23, # EE-only
+      all_seats_used_alert: 24 # EE-only
     }
 
     validates :group, presence: true
diff --git a/app/services/web_hook_service.rb b/app/services/web_hook_service.rb
index e89c87b9a8c..9e1d80ad056 100644
--- a/app/services/web_hook_service.rb
+++ b/app/services/web_hook_service.rb
@@ -287,7 +287,6 @@ class WebHookService
 
   def request_payload
     return data unless hook.custom_webhook_template.present?
-    return data unless Feature.enabled?(:custom_webhook_template, hook.parent, type: :beta)
 
     start_time = Gitlab::Metrics::System.monotonic_time
     rendered_template = render_custom_template(hook.custom_webhook_template, data.deep_stringify_keys)
diff --git a/app/views/layouts/_page.html.haml b/app/views/layouts/_page.html.haml
index d854190b734..f4428f1ccc7 100644
--- a/app/views/layouts/_page.html.haml
+++ b/app/views/layouts/_page.html.haml
@@ -1,6 +1,7 @@
 .layout-page{ class: page_with_sidebar_class }
   -# Render the parent group sidebar while creating a new subgroup/project, see GroupsController#new.
   - group = @parent_group || @group
+  - context = group || @project
 
   - sidebar_panel = super_sidebar_nav_panel(nav: nav, user: current_user, group: group, project: @project, current_ref: current_ref, ref_type: @ref_type, viewed_user: @user, organization: @organization)
   - sidebar_data = super_sidebar_context(current_user, group: group, project: @project, panel: sidebar_panel, panel_type: nav).to_json
@@ -28,6 +29,7 @@
       = dispensable_render "shared/service_ping_consent"
       = dispensable_render_if_exists "layouts/header/ee_subscribable_banner"
       = dispensable_render_if_exists "layouts/header/seat_count_alert"
+      = dispensable_render_if_exists "layouts/header/all_seats_used_alert", context: context
       = dispensable_render_if_exists "shared/namespace_user_cap_reached_alert"
       = dispensable_render_if_exists "shared/new_user_signups_cap_reached_alert"
       = dispensable_render_if_exists "shared/silent_mode_banner"
diff --git a/app/views/shared/web_hooks/_form.html.haml b/app/views/shared/web_hooks/_form.html.haml
index 8437ad99575..8579e3ac0f6 100644
--- a/app/views/shared/web_hooks/_form.html.haml
+++ b/app/views/shared/web_hooks/_form.html.haml
@@ -83,12 +83,11 @@
           help_text: s_('Webhooks|An access token is going to expire in the next 7 days. %{help_link}?').html_safe % { help_link: access_token_help_link }
 
 
-- if Feature.enabled?(:custom_webhook_template, hook.parent, type: :beta)
-  .form-group
-    = form.label :custom_webhook_template, s_('Webhooks|Custom webhook template (optional)'), class: 'label-bold'
-    = form.text_area :custom_webhook_template, value: hook.custom_webhook_template, class: 'form-control gl-form-input gl-form-input-xl', rows: 8, maxlength: 4096
-    %p.form-text.text-muted
-      = link_to s_('Webhooks|How to create a custom webhook template?'), help_page_path('user/project/integrations/webhooks', anchor: 'custom-webhook-template')
+.form-group
+  = form.label :custom_webhook_template, s_('Webhooks|Custom webhook template (optional)'), class: 'label-bold'
+  = form.text_area :custom_webhook_template, value: hook.custom_webhook_template, class: 'form-control gl-form-input gl-form-input-xl', rows: 8, maxlength: 4096
+  %p.form-text.text-muted
+    = link_to s_('Webhooks|How to create a custom webhook template?'), help_page_path('user/project/integrations/webhooks', anchor: 'custom-webhook-template')
 
 .form-group
   = form.label :enable_ssl_verification, s_('Webhooks|SSL verification'), class: 'label-bold checkbox'
diff --git a/config/feature_flags/beta/custom_webhook_template.yml b/config/feature_flags/beta/custom_webhook_template.yml
deleted file mode 100644
index df1fd4a8692..00000000000
--- a/config/feature_flags/beta/custom_webhook_template.yml
+++ /dev/null
@@ -1,9 +0,0 @@
----
-name: custom_webhook_template
-feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/362504
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142738
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/439610
-milestone: '16.10'
-group: group::import and integrate
-type: beta
-default_enabled: true
diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index 551ad6876a9..49bf05b7624 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -247,7 +247,7 @@ In some circumstances, like during [upgrades](replication/upgrading_the_geo_site
 [planned failover](disaster_recovery/planned_failover.md), it is desirable to pause replication between the primary and secondary.
 
 If you plan to allow user activity on your secondary sites during the upgrade,
-do not pause replication for a [zero downtime upgrade](../../update/zero_downtime.md). While paused, the secondary site gets more and more out-of-date.
+do not pause replication for a [zero-downtime upgrade](../../update/zero_downtime.md). While paused, the secondary site gets more and more out-of-date.
 One known effect is that more and more Git fetches get redirected or proxied to the primary site. There may be additional unknown effects.
 
 Pausing and resuming replication is done through a command-line tool from a specific node in the secondary site. Depending on your database architecture,
diff --git a/doc/administration/geo/replication/geo_validation_tests.md b/doc/administration/geo/replication/geo_validation_tests.md
index 9f0aaebc8fe..7bf3f22e9a2 100644
--- a/doc/administration/geo/replication/geo_validation_tests.md
+++ b/doc/administration/geo/replication/geo_validation_tests.md
@@ -24,7 +24,7 @@ The following are GitLab upgrade validation tests we performed.
 [Upgrade Geo multi-node installation](https://gitlab.com/gitlab-org/gitlab/-/issues/225359):
 
 - Description: Tested upgrading from GitLab 12.10.12 to 13.0.10 package in a multi-node
-  configuration. As part of the issue to [Fix zero-downtime upgrade process/instructions for multi-node Geo deployments](https://gitlab.com/gitlab-org/gitlab/-/issues/22568), we monitored for downtime using the looping pipeline, HAProxy stats dashboards, and a script to log readiness status on both nodes.
+  configuration. As part of the issue to [Fix zero-downtime upgrade process/instructions for multi-node Geo deployments](https://gitlab.com/gitlab-org/gitlab/-/issues/225684), we monitored for downtime using the looping pipeline, HAProxy stats dashboards, and a script to log readiness status on both nodes.
 - Outcome: Partial success because we observed downtime during the upgrade of the primary and secondary sites.
 - Follow up issues/actions:
   - [Investigate why `reconfigure` and `hup` cause downtime on multi-node Geo deployments](https://gitlab.com/gitlab-org/gitlab/-/issues/228898)
diff --git a/doc/administration/geo/replication/upgrading_the_geo_sites.md b/doc/administration/geo/replication/upgrading_the_geo_sites.md
index b9e9fac85ad..f527de2c656 100644
--- a/doc/administration/geo/replication/upgrading_the_geo_sites.md
+++ b/doc/administration/geo/replication/upgrading_the_geo_sites.md
@@ -28,7 +28,7 @@ Upgrading Geo sites involves performing:
 
 NOTE:
 These general upgrade steps require downtime in a multi-node setup.
-If you want to avoid downtime, consider using [zero downtime upgrades](../../../update/zero_downtime.md#multi-node--ha-deployment-with-geo).
+If you want to avoid downtime, consider using [zero-downtime upgrades](../../../update/zero_downtime.md#multi-node--ha-deployment-with-geo).
 
 To upgrade the Geo sites when a new GitLab version is released, upgrade **primary**
 and all **secondary** sites:
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index 0fd0d6523b9..273a719706a 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -529,7 +529,7 @@ For more information on configuring Gitaly Cluster, see [Configure Gitaly Cluste
 ### Upgrade Gitaly Cluster
 
 To upgrade a Gitaly Cluster, follow the documentation for
-[zero downtime upgrades](../../update/zero_downtime.md).
+[zero-downtime upgrades](../../update/zero_downtime.md).
 
 ### Downgrade Gitaly Cluster to a previous version
 
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index e95ccf0d541..cb3b2a7e15d 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -1294,7 +1294,7 @@ itself on the system so that the `gitlab-ctl` command can bring the registry ser
 Also, there's no way to save progress or results during the mark phase of the process. Only once
 blobs start being deleted is anything permanent done.
 
-### Continuous Zero Downtime Garbage Collection
+### Continuous Zero-Downtime Garbage Collection
 
 DETAILS:
 **Status:** Beta
diff --git a/doc/administration/postgresql/replication_and_failover.md b/doc/administration/postgresql/replication_and_failover.md
index 38d3e5e551c..7d1ff55461e 100644
--- a/doc/administration/postgresql/replication_and_failover.md
+++ b/doc/administration/postgresql/replication_and_failover.md
@@ -1087,7 +1087,7 @@ Reverting the PostgreSQL upgrade with `gitlab-ctl revert-pg-upgrade` has the sam
 `gitlab-ctl pg-upgrade`. You should follow the same procedure by first stopping the replicas,
 then reverting the leader, and finally reverting the replicas.
 
-### Near zero downtime upgrade of PostgreSQL in a Patroni cluster
+### Near-zero-downtime upgrade of PostgreSQL in a Patroni cluster
 
 DETAILS:
 **Status:** Experiment
@@ -1126,7 +1126,7 @@ cluster.
 #### Preflight check
 
 We rely on PostgreSQL [logical replication](https://www.postgresql.org/docs/current/logical-replication.html)
-to support near-zero downtime upgrades of Patroni clusters. The of
+to support near-zero-downtime upgrades of Patroni clusters. The of
 [logical replication requirements](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)
 must be met. In particular, `wal_level` must be `logical`. To check the `wal_level`,
 run the following command with `gitlab-psql` on any node of the existing cluster:
@@ -1137,7 +1137,7 @@ SHOW wal_level;
 
 By default, Patroni sets `wal_level` to `replica`. You must increase it to `logical`.
 Changing `wal_level` requires restarting PostgreSQL, so this step leads to a short
-downtime (hence near-zero downtime). To do this on the Patroni **leader** node:
+downtime (hence near-zero-downtime). To do this on the Patroni **leader** node:
 
 1. Edit `gitlab.rb` by setting:
 
diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md
index c5874651cd7..8944a9fe0d2 100644
--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -111,9 +111,9 @@ In general then, we'd only recommend you employ HA in the following scenarios:
 
 If you still need to have HA for a lower number of users, this can be achieved with an adjusted [3K architecture](3k_users.md#supported-modifications-for-lower-user-counts-ha).
 
-#### Zero Downtime Upgrades
+#### Zero-Downtime Upgrades
 
-[Zero Downtime Upgrades](../../update/zero_downtime.md) are available for standard Reference Architecture environments with HA (Cloud Native Hybrid is [not supported](https://gitlab.com/groups/gitlab-org/cloud-native/-/epics/52)). This allows for an environment to stay up during an upgrade, but the process is more complex as a result and has some limitations as detailed in the documentation.
+[Zero-Downtime Upgrades](../../update/zero_downtime.md) are available for standard Reference Architecture environments with HA (Cloud Native Hybrid is [not supported](https://gitlab.com/groups/gitlab-org/cloud-native/-/epics/52)). This allows for an environment to stay up during an upgrade, but the process is more complex as a result and has some limitations as detailed in the documentation.
 
 When going through this process it's worth noting that there may still be brief moments of downtime when the HA mechanisms take effect.
 
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 40dc9fc7b95..c865c9a17b7 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -9138,7 +9138,6 @@ Input type: `VulnerabilityCreateInput`
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="mutationvulnerabilitycreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationvulnerabilitycreateconfidence"></a>`confidence` **{warning-solid}** | [`VulnerabilityConfidence`](#vulnerabilityconfidence) | **Deprecated:** This field will be removed from the Vulnerability domain model. Deprecated in GitLab 15.4. |
 | <a id="mutationvulnerabilitycreateconfirmedat"></a>`confirmedAt` | [`Time`](#time) | Timestamp of when the vulnerability state changed to confirmed (defaults to creation time if status is `confirmed`). |
 | <a id="mutationvulnerabilitycreatedescription"></a>`description` | [`String!`](#string) | Long text section that describes the vulnerability in more detail. |
 | <a id="mutationvulnerabilitycreatedetectedat"></a>`detectedAt` | [`Time`](#time) | Timestamp of when the vulnerability was first detected (defaults to creation time). |
@@ -34248,20 +34247,6 @@ Determines whether the pipeline list shows ID or IID.
 | <a id="visibilityscopesenumprivate"></a>`private` | Snippet is visible only to the snippet creator. |
 | <a id="visibilityscopesenumpublic"></a>`public` | Snippet can be accessed without any authentication. |
 
-### `VulnerabilityConfidence`
-
-Confidence that a given vulnerability is present in the codebase.
-
-| Value | Description |
-| ----- | ----------- |
-| <a id="vulnerabilityconfidenceconfirmed"></a>`CONFIRMED` | Confirmed confidence. |
-| <a id="vulnerabilityconfidenceexperimental"></a>`EXPERIMENTAL` | Experimental confidence. |
-| <a id="vulnerabilityconfidencehigh"></a>`HIGH` | High confidence. |
-| <a id="vulnerabilityconfidenceignore"></a>`IGNORE` | Ignore confidence. |
-| <a id="vulnerabilityconfidencelow"></a>`LOW` | Low confidence. |
-| <a id="vulnerabilityconfidencemedium"></a>`MEDIUM` | Medium confidence. |
-| <a id="vulnerabilityconfidenceunknown"></a>`UNKNOWN` | Unknown confidence. |
-
 ### `VulnerabilityDismissalReason`
 
 The dismissal reason of the Vulnerability.
diff --git a/doc/architecture/blueprints/cells/impacted_features/schema-changes.md b/doc/architecture/blueprints/cells/impacted_features/schema-changes.md
index 0d6ca4717d3..dc85bd32c42 100644
--- a/doc/architecture/blueprints/cells/impacted_features/schema-changes.md
+++ b/doc/architecture/blueprints/cells/impacted_features/schema-changes.md
@@ -16,7 +16,7 @@ we can document the reasons for not choosing this approach.
 # Cells: Schema changes
 
 When we introduce multiple Cells that own their own databases this will complicate the process of making schema changes to Postgres and Elasticsearch.
-Today we already need to be careful to make changes comply with our zero downtime deployments.
+Today we already need to be careful to make changes comply with our zero-downtime deployments.
 For example, [when removing a column we need to make changes over 3 separate deployments](../../../../development/database/avoiding_downtime_in_migrations.md#dropping-columns).
 We have tooling like `post_migrate` that helps with these kinds of changes to reduce the number of merge requests needed, but these will be complicated when we are dealing with deploying multiple Rails applications that will be at different versions at any one time.
 This problem will be particularly tricky to solve for shared databases like our plan to share the `users` related tables among all Cells.
diff --git a/doc/architecture/blueprints/cells/infrastructure/deployments.md b/doc/architecture/blueprints/cells/infrastructure/deployments.md
index e72277cb0d2..c4c48edb9bb 100644
--- a/doc/architecture/blueprints/cells/infrastructure/deployments.md
+++ b/doc/architecture/blueprints/cells/infrastructure/deployments.md
@@ -166,7 +166,7 @@ Before we can integrate Secondary Cells to our deployment pipeline, we need a fe
    - This is required for appropriate testing. As noted below, we'll need a QA cell to direct a deployment to for which QA will execute tests against. A router will need to route QA tests to the appropriate Cell.
 1. Assets Deployment
    - This already exists today for .com. Today this is handled via HAProxy, but with Cells, the routing layer will become the responsible party to redirect assets in a similar fashion.
-   - If assets are chosen to be managed differently, this changes both how Delivery need to deploy said assets in order to provide as close to Zero Downtime Upgrades as possible, and configuration to the Cell installation to support routing to assets properly.
+   - If assets are chosen to be managed differently, this changes both how Delivery need to deploy said assets in order to provide as close to Zero-Downtime Upgrades as possible, and configuration to the Cell installation to support routing to assets properly.
 1. Feature Flags
    - We are assuming that the current Feature Flags workflows and tooling will just work on the Primary Cell and that Secondary Cells will not be affected.
    - The use of feature flags to mitigate incidents is limited to only the Primary Cell.
diff --git a/doc/architecture/blueprints/cells/iterations/cells-1.0.md b/doc/architecture/blueprints/cells/iterations/cells-1.0.md
index e17eb63d4b5..685788d88e7 100644
--- a/doc/architecture/blueprints/cells/iterations/cells-1.0.md
+++ b/doc/architecture/blueprints/cells/iterations/cells-1.0.md
@@ -459,7 +459,6 @@ The table below is a comparison between the existing GitLab.com features, and no
 | Organization Switching                                       | A user belongs to a single organization.                                                                                                                                                                                                                                                     |
 | Shared user accounts across Cells                            | Users will need to have new user accounts on each Cell for now                                                                                                                                                                                                                               |
 | GitLab Duo Pro license works across all projects on instance | GitLab Duo Pro licenses, once granted, [should allow users to use GitLab Duo Pro on all projects on the instance](https://gitlab.com/gitlab-org/gitlab/-/issues/441244). With Cells 1.0, this will only work within their own cell.                                                          |
-| Shared user accounts across Cells                            | Users needs to have new user accounts on each Cell for now                                                                                                                                                                                                                                   |
 | User removal                                                 | Users can only be part of one Organization. A removal would equal a deletion in this case, so only user deletions will be offered in Organizations on Cells 1.0. Upon removal, there would be no way for a User to discover another Organization to join, as they are private for Cells 1.0. |
 | Windows and Mac OS Runners    |  Mac and Windows runners are still in beta and there are some more complex technical considerations related to cost. See the discussion: [#434982 (comment 1789275416)](https://gitlab.com/gitlab-org/gitlab/-/issues/434982#note_1789275416) on sharing resources. |
 | Multiple Sizes for Linux Runners | We will only support [small linux runners on Cells 1.0](https://gitlab.com/gitlab-org/gitlab/-/issues/434982#note_1806447839). |
diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
index 9fe35c4c8a7..b7e345b544f 100644
--- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
+++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
@@ -208,7 +208,7 @@ It should execute the `list` task we defined earlier, which connects to the serv
 
 Envoy is not a dependency of Laravel, therefore you can use it for any PHP application.
 
-### Zero downtime deployment
+### Zero-downtime deployment
 
 Every time we deploy to the production server, Envoy downloads the latest release of our app from GitLab repository and replace it with preview's release.
 Envoy does this without any [downtime](https://en.wikipedia.org/wiki/Downtime),
diff --git a/doc/ci/jobs/index.md b/doc/ci/jobs/index.md
index 4c5253c10e3..c9058c1c943 100644
--- a/doc/ci/jobs/index.md
+++ b/doc/ci/jobs/index.md
@@ -10,7 +10,8 @@ DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** GitLab.com, Self-managed, GitLab Dedicated
 
-Pipeline configuration begins with jobs. Jobs are the most fundamental element of a `.gitlab-ci.yml` file.
+Jobs are fundamental elements of a GitLab CI/CD pipeline. Jobs are configured in the `.gitlab-ci.yml` file
+with a list of commands to run to accomplish tasks like building, testing, or deploying code.
 
 Jobs are:
 
diff --git a/doc/development/advanced_search.md b/doc/development/advanced_search.md
index a552b22226d..2153ac9f790 100644
--- a/doc/development/advanced_search.md
+++ b/doc/development/advanced_search.md
@@ -116,7 +116,7 @@ Example:
 - Searches can have their own analyzers. Remember to check when editing analyzers.
 - `Character` filters (as opposed to token filters) always replace the original character. These filters can hinder exact searches.
 
-## Zero downtime reindexing with multiple indices
+## Zero-downtime reindexing with multiple indices
 
 NOTE:
 This is not applicable yet as multiple indices functionality is not fully implemented.
diff --git a/doc/development/avoiding_required_stops.md b/doc/development/avoiding_required_stops.md
index a9ecc382d56..b9abc171531 100644
--- a/doc/development/avoiding_required_stops.md
+++ b/doc/development/avoiding_required_stops.md
@@ -66,7 +66,7 @@ migrations, or code changes that assume that schema changes introduced in
 prior migrations have completed by the time the code loads.
 
 Designing changes and migrations for [backwards compatibility between versions](multi_version_compatibility.md) can mitigate stop concerns with continuous or
-"zero-downtime" upgrades. However, the **contract** phase will likely introduce
+zero-downtime upgrades. However, the **contract** phase will likely introduce
 a required stop when a migration/code change is introduced that requires
 that background migrations have completed before running or loading.
 
diff --git a/doc/development/database/adding_database_indexes.md b/doc/development/database/adding_database_indexes.md
index 126821ea8e7..018d0b59eef 100644
--- a/doc/development/database/adding_database_indexes.md
+++ b/doc/development/database/adding_database_indexes.md
@@ -175,7 +175,7 @@ guessing query performance is a hard task.
 If you are concerned about the performance of a query on self-managed instances
 and decide that self-managed instances must have an index, follow these recommendations:
 
-- For self-managed instances following [zero downtime](../../update/zero_downtime.md)
+- For self-managed instances following [zero-downtime](../../update/zero_downtime.md)
   upgrades, post-deploy migrations execute when performing an upgrade after the application code deploys.
 - For self-managed instances that do not follow a zero-downtime upgrade,
   the administrator might choose to execute the post-deployment migrations for a release later,
diff --git a/doc/development/multi_version_compatibility.md b/doc/development/multi_version_compatibility.md
index d1feffb5b46..1c876145380 100644
--- a/doc/development/multi_version_compatibility.md
+++ b/doc/development/multi_version_compatibility.md
@@ -148,7 +148,7 @@ As an example, when adding a new feature with frontend and API changes, it may b
 
 ### Expand and contract pattern
 
-One way to guarantee zero downtime updates for on-premise instances is following the
+One way to guarantee zero-downtime updates for on-premise instances is following the
 [expand and contract pattern](https://martinfowler.com/bliki/ParallelChange.html).
 
 This means that every breaking change is broken down in three phases: expand, migrate, and contract.
@@ -157,7 +157,7 @@ This means that every breaking change is broken down in three phases: expand, mi
 1. **migrate**: all consumers are updated to make use of the new implementation.
 1. **contract**: backward compatibility is removed.
 
-Those three phases **must be part of different milestones**, to allow zero downtime updates.
+Those three phases **must be part of different milestones**, to allow zero-downtime updates.
 
 Depending on the support level for the feature, the contract phase could be delayed until the next major release.
 
diff --git a/doc/integration/advanced_search/elasticsearch.md b/doc/integration/advanced_search/elasticsearch.md
index cef2add0d54..8eca7b2bdf2 100644
--- a/doc/integration/advanced_search/elasticsearch.md
+++ b/doc/integration/advanced_search/elasticsearch.md
@@ -420,7 +420,7 @@ To enable languages support:
 1. Locate **Custom analyzers: language support**.
 1. Enable plugins support for **Indexing**.
 1. Select **Save changes** for the changes to take effect.
-1. Trigger [Zero downtime reindexing](#zero-downtime-reindexing) or reindex everything from scratch to create a new index with updated mappings.
+1. Trigger [zero-downtime reindexing](#zero-downtime-reindexing) or reindex everything from scratch to create a new index with updated mappings.
 1. Enable plugins support for **Searching** after the previous step is completed.
 
 For guidance on what to install, see the following Elasticsearch language plugin options:
diff --git a/doc/subscriptions/bronze_starter.md b/doc/subscriptions/bronze_starter.md
index a22ea168c1d..48a1ff47af0 100644
--- a/doc/subscriptions/bronze_starter.md
+++ b/doc/subscriptions/bronze_starter.md
@@ -80,7 +80,7 @@ the tiers are no longer mentioned in GitLab documentation:
 - Rake tasks:
   - [Displaying GitLab license information](../administration/raketasks/maintenance.md#show-gitlab-license-information)
 - Reference Architecture information:
-  - [Zero downtime upgrades](../administration/reference_architectures/index.md#zero-downtime-upgrades)
+  - [Zero-downtime upgrades](../administration/reference_architectures/index.md#zero-downtime-upgrades)
 - Repositories:
   - [Repository size limit](../administration/settings/account_and_limit_settings.md#repository-size-limit)
   - Repository mirroring:
diff --git a/doc/topics/autodevops/cicd_variables.md b/doc/topics/autodevops/cicd_variables.md
index a4bb59d10f1..eaa60d5d56c 100644
--- a/doc/topics/autodevops/cicd_variables.md
+++ b/doc/topics/autodevops/cicd_variables.md
@@ -57,7 +57,7 @@ Use these variables to customize and deploy your build.
 | `KUBE_INGRESS_BASE_DOMAIN`              | Can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/gitlab_managed_clusters.md#base-domain) for more information. |
 | `KUBE_NAMESPACE`                        | The namespace used for deployments. When using certificate-based clusters, [this value should not be overwritten directly](../../user/project/clusters/deploy_to_cluster.md#custom-namespace). |
 | `KUBECONFIG`                            | The kubeconfig to use for deployments. User-provided values take priority over GitLab-provided values. |
-| `PRODUCTION_REPLICAS`                   | Number of replicas to deploy in the production environment. Takes precedence over `REPLICAS` and defaults to 1. For zero downtime upgrades, set to 2 or greater. |
+| `PRODUCTION_REPLICAS`                   | Number of replicas to deploy in the production environment. Takes precedence over `REPLICAS` and defaults to 1. For zero-downtime upgrades, set to 2 or greater. |
 | `REPLICAS`                              | Number of replicas to deploy. Defaults to 1. Change this variable instead of [modifying](customize.md#customize-helm-chart-values) `replicaCount`. |
 | `ROLLOUT_RESOURCE_TYPE`                 | Allows specification of the resource type being deployed when using a custom Helm chart. Default value is `deployment`. |
 | `ROLLOUT_STATUS_DISABLED`               | Used to disable rollout status check because it does not support all resource types, for example, `cronjob`. |
diff --git a/doc/update/package/index.md b/doc/update/package/index.md
index 5f13cb154f6..e3137cb30af 100644
--- a/doc/update/package/index.md
+++ b/doc/update/package/index.md
@@ -34,7 +34,7 @@ GitLab package.
 - For single node installations, GitLab is not available to users while an
   upgrade is in progress. The user's web browser shows a `Deploy in progress` message or a `502` error.
 - For multi-node installations, see how to perform
-  [zero downtime upgrades](../zero_downtime.md).
+  [zero-downtime upgrades](../zero_downtime.md).
 - Upgrades to multi-node installations can also be performed
   [with downtime](../with_downtime.md).
 
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index 6cc99a85a89..d852af46c41 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -333,7 +333,7 @@ sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workh
 
 ### 13. Update Gitaly
 
-If Gitaly is located on its own server, or you use Gitaly Cluster, see [Zero Downtime upgrades](zero_downtime.md).
+If Gitaly is located on its own server, or you use Gitaly Cluster, see [Zero-downtime upgrades](zero_downtime.md).
 
 #### Compile Gitaly
 
diff --git a/doc/update/versions/gitlab_14_changes.md b/doc/update/versions/gitlab_14_changes.md
index e8797c7b5a6..ec8d886c5c4 100644
--- a/doc/update/versions/gitlab_14_changes.md
+++ b/doc/update/versions/gitlab_14_changes.md
@@ -208,7 +208,7 @@ DETAILS:
 
 - In GitLab 14.8, we are upgrading Redis from 6.0.16 to 6.2.6. This upgrade is expected to be fully backwards compatible.
 
-  Follow [the zero downtime instructions](../zero_downtime.md) for upgrading your Redis HA cluster.
+  Follow [the zero-downtime instructions](../zero_downtime.md) for upgrading your Redis HA cluster.
 
 ### Geo installations
 
diff --git a/doc/update/versions/gitlab_16_changes.md b/doc/update/versions/gitlab_16_changes.md
index 8bd708a9d31..d9bb9415fc4 100644
--- a/doc/update/versions/gitlab_16_changes.md
+++ b/doc/update/versions/gitlab_16_changes.md
@@ -881,7 +881,7 @@ Specific information applies to Linux package installations:
   mentioning that the installed Redis version is different than the one running is
   displayed at the end of reconfigure run until the restart is performed.
 
-  Follow [the zero downtime instructions](../zero_downtime.md) for upgrading your Redis HA cluster.
+  Follow [the zero-downtime instructions](../zero_downtime.md) for upgrading your Redis HA cluster.
 
 ### Self-compiled installations
 
diff --git a/doc/update/with_downtime.md b/doc/update/with_downtime.md
index 18afbeea23c..89210b4464e 100644
--- a/doc/update/with_downtime.md
+++ b/doc/update/with_downtime.md
@@ -23,7 +23,7 @@ relevant to your [upgrade path](index.md#upgrade-paths).
 For a single node installation, you must only [upgrade the GitLab package](package/index.md).
 
 The process for upgrading a number of components of a multi-node GitLab
-installation is the same as for zero downtime upgrades.
+installation is the same as for zero-downtime upgrades.
 The differences relate to the servers running Rails (Puma/Sidekiq) and
 the order of events.
 
@@ -94,7 +94,7 @@ following principles when upgrading those servers:
 
 ## Upgrade the Gitaly nodes (Praefect / Gitaly Cluster)
 
-If you're running Gitaly cluster, follow the [zero downtime process](zero_downtime.md)
+If you're running Gitaly cluster, follow the [zero-downtime process](zero_downtime.md)
 for Gitaly cluster.
 
 If you are using Amazon Machine Images (AMIs) on AWS, you can either upgrade the Gitaly nodes
@@ -199,7 +199,7 @@ DETAILS:
 **Tier:** Premium, Ultimate
 **Offering:** Self-managed
 
-Follow [the zero downtime instructions](zero_downtime.md)
+Follow [the zero-downtime instructions](zero_downtime.md)
 for upgrading your Redis HA cluster.
 
 ## Upgrade the Rails components
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index 6ffef7bb549..3023d9b4ff6 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -4,13 +4,13 @@ group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Zero downtime upgrades
+# Zero-downtime upgrades
 
 DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** Self-managed
 
-With Zero downtime upgrades, it's possible to upgrade a live GitLab environment without having to
+With zero-downtime upgrades, it's possible to upgrade a live GitLab environment without having to
 take it offline. This guide will take you through the core process of performing
 such an upgrade.
 
@@ -22,7 +22,7 @@ or management of third party services, such as AWS RDS, please refer to the resp
 
 ## Before you start
 
-Achieving _true_ Zero Downtime as part of an upgrade is notably difficult for any distributed application. The process detailed in
+Achieving _true_ zero downtime as part of an upgrade is notably difficult for any distributed application. The process detailed in
 this guide has been tested as given against our HA [Reference Architectures](../administration/reference_architectures/index.md)
 and was found to result in effectively no observable downtime, but please be aware your mileage may vary dependent on the specific system makeup.
 
@@ -34,16 +34,16 @@ or the [Support team](https://about.gitlab.com/support/).
 
 ## Requirements and considerations
 
-The Zero downtime upgrade process has the following requirements:
+The zero-downtime upgrade process has the following requirements:
 
-- Zero downtime upgrades are only supported on multi-node GitLab environments built with the Linux package that have Load Balancing and HA mechanisms configured as follows:
+- Zero-downtime upgrades are only supported on multi-node GitLab environments built with the Linux package that have Load Balancing and HA mechanisms configured as follows:
   - External Load Balancer configured for Rails nodes with health checks enabled against the [Readiness](../administration/monitoring/health_check.md#readiness) (`/-/readiness`) endpoint.
   - Internal Load Balancer configured for any PgBouncer and Praefect components with TCP health checks enabled.
   - HA mechanisms configured for the Consul, Postgres and Redis components if present.
     - Any of these components that are not deployed in a HA fashion will need to be upgraded separately with downtime.
 - **You can only upgrade one minor release at a time**. So from `16.1` to `16.2`, not to `16.3`. If you skip releases, database modifications may be run in the wrong sequence [and leave the database schema in a broken state](https://gitlab.com/gitlab-org/gitlab/-/issues/321542).
 - You have to use [post-deployment migrations](../development/database/post_deployment_migrations.md).
-- [Zero Downtime Upgrades are not available with the GitLab Charts](https://docs.gitlab.com/charts/installation/upgrade.html). This in turn means this type of upgrade is not available for Cloud Native Hybrid environments.
+- [Zero-downtime upgrades are not available with the GitLab Charts](https://docs.gitlab.com/charts/installation/upgrade.html). This in turn means this type of upgrade is not available for Cloud Native Hybrid environments.
 
 In addition to the above, please be aware of the following considerations:
 
@@ -52,8 +52,8 @@ In addition to the above, please be aware of the following considerations:
   - Certain major or minor releases may require a set of background migrations to be finished. While this doesn't require downtime (if the above conditions are met), it's required that you [wait for background migrations to complete](index.md#check-for-background-migrations-before-upgrading) between each major or minor release upgrade.
   - The time necessary to complete these migrations can be reduced by increasing the number of Sidekiq workers that can process jobs in the
 `background_migration` queue. To see the size of this queue, [check for background migrations before upgrading](index.md#check-for-background-migrations-before-upgrading).
-- [PostgreSQL major version upgrades](../administration/postgresql/replication_and_failover.md#near-zero-downtime-upgrade-of-postgresql-in-a-patroni-cluster) are a separate process and not covered by Zero Downtime upgrades (smaller upgrades are covered).
-- Zero Downtime Upgrades are supported for any GitLab components you've deployed with the GitLab Linux package. If you've deployed select components via a supported third party service, such as PostgreSQL in AWS RDS or Redis in GCP Memorystore, upgrades for those services will need to be performed separately as per their standard processes.
+- [PostgreSQL major version upgrades](../administration/postgresql/replication_and_failover.md#near-zero-downtime-upgrade-of-postgresql-in-a-patroni-cluster) are a separate process and not covered by zero-downtime upgrades (smaller upgrades are covered).
+- Zero-downtime upgrades are supported for any GitLab components you've deployed with the GitLab Linux package. If you've deployed select components via a supported third party service, such as PostgreSQL in AWS RDS or Redis in GCP Memorystore, upgrades for those services will need to be performed separately as per their standard processes.
 - As a general guideline, the larger amount of data you have, the more time it will take for the upgrade to complete. In testing, any database smaller than 10 GB shouldn't generally take longer than an hour, but your mileage may vary.
 
 NOTE:
@@ -61,7 +61,7 @@ If you want to upgrade multiple releases or do not meet these requirements [upgr
 
 ## Upgrade order
 
-We recommend a "back to front" approach for the order of what components to upgrade with Zero Downtime.
+We recommend a "back to front" approach for the order of what components to upgrade with zero downtime.
 Generally this would be stateful backends first, their dependents next and then the frontends accordingly.
 While the order of deployment can be changed, it is best to deploy the components running GitLab application code (Rails, Sidekiq) together. If possible, upgrade the supporting infrastructure (PostgreSQL, PgBouncer, Consul, Gitaly, Praefect, Redis) separately since these components do not have dependencies on changes made in version updates within a major release.
 As such, we generally recommend the following order:
diff --git a/doc/user/group/epics/index.md b/doc/user/group/epics/index.md
index 4640774732e..4f6f960f59c 100644
--- a/doc/user/group/epics/index.md
+++ b/doc/user/group/epics/index.md
@@ -10,8 +10,11 @@ DETAILS:
 **Tier:** Premium, Ultimate
 **Offering:** GitLab.com, Self-managed, GitLab Dedicated
 
+An epic in GitLab describes a large body of work that can be broken down into smaller parts.
+Epics organize issues and features into a high-level theme or goal.
+
 When [issues](../../project/issues/index.md) share a theme across projects and
-milestones, you can manage them by using epics.
+milestones, you can group them by using epics.
 
 You can also create child epics and assign start and end dates, which creates
 a visual roadmap for you to view progress.
diff --git a/doc/user/group/iterations/index.md b/doc/user/group/iterations/index.md
index 5029a062af6..76b4367bcfd 100644
--- a/doc/user/group/iterations/index.md
+++ b/doc/user/group/iterations/index.md
@@ -15,8 +15,11 @@ DETAILS:
 > - Moved to GitLab Premium in 13.9.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/221047) in GitLab 14.6. [Feature flag `group_iterations`](https://gitlab.com/gitlab-org/gitlab/-/issues/221047) removed.
 
-Iterations are a way to track issues over a period of time. This allows teams
-to track velocity and volatility metrics. For tracking the same item over multiple concurrent periods, you can use iterations with [milestones](../../project/milestones/index.md).
+An iteration in GitLab refers to a time-boxed workflow that groups issues to be worked on during
+a specific period of time, usually lasting 1-3 weeks.
+
+Teams can use iterations to track velocity and volatility metrics.
+For tracking the same item over multiple concurrent periods, you can use iterations with [milestones](../../project/milestones/index.md).
 Create and manage various [iteration cadences](#iteration-cadences) in a group.
 
 For example, you can use:
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index bcfd9f59ecd..fe50f8b5811 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -131,11 +131,7 @@ Custom headers appear in [recent deliveries](#recently-triggered-webhook-payload
 ## Custom webhook template
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142738) in GitLab 16.10 [with a flag](../../../administration/feature_flags.md) named `custom_webhook_template`. Enabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is available. To hide the feature, an administrator can
-[disable the feature flag](../../../administration/feature_flags.md) named `custom_webhook_template`.
-On GitLab.com and GitLab Dedicated, this feature is available.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/439610) in GitLab 17.0. Feature flag `custom_webhook_template` removed.
 
 You can set a custom payload template in the webhook configuration. The request body is rendered from the template
 with the data for the current event. The template must render as valid JSON.
diff --git a/doc/user/project/labels.md b/doc/user/project/labels.md
index 780fddab841..26727374c5c 100644
--- a/doc/user/project/labels.md
+++ b/doc/user/project/labels.md
@@ -10,17 +10,21 @@ DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** GitLab.com, Self-managed, GitLab Dedicated
 
-As your count of issues, merge requests, and epics grows in GitLab, it gets more challenging
-to keep track of those items. Especially as your organization grows from just a few people to
+Labels are a way to categorize and filter issues, merge requests, and epics in GitLab.
+
+As your projects grow in GitLab, it gets more challenging to keep track of the work that's done.
+Especially as your organization grows from just a few people to
 hundreds or thousands. With labels, you can organize and tag your work, and track the work items
 you're interested in.
 
-Labels are a key part of [issue boards](issue_board.md). With labels you can:
+Labels are a key part of [issue boards](issue_board.md).
 
-- Categorize [epics](../group/epics/index.md), issues, and merge requests using colors and descriptive titles like
-  `bug`, `feature request`, or `docs`.
-- Dynamically filter and manage [epics](../group/epics/index.md), issues, and merge requests.
-- Search lists of issues, merge requests, and epics, as well as issue boards.
+Use labels on [epics](../group/epics/index.md), issues, and merge requests to:
+
+- Categorize items using colors and descriptive titles like `bug`, `feature request`, or `docs`.
+- Dynamically filter and manage items to view work that's in progress or completed.
+- Search lists and boards.
+- Communicate priority or severity of items, using [scoped labels](#scoped-labels).
 
 ## Types of labels
 
diff --git a/doc/user/tasks.md b/doc/user/tasks.md
index 46db0ddeb4f..ac40c7f8577 100644
--- a/doc/user/tasks.md
+++ b/doc/user/tasks.md
@@ -14,23 +14,21 @@ DETAILS:
 > - [Creating, editing, and deleting tasks](https://gitlab.com/groups/gitlab-org/-/epics/7169) introduced in GitLab 15.0.
 > - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/334812) in GitLab 15.3.
 
-Known limitation:
-
-- [Tasks cannot be accessed via REST API.](https://gitlab.com/gitlab-org/gitlab/-/issues/368055)
-
-For the latest updates, check the [Tasks Roadmap](https://gitlab.com/groups/gitlab-org/-/epics/7103).
-
 FLAG:
 On self-managed GitLab, by default this feature is available. To hide the feature,
 an administrator can [disable the feature flags](../administration/feature_flags.md) named `work_items`.
 On GitLab.com, this feature is available. On GitLab Dedicated, this feature is not available.
 
-Use tasks to track steps needed for the [issue](project/issues/index.md) to be closed.
+A task in GitLab is a planning item that can be created in an issue.
+Use tasks to break down user stories captured in [issues](project/issues/index.md) into
+smaller, trackable items.
 
 When planning an issue, you need a way to capture and break down technical
 requirements or steps necessary to complete it. An issue with related tasks is better defined,
 and so you can provide a more accurate issue weight and completion criteria.
 
+For the latest updates, check the [Tasks roadmap](https://gitlab.com/groups/gitlab-org/-/epics/7103).
+
 Tasks are a type of work item, a step towards [default issue types](https://gitlab.com/gitlab-org/gitlab/-/issues/323404)
 in GitLab.
 For the roadmap of migrating issues and [epics](group/epics/index.md)
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index 71287b27e26..35c680722c9 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -33989,6 +33989,9 @@ msgstr ""
 msgid "No milestone"
 msgstr ""
 
+msgid "No more seats in subscription"
+msgstr ""
+
 msgid "No more than %{max_issues} issues can be updated at the same time"
 msgstr ""
 
@@ -59791,6 +59794,9 @@ msgstr ""
 msgid "Your name"
 msgstr ""
 
+msgid "Your namespace has used all the seats in your subscription and users can no longer be invited or added to the namespace."
+msgstr ""
+
 msgid "Your namespace storage is full. This merge request cannot be merged. To continue, %{link_start}manage your storage usage%{link_end}."
 msgstr ""
 
diff --git a/scripts/lint/unused_helper_methods.rb b/scripts/lint/unused_helper_methods.rb
index cb040b300e6..2fa5c0db693 100755
--- a/scripts/lint/unused_helper_methods.rb
+++ b/scripts/lint/unused_helper_methods.rb
@@ -16,7 +16,7 @@ start = Process.clock_gettime(Process::CLOCK_MONOTONIC)
 # Build an array of filename globs to process.
 # Only search file types that might use or define a helper.
 #
-extensions = %w[rb haml erb].map { |ext| "{ee/,}app/**/*.#{ext}" }
+extensions = %w[rb haml erb].flat_map { |ext| ["{ee/,}app/**/*.#{ext}", "{ee/,}lib/**/*.#{ext}"] }
 
 # Build a hash of all the source files to search.
 # Key is filename, value is an array of the lines.
diff --git a/spec/frontend/work_items/components/work_item_relationships/__snapshots__/work_item_relationship_list_spec.js.snap b/spec/frontend/work_items/components/work_item_relationships/__snapshots__/work_item_relationship_list_spec.js.snap
index d1b2f728e43..b5fd8cb4fab 100644
--- a/spec/frontend/work_items/components/work_item_relationships/__snapshots__/work_item_relationship_list_spec.js.snap
+++ b/spec/frontend/work_items/components/work_item_relationships/__snapshots__/work_item_relationship_list_spec.js.snap
@@ -5,7 +5,7 @@ exports[`WorkItemRelationshipList renders linked item list 1`] = `
   data-testid="work-item-linked-items-list"
 >
   <h4
-    class="gl-font-sm gl-font-weight-semibold gl-mb-0! gl-mt-3 gl-text-gray-700"
+    class="gl-font-sm gl-font-weight-semibold gl-mb-2 gl-ml-3 gl-mt-3 gl-text-gray-700"
     data-testid="work-items-list-heading"
   >
     Blocking
diff --git a/spec/services/web_hook_service_spec.rb b/spec/services/web_hook_service_spec.rb
index 266b6b8f472..7bb01f37ce6 100644
--- a/spec/services/web_hook_service_spec.rb
+++ b/spec/services/web_hook_service_spec.rb
@@ -404,20 +404,6 @@ RSpec.describe WebHookService, :request_store, :clean_gitlab_redis_shared_state,
               .once
           end
         end
-
-        context 'when feature flag is disabled' do
-          before do
-            stub_feature_flags(custom_webhook_template: false)
-          end
-
-          it 'does not render custom template', :aggregate_failures do
-            service_instance.execute
-
-            expect(WebMock).to have_requested(:post, stubbed_hostname(project_hook.url))
-              .with(headers: headers, body: '{"before":"oldrev","after":"newrev","ref":"ref"}')
-              .once
-          end
-        end
       end
 
       context 'when template is invalid' do
diff --git a/spec/support/rspec_order_todo.yml b/spec/support/rspec_order_todo.yml
index f9c8bf894d3..c103a96552a 100644
--- a/spec/support/rspec_order_todo.yml
+++ b/spec/support/rspec_order_todo.yml
@@ -802,7 +802,6 @@
 - './ee/spec/graphql/types/vulnerabilities/container_image_type_spec.rb'
 - './ee/spec/graphql/types/vulnerabilities_count_by_day_type_spec.rb'
 - './ee/spec/graphql/types/vulnerabilities/link_type_spec.rb'
-- './ee/spec/graphql/types/vulnerability_confidence_enum_spec.rb'
 - './ee/spec/graphql/types/vulnerability_details/base_type_spec.rb'
 - './ee/spec/graphql/types/vulnerability_details/boolean_type_spec.rb'
 - './ee/spec/graphql/types/vulnerability_details/code_type_spec.rb'