Dead Clicks vs Rage Clicks vs Error Clicks: A Taxonomy
Watch the session at 0:14. She's on the checkout page, coupon field in view, and she taps "Apply discount" — once, then again, then twice more inside a single second. The button doesn't move. No spinner, no error, no shift in the total. Then she scrolls up, scrolls back down, and abandons.
Thirty seconds. The whole taxonomy is right there.
A dead click is a click that gets no page response — a design or expectation gap. An error click fires a JavaScript or console error, which is a code-layer failure. A rage click is a rapid burst of repeated clicks, behavioral escalation rather than a root cause on its own. And as our friend at 0:14 just showed you, they stack on top of each other in the same broken flow constantly.
The three signals, side by side
If you only read one part of this, read the table. It's the disambiguation most vendor docs bury.
| Signal | Root cause | How it's detected | Typical fix |
|---|---|---|---|
| Dead click | Design / expectation mismatch — the UI looked clickable but did nothing | Click on an element with no DOM change or scroll within a few seconds | Fix the affordance (make it a real control, or stop making it look like one) |
| Error click | Code failure — a client-side JS/console error, or a visible error state | Click occurring immediately before a thrown error, or one that surfaces validation/404 | Ship an engineering fix; hand it to the responsible team |
| Rage click | Escalating frustration — the amplifier, layered on dead or error | Rapid repeated clicks (thresholds vary; ~3+ in a short window) | Follow it down to the underlying dead or error cause |
Look at the middle column. Dead and error clicks point at genuinely different parts of your stack. Rage sits on top of either one.
Dead clicks: the click that goes nowhere
A dead click lands on something the user believed was interactive and got nothing back. Fullstory's help docs put it plainly: "If nothing on the page changes within a few seconds of a click or tap, it will get marked as a Dead Click." Conviva's glossary sharpens the behavioral read — these are single, non-repeated clicks that "often indicate perceived clickability mismatches without the additional frustration signal of repeated attempts."
Here's the field note. Last quarter I watched six sessions in a row do the exact same thing to the same non-link heading on a pricing page. It was styled with a bold accent color that read as a button, and every one of those six users pointed at it once, waited, and moved on. Nobody rage-clicked. They just assumed it was broken and adjusted. That's the quiet version of frustration, and it's the one teams miss because it doesn't scream.
Dead clicks are a design problem almost every time. The pixel lied about what it would do.
Error clicks: the click that breaks something
An error click is tied to the code layer, not the copy. Fullstory scopes it precisely: error clicks "surface sessions with a click or tap right before a client-side JavaScript error or console error occurs." Conviva widens the lens to the visible failures a user actually feels — "a form validation failure, a 404, an API error."
What matters about an error click is where it routes. A dead click is a conversation with your designer. An error click is a ticket for an engineer, because something in the stack actually threw. When I see error clicks clustering on a specific input, my first move isn't to rewrite the label. It's to open the console and find the exception. This is the one signal where changing UX copy is usually the wrong answer.
Rage clicks: the frustration you can feel
You can read a rage click from across the room. Rapid, repeated jabs at the same spot. Sentry's docs define the threshold concretely: dead clicks are detected on <button>, <input>, and <a> elements that don't produce a DOM update or scroll within 7 seconds, and "when the user clicks on one of these elements 3 or more times within that 7-second timeframe... the SDK registers a 'rage click'." Other vendors run tighter windows — Conviva describes a common algorithm as "three or more clicks within a short time window (commonly 0.3 to 1 second) on a single element or within a small geographic area of the page."
The nuance worth carrying: Sentry treats rage clicks as "a subset of dead clicks." That framing is correct, and it's the crux of the whole taxonomy. Rage isn't a separate root cause. It's what a dead click or an error click looks like when the user hasn't given up yet.
And about the human on the other side. She isn't dumb, and she isn't impatient for no reason. The UI told her that thing was clickable. She believed it. She's clicking harder because your interface set an expectation and then broke its own promise. I keep a soft spot for these sessions because the frustration is entirely earned.
Why these three get conflated
They co-occur, so vendors bundle them. Reasonable. But the bundling breeds a triage error I see constantly: teams treat "frustration signal" as one bucket and throw one kind of fix at it.
Here's the layer logic. Dead clicks live in the design layer, so the fix is an affordance change. Error clicks live in the code layer, so the fix is an engineering change. Rage clicks live in the behavior layer, and behavior is a symptom, never a cause. So when you sort a rage-click report and start "fixing rage clicks," you haven't decided anything yet. You've found where it hurts, not what's wrong.
Mis-triage costs you real cycles. Rewrite the button copy on something that's actually throwing a console error, and you've shipped nothing. Chase an engineering ticket on something that's just a misleading style, and you've burned a sprint. The signals overlap. The fixes don't.
The diagnostic flowchart
Run any suspicious click through three questions, in order.
Did anything happen on the page? If no — no DOM change, no navigation, no scroll — you're looking at a dead click. Annotate the replay frame and note what the element looked like it should do.
Was an error thrown? If yes — a console error, a JS exception, a visible validation fail or 404 — reclassify it as an error click. This branch overrides the first one, because "nothing visible happened" plus "an error fired" is a code failure wearing a dead-click costume.
Did the user repeat rapidly? If yes — 3-plus clicks in a tight window — flag it as a rage click on top of whichever of the above you found. Rage is the modifier, not the answer.
The order matters. Check for the error before you conclude "dead," or you'll route design tickets that belong to engineering.
A worked example: one broken checkout, all three signals
Let me make this concrete with an illustrative sample. These numbers are a hypothetical worked example I annotated by hand, not vendor stats. I'm using them to show how the counts drive decisions.
Say I annotate 200 sessions on a single checkout. Three hotspots emerge.
On the coupon field, I count 18 dead clicks — users tapping a styled label that reads like a button but isn't wired to anything. Layered on that same field, 11 rage bursts, meaning eleven sessions escalated to rapid repeated jabbing before giving up. On the ZIP-code input, a separate cluster: 7 error clicks, each one landing right before a validation exception when the field choked on a valid nine-digit ZIP.
Now the triage almost decides itself. The ZIP field's 7 error clicks are an engineering ticket — the code threw, so ship a fix. The coupon field's 18 dead clicks are a design ticket, so make the label a real button or restyle it to stop promising interactivity. And the 11 rage bursts? They aren't a third project. They're the volume knob on the coupon problem, telling me where the pain is loudest and which fix to prioritize first. One sample, three counts, two actual fixes, one clear order of operations.
The false-positive trap most teams miss
Threshold heuristics don't know your product. They'll happily flag legitimately click-heavy UI as frustration.
Think about the controls people jab on purpose. Next/Previous arrows in a carousel. Calendar navigation. An audio-play button. Print or Download. Sentry's own troubleshooting docs call out that repeated clicks on non-mutating elements like audio-play buttons can trip the detector. A user clicking "Next" nine times through a gallery isn't enraged. They're browsing.
Before you trust a single count, allowlist those elements. I keep a short exclusion list per product and revisit it whenever we ship new interactive widgets. Skip this step and your rage-click dashboard becomes a monument to how often people use your working features. The behavior analytics glossary is a decent place to sanity-check what each signal actually measures before you tune thresholds.
How much does this actually happen?
Fair question. Real-volume problem, or research curiosity? The cleanest external number I trust comes from Microsoft Clarity's Bing case study. When they investigated missed clicks on the Bing search box, they reported it "impacted 4% of all the users that clicked on the search box."
Four percent of everyone who tried to use one of the most-clicked boxes on the internet hit a click that didn't register. That's the scale at a company with world-class engineering. Your checkout is almost certainly worse, and you almost certainly can't see it without watching.
Which tools surface all three automatically
Most mature replay tools capture the frustration signals now. They differ on detection method and, more usefully, on where the fix routes.
Fullstory pioneered the four-signal framing — rage, dead, error, and thrashed cursor — and its docs remain the clearest reference for the definitions. Strong on the UX-triage side.
Sentry couples dead and rage clicks tightly (rage as a subset of dead) and is strongest where error clicks matter, because error monitoring is its home turf. The click links straight to the stack trace.
Datadog RUM folds frustration signals into broader real-user monitoring, useful if your team already lives in Datadog for performance data.
Microsoft Clarity offers free replay and heatmaps with rage/dead detection, a low-friction starting point for smaller teams.
Amplitude comes at it from the product-analytics side, connecting frustration signals to funnels and cohorts.
Kixo (kixo.io) surfaces error and behavior analytics alongside session replay (web via rrweb, plus native iOS and Android), with heatmaps and privacy masking. Its differentiator is chat-first querying — you ask about the signals in plain language and get answers with a visible reasoning trail, instead of building the report by hand. It's a newer, AI-native platform, so weigh it against the older tools on depth of detection tuning for your specific stack. The fact sheet doesn't cover per-signal thresholds, so validate that against your needs before committing.
Pick on where your fixes actually happen. Error-heavy team? Favor the code-linked tools. Design-heavy problem? Favor the replay-and-heatmap depth.
Field notes: what I'd fix first
My triage order, every time. Error clicks first — the code threw, so ship the fix and stop the bleeding. Dead clicks second, because the UI is lying about what's clickable and the affordance needs correcting. Rage clicks last, and not as a task but as a compass: follow the loudest bursts down until they resolve into one of the other two.
Which brings me back to our user at 0:14. She jabbed "Apply discount" four times against a button that never responded. Run her through the flowchart. Nothing happened. No error fired. She repeated rapidly. That's a dead click with rage on top. The fix isn't calming her down. It's making the button do what she already believed it would.