Error Tracking: Best Practices

Overview

Application error tracking captures runtime exceptions, correlates them with a specific release and environment, and routes actionable alerts to the right person before users report the problem. Sentry is the reference implementation; Datadog APM, Rollbar, and Honeybadger cover the same surface.

Initialize the SDK with DSN, environment, and sample rate

Set dsn, environment, and tracesSampleRate at startup. The DSN is the only required field; omitting environment makes every environment’s errors appear in the same stream, which makes triage harder (Sentry JS options).

// src/instrument.ts  (import before all app code)
import * as Sentry from "@sentry/node";
 
Sentry.init({
  dsn: process.env.SENTRY_DSN,          // never hardcode
  environment: process.env.NODE_ENV,    // "production" | "staging" | "development"
  release: process.env.SENTRY_RELEASE, // e.g. git SHA or semver tag
  tracesSampleRate: process.env.NODE_ENV === "production" ? 0.1 : 1.0,
  sendDefaultPii: false,                // see PII section below
});

Read dsn and release from environment variables, not source. Store them as secrets-and-env secrets in CI. See ci-cd for injecting SENTRY_RELEASE at build time.

Upload source maps so production stack traces are readable

Minified production bundles produce unreadable stack traces. Source maps map minified positions back to original source lines. Without them, error titles like o is not a function at bundle.min.js:1:34291 are nearly useless.

Use the bundler plugin that matches your toolchain. Sentry recommends bundler plugins over manual sentry-cli upload for webpack, Vite, Rollup, and esbuild (source maps docs).

// vite.config.ts
import { sentryVitePlugin } from "@sentry/vite-plugin";
 
export default {
  build: { sourcemap: true },
  plugins: [
    sentryVitePlugin({
      org: process.env.SENTRY_ORG,
      project: process.env.SENTRY_PROJECT,
      authToken: process.env.SENTRY_AUTH_TOKEN,
    }),
  ],
};

For CI pipelines without a bundler plugin, use sentry-cli:

sentry-cli sourcemaps upload --org $SENTRY_ORG --project $SENTRY_PROJECT ./dist

Set devtool: "hidden-source-map" in webpack (or equivalent) so maps are uploaded to Sentry but not served publicly. Serving .map files exposes your original source to anyone who requests them.

Tag every error with a release and associate commits

A release ties errors to a specific deploy, enabling regression detection (“this error first appeared in v2.4.1”) and suspect-commit identification (Sentry releases).

# In your deploy pipeline, after pushing the build artifact:
sentry-cli releases new $SENTRY_RELEASE
sentry-cli releases set-commits --auto $SENTRY_RELEASE
sentry-cli releases finalize $SENTRY_RELEASE
sentry-cli releases deploys $SENTRY_RELEASE new -e production

The --auto flag reads your local git tree and associates commits between the previous release head and the current HEAD. Integrate this into the same ci-cd step that deploys the app so the release record always matches what is live.

Separate environments to control noise

Route development, staging, and production errors to separate Sentry environments using the environment init option. Apply inbound filters per environment:

• Development: mute or disable the DSN entirely. Local crashes are not actionable by the team.
• Staging: capture all errors, alert only on-call or a Slack channel that the team monitors casually.
• Production: full capture, strict alert routing, page for P1 issues.

Mixing environments inflates error counts and trains the team to ignore alerts, which is the primary failure mode of error tracking programs.

Scrub PII before the event leaves the process

Set sendDefaultPii: false (the SDK default) to prevent automatic inclusion of IP addresses and cookies (Sentry sensitive data). Use beforeSend to strip any PII that appears in custom context, breadcrumbs, or request bodies:

Sentry.init({
  // ...
  sendDefaultPii: false,
  beforeSend(event) {
    // Strip Authorization header if accidentally captured
    if (event.request?.headers) {
      delete event.request.headers["Authorization"];
      delete event.request.headers["Cookie"];
    }
    // Redact email from user context
    if (event.user?.email) {
      event.user.email = "[redacted]";
    }
    return event;
  },
});

Returning null from beforeSend drops the event entirely. Use this to discard known-safe noise (e.g., bot traffic errors, expected 404s) rather than creating alert rules that still ingest the data.

Set sample rates to control cost and volume

High-traffic services can exhaust quotas or produce alert fatigue if every error is sent. Two levers control volume:

• tracesSampleRate: fraction of transactions sent for performance tracing. Start at 0.1 in production, raise if you need finer trace data.
• sampleRate (error sampling): fraction of error events captured. Set to 1.0 unless event volume is genuinely unmanageable; errors are lower frequency than traces.

Prefer tracesSampler over tracesSampleRate when you need per-route control (e.g., health-check endpoints at 0, checkout flows at 1.0).

Route alerts with sensible thresholds

Alerts that fire on every single error produce no signal. Configure Sentry alert rules to trigger on:

• New issue (first occurrence of a previously unseen error): notify immediately.
• Regression (an issue that was resolved has reappeared): notify immediately.
• Volume spike: more than N events in M minutes on a single issue.

Route production P1 alerts to your incident-response oncall rotation. Route staging alerts to a Slack channel. Route development alerts nowhere. Use webhooks or Sentry’s native Slack/PagerDuty integrations for delivery. Avoid email-only routing; alerts that go to an inbox get batched and ignored.

Related

• llm-observability for tracking LLM-specific errors and trace quality separately from app errors
• observability for structured logging and metrics that complement error events
• ci-cd for injecting SENTRY_RELEASE and running sentry-cli steps in deploy pipelines
• incident-response for escalation paths when error alerts fire in production
• secrets-and-env for managing DSN and auth tokens safely
• webhooks for wiring Sentry alert webhooks to notification targets
• pre-launch-checklist for verifying error tracking is wired before going live