Your Customers Are Not Your Error Tracker
Here is how most small software companies find out something is broken: a customer tells them.
It feels like a system. The email arrives, you reproduce it, you fix it, you reply. The customer is grateful. You move on. And because this happens a few times a month, it is easy to believe you are hearing about most of what goes wrong.
You are not. You are hearing from the small minority of people who bothered to write, about the small minority of failures that were bad enough to write about. Everyone else closed the tab.
The people who do tell you are telling you late
In 2021, Rollbar surveyed nearly a thousand developers about how they learn about errors in production. A quarter said they had heard about a bug from users posting on social media. More than a fifth had heard about one from their CEO. Seventeen percent had found out from press coverage.
Read that list again as a ranking of how badly a bug has already gone by the time you hear about it. Social media means it was frustrating enough that someone told strangers before they told you. The CEO means a customer who mattered went over your head. Press means it is now a story.
None of those channels are early warning. They are the sound of a failure that has already done its damage.
The same survey found developers spend more than a quarter of their time fixing bugs, and 55% said they would ship more features if they did not. Bug-fixing is not the problem; every product has bugs. The problem is that a bug you learn about from a tweet costs more to fix than the same bug caught an hour after the deploy, because by then it has a reputation attached.
The people who do not tell you are the majority
The bigger number is the one you cannot see.
PwC surveyed 15,000 consumers for its Experience Is Everything report and found that 32% would stop doing business with a brand they loved after a single bad experience. In the US, 59% walk away after several. Those are people who liked the product. One broken checkout, one export that spun forever, one password reset that never arrived, and a third of them are gone.
Now put that next to the reporting rate. The widely cited figure from Lee Resource is that for every customer who complains, 26 stay silent. That number is old and the methodology is thin, so treat it as a shape rather than a measurement. But even if it is off by half, the shape holds: most of the people who hit your bug did not write in. They hit it, they decided how they felt about you, and they left or they stayed. You did not get a vote.
So the ticket that says "the export button just spins" is not one unhappy customer. It is one unhappy customer who wrote, standing in for a group who did not.
What "hearing about it earlier" actually means
Every developer already knows the fix is monitoring. The interesting question is why so many small teams have monitoring and still find out from customers.
Usually it is one of three things.
The errors go somewhere nobody looks. The tracker is installed, it fires, and its dashboard is the seventh tab in the morning check. By the time you open it, the customer's email is already in the second tab.
The errors and the customers live in different tools. Your tracker knows a TypeError in export.ts fired 340 times since 9 AM. Your helpdesk knows two people wrote in about exports. Nobody joins those, because joining them means holding two dashboards side by side and doing the match in your head. So you answer the tickets and, separately, you eventually fix the error, and you never find out they were the same event.
Nothing groups the noise. Three hundred and forty lines of the same stack trace with different request ids is one problem, not 340. If the tool shows you 340, you stop reading.
Fix those three and the sequence flips. The error is fingerprinted and grouped the moment it arrives. A watchdog notices it is new, or that it is recurring, and puts it in the same inbox as the tickets. When the first customer writes in, you already know what they are about to say, and you know how many other people hit the same thing and said nothing.
That last group is the one worth a proactive note. A customer who receives "we saw the export fail for you this morning, it is fixed, sorry" before they had to write is not a support cost. They are the 68% who stayed, and now they know why.
The arithmetic
Suppose a hundred customers hit a bug this week. If the reporting shape above is anywhere near right, three or four write in. You fix it because of them. The other ninety-six decide, individually and silently, whether it was the single bad experience that PwC says ends a third of relationships.
Your error tracker saw all hundred. The question is whether it told you in a place you were going to look, and whether it could point at the people involved.
Helmdesk keeps the log next to the tickets: events are fingerprinted into issues, the Log Watch agent flags new and recurring ones every fifteen minutes into the same review queue as the drafted replies, and because the customer directory is the join, "who hit this and has not written in yet" is a question you can ask. The logs docs cover the setup; this post covers the crossing.
Your customers were never your error tracker. They were just the only one you were reading.
Sources: Rollbar developer survey, Business Wire, Feb 2021; PwC, Experience Is Everything, 2018; the 1-in-26 figure is attributed to Lee Resource and is widely recycled without a primary citation, which is why this post treats it as a shape.
Hear about it before the customer does
Ship your app's errors to the same desk as its tickets. Grouped, watched, and joined to the customer who hit them.