Feature Idea: Surface Additional Details in Error Analytics with HTTP Response Codes

Please paste the [permalink][1] to the page in question below:

Please share your question/describe your issue below. Include any screenshots that may help us understand your question:


I’m curious as to how I can surface more about errors…
Basically, our RESTful service, which is built in C# using ASP.NET WebApi returns say a BadRequest; HTTP 400. In addition to the HTTP status code, we also have a simplistic JSON body returned with additional information. I’ve seen many API’s work in the same fashion.

The problem I’m having is I cannot see the message body in the Error Analytics, only that a 400 BadRequest has occurred and nothing more… Is there a way to surface this extra information so the Error Analytics can see this???


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.

1 Like


As you can see, there are no additional details, just the 400 HTTP Status Code and URL, the response would have contained a JSON body with another error code and description, but New Relic doesn’t show anything.

Surely, New Relic should just surface the entire message body associated with 4xx response codes…


Can anyone help here please?
The Error Analytics for services (in our case ASP.NET WebApi 2) doesn’t seem to very helpful at all…
The body of the return message is simply discarded…

@peter.king - You are correct that the body of the response is not displayed for status code only errors.

Is there a chance you can add the json response or some other bit of significant information using the agent’s AddCustomParameter API call? That information would appear in the error trace.

I’ll make a feature request to include the response body in the error trace for a 4xx response.

We could go down that road, but this would require code changes, which will be a pain to go through all calls in our services just to get the body of a HTTP response when it’s an error code.

Is there any timeline for the feature request, as it is quite basic I imagine to capture and store the response body of the HTTP response codes if it’s an error?

@peter.king - Alas, I’m not privy to the timelines for feature requests and I’d hate to hazard a guess as to when or if the feature would be implemented. I wish I could provide a specific timeline!

Thanks, but this is a fundamentally missed feature, how can HTTP errors be traced properly otherwise?

@peter.king -

That’s a great point and I made sure to reflect that concern in the feature request I made. There may be another engineering concern I’m not aware of that has prevented the adoption of this feature in the past. If the status code error had also been accompanied by an exception that we would show the exception but that is clearly not the case here. In the meantime you may need to try the custom attribute approach. I wish I had a better solution for you at this time! I’ll post here when I get an update on this.


We also have the same problem. Our API returns responses with HTTP error codes during normal use. These errors are usually because somebody is misusing the API, not that there is a problem with the API.

Not being able to see the requests and responses for errors gives us two problems. The first is that we can’t see how people are misusing the API, the second is it’s more difficult to see the real problems we may be having with the API because they are being masked by our ‘normal’ errors.


1 Like

Hey @douglas.waugh! Thank you very much for providing your use case and for letting us know what you would like to see moving forward. I will be passing this info along. :thumbsup:

Be sure to also vote above in the poll I have created. Thanks!

Consideration would have to be made for high security mode :wink:

1 Like