+1. This would improve the value of HTTP errors. Right now the majority of captured errors are designed and are not errors from the API/app perspective.
This is something that we need as well.
It’s getting awful to slog through so many bad requests.
This is one reason we’re thinking of leaving NewRelic honestly.
Hey @hawley! Thank you for your candid honesty above . I can absolutely see where you are coming from—manually slogging through tons of errors/bad requests sounds like a nightmare and a fairly good reason to give up on a product.
I want you to know: the future of this possible feature is been discussed by our Mobile Product team. Please hang tight and be sure to add your vote! It really helps our Mobile PM @sbily see the need behind this. I’ll pass your specific use case along as well, so please provide more detail if you wish.
Thanks again for posting and please be sure to check back on this soon.
I’m excited to let you know about a new feature for our Enterprise customers!
We now have a new Insights event type called MobileRequestError. If you run queries against this, you can include things like:
SELECT * from MobileRequestError where errorType=‘HTTPError’ and statusCode not like ‘401’
This way, you can filter out the errors you don’t care about. And, if you have access to the pre-release of NRQL alerts, you can set up an alert with the same criteria.
The documentation has several key examples.
We also have a level-up forum post.
I’d love to hear your ideas and feedback!
But what about the errors which are recorded under APM error analytics section. Still i am seeing new relic is recording http 400 status code and generating false alarms for us.
Great timing - as it happens we are working on a feature in the Java agent to mark certain kinds of errors as “expected”. We will still collect them so you can see them in Error analytics, but we will exclude them from the overall application error rate. That filtering will also be available for customizing your NRQL alert conditions and dashboards. Just curious for everyone on this thread: What languages are you using where you need this capability?
I’m also super frustrated by the lack of this feature. When you try to access our app, logged out, it returns a 403, and redirects you to the login page. This is a normal, handled use case, so I don’t expect to see it on the new relic dashboard. However, the volume of these errors drown out the actual server errors (5xx series), and so it’s super hard to find anything.
Sorry that you are frustrated with us right now, @tejas - I hope you were able to add your vote above. Please also know that I have passed your use case along to the right people.
Like our Product Manager, @scarpenter says above , we are making progress with this feature! and we are currently working on options that will cut back on “noise”. Thanks for jumping in and sharing your candid thoughts.
I’m super excited to let you all know that with Java Agent 3.38 you now have several flexible error configuration options to control how your errors are reported. You can configure certain exceptions that you expect your application logic will throw. These “expected errors” will not be counted towards your application error rate and Apdex; you will only be alerted on errors that truly affect the health of your application.
Expected errors can be configured by exception class or HTTP response code. When specifying an exception class, you can provide an error message to match. Here is a link to the documentation for more details.
Is there a way to ignore error based on (HTTP Response Code + HTTP Response Message) instead of just HTTP Response Code?
For example, if I have two different different scenarios for a transaction
Scenario 1: HTTP Response Code = 400, HTTP Response Message = Bad Request
Scenario 2: HTTP Response Code = 400, HTTP Response Message = Required Id missing
I want to mark the Scenario 2 as expected. How can I achieve it?
This sounds more like a 422 error to me. The status codes are meant to denote an entire class of things, and the 400 (bad or malformed request) versus a 422 (unprocessable entity) or a 404 (id missing or not found) are entirely different things. Perhaps you could do a bit more introspection into the actual meaning of the HTTP status codes as they pertain to errors in your application?
Our company would be looking for this functionality on our mobile (iOS, Android) platforms.
@daniel14 If you’re using our Mobile Enterprise product, you can do this today using MobileRequestError events in Insights. We will be bringing the functionality into the Mobile UI as well, using this same event-level data. Here’s a great forum post on it: Relic Solution: Leveraging MobileRequest and MobileRequestError events for more effective alerts & troubleshooting
Good afternoon. Has this issue been addressed with Synthetics in New Relic?
@Harvey.Dixon - Can you clarify? Are you looking for HTTP Errors to be ignored in Synthetics? This thread pertains mostly to Mobile, so we may need to get your post moved over to the Synthetics section. Let us know and we can help out from there.