How to Use Sentry: The Beginner's Guide (2026)

CodexFuse Team · 2026-10-31T03:57:27.257Z · 14 min read

How to Use Sentry: The Beginner's Guide to Error Tracking That Actually Works

Learning how to use Sentry is the moment your app stops being a black box. Right now, the most common way developers find out about a crash is an angry message from a user, three days after the fact, with no details attached. Sentry flips that around: a tiny SDK lives inside your app, catches errors the second they happen, and hands you the exact line of code, the trail of events that led there, and which deploy introduced it.

This Sentry for beginners tutorial walks the full arc, start to finish: create a project, grab your DSN, initialize the SDK in a Node.js and Express app, trigger one real error, read the issue it produces, triage it, and set up a single alert rule that tells you about new problems without flooding your inbox. Before your first real user finds a bug for you, break your own app on purpose — a quick pass over your endpoints with a REST API tester gives Sentry something to catch, so you can practice the whole loop in minutes.

What Is Sentry and How Does It Work?

Sentry is an error-tracking and performance-monitoring platform: you add its SDK to your application, and from that point on, uncaught exceptions, unhandled promise rejections, and errors you capture manually are reported to your Sentry project automatically, grouped into actionable issues. Think of it as the difference between a log file and a triage desk — logs record that something happened, Sentry tells you what broke, where, how often, and whether it is new.

Here is the whole journey of one error:

1. The SDK is installed in your app and initialized once at startup with your project's DSN.
2. Something throws — an uncaught exception, an unhandled rejection, or a manual Sentry.captureException() call.
3. The SDK packages the event: the stack trace, the release version, the environment, breadcrumbs (the clicks, logs, and HTTP requests that happened just before), and user context if you set it.
4. Sentry groups identical events into one issue using a fingerprint built mostly from the stack trace, so 1,000 crashes from the same line become one issue with a count of 1,000.
5. You triage the issue — assign it, resolve it, or set an alert so the next new one pings you.

How Do You Create Your First Sentry Project?

Sign up at sentry.io, create a project for your platform, and copy the DSN — the whole thing takes about two minutes, and everything after it depends on getting the platform choice right.

1. Sign up at sentry.io — the Developer plan is free for a single user, which is all a beginner needs.
2. Create an organization (your name or company is fine) and click Create Project.
3. Pick the platform that matches your app — choose Node.js for a backend, Express if you are on Express specifically, or React / Browser JavaScript for a frontend. This choice only affects which SDK the setup wizard recommends.
4. Name the project after your app and leave the alert defaults alone — you will tune alerts later in this guide.
5. Copy your DSN from the setup page (or later from Project Settings, then Client Keys). It looks like https://<key>@o<orgId>.ingest.sentry.io/<projectId>.

A DSN (Data Source Name) is the per-project key the SDK uses to send events — it identifies the project but is not a secret credential (micropyramid.com). Treat it like an API endpoint address, not a password.

Where Should You Put Your DSN?

Put your DSN in an environment variable — SENTRY_DSN — and read it from process.env in your init code.

Yes, the DSN is technically a public key, not a secret. The reason to use an environment variable anyway is practical, not paranoid: it keeps per-environment config (dev versus staging versus production projects) out of your source tree, and it means a public repo never hard-codes which Sentry project receives your events. While you are at it, keep real secrets and user data out of the event payload — Sentry's SDKs filter keys matching a built-in denylist like auth or password and send [Filtered] instead, and user identity collection can be disabled entirely (docs.sentry.io).

How Do You Install and Initialize the Sentry SDK?

Initialize the SDK as early as possible in your application's lifecycle — before your app code runs — so nothing throws before Sentry is watching.

Install the package:

npm install @sentry/node --save

Create a file called instrument.js in your project root, exactly as the current official Express guide teaches (docs.sentry.io):

const Sentry = require("@sentry/node");

Sentry.init({
  dsn: process.env.SENTRY_DSN,
});

