*This blog post was prepared by one of Airbrake awesome users; Federico Saravia.
At Citrusbyte, we’ve been using Airbrake for years, on a variety of projects, including AT&T mHealth and AT&T M2X. It has made our lives easier from Day 1. Now, we want to share our story and what we have learned along the way to help YOU take full advantage of this awesome service.
Errors are a common thing in complex software projects — your team can (and should) work hard to squash them before reaching production. But, from time to time, a nasty little bug may make it to production and give you and your users a hard time.
Software bugs in production are often really hard to identify, especially because they often have really low visibility due to some the following factors:
- Your users are the ones stumbling on them and their bug reports are not always accurate enough.
- They often occur in edge case scenarios and are difficult to reproduce.
- You may not know exactly when they occurred.
- You will need to spend long hours looking at logs in order to find a clue into what happened.
For this and many other reasons, it seems downright crazy not to use an error service that helps you address these issues and makes it easier for you to find and squash bugs faster and more easily. We chose Aibrake because it has a lot of powerful features that make it really easy to deal with errors and lets us know right away when something goes wrong.
Here is how we are using Airbrake to make sure our application is always error free:
Whenever an error occurs, everyone in the team gets an email from Airbrake with a brief description that points us to what’s going on. These are really important because we get to identify and fix an error right away without letting it affect more users.
Every error in Airbrake is displayed with a lot of contextual information that can be very valuable to identify what happened, when, and where. We get to know exactly which server is experiencing issues, when the issue started and how many times it occurred.
Error reports can also contain additional parameters which are automatically collected by the Airbrake client. These can include things like the whole request context, the server’s environment and pretty much everything you need to identify exactly what happens.
Last but not least, you get the whole backtrace exactly as you will find it in a log file but in a much nicer, easier to read format. Cool, huh?
Sometimes, the contextual information collected by default is not enough to identify the problem. You may need to know the value of that exact variable or inspect the whole result from a database query. This is when sending additional parameters can come in handy. Take a look into Airbrake’s KB for more information how to do it.
Exceptions may be the most common errors but they are not the only thing that can go wrong in an application. What if we just need to be sure all items in a batch job have been processed but can’t raise an exception when only a couple failed? You can leverage Airbrake’s client and report almost everything you need. Checkout “Useful custom error messages with Airbrake” to learn more.
Did you find more information about an error and want to share it with the team, or let everyone know how an error was fixed? You can add comments for every occurrence of an error and they will be stored within it, expanding the error’s contextual information.
If you already fixed one or more errors, you can mark them as resolved in the UI — this will help you keep things clean and focused on issues that still need resolution. If a resolved error happens again, Airbrake will take care of marking it as unresolved and will send you another notification right away so that you don’t miss anything.
Don’t want to get notified by email or feel that it isn’t enough? Take a look at Airbrake’s available integrations for a list of third party applications and tools to which Airbrake can send reports. You can choose from automatically creating an issue in GitHub to receiving notifications in a Slack channel — there is no way you will miss that next error!
Airbrake is not only useful for reporting errors that happen on a remote server, you can also use it in your local development environment and have instant access to all the goodies in their UI for debugging an application. Just create a new project, add the token to your local environment et voila! You can even share the full context of a development error with your team in a really easy and useful way.
Using Airbrake’s error service is a real lifesaver when dealing with software errors — it takes a common but annoying problem and turns it into something easy to manage and fix. Go ahead and give it a try! They are always happy to receive feedback from their users.
Guest author Federico Saravia is a software engineer who works at Citrusbyte. When he’s not spending time with his family he likes to read books and learn new things. He writes software for fun and profit and from time to time he writes technical articles on the Internet. He likes to spend his free time on the outdoors doing sports or playing with his dogs.
Interested in writing for Airbrake Blog? Send us a pitch!