Error Tracking

Every application has bugs. No matter how thorough your testing, some errors will only surface when real users interact with your software in ways you did not anticipate, on devices you did not test, and under conditions you could not replicate in staging. Error tracking is the practice of automatically capturing, grouping, and alerting on these production errors so that your team can find and fix problems before they affect more users.

Without error tracking, you are relying on users to report problems — and most users do not. Studies consistently show that the vast majority of users who encounter an error simply leave without saying a word. An error tracking system ensures that you know about every failure, even the ones your users never mention.

What Error Tracking Tools Do

Error tracking tools integrate with your application to automatically capture exceptions and errors as they occur in production. When an error happens, the tool collects a rich set of contextual information:

• Stack trace: The exact sequence of function calls that led to the error, showing file names, line numbers, and function names.
• Environment data: Browser type and version, operating system, device type, screen resolution, and locale.
• User context: Which user was affected (if authenticated), what page they were on, and what actions they took leading up to the error.
• Breadcrumbs: A timeline of events (clicks, navigation, network requests, console messages) that occurred before the error, helping you reproduce the issue.
• Release information: Which version of your code was running when the error occurred, enabling you to identify regressions introduced by specific deployments.

This context transforms a vague bug report like "the page is broken" into a precise, actionable description of exactly what went wrong and why.

Popular Error Tracking Tools

Several mature tools serve this space, each with different strengths:

• Sentry is the most widely used error tracking platform and is open-source, meaning you can self-host it if you need full control over your data. Sentry supports virtually every programming language and framework. Its free tier is generous enough for small projects, and its grouping and deduplication algorithms are among the best in the industry. Sentry also offers performance monitoring and session replay features.
• Bugsnag focuses on application stability, providing a stability score that quantifies the percentage of sessions that are error-free. It has strong support for mobile platforms (iOS and Android) in addition to web applications. Bugsnag excels at grouping errors by root cause rather than just by stack trace similarity.
• Rollbar provides real-time error monitoring with strong support for continuous deployment workflows. It can automatically link errors to the specific code change that introduced them and create issues in your project management tool. Rollbar supports grouping by custom fingerprints when the default algorithm does not suit your needs.
• Datadog offers error tracking as part of a broader observability platform that includes infrastructure monitoring, APM (Application Performance Monitoring), log management, and more. If your organization already uses Datadog for infrastructure, adding error tracking provides a unified view of your entire stack.

Source Maps: Readable Stack Traces in Production

Modern web applications are built with tools that transform your source code before it reaches the browser. Minification removes whitespace and shortens variable names to reduce file size. Bundlers combine multiple files into one. Transpilers convert TypeScript or modern JavaScript into backward-compatible code. The result is production code that looks nothing like what you wrote.

When an error occurs in minified code, the stack trace might show something like Error at e.t (main.a3f8b2.js:1:4523) — completely unreadable. Source maps solve this problem. A source map is a file that maps positions in the minified code back to the original source code. When you upload source maps to your error tracking tool, it can translate that cryptic stack trace into Error at calculateTotal (checkout.ts:47:12) — showing the original file name, function name, and line number.

To use source maps effectively:

• Generate source maps during your build process (most bundlers like webpack, Vite, and esbuild support this).
• Upload source maps to your error tracking service as part of your CI/CD pipeline, associating them with a release version.
• Do not serve source maps publicly in production — upload them directly to the error tracking tool so that users cannot view your original source code, but your team gets readable stack traces.
• Include the release version in your error tracking SDK configuration so the tool knows which source maps to use for each error.

Grouping and Deduplication

A single bug can generate thousands of individual error events. If every user who visits a broken checkout page triggers the same exception, you do not want thousands of separate alerts — you want one alert that tells you "this error has occurred 3,247 times affecting 1,891 users."

Error tracking tools group related errors into "issues" using algorithms that compare stack traces, error messages, and other attributes. This deduplication is critical for maintaining a manageable list of problems to fix. Most tools allow you to customize grouping rules when the default behavior does not match your needs. For example, if an error message includes a unique ID that changes every time, you might configure the tool to ignore that portion of the message when grouping.

Alert Fatigue and How to Manage It

Alert fatigue is one of the biggest threats to an effective error tracking practice. When your team receives too many alerts, people start ignoring them — and then they miss the critical ones. This is not a theoretical risk; it is one of the most common failure modes in monitoring.

To prevent alert fatigue:

• Set severity levels: Not every error deserves an immediate alert. Classify errors as critical, warning, or informational. Only send real-time notifications (Slack, PagerDuty, email) for critical issues that affect core functionality or a large number of users.
• Configure alert thresholds: Instead of alerting on every new error, set thresholds based on frequency or user impact. "Alert me when this error affects more than 100 users in an hour" is more useful than "alert me on every occurrence."
• Triage regularly: Schedule regular sessions to review and triage open issues. Resolve errors that have been fixed, ignore errors that are expected (such as bots hitting nonexistent endpoints), and assign priorities to the rest.
• Use quiet hours: Configure notification schedules so that non-critical alerts are batched into daily or weekly digests rather than sent in real time.
• Route alerts to the right team: Errors in the payment system should go to the payments team, not the entire engineering organization. Most error tracking tools support routing rules based on error attributes like the affected URL, error type, or tags.

Integration with Issue Trackers

Error tracking tools become significantly more powerful when integrated with your issue tracker. Sentry, Bugsnag, and Rollbar all support two-way integrations with GitHub Issues, Jira, Linear, and other project management tools. When you identify an error that needs a code fix, you can create an issue directly from the error tracking interface, and the issue will link back to the error with all its context. When the linked pull request is merged and deployed, the error can be automatically resolved.

This integration closes the loop between detection and resolution, giving you visibility into the full lifecycle of a bug: when it was first seen, how many users it affected, when a fix was assigned, and when the fix was verified in production.

Error Budgets and Service Level Objectives

An error budget is a concept from Site Reliability Engineering (SRE) that quantifies how much unreliability your service is allowed within a given period. It is derived from your Service Level Objective (SLO). If your SLO states that 99.9% of API requests should complete successfully, your error budget is 0.1% — meaning you can tolerate up to 0.1% of requests failing before you need to take corrective action.

Error tracking data feeds directly into error budget calculations. By measuring the actual error rate in production, you can determine whether you are within your error budget or burning through it too quickly. When the budget is nearly exhausted, the team shifts focus from shipping new features to improving reliability. When there is budget remaining, the team has confidence to ship changes faster.

This approach turns reliability from a subjective judgment ("things feel unstable") into an objective measurement ("we have consumed 73% of our monthly error budget with 11 days remaining"). It gives engineering leadership a data-driven framework for balancing velocity and stability.