# Your error tracker thinks your site is fine

Canonical: https://flusterduck.com/blog/your-error-tracker-thinks-your-site-is-fine
Published: 2026-07-30 · The Flusterduck team

Every bug we caught on our own sites last month shipped without throwing a single exception. Notes on the failures that live outside the console.

I went back through every bug we caught on our own sites in the last month. All of them had one thing in common: none of them threw. Not one exception, not one failed request, not a single red row in any tracker. As far as the runtime knew, the site was healthy the entire time.

This is not a complaint about error trackers. They do their job, and they do it well. The problem is that a whole category of expensive failure is defined by nothing happening, and you cannot log an event that does not exist.

## Bugs made of nothing

Some examples, all real:

- A button whose click handler quietly fell off in a refactor. Clicking it does nothing. Doing nothing is not an error.
- A form that fails validation and renders the message off-screen. The user watches the form reset and draws the obvious conclusion, which is that your product is broken.
- An invisible overlay parked on top of half the navigation at one specific width. Every click lands on the overlay. The overlay is executing flawlessly.
- Hover styling on table cells that were never clickable. People click them anyway. [This one happened to us](/blog/ai-investigates-our-site-every-night). One visitor clicked those cells 55 times.

Every one of these is a promise the interface made and broke. The code does exactly what the tests assert. The gap is between what the code does and what a person standing in front of it was led to expect, and no test file in your repo describes that expectation. None. Anywhere.

## The other error channel

Here's what took me too long to notice: these bugs do report themselves. Every time. Just not to the console.

A person who clicks a dead button clicks it again, faster. A person whose form silently resets types it all again, then quits halfway through the second attempt. A person stuck under an invisible overlay produces a tight cluster of clicks and leaves through the back button. These patterns are as recognizable as stack traces, and they localize the fault the same way, down to the element.

So you have two error channels. The runtime tells you when the code breaks. The audience tells you when the product breaks, in the only language they have. Nearly every team pipes the first channel into pagers, dashboards, and on-call rotations. Almost nobody instruments the second. Which is strange, because the second channel is the one with the money in it.

## The fifteen-minute version

You can sample your own second channel by hand, today. Open your most important page and click everything that looks clickable, including the parts you know are decorative. Every hover effect on a dead element is an invitation you personally extended to every visitor. Then break your signup form on purpose, twice, on a phone, and watch where the error message renders.

We run this exercise on our own properties and find something every single time, and finding this stuff is the product we sell. I've stopped being embarrassed about that, because it's the strongest evidence for the whole thesis: you cannot see the interface you look at every day. Familiarity is a rendering bug in the human reviewer. It's why we eventually pointed a machine at the problem. The machine has never seen the page before. Every night. Forever.

Steal the reframe even if you never touch anything we make. Your error tracker's silence is a fact about your code. Your users' behavior is a fact about your product. They disagree far more often than anyone wants to believe.