OpenSourcePicks

Open source alternatives to popular software, with live GitHub data

GitHub stats refreshed every day

Solid Errors

Database-backed exception tracker that runs inside your Rails application

Visit Solid ErrorsGitHubDocumentation

Main features

  • Records exceptions through the Rails error reporting API
  • Stores errors in a separate database or the primary one
  • Dashboard of unresolved errors with a detail view per error
  • Resolve errors; recurring ones are reopened
  • Email for every occurrence or only new and reopened errors
  • Active Support notifications for custom Slack or webhook alerts
  • Controller action or background job recorded with each occurrence
  • Opt-in recording of params and job arguments, with parameter filtering
  • Automatic deletion of old resolved errors
  • Overridable views

What Solid Errors does

Solid Errors is a Ruby gem that makes a Rails application track its own exceptions. It subscribes to the error reporting API built into Rails, so uncaught exceptions and anything passed to Rails.error.handle, Rails.error.record or Rails.error.report are saved to a database, grouped under the error they belong to, and shown in a dashboard mounted inside the app. There is no separate server, agent or account.

The scope is deliberately narrow. The README says the gem lets you view and resolve errors and little else, and points teams that need more to a hosted service. The dashboard has two screens: a list of unresolved errors and a detail page with the occurrences, backtraces and context. Each occurrence records whether it came from a request (with the controller action) or a background job (with its class, id and queue). Errors raised in jobs are captured when the job backend runs inside the Rails executor, which the README says Solid Queue, Sidekiq and GoodJob do.

Privacy and data

Because the data stays in your own database, nothing is sent to a third party. The defaults are also careful about personal data: request params and job arguments are not stored unless you switch them on, and then Rails’ filter_parameters is applied. The README explains why: positional job arguments, mail jobs and webhook payloads can contain user content that key-based filtering does not catch. Active Record objects in the context are stored as Global IDs rather than copied.

A destroy_after setting deletes resolved errors older than a chosen duration. The dashboard has no access control by default, so you must protect it with HTTP basic authentication, a Devise route constraint or your own admin controller.

Notifications

If ActionMailer is set up, Solid Errors can email a list of addresses for every occurrence or only when an error is new or reopened, with a configurable subject. For Slack, webhooks or other channels it publishes Active Support notifications when an error is created, reopened or resolved and for every occurrence; you subscribe to them in an initializer and send the message yourself.

Installing Solid Errors

It runs inside the app, so installing it is part of a normal deploy: add the gem, run the install generator, add an errors database to database.yml (SQLite, MySQL, Trilogy or PostgreSQL), run db:prepare and mount the engine. A separate database is recommended, but the tables can also live in the primary one. The gemspec requires Rails 7.1 or later and Ruby 3.2 or later. Schema changes between versions are described in an upgrade guide, and a helper lets your test suite fail until a migration has been applied.

Hosted version

There is no hosted service, because Solid Errors is a library that runs inside your own Rails application.

Limitations

Solid Errors only works for Rails, and only for the application it is installed in, so it cannot collect front-end JavaScript errors or errors from other services. It has no search, charts, release tracking or source maps, and the only built-in alert channel is email. The dashboard is unprotected until you configure authentication.

Who it suits

Solid Errors fits small and medium Rails applications, especially single-server apps on SQLite, whose teams want a record of production exceptions without another service to run or a vendor to send data to. For a standalone server that several Ruby apps can report to, see Errbit; the error tracking guide compares the approaches.

Technical details

Self-hosting needs

  • Rails 7.1+
  • SQLite
  • MySQL or PostgreSQL

Built with

  • Ruby
  • Ruby on Rails

Reviewed by the OpenSourcePicks editors from the project's repository and documentation. Something out of date? Tell us.