Show HN: Errorception - High performance JavaScript error tracking
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/
[+] [-] bdg|14 years ago|reply
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.
[+] [-] sdepablos|14 years ago|reply
[+] [-] rakeshpai|14 years ago|reply
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.
[+] [-] dclaysmith|14 years ago|reply
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?
[+] [-] rakeshpai|14 years ago|reply
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. :)
[+] [-] iambot|14 years ago|reply
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.
[+] [-] rakeshpai|14 years ago|reply
[+] [-] tudorw|14 years ago|reply
'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.
[+] [-] rakeshpai|14 years ago|reply
[+] [-] dolinsky|14 years ago|reply
They also provide a quick overview of their architecture if anyone is curious @ http://www.muscula.com/architecture
[+] [-] rakeshpai|14 years ago|reply
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. :)
[+] [-] endian|14 years ago|reply
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.
[+] [-] rakeshpai|14 years ago|reply
[+] [-] karterk|14 years ago|reply
[+] [-] rakeshpai|14 years ago|reply
[+] [-] gregdetre|14 years ago|reply
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.
[+] [-] rakeshpai|14 years ago|reply
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.
[+] [-] colinramsay|14 years ago|reply
[+] [-] rakeshpai|14 years ago|reply
Currently, mobile browsers aren't supported because mobile webkit doesn't support window.onerror. Errorception doesn't distinguish between browsers, so whenever mobile browsers add support, I'll be ready.
[+] [-] nashjain|14 years ago|reply
[+] [-] narad|14 years ago|reply
[+] [-] rakeshpai|14 years ago|reply
[+] [-] angry-hacker|14 years ago|reply
[+] [-] rakeshpai|14 years ago|reply
[+] [-] rakeshpai|14 years ago|reply
[+] [-] sidcool|14 years ago|reply
[+] [-] acharekar|14 years ago|reply
Thanks.
[+] [-] avlesh-singh|14 years ago|reply
[+] [-] rakeshpai|14 years ago|reply
[+] [-] sourav_sachin|14 years ago|reply
[+] [-] htilford|14 years ago|reply
[+] [-] pooja_chauhan|14 years ago|reply
[+] [-] endian|14 years ago|reply
[+] [-] rakeshpai|14 years ago|reply