A couple of months ago, I had some downtime at work, so I tasked myself with one of my goals for the year: implement error tracking for our JavaScript applications. It’s a bit crazy to think we weren’t monitoring our front end apps until now. Especially considering our stack is heavily comprised of a bunch of SOA-style Angular and Spine apps. But we’ve managed to do alright; and technically we did have New Relic passively keeping tabs on browser errors site-wide. However, it was about time we started paying serious attention to the nitty gritty errors thrown out in the wild.

Goals

Starting out, I didn’t exactly establish a set of clearly defined goals. Overall, I just wanted to find a good service to report exceptions that might come up across the various browsers and devices we support. Roughly speaking, here’s a list of what the service should be able to do for us:

It should provide a flexible JavaScript reporting client. We want to be able to control what exceptions we report on, as well as how we report on them.

We want to be able to control what exceptions we report on, as well as how we report on them. It should provide us with enough information to reproduce errors to help resolve them. Obviously, we want the typical reporting information: stack traces, browser/OS versions, frequency, etc. But related to the first point, we also want to be able to provide extra information ourselves through the reporting client, such as AJAX params, member information, or other environment variables.

Obviously, we want the typical reporting information: stack traces, browser/OS versions, frequency, etc. But related to the first point, we also want to be able to provide extra information ourselves through the reporting client, such as AJAX params, member information, or other environment variables. (It should help us achieve and maintain zero errors.) We have this policy for server-side exceptions, where we try to maintain zero errors and only report on important ones. This way, we can be sure that any error we’re notified of is something we need to stop and address ASAP. I naively set out to shoot for the same policy for JavaScript monitoring, but I quickly found out this was impossible.

Options

There’s a ton of tools out there for error monitoring, and I’m sure most of them would suit our needs described above. I didn’t want to get too caught up in trying out a bunch of different services, so here are the four options I considered:

New Relic . We’ve been using New Relic since I’ve started working here to monitor our app ecosystem’s general health, and it’s fantastic. I think it was sometime last year when they announced New Relic Browser, their monitoring service for the front end. The AJAX insights are where this service really shines, but the error reporting aspect of it didn’t give us enough flexibility (there was no reporting client available).

. We’ve been using New Relic since I’ve started working here to monitor our app ecosystem’s general health, and it’s fantastic. I think it was sometime last year when they announced New Relic Browser, their monitoring service for the front end. The AJAX insights are where this service really shines, but the error reporting aspect of it didn’t give us enough flexibility (there was no reporting client available). Honeybadger . Our back end Rails apps reported exceptions to Honeybadger, and it was pretty good overall. I did try using HB for one of our front end libraries, but it ended up being too noisy since it hooked into window.onerror without filtering anything out.

. Our back end Rails apps reported exceptions to Honeybadger, and it was pretty good overall. I did try using HB for one of our front end libraries, but it ended up being too noisy since it hooked into window.onerror without filtering anything out. TrackJS . This service looked really promising. It had a flexible reporting client, a beautiful dashboard, and an exciting feature called Telemetry Timeline, which provided context of the events leading up to the thrown exception. I tried it out for a week and— at least for the errors captured during that time— it didn’t seem to do a great job aggregating similar errors, the Telemetry Timeline wasn’t very useful, and it was quite noisy. In hindsight, I probably should have given it more time in production. With a bit of playing around, it may have turned out to be a nice solution to our problem.

. This service looked really promising. It had a flexible reporting client, a beautiful dashboard, and an exciting feature called Telemetry Timeline, which provided context of the events leading up to the thrown exception. I tried it out for a week and— at least for the errors captured during that time— it didn’t seem to do a great job aggregating similar errors, the Telemetry Timeline wasn’t very useful, and it was quite noisy. In hindsight, I probably should have given it more time in production. With a bit of playing around, it may have turned out to be a nice solution to our problem. Sentry. Recommended by our DevOps lead, Sentry held as much promise as TrackJS. It provided flexible reporting clients for a number of platforms (JavaScript, Ruby, Python, to name a few), it had a good-looking dashboard, and it was open source! It was still noisy, but it seemed to aggregate similar errors better in my opinion.

The Winner: Sentry

Sentry was the last service I tried, and it stuck. There’s a bunch of reasons why I liked it the most. I’ll boil it down to three.

First and foremost, the dashboard did the best job surfacing the most important errors using its Priority sort, which is a weighted score of the time of the last seen instance of an error and its frequency. Both its list views and detail views provide us with the information we care about most, in the simplest, most concise manner out of the group. Minimal clutter, maximum readability.

Secondly, it has a bunch of core and community driven integrations with other services. For us, it allows us to hook into HipChat for channel notifications and JIRA to create tickets. In addition to these integrations, Sentry allows us to create notification rules— i.e. we only want a HipChat notification the first time an error is seen, and only if it’s hit a threshold of x events reported in a given minute.

Lastly, it’s open source and supports a variety of platforms. With the source code up on GitHub, we could actually run our own Sentry server if we ever have the need to. The paid options are good enough that we’ll probably stick with it. Regardless, we still get the benefit of community driven improvements and bug fixes. The multi-platform support turned out to be an unexpected benefit, since we ended up moving all of our server-side apps to report to Sentry as well.