diff --git a/docs/platforms/javascript/common/session-replay/troubleshooting.mdx b/docs/platforms/javascript/common/session-replay/troubleshooting.mdx
index d3e94afccf07b..7aecc1be9acca 100644
--- a/docs/platforms/javascript/common/session-replay/troubleshooting.mdx
+++ b/docs/platforms/javascript/common/session-replay/troubleshooting.mdx
@@ -77,33 +77,6 @@ We're always working on ways to reduce the bundle size. Additionally, there are
 
 </Expandable>
 
-<Expandable title="How does Rage Click detection work?">
-
-The Replay SDK tries to detect cases where a user clicked on something, but nothing happened. This is called a "Dead Click" -- a click that seems to be "dead" and does nothing, from the user's perspective. This can happen if a bug prevents the UI from being correctly updated after a button is clicked.
-
-The way that the Replay SDK detects this is by checking if a click on a `<button>` or `<a>` element doesn't lead to either updates to the DOM or a page scroll. If within 7 seconds no updates are detected, the SDK will generate a "Slow Click" in the Replay UI. (We call it a "Slow Click" because it may be possible that something will happen after the 7s, but we chose this as a cutoff time.)
-
-Another concept related to this is "Rage Clicks". A "Rage Click" is when a user clicks on an element many times, which indicates frustration that something isn't working.
-
-When a Slow Click and a Rage Click come together, we have a very good indicator that something is actually wrong, and the Replay SDK will generate a "Rage Click" for this.
-
-Note that there are some limitations to this. On the one hand, there may be _false negatives_ -- we cannot detect all cases; for example, imagine a user clicks a "dead" button, but then clicks a different button afterwards that leads to a DOM update. In this case, since we cannot attribute the DOM update to a specific button, we'll _not_ capture this slow click.
-
-On the other hand, there may be _false positives_. For example, if a user clicks a link that leads to a file download, there is no reliable way to detect that a download was initiated, so a Slow Click may be generated even if the button is not actually "dead". For these cases, you can configure the SDK via `slowClickIgnoreSelectors` - see <PlatformLink to='/session-replay/configuration'>Configuration</PlatformLink> for more details.
-
-For example, you could ignore detection of dad and rage clicks for download links in your application like this:
-
-```javascript
-Sentry.replayIntegration({
-  slowClickIgnoreSelectors: [
-    ".download",
-    // Any link with a label including "download" (case-insensitive)
-    'a[label*="download" i]',
-  ],
-});
-```
-</Expandable>
-
 <Expandable title='I see the message: "A large number of mutations was detected (N). This can slow down the Replay SDK and impact your customers."'>
 
 The Sentry SDK attempts to minimize potential [performance overhead](/product/session-replay/performance-overhead/#how-is-session-replay-optimized) in a few different ways. For example, by keeping track of the number of DOM mutations that are happening then disabling recording when a large number of changes are detected. Many simultaneous mutations can slow down a web page whether Session Replay is installed or not, but when a large number of mutations happen, the Replay client can incur an additional slowdown because it records each change.
diff --git a/docs/product/issues/issue-details/replay-issues/index.mdx b/docs/product/issues/issue-details/replay-issues/index.mdx
index 98b13e6e5b581..bba5b084e9f96 100644
--- a/docs/product/issues/issue-details/replay-issues/index.mdx
+++ b/docs/product/issues/issue-details/replay-issues/index.mdx
@@ -19,6 +19,27 @@ In order to see rage clicks in your issue stream on the **Issues** page, your or
 While you can enable **session replay** with JavaScript SDK version 7.27.0, or higher, you'll need to have version 7.60.1 or higher in order to be able to see **rage click issues**.
 </Note>
 
+## Detection Criteria
+
+"Slow clicks" (also called "dead clicks") are only detected on `<button>`, `<input>`, and `<a>` elements that don't lead to updates to the DOM or a page scroll within 7 seconds). When the user clicks on one of these elements 3 or more times within that 7 second time frame, it indicates frustration, and the SDK registers a "rage click". 
+
+### Why am I seeing too many or too few rage clicks?
+There might be fewer rage clicks than you expect if the user stopped waiting for the site to respond before the 7 second threshold and instead chose to to something else. This is why the rage click issues that you *do* see are so valuable, because the user that clicked at least 3 times and continued waiting at least 7 seconds for the site to respond is likely very frustrated.
+
+You might also see more rage clicks than you expected from buttons that don't trigger a DOM mutation or page scroll (such as Print and Download buttons). There is no reliable way for the SDK to detect that a download or print has initiated, so a slow click might be generated even if the button is not actually "dead". For these cases, you can configure the SDK via `slowClickIgnoreSelectors` - see [Configuration](/platforms/javascript/session-replay/configuration/) for more details.
+
+For example, to ignore detection of dead and rage clicks for download links in your application:
+
+```javascript
+Sentry.replayIntegration({
+  slowClickIgnoreSelectors: [
+    ".download",
+    // Any link with a label including "download" (case-insensitive)
+    'a[label*="download" i]',
+  ],
+});
+```
+
 ## Get Rage Click Alerts
 
 To set up alerts and get notified when a rage click occurs, follow these steps: