How to Set Up Sentry for Error Tracking in a Node.js Production App

Why Sentry Node.js Error Tracking Matters in Production

When a Node.js app crashes at 3 AM, your logs alone rarely tell the full story. Sentry Node.js error tracking gives you real-time stack traces, user context, breadcrumbs, and performance insights so you can fix bugs before your users complain on Twitter.

In this hands-on tutorial, we at Coding4 will walk you through installing, configuring, and using Sentry in a real Node.js production application. Unlike other guides, we will also cover the things that actually bite you in production: source map uploads, smart alerting, and filtering noisy errors so your inbox stays sane. namastedev.com has a solid rundown on this.

What You Will Build

• A Node.js (Express) app instrumented with the latest Sentry SDK
• Automatic error and unhandled rejection capture
• Performance monitoring with distributed tracing
• Source maps uploaded on every deploy
• Alert rules that only ping you when it truly matters
• Filters to ignore known noise (bots, health checks, ECONNRESET, etc.)

Step 1: Create a Sentry Project

1. Sign in at sentry.io and create a new project.
2. Select Node.js as the platform (or Express if that fits better).
3. Copy the generated DSN. You will need it in a moment.

Step 2: Install the Sentry SDK

For any modern Node.js project (Node 18+ recommended in 2026), install the official SDK:

npm install @sentry/node @sentry/profiling-node

If you use TypeScript, no extra types package is needed. Sentry ships them out of the box.

Step 3: Initialize Sentry as Early as Possible

Create a dedicated instrument.js (or instrument.ts) file. It must be imported before any other module so Sentry can auto-instrument your dependencies.

// instrument.js
const Sentry = require('@sentry/node');
const { nodeProfilingIntegration } = require('@sentry/profiling-node');

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV || 'development',
  release: process.env.APP_RELEASE, // e.g. '[email protected]'
  integrations: [nodeProfilingIntegration()],
  tracesSampleRate: 0.2,        // 20% of transactions
  profilesSampleRate: 0.2,      // 20% of sampled transactions
  sendDefaultPii: false
});

Then in your entry file:

// server.js
require('./instrument');
const express = require('express');
const Sentry = require('@sentry/node');

const app = express();

app.get('/', (req, res) => res.send('Hello'));

app.get('/boom', () => {
  throw new Error('Test error from Coding4');
});

// The Sentry error handler must be registered before any other error middleware
Sentry.setupExpressErrorHandler(app);

app.use((err, req, res, next) => {
  res.statusCode = 500;
  res.end('Internal Server Error');
});

app.listen(3000);

Hit /boom once. You should see the error appear in your Sentry dashboard within seconds. This guide goes deeper on it.

Step 4: Capture Unhandled Rejections and Manual Errors

The SDK already hooks uncaughtException and unhandledRejection. For business logic errors you want to capture manually, use:

try {
  await chargeCustomer(order);
} catch (err) {
  Sentry.captureException(err, {
    tags: { module: 'billing' },
    extra: { orderId: order.id }
  });
  throw err;
}

Step 5: Upload Source Maps on Every Deploy

Without source maps, minified or transpiled stack traces are useless. The recommended way in 2026 is the Sentry Wizard:

npx @sentry/wizard@latest -i sourcemaps

It will:

• Create a .sentryclirc or environment variable setup
• Add build scripts using @sentry/cli
• Inject Debug IDs so source maps match no matter the release name

Add these environment variables to your CI/CD:

Variable	Purpose
SENTRY_AUTH_TOKEN	Auth token with project:releases scope
SENTRY_ORG	Your Sentry org slug
SENTRY_PROJECT	Project slug
APP_RELEASE	Unique release identifier, e.g. git SHA

In your CI pipeline, after a successful build:

npx sentry-cli sourcemaps inject ./dist
npx sentry-cli sourcemaps upload --release=$APP_RELEASE ./dist

Step 6: Filter the Noise

Nothing kills adoption faster than a dashboard full of junk. Here are filters we apply on almost every Coding4 project:

Sentry.init({
  // ...
  ignoreErrors: [
    'ECONNRESET',
    'ETIMEDOUT',
    'Non-Error promise rejection captured'
  ],
  beforeSend(event, hint) {
    const err = hint.originalException;

    // Drop 404s and health check noise
    if (event.request?.url?.includes('/health')) return null;
    if (err && err.status === 404) return null;

    // Drop known bot user agents
    const ua = event.request?.headers?.['user-agent'] || '';
    if (/bot|crawler|spider/i.test(ua)) return null;

    return event;
  }
});

Sampling Strategy

For high-traffic services, sample smartly instead of dropping data blindly:

tracesSampler: (ctx) => {
  if (ctx.request?.url?.includes('/health')) return 0;
  if (ctx.request?.url?.includes('/checkout')) return 1.0; // critical
  return 0.1;
}

Step 7: Configure Alerts That Actually Wake You Up

In the Sentry UI, go to Alerts > Create Alert. We recommend the following baseline rules:

1. New issue in production – notify Slack channel #alerts
2. Issue affects more than 50 users in 1 hour – page on-call via PagerDuty or Opsgenie
3. Regression detected – notify the author of the last release
4. Performance: p95 latency > 2s for 5 minutes on critical endpoints

Tie each alert to an environment tag (production only) to prevent staging noise.

Step 8: Add Rich Context

Context is what turns a stack trace into a fix. Add user and request context in your middleware:

app.use((req, res, next) => {
  Sentry.setUser({
    id: req.user?.id,
    email: req.user?.email
  });
  Sentry.setTag('tenant', req.tenantId);
  next();
});

Coding4 vs Basic Setup: What You Gain

Feature	Default Install	Coding4 Production Setup
Error capture	Yes	Yes + rich context
Source maps	Manual	Automated via CI with Debug IDs
Noise filtering	None	ignoreErrors + beforeSend + tracesSampler
Alerts	Email everything	Tiered alerts by severity and environment
Performance	Off	Distributed tracing + profiling

Common Pitfalls to Avoid

• Initializing Sentry too late: it must load before Express, HTTP, and any DB driver.
• Missing release tag: without it, source maps will not resolve.
• 100% sampling in production: expensive and often useless. Sample smartly.
• Sending PII by accident: keep sendDefaultPii: false unless you truly need it and you are compliant.
• Not scrubbing secrets: use beforeSend to strip tokens from URLs and headers.

FAQ

Is Sentry free for Node.js?

Yes, Sentry offers a free Developer plan with a monthly event quota. It is enough to get started and to instrument small services. Larger production workloads usually move to the Team or Business plan. For a real-world example, look at one agency that does this well.

Does Sentry slow down my Node.js app?

The overhead is minimal for error capture. Performance tracing and profiling add some cost, which is why you should use tracesSampleRate and profilesSampleRate instead of capturing 100% of traffic.

How is Sentry different from a logging tool like Winston or Pino?

Logs are streams of text. Sentry aggregates errors into issues, deduplicates them, tracks regressions across releases, and attaches breadcrumbs, source maps, and user context. Both are complementary.

Can I self-host Sentry?

Yes, Sentry provides a self-hosted Docker distribution. It requires more maintenance but keeps all data on your infrastructure. Recommended only if you have strict compliance requirements.

How do I test that Sentry works?

Add a temporary route like /debug-sentry that throws an error, hit it once, and confirm the issue appears in your dashboard. Remove it before shipping to production. This write-up is worth a look.

Wrapping Up

With this setup, your Node.js app is now equipped with production-grade Sentry error tracking: rich context, clean signal to noise ratio, working source maps, and alerts that respect your sleep. If you need help rolling this out across a fleet of microservices or integrating Sentry into your CI/CD, the team at Coding4 is one message away.