obsdog

Error Tracking

Error Tracking groups errors that recur from the same cause into a single Issue, so you can track the number of problems rather than the number of occurrences. It brings the three sources RUM, APM, and logs into one list, and can notify you only about new and recurring issues.

About 12 min read

What it does

It computes a fingerprint from attributes such as the error type, message, and stack trace, and groups errors with the same fingerprint into one Issue. Each Issue carries the first and last time it occurred, the trend in occurrence count, the number of affected users, and the commit suspected of causing it, and can be tracked with a state (For Review / Reviewed / Resolved / Ignored / Excluded).

When to use it

This is the equipment for getting out of the state where thousands of error logs appear per day but nobody knows how many actual defects there are. Typical uses are notifying only about Issues that newly appeared right after a release, detecting that a defect once resolved has recurred (Regression) in a new version, and prioritizing fixes by the number of affected sessions.

An everyday analogy

Rather than reading complaint letters one by one, it is a receptionist who bundles letters about the same matter and counts them for you: 300 letters on this matter, the first on Tuesday night, from 120 senders. A pile of counts turns into a list of problems to address, and the receptionist only comes to fetch the person in charge when a new bundle arrives.

Why Reading Error Logs One at a Time Breaks Down

Seen one at a time, every error looks about equally urgent. In reality, the same defect is simply being recorded over and over, once per user, and the number of problems to address should be far smaller. Datadog's Error Tracking is the feature that closes this gap, grouping thousands of similar errors into a single Issue (as of September 2026; source: Error Tracking). The grouping rule is to compute a fingerprint from attributes such as the error type, message, and stack trace, and place errors with the same fingerprint into the same Issue (source: Error Tracking Explorer). An Issue carries the number of affected users, the time it first occurred, and the commit suspected of causing it. When the report of 3,000 errors today turns into 4 unresolved Issues, one of which appeared for the first time today, a conversation about priorities becomes possible, and the work of bundling search results by eye is no longer needed.

Three Sources - What Differs in the Information Captured from RUM, APM, and Logs

Error Tracking does not limit errors to a single source. It ingests from three families, the browser and mobile SDKs, APM traces, and logs, and lets you handle them in one list by switching the Sources filter in the Explorer between All / Browser / Mobile / Backend (as of September 2026; source: Error Tracking Explorer). The information attached to an Issue differs by source.

Information Error Tracking captures by source (as of September 2026)
SourceIngestion Entry PointExamples of Information Attached to the IssueSource-Specific Features
Browser / Mobile (RUM)Browser SDK / Mobile SDKNumber of affected sessions, user characteristicsErrors not caught manually are classified as unhandled
Backend (APM)Error spans within tracesSpan tags such as resource name and operation name, direct navigation to related traces and logsException Replay automatically captures production variable values
LogsError events in logsLog attributes and originFiltering per log source
Source: Error Tracking / Error Tracking Explorer (as of September 2026)

Frontend Issues are tied to RUM sessions, so you get how many people were affected. Backend Issues are tied to APM traces, so they connect directly to which processing step of which request the error occurred in, and for APM-derived errors Exception Replay even preserves the variable values at the time the exception was raised (source: Error Tracking). Issues derived from Log Management can also group errors from existing systems where an SDK cannot be installed.

What the List Shows - New / Regression / Crash Markers and Sorting

In the Explorer list, each Issue shows the error type and message, the path of the originating file, the first and last occurrence times, a trend graph of occurrence count, and the count within the selected period (as of September 2026; source: Error Tracking Explorer). Issues carry markers: those less than 2 days from first occurrence with the state FOR REVIEW show New, those that had been resolved and then occur again in a new version show Regression, and those where the application crashed show Crash. There are four sort orders: Relevance (a priority combining age, recent count and surges, and whether a crash occurred), Count, Newest, and Impacted Sessions. Filtering is done with facets, and you can slice by error.type or error.handling (handled or unhandled). APM-derived errors are judged handled if the parent span returned success.

The Five Issue States and Automatic Transitions

