Sinatra Exception & Error Tracking

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.

On this page:

Installation

Using the Honeybadger gem with Sinatra

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

ruby
gem 'honeybadger'

Tell bundler to install:

bash
bundle install

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

bash
bundle exec honeybadger install [Your project API key]

This will do three things:

  1. 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.
  2. If Capistrano is installed, we'll add a require statement to Capfile.
  3. Send a test exception to your Honeybadger project.

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

ruby
# 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:

ruby
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):

html
<!-- 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):

yaml
# config/honeybadger.yml 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):

html
<!-- HONEYBADGER FEEDBACK -->

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

yaml
# config/locales/en.yml 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):

yaml
# config/honeybadger.yml 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:

ruby
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.