We Found and Fixed 16 Errors Across 5 Client Sites Before Anyone Noticed

Mike Kerchenski
Mike Kerchenski ·
We Found and Fixed 16 Errors Across 5 Client Sites Before Anyone Noticed

How we use Sentry and Microsoft Clarity to find bugs, silent failures, and UX friction before clients report them.

Most web agencies build your site and walk away. If something breaks, you find out when a customer complains. Or worse, when you lose a sale and never know why.

That's not how we work. Every month, I run a full audit across all my client sites using two tools: Sentry for error tracking and Microsoft Clarity for user behavior analytics. This week's audit is a good example of what that looks like in practice.

The Audit: 5 Sites, 16 Issues, Zero Client Reports

I manage five production web apps on the Hurrah.dev platform. Each one has Sentry capturing every server error and Clarity recording every user session. Here's what a routine Monday morning audit found.

Sentry: Errors Nobody Reported

Across all five sites, Sentry showed 16 unresolved issues. Here's how they broke down:

  • 3 real bugs that needed code fixes
  • 3 issues that needed investigation (turned out to be an iOS Safari quirk)
  • 10 framework noise issues (Blazor Server lifecycle events that look like errors but aren't)

The real bugs were the interesting ones.

A Silent SMS Failure

One client's app sends SMS notifications to customers. Sentry flagged 99 failed SMS attempts over the past year with the message: "Permission to send an SMS has not been enabled for the region indicated by the 'To' number."

The customers were in Mexico and the Philippines. The app tried to send, Twilio blocked it because those regions weren't enabled, and the error was caught and logged. But nobody knew. The staff thought the SMS went out. The customers never received it.

The fix took 2 minutes: enable Mexico and the Philippines in the Twilio console. Cost: about $0.20 per message when they actually send. The cost of not fixing it: customers who thought they were being ignored.

7,482 Dead Clicks

On the same client's wholesale inventory app, Clarity reported 7,482 "dead clicks" in 28 days. That's clicks on elements that don't respond. Nearly 4 dead clicks per session.

I pulled session recordings from the worst pages and analyzed 30 sessions. The pattern was clear:

The checkout page was the biggest offender. Users were clicking on cart line items (phone models, carrier info, prices) expecting something to happen. The items showed product details but had no remove button and weren't clickable. Users clicked, nothing happened, they clicked again harder (Clarity calls these "rage clicks"), and 29 rage clicks happened on the checkout page alone.

The fix: I added remove buttons to cart items, made item names link back to the product detail page, and added a clipboard copy button to serial number fields that users were trying to select.

The iOS Safari Mystery

Three separate Sentry issues showed "Importing a module script failed" across different components. All 44 events came from Mobile Safari on iOS 18. No other browser, no Android, no desktop.

The cause: iOS Safari aggressively purges cached resources when the phone sleeps or switches tabs. The app's server connection survives, but when it tries to load a JavaScript module, Safari has already thrown it away. The fix was a simple retry with a 1-second delay. Safari almost always succeeds on the second attempt.

Why This Matters for Your Business

These aren't hypothetical scenarios. This is what happened on a single Monday morning across five real business applications.

  • The SMS failure was costing a client real customer relationships. International customers weren't getting order notifications. Nobody complained because they didn't know what they were missing.
  • The dead clicks meant users were frustrated every time they checked out. In an inventory app where speed matters, 4 dead clicks per session adds up to thousands of moments of friction.
  • The iOS issue meant ~5% of mobile users got a broken experience. They'd open the app on their phone, and it would just stop working.

None of these were reported by clients. They were found through routine monitoring.

What Proactive Monitoring Actually Looks Like

Here's the process:

  1. Sentry audit -- Triage every unresolved error. Resolve what's been fixed, ignore framework noise, investigate real bugs.
  2. Clarity review -- Check dead clicks, rage clicks, bounce rates, and scroll depth. Watch session recordings for the worst pages.
  3. Cross-reference -- Sentry tells you what broke. Clarity tells you what frustrated users. Together they reveal issues neither catches alone.
  4. Fix and deploy -- Same day. Not "we'll put it in the next sprint."

This isn't extra. It's included in the $250/month subscription. Your app doesn't just get built and forgotten. It gets watched, maintained, and improved continuously.

The Takeaway

If you're paying someone to build your web app and they're not monitoring it after launch, you're paying for a product that degrades over time. Errors accumulate. User friction compounds. Performance drifts.

The businesses I work with at Hurrah.dev don't have to worry about that. Bugs get found and fixed before they cost you customers.

If you're running a business on spreadsheets and manual processes, and you want a custom app built by someone who actually watches the data after launch, let's talk.

Need help with this?

We build custom business software for $250/month with no setup fees. If this article resonated, let's talk about your situation.

Mike Kerchenski

Mike Kerchenski

Experienced full-stack developer with over 25 years of expertise in building web and mobile applications. Proficient in ASP.NET, .NET Framework, ASP.NET MVC, Web API, ASP.NET Core, and Azure. Skilled in database design, database programming, IIS, deployment, source control, dev ops, and front-end development. Passionate about the art and science of programming, constantly learning, and adhering to best practices such as source control, unit testing, and SOLID principles.