How to Add Sentry Error Tracking to a Web App in 20 Minutes

Sentry captures unhandled exceptions and performance traces from your app and groups them by stack trace fingerprint. The setup is: create a project, install the SDK for your framework, add the DSN, and upload source maps on each deploy. Front-end and back-end take about ten minutes each.

Source maps are the step people skip, and it is the one that makes Sentry useful. Without them every stack trace reads vendor.bundle.js:1:48213 and you learn nothing.

What Does Sentry Actually Do?

Sentry is an error tracking service. It receives exception events from your app, deduplicates them into issues, and shows frequency, affected users, and the release where it first appeared.

It is not APM and not logging. Datadog covers infrastructure metrics and logs; Sentry covers “this code threw an error, here is the payload that broke it.” Teams use both, and the overlap in cost is a common budget argument.

How Do I Install Sentry in a Node Back End?

npm install @sentry/node

Sentry.init({ dsn: process.env.SENTRY_DSN, environment: process.env.NODE_ENV, release: process.env.GIT_SHA, tracesSampleRate: 0.1 })

Initialize before your framework mounts. In Express, that means before app.use(...) calls — Sentry’s docs say it plainly and people still get empty traces because they initialized after routes.

Set tracesSampleRate below 1.0 unless traffic is small. A 0.1 sample gives statistically usable performance data without paying for every request.

How Do I Set Up the Front End Correctly?

For React, npm i @sentry/react, then call Sentry.init with your DSN and integrations: [Sentry.browserTracingIntegration()].

The essential step is source map upload:

1. Create an auth token in Sentry with project:releases scope.
2. Add sentry-cli to your build pipeline and run sentry-cli releases new $GIT_SHA.
3. Upload maps: sentry-cli releases files $GIT_SHA upload-sourcemaps ./dist.
4. Finalize: sentry-cli releases finalize $GIT_SHA.
5. Delete .map files from the deployed bundle.

That last step matters for two reasons: maps expose your source publicly if left in place, and Sentry needs them at upload time, not at runtime.

How Do I Stop Alert Noise?

The defaults send an email for every new issue, which produces hundreds of notifications in the first week. Fix in this order:

• Ignore patterns per project for browser extension errors — they are never your bug.
• Inbound filters to drop errors from localhost, bots, and known browser quirks.
• Alert rules scoped to level:error and an event count threshold (10+ in an hour) rather than every event.
• Release tag on every deploy, so you can tell new breakage from ignored old breakage.

What Does Sentry Cost?

The free Developer plan includes 5,000 errors per month, 50 session replays, and one user. That is enough for a side project and not enough for a production app with real traffic.

Team starts around $26 per month with 50,000 errors included, and pricing scales by event volume. The trap is noisy errors: one retry loop hitting an unhandled promise can burn your entire monthly quota in an afternoon. Quota exhaustion also disables alerts, so you find out from users instead.

Set a per-key rate limit (Sentry.init({... maxBreadcrumbs: 50}) plus a server-side rate limiter) before you go live.

Where Sentry Falls Short

Error grouping occasionally splits one bug into many issues when the stack differs, and merges unrelated bugs when fingerprints collide. You will spend time on issue hygiene.

Context depth is also limited by what you attach. Without breadcrumbs and user context, an error report is a stack trace with no story.

Who Should Use It

Any app with paying users and more than one engineer. Skip it for a static site with no JavaScript logic — there is nothing to throw.

Quick Summary

• Sentry groups exceptions into issues by stack fingerprint and tracks releases.
• Initialize before framework routes mount or traces come back empty.
• Upload source maps per release, then delete them from the deployed bundle.
• Free plan: 5,000 errors/month, one user — rate-limit noisy errors or quota dies fast.
• Not a replacement for logs or infrastructure metrics.