Then load it before anything else in your app:

// server.js — this require MUST come first
require("./instrument");

// Now require everything else
const express = require("express");
const app = express();
// ... routes ...
app.listen(3000);

Alternatively, load it with a Node flag: node --import ./instrument.js app.js (sentry.io/for/node/). Two things to know: the current guide requires Node >=20.19.0 <22.0.0 || >=22.12.0 <23.0.0 || >=23.2.0, and the expressIntegration the SDK sets up captures errors from your routes and middleware automatically — you do not register a Sentry error handler yourself. Errors with 3xx or 4xx status codes are skipped, since redirects and client errors are usually expected; pass a shouldHandleError callback to expressIntegration() to change which errors get captured (docs.sentry.io).

How Do You Trigger Your First Real Error?

Throw one on purpose — a deliberate crash is the fastest way to confirm the whole pipeline works. Every Sentry tutorial worth reading includes this step, because an untested pipeline is just hope.

Add a temporary route to your Express app:

app.get("/debug-sentry", function (req, res) {
  throw new Error("My first Sentry error!");
});

Restart the app, visit http://localhost:3000/debug-sentry in your browser (or hit it with that REST API tester), then open your Sentry project and click Issues. Within seconds you should see one issue titled "Error: My first Sentry error!" — click it and you will see the stack trace pointing at the exact line you threw from. Delete the debug route once you have confirmed it works.

How Do You Capture Errors Manually?

The Sentry capture exception API is your manual safety net: use Sentry.captureException() for errors you catch but still want reported — the SDK handles the uncaught ones on its own.

import * as Sentry from "@sentry/node";

try {
  aFunctionThatMightFail();
} catch (e) {
  Sentry.captureException(e);
}

Pass an Error object whenever you can — strings and non-Error values are captured too, but the resulting events may be missing a stack trace (docs.sentry.io). For things that are not errors at all, use Sentry.captureMessage() with an explicit severity level:

Sentry.captureMessage("Payment webhook retried 3 times", "warning");
// levels: "fatal" | "error" | "warning" | "log" | "debug" | "info"

Messages show up in your issue stream with the message as the issue name — handy for deploy markers and "this should not happen but did not crash" situations.

How Do You Read a Sentry Issue?

Read an issue top to bottom: title and count first, then the stack trace, then breadcrumbs, then tags.

The title is the fingerprint summary — "Error: Cannot read properties of undefined (reading 'email')" with a count of events and affected users next to it. The stack trace shows each frame of the call path; click the top in-app frame to see the exact line and the surrounding code. Breadcrumbs are the trail of what happened just before the crash — console logs, HTTP requests, navigation clicks — buffered until the next event is sent. Tags slice the issue by browser, operating system, release, and environment, which is how you discover that a bug only happens on one browser or one deploy.

If your stack trace shows minified gibberish or "source unknown" frames, that is a source-map problem, not a Sentry problem — fixed in the source maps section below.

How Do You Triage Issues Without Drowning?

Triage is a daily five-minute habit: scan new issues, resolve the real ones, and silence the noise with rules instead of willpower.

A healthy triage loop looks like this. Every morning, open the Issues stream and sort by "new". For each issue, decide one of three things: resolve it (fixed in code or a duplicate), assign it to whoever owns that area, or archive it with an ignore rule if it is third-party noise (ad blockers breaking your analytics script is the classic). When a resolved issue crashes again, Sentry reopens it automatically as a regression — that is your safety net for fixes that did not stick.

Make triage a team sport the moment a second person joins: one user on the free Developer plan is fine solo, but the moment a co-founder or freelancer needs to see bugs, you are looking at the $26/month Team plan (medium.com, pricing checked Oct 27, 2026).

How Do You Set Up Alerts That Don't Spam You?

Start with exactly one alert rule — "a new issue is created" — and only add more rules when you can name the specific pain each one prevents.

