Airbrake acquired by Exceptional

We have regular usage of 3000+ requests per second between our products. We have 12+ languages/frameworks that feed us exceptions. We also have integrations with PaaS providers like Heroku, EngineYard, AppFog and others. We also get hundreds of support requests each week. Part of our mission for embracing both of these products is to complete a vision that includes many powerful additions. But to get there we knew we needed to both retool the architecture for scale. We also wanted to keep under 24 hour turnaround time for our support.

When you look at our historical pricing there is no way we could meet our expectations of providing high reliability to our customers, a high quality of support and maintain all the bits that feed into the product--not to mention our vision for the future.

We tested our pricing changes with over a hundred of our users and they adamantly agreed--charge us more--make it rock solid--and let's see some of those features (e.g. search!).

And in general--our philosophy with pricing is this: we are developers. All of our customers are developers. But within this group there is a distinction--the side-project developer and the corporate developer. You are probably a corporate developer when you've advanced to having a company credit card. To you, our pricing is trivial for a production infrastructure service (see AWS or even Salesforce and friends). For the side-project developer--we are never going to be inexpensive enough. And we don't want to break your back to get great service from us! In fact, if anyone has been adversely affected by our plans, you should tell me! I take responsibility and want to hear from you.

I'm ben@airbrake.io or just give me a call at 415 500 5207. Although I'm in Berlin right now with some of our awesome users http://instagr.am/p/GtrfVDlnsy/, so if my speech is slurred or I'm slow to respond this evening, you know why. :-)

We run it at our organization to monitor 11 applications. One of the major benefits was LDAP authentication, and a custom issue tracker integration.

Why? Well, it's practically useless outside of Ruby. The UX assumes Rack/Rails-isms, so the experience is weird for Javascript errors. Beyond that, stack traces aren't good enough to debug many issues; you need logging integration. This is especially true for minified javascript.

You missed the small link at the bottom of the pricing grid

It's compatible with the Airbrake API, so you just need to configure the Airbrake Notifier gem to point to your Errbit instance.

Rolling your own is more effort than it's worth. On top of that, exception tracking is not something you want to have to worry about when your world comes crashing down, and that's exactly when a hand-rolled solution is most likely to fail. (i.e. Are you running your hand-rolled tracker in the same Heroku instance as your app? Then how do you know what went wrong when your app comes down? Are you running it as a separate Heroku instance? Why are you wasting money/resources running twice as many instances as you need?)

NewRelic is nice in the way that it integrates with other charting/reporting for your app. However, on a day-to-day basis, too many errors/exceptions are not caught by NewRelic making it ultimately unreliable. Also, you don't get nearly enough context with error reports to be able to debug the root cause (though they have been improving in this regard).

Email fails as a solution the first time you accidentally deploy an error that gets hit 500 times a second. This is especially true if your app, itself, needs to send emails. I've witnessed a situation where exception email notifications have caused message rate-limiting to kick in preventing customer targeted emails from being sent. Now you have two problems!

I won't say that Airbrake or Exceptional are perfect, but they are good for what they do. Obviously every situation is different, and you have to weigh the pros and cons (e.g. How much traffic are you receiving? Do you have a dedicated Ops team that can handle deploying/maintaining a hand-rolled solution? How much revenue are you loosing because of exceptions? Is your app targeting individuals that are likely to be turned off the first time they see a 500 page? or can you afford to have uncaught exceptions for now?). By no means, though, would I dismiss these solutions out of hand.

Heroku does the same thing for example. They are quite expensive if you compare them to running on raw ec2, but when you factor in the time that you need to spend to build and maintain your own infrastructure Heroku "suddenly" looks like a very good deal.

Why would I want to concern myself with maintaining another app when I can just use Airbrake?