Observability

Error monitoring

This feature is in Early Access

LaunchDarkly’s observability features are publicly available in early access.

They currently require the LaunchDarkly observability plugins and the JavaScript SDK. If you are interested participating in the Early Access Program for our upcoming observability plugins for server-side SDKs, sign up here.

Overview

This topic explains how to use LaunchDarkly’s observability features to understand and view errors in your application. The Errors view displays a list of recorded errors.

Get started

To instrument your application to capture errors, read the SDK documentation on Observability. The functionality is available through plugins to the LaunchDarkly JavaScript SDK.

View errors

To view details about a specific error, click the error in the list. The error details page appears. The page displays details about how many times the error has occurred, how many users have been affected, and when the error was first and most recently observed. The page opens to the Instances tab.

The Instances tab

Use this tab to get an overview of the error’s impact and see stack traces on per-instance occurrences. You can see details about a specific occurrence of an error, like what browser the user encountered it in, what URL they had loaded when it occurred, and more.

This tab includes a “Stacktrace” section, which LaunchDarkly populates:

  • if your sourcemap is inline, meaning it’s shipped as part of your application, or
  • if you have uploaded your sourcemap to LaunchDarkly. To learn how to upload your sourcemap, read Use ldcli for uploading sourcemaps].

A detailed view of an error.

A detailed view of an error.

The Metrics tab

An error’s Metrics tab shows you details about how the error has occurred over time and across different environments. You can see the number of times an error has occurred in a given second, the environments and browsers the error has occurred in, and more.

A detailed view of an error.

A detailed view of an error.

Group errors

LaunchDarkly groups errors together based on their error message and stack trace. When your application throws an error, LaunchDarkly finds the closest matching error and adds the new error instance to it.

An error matches if:

  • it has the same error message, or
  • it has the same top stack frame and three of the next four stack frames are the same, in any order

A stack frame matches if:

  • it has the same file name, function name, line number, and column number, or
  • it has the same source code and context, if sourcemaps are enabled

If there is no match with an existing error, LaunchDarkly creates a new error group.

Manage errors

As you review errors, you can change their status.

To change the status of an error:

  1. Navigate to the Errors view.
  2. Click to select an individual error. New errors start with an “Open” status.
  3. Click the status dropdown to change the status:
    • Select a new status from the menu. You can change an error’s status to “Ignored” or “Resolved.”
    • Select Snooze to snooze the error until the specified time.

The status dropdown menu for an error.

The status dropdown menu for an error.

You can also configure LaunchDarkly to automatically resolve errors that have not appeared for a given time period. To learn how, read Monitoring settings.

To learn more about the search specification for the errors view, read Search specification.

Search attributes

By default, the observability SDK plugin automatically injects the following attributes to provide additional help with searching for traces:

AttributeDescriptionExample
browserBrowser the end user was using.Chrome
client_idID associated with the error, added by LaunchDarkly. This can serve as a unique identifier if there is no context associated with the error.DQbQCEHN0FLuwCeW50AeLI0cH6C4
environmentThe environment key, based on the SDK credentials used in the SDK plugin.production
eventThe title of the error.Maximum call stack size exceeded
has_sessionWhether the error is tied to a session.true
secure_session_idSession ID that contains the error.wh1jcuN5F9G6Ra5CKeCjdIk6Rbyd
service_nameName of the service specified in the SDK plugin. To learn more, read Versioning sessions and errors.private-graph
service_versionVersion of the service specified in the observability SDK plugin. To learn more, read Versioning sessions and errors.e1845285cb360410aee05c61dd0cc57f85afe6da
statusStatus of the error group.RESOLVED
tagTag applied to the error.example error
trace_idTrace ID that contains this log.7654ff38c4631d5a51b26f7e637eea3c
typeGeneral type of the error.React.ErrorBoundary
visited_urlURL where the error occurred.https://app.example.com/1/errors

Filter

You can filter out errors that you do not want to view in LaunchDarkly. This is useful for errors that you know are not relevant to your application, or that are not actionable. Filtered errors do not count against your errors quota.

Ingestion filters

You can set up ingestion filters to limit the number of errors recorded in the following ways:

  • Sample a percentage of all data. For example, you may configure ingestion of 1% of all errors. For each error LaunchDarkly receives, it makes a randomized decision that results in storing only 1% of all errors.
  • Rate limit the maximum number of data points ingested in a one minute window. For example, you may configure a rate limit of 100 errors per minute. This lets you limit the number of errors recorded in case of a significant spike in use of your application.
  • Filter specific errors by a regex pattern match against the error body.

You can configure these filters from your project settings. To learn how, read Monitoring settings.