In your project, go to Alerts, then Create Alert Rule — Sentry alerts are configured per project, not globally. The beginner setup that does not spam: trigger on "An issue is created" (not "every event" — that is the inbox killer), notify by email, and filter to your production environment so staging experiments never page you. Four rules that cover most small apps as they grow:

Two tuning knobs matter most. Rate limits cap how many events one noisy issue can send, and ignore rules (Project Settings, then Inbound Filters) drop known noise — browser-extension errors, localhost traffic, and legacy-browser quirks — before they ever become issues. The goal is an inbox where every alert means "a human should look at this today." (Alert concepts per docs.sentry.io; free-plan email alerts confirmed by apicostcalc.com, verified 2026-10-16.)

How Do Releases Tell You Which Deploy Broke Things?

Set the release option in Sentry.init() to your app's version, and Sentry tags every event with it — so when errors spike, you can see they all started with [email protected] and suspect the deploy, not the code in general. That is what Sentry releases are for: tying every event to the exact deploy that produced it.

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  release: "my-app@" + process.env.npm_package_version,
});

Hard-coding a version string works for a tutorial; in real life, set the release from your CI environment so every deploy tags itself automatically. If your code lives on GitHub, the GitHub beginner guide covers the repo and workflow basics you will build the release-tagging step on top of. With releases wired up, Sentry's "suspect commits" can even point at the specific commit range where an issue first appeared.

How Do You Fix "Source Unknown" Stack Traces?

Sentry source maps are the fix for unreadable production stack traces: upload them so minified code maps back to the original files and line numbers.

The official way is one command, run as part of your build (docs.sentry.io):

npx @sentry/wizard@latest -i sourcemaps

The wizard detects your build setup and configures source-map upload for you. Run it before your first production deploy, and confirm it runs again on every build — a stale source map is worse than none, because it maps errors to the wrong lines. This is also the step where a CI pipeline earns its keep: uploads happen automatically on every release instead of whenever someone remembers.

How Much Does Sentry Cost in 2026?

Nothing, for one developer — and the paid jump is small until your error volume says otherwise.

The Developer plan is $0 for one user: 5,000 errors a month, a 30-day data lookback, 50 session replays, email alerts, and 10 custom dashboards (medium.com, pricing checked Oct 27, 2026; apicostcalc.com, verified 2026-10-16). The Team plan starts at $26/month billed annually ($29 month-to-month) with 50,000 errors included and unlimited seats; Business is $80/month billed annually ($89 monthly) with the same 50K errors plus SSO and longer retention (kurums.com, reviewed Sep 30, 2026). Sentry's AI debugging agent, Seer, is a separate add-on at $40 per active contributor per month (tech-insider.org).

If you would rather run it yourself, the official getsentry/self-hosted stack deploys with Docker Compose — 53 services (28 with the errors-only profile), asking for at least 4 CPU cores, 16 GB of RAM plus 16 GB of swap, and 20 GB of disk (dev.to, tested 2026-10-20). That is a real server, not a laptop project — our VPS hosting guide explains the kind of machine it needs, and the Docker beginner guide covers the Compose skills the install assumes. One licensing note: self-hosted Sentry is source-available under the Functional Source License, not open source — internal use is allowed, selling it as a competing service is not.

Sentry vs LogRocket: Which One Do You Actually Need?

Choose by the question you are asking: Sentry answers "what broke and where," LogRocket answers "what was the user doing when it broke."

Sentry is error-first — stack traces, grouping, releases, and alerts, with session replay as an add-on. LogRocket is replay-first — pixel-perfect session reconstruction with console logs, network payloads, and Redux actions attached, built to show you the user's experience around a bug. On price, LogRocket's free plan covers 1,000 sessions a month with one month of retention, and paid plans start at $69/month (g2.com, pricing provided by LogRocket; betterstack.com). Many teams run both: Sentry catches the crash and pages you, LogRocket's replay shows you what the user clicked into. If you can only pick one as a beginner, pick the one matching your biggest pain — mysterious crashes means Sentry, confused users means LogRocket.

