Your data. Anywhere you go.

New Relic for iOS or Android

Download on the App Store    Android App on Google play

New Relic Insights App for iOS

Download on the App Store

Learn more

Close icon

Feature Idea: NRQL for getting country codes by reponsecode



Looking for a way to chart/list countryCodes for transactions that ended with a given repsonseCode.

  • The ideal solution would be able to filter country codes by response code, so I could filter by, 500, for example, and get the countries where the 500 errors are coming from.

I’ve tried putting “Transaction, PageView” in the From, doesn’t seem to matter which (countryCode or httpResponseCode) I put in the facet, I get no results. Which doesn’t square with the results of using only the one. There are plenty of 404s, for example, and plenty of US countryCodes, but can’t seem to come up with both at the same time.

Use case for this ranges from locating where attacks are coming from (lots of 403’s from a countryCode) to locating errors while trying to handle international sites (which countryCodes produce ‘500’ errors to help find issues with translation files).

New Relic edit

Location Info via NRQL

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

0 voters

PageURL via NRQL

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


Hi, @arlen_walker: I think the issue is that httpResponseCode is a Transaction attribute, whereas countryCode is a PageView attribute. I don’t know of any way to FACET on two different event types in a single query. Also, if the server-side code returned an error (404, 500, etc.), it is likely that the resulting page (including the New Relic Browser agent) did not load successfully in the user’s browser, so there will be no country information.


Hmmm. I was hoping there was a way to pull together two different event types.

NR grabs a lot of server-side errors (that’s how it tracks PHP errors, for one example). Example: if you show Transaction grouped by httpResponseCode, you’ll see a list of the response codes during the time period, including not only redirects and 404’s, but also 403’s and 500’s, so I know the data is available. (As an example, I’m seeing 4 403’s in the last half-hour when I do that right now.)

In the case of 403’s, what I’m trying to do is build something that can show me where most of the attacks are coming from, so I can tell when something changes. (Where they are coming from on any given day isn’t as useful as discovering “This is not a ‘normal’ attack pattern.” That can mean a new player has “joined the game” and I need to check out what they’re bringing to the party.) The same information can be useful for 500’s, in that it can highlight other issues (not that 500’s don’t also occur during attack runs).

It’ll be even more irritating if that means I can’t match the response code (500, for example) with the request URL because that would be extremely useful (“Which requests cause most of the 500 errors” seems like a very good question to ask the data). I can almost do that with TransactionError, but I can’t get the query string, so with that I can’t reliably read what the problem is. PageView keeps track of the original URI; if your app breaks that into a query string, like most modern web apps do, then that is far more useful than “index.php” for troubleshooting.

Ah, well. If it were easy, anyone could do it.


Hi there, @arlen_walker! I can see that Phil gave you all the information on this, and wanted to offer to file a Feature Idea for capturing request location information on the APM side of things. Our Insights Product Manager will like to see how you want to use Insights for, as I understand it, a security solution.

You already provided a lot of great info, so just say the word! and I will add a poll to this thread so we can start to collect other/more community interest and use cases as well! :blush:

Thanks so much!


There are two feature requests in this issue, I think, both for additions to TransactionError (I think that’s the best place for them, since they’re both part of error analysis).

One is location info and the other is PageURL, both currently part of PageView and it would be helpful to see them in TransactionError so we can dig into where the errors are happening, both geographically (location code) and server-side (PageURL).

Location info can be paired with response code to spot new players in the game. In fact, it can be augmented by using something like mod_security to force specific error codes for specific types of attack (maybe returning error code “471” when a SQL Injection attack pattern is spotted, for a quick, off-the-cuff, example). I’ve already got most of the data I need for that in my server logs, but insight makes for an interesting user interface for it, saves me having to write a bunch of custom things in ELK to do the analysis.

Likewise PageURL is useful for determining what URLs attackers are focusing on breaking. Currently no event type contains both response code (which makes it easy to find attacks, when your security forces a 403 when it finds something it doesn’t like) and PageURL. Again, that information can be dug out of the local server logs, but the Insights queries could pull some interesting conclusions out of it as well. Also PageURL faceted with response code would be useful for triaging bugs in a complex application.

So feel free to poll for either or both features. I’d like to have them, plus a few others I’ve run into. (I’m greedy, I want them alllll! <cackles maniacally>)


You got it, @arlen_walker ! Fine with me to be greedy. I am sure others have bumped into this need as well—be sure to vote above!


Heh. Something I just noticed. I added something in angle brackets and it got edited out of my previous response. I’ll try to edit it back in.

There we go, that’s better.