Common issues/workarounds are documented here. If you don't find a solution to your problem here or in our support documentation, email and we'll assist you!

Upgrade the gem

Before digging deeper into this guide, make sure you are on the latest minor release of the honeybadger gem (i.e. 3.x.x). There's a chance you've found a bug which has already been fixed!

Send a Test Exception

You can send a test exception using the honeybadger command line utility:

honeybadger test

How to enable verbose logging

Troubleshooting any of these issues will be much easier if you can see what's going on with Honeybadger when your app starts. To enable verbose debug logging, run your app with the HONEYBADGER_DEBUG=true environment variable or add the following to your honeybadger.yml file:

debug: true

By default Honeybadger will log to the default Rails logger or STDOUT outside of Rails. When debugging it can be helpful to have a dedicated log file for Honeybadger. To enable one, set the HONEYBADGER_LOGGING_PATH=log/honeybadger.log environment variable or add the following to your honeybadger.yml file:

logging: path: 'log/honeybadger.log'

Common Issues

My errors aren't being reported

Error reporting may be disabled for several reasons:

Honeybadger is not configured

Honeybadger requires at minimum the api_key option to be set. If Honeybadger is unable to start due to invalid configuration, you should see something like the following in your logs:

** [Honeybadger] Unable to start Honeybadger -- api_key is missing or invalid. level=2 pid=18195

Honeybadger is in a development environment

Errors are ignored by default in the "test", "development", and "cucumber" environments. To explicitly enable Honeybadger in a development environment, set the HONEYBADGER_REPORT_DATA=true environment variable or add the following configuration to honeybadger.yml file (change "development" to the name of the environment you want to enable):

development: report_data: true

The error is ignored by default

Honeybadger ignores this list of exceptions by default.

The error was rescued without re-raising

Honeybadger will automatically report exceptions in many frameworks including Rails, Sinatra, Sidekiq, Rake, etc. For exceptions to reported automatically they must be raised; check for any rescue statements in your app where exceptions may be potentially silenced. In Rails, this includes any use of rescue_from which does not re-raise the exception.

Errors which are handled in a rescue block without re-raising must be reported to Honeybadger manually:

begin fail 'This error will be handled internally.' rescue => e Honeybadger.notify(e) end

The configuration is being overridden

Check to make sure that you aren't overriding the honeybadger.yml configuration file via Ruby configuration using Honeybadger.configure, or using an environment variable (HONEYBADGER_API_KEY, for instance).

For example, the Honeybadger Heroku addon sets the HONEYBADGER_API_KEY config option automatically, so you must remove the addon (or the config option) if you switch to a Honeybadger project with a different API key.

A rake task is running in a local terminal

By default, the Honeybadger rake integration reports errors that happen when running outside of a terminal, such as in a cron job or scheduled task. The integration does not report errors which happen when running rake manually from a terminal (i.e., if you SSH into a production server to run the task).

To report exceptions all the time, set the exceptions.rescue_rake config option to true.

The better_errors gem is installed

The better_errors gem conflicts with the Honeybadger gem when in development mode. To be able to report errors from development you must first temporarily disable/remove the better_errors gem. Better Errors should not affect production because it should never be enabled in production.

I'm not receiving notifications

Likewise, if the error is reported but your aren't being notified:

The error was reported already and is unresolved

By default we only send notifications the first time an exception happens, and when it re-occurs after being marked resolved. If an exception happens 100 times, but was never resolved you'll only get 1 email about it.

SignalException or SystemExit is reported when a process or rake task exits

The Honeybadger gem currently ignores signal exceptions in our at_exit callback, which is installed by default whenever Honeybadger is loaded. We do not ignore these exceptions anywhere else, such as in Rake tasks. If you would like to ignore them globally, you can add the following configuration to honeybadger.yml:

exceptions: ignore: - !ruby/class 'SystemExit' - !ruby/class 'SignalException'


If the error is ignored by default

Honeybadger ignores this list of exceptions by default. It may be surprising that ActiveRecord::RecordNotFound is on that list; that's because in a Rails controller that error class is treated as a 404 not-found and handled internally (and thus we shouldn't report it). Support for Sidekiq and friends was added later and inherited the default. We would like to provide alternate defaults for job processors in the future, but for now you can provide your own list of ignored class names if you want to change this behavior:

HONEYBADGER_EXCEPTIONS_IGNORE_ONLY=Error,ClassNames,Here bundle exec sidekiq

Command line utility

If you get an error while running the honeybadger command line utility:

  1. Try prefixing the command with bundle exec...even if you normally rely on bin-stubs to do this for you
  2. Check honeybadger help if you're having trouble with the syntax for a specific command.
  3. Try enabling verbose logging to get more info
  4. Ask Us! We're always here to help. Just copy the terminal output and email it to us at

Wrong controller/action name is reported in Rails

If you're using config.exceptions_app, you may need some extra config to report the correct controller and action to Honeybadger. See the Rails integration guide.

My Issue Isn't Here

For a deep-dive into how the honeybadger gem works, check out the Architecture Guide. If you're stuck, shoot us an: