(disclaimer: I know the founders; and I wrote the python / django client libraries)
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.
I like the concept but I don't like your pricing model. For what it is, even $19 a month feels like a lot. I would love to add this to the couple of web apps I run but at that cost it'd run parallel to the cost of my AWS overhead.
Semi-seriously, you should add a PAYG model that costs by the error, thus incentivising me to make my code less error-prone!
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.
That response can be generalized to "you should always give people whatever they ask". What if he already is valuing the app a lot, but the app just isn't worth the price compared to other apps, or he just doesn't find it that useful?
What your onboarding flow needs is "How this is different from X." Adding this to my app may be easy, but switching has cost (lost data, time spent, etc).
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).
looking at your homepage, i don't get what makes this different from airbrake.io, which i've been using for years.
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.
Thanks for the feedback. Out of interest, did you read the about page or watch the video? Is it expecting too much for casual visitors to do that (genuine question)?
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!
Since you're looking for other error management services, you might try ProjectLocker Pulse (http://www.projectlocker.com/pulse). Since Pulse is part of the ProjectLocker platform (source control, issue tracking, automated deployments, etc.), there is no extra fee or bandwidth metering for using it.
hey, if you are an airbrake user try out https://errormator.com service. We have airbrake compatible endpoint to get you started easly, but our native python client where the service really shines.
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)
I'll bite. I don't particularly dislike Airbrake, but I don't particularly like it, either, and I periodically want to use something else:
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.
OP here. In case people are wondering what the new approach is, Errordite allows you to look at your list of errors and by highlighting properties of the error define the rules by which errors are grouped into issues. See the video for a demo.
Yup but only automatially. Our matching default to automatic but you can redefine the matching rules.
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.
Ah, I see, thanks. I guess I just haven't had trouble with this in all my years working on web development, it's always the same error (the error doesn't vary on ids), if an IP address keeps sending me things that break my server, I fix my server, and if the same bug is causing different errors, I'll fix it quickly.
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).
Yep - if you're totally organised and completely on top of your app, then there may be little need for a service like this (although I'd say there's still value in the graphs, the multiple alerting channels and all the other good stuff).
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.
Ah, I see, thanks for the explanation. I imagine that if you're using someone else's codebase, you'd be in a much worse position to fix bugs immediately, I hadn't considered that.
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.