Hacker News Reader

Comment by iambot | Hacker News Reader

If you're product it targeting developers, as I'm sure a "High performance JavaScript error tracking" service would be. I would hope that the "Features" page would be a bit more descriptive of how it works.

While I understand that you don't want to over complicate the features section, the reality is that the people you're targeting should have more than a basic understanding of whats happening, and you should talk to them as such. - Unless you're targeting managers and hoping they will force this on their developers.

Edit: I notice you have _some_ technical info in the FAQ, but my personal opinion is that if you're targeting devs you need MOAR.

tl;dr: Give us more info.

View on HN

Thanks. Point taken. Do you have any specific questions in mind?

Some things off the top of my head:

What info do you report back? What format is it? Do you handle different types of errors? And if so how do you report them? Do you plan on providing an API for devs to retrieve this info?

That's all I can think of on the spot, I just think you know your product better than anyone else, adn if you were trying to convince yourself to use it, surely the 8 point feature list wouldn't cut it.

Cool... thanks for this list. I'll incorporate it in the FAQs.

To answer your questions right here: The only info reported back is the three parameters from window.onerror (error message, line number, file name), and the page on which the error occurred. It's submitted as a regular form POST. There's no distinction between different types of errors - everything that window.onerror catches is posted. I do have plans for an API (and several other features) in mind - it's still work in progress.

As an Aside: I would hope that you're sending back info on the user-agent as well (I only say this because you've not mentioned it).

When an error is encountered it makes all the diffence that it was on a machine running ie7 (as an example).

Oh yes, of course. I'm not explicitly sending the UA string. Since I'm just doing a client-side post, the UA string is sent as a part of the HTTP request itself. I record this, and errors are segregated by browsers by default automatically.

I'm with iambot. In almost all cases knowing the browser and versions makes the difference.

Other things that could be changed. You say you ignore errors like when "Google Analytics broke", but I think reporting this kind of errors should be configurable. For us, an ecommerce site, it's important for the GA tracker to work, as many decisions are based on the insights it provides.

I guess I should clarify that statement on the site. The errors aren't actually ignored. They are just filed separately as "muted errors". None of the errors posted are ignored - they are all visible for review.

Ah ok, good to know ;)

Reply on news.ycombinator.com