Sentry: Error Monitoring & Application Performance

Q: What does Sentry do that logs don't?

Logs are a flat stream you must search; Sentry structures errors into deduplicated, prioritized issues with assembled context (stack trace, user, breadcrumbs, release) and alerts you proactively. You could reconstruct some of this from logs, but Sentry does it automatically, groups intelligently, and is purpose-built for the "an exception occurred, here's everything you need to fix it" workflow. They complement each other.

Q: Sentry vs Datadog/New Relic?

Overlapping but different centers of gravity. Sentry is error-monitoring-first, with excellent issue grouping, release tracking, and developer-focused debugging context — and it's strong on frontend/mobile. Datadog/New Relic are broad infrastructure-and-APM platforms. Many teams run Sentry for application errors and a Datadog-class tool for infrastructure/metrics; some consolidate. Choose by whether error-debugging depth or full-stack breadth is your priority.

Sentry

Sentry is an error-monitoring and application-performance platform that tells you when your software breaks in production — with enough context to actually fix it. When an exception is thrown in your web app, mobile app, or backend, Sentry captures it along with the stack trace, the user affected, the browser/OS, the request, breadcrumbs of what happened just before, and the release it occurred in — then groups similar errors together so one recurring bug is one issue, not ten thousand notifications.

The problem it solves is fundamental: without it, you learn about production errors when users complain (if they bother), and you debug blind. Sentry closes that loop — you find out immediately, with the information needed to reproduce and resolve. It sits within the broader observability picture as the specialist for errors and exceptions, complementing metrics, logs, and traces.

TL;DR

Sentry captures unhandled errors automatically (and ones you report manually) with rich context: stack trace, user, environment, request, and breadcrumbs (the trail of events before the crash).
It groups similar errors into single issues — so a bug hitting 50,000 users is one actionable item, not 50,000 alerts.
Source maps turn minified frontend stack traces back into your real code, so a production JS error points to the actual line you wrote.
Releases tie errors to deploys — instantly see "this error started with v2.4.1," enabling regression detection and blast-radius assessment.
Beyond errors, Sentry does performance tracing (slow transactions, N+1 queries), session replay, and alerting.
The core discipline is signal over noise: capture what matters, filter the rest, and route alerts so real problems surface without fatigue.

Quick Example

Wiring Sentry into an app (JavaScript) — automatic capture plus manual context:

When this fails in production, you get the exception, the exact user, the order details, the release, and the breadcrumb trail (clicks, network calls, console logs) leading up to it — often enough to fix it without reproducing.

Core Concepts

Capture and Context

Sentry's value isn't just "an error happened" — it's the context that makes an error fixable:

Stack trace — where it broke, deminified via source maps to your real code.
Breadcrumbs — the trail of events before the error (navigation, clicks, network requests, console logs, DB queries) — often the key to why it happened.
User & environment — who was affected, on what browser/OS/device, in which environment.
Request data — URL, headers, parameters (with sensitive data scrubbed).
Tags & custom context — dimensions you add (feature, tenant, plan) to filter and search.

A raw error message tells you little; Sentry's assembled context frequently tells you exactly what to fix.

Grouping and Issues

If a bug hits every user loading a page, you don't want 50,000 identical alerts — you want one issue saying "this error affects 50,000 users." Sentry fingerprints errors (by stack trace, message, and other signals) and groups matching ones into a single issue with an occurrence count, affected-user count, and timeline. This is what makes error monitoring usable at scale: it turns a firehose of individual events into a prioritized list of distinct problems. You can tune grouping when the automatic fingerprinting splits or merges incorrectly.

Source Maps: Readable Frontend Errors

Production JavaScript is minified — a raw stack trace reads a.b.c is not a function at t (main.4f2a.js:1:24815), which is useless. Source maps (uploaded at build time) let Sentry translate that back to calculateTotal is not a function at Cart.tsx:42. Setting this up correctly is essential for frontend error monitoring — without source maps, JavaScript errors are nearly undebuggable. The same idea applies to other minified/compiled targets (mobile symbolication for iOS/Android crashes).

Releases and Regression Detection

Associating each error with a release (a deploy version) unlocks powerful workflows: see exactly which deploy introduced an error ("first seen in v2.4.1"), detect regressions (an error marked resolved that reappears in a later release), assess a deploy's health before rolling out further, and attribute issues to the commits that caused them (via commit integration). This ties error monitoring directly into your CI/CD and release process — a bad deploy's error spike is visible within minutes.

Beyond Errors: Performance and Replay

