Sinatra integration guide

Typical installation time: 3 minutes

Hi there! You’ve found Honeybadger’s guide to Sinatra exception and error tracking. Once installed, Honeybadger will automatically report exceptions wherever they may happen:

During a web request
In a background job
In a Rake task
When a process crashes (at_exit)

If you’re new to Honeybadger, read our Getting Started guide to become familiar with our Ruby gem. For a refresher on working with exceptions in Ruby, check out the Honeybadger guide to Ruby exceptions.

Installation

The first step is to add the honeybadger gem to your Gemfile:

gem 'honeybadger'

Tell bundler to install:

bundle install

Next, you'll set the API key for this project.

bundle exec honeybadger install [Your project API key]

This will do three things:

Generate a honeybadger.yml file. If you don't like config files, you can place your API key in the $HONEYBADGER_API_KEY environment variable.
If Capistrano is installed, we'll add a require statement to Capfile.
Send a test exception to your Honeybadger project.

Finally, require the honeybadger gem in your app after requiring the sinatra gem:

# Always require Sinatra first.
require 'sinatra'
# Then require honeybadger.
require 'honeybadger'
# Define your application code *after* Sinatra *and* honeybadger:
get '/' do
  raise "Sinatra has left the building"
end

Identifying users

If you’re using the devise or the warden gems for user authentication, then we already associate errors with the current user.

For other authentication systems (or to customize the user values), use Honeybadger.context to associate the current user:

Honeybadger.context({
  user_id: current_user.id,
  user_email: current_user.email
})

Collecting user feedback

The Honeybadger gem has a few special tags that it looks for whenever you render an error page in a Rack-based application. These can be used to display extra information about the error, or to ask the user for information about how they triggered the error. Honeybadger automatically installs the middleware for these in your Sinatra project.

Displaying the error ID

When an error is sent to Honeybadger, our API returns a unique UUID for the occurrence within your project. This UUID can be automatically displayed for reference on error pages.

To include the error id, simply place this magic HTML comment on your error page (normally public/500.html in Rails):

<!-- HONEYBADGER ERROR -->

By default, we will replace this tag with:

Honeybadger Error {{error_id}}

Where {{error_id}} is the UUID. You can customize this output by overriding the user_informer.info option in your honeybadger.yml file (you can also enabled/disable the middleware):

user_informer:
  enabled: true
  info: "Error ID: {{error_id}}"

You can use that UUID to load the error at the site by going to https://app.honeybadger.io/notice/some-uuid-goes-here.

Displaying a feedback form

When an error is sent to Honeybadger, an HTML form can be generated so users can fill out relevant information that led up to that error. Feedback responses are displayed inline in the comments section on the fault detail page.

To include a user feedback form on your error page, simply add this magic HTML comment (normally public/500.html in Rails):

<!-- HONEYBADGER FEEDBACK -->

You can change the text displayed in the form via the Rails internationalization system. Here’s an example:

en:
  honeybadger:
    feedback:
      heading: "Care to help us fix this?"
      explanation:
        "Any information you can provide will help us fix the problem."
      submit: "Send"
      thanks: "Thanks for the feedback!"
      labels:
        name: "Your name"
        email: "Your email address"
        comment: "Comment (required)"

The feedback form can be enabled and disabled using the feedback.enabled config option (defaults to true):

feedback:
  enabled: true

Content Security Policy reports

You can use Content Security Policy headers to help mitigate XSS attacks, and the SecureHeaders gem makes it easy to emit those headers from your Sinatra application. When a policy includes a report-uri or report-to directive, reports about blocked resources can be sent to a URL:

require 'rubygems'
require 'sinatra'
require 'secure_headers'

use SecureHeaders::Middleware

SecureHeaders::Configuration.default do |config|
  ...
  report_uri: "https://api.honeybadger.io/v1/browser/csp?api_key=HB_API_KEY_GOES_HERE&report_only=true&env=#{ENV['RACK_ENV']}"
end

Every parameter in the URL is optional, aside from the api_key parameter. If you don’t need the value to be generated at request time (as in this example, to report the current user’s id), then you can provide a simple string as the argument to report_uri. If you set the report_only parameter to true, then our UI will label reports as “CSP Report”; otherwise, they will be labeled as “CSP Error”.

CSP Reports and Errors show up with the rest of your app’s errors in the Honeybadger UI. For this reason, and since CSP reports can be very numerous, we recommend you create a separate Honeybadger project specifically for CSP reports.