Error Monitoring

Installation

Before you can start using Honeybadger to squash bugs, you'll need to install our library into your app. Installation ususally boils down to:

  1. Installing the honeybadger library
  2. Setting the API key
  3. Enabling error reporting

The details vary a little depending on language and platform. But you can always find the correct installation instructions for YOUR app on the "Project Settings" page.

In case you're wondering, we officially support: Ruby, client-side JavaScript, Vue, Elixir, Go, NodeJS, Java, Python, PHP, Clojure and Cocoa.

Once our client library is installed and configured, errors thrown by your application are automatically sent to our API.

Error Grouping

Honeybadger groups similar exceptions together using rules which we've found to work the best in most cases. The default information we use to group errors is:

  1. The file name, method name, and line number of the error's location
  2. The class name of the error
  3. The component/controller name

We use this information to construct a "fingerprint" of the exception. Exceptions with the same fingerprint are treated as the same error in Honeybadger.

You can customize the grouping for each exception by changing the error class name, component, or stack trace—or by sending a custom fingerprint.

Anatomy of an error

When your app reports an error to us, we make the details available on a web page that looks like this:

Error Detail Page Overview

Yeah, it looks a little complicated. But once you understand what all the pieces are, you'll see it's quite simple.

Let's inspect this page, piece by piece.

Honeybadger groups identical errors together. Using our navigation bar, you can still navigate between each individual occurrence of the error.


Resolve / Unresolve

When an error is marked "unresolved" we won't send you any additonal notifications when it re-occurs. Errors are ususally auto-resolved on deploy.

Resolved and Unresolved

Actions

Here you can perform many of the actions available to your error. Also, as you set up integrations for the project, any that can link back to the error (say, an issue tracker like GitHub) can be managed here.

Error actions

Pause or Ignore an Error

Speaking of actions, one of the more common ones is to ignore the occurrences an error.

Pausing

You can choose to "Pause" for a time duration or occurrence count. We will still record the occurrences, we just won't notify you.

Ignoring

When you "ignore" an error we will stop recording altogether, so it won't go against your quota.


Export an Error

Clicking the Export button will queue a process that will export the data for all the ocurrences for the error. You will receive an email within minutes that will allow you to download a JSON file containing the data. This file is a newline-delimited JSON file, which means each line is a valid JSON object. Each of those JSON objects has the data (parameters, context, etc.) for a single occurrence of the error.

Resolve on Deploy

By default, Honeybadger resolves all the errors in your project when you report a deployment, causing new alerts to be sent for any of the errors that re-occur. You can turn off this behavior by unchecking the "Resolve on deploy" checkbox in Project Settings. When turned off, there is a new action in the actions area of the error detail page, allowing you to resolve individual errors on the next deploy.

Error actions resolve on deploy

Notices

Notices are the individual error events that are sent from your app. We also refer to them as occurrences as well.

The Notices section allows you to see the distribution of occurrences over time. You can constrain the dates and filter using the same search criteria as our error search.

Notices

Comments

Communicate with team members, or record notes to retain context around an error. Your comments can be formatted in Github flavored markdown.

Comments

Backtrace

Each line in the backtrace links to the github or bitbucket repo. You can even click a button to open the file in your local editor.

Backtrace

Request Params, Cookies, ENV, etc.

When an error occurs during a web request, we record all the relevant debug info like params, cookies, the session, etc.

Params

Context Data

Our clients support providing a special set of data called context. This data is provided by you to help with debugging. You can use our search functionality to find errors with specific context.

user_id and user_email are special context keys that we use to help with looking up users or sending emails (as you can see below.)

Context

Browsing errors

Once you start collecting errors, it can be difficult to keep track of them. To make it easier, we've built a great interface for browsing and searching errors.

Navigating Errors

With advanced search, you can search by any field of params, environment, cookies or the session. Check out our dedicated search guide for more info.

Batch actions

You can use the Bulk Update dropdown to update multiple errors simultaneously. You can apply actions to all search results (this is the default), or you can use the checkboxes in the error list to apply the actions to selected errors.

  1. Use the search to select which errors you'd like change.
  2. Click on "Actions" and select one or more options from the drop-down.

Image of actions drop-down

Merging errors

You can merge two or more errors to create a single error. There are two ways to merge errors:

  1. Click the Merge button in the Actions panel on the error detail page.
  2. Select two or more errors to merge from the error index page using the checkboxes and use the "Merge to" action in the Bulk Update dropdown.

Note: The Bulk Update method can merge up to ten thousand error occurrences simultaneously. You can perform multiple updates if necessary.

Content Security Policy Reports

If you use Content Security Policy (CSP) headers to help mitigate XSS attacks, you can use Honeybadger to track policy violations. You can configure the required headers via code when using Rails or Sinatra, or you can configure your web server or framework to emit the headers. Either way, configuring CSP reporting requires specifying the report-uri directive:

Content-Security-Policy: ...; report-uri https://api.honeybadger.io/v1/browser/csp?api_key=HB_API_KEY_GOES_HERE&env=production Content-Security-Policy-Report-Only: ...; report-uri https://api.honeybadger.io/v1/browser/csp?api_key=HB_API_KEY_GOES_HERE&report_only=true&env=production

The env and report_only parameters are optional. When report_only is true, CSP report payloads will show up as "CSP Report" in our UI; otherwise, the label will be "CSP Error".

Since CSP violations can be noisy, we strongly suggest you track them in a separate Honeybadger project.

Local Edits

One of the advanced features in Honeybadger is configuring your local editor settings so that we can display links to open files locally when showing you an error backtrace:

To configure your editor, visit the Editor Settings page under My Profile. Select the editor you use (if you use a different editor which supports opening files via a custom protocol, let us know about it. Next, enter the absolute path to each project you wish to enable local editor links for, and click "Save" at the bottom. Re-visit your error pages - they should now have the "Open in editor" links!

If you're using TextMate or MacVim, you should be all set. Sublime and Visual Studio Code don't ship with a custom protocol by default. In order to make them work, you'll need to install one of these libraries:

If you're using Atom, make sure you're on version 1.23 or later for this to work.

Disclaimer: We do not endorse nor support these libraries; they are 3rd party open source software.