Sentry in a Node.js application gives you real-time error and performance monitoring in a few lines of code, but configuring it securely is the part that matters, because error reports can carry passwords, tokens, and personal data off your server if you let them. This guide covers a clean Sentry Node setup and, more importantly, how to keep sensitive data out of what you send.
What Sentry does for a Node app
Sentry captures unhandled exceptions and rejected promises, groups them into issues, and attaches context: the stack trace, the request that triggered it, the release version, and breadcrumbs of what happened before the error. Instead of grepping through logs after a user complains, you get an alert with the failing line and the state around it. For a Node service under real traffic, that is the difference between fixing a bug in minutes and hunting it for hours.
The performance side traces slow requests and database calls so you can see where latency accumulates. Both share the same SDK.
A minimal, correct setup
The modern SDK initializes early, before the rest of your application loads, so it can instrument everything. Install @sentry/node and initialize it at the very top of your entry point:
// instrument.js - imported first, before anything else
const Sentry = require("@sentry/node");
Sentry.init({
dsn: process.env.SENTRY_DSN,
environment: process.env.NODE_ENV,
tracesSampleRate: 0.1, // sample 10% of transactions
});
// index.js
require("./instrument");
const express = require("express");
const app = express();
// ... your routes ...
Sentry.setupExpressErrorHandler(app);
Two things worth noting. The DSN comes from an environment variable, never hardcoded, and tracesSampleRate is well below 1.0 in production so you are not paying to trace every single request. Sampling at 100% is a common and expensive mistake.
The security part: scrub before you send
This is where most integrations go wrong. By default an error report can include request bodies, headers, and local variables, and any of those can contain a password, an API key, a session cookie, or personal data. Sending that to a third-party service is a data-exposure problem and potentially a compliance violation.
Sentry provides a beforeSend hook that runs on every event before it leaves your process. Use it to strip anything sensitive:
Sentry.init({
dsn: process.env.SENTRY_DSN,
sendDefaultPii: false, // do not attach IP, cookies, user data by default
beforeSend(event) {
// Remove auth headers if present
if (event.request?.headers) {
delete event.request.headers["authorization"];
delete event.request.headers["cookie"];
}
// Redact obvious secrets from the request body
if (event.request?.data) {
for (const key of ["password", "token", "apiKey", "ssn"]) {
if (key in event.request.data) event.request.data[key] = "[redacted]";
}
}
return event;
},
});
Set sendDefaultPii: false so the SDK does not automatically attach IP addresses, cookies, and user identifiers. Turn on only the context you actually need, and redact the rest. Sentry also supports server-side data scrubbing rules, so treat beforeSend and the server rules as belt-and-suspenders.
Do not report what you can handle
Not every thrown error deserves an alert. Validation failures, expected 404s, and client-side aborts are noise that buries the errors you care about. Filter them out in beforeSend (return null to drop an event) or handle them before they propagate. A signal-to-noise problem in your monitoring is itself a security risk, because real incidents get lost in the flood.
Keep the SDK and its dependencies patched
The Sentry SDK is itself a dependency, and it pulls in a transitive tree of its own. Like any package, it can have vulnerabilities, and running an outdated version means missing fixes. This is the routine hygiene that applies to every dependency in a Node project: pin versions in your lockfile, and monitor them continuously. An SCA tool will flag when the SDK or anything beneath it has a published advisory, including transitive packages you never installed directly. If you are formalizing this practice across a team, the Safeguard Academy covers dependency hygiene end to end.
Wire it into your release process
Sentry becomes far more useful when it knows about your releases. Tag each deploy with a release identifier and upload source maps if you transpile, so a stack trace points to your original source instead of minified output:
Sentry.init({
dsn: process.env.SENTRY_DSN,
release: process.env.GIT_COMMIT_SHA,
});
With releases tagged, Sentry can tell you an error started appearing right after a specific deploy, which turns "something broke" into "this commit broke it."
FAQ
How do I stop Sentry from leaking sensitive data in Node?
Set sendDefaultPii: false and use the beforeSend hook to delete auth headers and cookies and redact secret fields from request bodies before the event is sent. Combine that with Sentry's server-side scrubbing rules for defense in depth.
Where should I put the Sentry DSN?
In an environment variable, read as process.env.SENTRY_DSN, never hardcoded in source. While the DSN is not a high-value secret, keeping it in config keeps it out of version control and lets you vary it per environment.
Why is my traces sample rate important?
tracesSampleRate controls what fraction of requests are traced for performance. Setting it to 1.0 in production traces everything, which is expensive and usually unnecessary. A value like 0.1 samples enough to spot trends without the cost.
Do I need to scan the Sentry SDK for vulnerabilities?
Yes. The SDK is a dependency with its own transitive tree, and it can carry vulnerabilities like any package. Pin it in your lockfile and monitor it with an SCA scanner so you catch published advisories, including in transitive dependencies.