While I appreciate a need for "Error Logging as a Service", I really wish all of these kind of tools were open and could configured for logging back to our own servers without needing to access anything else in the "cloud". Building LoB web apps that are often accessed from heavily firewalled networks makes these tools, unfortunately, useless.
Easy to deploy internally. Python server, client libs for basically everything, plugins to chat apps, issue trackers, you name it: https://github.com/getsentry/sentry
I'm a fan of Sentry, and their hosted service is very affordable. The fact you can push data to it on your own terms is great. I use it in combination with Logstash as an output, so any logged errors reaching Logstash are automatically piped to Sentry.
As a bonus, should you wind up deploying Sentry internally, you need only update the API host in Logstash.
We use Sentry a lot at Justcoin. Frontend, backend, workers, everywhere. It doesn't look great and their support is a bit slow at times, but it works and is affordable for startups.
Do you need open source or are you OK running something proprietary? If the latter is an option, Rollbar (https://rollbar.com) can be deployed on-premise.
This is aweesome! I've played around with the idea of building something like this in the past, and have always shied away because of the complexity. Well done - it looks super useful.
One minor critique: Can you refer to yourself as "track.js" or "TrackJS" instead of {Track.js}? You're going to drive me nuts if I have to type curly braces every time I mention you somewhere.
Saw their presentation at Iowa Code Camp last year and I was really impressed.
Unfortunately, at the time, they had no plans to support source maps. We exclusively use minified JavaScript in production. Seems like not getting a proper line number or filename in a stack trace would be a huge hindrance to debugging.
We are working on getting it back up ASAP, in the meantime you can also check out http://trackjs.com which is just static files. (The blog is of course wordpress)
(Edit: After kicking MySql things should be back - also, the rest of our application does not use MySQL :))
Paul Irish has a list of alternatives at https://plus.google.com/+PaulIrish/posts/12BVL5exFJn, but I really don't think any of them compare to this (TrackJS). So while I think everyone should be doing client-side reporting and evaluating all the options, I suspect TrackJS just brought this to another level (think awstats vs Google Analytics)
1) The performance impact should be functionally negligible. We do instrument a few of the lower level base JS objects but it's all very lightweight. We have not noticed any performance issues thus far. That said, we have some new features coming and we will make anything potentially performance impacting opt-in
2) the buffer of events is currently the latest 10 events from the console, network, and user interaction, for a total of 30. We are looking at modifying this.
3) You can certainly bundle our script, we use the same technique Google Analytics does to capture hits.
4) Nothing, although we currently don't have hard caps and would certainly be in communication with you if you were concerned that was happening!
I can speak to the performance issues. I use this on a very javascript laden website, and I've noticed absolutely zero performance hits as a result of running.
Your script name is tracker.js which is not the best name as adblockers/privacy blockers simply block any names with the word track and many other similar names.
If you name your script something else that is not blocked it would enable it to run, and be valuable to see the errors that users get when they block other js on a page.
I searched trackjs.com for minify or minified or "source map" and nothing comes up.
So my question will Trackjs work with Javascript code output by Google's Closure Compiler? I have tried Tracekit in the past and other similar Saas services for client javascript error logging and nothing seems to work with minified source produced by Closure compiler. Unfortunately, I can't do without Closure compiler and minification.
Rollbar.com works very well with minified JS from closure compiler. I have that setup in production. Also I find Rollbar does a better job of lumping errors together so that you can more easily scan for new errors. There is a lot of noise in JS errors and the grouping algo is just as important as each error's actual report.
We have used Track.js for many months to track JS errors in our production application and it is truly key to helping me and our CTO be aware of any client-facing issues that exist, recreate/fix those issues, and sleep well at night. I also know the founders personally and they are extremely skilled developers with deep expertise in Javascript and the DOM and I have no doubt they will continue to innovate and give us even more bang for our already well-worth-it buck
We've always had high demand for Javascript error reporting. We've been slowly building out a new notifier which address the importance of page load and capturing errors without blocking the page load. https://github.com/airbrake/airbrake-js
One of the main problems is clients / IE, not only on how they throw errors but also standards of source-map support and standardisation of how errors should be handled.
I welcome trackjs and all over javascript errors to come together to help make it better for all developers. I'm not sure on actions yet but NewRelic has started to do great work in the Node space already.
@ToddGardner! We wish you the best of luck, the app looks great.
Last time I tried to run airbrake-js, the airbrake script itself was throwing errors in IE8. The github repo says nothing of browser support. Would love to know if this is still the case.
I applaud this effort and it is a step in the right direction for JS app error tracking, but it is a half-measure: we need to get to the point where frontend frameworks track this by default, post back to a common server endpoint, and then that error report is emailed to the dev/admin list
That does not make any sense. I don't expect Angular, for example, to tell me when I have a syntax error. Also, things are rarely so clean in browser-land, anyway. Just because you have a framework doesn't mean there's not another parallel framework on a page, or plugins that don't need a framework, etc.
I've been waiting for the kick in the pants to finally add js error tracking.
This looks great. At my previous company, I set up Errorception (https://errorception.com/) and it was a good step, but I'm excited by the production-side logging possibilities that track js offers, and the timeline feature.
I've just now added it to my current company (https://zoomforth.com), and would be happy to report later on how it works out!
Wow everyone, thank you so much for your support! Your comments and ideas have been amazing and positive. We're thrilled to be making an impact and to help make the web better.
On the one hand this looks nice, on the other hand it is a shame that something like this is needed at all. Most of the errors I see in the wild are type errors and the industry has just failed to offer a good solution when JavaScript took off. I really hope there will be a lot more adoption of technologies that solve the problem instead of treading the symptoms in the future, for example new ES6+ features, JavaScript supersets like TypeScript or trans-compilation like GWT.
We went back and forth on this. We orginally just had /current/tracker.js but lots of folks feel weird about running potentially changing scripts on their production sites :) in the end we decided it was probably best to version it and let people upgrade as they see fit. Obviously the backwards compat is a little more work for us, but we felt it was a better choice overall. (You can also bundle our script)
Yeah, saw the bundling, nice touch. Though doesn't that mean any compilation problems won't get logged? Do I gain anything if I leave it unbundled but serve it myself (1 less DNS lookup I guess?)?
Also, really nice, simple reset process.
In fact, I'm very impressed with the UI so far, it's a dream to use, excellent get started documentation and it ended up taking me very little time to find the reset.
Thanks! Despite the fact that we all come from heavy client side rendering backgrounds, you'll find the bulk of our UI is server side rendered :)
Re: compilation errors - It depends on where our script is concatenated in the bundle to an extent. For best results we recommend putting it as the first thing in the bundle.
I think it's good to offer a latest release url as well as versioned ones too. We've had serious problems before due to a NewRelic update to their browser monitoring script that broke things for a bit.
Just like Google's developer CDN, where they to put the versions in the URLs, it's best to give the control to the developer of the application and allow them to update versus an automatic update which could introduce incompatibilities, deprecated APIs, etc.
I've been using TrackJS for several months (Oct of last year I think) on personal project and I also introduced it into the products that I develop at Pearson VUE. It has been rock solid and extremely helpful. We attempted a home grown version before switching to TrackJS and we are much happier now.
Hmm I'm skeptical about the reliability of this especially on older browers.
Does it track these events basically in an order? JavaScript is single threaded in the browser so multiple reschedulings could easily hit different objects and events unrelated to each other.
Very cool. Can you pass arbitrary parameters to the tracker? For instance, could I somehow pass in the user's id, and have that show up on the page? That way if he/she gave me a call and said something went wrong, it'd be easier to pin down.
Need to look into this more, I did something like this in the past with window.onerror which then set the error to our site so we could monitor javascript errors on client machines. Worked well enough, but yours looks a tad more polished than my attempt!
This is super cool. Tools that capture errors on the user's end are invaluable. In an ideal world, the user would never experience errors, but I haven't lived in that world yet. Can't wait to see how this evolves.
I wish your blog post picture showed us the stack trace tab. With the screenshot you used, I don't see how that could help me debug my typical client-side error. What I usually need is a stack trace.
This seems promising, however you might want to provide some interactive demo if you want more signups. And make it clearer that there's a free trial.
But again, looks very good and I might use it.
