The bugs that throw no error

Error trackers are good at one category of failure: the kind that throws. Something raises, a stack is captured, an issue appears, someone gets paged. That category is real and worth catching, and it is also the minority of the ways an application disappoints a person.

The larger category throws nothing. The button whose handler was never bound. The request that returns a clean 200 with an empty body. The page that works but takes nine seconds. The form that loses an entry when a session quietly expires. Every one of those is a failure. None of them raises an exception, so nothing in an error tracker will ever mention them.

They also do not reliably produce tickets. People do not file bugs about mild annoyance. They try again, then give up, then go do something else, and the only trace is a number that got slightly worse.

The user tells you anyway

Here is the useful part. A person who hits one of these does something distinctive, and it is visible in the event stream if anyone is watching it. Frustration has a shape. Somebody clicking a dead button does not click it once and calmly move on. They click it four times.

So the signal to watch is not the application's error output. It is the behavior of the person in front of it. The browser SDK keeps a rolling buffer of the last five minutes of session events and runs four detectors over that stream. When one fires, the window around it is flagged as a bug with nobody filing anything.

Rage click

Four or more clicks on the same target within one and a half seconds. This is the dead control: the handler that never bound, the submit that silently validates false, the link whose click is being swallowed by an overlay you cannot see in a screenshot.

Worth noting what makes this reliable. It keys on a stable component signature rather than a CSS path, so a rerender that changes class names does not split one angry user into four unrelated targets.

Retry storm

Four or more requests to the same endpoint within five seconds, or repeated failed responses to it. This is the user hammering refresh, and it is also, more often than teams expect, the application hammering itself: a retry policy with no backoff, an effect that refires on every render, a poll that never got cleaned up.

The second case rarely gets reported by anyone, because from the outside the page merely feels sluggish. From the inside it is one client generating load in a tight loop.

Slow response

Three or more responses of three seconds or longer inside a ten second window. Not one slow call, which happens to everyone, but a stretch where the application is consistently slow enough to feel broken.

The reason to record this as an event rather than watch it on a latency chart is that a chart tells you the ninety fifth percentile moved. The event tells you which session, which endpoints, and what the person was in the middle of doing when it happened.

Abandoned flow

Two or more filled inputs, and then the tab hides with no submit. Somebody started giving you information and stopped. This is the one teams underrate, because it is the closest thing in the list to a direct revenue signal and the least likely of the four to ever generate a ticket.

Nobody writes in to say they abandoned your signup form. They just do not sign up.

Thresholds are yours

Every number above is a config key. A drawing tool sees legitimate rapid clicking all day and needs the rage click threshold raised. A batch operations console has slow calls by design and needs the response window widened. Defaults exist so the tool works on the first run, not because we think your application has our rhythm.

What to do with a flag

The flag marks a reproduction window: the events on either side of the moment the person gave up. That window is what a coding agent needs, because it contains the ordered steps that led in, the requests in flight, the console output, and the state of storage and feature flags at the time.

Which is the difference between telling an agent that checkout is slow and showing it the ninety seconds in which one real person tried three times and left.

The detectors ship in the browser SDK, which is MIT licensed and published to npm. Turning them on is one initialization call and no account.

npx crumbtrail