Fixing a Simple JS Error with New Relic Browser

As a front-end developer, my favorite tools are invaluable to me. I spend countless hours in Chrome’s DevTools; validating that markup is as I expect it, identifying errors in JavaScript, and tweaking CSS to get just the right visual. Now that my team has launched New Relic Browser, I have another set of tools I not only love to use, but can also be proud of as a developer.

In many ways, by helping build Browser I’ve made my own front-end work easier. Here I’ll share a quick example that encapsulates why I love our Browser tools, and why you might love them, too. It all started with a JavaScript error on an embeddable widget that I wasn’t even working on.

While looking at Browser’s JS Errors for that widget page, I found an error that was occurring in over 1K page views per week, despite being a common JavaScript problem with a known solution. So how did that get there in the first place? First, I needed to know when this error started popping up. I clicked the error and was giving a graph of its frequency over time. By moving the time window backwards, I was able to find that it had started recently, and it gave me a reference time for the code change that caused it.

error_rate

With the ‘when’ in hand, I needed to know the ‘where’. For this, I turned to the Error Instance Details of the error. It provided me with helpful context — in this case, the controller and action of the Rails application. For more complex errors, the stack trace can also be invaluable.

error_instance

Next, I visited the action in local development and was able to reproduce the error. Looking at the code for that action, I found that it used a different layout file than most of the site. This layout file was missing an include of some JavaScript files, which ended up being the root cause.

local_error

I was also able to look at the revision log for the file, and see that it had last been edited in the timeframe that the problem started happening. I added the needed JavaScript and checked that it corrected the error locally. Finally, I committed the fix and shepherded it through our review and release process. With the fix released to production, I got to watch the same error frequency chart that helped me to find the error in the first place as it showed the error drop to zero. Triumph.

error_dropoff

In the end, New Relic Browser helped me fix a JavaScript error that I wouldn’t have encountered on my own, yet was effecting our customers. I felt pretty self-congratulatory that day – there’s nothing quite like finding out the product you’ve helped to build actually is useful, firsthand.

Think your site is free of JavaScript errors? Try New Relic Browser free of charge (for a limited time) to learn what your customers’ experience is like, from their perspective.

eric@newrelic.com'

I am a Software Engineer in Portland, OR with a Masters of Engineering in Computer Science from Oregon State University. I'm a big supporter of Open Source, and have published almost all the code I've written to GitHub. I'm also an avid tea drinker, bake (scones, cookies, coffee cake, etc), and enjoy riding my Segway. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!