- Catch errors that we don't instrument by default.
- Ignore errors that you don't want reported at all.
- Filter out noise from expected errors so you can focus on the errors that are affecting performance. (Java, Ruby, Node, and .NET agents only)
APM agents include API calls to report (or "notice") errors. These are useful when APM doesn't instrument your framework automatically or when there are particular errors that aren't caught for your supported framework.
To learn how to get an APM agent to report an error, see the agent-specific API documentation:
- C SDK:
Sometimes the APM agent instruments an error that you don't want reported, such as errors that contain sensitive information like user login errors. If you don't want an error to report to the our collector, you can ignore the error, and the APM agent discards the error entirely.
For Java, Ruby, and Node.js: If you want to report errors to APM but don't want those errors to affect your Apdex or error rate, mark them as expected instead.
There are two ways to ignore errors: through the agent configuration or through server-side configuration in the UI:
For the Ruby and Java agents, you can mark errors as expected. These errors will be reported to APM and available for viewing, but they won't affect the Apdex or error rate (or alert conditions based on error rate).
To configure errors as expected, see the agent-specific documentation:
If expected errors are enabled, APM's Error analytics page will, by default, have a filter applied with the
error.expected attribute set to
false, meaning expected errors will not be displayed. To view expected errors, turn off the
To view expected errors, query your data:
- To view charts of expected errors, create a query for the
- To create alert conditions for NRQL queries, use the
Among other places, error data appears in these parts of the UI:
- Error analytics page: shows in-depth charts and visual analysis of errors.
- APM Overview page: shows a high-level view of your application, which includes errors.
- Alert conditions: can be based on error rate.
transactionErrorevent: contains underlying error data, which can be used in NRQL queries.
If you need more help, check out these support and learning resources:
- Browse the Explorers Hub to get help from the community and join in discussions.
- Find answers on our sites and learn how to use our support portal.
- Run New Relic Diagnostics, our troubleshooting tool for Linux, Windows, and macOS.
- Review New Relic's data security and licenses documentation.