Errors page: Find, fix, and verify problems

EOL NOTICE

As of March 2022, we're discontinuing support for several capabilities, including our errors classic UI. For more details, including how you can easily prepare for this transition, see our Explorers Hub post.

With the Errors UI in New Relic One, you can see the line of code that's causing a bad experience for your users, and get enough data to reproduce the issue so you can fix it. When you do, you’ll be able to confirm your fix is working in production.

Use Errors in New Relic One to:

Group and filter events to triage important errors.
Get alert notifications about errors.
Review stack traces, logs, and other details.
Share the error information with charts and dashboards.
Report new errors using instrumentation, prevent certain errors from being reported, and filter out noisy errors using expected errors.

View the APM Errors page

To view the Errors page:

Go to one.newrelic.com > APM > (select an app), then click the Error rate table's title on your selected app's Summary page.
OR
Go to one.newrelic.com > APM > (select an app) > Events > Errors.

APM Errors UI: The Error rate chart always shows the rate for all errors, even if a filter is applied. To drill down further, use grouping and filter options for the Top 5 by count chart and Error traces table. Use the Instance dropdown to focus on a specific instance.

Use the Errors workflow to identify problems

Use this basic workflow to get the most out of the information you see from the Errors page.

Start with the Error rate chart to see at a glance whether there are any unexpected spikes, dips, or patterns with errors in general.
Correlate any general patterns on the Top 5 errors chart to alerts occurring during the same time period. Use the groups and filters to examine the error events and attributes in more detail, and look for patterns with error messages, transaction names, or other groupings.
Explore and share Error trace table information, including specific stack trace details, logs, and attributes (host, URL, user, custom attributes, etc.)
Also review the Error profiles page to guide your investigation into which attribute values might be correlated to the cause of errors, by comparing the frequency of those values between transactions where the error did and didn't occur (only in the old UI).

Start with the Error rate chart to see at a glance whether there are any unexpected spikes, dips, or patterns with errors in general. For example, are there any spikes near a recent deployment? You may want to change the selected time period to look for other historical patterns.

This chart always shows the overall error rate and count for the selected time period, even when you filter the rest of the page. If you want to focus your investigation on a particular type of error, use the Top 5 errors chart or the Error traces table.

Use the Top 5 errors chart to identify what error types and how many of those errors occurred during the same time period as the Error rate chart. For example:

Is the error spike related to a specific exception class or transaction?
Do the top errors point to a new host/container that recently got moved into production?
Are the top error messages repeatedly about failed connections by hosts that you know are in a specific region of your organization?

Have the chart backgrounds changed color to indicate an alert condition? (Light pink indicates the alert condition's Warning threshold, and dark pink indicates the Critical threshold.)

If you want to...	Do this...
Change the "top 5" selection	By default, Top 5 errors chart shows the top five errors by error class and transaction name. To group by other attributes, such as error message, host, or custom attribute, use the search bar.
Explore or share error trend data	The Top 5 errors chart uses error events, which include rich attribute data b default, along with any custom attributes you have added to the error event type. To examine this data in more detail, or to share it with others, select the View query or Add to dashboard links that appear when you click the chart's ... menu.

The Error traces table groups errors by the attributes you've selected, and links them to relevant detailed error traces.

Each row helps you find answers to questions such as:

How many of this transaction/class (or custom grouping) occurred within the selected time period?
What is the most recent error message?
When did this error first and last occur?
Sometimes it may be useful to sort error trace data other than from the most to fewest occurrences. You can change the sort order or filter options to focus on just the types of errors that matter the most to you and your teams. For example:
Which error has the fewest occurrences (sort on Errors column)?
When did a particular error stop (sort on Last occurred)?
Once you find the group of errors you want to fix, click a row in the Error traces table to drill down into the stack traces and attribute data that help pinpoint the cause.

Examine logs for error details

You can bring your logs and application's data together to make troubleshooting easier and faster. With logs in context, you can see log messages related to your errors and traces directly in your app's UI.

From the Errors page, click on an error to go to the Error details page.
From the error details page, click See logs.
To view details related to an individual log message, click directly on the message.

With logs in context, you can examine log data directly within your error details.

You can also see logs in context of your infrastructure data, such as Kubernetes clusters. No need to switch to another UI page in New Relic One.

Expected errors

Reduce noisy errors by marking them as “expected errors”. Such errors won't affect reported error rate or Apdex metrics. See Manage errors for more details.

Expected errors aren't shown by default on the Errors page. You can show them by turning on the Show N expected errors switch below the Group by bar.

Errors outside transactions

Using the New Relic agent API, you can record custom errors at any point in the execution of your code. Sometimes, such custom errors will occur when a transaction is not executing, such as in high-volume aynchronous code that doesn't handle an HTTP transaction.

Errors outside transactions are shown by default on the Errors page, but you can hide them by turning off the Show N errors outside transactions switch below the Group by bar.

Select the time period for error data

Use the time picker to examine details of error events over the past week. The error events view is available for up to a seven-day window of data collected over the last eight days.

You may notice slight differences in count if your time window is set to ending now. This occurs because the counts for the list and table may be requested at slightly different times as the page auto-refreshes.