Show HN: Errorception - High performance JavaScript error tracking
22 comments
Your product is for people who write code, but your sales pitch is some vaporous hand-wavy thing. I'm writing my own guide on quality JavaScript, and I have absolutely no idea of what your product does beyond "Group errors and email people, also, unobtrusive!"
I imagine (based only on your comments here) this is a JavaScript file that basically sends ajax data with `window.onerror` events from the browser.
You need a user story for customers. "Bob's website, twitter.com, sucks because it throws thousands of errors only to suppress them by hacking in window.onerror = function(){} so nobody gets to see them in the console and make fun of them, why not do better and get reports of what your errors actually look like!" Your user story needs to explain value (which I myself as a potential customer of yours do not see, I will explain in a moment).
Also, pricing on the volume of errors doesn't feel right. Especially if I'm using this for development. Some websites will pass even your $60 limit in a few days, never-mind errors that happen in loops. Why not just set one price? 20-25$/month or $200/year feels right to me.
You also need to compete on something that shows value. Who are you targeting? What errors do your customers care about? Why might I not want to use your tool? Why does twitter suppress errors rather than fix them? Why might twitter buy your service?
As for why you don't have my business, I see no advantage or benefit to your product. I've implemented similar features in the past only to move onto other things. Sending an web request (ajax or any other request type) with window.onerror is trivial. I even optimized it to not lag out pages when we have errors in loops through some other techniques. You haven't convinced me why a competent JS developer needs this, when the implementation for very basic functionality is trivial. Give me a reason to buy this; a spreadsheet of hand-wavy features doesn't answer the problems that keep me up at night.
tldr: Marketers, marketers, marketers.
I imagine (based only on your comments here) this is a JavaScript file that basically sends ajax data with `window.onerror` events from the browser.
You need a user story for customers. "Bob's website, twitter.com, sucks because it throws thousands of errors only to suppress them by hacking in window.onerror = function(){} so nobody gets to see them in the console and make fun of them, why not do better and get reports of what your errors actually look like!" Your user story needs to explain value (which I myself as a potential customer of yours do not see, I will explain in a moment).
Also, pricing on the volume of errors doesn't feel right. Especially if I'm using this for development. Some websites will pass even your $60 limit in a few days, never-mind errors that happen in loops. Why not just set one price? 20-25$/month or $200/year feels right to me.
You also need to compete on something that shows value. Who are you targeting? What errors do your customers care about? Why might I not want to use your tool? Why does twitter suppress errors rather than fix them? Why might twitter buy your service?
As for why you don't have my business, I see no advantage or benefit to your product. I've implemented similar features in the past only to move onto other things. Sending an web request (ajax or any other request type) with window.onerror is trivial. I even optimized it to not lag out pages when we have errors in loops through some other techniques. You haven't convinced me why a competent JS developer needs this, when the implementation for very basic functionality is trivial. Give me a reason to buy this; a spreadsheet of hand-wavy features doesn't answer the problems that keep me up at night.
tldr: Marketers, marketers, marketers.
I suppose the main advantage would be information aggregation with each error next to the number of occurrences (I don't want to see a hundred times the same error), the same business model as airbrake or getexceptional. I mean, almost any developer could implement an exception logger, but I don't really want to spend that time on a non-core feature for my business.
Sure, but that feature seems trivial to me, I can simply create a view in my database to shake the data however I would like.
https://gist.github.com/1438654
I could just select * from viewGroupErrors where error=12345
The cost of this app should be less than cost of my time to make it, right now the yearly cost is probably $50 to me.
https://gist.github.com/1438654
I could just select * from viewGroupErrors where error=12345
The cost of this app should be less than cost of my time to make it, right now the yearly cost is probably $50 to me.
bdg, I mean no disrespect, but the matter is honestly not that trivial. Ultimately, you are right - it does come down to getting some queries right, but you quickly discover that it's an ongoing effort. Three months since I'm doing this, and even now I'd be happier if I could manage duplicates better. It's not a simple select query for sure.
So now you only need to manage that table so it does not grow out of control, create a basic interface, some kind of alerts... all for $15-30 month. I don't know you, my hours are way more expensive. For this kind of non-core features SaaS is the way to go.
Thanks for taking the time for the comment, bdg.
About the pitch/technology/complications: You are right - everyone here too has echoed that I should clarify how the tech works, why it isn't really trivial, and generally improve the marketing pitch too. I hear you. Expect a change coming up soon. Thanks for the feedback - it's invaluable.
About the pitch/technology/complications: You are right - everyone here too has echoed that I should clarify how the tech works, why it isn't really trivial, and generally improve the marketing pitch too. I hear you. Expect a change coming up soon. Thanks for the feedback - it's invaluable.
I can see some problems with your "per-exception" pricing model.
If your product works and adds value, it will result in the reduction of exceptions. A reduction in the number of exceptions will result in web sites requiring a smaller plan. Smaller plans will result in lower revenue. The more useful your app is, the less money you will make (a bit of a generalization but you get the point).
Could you not migrate to page loads? Fire off an event on every page, regardless of whether or not there was an exception?
If your product works and adds value, it will result in the reduction of exceptions. A reduction in the number of exceptions will result in web sites requiring a smaller plan. Smaller plans will result in lower revenue. The more useful your app is, the less money you will make (a bit of a generalization but you get the point).
Could you not migrate to page loads? Fire off an event on every page, regardless of whether or not there was an exception?
Thanks for the feedback, Clay.
I considered that model for a really long time. But there were two problems with it. (a) Actually just handling large amounts of hits wasn't really a huge cost for me, and (b) I don't think the usefulness will reduce for people who actively deploy regularly.
If people don't deploy regularly, they'll likely be happy with the free plan anyway. :)
I considered that model for a really long time. But there were two problems with it. (a) Actually just handling large amounts of hits wasn't really a huge cost for me, and (b) I don't think the usefulness will reduce for people who actively deploy regularly.
If people don't deploy regularly, they'll likely be happy with the free plan anyway. :)
Charging per exception also adds a nice synergy to bugfixing.
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.
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.
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.
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.
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).
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.
Thanks, going to give it a try. One tiny typo (I think!), first line under Sign Up For Free Trial
'No oblations.'
plural of ob·la·tion (Noun) Noun: A thing presented or offered to God or a god. The presentation of bread and wine to God in the Eucharist.
'No oblations.'
plural of ob·la·tion (Noun) Noun: A thing presented or offered to God or a god. The presentation of bread and wine to God in the Eucharist.
I asked the mighty Google, and couldn't find anything like that. You could be right, of course. Do you have a link? I've even seen several others use the term verbatim.
I think the word you're looking for is "obligations".
Ah. I even read the "oblations" as "obligations" in my head. Thanks for pointing this out. It's fixed now.
no problem, it's working nicely, I have a few errors to fix now, cheers :)
edit: it would be nice to see some data aggregated and fed back into the community so that issues with some of the more popular JS packages like jquery could be fixed :)
edit: it would be nice to see some data aggregated and fed back into the community so that issues with some of the more popular JS packages like jquery could be fixed :)
That's a neat suggestion, though it may be hard to distinguish between developer errors and library errors. It's definitely something to aspire for.
Great to know you are liking the service. Cheers!
Great to know you are liking the service. Cheers!
No problem, I think it might be worth looking into further, you could restrict it to errors that recur across large numbers of accounts account then scrape github for possible links, cloudsource to verify the connections and bang, the world a better place, well, in a small way.
I came across http://www.muscula.com/ over the weekend, and they seem to be farther along with this kind of a product in terms of features (not to discourage you, just to give you a heads up as to what else is out there). Specifically, they've implemented a stack trace and also provide the browser/OS data in addition to the file/line/error.
They also provide a quick overview of their architecture if anyone is curious @ http://www.muscula.com/architecture
They also provide a quick overview of their architecture if anyone is curious @ http://www.muscula.com/architecture
I've heard about Muscula (and I'm reasonably sure they've heard about Errorception - it's a smallish world :) ), and I'm curious to know more about how they do what they do.
That said, the architecture isn't too different. Errorception is also built on Node and MongoDB. I am not a fan of JSONP (GET) for writing data (POST/PUT), mostly because I'm a stickler for HTTP semantics. Otherwise, without too much insight into what Muscula is doing, it certainly looks like we are very similar.
Browser/OS information is rather easy to get - it's all in the UA string. Errorception captures that already. :)
That said, the architecture isn't too different. Errorception is also built on Node and MongoDB. I am not a fan of JSONP (GET) for writing data (POST/PUT), mostly because I'm a stickler for HTTP semantics. Otherwise, without too much insight into what Muscula is doing, it certainly looks like we are very similar.
Browser/OS information is rather easy to get - it's all in the UA string. Errorception captures that already. :)
How, precisely, does your service interact with my code? What does an error report look like? This should be on the front page.
Also, "How can I pay for errorception? I'm working hard on getting a simple enough payment mechanism in place, that plays well with the laws of my land. As you can imagine, I need to start making money soon enough, and this is my top priority right now." doesn't inspire confidence in your product's reliability or half-life.
Also, "How can I pay for errorception? I'm working hard on getting a simple enough payment mechanism in place, that plays well with the laws of my land. As you can imagine, I need to start making money soon enough, and this is my top priority right now." doesn't inspire confidence in your product's reliability or half-life.
Thanks for pointing this out. I've fixed the FAQ to be more recent - what you saw was from an older time. Thanks again.
We've tried 2 or 3 existing Javascript error tracking systems in the past. None of them helped much.
Performance is not the feature I care about.
On the other hand, I would be delighted to pay to get more actionable information about our errors. It's so so hard to determine exactly where in the code, and under what circumstances, errors in the browser happen.
Performance is not the feature I care about.
On the other hand, I would be delighted to pay to get more actionable information about our errors. It's so so hard to determine exactly where in the code, and under what circumstances, errors in the browser happen.
Hey Greg,
The challenge you have mentioned is real, and is hard to crack. I certainly haven't solved the problem to my satisfaction yet. However, I'm rather far along the way. A lot of errors are classified as being irrelevant (I call it "muted", but that's a terminology thing), and the ones that are in your face are based on relevance and frequency. This is a very rudimentary way of deciding importance, but it's something. At least it's not a raw list of logs.
Improving the quality of "actionable information" as you put it will be the biggest (and most interesting and fun) challenge at Errorception. It'll get better over time.
The challenge you have mentioned is real, and is hard to crack. I certainly haven't solved the problem to my satisfaction yet. However, I'm rather far along the way. A lot of errors are classified as being irrelevant (I call it "muted", but that's a terminology thing), and the ones that are in your face are based on relevance and frequency. This is a very rudimentary way of deciding importance, but it's something. At least it's not a raw list of logs.
Improving the quality of "actionable information" as you put it will be the biggest (and most interesting and fun) challenge at Errorception. It'll get better over time.
That sounds promising. I'll take a look.
P.S. I'm at greg at memrise dot com if you make further progress and are looking for beta testers.
P.S. I'm at greg at memrise dot com if you make further progress and are looking for beta testers.
What's the support like for mobile browsers? Debugging mobile webkit is a pain. It'd be nice to see some screenshots on the site too.
I've used Errorception for one of my products and was very happy with the service provided by the author. Thanks.
You need to provide more information how the service works, what kind of data and how you can get etc.
Thanks. I'm assuming you already looked at http://errorception.com/faq and that wasn't satisfactory? I'll see how I can improve the FAQs.
Working link: http://errorception.com/
Clickable: http://errorception.com/
Congrats, I have worked with errorception, found it really useful.
Thanks.
Thanks.
Cool idea! Does it give me a stacktrace of exceptions too?
Nope, no stack trace at the moment. This is because the stack has unrolled by the time window.onerror is hit. However, there might be workarounds - fake stack traces we can build by walking the callstack in some browsers. I'm currently working on just this. :)
This sounds like a really cool idea! Will give it a whirl
Found an IE 7 bug in less than a minute <3
Wow Really cool idea...let me give it a try....any discount coupons?
[deleted]
I built Errorception since I couldn't didn't find any error reporting system that (a) didn't rewrite my JS, (b) didn't modify the browser runtime by overriding common functions, and (c) had a zero performance cost, especially with regards to blocking script tags.
Would love your thoughts. Site: http://errorception.com/