error-tracking-setup

Overview

Error tracking turns "users are seeing something broken" into actionable reports: what failed, where, how often, and for whom. The setup is similar across platforms (Sentry, Rollbar, Bugsnag, and similar): install an SDK, capture unhandled errors with context, and configure grouping and alerts. This skill covers doing it well, vendor-neutrally.

When to use

• Adding error tracking to a new application (frontend, backend, mobile)
• Deciding what context to attach to error reports (user, release, breadcrumbs)
• Taming noisy error groups and alert fatigue
• Handling source maps for minified JavaScript
• Setting up error tracking across environments (dev/staging/prod)

Core concepts

Capture unhandled errors automatically, handled ones deliberately. SDKs hook uncaught exceptions and unhandled rejections out of the box. For caught errors that still matter (failed payments, degraded fallbacks), capture explicitly with severity levels — but don't log-and-capture everything; noise drowns signal.

Context is what makes errors actionable. Attach: release/version (which deploy introduced it?), environment, user/request identifiers (not PII-heavy — IDs, not names), and breadcrumbs (the last N actions before the crash: navigation, API calls, clicks). An error with "user X, release 1.2.3, after 3 failed API retries" is debuggable; a bare stack trace often isn't.

Grouping determines your workload. Platforms group identical errors by stack trace fingerprint. Bad grouping (one group per URL parameter) floods you; over-grouping hides distinct bugs. Tune grouping rules: strip volatile values (IDs, timestamps) from fingerprints, split genuinely different failures.

Source maps for frontend. Minified production JS produces useless stack traces without source maps. Upload them at build time (CI step), keep them out of public bundles (upload privately, don't serve .map files), and verify with a test error that traces resolve to real code.

Sampling and quotas. High-traffic apps can't send every error; sample intelligently (100% of new/critical, sampled repeats) and set per-issue rate limits. Monitor ingestion volume — error-tracking bills scale with events, and a logging loop can bankrupt the quota overnight.

Practical workflow

1. Install the SDK per platform docs for each runtime (browser, Node, Python, mobile); initialize early in the boot sequence with DSN/key, environment, and release set from CI.
2. Configure context: user identification (stable ID), release tracking (git SHA per deploy), breadcrumbs (navigation, HTTP, console — automatic in most SDKs), and custom tags for segmentation (tenant, plan, region).
3. Set up source maps (frontend) or debug symbols (native) in the build pipeline; verify symbolication with a deliberate test error in staging.
4. Tune ingestion: environment filtering (don't send dev noise to prod projects), beforeSend hooks to scrub PII and drop known noise (browser-extension errors, bot traffic), and rate limits per issue.
5. Wire alerts: new-issue alerts to the owning team, regression alerts (resolved issue reappears), and spike alerts — routed by team ownership, not to one global channel.
6. Establish the triage habit: daily/weekly review of new issues (see issue-triage); unresolved error debt compounds exactly like tech debt.

Common pitfalls

• No release tracking — can't tell which deploy introduced the error; always set the release at build time.
• PII in error payloads — passwords, tokens, full request bodies in reports; scrub in beforeSend and audit what gets sent.
• Alerting on every error — pages for one-off blips; alert on new issues, regressions, and spikes, not raw counts.
• Ignoring frontend errors — backend-only tracking misses the errors users actually see; instrument the client too.
• Source maps missing or stale — minified traces nobody can read; automate upload in CI and verify.
• Letting the backlog rot — 500 open issues nobody triages; the tool becomes write-only. Triage regularly or stop paying for it.