The Fine Art of JavaScript Error Tracking

Goals

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

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

Things I Learned

Signal vs. Noise

https://www.youtube.com/watch?v=e4eE5VeO1_o

The State of Stack Traces

How We Use Sentry

Reporting

https://gist.github.com/jico/e4d14ae301ed93132823

Identification

It’s Not Over

--

--

--

Developer. Writer in moderation.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jico Baligod

Jico Baligod

Developer. Writer in moderation.

More from Medium

Frontend Versus backend for dummies

Web Dev Lesson 1! Learning Where to Look

The Dangers and Differences of JavaScript .innerHTML, .innerText, and .textContent

Week 1: Foundations — WebDev