Should You Use Sentry for JavaScript Frontends Too?

Yes — the Sentry JavaScript SDK for browsers uses the same init pattern, and it adds replay and user feedback on top.

import * as Sentry from "@sentry/browser";

Sentry.init({
  dsn: "https://[email protected]/0",
  release: "[email protected]",
  integrations: [
    Sentry.browserTracingIntegration(),
    Sentry.replayIntegration(),
    Sentry.feedbackIntegration({
      // user feedback widget config
    }),
  ],
});

Error monitoring starts working as soon as you call Sentry.init() (docs.sentry.io). Keep the frontend and backend in separate Sentry projects with separate DSNs — they have different release cadences, different noise profiles, and mixing them makes triage harder. If you are still setting up your editor, our VS Code beginner guide is a solid starting point.

Sources

• Sentry official Express guide — SDK install, instrument.js init pattern, Node version floor, expressIntegration auto-capture and shouldHandleError (docs.sentry.io, crawled Oct 30, 2026)
• Sentry official Express usage docs — captureException, captureMessage, severity levels, breadcrumbs (docs.sentry.io, crawled Oct 30, 2026)
• Sentry official Browser JavaScript guide — @sentry/browser init, tracing/replay/feedback integrations (docs.sentry.io, crawled Oct 29, 2026)
• Sentry Node.js product page — node --import ./instrument.js, require-first ordering (sentry.io/for/node/, crawled Oct 30, 2026)
• Sentry SDK privacy docs — built-in denylist filters auth/password keys to [Filtered] (docs.sentry.io, crawled Oct 29, 2026)
• apicostcalc.com Sentry pricing reference — Developer and Team tiers, verified against the official pricing page Oct 16, 2026
• Medium "Free Error Tracking Tools for a New SaaS (2026)" — Developer plan numbers checked on the pricing page Oct 27, 2026
• kurums.com error-tracking comparison — Developer, Team, and Business rows reviewed Sep 30, 2026
• tech-insider.org Sentry vs Bugsnag vs Rollbar 2026 — Seer $40/active contributor pricing
• G2 LogRocket pricing — free 1,000 sessions/month, Team from $69/month, pricing provided by LogRocket
• dev.to build-vs-buy exception monitoring — @sentry/node 11.8.0, self-hosted 53 compose services, 4 CPU / 16 GB RAM + 16 GB swap, FSL license (tested Oct 20, 2026)
• micropyramid.com Sentry setup guide — DSN as a per-project key (not a secret), keep traces_sample_rate low in production

Frequently Asked Questions

Is Sentry free?

Yes — the Developer plan is $0 forever for one user, with 5,000 errors a month, a 30-day lookback, 50 session replays, and email alerts. You only pay when a second person needs access (Team from $26/month billed annually) or your error volume outgrows the free quota.

Is the Sentry DSN a secret?

No. The DSN is a public key that tells the SDK which project to send events to — it identifies, not authenticates. Still, keep it in an environment variable rather than hard-coding it, so dev and production projects stay separate and your repo stays clean.

How is Sentry different from application logs?

Logs record lines; Sentry builds issues. A thousand identical crashes become one issue with a count, a stack trace, breadcrumbs of what led up to it, and the release that introduced it — plus an alert when something new appears. Logs tell you what happened; Sentry tells you what to fix first.

Do I still need an Express error handler with Sentry?

No. The SDK's expressIntegration captures errors from your routes and middleware automatically — you do not register a Sentry error handler. Use the shouldHandleError callback only when you want to capture or skip specific errors.

Will Sentry slow down my app?

Not noticeably. The SDK sends events asynchronously, so your request handling never waits on Sentry. In production, keep performance tracing sampled low (a fraction of transactions, not all of them) so the overhead stays flat as traffic grows.