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
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.
TrackJS gathers and computes these valuable statistics:
- A visual timeline with the occurrences of the errors. This can help us correlate the error with other events we have had in our platform.
- Statistics about the browsers where the error has happened, which can help us discover if it only happens in some of them.
- Other useful information like the OS of the client, and custom information we want to provide like user IDs.
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 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.
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.