Where Rage Clicks vs Dead Clicks Actually Differ

What is the difference between rage clicks and dead clicks?

The rage clicks vs dead clicks difference is one of cause: a rage click records a user repeating an action, and a dead click records a single click the page never answered. One is behavioural, one is structural. They overlap constantly, which is why tools list them side by side, but the fix for each is different.

A rage click tells you a person kept trying. That happens when the target is slow, when the response is invisible, and also when the interface legitimately invites repeated clicking. A dead click tells you an element received a click and produced no change. That happens when the element is not wired up, when a handler threw, and also when the change was real but the detector could not see it.

What thresholds does each vendor publish?

Two of the five publish numbers. Three describe the behaviour in prose and stop there.

Vendor	Rage click rule	Dead click rule
PostHog	$rageclick fires on "three clicks that are each within 30 pixels and 1 second of the previous one". Configurable as click_count: 3, threshold_px: 30, timeout_ms: 1000	$dead_click is "a click which isn't followed by a change to the page". No numeric window published
Hotjar	"when a user clicks on the same element five times within 500ms of one another"	Dead click filter finds sessions where users "clicked on a button, link, or a specific element of your site but didn't get any reaction". No numbers
FullStory	"clicking or tapping multiple times, rapidly, in the same area". No numbers	"If nothing on the page changes within a few seconds of a click or tap, it will get marked as a Dead Click". No numbers
LogRocket	"a series of rapid, repeated clicks on the same element". No numbers	"a click that did not result in a DOM change". No numbers
Microsoft Clarity	"the user clicks multiple times in a clustered area in rapid succession". No numbers	"a user clicks on an element but gets no feedback in a reasonable amount of time... the visual status doesn't change, and there's no navigation away from the page". No numbers

The two published rules do not agree, and they are not close. PostHog needs three clicks inside a one second window and allows the pointer to wander 30 pixels between them. Hotjar needs five clicks inside 500 milliseconds and requires them on the same element. A user who clicks three times in 800 milliseconds is raging in PostHog and invisible in Hotjar. A user who clicks five times over four seconds on one button is raging in neither.

That matters more than the numbers themselves. Rage click counts are not comparable across tools, and a migration between vendors will change the number without anything changing on your site.

What counts as a page change for a dead click?

No vendor commits to an answer in public, which is the weakest point in the whole signal.

LogRocket is the most specific, and it is still a category rather than a threshold: a dead click is "a click that did not result in a DOM change". Clarity adds two conditions in prose, that the visual status does not change and that there is no navigation away from the page, without saying how long it waits. FullStory says "within a few seconds". PostHog says only "a change to the page".

Everything ambiguous falls into that gap:

• A click that fires a network request whose response arrives after the detection window.
• A click that changes a canvas, a WebGL scene or a video element, none of which mutate the DOM.
• A click that opens a native dialog, triggers a download, or copies to the clipboard.
• A click that toggles a CSS class with no visible effect at the current breakpoint.

Each of these produces a dead click in at least one tool and nothing in another. Treat a raw dead click count as a search index over sessions rather than as a defect count, and confirm each cluster against the replay before it becomes a ticket. The practical workflow is the one described in dead click analysis.

Why do rage clicks fire on working interfaces?

Because the detector measures cadence, not intent, and plenty of correct interfaces ask for fast repeated clicks.

FullStory states the problem in its own documentation, under the heading "Why don't Rage Clicks work for me?": some UI components, like Next and Previous buttons, naturally invite repeated clicks, which trips the heuristic even though the behaviour is intended. PostHog reaches the same conclusion and ships defaults to compensate. With defaults: '2026-05-30' or later, PostHog automatically ignores navigation controls with text such as next, previous, > and <, quantity steppers marked + and -, and repeated clicks on text-selection surfaces such as inputs, textareas and contenteditable elements, since triple-clicking to select a line is not rage.

Both vendors ship an escape hatch in markup:

Vendor	Suppress rage clicks	Suppress dead clicks
PostHog	.ph-no-rageclick class, or rageclick.css_selector_ignorelist	.ph-no-deadclick class, or capture_dead_clicks.css_selector_ignorelist
FullStory	fs-ignore-rage-clicks class, or account settings	fs-ignore-dead-clicks class, or account settings

FullStory adds a detail worth planning around: suppression applies to new sessions only, and existing sessions are not reclassified retroactively.

PostHog's documentation closes the loop with the right instruction: confirm rage clicks against session replays before treating them as a hard frustration signal. That is the same discipline rage click analysis is built on.

Which causes sit behind each signal?

The two signals point at different parts of the stack, which is the reason to keep them separate instead of merging them into a single frustration count.

Rage clicks come from:

