A dead click is a click the page never answered. Analytics tools count it as friction and trend it over time. Many dead clicks are defects: a button under an invisible layer, a handler that never attached, a request that never came back. Fixing one needs the session on a ticket, and a dashboard holds only the rate.
A dead click is defined by what the page failed to do
Clarity and Fullstory both write the definition from the page’s side. Microsoft Clarity’s documentation on semantic metrics marks a click as dead “when a user clicks on an element but gets no feedback in a reasonable amount of time”, and spells out what no feedback means: “the visual status doesn’t change, and there’s no navigation away from the page.” Fullstory’s help article on frustration signals puts it as “clicks or taps that have no effect on the page”, marked when “nothing on the page changes within a few seconds of a click or tap.” The waiting window is worded differently in each, and neither passage pins it to a number. The test underneath is the same: the recorder watched the page and saw nothing happen.
Both vendors already name breakage among the causes. Clarity says a dead click “can signify broken elements, high latency requests, or misleading UX”. Fullstory’s examples run from an image somebody expects to zoom to “Is that form-submit button just not working?” So the definition contains the defect. What the metric does next is file it beside the confusing design, under one count, as a sign of poor experience.
That shared count is where the trouble starts. A heading styled like a link and a checkout button sitting under a transparent overlay produce the same event, because the event records only that the page stayed still. The difference between them lives inside the page: in the stacking order, in whether a listener was ever bound, in a request still waiting for its answer. A click position and a timestamp reveal none of those.
Counting dead clicks finds the pattern a single report never shows
The aggregate view has real work to do. Collected across every session a site records, dead clicks show where many visitors expected something that never happened. One person clicking a product photo that does not enlarge would never write in about it, and would be right not to: nothing is broken. Many people doing it on the same photo is a design finding, and only a tool that counts can surface it.
For that family, the dashboard is also the right place to check the fix. Make the photo open a larger view, or stop styling the caption as a link, and the count for that element should fall. No ticket is needed, because no single session holds anything a designer would learn from.
The same view catches some defects early. A button that collected almost no dead clicks last week and collects them steadily after a release is a regression announcing itself, much as real user monitoring shows a page getting slower for one device class before anyone complains. The dashboard is good at answering where and since when. It goes quiet on why, and why is the whole job once the element is supposed to work.
The click is the same and the cause decides who fixes it
A dead click on an element that is meant to act has a mechanism, and each mechanism leaves its evidence in a different place.
| What the dead click was | How to tell | Where the evidence lives |
|---|---|---|
| A design that looks interactive and is not | No handler was ever expected; console and network stay quiet | The aggregate: many visitors, one element |
A button covered by another element (a backdrop a closed modal left behind, a banner container, a wrong z-index) | The element under the pointer is not the button the person aimed at | The page as rendered at that moment, often only at one viewport width |
pointer-events: none left on the element by a loading or disabled state that never cleared | The button is on top and still ignores the click | The element’s computed style in that page state |
| A handler that never attached, because a script threw during start-up or was blocked | An exception at page load, long before the click | The console from page load onwards |
| A handler that runs and fails quietly | An exception at the moment of the click, caught or not | The console at the click |
| A request that hung, or failed with no message to the user | A call left without a response, or an error status nobody showed | The network log, with status and timing |
| A response the recorder missed (an update off-screen or slower than its window) | Something did change, later or elsewhere | The session itself, watched past the click |
Only the first row belongs to design, and the last row is not a failure at all. Everything between is a client-side error or something close to one, and every one of those rows needs evidence that only a single session holds.
The fourth row is the one the metrics are least equipped for. Both vendors also define a click-and-error signal: Clarity’s click errors “are JavaScript errors that occur after a user click”, and Fullstory’s error clicks surface sessions with “a click or tap right before a client-side JavaScript error or console error occurs”. A handler whose setup threw while the page loaded logged its console error then, possibly long before anyone clicked. The click itself throws nothing, so it would not count as an error click under either definition, and the exception that explains it sits far from the moment anyone would look.
The second row has its own trap. An overlay that covers a button at one breakpoint and clears it at another produces dead clicks on some laptops and none on the developer’s monitor, which is the same pattern cross-browser issues traces to the viewport rather than the browser.
A defect is fixed from one session, and that session has to reach a ticket
The person who met the dead button did not file anything. They clicked again, reloaded, tried another route or left. For the team, the bug exists only as a number on a dashboard somebody may read this week, which is what makes a dead click a bug report nobody filed.
Turning it into a filed one takes work that the metric does not do. Someone has to decide that the cluster on this element is a defect and not a design question, open a session where it happened, find the click, and write steps to reproduce that name the page state, the browser, the viewport and the account involved. Then a developer needs the evidence that sorts the table above: what sat on top of the button, what the console said at start-up, which call never returned. Without those, bug reproduction starts from a description of a button that “doesn’t work”, and the overlay that only appears at one width is the condition a developer on a different screen may never hit.
An analytics team that finds a dead-click cluster on a submit button has probably found a bug, and the useful next move is a ticket with one session attached, owned by whoever owns that button. Leaving it on the dashboard as a friction score to bring down over a quarter treats a broken control as a conversion problem.
Notarus attaches the session to a report and counts nothing
Notarus is built for the rows of that table one session can explain, once somebody has reported that session. Session replay records eligible sessions in the background from the moment the page is ready, and logs rage clicks, three clicks on one target inside a second, as their own event. When a report arrives saying that Pay did nothing, the available recording is linked to the ticket with the console output and the network requests, each request kept as the call and its result. The player runs beside a log of the same session, so a developer can see the console errors and requests captured around the click in the order they happened.
Two rows still take work after that. A covered button and a stuck pointer-events rule both look, on the film, like a click that landed on a page that did not move, and telling them apart means rebuilding that page state and inspecting the element. Because the film starts once the page is ready, a handler that threw during start-up may have failed before the replay began, and where the recording has a gap the player marks the interval it missed.
Counting is the part Notarus leaves alone. It does not detect dead clicks, score them or draw heatmaps, so the photo many visitors try to enlarge, and the dead button nobody writes in about, stay with whichever analytics product the team already runs.
