Sentry

The DSN (Data Source Name) is a URL that contains the project's public key and ID and tells the SDK where to send events. It only allows sending events to that project, not reading data or changing settings, so it is designed to be embedded in browser and mobile apps. The real secret is the auth token used by sentry-cli and build plugins to create releases and upload source maps; that one must stay in CI secrets. The risk of an exposed DSN is spam: someone could send fake events and consume quota. Mitigate it with allowed domains, rate limits per key and inbound filters.

Production JavaScript is minified and bundled, so a raw stack trace points to something like main.4f2a.js line 1, column 48211, which is useless. Source maps map those positions back to the original file, line and function. Sentry uses them on its servers to show readable stack traces with surrounding code. To keep your source private, upload the maps to Sentry during the build and do not deploy them to the public server: the bundler plugins can delete them after upload, or you can exclude .map files from the deploy. Debug IDs injected into each file let Sentry match maps reliably without relying on public URLs.

Each event gets a fingerprint. By default it is based on the stack trace, mostly the in-app frames, which is your code rather than libraries; if there is no stack trace it falls back to the exception type and message. Events with the same fingerprint belong to the same issue. Sometimes the default is wrong: one generic error from different causes merges into one issue, or a dynamic message creates thousands of issues. You fix that with fingerprint rules and stack trace rules in project settings, or by setting a custom fingerprint in the SDK, for example grouping all timeouts from one API client by endpoint.

Error tracking captures exceptions and crashes with stack traces and context, groups them and alerts. Tracing (performance monitoring) records spans for page loads, navigations, API requests and database queries, so you see how long things take and where the time goes, even when nothing fails. Sentry connects them: an error carries the trace ID, so you can open the request that failed and see the slow query before it. Errors are usually kept at 100%, while traces are sampled because their volume is much higher. Since version 8, Sentry's JavaScript SDK uses OpenTelemetry internally, so it can work alongside other OTel instrumentation.

Logs tell you what the server did; Sentry tells you which problems users actually hit and how often. Most frontend and mobile errors never reach server logs at all: a crash in the browser or app happens on the user's device. Sentry captures those, groups thousands of events into a short list of issues, shows the exact line of original code, the release and commit that introduced it, how many users are affected, and a replay of what the user did. It alerts the team when a new problem appears after a deploy. That usually turns a bug from days of guessing into an hour of fixing, which pays for the plan quickly.

Structure and ownership come first. Create projects per deployable app, use environments (production, staging) and releases consistently, and add ownership rules or code owners integration so each issue is auto-assigned to a team. Alert on what matters: new issues in production, regressions, and metric alerts on error rate or crash-free sessions tied to SLOs, routed to the owning team's channel and paging only for user-impacting thresholds. Reduce noise with inbound filters, ignore rules and fingerprint rules for known groups. Run a weekly triage per team with a simple rule: resolve, assign, or archive with a reason. Track crash-free rate per release as a release gate. The trade-off is upfront configuration work, which pays back as trust in alerts.

They overlap but are focused differently. OpenTelemetry is an instrumentation standard and pipeline; it gives you portable traces, metrics and logs, but no backend, no issue grouping and no workflow. Sentry is a product built around developer workflows: grouping, regressions, release health, suspect commits, replays and source map handling, plus tracing. Since its JavaScript SDK runs on OpenTelemetry internally and Sentry accepts OTLP, they combine well: OTel instrumentation for backend services with a Collector exporting traces to your tracing backend, and Sentry for frontend and mobile errors, crashes and replays, sharing trace context. Choose by questions: "which code is broken for users?" fits Sentry; "where does latency go across 30 services?" fits an OTel tracing backend.

Collect the minimum. Use an internal user ID instead of email or name, keep default PII collection off, and strip headers, cookies, query strings and request bodies that may contain personal data in beforeSend. Enable server-side data scrubbing and advanced scrubbing rules as a safety net. For Session Replay, keep the defaults that mask all text and block media, and unmask only specific safe elements; never record payment or medical forms. Choose the EU data region if your users are in Europe, sign the data processing agreement, and set retention as short as is useful. Document Sentry as a processor in your privacy policy. Finally, honour consent: initialise replay only after the user accepts, if your legal basis requires it.