EventMachine integration guide

Add Bugsnag to your EventMachine projects.


Bugsnag’s Ruby gem can be installed using Bundler by adding the gem to your Gemfile:

gem 'bugsnag-em'

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

Basic configuration

To identify your app in the Bugsnag dashboard, you’ll need to configure your Bugsnag API key. You can find your API key when creating a project in your Bugsnag dashboard, or later from your project settings page.

To set your API key in your app, add the following code to your entrypoint:

require 'bugsnag'

Bugsnag.configure do |config|
  config.api_key = 'YOUR_API_KEY_HERE'

Alternatively, you can set the BUGSNAG_API_KEY environment variable.

You can find your API key in Project Settings from your Bugsnag dashboard.

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

Reporting unhandled exceptions

To automatically capture unhandled exceptions in your EventMachine applications, you’ll need to implement EventMachine.error_handler:


If you’d like more fine-grained error handling, you can use the errback function, for example:

EventMachine::run do
  server = EventMachine::start_server('', PORT, MyServer)
  server.errback {
    EM.defer do
      Bugsnag.notify(RuntimeError.new('Something bad happened'))

For this to work, include Deferrable in your MyServer, then whenever you want to raise an error, call fail.

Reporting handled exceptions

Reporting handled exceptions can be accomplished as follows:

  raise 'Something went wrong!'
rescue => exception

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 calling Bugsnag.notify(), adding a custom skip_bugsnag property to your exception, and then re-raising the exception:

  raise 'Something went wrong!'
rescue => exception
  exception.instance_eval { def skip_bugsnag; true; end }

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

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 on your Bugsnag dashboard.

You can set this information using a Bugsnag.with block as follows:

Bugsnag.with(user: {id: 9000, email: "bugs.nag@bugsnag.com"}) do
  EM::next_tick do
    raise 'oops'

For more information, see reporting handled errors.

Sending diagnostic data

In order to quickly reproduce and fix errors, it is often helpful to send additional application-specific diagnostic data to Bugsnag. This can be accomplished using the Bugsnag.with call:

Bugsnag.with(user_id: '123') do
  # Your code here:
  http = EM::HttpRequest.new('http://google.com/').get
  http.errback{ raise 'oops' }

Tracking releases

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

Ensure you’ve set your app version within the application:

Bugsnag.configure do |config|
  config.app_version = '1.3.0'

Set up a build tool integration to enable linking to code in your source control provider from the releases dashboard, timeline annotations, and stack traces.

Catching JavaScript errors

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