Install the SDK, set the DSN, upload source maps — and every unhandled exception arrives grouped, deduplicated, and pointing at the real line of code instead of minified noise.
The whole path from silent failures to grouped, alerting errors. Source maps and alert rules are the two steps that separate a useful setup from a noisy one.
Sign up at sentry.io (or self-host — same product, your infra) and create a project per app, picking the platform so the setup wizard matches. Sentry hands you a DSN: a public-ish ingest URL that identifies where events go.
The DSN isn't a secret in the way an API key is — it can only submit events, not read them — but keep it in config/env anyway so staging and production report to separate projects.
Install the SDK for your stack and initialize it as early as possible in the app's startup, before anything that might crash. Set environment (production/staging) and release — release is what later lets Sentry say "this error started in v1.4.2."
Unhandled exceptions are captured automatically from that point. For handled-but-notable failures, call captureException in your catch blocks — silent catches are where the interesting bugs hide.
Sentry.init({
dsn: process.env.SENTRY_DSN,
environment: "production",
release: "[email protected]",
tracesSampleRate: 0.1,
}); A minified stack trace is nearly useless. Wire your build to upload source maps — Sentry ships bundler plugins (Vite, webpack, esbuild) and a CLI that do it in one step, keyed to the same release string you set in init.
Do the upload in CI, not from laptops, so every deployed release has matching maps. This is the single step that most improves day-to-day debugging value.
Default "alert on every new issue" gets muted within a week. Better baseline: alert when a new issue appears in production, and when any issue exceeds a rate threshold (say 50 events in an hour). Route to Slack for visibility and email/PagerDuty for the high-threshold rule.
Mark noisy-but-harmless issues as ignored with conditions (ignore until it happens 100×) rather than resolving them repeatedly.
Review what leaves your app: enable server-side data scrubbing (on by default), add your own sensitive field names, and use beforeSend to drop or redact anything the defaults miss. Error events include request data and user context — treat them like logs, because they are.
Keep tracesSampleRate low (5–10%) unless you're actively using performance data; errors are always captured regardless, and quota is what you pay for.
Stack traces are minified garbage.
Source maps missing or release strings don't match between init and the upload. Make both use the exact same release value, uploaded in CI.
Quota burns down in a day.
One looping error or a chatty integration. Set rate-based ignores on the offender, add beforeSend filtering, and cap with spike protection in project settings.
Errors from localhost and staging pollute production.
Same DSN everywhere. Use separate projects (or at minimum the environment tag plus environment-filtered alerts) per deploy target.
'ResizeObserver loop' and browser-extension noise dominate.
Add the standard ignore list (Sentry publishes one) to ignoreErrors, and use allowUrls to only accept events from your own bundles.
User reports a bug but there's no matching event.
The error was swallowed by a catch block or happened before Sentry.init ran. Initialize earlier, and add captureException to broad catch handlers.
Honesty note: articles are drafted with AI assistance, then a human checks each one against the vendor's current setup flow before it publishes — nothing goes live unreviewed. Vendor interfaces still change; if a step looks different, the underlying record is what matters.