diff --git a/.github/instructions/code.instructions.md b/.github/instructions/code.instructions.md
index fcbb06f1a9b1..b8b1f9875055 100644
--- a/.github/instructions/code.instructions.md
+++ b/.github/instructions/code.instructions.md
@@ -94,7 +94,7 @@ Run the following commands to validate your changes:
 8. Validate that any new or changed tests pass. See "Tests".
 9. Validate that these changes meet our guidelines. See "Guidelines".
 10. If you are running in agentic mode, _stop_ at this point and request review before continuing. Suggest how the human should review the changes.
-11. If a branch and pull request already exist, commit and push, then _concisely_ comment on the pull request that you are GitHub Copilot and what changes you made and why. 
+11. If a branch and pull request already exist, commit and push, then _concisely_ comment on the pull request that you are GitHub Copilot and what changes you made and why.
 12. If this is new work and no pull request exists yet, make a pull request:
     - label "llm-generated"
     - draft mode
@@ -102,5 +102,25 @@ Run the following commands to validate your changes:
 13. If you are in agentic mode, offer to wait for CI to run and check that it passes. If the human agrees, verify in CI: `sleep 240 && gh pr checks $number`. Address all failures, don't assume they're flakes.
 14. If you are in agentic mode, offer to do any or all of:
     - mark the pull request as ready,
-    - assign the issue to the human if it is not already assigned, 
+    - assign the issue to the human if it is not already assigned,
     - _concisely_ comment on the issue explaining the change, indicating you are GitHub Copilot.
+
+## Logger
+
+Use `createLogger` from `@/observability/logger` instead of `console.log` in server-side code.
+
+```typescript
+import { createLogger } from "@/observability/logger";
+
+const logger = createLogger(import.meta.url);
+
+logger.debug("Detailed tracing");
+logger.info("Normal event", { userId });
+logger.warn("Recoverable issue");
+logger.error("Failure", { error });
+```
+
+- Pass a plain object as the second argument to add structured context (emitted as logfmt in production).
+- Never log secrets, tokens, or PII.
+- Create loggers once at module scope, not inside functions.
+- Do not use the logger in scripts (locally-run code); `console.log` is fine there.
diff --git a/content/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities.md b/content/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities.md
index e7c75a54059b..d8cdb06b4dd1 100644
--- a/content/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities.md
+++ b/content/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities.md
@@ -77,7 +77,7 @@ If you have legacy CAs that are exempt from the expiration requirement, you can
 If you use a username as the login extension, {% data variables.product.company_short %} validates that the named user has not been renamed since the certificate was issued. This prevents a rename attack, where a certificate issued for a username is valid even if the underlying user account changes. To enforce this, the certificate must include the `valid_after` claim, which tells us when the certificate was issued. This field is often missing if an expiration is not required for the certificate, which is why expirations are now required.
 {% endif %}
 
-To issue a certificate for someone who uses SSH to access multiple {% data variables.product.company_short %} products, you can include two login extensions to specify the username for each product. For example, the following command would issue a certificate for USERNAME-1 for the user's account for {% data variables.product.prodname_ghe_cloud %}, and USERNAME-2 for the user's account on {% data variables.product.prodname_ghe_server %} at HOSTNAME.
+To issue a certificate for someone who uses SSH to access multiple {% data variables.product.company_short %} products, you can include two login extensions to specify the username for each product. For example, the following command would issue a certificate for USERNAME-1 for the user's account for {% data variables.product.prodname_ghe_cloud %}, and USERNAME-2 for the user's account on {% data variables.product.prodname_ghe_server %} or {% data variables.enterprise.data_residency %} at HOSTNAME.
 
 ```shell
 ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@github.com=USERNAME-1 extension:login@HOSTNAME=USERNAME-2 ./user-key.pub
diff --git a/src/search/lib/ai-search-proxy.ts b/src/search/lib/ai-search-proxy.ts
index a622508a735f..50de15d9b871 100644
--- a/src/search/lib/ai-search-proxy.ts
+++ b/src/search/lib/ai-search-proxy.ts
@@ -9,7 +9,7 @@ import { handleExternalSearchAnalytics } from '@/search/lib/helpers/external-sea
 // Maximum time (ms) to wait for the initial response from the upstream
 // AI search service. Streaming may take longer once the connection is
 // established, but the connect + first-byte must complete within this window.
-const AI_SEARCH_TIMEOUT_MS = 4_000
+const AI_SEARCH_TIMEOUT_MS = 9_000
 
 export const aiSearchProxy = async (req: ExtendedRequest, res: Response) => {
   const { query, version } = req.body ?? {}