It brings value in three places. One is code detection and resolution. You can pinpoint and identify where the issue lies within the application. 

The second thing is performance monitoring, which actually gives you performance in terms of actual signs. When a user logs into a particular website, what kind of performance that user actually sees, we can see that as well.

It also gives metrics. All that session data as well we get helps us come to know if a user was frustrated when using the site or if they were happy, or what the emotion was.

New Relic is an APM tool, similar to Dynatrace or Datadog. It uses an agent to discover metrics based on browser, mobile, and custom matrices. We can also develop synthetic monitoring. It has helped us in exploring the metrics.

It has helped my organization to dive deeper into the application using the APM module is very helpful. So when we're looking for problems of why an app is behaving incorrectly, we can dive deep into it using the APM module.

It was a good solution. My boss, who was a VP, was very happy with the system, and he didn't want to change the system because it was working well. Whenever anything went wrong, we got clear information about that on the fly. This information helped the operations team in sorting things faster. It gave clear information and a complete picture of what was happening in our system, which helped the operations team in performing the required actions.

There's another user on our team that sets up the list of servers that need to be monitored. You just click on those servers and then from there you can pull all the data, so that's really helpful. You don't have to go through a list of 500 servers. You click on one server, and it brings up ten servers that are in that environment. You don't have to choose those same ten every time. Instead, you just click on that one link. You just have to click on the name of the group you want to look at, and it'll pull metrics for those same ten or 15 servers each time. That's very helpful.

Not so far. Although, we haven't really got a very mature system of defining our application processes from end-to-end and certainly not our client-centric impact.

I'm reasonably satisfied. We haven't run the rule over it too much because it hasn't been a massive investment.

It has been quite valuable to demonstrate how we can change our views for our services due to their service. It has proved value so far.

It gives insights to non-technical people about what technical issues are most important, how much it impacts customers, and potentially, where we should be targeting our development teams when they have time.

• It visualizes metrics well and tracks our incoming requests, providing a lot of detail which is useful for troubleshooting. 
• It can track cross-application, knowing when you go from one application to another, like a request stop. 
• It's very visually appealing and useful.

We have been able to proactively identify failures before they happen. As an example of something in the last week, we had an instance where a volume was filling up on one of our VMs, so we set up a basic alert that if it got to a certain point, it would send me an email. This way, my support team or I could take some action on it and execute a run look. This has prevented failures from occurring in our production environment.

NewRelic provides a one-stop shop monitoring solution for organizations that are looking for 360 degree monitoring solution. Application, Infrastructure, Network, Database, Enduser monitoring, Mobile everything under one roof. Apart from that, as per Gartner Magic quadrant, NewRelic is among the top leaders.

We work in a small team in a startup with a lot of customers. From a customer to a software engineer was a one-step process, so tickets could come directly to me. I could go directly into New Relic to investigate what the customer was reporting and verify what they were saying. We can address those issues much faster with New Relic, which is brilliant. That changed things drastically for us.

Previously, we didn’t know what was broken. Now, New Relic tells us so we can prioritize what our teams work on. More importantly, it gives us the ammunition to go back to our product development team to convince them of the priority of fixing certain issues, which helps us prioritize our team’s activities.

Since we migrated from on-premise solution to the cloud (AWS), we have migrated somethings into Lambda API Gateway and DynamoDB. We have also done the New Relic integration with Serverless AWS, which has helped us with monitoring, and keeping our monitoring from our on-premise part with the cloud part.

It provides a single pane for operation teams to look at and get to the root cause of issues. This allows them to take the required corrective actions and to remove some of the blame game. People can only look at their own isolated metrics.

I can have my developers find bugs and fix them in one-tenth of time they used to take. It enables the stability of our product, and it's allowed me to keep human resources at a minimum so that we have a smaller number of people to do better things.

Every action we have certain attributes that we keep pushing data and we don’t have to worry about it. It captures everything, which we can send to executive management. We can put a feature out and see how people respond to it, and that can go into a release which will help make money for the company and add value for the customer.

