Why do we use TrackJS

Why and how we use TrackJS at RightScale to capture JavaScript errors.

JavaScript debugging, the state problem

As many JavaScript developers know, tracking live production errors can be very challenging. The reason is that regular log and error gathering systems, like Errbit and Airbrake, are designed to deal with RESTful APIs which are by definition stateless (at least mostly stateless, many practical webapps violate REST and include a small amount of state). On the other hand SPAs (Single Page Applications) have an immense amount of state and all modern JavaScript frameworks exist to tackle the problem of this expansive state-space.

As a rule, UI errors that end up in production only manifest themselves in a small portion of this vast state-space and tools that are designed only to capture the request (i.e. url, url params, env variables, etc which is what Errbit and similar tools do) fail to come up with reproducible error information. Hence the frustration of front-end engineers having to close almost every single error captured in conventional systems as “cannot reproduce”.

TrackJS to the rescue

Telemetry timeline

The power of TrackJS resides on its Telemetry timeline view:

This timeline shows the chain of events that led to the error. With it it’s possible to understand, at least partially, what sort of state the UI could have been in when the error occurred.

Error statistics

TrackJS gathers and computes these valuable statistics:


Frequently the JavaScript files are minified into one huge line:

Thanks to using sourcemaps, TrackJS can de-minify the sourcecode and, finally, the error is no longer always in line 1:

TrackJS automatically loads sourcemaps and applies them to error stack traces for you (The red dot above the Stack Trace tab appears when a sourcemap was found and automatically applied).


TrackJS allow us to define several applications to gather the errors. The key that we use to authenticate and send the error to the server is also tied to an application so errors go directly to their corresponding applications.

Almost every screen in TrackJS can be filtered by the dropdown box that allows us to select which application we want to display (we can also select ALL to see all applications):

While this feature is very useful, we miss a bit more granularity: it would be very interesting to be able to define environments inside applications (or have the usual ones predefined: development, staging, integration and production). Currently we have to create a different app for every environment (“App1 - Staging”, “App1 - Production”, …) but then we can’t view and get statistics of all the environment errors for an application together.


TrackJS Slack notification

TrackJS also provides us several mechanisms to be notified when errors happen like the classic email notification. It is also possible to set up notifications that will be delivered directly into our chat system via the corresponding integrations, like Slack notifications.

We also have the fully customizable option of defining our own webhook endpoint to receive a JSON with the information of the error.

TrackJS email notification

Finally, we can set up to receive a daily email with a summary of the errors from the previous day.

Again, in the notification area we miss a more fine-grained set up of notifications per app. TrackJS allow us to select, for each application, if it should send notifications and be accounted for the daily statistics email, but all selected applications will share the same configuration, so we don’t have the option to specify different Slack channels to receive notifications depending on the application, or different daily emails with different sets of applications.

TrackJS UI shows that the notifications tab is in “Beta” state, so hopefully soon we will see improvements in this area.


At RightScale, TrackJS has become an indispensable tool for capturing and debugging JavaScript errors.

Thanks to features like the “Telemetry Timeline” and use of sourcemaps, understanding and fixing JavaScript bugs has become a much easier and less time consuming task, optimising the time of our developers so, instead of spending so much time debugging obscure errors, they have more time developing new features for our clients.