Sentry has grown past pure error tracking into broader observability:

Performance/tracing — captures slow transactions and distributed traces, surfacing slow endpoints, N+1 queries, and slow frontend page loads (Core Web Vitals).
Session Replay — a video-like reconstruction of what the user did before an error (privacy-scrubbed), turning "can't reproduce" into "watch it happen."
Alerting — routes issues to Slack/PagerDuty/email based on rules (new issue, spike, threshold).

Best Practices

Manage Signal vs Noise

The failure mode of error monitoring is alert fatigue — so many errors that the team ignores all of them, including the real ones. Combat it deliberately: filter out known-benign errors (browser extension noise, bot traffic, expected network blips) with ignoreErrors/beforeSend, set alert rules that fire on new or spiking issues rather than every occurrence, and triage the backlog so the issue list reflects real priorities. A Sentry no one looks at because it cries wolf is worthless.

Scrub Sensitive Data

Errors carry request data, user info, and variables — which can include passwords, tokens, PII, and payment data. Sentry scrubs common patterns by default, but configure beforeSend and data-scrubbing rules to strip anything sensitive before it leaves your app. Sending secrets to your error monitor is a real security and compliance risk — see Secrets Management.

Add Context Proactively

Set the user, tags, and relevant custom context early in the request lifecycle so every error carries them. The difference between "TypeError somewhere" and "TypeError for user 4821 on the checkout feature during payment for order 1042" is the difference between a two-day investigation and a two-minute fix.

Use Environments and Releases

Separate production, staging, and development so real user errors aren't buried under dev noise, and always set the release so you can correlate errors with deploys. These two settings are cheap and hugely increase Sentry's usefulness.

Common Mistakes

Alert Fatigue

Capturing everything and alerting on every occurrence trains the team to ignore Sentry entirely — at which point it stops catching real incidents. Filter benign noise aggressively, alert on new/spiking issues not every event, and keep the signal high. A tuned, trusted Sentry beats a comprehensive, ignored one.

Missing Source Maps

Frontend errors without source maps are minified gibberish — effectively unusable. Uploading source maps as part of the build is non-negotiable for JavaScript error monitoring; skipping it means you capture errors you can't debug.

Leaking Sensitive Data

Unscrubbed error context can ship passwords, tokens, and PII to Sentry. Configure data scrubbing (beforeSend, server-side scrubbing) and treat the error pipeline as a place secrets can escape. This is both a compliance and a security concern.

No Ownership or Triage

An error monitor accumulating thousands of unreviewed issues is noise, not observability. Someone must own triage — assigning, resolving, ignoring, and tracking issues — or the tool becomes a graveyard nobody trusts.

Treating It as Your Only Observability

Sentry excels at errors and traces but isn't a full replacement for metrics, logs, and infrastructure monitoring. It answers "what broke and why" for application errors; you still need the broader observability stack for system health, capacity, and non-error behavior.

FAQ

What does Sentry do that logs don't?

Logs are a flat stream you must search; Sentry structures errors into deduplicated, prioritized issues with assembled context (stack trace, user, breadcrumbs, release) and alerts you proactively. You could reconstruct some of this from logs, but Sentry does it automatically, groups intelligently, and is purpose-built for the "an exception occurred, here's everything you need to fix it" workflow. They complement each other.

Is Sentry only for errors?

It started there but now also does performance monitoring/tracing, session replay, and (increasingly) logs and broader observability. For many teams it's the primary tool for application-level errors and performance, alongside infrastructure monitoring from Prometheus/Datadog. Error monitoring remains its core strength.

Do I need source maps?

For frontend (JavaScript) and mobile, effectively yes — without them, minified/compiled stack traces are undebuggable. Upload source maps (or mobile debug symbols) as part of your build so Sentry can map errors back to your real source. It's a one-time setup with outsized payoff.

Sentry vs Datadog/New Relic?

Overlapping but different centers of gravity. Sentry is error-monitoring-first, with excellent issue grouping, release tracking, and developer-focused debugging context — and it's strong on frontend/mobile. Datadog/New Relic are broad infrastructure-and-APM platforms. Many teams run Sentry for application errors and a Datadog-class tool for infrastructure/metrics; some consolidate. Choose by whether error-debugging depth or full-stack breadth is your priority.

Is it self-hostable?

Yes — Sentry is open source and can be self-hosted, though the hosted SaaS is what most teams use (self-hosting the full modern stack is non-trivial). Self-hosting matters for data-residency or privacy requirements where errors (potentially containing sensitive data) can't leave your infrastructure.