Show HN: Errordite, a new approach to exception management
errordite.com
errordite.com
When we started YunoJuno we hooked up Sentry, as we are a django app, and it's the default option for error management (oh, and it had an Heroku add-on available). It's a great product, but I got frustrated early on with how it was aggregating errors - and ended up in a public StackOverflow confessional during which I unpicked the source and tried to work out what was going on (http://stackoverflow.com/questions/13331973/how-does-sentry-...).
I started using Errordite when it became available (I had to write the python client first!) and ran both in parallel for a couple of months. Both do a great job of helping manage exceptions, but the killer for us (and the reason we dropped Sentry recently) is that Errordite allowed us to determine the rules around grouping exceptions ourselves.
I won't say any more for fear of sounding like a plant, but in answer to those who have posted 'what's the difference' - it's (IMO) the ability to set custom rules around how errors are handled.
Semi-seriously, you should add a PAYG model that costs by the error, thus incentivising me to make my code less error-prone!
Please read http://wadefoster.net/post/49775946303/startups-you-should-v... :)
EDIT: What I am trying to say is that the comment is underestimating the value of something like an error tracker, vastly - especially when managing several web apps.
I recently discovered that it's conversation grouping works quite decently for error messages.
X includes at least: Honeybadger (what I use presently), AirBrake (just switched from this), NewRelic (also does what you do, and everybody uses it), BugSense, Errormator, Sentry, and I'm sure there are others in this field (for some reason).
I'd really love to have a well-rounded error management service (and airbrake isn't perfect), so I'm generally interested. But if you want to win me over as a customer, you might need to clarify on your homepage what's new in your approach.
Best wishes :)
1. The hideous UI. =)
2. Airbrake would 500 when trying to render the data about some of our 500s! A Rails app I work on was raising Rack exceptions about UTF-8 encodings, but viewing them on Airbrake caused it to fail, too. Meh.
3. We had to disable the JS error handler, as it would routinely take 3+ seconds to download for clients, or just time out entirely. Meh.
4. A few people on my team just never received the emails from airbrake. They were registered with the right address, it didn't go to spam, etc. It just never showed up. We gave up and switched it to mailing our foo-dev@ mailing list, and now people that have no ability to address the issue (and, honestly, mostly overreact to exceptions =) get the email, too. Meh.
See, it's just that "Meh." at the end of everything. A pretty reasonable summary of my Airbrake experience.
I have been passively searching for a new error monitoring service, so I clicked this link from my phone while on a train to work. I'm not going to find headphones, wait on a video to load, and then hope it's high enough quality on my phone to be a useful look at what you're offering. And the About page is hidden beneath a 'Docs' menu, which is actually right next to two links that take me to a sign-in form, so it never even occurred to me to look for it. I thought 'How It Works' was all you had besides the video.
So I added it to my "hey maybe come back and look at this some day" list of TODOs. That's a very big list. I rarely actually go back and look.
Had it been two screenshots of a decent UI and a quick blurb about your (likely very useful!) grouping/filtering functionality, I'd have been much more likely to make sure I went back to view the video.
That said, I'm now watching the video, and this looks pretty nice. Good luck!
Our index page is not the best ever yet - but we were focused on delivering actual app that kicks ass. You get error collection + logging + performance metrics in a single package!
(not with airbrake api obviously - only errors part with their client but it makes it easy to switch)
Disclaimer: I work for ProjectLocker.
Examples:
1. your exception messages contain the id of the entity you're dealing with "FooBar 1234 has broken". You only want to match then on the FooBar has broken bit, not the 1234.
2. for whatever reason, some IP address keeps sending you dodgy requests that break your server. You can filter all errors requests from this IP address so you don't get swamped with these errors.
3. The same bug deep down in your code is causing different errors higher up. You can choose to match on the part of your stack trace that is the common cause and get all these errors attached to the same issue.
I guess #3 is the only example that might apply to me, but I have literally never had this happen, so I don't know. Then again, I don't even use Sentry, I get the issues emailed to me and I fix them on the spot (they're usually 1-line fixes, typos, or something like that).
We developed Errordite as a result of working on large(ish) eCommerce websites where the wide variety of errors produced made it impossible to understand exactly the different things that could be going wrong - and I think for this kind of thing, where you are not going to always be on top of your errors, Errordite is invaluable.