What is a rage click? And how are they actually detected?

A rage click is what a person does when they click something and nothing happens, so they click it again. And again. And again.

It is one of the few behavioural signals in web analytics that is almost never ambiguous. A drop in conversion could be seasonality, a pricing change, or a bad traffic source. A burst of four clicks on the same button in under a second means that button did not do what the person expected.

The definition

Most tools converge on the same shape: three or more clicks, close together in time, in roughly the same place.

The details vary by tool, and vendors are usually vague about them. Here is exactly how UserTapes does it, because a heuristic you cannot inspect is a heuristic you cannot trust:

Parameter	Value	Meaning
Minimum clicks	3	Two clicks is a double-click, not frustration
Time window	700 ms	Maximum gap between consecutive clicks
Radius	30 px	Maximum spatial spread of the whole cluster

The window is between consecutive clicks, not across the whole burst. Five clicks each 600 ms apart is one rage cluster spanning three seconds. That is deliberate — sustained mashing is still mashing.

The radius matters just as much as the timing. Someone clicking rapidly across a page is navigating fast, not raging. Someone landing four clicks inside a 30-pixel circle is hitting the same control repeatedly.

Rage clicks versus dead clicks

These get conflated and they are not the same thing.

A dead click is a single click where nothing responded. A rage click is the human reaction to a dead click that the person has not given up on yet.

Detecting a dead click is harder, because “nothing responded” needs a definition. UserTapes calls a click dead when no DOM mutation occurs within 1000 ms of it, and the session ran long enough afterwards for a mutation to have plausibly happened. That last condition matters: without it, the final click of every session is a false positive, because the recording ends before anything can change.

This heuristic has real limits worth knowing:

• A click that triggers a fetch and only paints 1.2 seconds later reads as dead. It is not; it is slow. Which is arguably still a bug.
• A click that causes a purely visual change with no DOM change — a CSS-only hover state, a canvas redraw — reads as dead when it worked fine.
• A click on a link that navigates away is not dead, but the navigation itself ends the mutation window, so this needs special-casing.

Any vendor telling you their dead-click detection is exact is overselling it. It is a signal, not a verdict.

What rage clicks actually tell you

In rough order of how often each turns out to be the cause:

A silent failure. The most common by a distance. A request failed, the code swallowed the error, and the UI gave no feedback. The button still looks clickable, so the user clicks it. This is the canonical rage click, and it is almost always a missing error state rather than a missing feature.

A disabled-looking control that is actually enabled — or the reverse. If the button does not visibly change on click, the user cannot tell their click registered.

Slow responses with no loading state. If a click takes two seconds and nothing indicates work is happening, users assume it failed. Adding a spinner fixes the rage clicks without making anything faster.

Something that looks clickable but is not. A heading styled like a link, a card that looks like a button, an icon with no handler. Here the rage clicks are telling you about an affordance problem, not a bug.

A false positive. Genuinely: some people double-click everything, because that is what they learned on a desktop operating system. A rage cluster on a form submit from a single user is not a pattern. Fourteen users on the same button is.

That last point is the practical one. A rage click on its own is noise. A rage click that repeats across sessions is a bug report. Any tool worth using should let you ask how many distinct sessions hit the same control, not just show you one dramatic recording.

Finding them without watching hours of video

The honest problem with session replay has always been that the data is real but the interface is a video player. Nobody has time to watch 400 sessions to find the four that matter.

Two things fix this. The first is filtering: query sessions by whether they contain a rage cluster at all, rather than browsing chronologically. The second is not watching video in the first place.

UserTapes derives a text transcript from every recording, so a rage cluster appears as a line:

- ⚠ 0:19 rage click ×4 · button "Pay now"
- ⚠ 0:21 POST https://example.com/api/pay · 502

Two lines, and the cause is already visible. The 502 is why the button did nothing. You have the diagnosis without opening the player — though the timestamp is a link into it if you want to see the moment.

Because the transcript is text, an agent can read it. Connected over MCP, you can ask Claude or Cursor “did anyone rage click this week, and why?” and get an answer grounded in specific sessions. That workflow is covered in session replay over MCP.

What to do when you find one

1. Check whether it repeats. One session is an anecdote. Filter for the same control across the last week before you spend time on it.
2. Look at the two lines after the cluster, not the cluster. The rage click is the symptom. The failed request, the JS error, or the absence of either is the cause.
3. If nothing failed, it is a feedback problem. The click worked and the user could not tell. Add a loading state or a state change.
4. If something failed silently, fix the error state first. The underlying bug matters, but a user who sees “coupon code expired” does not rage click even when the coupon really is expired.

That fourth point is the one teams skip. Most rage clicks are not caused by the failure. They are caused by the failure being invisible.

---

If you want to see rage clicks in your own product, UserTapes records 100 sessions free with no card and no expiry, and flags rage clusters, dead clicks, JS errors, and failed requests on the timeline automatically. Related reading: how to reproduce a bug a user reported.