First of all, it tells us loopholes in our system. The whole error-reporting thing lets us identify problems faster so we can take corrective action sooner. We can think about performance of certain code that’s been written, so we can take preventative actions.

It replicates testing, and we have a much higher level of functional and scripted testing across our application. We can execute test cases as they’re meant to be.

It makes my executives happy because it allows me to provide them with usage statistics. We have three types of users: customer, internal, and vendor. We can see who’s logged on, when, how long, what views they’re using, what data elements they’ve updated and how often, and which features of all reports that customers retrieve and use the most. And management knows who’s doing work and who’s not, and who's doing what they’re supposed to be doing.

It helps us troubleshoot issues quicker, and when we're using it for performance analysis, several items can boil to the top. We can look at what's going on and what's slow and causing problems, instead of looking in general at which queries or operations are causing slowness.

With the help of New Relic APM, we managed to deliver an online B2B application with average response times below two seconds, where with v6, the average response times was about 30 seconds.

Yes. However we dropped due to not able to achieve RoI due to high cost

Sometimes, I monitor the user's time of response and use this information to improve the number of servers on the back-end. Or, I can use it to change my back log for front-end developers and improve their response times. It's very important in this case because I can improve the experience of the final user.

The website is much more responsive because we are able to quickly pinpoint the worst pages – we can be really targeted with where we put our resources. In a lot of areas, one page takes one minute, the next can be ten, then some take one, some take 30 seconds. You have to decide at what point you want to focus, this allows us to find the pages that are really painful for users, and fix those and make them a lot better.

We can monitor our performance easily using the metrics, Apex, that New Relic have devised. This is a weighted number (0 to 1) which gives us a clear unobtrusive insight into our performance. Therefore, by leveraging the API, we can integrate the current performance metrics of our entire stack into our wall-boards and internal reporting.

Very simple, using server monitoring. I saw over a period of time our disk usage increase until some servers went into yellow alert (above 70%). Then we started working on this issue without a rush because we knew we had time, and instead of increasing the size of our servers and thus having extra cost, we managed to find how to reduce our storage footprint to fit within our current servers. Constantly seeing the green status of all my servers makes me sleep well at night.

I think that we didn’t have much insight into which things were causing the biggest performance hits, so it gave us instant feedback on incidents which may have caused users enough pain.

It gives us the ability to determine when and what we need to scale, instead of just chucking machines at layers and hoping it’s right. It all goes towards giving our customers the best experience possible.

Speed to issue resolution – making sure our stack is healthy. If someone reports an issue we’ll always go to New Relic first; that’s where it becomes a good product in and of itself. It gives us all the information we need in one place.

We have custom insights dashboards – massive screens with all this information aggregated.

The real benefits are for end users. They’re getting a better experience with our software. It allows us to respond faster to any incidences.

Being able to quickly figure out the root causes of issues. It also makes it very easy to share that information with developers and other people within engineering – we can drill down in parallel.

It helps us keep our customers happy, that’s the bottom line. When it responds the way they expect, they’re happy.

We've been able to automate a lot of our interactions with it. Also, it has the ability to monitor random URLs not tied to the one pinger per application (though it costs extra).

The biggest thing is being able to give our customers a world-class experience. As we’re in media, this means things like hockey results, election results, favorite TV shows, etc. We’re able to cover all our bases to make sure our customers get what they love.

We are now able to quickly identify how our product behaves in production. Before New Relic APM, we would push a build, and try to dig through a plethora of information (event logs, error messages, customer feedback, etc) to find problem spots. Instead, we now publish and can see all the key stats (apdex, response time, error rate, etc.) and quickly drill into what’s causing an issue.

It has given us better insight into the performance of the system, allowing us to prepare things, if necessary. It has been helpful to patch things before they are a problem.

