diff --git a/.devcontainer/Dockerfile b/.devcontainer/Dockerfile
index 3eb2c5b8fb18..ae161e4f1bdc 100644
--- a/.devcontainer/Dockerfile
+++ b/.devcontainer/Dockerfile
@@ -1,3 +1,3 @@
 # To find available Node images, see https://mcr.microsoft.com/en-us/product/devcontainers/javascript-node/tags
-ARG VARIANT=dev-24-bullseye
-FROM mcr.microsoft.com/devcontainers/javascript-node:dev-24-bullseye@sha256:3502f1f21b1989500e8c72ada7d6e496dc4540b0707d4ea4ff743077f88a6c2d
+ARG VARIANT=dev-24-bookworm
+FROM mcr.microsoft.com/devcontainers/javascript-node:dev-24-bookworm@sha256:0a13d22653dd10688a2cb0567eb6d9578e43f24019a98d900ece1112269b66ba
diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index 83236bcee94f..a8d17e5cbc20 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -42,7 +42,9 @@ updates:
   - package-ecosystem: 'docker'
     registries:
       - ghcr
-    directory: '/'
+    directories:
+      - '/'
+      - '/.devcontainer'
     schedule:
       interval: daily
     cooldown:
diff --git a/content/copilot/concepts/agents/copilot-cli/rubber-duck.md b/content/copilot/concepts/agents/copilot-cli/rubber-duck.md
index ffb01eb743ae..8436584cd772 100644
--- a/content/copilot/concepts/agents/copilot-cli/rubber-duck.md
+++ b/content/copilot/concepts/agents/copilot-cli/rubber-duck.md
@@ -20,9 +20,6 @@ Rubber duck is a built-in agent in {% data variables.copilot.copilot_cli %} that
 
 The rubber duck agent is designed to review proposed changes, not to make file changes itself. The main agent for the session decides what to do with the feedback.
 
-> [!NOTE]
-> The rubber duck agent is currently only available if the main agent is using a Claude or GPT large language model.
-
 ## Why "rubber duck"?
 
 The name comes from a long-standing technique in software engineering called **rubber ducking** in which you explain your code, or proposed solution, to an inanimate object—traditionally a rubber duck. The idea is that by articulating your thinking, you often uncover mistakes, misunderstandings, or logical flaws.
diff --git a/content/copilot/concepts/agents/copilot-memory.md b/content/copilot/concepts/agents/copilot-memory.md
index 7306356cd42b..db1a0829bbda 100644
--- a/content/copilot/concepts/agents/copilot-memory.md
+++ b/content/copilot/concepts/agents/copilot-memory.md
@@ -33,7 +33,7 @@ We typically refer to these repository-level facts and user-level preferences as
 
 ## Feature availability
 
-{% data variables.copilot.copilot_memory %} is currently used by {% data variables.copilot.copilot_cloud_agent %}, {% data variables.copilot.copilot_code-review_short %}, and {% data variables.copilot.copilot_cli_short %}.
+{% data variables.copilot.copilot_memory %} is currently used by {% data variables.copilot.copilot_cloud_agent %}, {% data variables.copilot.copilot_code-review_short %}, {% data variables.copilot.copilot_cli_short %}, and agentic autofix.
 
 Facts and preferences captured by one {% data variables.product.prodname_copilot_short %} feature can be used by another. For example, if {% data variables.copilot.copilot_cloud_agent %} discovers how your repository handles database connections, {% data variables.copilot.copilot_code-review_short %} can later apply that knowledge to spot inconsistent patterns in a pull request. Similarly, if {% data variables.copilot.copilot_code-review_short %} learns that certain settings must stay synchronized across two files, {% data variables.copilot.copilot_cloud_agent %} will know to update both files when changing one.
 
diff --git a/content/copilot/get-started/enterprise-ai-governance.md b/content/copilot/get-started/enterprise-ai-governance.md
index 52f14fb3c208..9ffab61f3e83 100644
--- a/content/copilot/get-started/enterprise-ai-governance.md
+++ b/content/copilot/get-started/enterprise-ai-governance.md
@@ -38,6 +38,7 @@ journeyTracks:
     title: 'Enabling agents'
     description: 'Roll out and monitor agentic features.'
     guides:
+      - href: '/copilot/tutorials/roll-out-at-scale/enable-developers/drive-team-agentic-adoption'
       - href: '/copilot/tutorials/roll-out-at-scale/enable-developers/copilot-app-for-teams'
       - href: '/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/enable-copilot-cloud-agent'
       - href: '/copilot/tutorials/cloud-agent/give-access-to-resources'
diff --git a/content/copilot/how-tos/administer-copilot/manage-for-enterprise/use-managed-settings/override-settings-for-teams.md b/content/copilot/how-tos/administer-copilot/manage-for-enterprise/use-managed-settings/override-settings-for-teams.md
index c8382a38c2be..a219ffc07e6c 100644
--- a/content/copilot/how-tos/administer-copilot/manage-for-enterprise/use-managed-settings/override-settings-for-teams.md
+++ b/content/copilot/how-tos/administer-copilot/manage-for-enterprise/use-managed-settings/override-settings-for-teams.md
@@ -18,9 +18,9 @@ To make a key eligible for team overrides, you will mark it as `overridable` in
 
 ## Supported keys
 
-The `{ "overridable": <VALUE> }` syntax applies to the `model`, `permissions.disableBypassPermissionsMode`, `permissions.deny`, `permissions.ask`, `permissions.allow`, `allowedMcpServers`, and `deniedMcpServers` keys.
+The `{ "overridable": <VALUE> }` syntax applies to the `model`, `permissions.disableBypassPermissionsMode`, `permissions.deny`, `permissions.ask`, `permissions.allow`, `allowedMcpServers`, `deniedMcpServers`, `extraKnownMarketplaces`, `strictKnownMarketplaces`, and `sandbox` keys.
 
-`enabledPlugins` and `extraKnownMarketplaces` work additively. The enterprise `{% data variables.copilot.managed_setting_file %}` sets a baseline, and an enterprise team file can add more plugins and marketplaces on top of it.
+`enabledPlugins` works additively. The enterprise `{% data variables.copilot.managed_setting_file %}` sets a baseline, and an enterprise team file can add more plugins on top of it.
 
 For a full description of these keys and their syntax, see [AUTOTITLE](/copilot/reference/enterprise-administrators/enterprise-managed-settings).
 
@@ -64,7 +64,7 @@ You will use `copilot/{% data variables.copilot.team_mappings_file %}` and the `
     }
     ```
 
-1. Create the team settings file under `copilot/{% data variables.copilot.team_settings_directory %}`. You can include any keys you marked as overridable, plus the additive keys `enabledPlugins` and `extraKnownMarketplaces`. Every other key stays governed by your enterprise default.
+1. Create the team settings file under `copilot/{% data variables.copilot.team_settings_directory %}`. You can include any keys you marked as overridable, plus the additive key `enabledPlugins`. Every other key stays governed by your enterprise default.
 
    ```json
    {
diff --git a/content/copilot/how-tos/github-copilot-app/agent-sessions.md b/content/copilot/how-tos/github-copilot-app/agent-sessions.md
index 6b5863871b9b..e05ade0c17d7 100644
--- a/content/copilot/how-tos/github-copilot-app/agent-sessions.md
+++ b/content/copilot/how-tos/github-copilot-app/agent-sessions.md
@@ -91,9 +91,6 @@ The rubber duck agent is a built-in agent that acts as a constructive critic, re
 
 When rubber duck is enabled, {% data variables.product.prodname_copilot_short %} can consult it automatically at key points while it works. The main session agent passes work to the rubber duck agent, receives the critique, then decides how to apply that feedback before continuing.
 
-> [!NOTE]
-> The rubber duck agent is currently only available if the main agent is using a Claude or GPT large language model.
-
 You can also manually ask {% data variables.product.prodname_copilot_short %} to get a review from the rubber duck agent.
 
 1. Open an active session.
diff --git a/content/copilot/reference/copilot-usage-metrics/copilot-usage-metrics.md b/content/copilot/reference/copilot-usage-metrics/copilot-usage-metrics.md
index 52a82f44f621..809d2ccd008c 100644
--- a/content/copilot/reference/copilot-usage-metrics/copilot-usage-metrics.md
+++ b/content/copilot/reference/copilot-usage-metrics/copilot-usage-metrics.md
@@ -90,17 +90,15 @@ Organization-scope reports also include `organization_id` alongside `enterprise_
 
 The **Type** column uses JSON Schema types: `string`, `integer`, `number`, `boolean`, `array`, and `object`. The **Nullable** column indicates whether a field's value can be `null` or absent from a record where it would otherwise apply. Activity breakdown arrays are always present but can be empty (`[]`). Optional arrays are marked as nullable and can be absent.
 
-### Report identification and partition fields
+### Report identification fields
 
-These fields identify the scope, date, and (for exports) partition of each record. The exact set present depends on the report shape.
+These fields identify the scope and date of each record. The exact set present depends on the report shape.
 
 | Field | Type | Nullable | Description |
 |:--|:--|:--|:--|
 | `day` | `string` | No | Calendar day this record represents, in `YYYY-MM-DD` format. In 28-day reports, `day` appears within each `day_totals` entry rather than at the top level. |
 | `enterprise_id` | `string` | No | Unique ID of the enterprise. Included in both enterprise- and organization-scope reports. |
 | `organization_id` | `string` | Yes | Unique ID of the organization. Included in organization-scope reports only; omitted from enterprise-scope reports. |
-| `etl_id` / `day_partition` | `string` | No | Partition fields used for housekeeping. Included in exported NDJSON files and returned by the usage metrics APIs. |
-| `entity_id_partition` | `integer` | No | Entity partition used for housekeeping. Included in exported NDJSON files and returned by the usage metrics APIs. |
 
 ### Per-user report fields
 
@@ -126,6 +124,7 @@ Per-user reports contain one record per user for the reporting period. The 28-da
 | `used_copilot_cloud_agent` | `boolean` | No | Whether the user used {% data variables.copilot.copilot_cloud_agent %} that day. Carries the same value as `used_copilot_coding_agent`; both names are retained for backward compatibility. |
 | `used_copilot_code_review_active` | `boolean` | Yes | Whether the user actively engaged with {% data variables.copilot.copilot_code-review_short %} that day. A user is considered active if they manually requested a {% data variables.product.prodname_copilot_short %} review, or applied a {% data variables.product.prodname_copilot_short %} review suggestion. Null when there is no {% data variables.copilot.copilot_code-review_short %} signal for the user that day. |
 | `used_copilot_code_review_passive` | `boolean` | Yes | Whether the user had {% data variables.product.prodname_copilot_short %} automatically assigned to review their pull request that day, without actively engaging with the review. Null when there is no {% data variables.copilot.copilot_code-review_short %} signal for the user that day. |
