Elixir Plug, Logger and client for the ⚡ Honeybadger error notifier.

Watch our screencast by Josh Adams of ElixirSips!

Prerequisites: minimum of Elixir 1.0 and Erlang 18.0

Add the Honeybadger package to deps/0 and application/0 in your application's mix.exs file and run mix do deps.get, deps.compile

defp application do
 [applications: [:honeybadger, :logger]]
end

defp deps do
  [{:honeybadger, "~> 0.7"}]
end

By default the environment variable HONEYBADGER_API_KEY will be used to find your API key to the Honeybadger API. If you would like to specify your key or any other configuration options a different way, you can do so in config.exs:

config :honeybadger,
  api_key: "sup3rs3cr3tk3y"

We also need to set the name of the environment for each environment. This ensures that we can accurately report the environment that an error occurs in. You can add something like the following to each of your #{env}.exs files:

config :honeybadger,
  environment_name: :dev

If environment_name is not set we will fall back to the value of Mix.env(). Mix.env() uses the atomized value of the MIX_ENV environment variable and defaults to :dev when the environment variable is not set. This should be good for most setups. If you want to have an environment_name which is different than the Mix.env(), you should set environment_name in your config.exs files for each environment. This ensures that we can give you accurate environment information even during compile time. Explicitly setting the environment_name config takes higher precedence over the Mix.env() value.

The Honeybadger package can be used as a Plug alongside your Phoenix applications, as a logger backend, or as a standalone client for sprinkling in exception notifications where they are needed.

The Honeybadger Plug adds a Plug.ErrorHandler to your pipeline. Simply use the Honeybadger.Plug module inside of a Plug or Phoenix.Router and any crashes will be automatically reported to Honeybadger. It's best to use Honeybadger.Plug after the Router plugs so that exceptions due to non-matching routes are not reported to Honeybadger.

defmodule MyPhoenixApp.Router do
  use Crywolf.Web, :router
  use Honeybadger.Plug

  pipeline :browser do
    [...]
  end
end

defmodule MyPlugApp do
  use Plug.Router
  use Honeybadger.Plug

  [... the rest of your plug ...]
end

Just set the use_logger option to true in your application's config.exs and you're good to go! Any SASL compliant processes that crash will send an error report to the Honeybadger.Logger. After the error reaches the logger we take care of notifying Honeybadger for you!

You can manually report rescued exceptions with the Honeybadger.notify function.

try do
  File.read! "this_file_really_should_exist_dang_it.txt"
rescue
  exception ->
    Honeybadger.notify(exception)
end

If you'd like to see the module in action before you integrate it with your apps, check out our sample Phoenix application.

You can deploy the sample app to your Heroku account by clicking this button:

Don't forget to destroy the Heroku app after you're done so that you aren't charged for usage.

The code for the sample app is available on Github, in case you'd like to read through it, or run it locally.

Before data is sent to Honeybadger, it is passed through a filter to remove sensitive fields and do other processing on the data. The default configuration is equivalent to:

config :honeybadger,
  filter: Honeybadger.Filter.Default,
  filter_keys: [:password, :credit_card]

This will remove any entries in the context, session, cgi_data and params that match one of the filter keys. The filter is case insensitive and matches atoms or strings.

If Honeybadger.Filter.Default does not suit your needs, you can implement your own filter. See the Honeybadger.Filter.Mixin module doc for details on implementing your own filter.

You can set configuration options in config.exs. It looks like this:

config :honeybadger,
  api_key: "sup3rs3cr3tk3y",
  environment_name: :prod

Here are all of the options you can pass in the keyword list:

Use the Honeybadger.notify/2 function to send exception information to the collector API. The first parameter is the exception and the second parameter is the context/metadata. There is also a Honeybadger.notify/1 which doesn't require the second parameter.

try do
  File.read! "this_file_really_should_exist_dang_it.txt"
rescue
  exception ->
    context = %{user_id: 5, account_name: "Foo"}
    Honeybadger.notify(exception, context)
end

Honeybadger.context/1 is provided for adding extra data to the notification that gets sent to Honeybadger. You can make use of this in places such as a Plug in your Phoenix Router or Controller to ensure useful debugging data is sent along.

def MyPhoenixApp.Controller
  use MyPhoenixApp.Web, :controller

  plug :set_honeybadger_context

  def set_honeybadger_context(conn, _opts) do
    user = get_user(conn)
    Honeybadger.context(user_id: user.id, account: user.account.name)
    conn
  end
end

Honeybadger.context/1 stores the context data in the process dictionary, so it will be sent with errors/notifications on the same process. The following Honeybadger.notify/1 call will not see the context data set in the previous line.

Honeybadger.context(user_id: 5)
Task.start(fn ->
  # this notify does not see the context set earlier
  # as this runs in a different elixir/erlang process.
  Honeybadger.notify(%RuntimeError{message: "critical error"})
end)

If your server needs a proxy to access honeybadger, add the following to your config

config :honeybadger,
  proxy: "url",
  proxy_auth: {"username", "password"}

1. Set the HONEYBADGER_API_KEY as documented above
2. Remove :dev from the excluded_envs by adding this to your config/dev.exs

config :honeybadger,
  exclude_envs: [:test]

3. Run the mix honeybadger.test mix task task to simulate an error

• Erlang >= 18.0
• Elixir >= 1.3
• Plug >= 1.0
• Phoenix >= 1.0 (This is an optional dependency and the version requirement applies only if you are using Phoenix)

See https://github.com/honeybadger-io/honeybadger-elixir/blob/master/CHANGELOG.md

If you're adding a new feature, please submit an issue as a preliminary step; that way you can be (moderately) sure that your pull request will be accepted.

1. Fork it.
2. Create a topic branch git checkout -b my_branch
3. Commit your changes git commit -am "Boom"
4. Update the Changelog
5. Push to your branch git push origin my_branch
6. Send a pull request

1. Update the version property in mix.exs
2. Create a git commit with all the changes so that your working directory is clean
3. Run mix release from your terminal, which will do the following:
   1. Upload the new version of honeybadger to hex.pm
   2. Create a git tag with the version number and push it to GitHub

This library is MIT licensed. See the LICENSE file in this repository for details.