What technically counts as a rage click?
Most analytics tools converge on the same heuristic:
- Three or more
clickevents - On the same DOM element (or within a small pixel radius — typically 10 px)
- Within a sliding window of 1000 to 2000 ms
- Optionally followed by no DOM mutation, no navigation, and no network request
The exact thresholds vary slightly between vendors, but anything more than three clicks per second on the same target is almost universally treated as a rage click.
Why does it matter?
Rage clicks correlate strongly with abandonment. They are valuable because they are observable without surveys:
- They surface broken JavaScript handlers that throw silent errors
- They flag elements that look interactive but are not (see dead clicks)
- They identify slow API calls where the user thinks the button "did nothing"
- They reveal misleading affordances — for example a static icon that resembles a button
- They are an early signal that a checkout, form, or onboarding step is at risk
A 2021 Contentsquare benchmark (Digital Experience Benchmark report) found that pages with rage-click rates above 7 percent saw conversion rates drop by roughly half compared to pages below 2 percent.
How do you detect a rage click in code?
A minimal detector looks like this:
const rageMap = new WeakMap();
const WINDOW_MS = 1500;
const THRESHOLD = 3;
document.addEventListener("click", (e) => {
const el = e.target;
const now = performance.now();
const events = (rageMap.get(el) || []).filter(t => now - t < WINDOW_MS);
events.push(now);
rageMap.set(el, events);
if (events.length >= THRESHOLD) {
reportRageClick({
selector: cssPath(el),
x: e.clientX,
y: e.clientY,
count: events.length,
});
}
});
In production you would also debounce reports, group by stable CSS selector, and attach the surrounding session replay segment.
What are the most common causes?
- A click handler that throws a runtime error before the visible state updates
- A button wired to an API that responds in more than 500 ms with no loading spinner
- A
<div>styled to look like a button but missing the click handler - A modal
z-indexbug where an overlay swallows clicks - A form submit blocked by a hidden validation error above the fold
- Touch and click events double-firing on mobile, masking a real failure
How is a rage click different from a dead click?
| Aspect | Rage click | Dead click |
|---|---|---|
| Click count | 3+ in quick succession | 1 (or any) |
| Outcome | No useful response, user keeps trying | No response at all |
| Signal type | Frustration | Affordance failure |
| Detection window | 1 to 2 seconds | ~1.5 seconds of no DOM mutation |
A dead click is usually the first click in what becomes a rage click. Rage clicks add the emotional dimension — the user knew something should happen and pushed harder.
How do you fix the underlying issue?
- Wrap click handlers in
try / catchand forward errors to your error tracker - Add an immediate visual response (loading spinner, button disabled state) within 100 ms of the click
- Promote
<div>and<span>pseudo-buttons to real<button>elements - Audit
pointer-events: nonerules and overlay stacking - Reproduce the rage click using the matched session replay rather than guessing
How it relates to CloseTrace
CloseTrace's session capture flags rage clicks automatically and surfaces them on the funnel view, so you can jump from a spike in frustration to the exact replay segment in two clicks — without having to instrument anything per element.