We are a web development agency, focused on Drupal CMS. As New Relic is already integrated with Drupal, we can get our projects done with best practice and with the best value that we believe in. New Relic provides deep analysis for data and server health so it lets us know of network bottlenecks before we deliver the project to enhance our product. Therefore, we can be sure that we deliver the best value for our customers.

Short turn-time to resolution is essential. It’s the flashlight to the core of an issue in a production environment that everyone may have missed in development, QA, and implementation.

So basically it allows the business to more efficiently spend its money rather than in QA. The faster you can identify these question marks and find answers, the faster we can solve the problem, and the quicker we can solve the problem. We can focus on net new value.

New Relic helped us in realizing that sometimes our online service wasn't as fast and reliable as we expected it to be. With the help of New Relic tools, our organization was able to detect, track, and fix errors in our website, so we focused our efforts in these areas.

We monitor the Internet daily, or every few days. Then, every time there is a crisis, high traffic, or if we see a problem with a server, we go to New Relic and monitor it to determine the cause.

It enables us to fine-tune our application quicker. It's also better if we find issues in our application than if our customers find it.

It also prevents performance issues because we're able to see potential issues before they cause real problems.

Helped us understand that we had a professional group of our users that we didn’t even know about.

It identified mechanized behavior (e.g. bots) and then blocked them.

We detect issues using dashboards that we built on New Relic. For example, if our drivers are taking too long to get rides, we usually detect the problem using New Relic dashboards.

We are concerned about our application's print and load times. It should be faster for the end user's experience. New Relic has helped us in terms of the optimizing our print and loading times.

It has solved many of our performance issues.

It has helped us maintain a much higher uptime than we had previously.

It fulfills the need that we had for the product.

The New Relic toolset has become part of our SDLC -- reviewing the changes we made for impact to the production environment. It's been a valuable asset to identify areas for improvement in our application.

It comes in as part of the regular process for every application roll-out. We have a standard visibility process for any application that rolls out. It gives us the ability to train our people and provide a more responsive application. We used to have many tools with many different functions, and now APM allows us to consolidate a lot of it.

We get greater insight into what our application is doing once it’s in production. We can identify issues faster, and being able to identify issues before they become a big problems is an improvement. We use it in load testing to identify inefficient query patterns.

The best thing is that the team has grown, and a lot of people are developing the code, but you tend to have regressions that are clearly visible in those transaction traces.

When there’s a deployment, it shows by graphing if a regression has happened, and it allows us to react. Catching regressions in performance is very important, and since we now see the breakdown in every single layer in the application, you know right away if there’s something you’re not expecting. We can then go and figure out if it’s an infrastructure or code issue. It gives you a high level view of all of the requests coming in. Error rates are a good indicator for potential rollbacks for a potential deployment – and usually it’s pretty instantaneous. At the end of the day as users, we get what we want.

We found the following benefits after installing New Relic:

a) Ability to pin-point the exact module/service creating issues.

b) Lightening fast issue identification since there is no need to go through gigabytes of log files and, since we have a number of servers in our cluster, it isn't even feasible to check each and every server.

c) Access to web page load-time, size, and error tracking, vital for a e-commerce.

New Relic has changed the way we are dealing with application problems. It's the first place for our administrators to check if we encounter issues. In most cases, New Relic can immediately pinpoint the root cause of the issue, be it application errors, slow transactions, external services, database throughput or high transaction count. New Relic can monitor thresholds and alert if required. We are also using New Relic to help understand performance tests and bottlenecks.

Early in our app lifecycle we would receive random reports of slow response times from users. Of course, they were never reproducible in our QA environments nor did our OS-specific monitoring tools show any problems. Implementing the APM with our app servers gave us visibility into what our Java code and JVMs were doing at the time users had problems. This allowed us to zero in on infrastructure and code issues as well as implement monitoring cases specific to our app.

We can monitor response times, volume, and Apdex. Our alerting is based on Apdex. It's a great sanity check. It's helped us to find problems early and to make sure that what we're doing is working.

