Error Monitoring in Action

Dealing with errors and crashes, both while developing your application, and worse, in production, are an everyday occurrence for application developers. We are used to needing to troubleshoot problems, as it is a part of every development position imaginable. While developing and testing locally, we can often take advantage of our own developer tools and logs, but when users begin reporting errors, we need something more.

Raygun Error Monitoring makes troubleshooting easier and can save you hours in the debugging process. It will constantly pull error data from your application, and feed it into an easy-to-digest report. We will be able to see how many unique users have experienced the issue, on what pages, with what browsers, and at what times. You will be able to assign the error to a user on your account, and track comments and progress in resolving it.

Additionally, if you use bundled JavaScript in your application, you can upload source maps and break the stack trace into intelligible pieces, so that you can quickly find the root of an error in the actual files it was caused by.

In this article, we will dive in and make sure we are able to set up an application, configure Crash Reporting, and start using it to locate errors that your users encounter. We’ll be using an open source demo React application, available for anyone to check out and follow along with, if so desired.

We will look at several different configuration and error reporting scenarios and try to ensure that we are prepared to meet any such challenges that we encounter with a production site in the wild.

Set Up Our Test Application

First and foremost, we’ll need to get our test application set up. We will be using the RealWorld demo application today, which can be found on GitHub.

You can log into your development server and just clone the repository, like so:

git clone https://github.com/gothinkster/react-redux-realworld-example-app.git

Once you have the application downloaded, you can run npm install to install all of RealWorld’s required dependencies, and then npm start to start your development server. This application will draw from a publicly available backend that is periodically erased, giving us test data to start out with immediately. In later tutorials, we may replace that backend with one of our own, but for now, let’s keep the default. For purposes of testing with Raygun, instead of using a development build, we can also launch in production mode, to mimic the troubleshooting endeavors on a production site. Instead of npm start, simply:

npm run build
serve -s build

Note that if you choose to serve a production build, when you make changes to your application code you will need to create a new build and serve it, rather than the automatic updating that the development server will do. Using static production builds can be helpful, though, when dealing with source mapping in Raygun, a topic we will discuss in more depth later.

Once served, the app should look something like the following:

Connect to Raygun

Go to your Raygun dashboard and create an application. You can choose React as the technology, and will be given code snippets to place on your site, connecting it to Raygun’s monitoring.

<script type="text/javascript">
     !function(a,b,c,d,e,f,g,h){a.RaygunObject=e,a[e]=a[e]||function(){
     (a[e].o=a[e].o||[]).push(arguments)},f=b.createElement(c),g=b.getElementsByTagName(c)[0],
     f.async=1,f.src=d,g.parentNode.insertBefore(f,g),h=a.onerror,a.onerror=function(b,c,d,f,g){
     h&&h(b,c,d,f,g),g||(g=new Error(b)),a[e].q=a[e].q||[],a[e].q.push({
     e:g})}}(window,document,"script","//cdn.raygun.io/raygun4js/raygun.min.js","rg4js");
   </script>

Call the Raygun script, providing it with your application’s key, and set enableCrashReporting and enablePulse to true.

<script type="text/javascript">
     rg4js('apiKey', 'kFetsl3D7yDDqE3yM0cNGn');
     rg4js('enableCrashReporting', true);
     rg4js('enablePulse', true);
   </script>

You can put this in your index, just before the close of the body tags.

Reporting on routing events can be different in React than in traditional web apps. If you would like to learn about enhancing the reporting on React apps, read this post on Enhanced integration between Raygun4JS and React.

Crash Reporting Scenario 1

Once everything is connected, we should be able to see application errors in Raygun. To test this, let’s induce an error.

Here, we’ve opened the App.js file and popped down to line 48, and turned this.props.onLoad() to this.prop.onLoad(). Just one letter difference, it’ll be enough to prompt an error and let us look at how Crash Reporting works. Take a look at Raygun. When you open the Crash Reporting tab, you’ll be presented with a list. Click your error in the list (presumably the only one) and you’ll see a report like this one:

In our example, the very first message tells us where to look. In App.js, at line 48, we see that "undefined is not an object" while evaluating "this.prop.onLoad". Experience tells us that this syntax is wrong, that a character is missing, but even if it did not, you know now exactly where to start your investigation.

Source Mapping

If your report is a stack trace with a bunch of references to your bundled JavaScript, never fear. This only means that Raygun could not immediately find the right way to map your bundled JavaScript and take it apart to assist with troubleshooting. If this happens, head over in the sidebar to "Application Settings", and then "JS source map center". Here, you can upload your compiled JS and map (in this demo, found at build/static/js).

Upload both the .js file and the .map. Once this is done, head back to the crash reporting screen and click the button to re-map. If this doesn’t work, wait a few moments, refresh the page, and try again. Now, the uselessly obfuscated stack trace is broken into very specific messages.

Crash Reporting Scenario 2

Now that we’ve used Raygun’s Crash Reporting to solve one problem, and also learned about Raygun’s source mapping features, let’s analyze one more situation.

The Banner.js component takes two inputs, appName and token. Inside of our component, the state of token is checked - if it is defined, there is an outcome, and then there is a default outcome if it isn’t. The appName, however, is just used, and expected to have value. Let’s create a scenario in which the value of the appName received by Banner.js is in fact null. We will do that by simply re-defining it as null just inside the function.

The un-conditional display of appName as the home page’s H1 now causes an app crash. Perfect! Let’s take a look at Raygun.

Again, when properly source mapped, the error reported here is as crystal clear as can be. When we read that null is not an object, while evaluating the toLowerCase statement, and are given a file and line number, we immediately know what’s happening. Somewhere, somehow, appName is being set to null. Now we can start back-tracing it to where the value is supposed to be sourced and check it.

Additionally, this would be the place where we might prefer to check that appName has a value, and default the H1 tag to some standard value in the event that appName ever comes up empty.

Crash Reporting Sidebar

While we are investigating this error, or the one before, pay attention to the incredibly useful sidebar that has been set up as part of the Crash Reporting feature set.

Here, we will be able to find a whole bunch of information about our error occurrence. First, the state of the error - it is currently Active, but can also be Resolved or Ignored. It can be assigned to a particular member of our Raygun account.

There is also a way to view the set of users who have experienced this error, as well as a timeline of when the issue was originally experienced compared to the latest instance of it. Lastly, we also have details about the browser that the user(s) were using.

Conclusion

Raygun Error Monitoring offers the automatic tracking of errors experienced by users, correlation between the users who experience them, time stamps, stack traces, and more. Couple this feature with the custom source mapping for bundled apps, and you’re looking at an incredibly powerful and flexible solution to the errors that pop up here and there in your production websites, or even while developing. You can also take this further and include an entire user journey and performance story that led to an error if you pair Crash Reporting with Raygun's Customer Experience Monitoring functionality.

With plans starting at just $4 per month, Raygun Error Monitoring is a cost-effective way of gaining visibility into the crashes and errors. Sign up for a free 14-day trial today.