Feature Idea: Is There a Way to Ignore Certain HTTP Errors?

In my use case, I’ve got quite a lot of http 400 or 401 errors, however, most of them were designed: for example, if the access token is expired, server will return a 401, and if the user inputs wrong username/password while logging in (post these parameters to /login API), server will return a 400.
In this case, I’d like to just ignore all of them, since I should not care about these failures.


New Relic edit

  • I want this, too
  • I have more info to share (reply below)
  • I have a solution for this

0 voters

We take feature ideas seriously and our product managers review every one when plotting their roadmaps. However, there is no guarantee this feature will be implemented. This post ensures the idea is put on the table and discussed though. So please vote and share your extra details with our team.

@ytian there isn’t a way currently to ignore errors in the Android or iOS SDKs. However, I’ll share your use case with our product managers. We’ll be in touch if there are any updates or developments for this feature.

+1 this addition. We’re finding it hard to rely on the error rate alerts without excluding known and non problematic errors.

Added you to this issue! Thanks!

+1 too. This would be very useful. Getting alerts for non-issues.

Thanks all! Duly noted. We do have a bit of a backlog, but hopefully this is something we can tackle along the way.

+1 (this extra typing I’m doing in this post is only here because the forum requires > 20 characters per post).

Thanks for sharing your use case with us, @paul.roe! I will be sure to pass it along to my product managers via feature request.

Could you clarify, @paul.roe? What reply? And are you saying it’s limited to 20 characters?

just that the forum posts are required to have 20 characters. All I really wanted was to +1

Got it, thank you @paul.roe !

+1 I have requested this too. In particula, i get alot of DNS lookup failed and this will set off alerts. I would like to be able to ignore this.

Thank you for letting me know your use case, @david.freedman! I’ll be sure to add this to your feature request. :thumbsup:

This is essentially a must-have. The mobile monitoring is currently absolutely worthless to us, as we cannot rely on it’s alerts to be in any way actionable.

Our APIs respond with various “error codes” to various user events, any of which will be counted as an “application error” of some sort and end up triggering alerts. We use a wide variety of 4xx -errors to indicate to the app that the request did not succeed, but this does not indicate an error in the system.

As it is, we get no benefit from mobile monitoring, and it is practically wasted money to our organization. To make this useful the preferred way would be to be able to set up ignores in e.g. the following manner:

*://*.company.com/* - 401, 403, 426
https://another.company.com/api/* - 404

Hey @lietu! Thanks so much for letting me know your situation. I am sending all the details you provided to our product team so they can see how you are being affected without this functionality. Thanks for being candid with us—I appreciate it!

Other than creating a feature request for you about this, would you like me to connect you with your Account Executive so that you can talk about how you feel this is a wasted expense?

+1. The same. New Relic tracks all valid errors from mobile as HTTP errors (wrong credentials, unable to update model etc…)…

+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.

Hi @Oleksii.Kozulin @lebarovets , thanks for letting us know! I’ve added this feature request for you two.

Hey there,

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 :arrow_up:. 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.