By Today we're releasing a powerful new set of search features not only to help you find errors inside of Honeybadger, but to tell Honeybadger which errors you want to be notified of.
If there's one thing we've learned while building Honeybadger, it's that understanding and prioritizing data is hard. Not only must we find the relevant information and present it in a way which is understandable, but then we need to decide what to do with it; this is sometimes referred to as "signal vs. noise." We did our best to tackle these problems specifically for the Ruby community, and we think the results speak for themselves: in 5 minutes or less you can monitor your Ruby app for errors and other performance issues.
We also built a ton of options for when and how to be notified of errors, from email and SMS to GitHub, Jira, Slack, HipChat, and many more. One thing we noticed about our integrations is that we didn't always want the same notification everywhere; for example, sometimes we wanted errors from staging to show up on Slack, but only errors from production to be sent via email. To make matters worse, everyone had their own preferences. We built the ability to disable each notification individually for certain environments, but it was soon clear that our customers wanted even more control over what errors they were notified about.
Today we're excited to introduce two powerful new features:
A new query syntax for our existing (and awesome) error search.
Search filters for alerts and integrations.
Let's explain each in turn.
New query syntax
In addition to full-text search across many error attributes such as the class, message, params, and context, we've added a key:value token syntax to filter the results directly from your search query. Here's an example query:
ruby
request failed class:httperror -tag:wip -tag:postending component:userscontroller action:update
The first part of the query -- "request failed" -- is a full-text search. This works like it always has, and will return any results which include the words "request" and "failed" in the search index. The magic happens at class:HTTPError , which tells us to return only instances of class HTTPError . Next, "-tag:wip -tag:pending" both exclude any errors tagged with "wip" or "pending". Finally, we only want errors which happened in UsersController#update .
These tokens can be combined to form very finely-grained results. To learn more about what kinds of tokens you can use, check out the documentation.
Search filters for notifications
The new query syntax is pretty powerful, right? What if you could use the same queries to filter each type of error notification available in Honeybadger today for both personal notifications and project integrations?
Yeah, we wish we had that too 
.
Just kidding, we totally built that, and it's available today to plans Medium and above. When you edit your alerts and integrations under project settings you will now see a new section called "Error Filters":
To create a filter:
Choose which event you want it to apply to or choose "All events".
Enter a query just as you would when searching for errors.
Save your settings.
You should now receive notifications only when they match your new search filter. You can also add multiple filters per event, in which case you will be notified when the error matches any one of the filters for that notification.
On a recent JavaScript project I created a filter for "When a fault occurs" with a query of -class:window.onerror so that I wouldn't receive any more emails about window.onerror events, since they aren't typically very actionable on that project. That's just one of the myriad ways these filters can be combined to receive actionable alerts, though. Since you can send tags from our Ruby gem amd JavaScript notifiers, why not create a filter for all errors tagged with "slack" and then use the filter "tag:slack" to tell Honeybadger that Slack should be notified, for example?
That's right, it's time to get creative! We'd love to hear about how you find value in this feature. Feel free to drop us a line if you come up with a cool way to use the new filters.
Not using Honeybadger yet or need to upgrade? Check out our awesome error tracking plans!
