diff --git a/src/content/docs/billing.mdx b/src/content/docs/billing.mdx
index aacf79f322..977101a62f 100644
--- a/src/content/docs/billing.mdx
+++ b/src/content/docs/billing.mdx
@@ -4,8 +4,6 @@ description: Understand how Mergify fair billing works.
 ---
 
 import DownloadLink from '../../components/DownloadLink.astro';
-import { Image } from "astro:assets"
-import PlanScreenshot from "../images/billing/plan.png"
 
 This page explains how Mergify's contributor-based billing works and how to
 read your invoice.
@@ -103,16 +101,26 @@ invoiced for 10 extra users over 45 days.
 
 You can check your current usage on the [Plan
 page](https://dashboard.mergify.com/settings/plan) of the Mergify dashboard,
-under **Settings → Plan**. It lists each product alongside its repository count
-and its number of active contributors.
+under **Settings → Plan**. It lists each product you use in a table, with its
+repository count and its number of active contributors:
 
-<Image
-  src={PlanScreenshot}
-  alt="Settings Plan page listing each Mergify product with its repository and active contributor counts"
-/>
+| Product | Repositories | Active contributors |
+|---|---|---|
+| Merge Queue | 10 repositories | 25 contributors |
+| CI Insights | 5 repositories | 15 contributors |
+| Workflow Automation | 10 repositories | 25 contributors |
+
+The counts above are examples. If you are a billing manager, the table has an
+**On-demand Usage** column showing what you are billed monthly on top of your
+plan. On a yearly subscription, it also has a **Committed** column showing the
+seats you pre-purchased.
+
+On some plans the third column is headed **Collaborators** instead. It counts
+everyone with access to a repository, rather than only the people who
+contributed to it.
 
-You can then click on the number of contributors to get the list of active
-users for each product.
+Both counts are links. The repository count opens the list of repositories using
+that product, and the contributor count opens the list of people counted for it.
 
 :::note
   This is not available for on-premise plans.
diff --git a/src/content/docs/merge-queue/batches.mdx b/src/content/docs/merge-queue/batches.mdx
index f47aad1e74..8b25cfed5d 100644
--- a/src/content/docs/merge-queue/batches.mdx
+++ b/src/content/docs/merge-queue/batches.mdx
@@ -738,7 +738,10 @@ temporary batch PRs, only when all of the following are true:
 
 Optionally set `update_bot_account` to avoid in-place updates blocked by GitHub
 for security reasons (for example, PRs from forks that modify workflows, or PRs
-opened by other bots).
+opened by other bots). The reverse holds for ordinary PRs from forks: with
+`update_method: rebase`, setting the account makes Mergify refuse them at queue
+entry. See [Combining Merge and Update
+Methods](/merge-queue/merge-strategies#combining-merge-and-update-methods).
 
 ## Skip intermediate results (anti-flake protection)
 
diff --git a/src/content/docs/merge-queue/direct-merge.mdx b/src/content/docs/merge-queue/direct-merge.mdx
index ed24094094..dc36048611 100644
--- a/src/content/docs/merge-queue/direct-merge.mdx
+++ b/src/content/docs/merge-queue/direct-merge.mdx
@@ -108,8 +108,6 @@ request and a full CI run.
 - **The queue does not use [two-step CI](/merge-queue/two-step).** Two-step CI defers the heavy
   suite to the queue on purpose, so the pull request's own CI is not the full signal.
 
-- **`autosquash` is off.** Rewriting the commits changes what was tested.
-
 - **The merge method is not [`merge-batch`](/merge-queue/merge-strategies#merge-batch).** It merges
   the batch pull request itself, so there has to be one.
 
diff --git a/src/content/docs/merge-queue/merge-strategies.mdx b/src/content/docs/merge-queue/merge-strategies.mdx
index 577719c8ed..98311b89ce 100644
--- a/src/content/docs/merge-queue/merge-strategies.mdx
+++ b/src/content/docs/merge-queue/merge-strategies.mdx
@@ -158,10 +158,12 @@ rebase update occurs, the commit SHAs on the PR will change; what fast-forward
 preserves are the SHAs of the PR branch at merge time.
 
 :::caution
-  When using `update_bot_account` with fast-forward inplace mode, support for
-  fork pull requests is deprecated. See the
-  [update method deprecation note](#combining-merge-and-update-methods) for
-  details and migration options.
+  Combining fast-forward inplace mode with an `update_bot_account` makes
+  Mergify refuse pull requests coming from a fork when they are queued.
+  `update_method: merge` is not a way out here: a fast-forward queue lands by
+  moving the base branch onto the pull request's head, and it exists to keep
+  merge commits out of that history. See [Combining Merge and Update
+  Methods](#combining-merge-and-update-methods) for what to do instead.
 :::
 
 <GitGraph
@@ -364,10 +366,25 @@ The `update_method` option controls how Mergify updates PR branches when they
 fall behind the base branch. Combining `merge_method` with `update_method`
 gives you additional control over your history shape.
 
-:::note
-  Support for fork pull requests with `update_method: rebase` combined with
-  `update_bot_account` is deprecated. If your repository
-  receives fork PRs, use `update_method: merge` instead.
+:::caution
+  Mergify refuses a pull request coming from a fork at queue entry if the queue
+  [runs its checks in place](/merge-queue/batches#in-place-checks-no-batch-prs)
+  with `update_method: rebase` and an `update_bot_account`. GitHub refuses an
+  OAuth token on its rebase API for a fork, so rebasing on behalf of a user
+  would mean impersonating that user to force-push the contributor's branch,
+  and Mergify does not do that.
+
+  Unset `update_bot_account` to keep queueing pull requests from forks: with no
+  account to impersonate, the update rebases through GitHub's API as Mergify.
+  On a queue that does not merge with `fast-forward`, `update_method: merge`
+  works too, and merges the base branch into the pull request rather than
+  rebasing it.
+
+  One kind of pull request from a fork goes the other way: for one that
+  changes GitHub Actions workflows, or that another GitHub App's bot opened,
+  GitHub lets Mergify update in place only *with* an `update_bot_account`. A
+  queue that receives those has to run its checks on a
+  [draft pull request](/merge-queue/batches) instead.
 :::
 
 ### Semi-Linear History (Rebase + Merge Commit)
diff --git a/src/content/docs/test-insights/quarantine.mdx b/src/content/docs/test-insights/quarantine.mdx
index 12495e1c93..74b517f20c 100644
--- a/src/content/docs/test-insights/quarantine.mdx
+++ b/src/content/docs/test-insights/quarantine.mdx
@@ -12,7 +12,7 @@ This helps you keep your CI green while maintaining full visibility into test re
 ## How Quarantine Works
 
 When you quarantine a test in the Mergify dashboard, its future executions will continue to be collected by
-[CI Insights](/ci-insights/), but your CI will ignore failures.
+[Test Insights](/test-insights), but your CI will ignore failures.
 
 This avoids pipeline disruption while still surfacing issues in the UI and keeping historical data intact.
 
@@ -24,7 +24,7 @@ To ensure the correct setup, refer to [the documentation for your test framework
 ### From the Mergify Dashboard
 
 The [Mitigation page](https://dashboard.mergify.com/test-insights/mitigation) on the dashboard contains the list of
-tests that were retrieved from the CI Insights integration.
+tests that Test Insights collected from your CI runs.
 From there, you can add or remove a test from quarantine.
 
 ### From the Mergify CLI
diff --git a/src/content/docs/workflow/actions/rebase.mdx b/src/content/docs/workflow/actions/rebase.mdx
index ac9ad4fcac..1a44ea7abb 100644
--- a/src/content/docs/workflow/actions/rebase.mdx
+++ b/src/content/docs/workflow/actions/rebase.mdx
@@ -33,8 +33,7 @@ the action. A pull request is rebased only when it is open, has no conflict, is
 not in a merge queue
 ([`queue-position = -1`](/configuration/conditions#attributes-list)), and is
 either behind its base branch (`#commits-behind > 0`) or does not have a linear
-history (`-linear-history`). With `autosquash` enabled, holding more than one
-commit (`#commits > 1`) is a third way to satisfy that either/or requirement.
+history (`-linear-history`).
 
 Rebasing writes the pull request's head branch, so the [restrictions on writing
 a fork's branch](/workflow/actions/update#fork-pull-requests) apply here too.