An Issue has five states, and all start from FOR REVIEW (as of September 2026; source: Issue States in Error Tracking).

  • FOR REVIEW: a new or recurring Issue. Assigning an owner or creating a work item moves it automatically to REVIEWED
  • REVIEWED: an Issue for which a response has been decided. Once fixed and occurrences stop, it moves to RESOLVED (manually or automatically)
  • RESOLVED: resolved. If there is a version tag, it is resolved automatically when it has not recurred in a newer version for 14 days or more; if not, it is resolved automatically after 14 days with no occurrences
  • IGNORED: an Issue that needs no further investigation or response
  • EXCLUDED: a state that stops tracking altogether. Collection of new errors stops, and it is no longer counted toward usage and billing
Source: Issue States in Error Tracking (as of September 2026)

The value of these state transitions lies in automation. The moment you assign an owner it becomes REVIEWED, and something you fixed becomes RESOLVED if it stays quiet for 14 days, so almost no manual closing work is required. When a resolved Issue occurs again in a new version, it comes back automatically as a Regression, so the bug you thought you had fixed surfaces in the release decision. This recurrence detection presupposes that the service carries a version tag, which is another place where including version in your tagging convention pays off.

Notify on New Issues, Not on Count Thresholds

An alert that places a threshold on the error count also fires when a known Issue rises or falls. Error Tracking has a dedicated monitor type that can notify you when a new Issue appears or when a high-impact Issue emerges (as of September 2026; source: Error Tracking Explorer). The search conditions you build in the Explorer can be exported directly as the scope of a monitor, so a condition such as Issues marked New in the Backend of the payment service can be turned into a monitor straight from the filter you verified in the list. The effect of this design is that the denominator for notifications changes from occurrence count to the appearance of an Issue. Even if one defect occurs 1,000 times, you get one notification, and when a defect you thought you had fixed comes back as a Regression, the notice arrives through the same route. Dividing the roles, counts for the overall trend and Issues for new events that need a response, is the form that is easiest to operate.

How Pricing Applies

Because Error Tracking runs on top of each product that serves as the source of errors, billing also arises first in the units of the respective product, RUM / APM / logs (for how the units work, see how to read the pricing structure). This article does not cover a standalone unit price for Error Tracking; check Datadog Pricing for whether an independent SKU exists and its price. The official documentation states explicitly that setting an Issue to EXCLUDED stops the collection of new errors and removes it from usage and billing counts (as of September 2026; source: Issue States in Error Tracking). Excluding expected exceptions therefore matters on the cost side too. In addition, for the backend there is also a Standalone Backend Error Tracking path that sends errors to Error Tracking from SDK instrumentation, separately from APM traces (source: Backend Error Tracking).

Can It Do the Same Things as Sentry?

The skeleton of grouping errors into Issues, cycling through states, and detecting recurrence overlaps with dedicated error monitoring tools such as Sentry. The difference is what sits next to the Issue: in Datadog, the center of the design is that you can move from the same screen to the trace of the error span, related logs, and host metrics. A comparison that includes the areas where Sentry is stronger, and the decision between using both or replacing one, is covered in Datadog versus Sentry, so this article confines itself to the mechanism inside Datadog.

Finally, here is the order in which an organization that already searches for errors in logs can shift its operations to Error Tracking. There is no need to switch everything at once.

  • 1. Pick one source and enable it. Start with the family with the highest count (often logs or RUM) and see what fraction of the count the number of Issues comes to
  • 2. Establish a daily routine of bringing FOR REVIEW to zero. Assigning an owner alone moves it to REVIEWED, so it fits in 10 minutes in the morning
  • 3. Set expected failures to EXCLUDED. They drop out of both collection and billing, and the list becomes only what needs a response
  • 4. Align the version tag and use the Regression marker in release decisions
  • 5. Add a monitor for new Issues next to the count monitor, and shift notifications toward the Issue unit
Five stages for shifting operations to Error Tracking (source for state and marker specifications: Issue States in Error Tracking / Error Tracking Explorer)

