Setting up Sentry for a Single Page Application (SPA) usually puts you in a dilemma: you either get useful data or you just collect junk. Using error tracking tools is easy, but the real challenge is making sure your dashboard doesn't turn into a "data museum" filled with confusing noise.
I used to think that the more errors recorded, the better our monitoring was. I was wrong. A dashboard cluttered with thousands of events often gives a false sense of security. The ideal target is actually quite simple: Sentry should tell us exactly what broke, in which version, and whether it's a new issue. If it can't answer those, it's better not to have the data at all.
In practice, you have to be aggressive about filtering what enters your system. Focus on uncaught exceptions or failures in critical flows like checkout and auth. Everything else should be treated as noise. Errors caused by a user's browser extensions, network issues that already have a retry mechanism, or even simple window resize events don't need to trigger notifications. Even 401 or 403 statuses should be ignored if they are expected application behavior. Those aren't bugs.
One crucial aspect that often gets overlooked is PII (Personally Identifiable
Information). By default, Sentry can potentially capture emails or usernames
through breadcrumbs. To avoid the risk, use masked IDs or clean sensitive data
like passwords and tokens using the beforeSend function. If you can't clearly
explain how that data is stored and who can access it, you probably shouldn't be
blindly enabling features like session replay.
On the technical side, source maps and release versions are non-negotiable. Without uploading source maps via your CI, the stack traces you get are just minified code that's useless to read. I always make sure every build has a clear version identity through environment variables. That way, if a regression happens, we know exactly which commit introduced the problem.
Don't get trapped in bad sampling settings, either. Turning on 100% tracing in production doesn't mean you're getting more insight; it just means you're paying a higher cost for a mountain of unnecessary logs. We need insights, not just numbers.
An effective error tracking system is one that lets you work with peace of mind. You should only get an alert if something actually requires action. And when that alert does show up, you should be able to jump straight to the problematic line in your original source code without being distracted by third-party noise or irrelevant data.