diff --git a/contents/docs/replay-vision/quota-and-limits.mdx b/contents/docs/replay-vision/quota-and-limits.mdx
index 2e54278ccd59..f2867a3af369 100644
--- a/contents/docs/replay-vision/quota-and-limits.mdx
+++ b/contents/docs/replay-vision/quota-and-limits.mdx
@@ -48,10 +48,11 @@ In practice this means: **every observation that produces a `$recording_observed
 
 ## What happens when the cap is reached
 
-Both enforcement paths use the same check:
+Each enforcement path handles this differently:
 
 - **Background sweeps** – new observations queued by the automatic schedule are silently skipped. The scanner stays enabled, the sweep keeps running, but no work gets queued until quota frees up (next month, or as in-flight observations resolve to ineligible/failed).
-- **On-demand triggers** – the player action and the `vision-scanners-scan-session` MCP tool return a `402 Payment Required` response with a `quota_limit_exceeded` code.
+- **Single on-demand triggers** – the player action and the `vision-scanners-scan-session` MCP tool return a `402 Payment Required` response with a `quota_limit_exceeded` code.
+- **Bulk on-demand scans** – the **Scan N selected** action starts as many scans as the quota and concurrency limits allow, then reports the remaining sessions as `skipped_quota` or `skipped_limit` rather than failing the entire batch.
 
 A scanner that's been silenced by the cap will resume producing observations automatically once usage drops below the cap (e.g. at the start of the next month).
 
diff --git a/contents/docs/replay-vision/running-scanners.mdx b/contents/docs/replay-vision/running-scanners.mdx
index ee9980ff13bf..24b724a042c3 100644
--- a/contents/docs/replay-vision/running-scanners.mdx
+++ b/contents/docs/replay-vision/running-scanners.mdx
@@ -36,7 +36,7 @@ Sweeps run continuously – once a scanner is enabled, observations start accumu
 
 ### What happens when I change filters?
 
-Changing a scanner's filters affects which **new** sessions match going forward. Old recordings aren't re-evaluated against the new filters. If you broaden the filters and want to backfill, trigger on-demand observations against the recordings you care about – the bulk [**Scan these recordings**](#from-the-recordings-list) action is the fastest way – or wait for new matches to come in.
+Changing a scanner's filters affects which **new** sessions match going forward. Old recordings aren't re-evaluated against the new filters. If you broaden the filters and want to backfill, trigger on-demand observations against the recordings you care about – the bulk [**Scan N selected**](#from-the-recordings-list) action is the fastest way – or wait for new matches to come in.
 
 ### What happens when I disable the scanner?
 
@@ -62,7 +62,11 @@ On-demand triggers:
 
 ### From the recordings list
 
-To scan a batch in one go, select recordings in the [recordings list](/docs/session-replay/how-to-watch-recordings) and choose **Scan these recordings**, then pick a scanner. Each selected session is queued as its own observation. Sessions the scanner has already observed are skipped automatically, so re-scanning a selection is safe.
+The On-demand tab's recordings table has a checkbox column for multi-select. Tick individual rows or use **select all on page**, then click **Scan N selected** in the selection bar. Each selected session is queued as its own observation.
+
+Recordings the scanner has already observed or that are currently in flight are greyed out and can't be selected — there's nothing to re-scan.
+
+The bulk action **scans what fits**: it starts as many observations as your [concurrency limits and monthly credit quota](/docs/replay-vision/quota-and-limits) allow, then reports the rest as skipped rather than failing the whole batch. A toast notification summarizes the outcome — how many started, plus any that were skipped or failed — so you know at a glance whether a partial run happened.
 
 This is also the fastest way to backfill after broadening a scanner's filters.