Front-end errors are collected with Real User Monitoring (RUM). The error message and stack trace are included when available.

Error origins

Front-end errors are split into four different categories depending on their error.origin:

  • source: Unhandled exceptions or unhandled promise rejections (source-code related).
  • console: console.error() API calls.
  • custom: Errors sent with the RUM addError API.

Error attributes

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

AttributeTypeDescription
error.sourcestringWhere the error originates from (for example, console).
error.typestringThe error type (or error code in some cases).
error.messagestringA concise, human-readable, one-line message explaining the event.
error.stackstringThe stack trace or complementary information about the error.

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.

AttributeTypeDescription
error.typestringThe error type (or error code in some cases).

Collect errors manually

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

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

Note: The Error Tracking feature processes errors sent with source set to custom or source and that contain a stack trace. Errors sent with any other source (such as console) will not be 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);
}

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.”

Real User Monitoring script error example

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 via 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