Collecting Browser Errors

Overview

The Browser SDK collects frontend errors, including the error message and stack trace when available. For triaging and managing these errors in the Error Tracking product, see Browser Error Tracking.

When the Browser SDK collects an error:

• The error is captured as an Error event in RUM.
• Retention Filters that target sessions containing an Error event retain the current session.
• The RUM metrics rum.measure.error, rum.measure.session.error, and rum.measure.view.error_free are updated, regardless of whether the session is retained.
• The error is captured in Error Tracking.

Error Tracking rules do not apply to Error events, and RUM still records Error events that match Ignored and Excluded issues in Error Tracking. To prevent errors from being recorded as Error events, you must discard them before they are sent to Datadog using the beforeSend callback.

Error sources

Frontend errors come from several different sources:

• agent: From the SDK execution
• console: From console.error() API calls
• custom: Sent with the addError API
• report: From the ReportingObserver API
• source: From unhandled exceptions or unhandled promise rejections in the source code

Error attributes

For information about the default attributes for all event types, see Data Collected. For information about configuring for sampling or global context see Modifying Data and Context.

Source errors

Source errors include code-level information about the error. More information about the different error types can be found in the MDN documentation.

Collect errors manually

Monitor handled exceptions, handled promise rejections, and other errors not tracked automatically by the Browser SDK with the addError() API:

addError(
 error: unknown,
 context?: Context
);

Note: Error Tracking processes errors that are sent with the source set to custom, source, report or console, and contain a stack trace. Errors sent with any other source (such as network) or sent from browser extensions are not processed by Error Tracking.

import { datadogRum } from '@datadog/browser-rum';
// Send a custom error with context
const error = new Error('Something wrong occurred.');
datadogRum.addError(error, {
 pageStatus: 'beta',
});
// Send a network error
fetch('<SOME_URL>').catch(function(error) {
 datadogRum.addError(error);
})
// Send a handled exception error
try {
 //Some code logic
} catch (error) {
 datadogRum.addError(error);
}

// Send a custom error with context
const error = new Error('Something wrong occurred.');
window.DD_RUM.onReady(function() {
 window.DD_RUM.addError(error, {
 pageStatus: 'beta',
 });
});
// Send a network error
fetch('<SOME_URL>').catch(function(error) {
 window.DD_RUM.onReady(function() {
 window.DD_RUM.addError(error);
 });
})
// Send a handled exception error
try {
 //Some code logic
} catch (error) {
 window.DD_RUM.onReady(function() {
 window.DD_RUM.addError(error);
 })
}

// Send a custom error with context
const error = new Error('Something wrong occurred.');
window.DD_RUM && window.DD_RUM.addError(error, {
 pageStatus: 'beta',
});
// Send a network error
fetch('<SOME_URL>').catch(function(error) {
 window.DD_RUM && window.DD_RUM.addError(error);
})
// Send a handled exception error
try {
 //Some code logic
} catch (error) {
 window.DD_RUM && window.DD_RUM.addError(error);
}

React error boundaries instrumentation

You can instrument the React error boundaries to monitor React rendering errors using the RUM Browser SDK addError() API.

The collected rendering errors contain a component stack, which is unminified like any other error stack traces after you upload sourcemaps.

To instrument React error boundaries for monitoring, use the following:

import { datadogRum } from '@datadog/browser-rum';
class ErrorBoundary extends React.Component {
 ...
 componentDidCatch(error, info) {
 const renderingError = new Error(error.message);
 renderingError.name = `ReactRenderingError`;
 renderingError.stack = info.componentStack;
 renderingError.cause = error;
 datadogRum.addError(renderingError);
 }
 ...
}

class ErrorBoundary extends React.Component {
 ...
 componentDidCatch(error, info) {
 const renderingError = new Error(error.message);
 renderingError.name = `ReactRenderingError`;
 renderingError.stack = info.componentStack;
 renderingError.cause = error;
 DD_RUM.onReady(function() {
 DD_RUM.addError(renderingError);
 });
 }
 ...
}

class ErrorBoundary extends React.Component {
 ...
 componentDidCatch(error, info) {
 const renderingError = new Error(error.message);
 renderingError.name = `ReactRenderingError`;
 renderingError.stack = info.componentStack;
 renderingError.cause = error;
 window.DD_RUM &&
 window.DD_RUM.addError(renderingError);
 }
 ...
}

Troubleshooting

Script error

For security reasons, browsers hide details from errors triggered by cross-origin scripts. When this happens, the Error Details tab shows an error with the minimal message “Script error.”

For more information about cross-origin scripts and why details are hidden, see CORS and this Note on Global Event Handlers. Some possible reasons for this error include:

• Your JavaScript files are hosted on a different hostname (for instance, example.com includes assets from static.example.com).
• Your website includes JavaScript libraries hosted on a CDN.
• Your website includes third-party JavaScript libraries hosted on the provider’s servers.

Get visibility into cross-origin scripts by following these two steps:

1. Call JavaScript libraries with crossorigin="anonymous".

   With crossorigin="anonymous", the request to fetch the script is performed securely. No sensitive data is forwarded through cookies or HTTP authentication.

2. Configure the Access-Control-Allow-Origin HTTP response header:

   • Access-Control-Allow-Origin: * to allow all origins to fetch the resource.
   • Access-Control-Allow-Origin: example.com to specify a single allowed origin. If the server supports clients from multiple origins, it must return the origin for the specific client making the request.

Further Reading

Request a personalized demo