Dead, Error and Rage Click Monitoring

🕵️ Dead, Error, and Rage Click Monitoring

GermainUX RUM JS automatically monitors user clicks and identifies interaction patterns that may indicate confusion, frustration, or application failure.

Click monitoring is preconfigured for every UX Monitoring Profile. Additional configuration is required only when customers want to change the default thresholds or exclude application-specific elements.

✨ Benefits

Click monitoring helps organizations:

• Detect elements that users click but that do not respond.

• Identify clicks associated with JavaScript errors.

• Detect repeated interactions that may indicate frustration.

• Understand which pages, features, and workflows create friction.

• Replay affected sessions to see what the user experienced.

• Measure how many users and sessions are affected.

• Correlate interaction friction with errors, performance, abandonment, and lost productivity.

• Prioritize application improvements based on frequency and business impact.

• Notify teams when a significant click-related issue is detected.

Preconfigured click types

GermainUX automatically monitors the following click types:

The default configuration is suitable for most applications.

Dead clicks

A dead click occurs when the user clicks or touches an element and GermainUX detects no resulting DOM change or scrolling within 500 milliseconds.

Dead clicks can indicate:

• A button or link that does not work

• An element that appears interactive but is not

• A delayed response

• An invisible overlay blocking the interaction

• A disabled control without clear feedback

• A missing event handler

• User confusion about what can be clicked

A dead click is a friction signal, not definitive proof of a defect. Some valid interactions do not immediately change the DOM or scroll the page.

Examples include:

• Copying text

• Focusing an input

• Starting a file download

• Opening a native browser function

• Triggering background processing

• Interacting with a canvas or specialized control

• Waiting for a response that takes longer than the configured threshold

Use Session Replay and related network, console, and performance evidence to determine what occurred.

Error clicks

An error click occurs when a click or touch interaction is followed by a JavaScript console error within 300 milliseconds.

Error clicks help associate a technical failure with the user action that likely triggered it.

They can help answer:

• Which user action preceded the error?

• Which page or element was involved?

• Did the error prevent the expected result?

• Was the error visible to the user?

• How many users encountered the same problem?

• Did the error cause abandonment or workflow failure?

The timing relationship does not, by itself, prove that the click caused the JavaScript error. Review the Session Replay, stack trace, console activity, and related network requests before confirming causation.

Rage clicks

A rage click occurs when a user performs at least three consecutive clicks on the same element, with less than 500 milliseconds between each click.

Rage clicks can indicate:

• A slow or unresponsive control

• A button that provides no immediate feedback

• A failed interaction

• An unexpected overlay

• A delayed network request

• User uncertainty

• An element that appears clickable but is not

• Duplicate-submission risk

Repeated clicking can also be intentional. Examples include game controls, counters, navigation controls, or other interfaces designed for rapid interaction.

Configure exclusions or different thresholds for these elements when necessary.

Session Replay

Dead, error, and rage clicks appear in the corresponding recorded user session.

Session Replay helps teams:

• See the application state at the time of the interaction.

• Identify the element the user selected.

• Review what happened immediately before and after the click.

• Determine whether the page responded later.

• Inspect related JavaScript and console events.

• Review related network requests.

• Understand whether the user recovered, repeated the action, or abandoned.

• Determine whether the same friction affected a business workflow.

This makes it possible to validate automatically detected friction without manually attempting to reproduce every issue.

See User Session Monitoring, Replay & 6 Heatmaps.

Analysis at scale

GermainUX can analyze click friction across the complete monitored user population.

Measures can include:

• Click count

• Dead-click count

• Error-click count

• Rage-click count

• Unique users affected

• Unique sessions affected

• Friction rate

• Abandonment following the interaction

• Workflow delay

• Lost productivity

• Conversion impact

Results can be segmented by:

• Click type

• Element

• Element text

• Page or route

• Application

• Environment

• Application version

• User or role

• Browser

• Browser version

• Device

• Operating system

• Business process

• Customer segment

• Time period

Analysis can help determine whether a click issue is isolated or widespread and whether it affects an important customer journey or employee workflow.

Heatmaps

GermainUX heatmaps can aggregate click activity across users and sessions.

They help identify:

• Frequently selected elements

• Areas receiving unexpected interaction

• Dead-click concentrations

• Rage-click concentrations

• Differences between successful and unsuccessful users

• Elements that attract attention but do not help users progress

A high number of clicks does not necessarily indicate success or failure. Use the associated outcomes and Session Replay to interpret the behavior.

Business impact

Click friction can be correlated with business outcomes.

Customization

Customize the default settings only when the application’s behavior requires it.

Customize dead-click detection

The default dead-click threshold is 500 milliseconds.

Use deadClickThresholdMillis to change how long GermainUX waits for a visible page effect.