I'm on a small team and have an interaction with the Ops teams only when a negative happens, but I've used it a couple of times to pass problems from my plate to someone else's as I've proved it's not my problem.

It allows us to monitor in our little part of the company, but it plays a role in the larger functioning of the company because we have our hand in so many areas.

We can get a complete and detailed view of each component of our product and focus immediately on performance issues, or give priority to the code/component we want to optimize.

Also, with the reporting/alerting and SLA feature we can generate reports to see the average response on days/weeks/months.

Lastly, it can help us compare between days, so we can see the impact of a deployment of new code on performance.

You can immediately see if there is some slowness. It can also alert you, and you can fix the problem pretty soon. In pre-production, you can ensure that everything is okay, and you don't put the worst performance to production. The performance should at least be at the same level as before.

As soon as it monitors all our systems and is integrated with PagerDuty, the operations team just needs to wait for alerts on their cellphones to fix things.

We’re able to see how deployments are affecting the application, both good and bad. APM surely shows us the change in behavior. It lets us know how our application is doing. A lot of our information comes from trouble tickets, and we can correlate back to APM to see what’s going. It’s not so accurate, but it has to do with the data integration, but New Relic has said that it’ll give more data points and real-time data.

We have both Ops and Tech Leads subscribed to the alerts now. In general the Ops team only responds to "server down" or other infrastructure issues, whereas the Tech Leads will become interested if errors are being thrown or the Apdex scores are affected. They then have the chance to observe the system during an issue, as well as grab stack dumps and thread traces that allow us to quickly identify issues that are hard or impossible to replicate in a test environment.

It allows the Ops teams to better cooperate with the DEV teams. Essential in a devops culture is that the different role within a devops team use the same metrics and data. NR provides some of this data and input.

It’s been helpful to get a unified understanding of how our application is being used, usage patterns, etc. We get a shared organizational understanding.

As a QA manager, it helps me to know exactly where to focus our attentions because we can pinpoint specifically where there may be issues -- where geographically, which browsers, which browser versions, and other very granular details.

Mean time to recovery has improved, leading to cost savings and reduced customer dissatisfaction.

We can make sure sites are up and running and that they’re performing normally. If we see any spikes we can troubleshoot – if they’re in house or in the cloud. Sometimes we can get to the systems faster because of the insights.

Makes it a lot easier to troubleshoot application issues.

New Relic gave us a quick, easy way to monitor our web application for all of our systems. This changed how and what we responded to.

We’re able to deploy very quickly, not concerning ourselves with every single issue. In production we can address every issue.

We’re able to address events immediately. We have very good uptime and customer retention. So it’s all about giving them the best customer experience. It gives us a good digest of how the system is behaving and being able to diagnose any issues.

It saves time and engineering resources in terms of making things faster and diagnoses problems. For us, engineering uses it but no one else even knows what it is. Overall, it improves the experience of the customers and site users.

It just gives us an idea for how fast were running. That cuts down to it -- how fast we're running, and if there is slowness, where it's coming from. It's really fast at telling us.

On a regular basis, we're able to identify incorrectly optimized SQL queries, external machine bottlenecks (i.e. higher throughput than can be handled), and other low performance issues.

Helped us pin point the exact piece causing the performance bottleneck by using the transaction trace view.

We can analyse events after the event has occurred. This gives us better visibility to plan resolutions in a timely fashion.

Its greatest benefit comes from its ability to provide trending/marketing data. We can replace some requests from our data warehouse and get a quick glimpse into that data, especially with our mobile platform and website for different browsers.

Before New Relic, dev and ops were separate, and now they’ve come together more and there’s less finger-pointing. There’s a clear understanding of where the problems are and so the people responsible can solve the issues. There’s more trust between the two groups and people are more willing to work together.

When an app goes down, we can get insights into the issue with New Relic. It tells us what the problem is. For example, if there is an issue in the code, we see a spike in the error rate in the applications. The load environment lets us stress test our application to find the bottlenecks in the code.

