It had not occurred to me that we should be recording our client side errors until I was listening to a talk given by Paul Irish at fluent 2012, and he mentioned a tool called errorception. This got me thinking, how many client side errors are our users really encountering? Could this explain some of the ‘loch ness’ bugs we have? How well do we support different browsers?
I therefore thought it would be a good idea to at least trial a client side error tracking service and found there was a rather long list of possible options. After a little research I settled on trialing errorception because it made a very strong point of not compromising the performance of your site, and frankly it was recommended. However, keep an eye out for the new kid on the block called trackjs, which has taken a different approach and might be worth checking once its up and running (currently in testing).
I signed up to errorception on a trial basis allowing me to record 100 errors a day for 30 days. This required no credit card details or obligation, and gave access to the complete offering.
The setup process for errorception could not have been more simple! Once you have signed up a unique script tag is displayed, you simply have to paste this into the head tag of your site and you are done.
This script tag will send an error report to the errorception server by monitoring the ‘onerror’ event.
So it is clear from the setup that errorception is responsible for recording and managing the errors on your site. Once you have logged in to the site you have three main areas; Errors, Graphs and Settings.
The error screen neatly groups and lists the errors that have occurred on all of your sites by relevance or frequency. This can then be further filtered to your hearts content. Each error is self titled detailing the URL where it occurred, the browser that was being used, the number of occurrences and a little graph displaying change over time.
The detailed view gives you a more comprehensive view of the error, with the ability to close an error once it has been fixed or ignore it if you have fixed it but are yet to deploy into production. More details are available on where the error occurred by clicking the line number:
The graphing capabilities are very browser focused. Although very useful I would like to see the data cut in other ways, such as errors by URL/Domain.
There are three key settings of note; Posting Errors, User Accounts and Service Hooks. Posting Errors allow you to set a list of allowed domains and ignored scripts, both essential functionality. User Accounts allow you to add multiple users to monitor the project, neatly sending them an email invite. Finally the Service Hook area allows you to link up with services such as ‘Loggly’ or ‘Flowdock’.
I can see us using this service to proactively remove errors that users do not report, as well as using it to track down issues reported by users. There are however some small enhancements that would really make the service even more powerful:
- The ability to comment on errors and assign them to users, or the ability to export an errors details to PDF.
- More URL focused graphing/grouping to help identify error hotspots in your software.