The key points of this order are steps 1 and 3. If you first measure, on a single source, how much the count shrinks into a number of Issues, the return on the effort you put into this feature becomes visible in numbers. If you do not finish step 3 first, expected exceptions squat in FOR REVIEW and the daily routine becomes an empty ritual. Once this is in place, the starting point of incident response changes from searching logs and bundling the same things by eye to looking at the Issue list for new bundles and returning bundles, and the first 10 minutes of an investigation can be spent on isolating the problem itself.

Things to watch out for

  • This article is based on the official documentation as of September 2026. Issue state names, marker conditions, and the number of days for automatic resolution may change, so when in doubt, give priority to what the screen shows and what the official documentation says.
  • This article does not cover the unit price of Error Tracking. Check the official pricing page for how billing is handled and whether an independent SKU exists. Billing treatment may be revised after writing, so confirm the pricing page before signing a contract.
Share

Related products

RUMReal User Monitoring records and visualizes, as is, the speed, interactions, and errors that actual users experienced in the browser or mobile app. Even when every server-side monitor is normal, things can be broken on the user's screen. It is the monitoring that shows that gap.APMA product that follows each individual request your application receives and visualizes where the time went as a trace.Log ManagementLog Management is the product that gathers logs from servers, containers, and cloud services in one place and connects them to search, retention, and notification. It has a distinctive structure in which ingestion and indexing are billed separately.Monitors and AlertsA mechanism that watches metrics and logs with thresholds or anomaly detection and delivers signs of trouble as notifications.Incident ManagementIncident Management keeps the record and the roles on a single screen, from declaring an outage through resolving it to writing the retrospective. It handles state, severity, the commander, the timeline, and Slack integration, and pricing is determined by seats for the number of people who edit the record.Mobile RUMMobile RUM puts an SDK into native apps such as iOS and Android and records crashes, launch time, and per-screen slowness from the real user's device. The billing unit is the same session as browser RUM; only the items you can see are mobile-specific.

Related articles

Datadog vs Sentry - Where Error Tracking Draws the Line and Patterns for Running BothWhen a team using Sentry considers Datadog, the first thing to decide is "replace or run both". This article lines up the feature names and billing units of the overlapping areas (error tracking, tracing, RUM) from both vendors' primary sources, acknowledges where Sentry wins, and then shows the conditions for consolidating onto Datadog and the patterns for running both.

Products in the same category

Mobile RUMMobile RUM puts an SDK into native apps such as iOS and Android and records crashes, launch time, and per-screen slowness from the real user's device. The billing unit is the same session as browser RUM; only the items you can see are mobile-specific.Product AnalyticsA product that reads user behavior collected by the same SDK as RUM in the form of funnels and retention. Whereas RUM looks at "is it fast, is it broken," this answers "who did what, and where did they drop off."RUMReal User Monitoring records and visualizes, as is, the speed, interactions, and errors that actual users experienced in the browser or mobile app. Even when every server-side monitor is normal, things can be broken on the user's screen. It is the monitoring that shows that gap.Session ReplayA feature that records what users do in the browser or mobile app as changes to the screen and plays it back. Because it records DOM changes rather than recording video, what is kept and what is not is decided by configuration.SyntheticsExternal monitoring that keeps sending automated simulated requests from around the world so you notice failures before your users do. It checks on a schedule, even in the middle of the night when no real users are present and on paths nobody has taken yet.

Similar articles / products

Datadog vs Sentry - Where Error Tracking Draws the Line and Patterns for Running BothWhen a team using Sentry considers Datadog, the first thing to decide is "replace or run both". This article lines up the feature names and billing units of the overlapping areas (error tracking, tracing, RUM) from both vendors' primary sources, acknowledges where Sentry wins, and then shows the conditions for consolidating onto Datadog and the patterns for running both.EventAn event is a signal that records something that happened at a particular time as a single item, such as a deployment or a change in a monitor's state. Its role differs from metrics, which track numeric trends, and logs, which retain processing details; it is a clue that ties a change seen on a graph to "when what was changed."Work ManagementWork Management (formerly Case Management) is a feature that tracks matters requiring a response that fall short of an incident as work items with an assignee and a status. Items raised from monitors or security signals are opened and closed within a project.