Rails integration guide

Add Bugsnag to your Ruby on Rails projects to automatically monitor exceptions in your Rails applications.

New to Bugsnag? Create an account now.

Installation

Add the bugsnag Ruby gem to your Gemfile:

gem 'bugsnag'

Don’t forget to run bundle install after updating your Gemfile.

Basic configuration

Run our generator to create the config/initializers/bugsnag.rb configuration file and set your project’s integration API key:

$ rails generate bugsnag YOUR_API_KEY_HERE

Alternatively, you can set the BUGSNAG_API_KEY environment variable.

You can find your integration API key immediately after creating a new project from your Bugsnag dashboard, or later on your project’s settings page.

Further configuration

If you’d like to configure Bugsnag further, check out the configuration options reference.

Reporting unhandled exceptions

After completing installation and basic configuration, unhandled exceptions in your Rails app will be automatically reported to your Bugsnag dashboard.

Exceptions in Sidekiq, Resque, Delayed Job, Mailman, and Rake will also be automatically reported.

Reporting handled exceptions

Reporting handled exceptions can be accomplished as follows:

begin
  raise 'Something went wrong!'
rescue => exception
  Bugsnag.notify(exception)
end

Adding diagnostics or adjusting severity

It can often be helpful to adjust the severity or attach custom diagnostics to handled exceptions. For more information, see reporting handled errors.

Avoiding re-notifying exceptions

Sometimes after catching and notifying a handled exception you may want to re-raise the exception to be dealt with by your standard error handlers without sending an automatic exception to Bugsnag. This can be accomplished by setting a skip_bugsnag property on the exception to true as follows:

begin
  raise 'Something went wrong!'
rescue CustomException => exception
  Bugsnag.notify(exception)
  exception.skip_bugsnag = true

  # Now this won't be sent a second time by the exception handlers
  raise exception
end

Sending diagnostic data

Automatically captured diagnostics

Bugsnag will automatically capture and attach the following diagnostic data to every exception report:

  • A full stacktrace
  • Request information, including ip, headers, URL, HTTP method, and HTTP params
  • Session data
  • Release stage (production, beta, staging, etc)
  • Hostname

Attaching custom diagnostics

It can often be helpful to attach application-specific diagnostic data to exception reports. This can be accomplished as follows:

class ApplicationController < ActionController::Base
  before_bugsnag_notify :add_diagnostics_to_bugsnag

  # Your controller code here

  private
  def add_diagnostics_to_bugsnag(report)
    report.add_tab(:diagnostics, {
      product: current_product.name
    })
  end
end

For more information, see customizing error reports.

Identifying users

In order to correlate errors with customer reports, or to see a list of users who experienced each error, it is helpful to capture and display user information:

If you are using the Devise, Warden, or Clearance authentication frameworks, we will automatically capture information about the currently authenticated user. Otherwise, you can set this information as follows:

class ApplicationController < ActionController::Base
  before_bugsnag_notify :add_user_info_to_bugsnag

  # Your controller code here

  private
  def add_user_info_to_bugsnag(report)
    report.user = {
      email: current_user.email,
      name: current_user.name,
      id: current_user.id
    }
  end
end

For more information, see customizing error reports.

Session tracking

Bugsnag can track the number of “sessions” that happen in your application. This enables Bugsnag to provide and compare crash rates between releases to help you understand the quality of your releases. This functionality is disabled by default, but can be enabled through the configuration:

Bugsnag.configure do |configuration|
  configuration.auto_capture_sessions = true
end

Using this option, Bugsnag will report a session each time a request is made to the server.

If you want control over what is deemed a session, rather than using the auto_capture_sessions option, you can call Bugsnag.start_session when appropriate for your application.

Tracking deploys

By sending your source revision or application version to us when you deploy a new version of your app, you’ll be able to see which deploy each error was introduced in, or seen in.

Find information on how to track deployment using Capistrano in our how to track deploys using Capistrano

If you are using a deployment system other than Capistrano, see our deploy tracking guide.

Catching JavaScript errors

Catch and report errors in your client-side JavaScript with the Web browser JavaScript guide