Troubleshooting
Common issues/workarounds are documented here. If you don't find a solution to your problem here or in our support documentation, email support@honeybadger.io 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'
- Related: #306
Sidekiq/Resque/ActiveJob/etc.
- See Common Issues
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:
- Try prefixing the command with
bundle exec
...even if you normally rely on bin-stubs to do this for you - Check
honeybadger help
if you're having trouble with the syntax for a specific command. - Try enabling verbose logging to get more info
- Ask Us! We're always here to help. Just copy the terminal output and email it to us at support@honeybadger.io
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.
- Related: #250
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: support@honeybadger.io