6 ms·

You should be using Google Analytics to log your startup's client-side errors

187 points by dclaysmith 15y ago

nathan_f77 15y ago
You can also use Errbit (https://github.com/errbit/errbit https://github.com/errbit/errbit) to log your client-side errors.
- pbiggar 15y ago
  Can you go into this a bit more? errbit looks like it's airbrake compatible, and we're very happy with airbrake, even though it's JS support isn't fantastic. Can I just take errbit's notifier.js and use that? The docs dont say anything about JS...
  - sleepyhead 15y ago
    Yes. Errbit is great. Replaced Airbrake for me and saved me some cash.
    - pbiggar 15y ago
      OK, but I don't really care about the $15 per month - I really just want better JS notifications (and am perfectly happy with airbrake running the service for me). So do they have a better JS notification? How do we use it?
      - sleepyhead 14y ago
        It works the same way as Airbrake.
jreposa 15y ago
I tried Airbrake yesterday and it wasn't that helpful. I had to turn it off quickly as I was inundated with errors. You can see from your screenshot that you're getting Script Error at line 0. A number of other errors pop up that I couldn't quite figure out. For instance, when the variable 'google' isn't found it's because the google javascript never loaded. But, how many browsers are rejecting the google maps javascript?
- dmethvin 15y ago
  It sounds like Airbrake was very helpful. It is telling you that users are experiencing errors frequently, something you didn't know before. If, for example, the "google javascript never loaded" situation is common you'd want to either fix that or have your own script work around it -- at the very least, let the user know why the page is broken and that it isn't your fault. Line 0 script errors can be from dynamically loaded code, such as JSONP requests or `eval()` code.
  - ecaroth 15y ago
    FF/Chorme/Safari also give the Line 0 "script errors" when an error occurs in any JS file that isn't on your domain (IE jquery from a CDN, 3-rd party scripts, etc). This is a cross-origin security feature.
  - jreposa 15y ago
    Well... Yes. It was helpful for that reason. I waded through many of the errors and traced them back to actual lines of code. It just so happens that many of the errors weren't particularly useful to me. I.e., not actionable. Our browser tests include IE7, IE8, IE9, Safari, Firefox and Chrome. None of those errors are present in our tests. As you note, in many of the cases I could wrap the errors with notifications to the user. But, really, if the google variable isn't loaded for a small set of users and I can't easily configure a test system that can reproduce it, I'm not going to take the time right now. I have too many other pressing things on my list.
    - martian 15y ago
      The "google" variable is often not loaded for people who use Adblock or similar extensions that block social media plugins. You can simply check that "google" exists before running the code that depends on it: if (typeof google !== "undefined") { // run google code here google.magic(); }
    - dmethvin 15y ago
      I understand deadlines, and yes you may not be able to do more than explain to the user that there is a problem out of your control. But don't diss Airbrake because you don't have time to investigate and/or fix. They're not sayin' you have to fix it, they're just sayin'.
dmethvin 15y ago
Google Analytics works for summary-level error reporting (file, line, error message) but not very well if you want to know the details like a stack trace which can change on each occurrence. That's where the other solutions are much better. GA is certainly better than closing your eyes though.
- dclaysmith 15y ago
  Yeah, there are definitely limitations. I'm going to keep playing around with the data that gets sent to Google Analytics. File/Line/Message doesn't do much (especially w/ minified js files) but there is likely a clever way to capture and log more information (navigator.* etc) or use try/catch to capture/log the stack trace. Javascript not my strongest area so slow going...
  - gravitronic 15y ago
    Regardless, thank you very much. Generally there is no 100% perfect solution but a copy&pasteable solution to this issue is the kind of thing I love to come across on HN.
- DavidPP 15y ago
  You are right this isn't necessary a replacement for other solutions. But even if you use other logging solutions, it might be a good idea to log them in GA also so that you can measure the impact of those errors on metrics like conversions.
augustl 15y ago
I wonder if there are JS minifiers that creates a symbol file so that I can expand stack traces with it, much like compilers do.
- rakeshpai 15y ago
  Yes there are. Google Closure compiler does export this thing called Source Maps (http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ http://www.html5rocks.com/en/tutorials/developertools/source...) which is very exciting. If it weren't for the fact that we don't get column numbers in window.error, I would have already supported source maps in http://errorception.com/ http://errorception.com/ by now. I'm still looking actively for ways to include support though.
dminor 15y ago
I did something similar on our site a couple years ago. One nice thing about tying it into Google Analytics is you can analyze the effect of each type of error on your conversion rate, which helps prioritize your fixes.
DavidPP 15y ago
Thanks you took up on my comment and expanded this to a blog post! Where I work, we use try/catch block but they do have their drawbacks (one of them is less optimization in Chrome).
- dclaysmith 15y ago
  Very clever idea (added a link to your twitter/tumblr). Do you use try/catch in each method or a single wrapper of some sort?
  - rakeshpai 15y ago
    It isn't possible to have a single "wrapper" try/catch in JS, because of the event-loop nature of most JS hosts. This is because functions that are scheduled to run on the event loop (say, using a button click, or a ajax call), aren't in the same call-stack as the code that defined it. Since they aren't in the same call-stack, an outer try/catch won't work on the inner callback.
  - DavidPP 15y ago
    Well, in our case we work with multiples development teams, so we only "catching" errors in our code so we don't use a wrapper. If someone try it this way, I would be curious to hear about the results.
deleted 15y ago
[deleted]
zinssmeister 15y ago
After reading yesterdays post about client-side error tracking I started looking into leveraging Google Analytics (because obviously it would be a fast way to get some small level of error reporting up and running). There is one thing I would have to add to this topic: We decided to track these error events in a separate Google Analytics profile, because there is a 500 events per session limit: http://code.google.com/apis/analytics/docs/tracking/eventTrackerGuide.html#implementationConsiderations http://code.google.com/apis/analytics/docs/tracking/eventTra...
Kiro 15y ago
Will this mess up other things in Google Analytics? Or is there any other reason not to use this?
- dclaysmith 15y ago
  You need to give some thought about how you categorize your events. If you plan on using events for other things, you want to give some upfront planning for how you Categorize and label things otherwise you might make reporting difficult.
toast76 15y ago
window.onerror is unreliable at best. doesn't work in all browsers. doesn't capture stack information. won't give the desired result when using libraries like jquery. doesn't work particularly well with minimized code. in most (all?) versions of IE will just return "unknown error". Using try/catch to resolve this also doesn't help unless you literally try/catch every function There are plenty of services out there that tackle this problem properly. Shell out the money and use one.
- mwww 15y ago
  Can you recommend some of those services you are talking about?
gnu8 15y ago
Two problems though: 1) no one should use Google Analytics, especially not start-ups, because it gives Google full access to intelligence that you don't want them to have. 2) I block Google Analytics because neither Google nor fly-by-night Web 2.0 startups have any business tracking that stuff. In fact it should be normal practice for all web browsers to block urchin.js by default.
- mwww 15y ago
  What's wrong with start-ups using GA? Aren't you a bit paranoid?
pconf 15y ago
The problem with Google Analytics is that it gives Google _all_ your weblogs. Not just your page hits but also your site _viewer's_: IP address, browser type, OS type, screen resolution, browser window size, as well as any lingering js or cookie info from their prior browsing. Google uses this data to correlate everything they can track about you, which would blow your mind if you knew what they know, then they sell this data for a substantial profit. EPIC, the EFF, and the ACLU website's go into detail about why this is decidedly not a good thing. What I find fascinating, however, are those who ask why is that such a bad thing without, supposedly, considering the ramifications. If they ever were confronted with all that Google knows about them, from browsing to email to online purchases (not to mention their HN alias, and a fair amount of offline info too) they'd be too embarrassed to ever again "wonder" what the problem was. At some point the scope of Google's privacy invasion will become better known and people will think twice before even considering spyware like Google Analytics. Until then it's Google's ballgame, at least here in the US.

187 points by dclaysmith 15y ago

You can also use Errbit (https://github.com/errbit/errbit https://github.com/errbit/errbit) to log your client-side errors.

pbiggar 15y ago
Can you go into this a bit more? errbit looks like it's airbrake compatible, and we're very happy with airbrake, even though it's JS support isn't fantastic. Can I just take errbit's notifier.js and use that? The docs dont say anything about JS...
- sleepyhead 15y ago
  Yes. Errbit is great. Replaced Airbrake for me and saved me some cash.
  - pbiggar 15y ago
    OK, but I don't really care about the $15 per month - I really just want better JS notifications (and am perfectly happy with airbrake running the service for me). So do they have a better JS notification? How do we use it?
    - sleepyhead 14y ago
      It works the same way as Airbrake.

jreposa 15y ago

I tried Airbrake yesterday and it wasn't that helpful. I had to turn it off quickly as I was inundated with errors. You can see from your screenshot that you're getting Script Error at line 0. A number of other errors pop up that I couldn't quite figure out. For instance, when the variable 'google' isn't found it's because the google javascript never loaded. But, how many browsers are rejecting the google maps javascript?

dmethvin 15y ago
It sounds like Airbrake was very helpful. It is telling you that users are experiencing errors frequently, something you didn't know before. If, for example, the "google javascript never loaded" situation is common you'd want to either fix that or have your own script work around it -- at the very least, let the user know why the page is broken and that it isn't your fault. Line 0 script errors can be from dynamically loaded code, such as JSONP requests or `eval()` code.
- ecaroth 15y ago
  FF/Chorme/Safari also give the Line 0 "script errors" when an error occurs in any JS file that isn't on your domain (IE jquery from a CDN, 3-rd party scripts, etc). This is a cross-origin security feature.
- jreposa 15y ago
  Well... Yes. It was helpful for that reason. I waded through many of the errors and traced them back to actual lines of code. It just so happens that many of the errors weren't particularly useful to me. I.e., not actionable. Our browser tests include IE7, IE8, IE9, Safari, Firefox and Chrome. None of those errors are present in our tests. As you note, in many of the cases I could wrap the errors with notifications to the user. But, really, if the google variable isn't loaded for a small set of users and I can't easily configure a test system that can reproduce it, I'm not going to take the time right now. I have too many other pressing things on my list.
  - martian 15y ago
    The "google" variable is often not loaded for people who use Adblock or similar extensions that block social media plugins. You can simply check that "google" exists before running the code that depends on it: if (typeof google !== "undefined") { // run google code here google.magic(); }
  - dmethvin 15y ago
    I understand deadlines, and yes you may not be able to do more than explain to the user that there is a problem out of your control. But don't diss Airbrake because you don't have time to investigate and/or fix. They're not sayin' you have to fix it, they're just sayin'.

dmethvin 15y ago

Google Analytics works for summary-level error reporting (file, line, error message) but not very well if you want to know the details like a stack trace which can change on each occurrence. That's where the other solutions are much better. GA is certainly better than closing your eyes though.

dclaysmith 15y ago
Yeah, there are definitely limitations. I'm going to keep playing around with the data that gets sent to Google Analytics. File/Line/Message doesn't do much (especially w/ minified js files) but there is likely a clever way to capture and log more information (navigator.* etc) or use try/catch to capture/log the stack trace. Javascript not my strongest area so slow going...
- gravitronic 15y ago
  Regardless, thank you very much. Generally there is no 100% perfect solution but a copy&pasteable solution to this issue is the kind of thing I love to come across on HN.
DavidPP 15y ago
You are right this isn't necessary a replacement for other solutions. But even if you use other logging solutions, it might be a good idea to log them in GA also so that you can measure the impact of those errors on metrics like conversions.

augustl 15y ago

I wonder if there are JS minifiers that creates a symbol file so that I can expand stack traces with it, much like compilers do.

rakeshpai 15y ago
Yes there are. Google Closure compiler does export this thing called Source Maps (http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ http://www.html5rocks.com/en/tutorials/developertools/source...) which is very exciting. If it weren't for the fact that we don't get column numbers in window.error, I would have already supported source maps in http://errorception.com/ http://errorception.com/ by now. I'm still looking actively for ways to include support though.

dminor 15y ago

I did something similar on our site a couple years ago. One nice thing about tying it into Google Analytics is you can analyze the effect of each type of error on your conversion rate, which helps prioritize your fixes.

DavidPP 15y ago

Thanks you took up on my comment and expanded this to a blog post! Where I work, we use try/catch block but they do have their drawbacks (one of them is less optimization in Chrome).

dclaysmith 15y ago
Very clever idea (added a link to your twitter/tumblr). Do you use try/catch in each method or a single wrapper of some sort?
- rakeshpai 15y ago
  It isn't possible to have a single "wrapper" try/catch in JS, because of the event-loop nature of most JS hosts. This is because functions that are scheduled to run on the event loop (say, using a button click, or a ajax call), aren't in the same call-stack as the code that defined it. Since they aren't in the same call-stack, an outer try/catch won't work on the inner callback.
- DavidPP 15y ago
  Well, in our case we work with multiples development teams, so we only "catching" errors in our code so we don't use a wrapper. If someone try it this way, I would be curious to hear about the results.

deleted 15y ago

[deleted]

zinssmeister 15y ago

After reading yesterdays post about client-side error tracking I started looking into leveraging Google Analytics (because obviously it would be a fast way to get some small level of error reporting up and running). There is one thing I would have to add to this topic: We decided to track these error events in a separate Google Analytics profile, because there is a 500 events per session limit: http://code.google.com/apis/analytics/docs/tracking/eventTrackerGuide.html#implementationConsiderations http://code.google.com/apis/analytics/docs/tracking/eventTra...

Kiro 15y ago

Will this mess up other things in Google Analytics? Or is there any other reason not to use this?

dclaysmith 15y ago
You need to give some thought about how you categorize your events. If you plan on using events for other things, you want to give some upfront planning for how you Categorize and label things otherwise you might make reporting difficult.

toast76 15y ago

window.onerror is unreliable at best. doesn't work in all browsers. doesn't capture stack information. won't give the desired result when using libraries like jquery. doesn't work particularly well with minimized code. in most (all?) versions of IE will just return "unknown error". Using try/catch to resolve this also doesn't help unless you literally try/catch every function There are plenty of services out there that tackle this problem properly. Shell out the money and use one.

mwww 15y ago
Can you recommend some of those services you are talking about?

gnu8 15y ago

Two problems though: 1) no one should use Google Analytics, especially not start-ups, because it gives Google full access to intelligence that you don't want them to have. 2) I block Google Analytics because neither Google nor fly-by-night Web 2.0 startups have any business tracking that stuff. In fact it should be normal practice for all web browsers to block urchin.js by default.

mwww 15y ago
What's wrong with start-ups using GA? Aren't you a bit paranoid?

pconf 15y ago

The problem with Google Analytics is that it gives Google _all_ your weblogs. Not just your page hits but also your site _viewer's_: IP address, browser type, OS type, screen resolution, browser window size, as well as any lingering js or cookie info from their prior browsing. Google uses this data to correlate everything they can track about you, which would blow your mind if you knew what they know, then they sell this data for a substantial profit. EPIC, the EFF, and the ACLU website's go into detail about why this is decidedly not a good thing. What I find fascinating, however, are those who ask why is that such a bad thing without, supposedly, considering the ramifications. If they ever were confronted with all that Google knows about them, from browsing to email to online purchases (not to mention their HN alias, and a fair amount of offline info too) they'd be too embarrassed to ever again "wonder" what the problem was. At some point the scope of Google's privacy invasion will become better known and people will think twice before even considering spyware like Google Analytics. Until then it's Google's ballgame, at least here in the US.