Honeybadger has deep support for a wide variety of third-party integrations. This page provides an overview of some cool features available for every integration.
You get to choose exactly which events result in a notification or ticket being created:
Escalations let you receive extra notifications when your error rate goes above a number you’ve configured.
Lets you protect yourself from floods of notifications when everything goes wrong at once.
With filters you can be hyper-precise about which errors trigger notifications or issue creation. You could
- Create issues in separate trackers for staging, preprod and production
- Route notifications to a certain team’s inbox whenever an error assigned to that team reoccurs.
The syntax for channel filters is essentially the same as our search syntax, with a few limitations:
- You can’t filter on params, context, session or other per-notice data
- Filters don’t support freeform text search. You must use the
Below is a list of fields you can use when constructing your queries.
Note that you can prefix any query with
- to create its inverse.
||Errors assigned to anyone|
||Errors assigned to a specific person|
||Errors occurring in production|
||Errors with a certain class|
||Errors with a tag|
||Errors with a message|
||Errors occurring in a controller/component|
||Errors occurring in an action|
Multiple filters are evaluated using a logical OR.
If any query matches the error, a notification will be sent.
When using negative queries like
-class:Foo, this OR behavior can give unexpected results.
To combine multiple negative matches, use a single filter with a search term like
-class:"Foo" AND -class:"Bar".
You can ignore environments. We auto-populate the list based on environments we’ve seen in your app.
For some of our integrations, we allow the option to provide a custom format for specific fields (e.g., email subject line or Trello card title). Your custom format will be used for all events that are applicable for the integration (reported, assigned, marked as resolved, etc).
The following is a list of valid formatter tokens:
|[project]||The project name|
|[environment]||The operating environment — production, development, etc.|
|[type]||The event type — occurred, assigned, etc.|
|[class]||The class of the error associated with the event|
|[message]||The message of the error associated with the event|
|[component]||The component name (might be null, usually maps to the controller name)|
|[action]||The action name (might be null, usually maps to the controller action e.g.
|[fault_id]||A unique id for the fault event|
|[file]||The filename with path and line number where the error occurred|
|[backtrace]||The backtrace of the error associated with the event (first 3 lines)|
|[url]||The URL of the event in the Honeybadger UI|