Error Tracking Guide: Tools, Best Practices & Setup (2026)

Every production application throws errors. The question is whether you find out before your users do — or after they've already left. Error tracking closes that gap by automatically capturing exceptions, grouping them by root cause, and alerting your team in real time.

This guide covers everything you need to set up effective error tracking: how it works, which tools to use, how to configure alerting without noise, and how to connect error data to your SLOs.

What Is Error Tracking?

Error tracking (also called exception monitoring or crash reporting) is the practice of automatically capturing runtime errors in your application and centralizing them for triage. When your code throws an unhandled exception, the error tracking SDK intercepts it, enriches it with context (stack trace, request headers, user ID, environment), and sends it to a central platform.

Unlike raw logging, error trackers:

• Group similar errors — 10,000 occurrences of the same NullPointerException appear as one issue, not 10,000 log lines
• Track first and last seen — you know when an error started and whether it's getting worse
• Alert on new errors — you're notified the first time a previously-unseen exception appears in production
• Link errors to deploys — see exactly which release introduced a new error
• Capture breadcrumbs — the sequence of events (API calls, UI interactions, console logs) leading up to the crash

Error Tracking vs. Logging vs. APM

The most effective observability stacks use all four layers together. Error tracking and uptime monitoring are the minimum viable combination for any production application.

Error Tracking Tool Comparison (2026)

Sentry

Sentry is the de facto standard for error tracking. With SDKs for 100+ platforms (JavaScript, Python, Go, Rust, Ruby, Java, iOS, Android, and more), it's the most universally applicable option. Sentry's performance monitoring feature bridges the gap between error tracking and APM by capturing transaction traces alongside errors.

• Free tier: 5,000 errors/month, 10K performance units
• Paid: $26/month (Team), $80/month (Business)
• Self-hosted: Yes (open-source, Docker-based)
• Best for: Teams of all sizes, especially JavaScript/Python heavy stacks

Rollbar

Rollbar differentiates with its deploy tracking and flexible error grouping rules. You can write custom fingerprinting logic to group errors exactly as your team expects. Rollbar also integrates deeply with GitHub, GitLab, and Jira for linking errors to commits and issues.

• Free tier: 5,000 occurrences/month
• Paid: $12/month (Essentials), $55/month (Advanced)
• Best for: Teams doing frequent deploys who need error attribution to releases

Bugsnag

Bugsnag is the top choice for mobile-first teams. Its iOS and Android SDKs are best-in-class, with support for native crashes, ANRs (Application Not Responding), and battery/memory impact tracking. The stability score metric — percentage of sessions without errors — is a useful product health KPI.

• Free trial: 14 days
• Paid: $47/month (Starter), custom for Enterprise
• Best for: Mobile apps, or teams wanting stability-score reporting

Datadog Error Tracking

If you're already in the Datadog ecosystem, their error tracking feature integrates directly with APM traces, logs, and dashboards. You get correlation across all signals — an error can link directly to the slow DB query that caused a timeout, for example. It's expensive standalone but free if you're paying for APM.

• Cost: Included with APM ($31+/host/month)
• Best for: Existing Datadog customers

Glitchtip (Open Source)

Glitchtip is a Sentry-compatible open-source alternative. It accepts Sentry SDK events (so migration is zero-code), provides the same error grouping and alerting, and can be self-hosted for free. Trade-off: fewer integrations, slower feature development, and you own the ops burden.

• Cost: Free (self-hosted) or $9/month (cloud)
• Best for: Budget-conscious teams or those with data residency requirements

Setting Up Error Tracking: A Practical Example

JavaScript / Node.js (Sentry)

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

// sentry.ts — initialize before any other imports
import * as Sentry from '@sentry/node';
import { nodeProfilingIntegration } from '@sentry/profiling-node';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  release: process.env.GIT_SHA,           // links errors to commits
  integrations: [nodeProfilingIntegration()],
  tracesSampleRate: process.env.NODE_ENV === 'production' ? 0.1 : 1.0,
  profilesSampleRate: 0.1,
  beforeSend(event) {
    // Filter known bot errors before they count against your quota
    if (event.request?.url?.includes('/healthcheck')) return null;
    return event;
  },
});

Python (Sentry)

pip install sentry-sdk

import sentry_sdk
from sentry_sdk.integrations.django import DjangoIntegration
from sentry_sdk.integrations.redis import RedisIntegration

sentry_sdk.init(
    dsn=os.environ["SENTRY_DSN"],
    integrations=[
        DjangoIntegration(transaction_style="url"),
        RedisIntegration(),
    ],
    traces_sample_rate=0.1,
    send_default_pii=False,  # GDPR compliance
    environment=os.environ.get("ENVIRONMENT", "production"),
    release=os.environ.get("GIT_SHA"),
)

Go

go get github.com/getsentry/sentry-go

import "github.com/getsentry/sentry-go"

func main() {
    if err := sentry.Init(sentry.ClientOptions{
        Dsn:              os.Getenv("SENTRY_DSN"),
        Environment:      os.Getenv("ENVIRONMENT"),
        Release:          os.Getenv("GIT_SHA"),
        TracesSampleRate: 0.1,
        BeforeSend: func(event *sentry.Event, hint *sentry.EventHint) *sentry.Event {
            // Scrub PII from request bodies
            if event.Request != nil {
                event.Request.Data = "[redacted]"
            }
            return event
        },
    }); err != nil {
        log.Fatalf("sentry.Init: %v", err)
    }
    defer sentry.Flush(2 * time.Second)
}