Use deadClickIgnoreNodeTypes to exclude element types that should not be evaluated for dead clicks.

The following example waits up to one second and ignores input and textarea elements:

const settings = germainApm.getDefaultSettings();

settings.plugins.click.deadClickThresholdMillis = 1000;
settings.plugins.click.deadClickIgnoreNodeTypes = [
    'INPUT',
    'TEXTAREA'
];

germainApm.start(settings);

Increase the threshold when valid application responses frequently take longer than 500 milliseconds. Reducing it can increase false positives.

Customize error-click detection

The default error-click threshold is 300 milliseconds.

The following example associates console errors occurring within one second of a click:

const settings = germainApm.getDefaultSettings();

settings.plugins.click.errorClickThresholdMillis = 1000;

germainApm.start(settings);

A longer interval can associate more errors with user clicks, but it can also increase incorrect associations.

Customize rage-click detection

By default, GermainUX identifies a rage click when it detects three consecutive clicks on the same element with no more than 500 milliseconds between clicks.

The following example requires five consecutive clicks with no more than 300 milliseconds between each click:

const settings = germainApm.getDefaultSettings();

settings.plugins.click.rageClickCounter = 5;
settings.plugins.click.rageClickThresholdMillis = 300;

germainApm.start(settings);

Adjust these settings according to the normal interaction pattern of the application.

Exclusions

Exclude elements that legitimately produce patterns resembling friction.

Possible examples include:

• Game controls

• Increment and decrement buttons

• Carousel controls

• Map controls

• Rich-text editors

• Drawing canvases

• Repeated-selection interfaces

• Controls that intentionally do not update the DOM

• Third-party widgets that GermainUX cannot fully observe

Use the narrowest possible exclusions. Broad exclusions can hide genuine user-experience issues elsewhere on the page.

KPIs and SLAs

Click monitoring is preconfigured with the appropriate browser and user-experience KPIs.

Review the available KPIs for Browser Monitoring.

Customize KPIs or SLAs only when required to:

• Set an application-specific friction threshold.

• Define an SLA for a critical control or workflow.

• Add a custom measure or pivot.

• Exclude an accepted interaction pattern.

• Categorize click friction by business impact.

• Relate an element to a specific business process.

• Configure a customer-specific notification.

Useful SLA conditions can include:

• Dead-click rate exceeds the permitted percentage.

• Error clicks affect more than a defined number of users.

• Rage clicks increase after an application release.

• Click friction occurs on a critical business-process milestone.

• An important button produces repeated dead or error clicks.

Notifications

When click friction meets a configured condition, GermainUX can:

• Send an alert.

• Notify interested users through a Watch.

• Include the insight in a dashboard or report.

• Initiate an approved investigation workflow.

For example, a Watch can notify a product owner when an error click is detected on the checkout confirmation button.

A Watch notifies users about an insight already detected by GermainUX; it does not create a new click insight.

Validation

Dead clicks

1. Open the monitored application.

2. Select an element that intentionally produces no page effect.

3. Wait for the default threshold.

4. Confirm that GermainUX creates a dead-click event.

5. Open the associated Session Replay.

6. Verify that the correct element and page are identified.

Error clicks

1. Use a safe test control that produces a JavaScript error.

2. Click the control.

3. Confirm that the console error occurs within the configured interval.

4. Verify that GermainUX creates an error-click event.

5. Confirm that the click and error appear in the same session.

Rage clicks

1. Click the same test element three times rapidly.

2. Keep the interval between clicks below 500 milliseconds.

3. Confirm that GermainUX creates a rage-click event.

4. Verify the affected element and session.

Perform validation in a non-production environment whenever possible.

Troubleshooting

If click events are missing:

1. Confirm that GermainUX RUM JS is running.

2. Verify that the correct UX Monitoring Profile is active.

3. Confirm that click monitoring has not been disabled.

4. Check whether the element is excluded.

5. Verify that the interaction occurs within an accessible browser context.

6. Review cross-origin iframe restrictions.

7. Confirm that sampling or consent did not exclude the session.

8. Check the browser console for RUM JS errors.

If too many dead clicks are detected:

• Increase the dead-click threshold.

• Exclude legitimate non-DOM interactions.

• Review delayed responses and background actions.

• Confirm that the application provides appropriate visual feedback.

If too many error clicks are detected:

• Reduce the error-click interval.

• Exclude unrelated console errors.

• Review recurring background errors that occur after every click.

• Improve JavaScript error categorization.

If legitimate rapid interactions are classified as rage clicks:

• Increase the required click count.

• Reduce the permitted interval.

• Exclude controls designed for repeated interaction.

Deployment and configuration

ℹ️ Get More Information

GermainUX can help determine which monitoring, analytics and automation capabilities are appropriate for your Browsers.

Contact GermainUX Support.