New Relic Shows How to Filter Errors with OpenTelemetry
Alert fatigue is a real problem for engineering teams. When routine, non-critical errors pile into dashboards and inboxes, on-call engineers burn out chasing false alarms. New Relic is now offering a practical fix through New Relic OpenTelemetry error filtering, using the OpenTelemetry Collector’s Transform Processor.
The guide, published on May 11, 2026 by Software Engineer Emilia Ferreyra of the NRDOT team, explains how errors are represented inside New Relic. Error rate charts on service summary pages pull from metrics with an error.type attribute. Meanwhile, spans marked with an ERROR status code drive the Errors Inbox experience, helping teams detect, triage, and resolve problems.
The challenge is that not every error deserves that treatment. In most applications, certain HTTP responses, such as a 500 Internal Server Error, are expected behaviors rather than actual system failures. When these routine events keep showing up as critical errors, they inflate error rates and distort service level indicators (SLIs).
That is exactly where New Relic OpenTelemetry error filtering comes in. Rather than blindly dropping data, the approach selectively updates span status codes and metric attributes. This prevents an event from negatively affecting golden signals while still keeping the underlying trace data available for debugging when it is actually needed.
The method uses the OTel Collector’s Transform Processor to modify error data before it reaches New Relic. For spans, the configuration changes the status code from ERROR to UNSET, effectively marking the error as ignored. At the same time, the error.type attribute is removed from the relevant metric datapoints to stop it from inflating the error rate chart.
In a proof-of-concept test, applying the configuration for HTTP 500 errors cut the error rate from 50% to 31.25%. The 500 errors also disappeared entirely from the Errors Inbox, leaving only genuinely actionable issues.
