Errors inbox provides a unified error tracking experience to detect and triage errors:
- View and triage issues across applications and services that your team cares about for faster error resolutions.
- Proactive notifications with detailed error information in Slack.
- Error profiles to show similarities between error events and surface the root cause by analyzing attributes.
- Analyze errors in context of the full stack and resolve errors with precision.
- Errors for APM, browser, mobile, and AWS Lambda functions are all captured in the same inbox.
Ready to get started? See our docs about creating your first workload.
Once you've set up your errors inbox, you can begin proactively monitoring all errors in your stack:
Error groups are sets of events that make up a unique error. Error groups are stored long term and contain metrics, activity log, discussions, and basic information about the unique error. Error groups are tied to the entity, so making a change to the state of an error group in one errors inbox will impact all other inboxes that contain that entity.
Error events get grouped into an error group when they share the same fingerprint. As events are ingested by New Relic, we run the events through a set of managed rules that output a fingerprint. Every unique fingerprint has a single error group associated with it.
The New Relic managed rules normalize the error data, identifying and ignoring unique values such as UUIDs, hex values, email addresses, etc. that would cause grouping "like" errors into unique groups. New Relic account ID, entity ID, error class, error message, stack trace, and exception are all data that can impact a fingerprint.
While our managed rules are able to provide automatic error grouping based on a predefined set of patterns, it is impossible to recognize every possible combination.Thus, removing high variability values from error messages will guarantee that your errors are grouped correctly.
For example, consider these two error messages:
- "Parsing Error: you put 124 and that is not allowed"
- "Parsing Error: you put 456 and that is not allowed"
These error messages look similar but these error occurrences are less likely to be grouped properly due to numbers that are shorter than 4 digits (124). If there is additional information (e.g. SQL statements, ids, etc) you would like to include in the error message, it can be sent via custom attributes.
- Avoid using numbers less than 4 digits long inside the error message.
- Avoid including special character inside error message.
- Avoid including SQL statements inside error message.
- Avoid including stack trace in the error message. Stack traces will not be formatted when sent as error message, thereby will not work with the CodeStream integration
- Avoid including data that have high variability (ex: ids, dates, JSON). Users will be better served if these values were collected as attributes. These attributes can be viewed at the individual occurrence level as well as at the error group level in errors inbox inside the attributes tab.
- We caution use of dates/timestamps. Although we do catch and group some error messages that contain timestamps, we can't guarantee we will recognize every format.
Your errors inbox displays the total number of occurrences of each error group within the selected timeframe. The corresponding sparkline chart displays the total number of occurrences per day over the selected timeframe as you hover over it.
Using the dropdown in the top right, you can sort the list of grouped errors by the number of occurrences or by the error that was last seen in the time range selected. For example, if the time picker selected is
Jan 24 5:00pm ET -- Jan 24 5:45pm ET and you sort by last seen, you will see error groups sorted with those containing the most recent occurrence first.
An error group is tagged with a regression tag when a new error matches a resolved error group's fingerprint. The regression tag will disappear once a regressed error group's state is changed.
An error group is tagged with an expected tag if all error occurrences in the group are expected. It is tagged with a contains expected tag if some error occurrences are expected and some are not. These tags are available on all errors after January 21, 2023.
See more on how to mark errors as expected.
You can resolve, ignore, or unresolve errors in bulk with the Edit groups dropdown.
You can update the status of multiple error groups (up to 2,000) all at once. In the inbox view, check the Error groups checkbox to update all of your error groups in the inbox. You can also select individual error groups to update their statuses.
We understand it's very useful to know when an error group was first seen in order to correlate it with a change in the code/system. The accuracy of first and last seen dates depends on the three scenarios outlined below:
Scenario 1: If an error group was first created on or after 5/17/2022, first and last seen values are accurate.
Scenario 2: If an error group was first created before 5/17/2022, the first seen date will not be accurate. The first seen date is either 5/17/2022 or the date of the earliest occurrence (if the time window selected is before 5/17/2022). The last seen value will be accurate.
Scenario 3: If an error group occurs once per week or less, the first and last seen dates are estimates based on the time of the single occurrence. We only track first and last seen dates accurately for errors that show up more than once per week.
Errors inbox enables you to triage error groups directly from the main screen or from the error details page. Triaging helps remove the noise from your errors inbox, and lets you focus on the high impact errors that need attention.
You can set one of three statuses, and filter your inbox by status.
Unresolved: This is the default status of error groups.
Resolved: Setting an error as resolved will hide it from the default inbox view unless filters are updated to include resolved errors. If events matching the error group fingerprint occur after marking an error group as resolved, it will automatically reset the status to
Unresolved. This can be useful for identifying regressions.
Ignored: This will hide the error group from the inbox view unless filters are updated to include ignored errors, or until you stop ignoring the error group.
Errors inbox enables you to filter out expected errors for APM entities. You can mark errors as expected, and filter them out of your inbox to remove noise.
- error.expected != true: This is the default. It hides all error groups that have only expected errors and it marks error groups that have a mix of expected and unexpected errors with the "Contains expected" tag.
- error.expected = true: This filter will show error groups where some or all errors in the group are expected. This can be useful for identifying which errors are marked as expected.
- Removing the error.expected filter will show all error groups whether they contain errors that are marked as expected or not.
- Expected errors are always removed from notifications.
- All of the features above as well as the expected errors tags are available on errors after January 21, 2023.
Clicking on a specific error group takes you to the error details page, where you will find full context of the issue. This context can help you triage the error and assign it to the correct team or individual.
The attributes tab helps you observe interesting trends across all error occurrences inside a specific error group. You can download this information as a CSV file for further analysis. When an attribute bar is clicked, a table is rendered which shows the breakdown of attributes and counts.
You can assign an error group to anyone. Simply select the user from the assign dropdown menu. You may also assign an error to any email address, even if they aren't a New Relic user.
You can update the filter in errors inbox to show only errors assigned to yourself, or a teammate.
Standard role restrictions (read-only, standard, etc.) are only enforced in the error group comments feature of errors inbox. Outside of the comments capability, role restrictions are not enforced. Therefore, a read-only user has the ability to assign an error group within an account, outside of the account, and update the states of the error group (such as ignored, resolved, unresolved).