• Latency. The handler works, the response takes two seconds, the user clicks again.
• Missing feedback. The handler works instantly, nothing visible confirms it, the user clicks again.
• Blocked submission. Client-side validation fails silently and the button appears inert.
• Legitimate repetition. Pagination, steppers, carousels, text selection.

Dead clicks come from:

• Unbound elements. Text, icons and images styled to look interactive with no handler.
• Handler errors. A JavaScript exception before the state change. FullStory tracks this separately as Error Clicks, which surface a click immediately before a client-side JavaScript or console error.
• Detection blind spots. Canvas, video, downloads, new tabs, native dialogs.

A cluster that shows both signals on the same selector is the strongest case you will get: the element looks clickable, does nothing, and users keep trying. A dead click cluster with no rage clicks usually means the element looks clickable to a machine and not to a person, which is a lower priority.

Reading a click cluster

Rage clicks and dead clicks on the same selector

• The element looks clickable
• It produces no change
• Users keep trying anyway
• Highest priority to investigate

Dead clicks alone, no rage clicks

• The element looks clickable to a machine
• It does not look clickable to a person
• Lower priority to investigate

How should you use the two together?

Rank by sessions affected and position in the funnel, then watch the replay before writing the ticket.

Neither count is meaningful in isolation. A hundred rage clicks on a carousel arrow is a detector artefact. Twelve dead clicks on a checkout submit button is a revenue incident. The difference is not the number, it is where the element sits and whether the session recovered afterwards.

A workable order of operations:

1. Group by CSS selector or stable element ID, never by raw coordinates.
2. Filter to pages that carry conversion weight.
3. Check whether sessions containing the cluster completed the step.
4. Watch three replays from the cluster. Confirm the element, the expectation and the failure.
5. Only then open the ticket, with the selector, the page, the session count and a replay link.

This is the same ranking logic that applies to every other signal in the frustration signals family, and it is why session replay sits underneath both metrics rather than beside them. The counts find the candidates. The recording decides.

Frequently asked questions

Which vendors publish an exact rage click threshold?

PostHog and Hotjar. PostHog documents three clicks, each within 30 pixels and 1 second of the previous one, exposed as click_count, threshold_px and timeout_ms. Hotjar documents five clicks on the same element within 500ms of one another. FullStory, LogRocket and Microsoft Clarity publish no numbers for either signal.

Does anyone publish a numeric dead click threshold?

No. FullStory says "within a few seconds", Clarity says "a reasonable amount of time", LogRocket defines it as a click with no DOM change, and PostHog defines it as a click not followed by a change to the page. None of the five states a millisecond value.

Are rage click counts comparable between tools?

No. With PostHog's defaults a three-click burst inside one second counts. Under Hotjar's rule it does not, because Hotjar requires five clicks inside 500ms on one element. Any migration between the two changes the count with no change to user behaviour.

Can a click be both a rage click and a dead click?

Yes, and that combination is the highest-value cluster to investigate. The element received repeated clicks and produced no page change, which removes both of the common false-positive explanations at once.

How do you stop a carousel or stepper from producing rage clicks?

Add the vendor's exclusion class to the element. PostHog uses .ph-no-rageclick and also accepts rageclick.css_selector_ignorelist. FullStory uses fs-ignore-rage-clicks. FullStory notes that exclusions apply to sessions captured after the change, so historical sessions keep their original classification.

Does a dead click always mean something is broken?

No. Clicks on canvas elements, video players, download links, clipboard actions and native dialogs all produce real responses that a DOM-mutation detector cannot see. Confirm the cluster in a replay before treating it as a defect.

What does FullStory's Error Click signal capture?

FullStory logs this as a separate signal called Error Clicks, distinct from dead clicks. It flags a click that happens right before a client-side JavaScript or console error, tying the failure to a specific interaction rather than a general page error. That link comes closer to a bug report than a dead click ever gets, since a dead click only tells you the DOM did not change.

What is the recommended workflow before turning a click cluster into a ticket?

Group the clicks by CSS selector or stable element ID first, then filter to pages that carry conversion weight. Check whether sessions in the cluster completed the step, then watch three replays to confirm the element, the expectation and the failure. Only after that do you open the ticket, with the selector, the page, the session count and a replay link.

What besides a slow response causes a rage click?

Latency is one cause, but a rage click also fires when the handler responds instantly and nothing visible confirms that anything happened. It fires when client-side validation fails silently and the button just looks inert, and when the interface legitimately invites repeated clicks, as in pagination, steppers, carousels or text selection.

Why does grouping by CSS selector matter more than grouping by raw coordinates?

The workable order of operations starts by grouping clicks by CSS selector or stable element ID, never by raw coordinates. Raw coordinates describe a spot on the screen, not the element a person interacted with, so grouping by them scatters the same button's clicks across many different buckets. Grouping by selector is what makes it possible to rank clusters by sessions affected and position in the funnel.