Error Alert Strategy

Raw error volume is a terrible alert signal. A spike in errors after a deploy is expected during a canary rollout. An error that's been happening for six months at 0.001% rate doesn't need a 3 AM page. Alert on meaningful change, not raw counts.

Alert Types That Actually Work

Reducing Alert Noise

Alert fatigue is the biggest failure mode in error tracking. Teams stop responding to alerts when every deploy triggers a wave of notifications. Strategies to reduce noise:

• Ignore known errors. Third-party scripts that throw on every page load, browser extensions, known bots — mark these as ignored so they don't appear in your issue list.
• Set frequency thresholds. Don't alert on a known flaky error until it crosses 100 occurrences/hour.
• Mute errors during deploys. Automatically suppress alerts for 10 minutes after a new release when some transient errors are expected.
• Route by severity. New errors → Slack channel. High-frequency regressions → PagerDuty. Known intermittent issues → weekly digest only.
• Use ownership rules. Route frontend errors to the frontend team's channel, payments errors to the payments team. Everyone gets what's relevant to them.

Error Context: What to Capture

A stack trace tells you where the error happened. Context tells you why. The richer your context, the faster your triage.

Always Capture

• User ID (not email — helps debug without storing PII in error data)
• Request ID / trace ID — for correlating with logs and APM traces
• Release / git SHA — know exactly which deploy introduced the error
• Environment — staging vs. production errors require different responses
• Request URL and method — which endpoint triggered the error

Be Careful With

• Request bodies — may contain passwords, PII, payment data. Scrub before sending.
• Headers — Authorization headers with tokens should be redacted.
• Local variables — Sentry's local variable capture is powerful but can expose sensitive data. Enable only after reviewing what's in scope.

// Attach context at the request level
app.use((req, res, next) => {
  Sentry.setUser({ id: req.user?.id });
  Sentry.setTag('request_id', req.headers['x-request-id']);
  Sentry.setContext('request', {
    url: req.url,
    method: req.method,
    // DO NOT include: req.body (may contain PII)
  });
  next();
});

// Manual error capture with extra context
try {
  await processPayment(order);
} catch (err) {
  Sentry.withScope((scope) => {
    scope.setTag('payment.provider', 'stripe');
    scope.setContext('order', { id: order.id, amount: order.total });
    Sentry.captureException(err);
  });
  throw err;
}

Connecting Errors to SLOs

Error tracking data becomes strategically valuable when connected to service level objectives. Instead of treating every error as equally important, you measure what fraction of user interactions result in errors and track that against your SLO.

A typical error rate SLO: “99.5% of API requests must return a non-5xx response.” This means your error budget is 0.5% of requests per month — about 3.6 hours of total 100% error rate time, or ~216 minutes of 50% error rate.

Configure error budget burn rate alerts: if you're burning your monthly budget at 14x the normal rate, you'll exhaust it in 2 hours — that's a page-level alert. At 3x the rate, you have 10 days — Slack notification only.

Error Tracking Best Practices

• Treat all new errors as incidents until proven otherwise. Assign an owner, investigate, and either resolve or explicitly ignore with a documented reason.
• Link error trackers to your deployment pipeline. When you deploy, mark a new release in Sentry/Rollbar so you can instantly see if error rates changed post-deploy.
• Set up source maps for frontend errors. Without source maps, JavaScript stack traces are minified and unreadable. Upload source maps as part of your build process.
• Review your ignore list quarterly. Ignored errors accumulate over time. What was noise last year may signal a new attack vector today.
• Run error budget reviews in sprint retros. How much error budget did we burn this sprint? What caused it? What would we do differently?
• Use error tracking in staging, too. Catching errors in staging before they reach production is the highest-leverage use of the tool.

FAQ: Error Tracking

What is error tracking?

Error tracking automatically captures runtime exceptions in your application, groups similar errors by root cause, attaches stack traces and user context, and alerts your team in real time. Unlike logs, error trackers deduplicate and prioritize so you focus on what matters.

Is Sentry free?

Yes — Sentry has a free tier covering 5,000 errors/month and 10,000 performance transactions/month. It's also open-source and self-hostable for free. Paid plans start at $26/month and scale based on event volume and features.

What's the difference between Sentry and Rollbar?

Both are excellent error trackers with similar core features. Sentry has broader SDK support (100+ platforms) and better performance monitoring. Rollbar is slightly cheaper, has better deploy-based error attribution, and offers more flexible custom error grouping rules. For most teams, Sentry is the default choice; Rollbar is worth evaluating if deploy tracking is a priority.

How do I reduce error tracking costs?

Apply sampling to high-volume, well-understood errors (e.g., rate-limit 429s from known scrapers). Filter out known bot traffic in your beforeSend hook. Ignore errors from third-party scripts. Set up error grouping rules to prevent slight variations from creating separate issues. For very high-traffic apps, consider self-hosting Glitchtip or Sentry.