Appfail - Exception monitoring built for the web

Today we're talking to Sam and Peter of Appfail about their experiences building their exception logging service and deploying it on AppHarbor.

Why did you decide to start AppFail?

We are professional .NET developers and we have always used tools like ELMAH and Log4Net to find and track problems in our applications. Over time, however, we realised that our approach was ineffective in some areas and really deficient in others. We spent too much time searching and sorting exception emails and exception logs to find and diagnose problems. It was hard to pick patterns – such as seeing that issues occurred on certain days or in certain conditions – and to keep a full historical perspective of our failures and their fixes. We realised that we needed better tools and a better approach. We decided that our solution must help us to:

• expose all of our application’s failures
• find the failures that matter most – those that have the biggest impact;
• track failure progress over time as we deploy fixes;
• show developers and administrators failure information about each page as they browse the live site;
• provide the ability to review and replay failure conditions directly in the page;
• have flexible notifications like ELMAH but with a tighter mobile integration;
• get notified only about important failures as soon as they happen;
• get notified of failures via mobile messaging;
• allow multiple collaborators to work together;
• become a cloud SaaS offering – easily scalable and accessible by anyone with an internet connection;

We also decided to put a lot of care and effort into our UI/UX. We focused on creating a straightforward and unobtrusive user interface with a lot of visual cues, balance and white space. Appfail needed to be a very easy to configure and a cinch to use. It needed to be useful if the developer just wanted a snapshot of failure information and yet provide enough depth to be useful in solving complicated problems. There are other tools on the market which aim to do similar things to Appfail. We looked at them but we weren’t too happy with what we saw. We felt that we could build a more useful product with a better user experience and better functionality for us and for the others out there. And so we made Appfail.

What technologies are you using?

Appfail is built on .NET 4.0 using C#. The main portal – appfail.net – is built on with ASP.NET MVC3. It runs on top of AppHarbor and uses MongoDB (via MongoHQ) for its database. We use Memcacher for sharing state between instances and we use New Relic for diagnosing performance issues. We leverage Amazon Web Services for our queue (SQS) which stores exceptions before they are processed by Appfail and email (SES) for notifications. Furthermore, we employ services such as ViaNett for TXT/SMS notifications. Our code is stored on GitHub and we use Tender to maintain a collection of our KB articles and engage with our users. We use Trello to plan future work, Google Apps, Blogger and Google Analytics.

What advice would you give to other developers running their apps on AppHarbor?

Using AppHarbor enabled us to rapidly develop, test and deliver Appfail. AppHarbor’s integration with GitHub allowed us to push code and immediately play with the changes online. AppHarbor’s add-ons helped us to quickly leverage other tried & tested technologies such as MongoDB. A big draw toward Appharbor was the low cost during development. With Appharbor we had no costs while we prototyped Appfail -- $0 for single instances of our web portal and API endpoint and $0 for a sandboxed MongoDB database. Just a couple of days before going live with beta, we ramped up our instance count, upgraded our MongoHQ plan and added Memcacher for a shared cache.

We’d encourage all passionate .NET developers to try out AppHarbor, play with add-ons and see how it fits them. It has certainly helped to lower the barrier to entry and eased a lot of our pain points. The staff at AppHarbor are impressively responsive (generally responding within a few hours) and have even helped with issues in our own code and suggested fixes.

What's in store for the future?

We have just launched our public beta of Appfail and we have a lot planned. One of our first priorities is to start offering support for other languages and frameworks. We plan to target ruby, python, php and others. We also plan to release a raft of new features, which we have found particularly useful, such as the ability to label, group and classify failures and we are expecting to make a few cool announcements in the mobile space as well. Our other major focus is to foster an Appfail community that help to solve each other’s problems. Wouldn’t it be great if Appfail could tell you about others who have encountered a particular failure, and show you how they solved it? We will extend collaboration options to allow this, and we’ll also link with other sites such as StackOverflow. Our aim is to harness collective knowledge and experience to make our lives as developers easier. This is what Appfail is all about.

Last but not least we are planning on introducing an AppHarbor add-on for our service. Look out for it in the very near future!

Any final thoughts?

We are excited to launch the public beta of Appfail. We have had a great response and a lot of interest so far. The only way we can make it better, however, is for more people to try it (the beta is absolutely free) and to give us their feedback. Please try it and if you have any questions or suggestions please drop us a line at support.appfail.net or [email protected]

As we grow we will continue to leverage AppHarbor as our platform because of the excellent experience we have had. We hope that other developers will give AppHarbor a try and we are thankful for the support and encouragement we have received.