Why doesn't Scout include exception monitoring?

November 09 Bullet_white By Derek Bullet_white Comments Comments

It's a reasonable ask: performance issues and exceptions are often fixed by modifying the application source code, so why not include exception monitoring within Scout? It seems logical to bundle this together into the same agent.

There's four reasons we believe performance and exception monitoring should be handled by dedicated products.

1. The data says bundled monitoring isn't working

Nearly two-thirds of companies using a combined performance+exception monitoring vendor end up paying for another dedicated exception monitoring service*. As a customer, it would make no financial sense to tack on another exception monitoring service if you were happy with what your APM vendor offered. These APM services include exception monitoring for free.

* - based on data collected from customers switching to Scout.

2. Performance and bugs don't frequently intermingle

Outside of service timeouts, most application exceptions are not tied to performance issues. These timeouts are generally a small portion of exceptions. It's hard to justify the value of an integrated service when the overlaps are small.

We like overlapping problems: for example, we created a database monitoring addon because our data showed that the database is the largest performance bottleneck for web apps.

3. The exception monitoring arms race

I can think of four dedicated exception monitoring services off the top of my head (Sentry, HoneyBadger, Rollbar, and Raygun). This competition makes each product better. It's a fool's game to think splitting our product engineering time between performance and exception monitoring could build an exception monitoring service that rivals an experience built by a dedicated team.

Getting an accurate view of app performance is a hard enough problem on its own.

4. Performance UI != Exception UI

For performance, there's a natural way to aggregate data: by each web endpoint. These are the transactions that occur from your browser to the app server.

This isn't the case with exceptions: a bug at a lower level library may trigger many problems across endpoints. This means most exception monitoring UIs start w/the exception name, with some smart logic around combining exceptions across similar backtraces.

Exceptions are an event stream: performance is not. This means that a great exception monitoring product likely has a very different experience than a great performance monitoring product. One doesn't build off the other.


Performance monitoring and exception monitoring are two very different problems that rarely overlap. Doing both together is hard: nearly two-thirds of customers using a combined APM+Excecption monitoring vendor end up paying for another exception monitoring service anyway. Finally, there's a wealth of solid, dedicated exception monitoring vendors.

Get notified of new posts.

Once a month, we'll deliver a finely-curated selection of optimization tips to your inbox.


comments powered by Disqus