Designing metrics for developers

At Opbeat, we constantly think about how we can help developers better understand how their app is performing, which issues an app has, and how pressing they are. And for a long time, we have thought that developers deserve a better, simpler solution for application performance metrics. Something that is built for developers not system administrators, and easy to use by solo developers and teams alike.

Opbeat Application Performance Metrics

Last week, we released metrics for Django developers on Opbeat. We listened to what developers said they really wanted, what the best features of the competition are, and ruthlessly cut away anything unnecessary.

Doing our research, we had a clear image of what we should focus on building, summed up perfectly by one user:

I want to see which part of my app is slowest and used by the most people, so I know what to work on next.

This led the design phase: How could we could solve that problem with as few features as possible? We saw these form the basis of the solution:

Display response times for views in the users’ apps with the number of requests for those views.

Response times will tell you how much time is spent serving a part of your app. As an example, we can time how long it takes Opbeat to display a list of your open errors, sorted by last occurrence. Displaying that list requires a lot of moving parts in each of the requests, from the code that needs to run, to the database being called.

The number of requests can give you an indicator on how popular a particular part of your app is. The open error list is one the most popular pages in Opbeat, and one of the most complex, so it is natural for us to spend some time making sure it is served as fast as possible.

Combining those two data points, response times and number of requests, we got exactly what our user was looking for: The slowest views that are used the most.

There are a couple of variants of this measurement, with Apdex being a popular, but overly complex one for our case. Other services have called the measurement “agony”, which is somewhat fitting, given that you calculate slow views used by many people. However, it carries some negative connotations that did not feel right to us.

That is how we came to “Impact”, which is the default sorting order for the list of views we have measured in your app. You want your work to have impact, so start at the top of the list to get the most out of it.

We want to give you everything you need to run your app as smoothly as possible, and what we released last week is just the start. We can not wait to show you what is next.

About the author
Mark Jensen is a product designer and code enthusiast who runs to eat.
You can follow him on Twitter or his blog.