+| `used_vscode_agent` | `boolean` | Yes | Whether the user used the dedicated {% data variables.product.prodname_vscode_shortname %} Agents window during the reporting period. Omitted when no dedicated Agents-window data is available for the user. |
 | `ai_adoption_phase` | `object` | No | The user's AI adoption phase for the day. Always present; defaults to the "No Cohort" phase. See [AI adoption phase fields](#ai-adoption-phase-fields). |
 | `distinct_skill_use_count` | `integer` | Yes | Number of different skill identifiers with recorded activity for the user. See [{% data variables.copilot.copilot_cli_short %} customization fields](#copilot-cli-customization-fields-api-only). |
 | `distinct_custom_agent_use_count` | `integer` | Yes | Number of different custom agent identifiers with recorded activity for the user. See [{% data variables.copilot.copilot_cli_short %} customization fields](#copilot-cli-customization-fields-api-only). |
@@ -140,6 +139,7 @@ Per-user reports contain one record per user for the reporting period. The 28-da
 | `totals_by_cli` | `object` | Yes | CLI-specific metrics for the user. Omitted when the user had no {% data variables.copilot.copilot_cli_short %} usage that day. See [{% data variables.copilot.copilot_cli_short %} metrics fields](#copilot-cli-metrics-fields). |
 | `totals_by_copilot_app` | `object` | Yes | {% data variables.copilot.github_copilot_app_short %} metrics for the user. Omitted when the user had no {% data variables.copilot.github_copilot_app_short %} usage that day. See [{% data variables.copilot.github_copilot_app_short %} metrics fields](#copilot-app-metrics-fields). |
 | `totals_by_3rd_party_agent` | `array` | Yes | Per-agent usage metrics for recognized {% data variables.copilot.agent_apps %}. Omitted when the user had no recognized {% data variables.copilot.agent_app %} activity during the reporting period. See [{% data variables.copilot.agent_apps_caps %} metrics fields](#agent-apps-metrics-fields). |
+| `totals_by_vscode_agent` | `object` | Yes | Dedicated {% data variables.product.prodname_vscode_shortname %} Agents-window metrics for the user. Omitted when both required counts are not available. See [{% data variables.product.prodname_vscode_shortname %} Agents-window metrics fields](#vs-code-agents-window-metrics-fields). |
 | `totals_by_ide` | `array` | No | Per-IDE breakdown of the user's activity. See [Activity breakdown objects](#activity-breakdown-objects). |
 | `totals_by_feature` | `array` | No | Per-feature breakdown of the user's activity. See [Activity breakdown objects](#activity-breakdown-objects). |
 | `totals_by_language_feature` | `array` | No | Breakdown combining language and feature dimensions. See [Activity breakdown objects](#activity-breakdown-objects). |
@@ -156,7 +156,9 @@ Active-user counts:
 |:--|:--|:--|:--|
 | `daily_active_users` | `integer` | No | Number of unique users who used {% data variables.product.prodname_copilot_short %} on a given day. |
 | `weekly_active_users` | `integer` | No | Number of unique users who used {% data variables.product.prodname_copilot_short %} during a trailing seven-day window. |
+| `weekly_active_vscode_agent_users` | `integer` | Yes | Number of unique users who used the dedicated {% data variables.product.prodname_vscode_shortname %} Agents window from Sunday through the report day, inclusive. This calendar-to-date count is not a trailing seven-day window. |
 | `monthly_active_users` | `integer` | No | Number of unique users who used {% data variables.product.prodname_copilot_short %} during a trailing 28-day window. |
+| `monthly_active_vscode_agent_users` | `integer` | Yes | Number of unique users who used the dedicated {% data variables.product.prodname_vscode_shortname %} Agents window from the first day of the calendar month through the report day, inclusive. This calendar-to-date count is not a trailing 28-day window. |
 | `monthly_active_chat_users` | `integer` | No | Number of unique users who used chat during a trailing 28-day window. |
 | `monthly_active_agent_users` | `integer` | No | Number of unique users who used agent mode during a trailing 28-day window. |
 | `daily_active_copilot_cloud_agent_users` | `integer` | No | Number of unique users who used {% data variables.copilot.copilot_cloud_agent %} on a given day. |
@@ -170,6 +172,7 @@ Active-user counts:
 | `monthly_passive_copilot_code_review_users` | `integer` | No | Number of unique users who had {% data variables.copilot.copilot_code-review_short %} automatically assigned to review their pull request during a trailing 28-day window, with no active engagement. |
 | `daily_active_cli_users` | `integer` | Yes | Number of unique users who used {% data variables.copilot.copilot_cli_short %} on a given day. This count is **independent** of IDE active-user counts and is **not** included in IDE-based active-user definitions. Omitted for enterprises or organizations with no CLI usage that day. |
 | `daily_active_copilot_app_users` | `integer` | Yes | Number of unique users who used the {% data variables.copilot.github_copilot_app_short %} on a given day. Null when the enterprise or organization has no {% data variables.copilot.github_copilot_app_short %} activity that day. |
+| `daily_active_vscode_agent_users` | `integer` | Yes | Number of unique users who used the dedicated {% data variables.product.prodname_vscode_shortname %} Agents window on a given day. Omitted when no dedicated Agents-window data is available for the enterprise or organization. |
 
 Activity totals and breakdowns:
 
@@ -200,6 +203,7 @@ Activity totals and breakdowns:
 | `totals_by_cli` | `object` | Yes | Aggregated {% data variables.copilot.copilot_cli_short %} metrics for the day. Omitted when there is no CLI usage that day. Unlike the per-user form, it does not include `last_known_cli_version`. See [{% data variables.copilot.copilot_cli_short %} metrics fields](#copilot-cli-metrics-fields). |
 | `totals_by_copilot_app` | `object` | Yes | Aggregated {% data variables.copilot.github_copilot_app_short %} metrics for the day. Null when the enterprise or organization has no {% data variables.copilot.github_copilot_app_short %} activity that day. See [{% data variables.copilot.github_copilot_app_short %} metrics fields](#copilot-app-metrics-fields). |
 | `totals_by_3rd_party_agent` | `array` | Yes | Aggregated per-agent usage metrics for recognized {% data variables.copilot.agent_apps %}. Omitted when the enterprise or organization had no recognized {% data variables.copilot.agent_app %} activity that day. See [{% data variables.copilot.agent_apps_caps %} metrics fields](#agent-apps-metrics-fields). |
+| `totals_by_vscode_agent` | `object` | Yes | Aggregated dedicated {% data variables.product.prodname_vscode_shortname %} Agents-window metrics for the day. Omitted when both required counts are not available. See [{% data variables.product.prodname_vscode_shortname %} Agents-window metrics fields](#vs-code-agents-window-metrics-fields). |
 | `totals_by_ai_adoption_phase` | `array` | Yes | Per-phase aggregates of users and their average activity. Omitted when no adoption-phase data is available. See [AI adoption phase fields](#ai-adoption-phase-fields). |
 | `pull_requests` | `object` | No | Daily pull request activity for the enterprise or organization. See [Pull request activity fields](#pull-request-activity-fields). |
 
@@ -353,6 +357,24 @@ The `totals_by_copilot_app` object contains the following nested fields when {%
 | `totals_by_copilot_app.token_usage.prompt_tokens_sum` | `integer` | No | Total prompt tokens sent across all {% data variables.copilot.github_copilot_app_short %} requests on this day. |
 | `totals_by_copilot_app.token_usage.avg_tokens_per_request` | `number` | Yes | Average of output and prompt tokens per {% data variables.copilot.github_copilot_app_short %} request, computed as `(output_tokens_sum + prompt_tokens_sum) ÷ request_count`. Null when there were no requests that day. |
 
+### {% data variables.product.prodname_vscode_shortname %} Agents-window metrics fields
+
+The dedicated {% data variables.product.prodname_vscode_shortname %} Agents-window fields appear in enterprise, organization, enterprise-user, and organization-user 1-day and 28-day reports. In aggregated 28-day reports, they appear within each applicable `day_totals` entry, and weekly and monthly counts are calculated relative to the `day` of each entry. In per-user 28-day reports, they appear at the top level of each user record.
+
+These fields are distinct from editor-window agent mode, including `used_agent`, `monthly_active_agent_users`, and the `chat_panel_agent_mode` and `agent_edit` feature values. Dedicated Agents-window activity is not included in generic top-level activity totals or dimensional breakdowns such as `totals_by_feature`, `totals_by_model_feature`, or `totals_by_ai_adoption_phase`.
+
+The daily count and per-user fields can be omitted when no dedicated Agents-window data is available. The weekly and monthly fields are both omitted when there is no qualifying activity in either period. If one period has qualifying activity and the other does not, the inactive period has a value of `0`. The `totals_by_vscode_agent` object appears only when both nested counts are available, including when both counts are zero.
+
+| Field | Type | Nullable | Description |
+|:--|:--|:--|:--|
+| `daily_active_vscode_agent_users` | `integer` | Yes | Number of unique users who used the dedicated {% data variables.product.prodname_vscode_shortname %} Agents window on the day. Aggregated enterprise and organization reports only. |
+| `weekly_active_vscode_agent_users` | `integer` | Yes | Number of unique users who used the dedicated Agents window from Sunday through the report day, inclusive. Aggregated enterprise and organization reports only. |
+| `monthly_active_vscode_agent_users` | `integer` | Yes | Number of unique users who used the dedicated Agents window from the first day of the calendar month through the report day, inclusive. Aggregated enterprise and organization reports only. |
+| `used_vscode_agent` | `boolean` | Yes | Whether the user used the dedicated {% data variables.product.prodname_vscode_shortname %} Agents window during the reporting period. Enterprise-user and organization-user reports only. |
+| `totals_by_vscode_agent` | `object` | Yes | Session and user-message totals for the dedicated {% data variables.product.prodname_vscode_shortname %} Agents window. |
+| `totals_by_vscode_agent.session_count` | `integer` | No | Number of distinct Agents-window sessions represented in the record. Required when `totals_by_vscode_agent` is present. |
+| `totals_by_vscode_agent.total_user_messages` | `integer` | No | Number of user messages sent in the Agents window represented in the record. Required when `totals_by_vscode_agent` is present. |
+
 ### {% data variables.copilot.agent_apps_caps %} metrics fields
 
 > [!NOTE]
diff --git a/content/copilot/reference/copilot-usage-metrics/example-schema.md b/content/copilot/reference/copilot-usage-metrics/example-schema.md
index 1977434a5cfd..c33b7903074f 100644
--- a/content/copilot/reference/copilot-usage-metrics/example-schema.md
+++ b/content/copilot/reference/copilot-usage-metrics/example-schema.md
@@ -144,6 +144,10 @@ The following examples show schemas for user-, enterprise-, and repository-level
     "mcp": "other"
   }],
   "totals_by_model_feature": [],
+  "totals_by_vscode_agent": {
+    "session_count": 1,
+    "total_user_messages": 1
+  },
   "totals_by_plugin": [{
     "interaction_count": 2,
     "plugin": "other"
@@ -167,16 +171,16 @@ The following examples show schemas for user-, enterprise-, and repository-level
   "used_copilot_code_review_active": null,
   "used_copilot_code_review_passive": null,
   "used_copilot_coding_agent": false,
+  "used_vscode_agent": true,
   "user_id": 1,
   "user_login": "login1",
-  "user_initiated_interaction_count": 1,
-  "etl_id": "green",
-  "day_partition": "2025-10-01",
-  "entity_id_partition": 1
+  "user_initiated_interaction_count": 1
 }]
 ```
 
-Organization per-user reports use the same `totals_by_3rd_party_agent` entry fields and also include `organization_id`. In per-user reports, entries in `totals_by_3rd_party_agent` do not include `session_count`.
+Organization per-user reports use the same `totals_by_3rd_party_agent` entry fields and also include `organization_id`. The per-user `totals_by_3rd_party_agent` entries omit `session_count`.
+
+In both enterprise and organization per-user reports, `used_vscode_agent` and `totals_by_vscode_agent` provide dedicated metrics for the {% data variables.product.prodname_vscode_shortname %} Agents window. These fields appear at the top level in both 1-day and 28-day reports. They are omitted when no dedicated {% data variables.product.prodname_vscode_shortname %} Agents-window data is available, and `totals_by_vscode_agent` is omitted unless both of its counts are available.
 
 The {% data variables.copilot.copilot_cli_short %} customization fields shown in this example appear in both 1-day and 28-day per-user reports.
 
@@ -194,6 +198,7 @@ In this example, `used_copilot_code_review_active` and `used_copilot_code_review
     "daily_active_copilot_cloud_agent_users" : 1,
     "daily_active_copilot_code_review_users" : 1,
     "daily_active_users" : 2,
+    "daily_active_vscode_agent_users" : 2,
     "daily_passive_copilot_code_review_users" : 0,
     "day" : "2025-10-01",
     "distinct_custom_agent_use_count" : 2,
@@ -211,6 +216,7 @@ In this example, `used_copilot_code_review_active` and `used_copilot_code_review
     "monthly_active_copilot_cloud_agent_users" : 1,
     "monthly_active_copilot_code_review_users" : 1,
     "monthly_active_users" : 2,
+    "monthly_active_vscode_agent_users" : 2,
     "monthly_passive_copilot_code_review_users" : 0,
     "pull_requests" : {
       "median_minutes_to_merge" : 2.5,
@@ -358,6 +364,10 @@ In this example, `used_copilot_code_review_active` and `used_copilot_code_review
       "mcp" : "other"
     } ],
     "totals_by_model_feature" : [ ],
+    "totals_by_vscode_agent" : {
+      "session_count" : 2,
+      "total_user_messages" : 2
+    },
     "totals_by_plugin" : [ {
       "interaction_count" : 4,
       "plugin" : "other"
@@ -377,6 +387,7 @@ In this example, `used_copilot_code_review_active` and `used_copilot_code_review
     "weekly_active_copilot_cloud_agent_users" : 1,
     "weekly_active_copilot_code_review_users" : 1,
     "weekly_active_users" : 2,
+    "weekly_active_vscode_agent_users" : 2,
     "weekly_passive_copilot_code_review_users" : 0
   } ],
   "enterprise_id" : "1",
@@ -406,10 +417,7 @@ In this example, `used_copilot_code_review_active` and `used_copilot_code_review
     } ]
   },
   "report_end_day" : "2025-10-01",
-  "report_start_day" : "2025-09-04",
-  "etl_id" : "green",
-  "day_partition" : "2025-10-01",
-  "entity_id_partition" : 1
+  "report_start_day" : "2025-09-04"
 }, {
   "day_totals" : [ {
     "code_acceptance_activity_count" : 2,
@@ -571,10 +579,7 @@ In this example, `used_copilot_code_review_active` and `used_copilot_code_review
     } ]
   },
   "report_end_day" : "2025-10-01",
-  "report_start_day" : "2025-09-04",
-  "etl_id" : "green",
-  "day_partition" : "2025-10-01",
-  "entity_id_partition" : 2
+  "report_start_day" : "2025-09-04"
 } ]
 ```
 
diff --git a/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md b/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md
index 4f700e8d272a..6953b3b9856e 100644
--- a/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md
+++ b/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md
@@ -144,6 +144,25 @@ The following source types are supported:
 
 See [AUTOTITLE](/copilot/concepts/enterprise/plugin-standards).
 
+For server-managed enterprise team overrides, wrap the complete marketplace map in `overridable`:
+
+```json
+{
+  "extraKnownMarketplaces": {
+    "overridable": {
+      "enterprise-plugins": {
+        "source": {
+          "source": "github",
+          "repo": "OWNER/REPO"
+        }
+      }
+    }
+  }
+}
+```
+
+A team file can then provide a regular marketplace map to replace this default. Include any default marketplaces that the team should retain. If the team omits the key, the enterprise default remains.
+
 ## strictKnownMarketplaces
 
 Restricts plugin installation to only the marketplaces explicitly defined by the enterprise. An empty array means complete lockdown. Each entry is a marketplace object with a `source` property indicating the source type. The following source types are supported:
@@ -157,6 +176,20 @@ Restricts plugin installation to only the marketplaces explicitly defined by the
 * `"hostPattern"` — requires `hostPattern` (regex matching marketplace hosts)
 * `"pathPattern"` — requires `pathPattern` (regex matching marketplace paths)
 
+This key is overridable for enterprise teams. Wrap the complete allowlist in `overridable` at the enterprise level:
+
+```json
+{
+  "strictKnownMarketplaces": {
+    "overridable": [
+      { "source": "github", "repo": "OWNER/REPO" }
+    ]
+  }
+}
+```
+
+Use a regular array in the team file to replace the default allowlist. Omitting the key retains the enterprise default. An explicit empty array, `[]`, means complete lockdown, not an unmanaged policy.
+
 ## model
 
 Sets your preferred model as the default for new conversations. This lets you choose the default model that best fits your enterprise's workflows. Users can still select a different model on a per-conversation basis.
@@ -288,6 +321,21 @@ The following sub-properties are supported:
 * `allowDevToolAccess`: `false` prevents automatic access to development-tool configuration, caches, registries, and toolchains. These locations can contain package registry credentials or tokens. Disabling access can cause package restoration, authenticated registry operations, or builds that use shared caches to fail unless you explicitly grant the required paths.
 * `userPolicy`: An object that configures filesystem, network, and macOS-specific Seatbelt restrictions. The supported properties are described in the following sections.
 
+For server-managed enterprise team overrides, wrap the entire sandbox object in `overridable`:
+
+```json
+{
+  "sandbox": {
+    "overridable": {
+      "enabled": true,
+      "allowBypass": false
+    }
+  }
+}
+```
+
+The wrapper must be the only property directly inside `sandbox`. Individual sub-properties, such as `sandbox.enabled`, cannot use their own `overridable` wrappers. A team file's regular sandbox object replaces the entire wrapped default, so include every restriction that should remain. Omitting `sandbox` retains the enterprise default.
+
 ### `sandbox.userPolicy.filesystem`
 
 Configures filesystem access for sandboxed processes. Paths should be absolute. Managed grant lists are matched against user-configured lists by exact path string, not by parent or child path coverage.
diff --git a/content/copilot/tutorials/roll-out-at-scale/drive-downstream-impact/index.md b/content/copilot/tutorials/roll-out-at-scale/drive-downstream-impact/index.md
index 5c23555182fb..115f121f4522 100644
--- a/content/copilot/tutorials/roll-out-at-scale/drive-downstream-impact/index.md
+++ b/content/copilot/tutorials/roll-out-at-scale/drive-downstream-impact/index.md
@@ -14,4 +14,3 @@ redirect_from:
   - /copilot/tutorials/rolling-out-github-copilot-at-scale/drive-downstream-impact
 contentType: tutorials
 ---
-
diff --git a/content/copilot/tutorials/roll-out-at-scale/enable-developers/drive-adoption.md b/content/copilot/tutorials/roll-out-at-scale/enable-developers/drive-adoption.md
index 5963944947d2..fdaa5d1796cd 100644
--- a/content/copilot/tutorials/roll-out-at-scale/enable-developers/drive-adoption.md
+++ b/content/copilot/tutorials/roll-out-at-scale/enable-developers/drive-adoption.md
@@ -16,6 +16,8 @@ category:
   - Manage Copilot for a team
 ---
 
+Use this guide for an initial organization-wide rollout: granting licenses, helping developers set up their environments, and providing broad training and support. For a focused rollout of agentic tools to an established team, see [AUTOTITLE](/copilot/tutorials/roll-out-at-scale/enable-developers/drive-team-agentic-adoption).
+
 An effective enablement process is essential to drive adoption of {% data variables.product.prodname_copilot_short %} in your organization. This process should be tailored to your organization's needs and goals, and should be designed to help your teams understand how to use {% data variables.product.prodname_copilot_short %} effectively.
 
 Your enablement process may evolve based on feedback and results. You should regularly review and update the process to ensure it continues to meet your organization's needs.
diff --git a/content/copilot/tutorials/roll-out-at-scale/enable-developers/drive-team-agentic-adoption.md b/content/copilot/tutorials/roll-out-at-scale/enable-developers/drive-team-agentic-adoption.md
new file mode 100644
index 000000000000..0a8fb365ed35
--- /dev/null
+++ b/content/copilot/tutorials/roll-out-at-scale/enable-developers/drive-team-agentic-adoption.md
@@ -0,0 +1,165 @@
+---
+title: Driving team adoption of agentic GitHub Copilot
+shortTitle: Drive agentic adoption
+allowTitleToDifferFromFilename: true
+intro: 'Help established teams build sustained habits with {% data variables.copilot.github_copilot_app %} and {% data variables.copilot.copilot_cli_short %}, then measure adoption and business impact.'
+versions:
+  feature: copilot
+contentType: tutorials
+category:
+  - Roll Copilot out at scale
+  - Manage Copilot for a team
+---
+
+After developers are using {% data variables.product.prodname_copilot_short %}, a focused rollout can help established teams add {% data variables.copilot.github_copilot_app %} and {% data variables.copilot.copilot_cli_short %} to their daily work. These tools complement IDE chat and agent mode. The goal is to help teams build repeatable agentic workflows with the tool that best fits each task.
+
+This playbook is for people who coordinate {% data variables.product.prodname_copilot_short %} adoption for established teams. It guides you through a two-week onboarding sprint to test workflow fit and establish usage habits. A two-week sprint provides an early signal of adoption, not enough evidence to prove long-term productivity or cost impact.
+
+## Before the sprint
+
+Identify a rollout coordinator and the people responsible for policies, licenses, metrics, security, support, and spending. Agree on who can pause the sprint or disable access if you find an unexpected policy, security, or cost issue.
+
+### Select and equip an initial team
+
+Start with one team or a small group of established teams. Participants are more likely to learn from each other, and you can distinguish team practices from individual preferences.
+
+Choose teams that have:
+
+* A manager or team lead who will model usage and discuss it in team meetings
+* One or more experienced individual contributors who can test advanced workflows, support peers, and turn successful experiments into team guidance
+* Work that suits agentic tools, such as investigating a codebase, making coordinated changes across files, running tests, or preparing pull requests
+* Stable delivery metrics that you can use as a baseline
+
+Avoid selecting only enthusiasts. Include a representative mix of experience levels so that the sprint reveals common setup, trust, and workflow barriers.
+
+Select a real project with enough suitable work for participants to use agentic tools several times during the sprint. Then prepare access:
+
+1. Confirm that each participant receives their {% data variables.product.prodname_copilot_short %} license through the organization whose policies will govern the sprint.
+1. Work with the appropriate enterprise and organization owners to enable the separate policies for {% data variables.copilot.github_copilot_app %} and {% data variables.copilot.copilot_cli_short %}.
+1. Confirm the scope before enabling a policy. Organization policies apply to everyone who receives their license through that organization, not only the selected team. Enterprise policies can also restrict which settings organization owners can change. For more information, see [AUTOTITLE](/copilot/concepts/enterprise/policies).
+1. Ask participants to install and sign in to both tools before the kickoff. See [AUTOTITLE](/copilot/get-started/quickstart-copilot-app) and [AUTOTITLE](/copilot/how-tos/copilot-cli/set-up-copilot-cli).
+1. Confirm that each participant can access the project and use the tools under the intended policies and managed settings.
+1. Give the person measuring the sprint access to {% data variables.product.prodname_copilot_short %} usage metrics. For the required role, see [AUTOTITLE](/copilot/concepts/copilot-usage-metrics/copilot-metrics).
+
+If you are enabling these tools for the first time, treat the sprint as part of a broader feature pilot. Before kickoff, estimate usage-based costs, set an appropriate budget with the intended stop behavior, and plan to monitor spending during the sprint. For a complete process, see [AUTOTITLE](/copilot/tutorials/roll-out-at-scale/govern-at-scale/pilot-a-feature-or-model).
+
+### Define activation and outcome targets
+
+Set an **activation** target for the onboarding sprint. For example, set a target for each participant to use either {% data variables.copilot.github_copilot_app_short %} or {% data variables.copilot.copilot_cli_short %} on at least three separate days in each week of the sprint. Repeated use gives participants time to try the tools on different tasks and decide where they fit into daily work.
+
+Pair the activation target with one or two **outcomes** that matter to the team. For example:
+
+* Reduce the time from starting work to opening a pull request.
+* Complete more maintenance tasks without delaying planned feature work.
+* Reduce time spent investigating unfamiliar code.
+* Maintain or improve review quality while increasing pull request throughput.
+
+Record a baseline for the outcomes before the sprint.
+
+Do not use the amount of generated code as a success target. More generated code does not necessarily create more value and can increase review or maintenance work.
+
+### Prepare workflows, tracking, and safeguards
+
+Instead of asking participants to "use AI more," give the team two or three **approved workflows** that match their current work. For example:
+
+* Use {% data variables.copilot.copilot_cli_short %} to investigate a failure, plan a multi-file change, run tests, or review local changes.
+* Use {% data variables.copilot.github_copilot_app_short %} to work from an issue, make changes in an agent session, and open a pull request.
+* Move between the tools when useful, for example by opening {% data variables.copilot.github_copilot_app_short %} from {% data variables.copilot.copilot_cli_short %} with `copilot app`.
+
+For each workflow, document the required human review, testing, and approval steps. If your enterprise uses custom instructions, agents, managed settings, or approved Model Context Protocol (MCP) servers, configure them before the sprint.
+
+Decide how the team will share examples and track progress. You can:
+
+* Add a temporary pull request label, such as `copilot-pilot`, so participants can find and discuss relevant examples.
+* Add a consistent marker to relevant commit messages, such as `Copilot-Assisted: true`, if your organization already analyzes commit metadata.
+* Prepare a team dashboard that shows the share of participants active on either tool on three or more days per week.
+* Choose an existing team meeting or channel where participants can share the task, workflow, and result without sharing prompts that may contain sensitive information.
+
+Labels and commit message markers provide self-reported context, not authoritative usage data. Use them to find examples and start conversations. Use {% data variables.product.prodname_copilot_short %} usage metrics to measure activity.
+
+Before kickoff, document:
+
+* Who will review access, policy behavior, agent activity, support issues, and spending during the sprint
+* How participants will report unexpected or unsafe behavior
+* Conditions that will pause or stop the sprint, such as an unintended policy scope, repeated unsafe results, or spending approaching the agreed limit
+* How the responsible owner will disable the tools or remove sprint-specific configuration
+
+## During the sprint
+
+In the first week, remove setup barriers and create shared experiences. In the second week, reinforce successful workflows and address barriers.
+
+### Week one: Launch and complete the first workflows
+
+1. **Launch with the whole team.** Explain the outcomes you want to improve, the activation target, and the guardrails participants must follow.
+1. **Demonstrate real work.** Ask the manager, team lead, or experienced contributor to complete one of the selected workflows in the team's codebase. Show where human review and approval remain required.
+1. **Complete a first task together.** Pair participants so that everyone starts a session in {% data variables.copilot.github_copilot_app_short %} or {% data variables.copilot.copilot_cli_short %} and completes a small, low-risk task.
+1. **Use the tools during normal work.** Ask participants to use at least one selected workflow on the number of days in your activation target. Avoid creating artificial exercises after the first task.
+1. **Check operations.** Confirm that policies and managed settings behave as intended. Review support and safety reports, and check usage-based spending against the agreed limit.
+
+### Week two: Reinforce useful workflows
+
+1. **Discuss usage in existing meetings.** Ask what the tools helped with, when participants chose another {% data variables.product.prodname_copilot_short %} tool or feature, and what blocked them.
+1. **Respond to workflow barriers.** Use the following actions:
+   * **Another tool fit the task better**: Keep the existing workflow for that task and focus the sprint on work that benefits from the selected tools.
+   * **The participant did not know how to start**: Provide a tested starter prompt for one of the selected workflows.
+   * **The agent lacked context or produced poor results**: Improve repository instructions, task descriptions, or available tools, then test the workflow again.
+   * **The participant did not trust the result**: Demonstrate how to review diffs, restrict permissions, run tests, and discard unwanted changes.
+   * **The tool was unavailable or blocked**: Verify license assignment, policies, installation, authentication, network access, and approved tool configuration.
+1. **Adjust the workflow guidance.** Remove workflows that did not help, fix access or configuration problems, and share practices from successful sessions.
+1. **Check operations again.** Review safety reports, agent activity, policy behavior, support needs, and spending. Pause the sprint if it meets one of your stop conditions.
+1. **Review preliminary results.** At the end of week two, compare activation and outcome signals with the baseline.
+
+Do not discourage normal IDE use. The goal is to help the team choose an agentic tool when it reduces effort or expands what they can accomplish.
+
+## After the sprint
+
+Measure the results, document what you learned, and decide whether to repeat, expand, redesign, pause, or stop the rollout.
+
+### Measure sustained usage
+
+Use daily reports for each user from the {% data variables.product.prodname_copilot_short %} usage metrics API:
+
+* `used_cli` and `used_copilot_app` show whether a person used each tool on a given day.
+* `totals_by_cli` and `totals_by_copilot_app` provide session, request, and prompt counts for deeper analysis.
+
+To check the activation target:
+
+1. Filter the daily rows to the sprint dates.
+1. Keep rows where `used_cli` or `used_copilot_app` is `true`.
+1. Group the rows by user and week.
+1. Count the distinct `day` values in each group.
+
+A participant meets a three-day target when the count is at least three in each week.
+
+To view these fields by team, join the user-teams report with the per-user usage report. See [AUTOTITLE](/copilot/reference/copilot-usage-metrics/team-level-metrics).
+
+Use the impact dashboard as a directional, longer-term view of overall agent adoption. Adoption cohorts use a trailing 28-day window and can reflect activity from agentic features beyond the two tools in this sprint. Do not use a cohort change to attribute impact to this sprint. See [AUTOTITLE](/copilot/how-tos/administer-copilot/view-impact-dashboard).
+
+### Measure team outcomes
+
+Compare the sprint period with your baseline, using measures such as:
+
+* Pull requests merged per developer
+* Median time to merge pull requests
+* Completion rate for maintenance or backlog work
+* Defects, rework, or review findings
+* Participant confidence and satisfaction from a short survey
+
+Review quantitative results alongside team feedback. Differences in project complexity, staffing, and work type can affect delivery metrics, so do not attribute every change to {% data variables.product.prodname_copilot_short %}.
+
+### Decide how to scale
+
+Summarize:
+
+* The percentage of participants who reached the activation target
+* Which workflows participants repeated without prompting
+* The most common setup, governance, or trust barriers
+* Changes in the selected team outcomes
+* Usage-based costs and any operational work required to support the rollout
+* Any safety issues and how you resolved them
+
+Expand to another established team when the initial team demonstrates repeatable workflows and acceptable quality, safety, support needs, and cost. If activation is low, identify and address that team's specific barriers, such as setup problems or unsuitable workflows. Do not change the rollout for teams that have already adopted the tools successfully.
+
+If you enabled the tools specifically for this sprint, do not use two weeks of data as proof of long-term cost impact. Continue the broader pilot until you have enough billing-cycle data to make a defensible expansion decision.
+
+As you expand, keep the same activation and outcome definitions so that you can compare rollout groups. Revisit the targets after you have enough internal evidence to define sustained, valuable use for your enterprise.
diff --git a/content/copilot/tutorials/roll-out-at-scale/enable-developers/index.md b/content/copilot/tutorials/roll-out-at-scale/enable-developers/index.md
index 9680f2cc2d6b..e5abd6ad7f74 100644
--- a/content/copilot/tutorials/roll-out-at-scale/enable-developers/index.md
+++ b/content/copilot/tutorials/roll-out-at-scale/enable-developers/index.md
@@ -8,6 +8,7 @@ children:
   - /drive-adoption
   - /copilot-app-for-teams
   - /integrate-ai-agents
+  - /drive-team-agentic-adoption
 redirect_from:
   - /copilot/rolling-out-github-copilot-at-scale/enabling-developers
   - /copilot/tutorials/rolling-out-github-copilot-at-scale/enabling-developers
diff --git a/data/release-notes/enterprise-server/3-17/0-rc1.yml b/data/release-notes/enterprise-server/3-17/0-rc1.yml
index 68d59ebc2c66..7a843b17ee65 100644
--- a/data/release-notes/enterprise-server/3-17/0-rc1.yml
+++ b/data/release-notes/enterprise-server/3-17/0-rc1.yml
@@ -183,7 +183,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from an appliance with version 3.13 or greater, the Elasticsearch indices must be reindexed before the data will display. This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from an appliance with version 3.13 or greater, the Elasticsearch indices must be reindexed before the data will display. This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/0.yml b/data/release-notes/enterprise-server/3-17/0.yml
index 1aaa018f2ecc..12500a33075d 100644
--- a/data/release-notes/enterprise-server/3-17/0.yml
+++ b/data/release-notes/enterprise-server/3-17/0.yml
@@ -188,7 +188,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from an appliance with version 3.13 or greater, the Elasticsearch indices must be reindexed before the data will display. This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from an appliance with version 3.13 or greater, the Elasticsearch indices must be reindexed before the data will display. This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/1.yml b/data/release-notes/enterprise-server/3-17/1.yml
index db55926a3d9a..9884ee4eeea8 100644
--- a/data/release-notes/enterprise-server/3-17/1.yml
+++ b/data/release-notes/enterprise-server/3-17/1.yml
@@ -62,7 +62,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/10.yml b/data/release-notes/enterprise-server/3-17/10.yml
index 2f86a87c1984..ead687ea3360 100644
--- a/data/release-notes/enterprise-server/3-17/10.yml
+++ b/data/release-notes/enterprise-server/3-17/10.yml
@@ -57,7 +57,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/11.yml b/data/release-notes/enterprise-server/3-17/11.yml
index c7a9294ac7ec..c0643d516a2a 100644
--- a/data/release-notes/enterprise-server/3-17/11.yml
+++ b/data/release-notes/enterprise-server/3-17/11.yml
@@ -61,7 +61,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/12.yml b/data/release-notes/enterprise-server/3-17/12.yml
index b750ebe624e8..5a684fca48ac 100644
--- a/data/release-notes/enterprise-server/3-17/12.yml
+++ b/data/release-notes/enterprise-server/3-17/12.yml
@@ -53,7 +53,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/13.yml b/data/release-notes/enterprise-server/3-17/13.yml
index e4490e5d1585..da102aa3db8d 100644
--- a/data/release-notes/enterprise-server/3-17/13.yml
+++ b/data/release-notes/enterprise-server/3-17/13.yml
@@ -51,7 +51,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/14.yml b/data/release-notes/enterprise-server/3-17/14.yml
index 98912b0fdc10..7cbe1608e1e1 100644
--- a/data/release-notes/enterprise-server/3-17/14.yml
+++ b/data/release-notes/enterprise-server/3-17/14.yml
@@ -83,7 +83,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/15.yml b/data/release-notes/enterprise-server/3-17/15.yml
index 1b12c5b2cb0b..139a4859e161 100644
--- a/data/release-notes/enterprise-server/3-17/15.yml
+++ b/data/release-notes/enterprise-server/3-17/15.yml
@@ -60,7 +60,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/16.yml b/data/release-notes/enterprise-server/3-17/16.yml
index 96528a4eab91..65547470c03b 100644
--- a/data/release-notes/enterprise-server/3-17/16.yml
+++ b/data/release-notes/enterprise-server/3-17/16.yml
@@ -39,7 +39,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/17.yml b/data/release-notes/enterprise-server/3-17/17.yml
index 07fe2feda1f6..32bed6207cac 100644
--- a/data/release-notes/enterprise-server/3-17/17.yml
+++ b/data/release-notes/enterprise-server/3-17/17.yml
@@ -57,7 +57,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or later appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or later appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/18.yml b/data/release-notes/enterprise-server/3-17/18.yml
index fcff853f10b0..b2ecdc47191f 100644
--- a/data/release-notes/enterprise-server/3-17/18.yml
+++ b/data/release-notes/enterprise-server/3-17/18.yml
@@ -64,7 +64,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/19.yml b/data/release-notes/enterprise-server/3-17/19.yml
index 1185947b1c5a..d7863180e3d0 100644
--- a/data/release-notes/enterprise-server/3-17/19.yml
+++ b/data/release-notes/enterprise-server/3-17/19.yml
@@ -51,7 +51,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/2.yml b/data/release-notes/enterprise-server/3-17/2.yml
index d257b15c495f..212f02abfb1f 100644
--- a/data/release-notes/enterprise-server/3-17/2.yml
+++ b/data/release-notes/enterprise-server/3-17/2.yml
@@ -45,7 +45,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/20.yml b/data/release-notes/enterprise-server/3-17/20.yml
index 86c3bfc85b4a..58aa6d1e356b 100644
--- a/data/release-notes/enterprise-server/3-17/20.yml
+++ b/data/release-notes/enterprise-server/3-17/20.yml
@@ -51,7 +51,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/21.yml b/data/release-notes/enterprise-server/3-17/21.yml
index 2676a1edb045..a8545e80b20d 100644
--- a/data/release-notes/enterprise-server/3-17/21.yml
+++ b/data/release-notes/enterprise-server/3-17/21.yml
@@ -51,7 +51,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/3.yml b/data/release-notes/enterprise-server/3-17/3.yml
index bae20351e1d6..408896f2508e 100644
--- a/data/release-notes/enterprise-server/3-17/3.yml
+++ b/data/release-notes/enterprise-server/3-17/3.yml
@@ -35,7 +35,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/4.yml b/data/release-notes/enterprise-server/3-17/4.yml
index ca3683d556a6..427c3ee7736c 100644
--- a/data/release-notes/enterprise-server/3-17/4.yml
+++ b/data/release-notes/enterprise-server/3-17/4.yml
@@ -49,7 +49,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/5.yml b/data/release-notes/enterprise-server/3-17/5.yml
index 73241617951e..51fed2573109 100644
--- a/data/release-notes/enterprise-server/3-17/5.yml
+++ b/data/release-notes/enterprise-server/3-17/5.yml
@@ -61,7 +61,7 @@ sections:
     - |
       Running `ghe-cluster-config-apply` as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/6.yml b/data/release-notes/enterprise-server/3-17/6.yml
index 683f619bc723..fff300d0812e 100644
--- a/data/release-notes/enterprise-server/3-17/6.yml
+++ b/data/release-notes/enterprise-server/3-17/6.yml
@@ -53,7 +53,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/7.yml b/data/release-notes/enterprise-server/3-17/7.yml
index afe838f54f0f..85b3aea1fed7 100644
--- a/data/release-notes/enterprise-server/3-17/7.yml
+++ b/data/release-notes/enterprise-server/3-17/7.yml
@@ -67,7 +67,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  You can also trigger the reindexing by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  You can also trigger the reindexing by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/8.yml b/data/release-notes/enterprise-server/3-17/8.yml
index 34f565cf57cb..04beb37bc9e1 100644
--- a/data/release-notes/enterprise-server/3-17/8.yml
+++ b/data/release-notes/enterprise-server/3-17/8.yml
@@ -63,7 +63,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-17/9.yml b/data/release-notes/enterprise-server/3-17/9.yml
index ba1efba20d33..649f9dfae534 100644
--- a/data/release-notes/enterprise-server/3-17/9.yml
+++ b/data/release-notes/enterprise-server/3-17/9.yml
@@ -26,7 +26,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/0-rc1.yml b/data/release-notes/enterprise-server/3-18/0-rc1.yml
index eb4fe6c9b918..5b99a5548c42 100644
--- a/data/release-notes/enterprise-server/3-18/0-rc1.yml
+++ b/data/release-notes/enterprise-server/3-18/0-rc1.yml
@@ -208,7 +208,7 @@ sections:
     - | 
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from an appliance with version 3.13 or greater, the Elasticsearch indices must be reindexed before the data will display. This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from an appliance with version 3.13 or greater, the Elasticsearch indices must be reindexed before the data will display. This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/0.yml b/data/release-notes/enterprise-server/3-18/0.yml
index 4332c75a999b..459cebf355a1 100644
--- a/data/release-notes/enterprise-server/3-18/0.yml
+++ b/data/release-notes/enterprise-server/3-18/0.yml
@@ -211,7 +211,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from an appliance with version 3.13 or greater, the Elasticsearch indices must be reindexed before the data will display. This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from an appliance with version 3.13 or greater, the Elasticsearch indices must be reindexed before the data will display. This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/1.yml b/data/release-notes/enterprise-server/3-18/1.yml
index 37a90680dcfd..28ce5b70e4f7 100644
--- a/data/release-notes/enterprise-server/3-18/1.yml
+++ b/data/release-notes/enterprise-server/3-18/1.yml
@@ -67,7 +67,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  You can also trigger the reindexing by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  You can also trigger the reindexing by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/10.yml b/data/release-notes/enterprise-server/3-18/10.yml
index 5070288d1fe0..f9fc3774473c 100644
--- a/data/release-notes/enterprise-server/3-18/10.yml
+++ b/data/release-notes/enterprise-server/3-18/10.yml
@@ -47,7 +47,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/11.yml b/data/release-notes/enterprise-server/3-18/11.yml
index 36adb28db2c7..b3acfc9160db 100644
--- a/data/release-notes/enterprise-server/3-18/11.yml
+++ b/data/release-notes/enterprise-server/3-18/11.yml
@@ -61,7 +61,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or later appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or later appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/12.yml b/data/release-notes/enterprise-server/3-18/12.yml
index 37320a4b4c15..6bd32bbb1c51 100644
--- a/data/release-notes/enterprise-server/3-18/12.yml
+++ b/data/release-notes/enterprise-server/3-18/12.yml
@@ -68,7 +68,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/13.yml b/data/release-notes/enterprise-server/3-18/13.yml
index f603b9bf925f..7be7d8999fe7 100644
--- a/data/release-notes/enterprise-server/3-18/13.yml
+++ b/data/release-notes/enterprise-server/3-18/13.yml
@@ -61,7 +61,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/14.yml b/data/release-notes/enterprise-server/3-18/14.yml
index 6aad5c1b314e..88196cf57ba0 100644
--- a/data/release-notes/enterprise-server/3-18/14.yml
+++ b/data/release-notes/enterprise-server/3-18/14.yml
@@ -61,7 +61,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/15.yml b/data/release-notes/enterprise-server/3-18/15.yml
index d193c45bc6b9..9b7e274dc51c 100644
--- a/data/release-notes/enterprise-server/3-18/15.yml
+++ b/data/release-notes/enterprise-server/3-18/15.yml
@@ -75,7 +75,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/2.yml b/data/release-notes/enterprise-server/3-18/2.yml
index 9c8d0dec27a6..d09e4ab0acac 100644
--- a/data/release-notes/enterprise-server/3-18/2.yml
+++ b/data/release-notes/enterprise-server/3-18/2.yml
@@ -67,7 +67,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/3.yml b/data/release-notes/enterprise-server/3-18/3.yml
index 22707c5ee49d..5206e36cbbdd 100644
--- a/data/release-notes/enterprise-server/3-18/3.yml
+++ b/data/release-notes/enterprise-server/3-18/3.yml
@@ -26,7 +26,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/4.yml b/data/release-notes/enterprise-server/3-18/4.yml
index 7863c76961b8..2fbdaab75fb5 100644
--- a/data/release-notes/enterprise-server/3-18/4.yml
+++ b/data/release-notes/enterprise-server/3-18/4.yml
@@ -67,7 +67,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/5.yml b/data/release-notes/enterprise-server/3-18/5.yml
index e28b57e43c10..739bdd90147b 100644
--- a/data/release-notes/enterprise-server/3-18/5.yml
+++ b/data/release-notes/enterprise-server/3-18/5.yml
@@ -69,7 +69,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/6.yml b/data/release-notes/enterprise-server/3-18/6.yml
index 337c1a413484..c9388bdfc071 100644
--- a/data/release-notes/enterprise-server/3-18/6.yml
+++ b/data/release-notes/enterprise-server/3-18/6.yml
@@ -57,7 +57,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/7.yml b/data/release-notes/enterprise-server/3-18/7.yml
index cf2b719e9ea2..42b151f73500 100644
--- a/data/release-notes/enterprise-server/3-18/7.yml
+++ b/data/release-notes/enterprise-server/3-18/7.yml
@@ -55,7 +55,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/8.yml b/data/release-notes/enterprise-server/3-18/8.yml
index cec62c557bb9..2cfe59e44480 100644
--- a/data/release-notes/enterprise-server/3-18/8.yml
+++ b/data/release-notes/enterprise-server/3-18/8.yml
@@ -98,7 +98,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-18/9.yml b/data/release-notes/enterprise-server/3-18/9.yml
index 3b4bab85f371..bcea44276aea 100644
--- a/data/release-notes/enterprise-server/3-18/9.yml
+++ b/data/release-notes/enterprise-server/3-18/9.yml
@@ -64,7 +64,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/0-rc1.yml b/data/release-notes/enterprise-server/3-19/0-rc1.yml
index eba3e6c7f5d6..9afe09b2cf30 100644
--- a/data/release-notes/enterprise-server/3-19/0-rc1.yml
+++ b/data/release-notes/enterprise-server/3-19/0-rc1.yml
@@ -225,7 +225,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/0.yml b/data/release-notes/enterprise-server/3-19/0.yml
index a615484e15fb..115624d63719 100644
--- a/data/release-notes/enterprise-server/3-19/0.yml
+++ b/data/release-notes/enterprise-server/3-19/0.yml
@@ -230,7 +230,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/1.yml b/data/release-notes/enterprise-server/3-19/1.yml
index ca721c5d68f1..fec764cea93d 100644
--- a/data/release-notes/enterprise-server/3-19/1.yml
+++ b/data/release-notes/enterprise-server/3-19/1.yml
@@ -72,7 +72,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/10.yml b/data/release-notes/enterprise-server/3-19/10.yml
index da961a5d7481..6694075889f2 100644
--- a/data/release-notes/enterprise-server/3-19/10.yml
+++ b/data/release-notes/enterprise-server/3-19/10.yml
@@ -54,6 +54,9 @@ sections:
     - |
       Users can see the progress of a repository being migrated with Enterprise Live Migrations (ELM). A banner indicates when the migration is in progress and the repository is still editable, when the repository has entered read-only cutover, and when the migration is complete, with a link to the destination repository. 
   known_issues:
+    # https://github.com/github/ghes/issues/19970
+    - |
+      On appliances with 84 GB or more of RAM, MySQL could consume most available memory after an upgrade because the default InnoDB buffer pool scales with available RAM. Before adding RAM to increase memory headroom, contact GitHub Support about setting an appropriate `mysql.max-memory` limit. [Updated: 2026-09-24]
     - |
       During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading.
     - |
@@ -71,7 +74,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/11.yml b/data/release-notes/enterprise-server/3-19/11.yml
index 00301c41bef2..bf5a1770e6ce 100644
--- a/data/release-notes/enterprise-server/3-19/11.yml
+++ b/data/release-notes/enterprise-server/3-19/11.yml
@@ -44,6 +44,9 @@ sections:
     - |
       Administrators can configure multiple WireGuard tunnels for high-availability deployments by setting `wireguard.num-tunnels`. Multiple tunnels distribute inter-node traffic across network queues and CPU cores, improving performance during high-volume traffic. The default configuration remains unchanged. See [Mitigating single-core softirq saturation](/admin/monitoring-and-managing-your-instance/additional-nodes/configuring-additional-nodes#mitigating-single-core-softirq-saturation).
   known_issues:
+    # https://github.com/github/ghes/issues/19970
+    - |
+      On appliances with 84 GB or more of RAM, MySQL could consume most available memory after an upgrade because the default InnoDB buffer pool scales with available RAM. Before adding RAM to increase memory headroom, contact GitHub Support about setting an appropriate `mysql.max-memory` limit. [Updated: 2026-09-24]
     - |
       During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading.
     - |
@@ -61,7 +64,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/12.yml b/data/release-notes/enterprise-server/3-19/12.yml
index b17079f46fb9..720035ec4ace 100644
--- a/data/release-notes/enterprise-server/3-19/12.yml
+++ b/data/release-notes/enterprise-server/3-19/12.yml
@@ -83,7 +83,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/2.yml b/data/release-notes/enterprise-server/3-19/2.yml
index 5f3e08ee43a0..4569b34f91f8 100644
--- a/data/release-notes/enterprise-server/3-19/2.yml
+++ b/data/release-notes/enterprise-server/3-19/2.yml
@@ -71,7 +71,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/3.yml b/data/release-notes/enterprise-server/3-19/3.yml
index a8463a736de9..29cd403fb188 100644
--- a/data/release-notes/enterprise-server/3-19/3.yml
+++ b/data/release-notes/enterprise-server/3-19/3.yml
@@ -71,7 +71,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/4.yml b/data/release-notes/enterprise-server/3-19/4.yml
index 0c3618f33953..5898a812293a 100644
--- a/data/release-notes/enterprise-server/3-19/4.yml
+++ b/data/release-notes/enterprise-server/3-19/4.yml
@@ -69,7 +69,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/5.yml b/data/release-notes/enterprise-server/3-19/5.yml
index 50370abd2393..a2d4f11946f4 100644
--- a/data/release-notes/enterprise-server/3-19/5.yml
+++ b/data/release-notes/enterprise-server/3-19/5.yml
@@ -106,7 +106,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/6.yml b/data/release-notes/enterprise-server/3-19/6.yml
index 2c5cd7ee793d..7598cb5394f4 100644
--- a/data/release-notes/enterprise-server/3-19/6.yml
+++ b/data/release-notes/enterprise-server/3-19/6.yml
@@ -72,7 +72,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/7.yml b/data/release-notes/enterprise-server/3-19/7.yml
index c62c3405020d..c2adc2756dac 100644
--- a/data/release-notes/enterprise-server/3-19/7.yml
+++ b/data/release-notes/enterprise-server/3-19/7.yml
@@ -49,7 +49,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/8.yml b/data/release-notes/enterprise-server/3-19/8.yml
index bebab7fdb1a3..e5618b61dee3 100644
--- a/data/release-notes/enterprise-server/3-19/8.yml
+++ b/data/release-notes/enterprise-server/3-19/8.yml
@@ -67,7 +67,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-19/9.yml b/data/release-notes/enterprise-server/3-19/9.yml
index 014a2f18044a..5f7a3123c32f 100644
--- a/data/release-notes/enterprise-server/3-19/9.yml
+++ b/data/release-notes/enterprise-server/3-19/9.yml
@@ -80,7 +80,7 @@ sections:
     - |
       {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded.
     - |
diff --git a/data/release-notes/enterprise-server/3-20/0-rc1.yml b/data/release-notes/enterprise-server/3-20/0-rc1.yml
index f647345fde20..af0f705cd9de 100644
--- a/data/release-notes/enterprise-server/3-20/0-rc1.yml
+++ b/data/release-notes/enterprise-server/3-20/0-rc1.yml
@@ -186,7 +186,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-20/0.yml b/data/release-notes/enterprise-server/3-20/0.yml
index 3d207e85575f..e182de08cced 100644
--- a/data/release-notes/enterprise-server/3-20/0.yml
+++ b/data/release-notes/enterprise-server/3-20/0.yml
@@ -180,7 +180,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-20/1.yml b/data/release-notes/enterprise-server/3-20/1.yml
index 14ea5e67e1fc..120a1b8a1c2c 100644
--- a/data/release-notes/enterprise-server/3-20/1.yml
+++ b/data/release-notes/enterprise-server/3-20/1.yml
@@ -104,7 +104,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-20/2.yml b/data/release-notes/enterprise-server/3-20/2.yml
index d70daee6c5d8..55507088d071 100644
--- a/data/release-notes/enterprise-server/3-20/2.yml
+++ b/data/release-notes/enterprise-server/3-20/2.yml
@@ -72,7 +72,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-20/3.yml b/data/release-notes/enterprise-server/3-20/3.yml
index 6432990fef09..ee0807d4696f 100644
--- a/data/release-notes/enterprise-server/3-20/3.yml
+++ b/data/release-notes/enterprise-server/3-20/3.yml
@@ -47,7 +47,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-20/4.yml b/data/release-notes/enterprise-server/3-20/4.yml
index 0b6dfe876fad..3aae93b4b5e4 100644
--- a/data/release-notes/enterprise-server/3-20/4.yml
+++ b/data/release-notes/enterprise-server/3-20/4.yml
@@ -67,7 +67,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or later appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or later appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-20/5.yml b/data/release-notes/enterprise-server/3-20/5.yml
index 8cd3e1d88aaa..7c9263457841 100644
--- a/data/release-notes/enterprise-server/3-20/5.yml
+++ b/data/release-notes/enterprise-server/3-20/5.yml
@@ -84,7 +84,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-20/6.yml b/data/release-notes/enterprise-server/3-20/6.yml
index 20028f48311f..dddbd0d56fe7 100644
--- a/data/release-notes/enterprise-server/3-20/6.yml
+++ b/data/release-notes/enterprise-server/3-20/6.yml
@@ -61,6 +61,9 @@ sections:
     - |
       Users can see the progress of a repository being migrated with Enterprise Live Migrations (ELM). A banner indicates when the migration is in progress and the repository is still editable, when the repository has entered read-only cutover, and when the migration is complete, with a link to the destination repository. 
   known_issues:
+    # https://github.com/github/ghes/issues/19970
+    - |
+      On appliances with 84 GB or more of RAM, MySQL could consume most available memory after an upgrade because the default InnoDB buffer pool scales with available RAM. Before adding RAM to increase memory headroom, contact GitHub Support about setting an appropriate `mysql.max-memory` limit. [Updated: 2026-09-24]
     - |
       During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading.
     - |
@@ -76,7 +79,7 @@ sections:
     - |
       Running a config apply as part of the steps for [AUTOTITLE](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shut down the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-20/7.yml b/data/release-notes/enterprise-server/3-20/7.yml
index 8ff1b269d03c..ccfc8547d88f 100644
--- a/data/release-notes/enterprise-server/3-20/7.yml
+++ b/data/release-notes/enterprise-server/3-20/7.yml
@@ -52,6 +52,9 @@ sections:
     - |
       Administrators can configure multiple WireGuard tunnels for high-availability deployments by setting `wireguard.num-tunnels`. Multiple tunnels distribute inter-node traffic across network queues and CPU cores, improving performance during high-volume traffic. The default configuration remains unchanged. See [Mitigating single-core softirq saturation](/admin/monitoring-and-managing-your-instance/additional-nodes/configuring-additional-nodes#mitigating-single-core-softirq-saturation).
   known_issues: 
+    # https://github.com/github/ghes/issues/19970
+    - |
+      On appliances with 84 GB or more of RAM, MySQL could consume most available memory after an upgrade because the default InnoDB buffer pool scales with available RAM. Before adding RAM to increase memory headroom, contact GitHub Support about setting an appropriate `mysql.max-memory` limit. [Updated: 2026-09-24]
     - |
       Site administrators can ensure that secret scanning uses processor features available on their GHES instance because secret scanning compiles its pattern-matching databases on the instance instead of using prebuilt databases. The first scan of each type after an upgrade or restart can take a few seconds longer while the databases are prepared. 
     - |
@@ -69,7 +72,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-20/8.yml b/data/release-notes/enterprise-server/3-20/8.yml
index ec3d8f5c550f..3f9ee4a51b9f 100644
--- a/data/release-notes/enterprise-server/3-20/8.yml
+++ b/data/release-notes/enterprise-server/3-20/8.yml
@@ -90,7 +90,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-21/0-rc1.yml b/data/release-notes/enterprise-server/3-21/0-rc1.yml
index 05219e26633a..d7cd04bf21e3 100644
--- a/data/release-notes/enterprise-server/3-21/0-rc1.yml
+++ b/data/release-notes/enterprise-server/3-21/0-rc1.yml
@@ -252,7 +252,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-21/0.yml b/data/release-notes/enterprise-server/3-21/0.yml
index cf1b416f5614..ed4b41b45cb9 100644
--- a/data/release-notes/enterprise-server/3-21/0.yml
+++ b/data/release-notes/enterprise-server/3-21/0.yml
@@ -251,7 +251,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning.
     - |
diff --git a/data/release-notes/enterprise-server/3-21/1.yml b/data/release-notes/enterprise-server/3-21/1.yml
index 77965f9501f0..a4a6a161f744 100644
--- a/data/release-notes/enterprise-server/3-21/1.yml
+++ b/data/release-notes/enterprise-server/3-21/1.yml
@@ -19,7 +19,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-21/2.yml b/data/release-notes/enterprise-server/3-21/2.yml
index 6acd023501b3..9891f133b8a5 100644
--- a/data/release-notes/enterprise-server/3-21/2.yml
+++ b/data/release-notes/enterprise-server/3-21/2.yml
@@ -66,7 +66,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-21/3.yml b/data/release-notes/enterprise-server/3-21/3.yml
index a33e1b74e7d5..e07b6e9afadc 100644
--- a/data/release-notes/enterprise-server/3-21/3.yml
+++ b/data/release-notes/enterprise-server/3-21/3.yml
@@ -80,7 +80,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-21/4.yml b/data/release-notes/enterprise-server/3-21/4.yml
index e60b20010230..218ef32ba54a 100644
--- a/data/release-notes/enterprise-server/3-21/4.yml
+++ b/data/release-notes/enterprise-server/3-21/4.yml
@@ -60,6 +60,9 @@ sections:
     - |
       Users can see the progress of a repository being migrated with Enterprise Live Migrations (ELM). A banner indicates when the migration is in progress and the repository is still editable, when the repository has entered read-only cutover, and when the migration is complete, with a link to the destination repository. 
   known_issues:
+    # https://github.com/github/ghes/issues/19970
+    - |
+      On appliances with 84 GB or more of RAM, MySQL could consume most available memory after an upgrade because the default InnoDB buffer pool scales with available RAM. Before adding RAM to increase memory headroom, contact GitHub Support about setting an appropriate `mysql.max-memory` limit. [Updated: 2026-09-24]
     - |
       During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading.
     - |
@@ -75,7 +78,7 @@ sections:
     - |
       Running a config apply as part of the steps for [AUTOTITLE](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shut down the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-21/5.yml b/data/release-notes/enterprise-server/3-21/5.yml
index b7b1dc7745df..100521015d2b 100644
--- a/data/release-notes/enterprise-server/3-21/5.yml
+++ b/data/release-notes/enterprise-server/3-21/5.yml
@@ -52,6 +52,9 @@ sections:
     - |
       Administrators can configure multiple WireGuard tunnels for high-availability deployments by setting `wireguard.num-tunnels`. Multiple tunnels distribute inter-node traffic across network queues and CPU cores, improving performance during high-volume traffic. The default configuration remains unchanged. See [Mitigating single-core softirq saturation](/admin/monitoring-and-managing-your-instance/additional-nodes/configuring-additional-nodes#mitigating-single-core-softirq-saturation).
   known_issues:
+    # https://github.com/github/ghes/issues/19970
+    - |
+      On appliances with 84 GB or more of RAM, MySQL could consume most available memory after an upgrade because the default InnoDB buffer pool scales with available RAM. Before adding RAM to increase memory headroom, contact GitHub Support about setting an appropriate `mysql.max-memory` limit. [Updated: 2026-09-24]
     - |
       Webhook configurations now use TCP (instead of UNIX streams) by default when connecting to the internal queueing system. To use UNIX, run `ghe-config app.hookshot-go.aqueduct-tcp-connection-enabled false`. 
     - |
@@ -71,7 +74,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-21/6.yml b/data/release-notes/enterprise-server/3-21/6.yml
index a23950cbb99f..aa2bf3bf469f 100644
--- a/data/release-notes/enterprise-server/3-21/6.yml
+++ b/data/release-notes/enterprise-server/3-21/6.yml
@@ -96,7 +96,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-22/0-rc1.yml b/data/release-notes/enterprise-server/3-22/0-rc1.yml
index 5336109f64f6..970503e71326 100644
--- a/data/release-notes/enterprise-server/3-22/0-rc1.yml
+++ b/data/release-notes/enterprise-server/3-22/0-rc1.yml
@@ -213,7 +213,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-and-managing-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shut down the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-22/0.yml b/data/release-notes/enterprise-server/3-22/0.yml
index c0a147589272..d2a2a077e7c3 100644
--- a/data/release-notes/enterprise-server/3-22/0.yml
+++ b/data/release-notes/enterprise-server/3-22/0.yml
@@ -197,6 +197,9 @@ sections:
 
   known_issues:
     # Known issues from "GHES Release Note Tracking" project
+    # https://github.com/github/ghes/issues/19970
+    - |
+      On appliances with 84 GB or more of RAM, MySQL could consume most available memory after an upgrade because the default InnoDB buffer pool scales with available RAM. Before adding RAM to increase memory headroom, contact GitHub Support about setting an appropriate `mysql.max-memory` limit. [Updated: 2026-09-24]
     - |
       During an upgrade of {% data variables.product.prodname_ghe_server %}, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading.
     - |
@@ -212,7 +215,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shut down the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a scheduled job that runs on the first Saturday of each month. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/release-notes/enterprise-server/3-22/1.yml b/data/release-notes/enterprise-server/3-22/1.yml
index 8ad970f32781..87e5d3665365 100644
--- a/data/release-notes/enterprise-server/3-22/1.yml
+++ b/data/release-notes/enterprise-server/3-22/1.yml
@@ -92,7 +92,7 @@ sections:
     - |
       Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps.
     - |
-      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a nightly scheduled job.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
+      When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up.  This happens via a scheduled job that runs on the first Saturday of each month.  It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`.
     - |
       When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.
     - |
diff --git a/data/reusables/release-notes/2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade.md b/data/reusables/release-notes/2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade.md
index daa8804be6d4..82591756c47c 100644
--- a/data/reusables/release-notes/2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade.md
+++ b/data/reusables/release-notes/2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade.md
@@ -1 +1 @@
-If a hotpatch upgrade requires the `haproxy-frontend` service to be restarted, the restart will hang if there are existing long-lived connections, such as browser web sockets or Git operations. No new connections will be accepted for up to 5 minutes. Any existing unfinished connections at this time will be disconnected.
+If a hotpatch upgrade requires the `haproxy-frontend` service to be restarted, the restart will hang if there are existing long-lived connections, such as browser web sockets or Git operations. No new connections will be accepted for up to 2 minutes. Any existing unfinished connections at this time will be disconnected.
diff --git a/package-lock.json b/package-lock.json
index 46353e74eb1f..333b34ce3507 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -134,7 +134,7 @@
         "commander": "^15.0.0",
         "cross-env": "^10.1.0",
         "csv-parse": "7.0.0",
-        "domhandler": "^5.0.3",
+        "domhandler": "^6.0.1",
         "eslint": "^9.39.3",
         "eslint-config-prettier": "^10.1.8",
         "eslint-import-resolver-typescript": "^4.4.4",
@@ -6569,6 +6569,36 @@
         "url": "https://github.com/sponsors/fb55"
       }
     },
+    "node_modules/cheerio-select/node_modules/domhandler": {
+      "version": "5.0.3",
+      "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-5.0.3.tgz",
+      "integrity": "sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==",
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "domelementtype": "^2.3.0"
+      },
+      "engines": {
+        "node": ">= 4"
+      },
+      "funding": {
+        "url": "https://github.com/fb55/domhandler?sponsor=1"
+      }
+    },
+    "node_modules/cheerio/node_modules/domhandler": {
+      "version": "5.0.3",
+      "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-5.0.3.tgz",
+      "integrity": "sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==",
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "domelementtype": "^2.3.0"
+      },
+      "engines": {
+        "node": ">= 4"
+      },
+      "funding": {
+        "url": "https://github.com/fb55/domhandler?sponsor=1"
+      }
+    },
     "node_modules/cheerio/node_modules/parse5": {
       "version": "7.3.0",
       "resolved": "https://registry.npmjs.org/parse5/-/parse5-7.3.0.tgz",
@@ -6972,6 +7002,21 @@
         "url": "https://github.com/sponsors/fb55"
       }
     },
+    "node_modules/css-select/node_modules/domhandler": {
+      "version": "5.0.3",
+      "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-5.0.3.tgz",
+      "integrity": "sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==",
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "domelementtype": "^2.3.0"
+      },
+      "engines": {
+        "node": ">= 4"
+      },
+      "funding": {
+        "url": "https://github.com/fb55/domhandler?sponsor=1"
+      }
+    },
     "node_modules/css-tree": {
       "version": "3.2.1",
       "resolved": "https://registry.npmjs.org/css-tree/-/css-tree-3.2.1.tgz",
@@ -7302,6 +7347,21 @@
         "url": "https://github.com/cheeriojs/dom-serializer?sponsor=1"
       }
     },
+    "node_modules/dom-serializer/node_modules/domhandler": {
+      "version": "5.0.3",
+      "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-5.0.3.tgz",
+      "integrity": "sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==",
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "domelementtype": "^2.3.0"
+      },
+      "engines": {
+        "node": ">= 4"
+      },
+      "funding": {
+        "url": "https://github.com/fb55/domhandler?sponsor=1"
+      }
+    },
     "node_modules/dom-serializer/node_modules/entities": {
       "version": "4.3.0",
       "license": "BSD-2-Clause",
@@ -7323,18 +7383,38 @@
       "license": "BSD-2-Clause"
     },
     "node_modules/domhandler": {
-      "version": "5.0.3",
+      "version": "6.0.1",
+      "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-6.0.1.tgz",
+      "integrity": "sha512-gYzvtM72ZtxQO0T048kd6HWSbbGCNOUwcnfQ01cqIJ4X2IYKFFHZ5mKvrQETcFXxsRObZulDaKmy//R7TPtsBg==",
+      "dev": true,
       "license": "BSD-2-Clause",
       "dependencies": {
-        "domelementtype": "^2.3.0"
+        "domelementtype": "^3.0.0"
       },
       "engines": {
-        "node": ">= 4"
+        "node": ">=20.19.0"
       },
       "funding": {
+        "type": "github",
         "url": "https://github.com/fb55/domhandler?sponsor=1"
       }
     },
+    "node_modules/domhandler/node_modules/domelementtype": {
+      "version": "3.0.0",
+      "resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-3.0.0.tgz",
+      "integrity": "sha512-umCQid3jKbDmVjx8jGaW7uUykm4DEUeyV21hPxNMo2nV955DhUThwqyOIDtreepP31hl84X7G5U9ZfsWvIB3Pg==",
+      "dev": true,
+      "funding": [
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/fb55"
+        }
+      ],
+      "license": "BSD-2-Clause",
+      "engines": {
+        "node": ">=20.19.0"
+      }
+    },
     "node_modules/domutils": {
       "version": "3.2.2",
       "resolved": "https://registry.npmjs.org/domutils/-/domutils-3.2.2.tgz",
@@ -7349,6 +7429,21 @@
         "url": "https://github.com/fb55/domutils?sponsor=1"
       }
     },
+    "node_modules/domutils/node_modules/domhandler": {
+      "version": "5.0.3",
+      "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-5.0.3.tgz",
+      "integrity": "sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==",
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "domelementtype": "^2.3.0"
+      },
+      "engines": {
+        "node": ">= 4"
+      },
+      "funding": {
+        "url": "https://github.com/fb55/domhandler?sponsor=1"
+      }
+    },
     "node_modules/dotenv": {
       "version": "17.3.1",
       "resolved": "https://registry.npmjs.org/dotenv/-/dotenv-17.3.1.tgz",
@@ -9661,6 +9756,21 @@
         "entities": "^7.0.1"
       }
     },
+    "node_modules/htmlparser2/node_modules/domhandler": {
+      "version": "5.0.3",
+      "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-5.0.3.tgz",
+      "integrity": "sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==",
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "domelementtype": "^2.3.0"
+      },
+      "engines": {
+        "node": ">= 4"
+      },
+      "funding": {
+        "url": "https://github.com/fb55/domhandler?sponsor=1"
+      }
+    },
     "node_modules/htmlparser2/node_modules/entities": {
       "version": "7.0.1",
       "resolved": "https://registry.npmjs.org/entities/-/entities-7.0.1.tgz",
@@ -11194,15 +11304,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/lru-cache": {
-      "version": "11.0.0",
-      "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-11.0.0.tgz",
-      "integrity": "sha512-Qv32eSV1RSCfhY3fpPE2GNZ8jgM9X7rdAfemLWqTUxwiyIC4jJ6Sy0fZ8H+oLWevO6i4/bizg7c8d8i6bxrzbA==",
-      "dev": true,
-      "engines": {
-        "node": "20 || >=22"
-      }
-    },
     "node_modules/magic-string": {
       "version": "1.2.3",
       "resolved": "https://registry.npmjs.org/magic-string/-/magic-string-1.2.3.tgz",
@@ -12325,16 +12426,6 @@
         "url": "https://github.com/sponsors/ljharb"
       }
     },
-    "node_modules/minipass": {
-      "version": "7.1.3",
-      "resolved": "https://registry.npmjs.org/minipass/-/minipass-7.1.3.tgz",
-      "integrity": "sha512-tEBHqDnIoM/1rXME1zgka9g6Q2lcoCkxHLuc7ODJ5BxbP5d4c2Z5cGgtXAku59200Cx7diuHTOYfSBD8n6mm8A==",
-      "dev": true,
-      "license": "BlueOak-1.0.0",
-      "engines": {
-        "node": ">=16 || 14 >=14.17"
-      }
-    },
     "node_modules/mockdate": {
       "version": "3.0.5",
       "dev": true,
@@ -12965,6 +13056,21 @@
         "url": "https://github.com/inikulin/parse5?sponsor=1"
       }
     },
+    "node_modules/parse5-htmlparser2-tree-adapter/node_modules/domhandler": {
+      "version": "5.0.3",
+      "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-5.0.3.tgz",
+      "integrity": "sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==",
+      "license": "BSD-2-Clause",
+      "dependencies": {
+        "domelementtype": "^2.3.0"
+      },
+      "engines": {
+        "node": ">= 4"
+      },
+      "funding": {
+        "url": "https://github.com/fb55/domhandler?sponsor=1"
+      }
+    },
     "node_modules/parse5-htmlparser2-tree-adapter/node_modules/parse5": {
       "version": "7.3.0",
       "resolved": "https://registry.npmjs.org/parse5/-/parse5-7.3.0.tgz",
@@ -13149,23 +13255,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/path-scurry": {
-      "version": "2.0.2",
-      "resolved": "https://registry.npmjs.org/path-scurry/-/path-scurry-2.0.2.tgz",
-      "integrity": "sha512-3O/iVVsJAPsOnpwWIeD+d6z/7PmqApyQePUtCndjatj/9I5LylHvt5qluFaBT3I5h3r1ejfR056c+FCv+NnNXg==",
-      "dev": true,
-      "license": "BlueOak-1.0.0",
-      "dependencies": {
-        "lru-cache": "^11.0.0",
-        "minipass": "^7.1.2"
-      },
-      "engines": {
-        "node": "18 || 20 || >=22"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/isaacs"
-      }
-    },
     "node_modules/path-to-regexp": {
       "version": "8.4.2",
       "resolved": "https://registry.npmjs.org/path-to-regexp/-/path-to-regexp-8.4.2.tgz",
diff --git a/package.json b/package.json
index 4bf3b4e51425..b03e0338d15d 100644
--- a/package.json
+++ b/package.json
@@ -296,7 +296,7 @@
     "commander": "^15.0.0",
     "cross-env": "^10.1.0",
     "csv-parse": "7.0.0",
-    "domhandler": "^5.0.3",
+    "domhandler": "^6.0.1",
     "eslint": "^9.39.3",
     "eslint-config-prettier": "^10.1.8",
     "eslint-import-resolver-typescript": "^4.4.4",
diff --git a/src/graphql/data/fpt/schema-pulls.json b/src/graphql/data/fpt/schema-pulls.json
index f158839baaa9..ca30aa2fcee6 100644
--- a/src/graphql/data/fpt/schema-pulls.json
+++ b/src/graphql/data/fpt/schema-pulls.json
@@ -615,7 +615,7 @@
       "name": "mergePullRequest",
       "id": "mergepullrequest",
       "href": "/graphql/reference/pulls#mutation-mergepullrequest",
-      "description": "<p>Merge a pull request.</p>",
+      "description": "<p>Merge a pull request.</p>\n<div class=\"ghd-alert ghd-alert-accent\" data-container=\"alert\"><p class=\"ghd-alert-title\"><svg version=\"1.1\" width=\"16\" height=\"16\" viewBox=\"0 0 16 16\" class=\"octicon mr-2\" aria-hidden><path d=\"M0 8a8 8 0 1 1 16 0A8 8 0 0 1 0 8Zm8-6.5a6.5 6.5 0 1 0 0 13 6.5 6.5 0 0 0 0-13ZM6.5 7.75A.75.75 0 0 1 7.25 7h1a.75.75 0 0 1 .75.75v2.75h.25a.75.75 0 0 1 0 1.5h-2a.75.75 0 0 1 0-1.5h.25v-2h-.25a.75.75 0 0 1-.75-.75ZM8 6a1 1 0 1 1 0-2 1 1 0 0 1 0 2Z\"></path></svg></p>\n<p>\nWe recommend using the <a href=\"/en/rest/pulls/pulls#merge-a-pull-request-asynchronously\">asynchronous merge REST\nAPI</a> instead.\nThis mutation does not support stacked pull requests.</p>\n</div>",
       "isDeprecated": false,
       "inputFields": [
         {
diff --git a/src/graphql/data/fpt/schema.docs.graphql b/src/graphql/data/fpt/schema.docs.graphql
index 4ef569cc4192..e3c1e2b7b8b9 100644
--- a/src/graphql/data/fpt/schema.docs.graphql
+++ b/src/graphql/data/fpt/schema.docs.graphql
@@ -28648,6 +28648,11 @@ type Mutation @docsCategory(name: "meta") {
 
   """
   Merge a pull request.
+
+  > [!NOTE]
+  > We recommend using the [asynchronous merge REST
+  API](${externalDocsUrl}/rest/pulls/pulls#merge-a-pull-request-asynchronously) instead.
+  > This mutation does not support stacked pull requests.
   """
   mergePullRequest(
     """
diff --git a/src/graphql/data/ghec/schema-pulls.json b/src/graphql/data/ghec/schema-pulls.json
index f158839baaa9..72f59588dd37 100644
--- a/src/graphql/data/ghec/schema-pulls.json
+++ b/src/graphql/data/ghec/schema-pulls.json
@@ -615,7 +615,7 @@
       "name": "mergePullRequest",
       "id": "mergepullrequest",
       "href": "/graphql/reference/pulls#mutation-mergepullrequest",
-      "description": "<p>Merge a pull request.</p>",
+      "description": "<p>Merge a pull request.</p>\n<div class=\"ghd-alert ghd-alert-accent\" data-container=\"alert\"><p class=\"ghd-alert-title\"><svg version=\"1.1\" width=\"16\" height=\"16\" viewBox=\"0 0 16 16\" class=\"octicon mr-2\" aria-hidden><path d=\"M0 8a8 8 0 1 1 16 0A8 8 0 0 1 0 8Zm8-6.5a6.5 6.5 0 1 0 0 13 6.5 6.5 0 0 0 0-13ZM6.5 7.75A.75.75 0 0 1 7.25 7h1a.75.75 0 0 1 .75.75v2.75h.25a.75.75 0 0 1 0 1.5h-2a.75.75 0 0 1 0-1.5h.25v-2h-.25a.75.75 0 0 1-.75-.75ZM8 6a1 1 0 1 1 0-2 1 1 0 0 1 0 2Z\"></path></svg></p>\n<p>\nWe recommend using the <a href=\"/en/enterprise-cloud@latest/rest/pulls/pulls#merge-a-pull-request-asynchronously\">asynchronous merge REST\nAPI</a> instead.\nThis mutation does not support stacked pull requests.</p>\n</div>",
       "isDeprecated": false,
       "inputFields": [
         {
diff --git a/src/graphql/data/ghec/schema.docs.graphql b/src/graphql/data/ghec/schema.docs.graphql
index 4ef569cc4192..e3c1e2b7b8b9 100644
--- a/src/graphql/data/ghec/schema.docs.graphql
+++ b/src/graphql/data/ghec/schema.docs.graphql
@@ -28648,6 +28648,11 @@ type Mutation @docsCategory(name: "meta") {
 
   """
   Merge a pull request.
+
+  > [!NOTE]
+  > We recommend using the [asynchronous merge REST
+  API](${externalDocsUrl}/rest/pulls/pulls#merge-a-pull-request-asynchronously) instead.
+  > This mutation does not support stacked pull requests.
   """
   mergePullRequest(
     """