In one case, a developer had an end-user report a recurring issue with a web application after a new release. I was able to use New Relic to find the error and provide the developer with the exact line of code that was causing the error within minutes of the issues being reported.

New Relic has detailed analysis of various parameters such as Web Server, Database server, Application Server etc. so we were able to provide the client with more productive reports.

The browser functionality gives view activity on the client, JS errors, in the same view as the rest of the APM allows us to solve these things quickly.

We use it at our clients' sites. We own all our dev servers, and then hand them off to our clients. 

Then, with our micro-services, we have basic analytics. It is super simple to set up.

This product had actually helped us in identifying peak load hours and system response to such situations. Also on Local system if we have upgraded or downgraded any API, this tool has actually given data facts in response time & that is very important.

It gives us useful insights for end-users and gives more information which led us to drive the future strategy for the application for business units.

The solution makes it very easy to have a holistic view.

Tracking and monitoring production is mandatory, however, we did it for years only for the back-end side. As the client-side applications grow bigger and get more complex more responsibility gets to the client. Because of that we must be able to understand if our clients are "healthy". The term "healthy" is not clear to what it means. 

Presently we report data to New Relic Insights, and we've built some really readable and understandable graphs. We monitor with those graphs every deploy to production, and we are advising the graphs to resolve current problems with our application, like errors and problems with the load and response times.

In the past, we had to look at server metrics such as CPU and the number of connections. With APM, we can see much more about what it's doing. It's helped with a lot of troubleshooting of performance issues. It's also helped with code problems, where we deploy something and it's performing slowly. It helps us see the problem in the web app, database, rendering, etc.

From an ops standpoint, we can know and pinpoint what the problem is. We're excited by down-to-the-server performance, as this was missing before.

It was the first tool our company used for application level monitoring. It doesn't require much investment or technical expertise to implement, and I would recommend it for SME.

This tool has really helped us in monitoring our production apps and also to diagnose the errors coming in using APM and synthetics modules.

Reduced the worry in supporting live websites.

We are able to detect errors in the software.

I could spend less time verifying code and check for performance. I created accounts for my devs and integrated this into the KPI’s and also the test process. This in turn reduces the amount of money we were spending on our servers. The database performance was something we were able to greatly improve.

We have an operations center which uses it quite extensively to manage production. They can go back and look at trending and history of the applications. They have alerts set up which trigger off of it. 

I go in afterwards and help do the root cause analysis and troubleshooting.

• Debugging response time is less
• Alert notifications and alert summaries

It gives us enough knowledge to know where to improve things on the database side, or to make improvements in the application logic.

Troubleshooting and identifying problems since were a cloud based solution. It captures the issue so we don’t have to reproduce the issue, as it saves us that step and from having to RDP into the machine. Helps us identify flaws in the code, ex. A very that was inefficient in the code we identified

Identifies bottlenecks in applications, the servers and the network.

New Relic is now the leader in efficiency improvement. We are able to configure our own specific dashboards so that we can monitor the things which we want to monitor. 

Some of the parameters in our deployment, which we already know and we want to monitor constantly, can be selected on our own custom dashboard.

The data visualization is easy to read. Better yet, it's easy to show other people the visualizations.

If something goes bad, we can resolve it faster and in the proper way, rather than spending a lot of time just trying to understand what’s going on. We can see easily what’s working and not, so there’s less downtime.

We used to get lots of complaints from clients on app slowness. Using New Relic we are able to solve the slowness issues based on traffic and server response metrics.

Both developers and operations people can look at the same data, and that’s a great benefit. Operations can monitor, as they’re also in charge of the website, and developers can use it to see code changes.

We all look at the data, so we are all privy to the data at the same time. Before, we only had siloed views that provided limited data.

It's given us the ability for anyone to know how our customers experience our application.

It helps me to identify root cause on the code level issues.