One of the most difficult parts of starting a new job, I think, is to learn how to navigate the different tools and applications that are used to support the main app. Airbrake is one the tools that my team uses at Pingboard. As the Support Engineer, I was told that it would help me in a lot of troubleshooting situations.

I didn’t fully understand the purpose of Airbrake until a few months after I started. We have all of our app logs in a separate database, and I would scour those when troubleshooting an issue. Later, I learned that Airbrake is used to monitor only exception errors that occur. These are errors that we aren’t handling in the app somehow, and the customer usually doesn’t know what went wrong. We have a generic page that says something like “Oops! Something went wrong. Go back and try again”. This page shows up when a customer receives a 500 error from our server. Those errors are logged into Airbrake.

Airbrake lists all the unique errors and aggregates them so that you can view a timeline of how often a specific error occured. This is helpful when trying to hunt down a deploy that may have introduced a bug. It’s also useful to see the impact of a certain bug - how many users or customers is it affecting?

Not only does it show you a count of the errors, but you can view the stack trace of the exception error in the code to nail down the exact line of code that caused it. AWESOME!!

Airbrake can also log parameters or other data related to an exception error. Our Engineering team decided to not log this, as a lot of our customer data is sensitive and we don’t want it passed to other services. Instead, we have a few IDs that can help point us to the related data of an error.

Read more about the Airbrake product on their website.

Published 6 Mar 2019

<%= @today.i_learned %> An early-career Web Developer's discoveries in Ruby, Rails, Javascript, and React. Currently the Support Engineer @ Pingboard in Austin, TX. I just write what I learn and try not to overthink things.
Kelsey Huse on Twitter