The Four Frustration Signals and What Each One Means

What are frustration signals in UX?

The term frustration signals covers automatically detected behaviors that show a user hit friction, and the standard set is rage clicks, dead clicks, error clicks and thrashed cursors, each defined by a threshold rather than by a guess. A detector reads the event stream coming off the page, applies a rule with numbers in it, and tags the session when the rule matches. Nobody labels these by hand. That is the point. A rule can scan a hundred thousand sessions in a night, and a researcher cannot.

The word signal is doing real work there. A signal is not a diagnosis. It marks a second or two where the user and the interface disagreed about what should happen next, and it hands you a timestamp. Working out what actually broke is still your job.

What are the four standard signals?

Four behaviors make up the set that most replay tools ship with, and they cover different failure modes. Rage clicks catch an unresponsive control. Dead clicks catch something that looks clickable and is not. Error clicks catch an action that threw a JavaScript exception. Thrashed cursors catch a user who cannot find what they came for.

Signal	What the user did	What it points at	What to check first
Rage click	Clicked the same spot several times in a row, fast	A control that responded too slowly or not at all	Time from click to first visible change on that element
Dead click	Clicked once on something that produced no response at all	Non-interactive text, an icon with no handler, a disabled state with no explanation	Whether the element has a click handler and whether it looks like a button
Error click	Clicked, and a JavaScript error fired right after	A broken handler, a failed request, a null reference in the click path	The stack trace and the network call attached to that click
Thrashed cursor	Moved the pointer back and forth quickly without clicking	Scanning for a control that is missing, mislabeled or below the fold	Whether the target of that page section is visible at that viewport width

Read down the third column and you can see why the four exist as a set. They are four distinct kinds of user friction, and lumping them into one "frustration" number throws away the part that tells you where to look.

How does a detector decide something is a rage click?

Every rage click rule is built from three numbers: how many clicks, inside what radius, within what time window. A run of clicks that clears all three at once gets tagged. Say your tool is configured for three clicks inside a twenty pixel radius within one second. Four clicks on the same button in 700 milliseconds match. Four clicks spread across five seconds do not, because the window closed. Two clicks anywhere do not, because the count never got there.

The other three signals use the same style of rule with different inputs. A dead click detector watches for a click followed by no DOM change, no navigation and no network request before a wait window expires. An error click detector links a click to any JavaScript error thrown within a short window after it. A thrashed cursor detector measures pointer distance and direction changes over a window with no click in it.

Are those thresholds the same in every tool?

No. There is no standards body for this, and every vendor picks its own count, radius and window, then ships them as defaults you can sometimes edit. One tool's three clicks in one second is another tool's four clicks in two seconds.

Two consequences follow. Rage click counts do not transfer between tools, so a migration can move the number without a single thing changing in your UI. And a benchmark you read in someone else's blog post is measuring their thresholds, not yours. Open your tool's settings, write down the actual values, and put them next to any number you report.

Why do two identical rage clicks need different fixes?

Because the detector cannot see intent, only clicks. A user hammering a Save button that takes four seconds to respond and a user hammering a div that was never wired to anything produce the same event pattern. Same count, same radius, same window, same tag on the session.

The fixes have nothing in common. The slow button needs an optimistic state, a spinner or a faster endpoint, and the click handler already works. The dead element needs a handler, or it needs to stop looking like a button. Ship the loading spinner on the second case and you have made a broken control look busy.

This is the honest limit of every frustration signal, and it is why the count on its own is close to useless. A rate that went from 2 percent to 5 percent tells you something changed. It does not tell you what, and it will not until someone watches one of the sessions.

How do you rank signals by impact?

Rank by the share of sessions affected, not by raw signal count, because one furious user clicking forty times can outweigh a problem that quietly hits a thousand people.

frustration rate = sessions with at least one signal / total sessions

Take a week with 8,300 sessions where 412 contained at least one signal. That is 412 / 8,300 = 0.0496, a frustration rate of 4.96 percent. Then split the same calculation by element. If 280 of those 412 sessions all fired on one checkout button, that single element accounts for 3.37 percent of all sessions on its own, and the remaining 132 sessions are scattered across the rest of the site. You now know which fix to schedule first.

Group before you count. Forty rage clicks from one person on one button is one bug, not forty, and a ranking that treats it as forty will send you after the loudest user instead of the widest problem.

One week, 8,300 sessions

Total sessions 8,300

Sessions with a signal 412

Checkout button 280

Rest of site 132

What makes a frustration signal actually useful?

A signal is useful when you can click it and land in the exact second it fired. That is the whole loop. The rule finds the moment, the recording shows the cause, and the cause tells you what to change.

Without that jump, you have a chart that says users are unhappy somewhere. With it, you watch the checkout button take four seconds, see the third click land before the first response, and know the fix is a disabled state during the request. Flowsery detects rage clicks, dead clicks, JavaScript errors and drop-offs automatically, groups the matching sessions into one issue, and ranks issues by how many users hit them, so the signal arrives already attached to the replay you need to watch.

Frequently asked questions

Is there an official list of frustration signals?

No standards body defines the set. Rage clicks, dead clicks, error clicks and thrashed cursors are the four that most session replay products converged on, so treat them as a convention rather than a specification. Some tools add their own, such as repeated form submissions or backtracking between two pages.

What is the difference between a rage click and a dead click?

A rage click is several fast clicks in the same small area, which means the user tried again because nothing happened. A dead click is a single click that produced no response at all. The same broken element can generate both, depending on whether the user gave up after one try or kept going.

Can a frustration signal be a false positive?

Yes, and this is the main thing to plan around. A rage click on a slow but working button looks identical to a rage click on a genuinely dead element, and double-clicking out of habit on a desktop app that behaves like a website will trip the same rule. The tag tells you where to look, not what is wrong.

Do frustration signals work on mobile?

Rage clicks, dead clicks and error clicks translate directly to taps, since the underlying rule is about count, distance and timing. Thrashed cursors do not, because touch devices have no hovering pointer to track. On mobile, tools substitute other movement signals such as rapid scroll reversals.

Should I set an alert on my frustration rate?

Alert on a sudden change rather than on an absolute number, since the absolute number depends on thresholds you did not standardize. A jump right after a deploy is worth waking someone for. A rate that has sat at 4 percent for six months is a backlog item, not an incident.

How many sessions do I need before the numbers mean anything?

Enough that a single user cannot swing the rate, which means grouping by user first and by element second. If one element accounts for most of your tagged sessions across many different users, that holds up at small volumes. A rate calculated from a handful of sessions moves several points every time one person mashes a button.

How do you calculate a frustration rate?

Divide sessions with at least one signal by total sessions for the period. A week with 8,300 sessions and 412 tagged sessions works out to 412 / 8,300, a frustration rate of 4.96 percent. Split the same calculation by element to see which pages or buttons are driving the number.

Why does a slow button trigger a rage click?

The detector only sees clicks, not the reason behind them. A Save button that takes four seconds to respond gets clicked several times before the first response arrives, and that pattern matches the same count, radius and window as a button with no handler at all. The fix is an optimistic state, a spinner or a faster endpoint, not a new click handler.

What usually causes a dead click?

A dead click fires on non-interactive text, an icon with no handler, or a disabled state with no explanation, anything that looks clickable but produces no DOM change, navigation or network request before the wait window expires. Check whether the element has a click handler and whether it looks like a button.

Why group frustration signals by user before ranking them?

One person mashing a button forty times produces forty rage click events for a single bug, and a ranking that counts raw signals chases that noise instead of the problem hitting the most people. Group by user first, then by element, so a furious individual does not outweigh a fix that quietly touches a thousand sessions.