Errbit: a self-hosted, Airbrake-compatible error catcher

What Errbit is for, and who the README expects to run it

Errbit is a tool for collecting and managing errors from other applications. That sentence from the README is the whole product: your apps send exception notices, Errbit stores them, groups them, and shows them in a web UI with backtraces and a per-error summary. The Airbrake API compliance is the interesting part. Because Errbit speaks the Airbrake protocol, the README says you can point the airbrake gem at your Errbit server rather than at Airbrake's hosted service. The configuration instructions live in the repository at app/views/apps/_configuration_instructions.html.erb, which is a template rendered inside the app rather than a standalone document, so the per-app setup text is generated by the instance you are running.

The intended audience is narrow and the README does not soften it: this app is intended for people with experience deploying and maintaining Rails applications. If that is not you, the installation path will feel like a series of unexplained steps. If it is you, the shape of the thing is familiar: a Rails app, a MongoDB dependency, environment-variable configuration, and a bootstrap rake task. Errbit is not a hosted product with a signup page. It is a piece of infrastructure you own, patch and back up yourself.

How Errbit groups notices into errors

The mechanism that matters most day to day is fingerprinting. By default, Errbit uses the notice's error class, error message, complete backtrace, component (or controller), action and environment name to generate a unique fingerprint for every notice. Two notices with the same fingerprint are shown as separate occurrences of one error; notices with different fingerprints are shown as separate errors. That is why a single bug can appear as several entries if, for example, the same exception is raised from two controllers.

The fingerprinter is configurable under the Config menu, and since version 0.7.0 it can also be configured per app under the edit menu. There is a real operational consequence here that the README states plainly: changing the fingerprinter applies to all apps, and the change affects only notices that arrive after the change. Existing notices keep their old grouping until you run bundle exec rails errbit:notice_refingerprint to refingerprint them. On a large database that task is a migration-sized operation, not a toggle, so the decision about which fingerprinter you want is better made before you have months of notices stored.

Installing Errbit and getting a first notice in

The requirements list is short: Ruby 4.0 and MongoDB >= 7.0. The README's installation sequence starts with installing MongoDB, then cloning the repository and running three commands from inside it.

git clone https://github.com/errbit/errbit.git
bundle install
bundle exec rails errbit:bootstrap
bundle exec rails server

After bundle exec rails errbit:bootstrap you should have an initial admin user, and bundle exec rails server brings the web UI up on the Rails default port. The bootstrap task is the step that makes the app usable; skipping it leaves you with no way in.

If you would rather not install Ruby and MongoDB by hand, the repository ships a docker-compose.yml that defines only the database side. Note that the volume is declared external, so it must already exist before the stack starts.

volumes:
  errbit_mongodb_data:
    external: true

services:
  mongo:
    image: "mongo:8.3"
    ports:
      - "27017:27017"
    volumes:
      - "errbit_mongodb_data:/data/db:rw"

The compose file publishes MongoDB on port 27017 and uses the mongo:8.3 image, which satisfies the >= 7.0 requirement. There is also a Dockerfile in the repository that builds the Rails app itself on ruby:4.0.7-slim, and an app.json with a Heroku deploy button referenced from the README. Those are the three deployment routes the repository actually provides.

Configuration is done entirely through environment variables, per the README, with the details in docs/configuration.md. A .env.default file sits at the top level as a starting point. Authentication is optional but configured the same way. For GitHub sign-in you set GITHUB_AUTHENTICATION=true, register the instance at github.com/settings/applications/new with the callback URL https://errbit.example.com/users/auth/github/callback, then set GITHUB_CLIENT_ID and GITHUB_SECRET. The README also documents GITHUB_ACCESS_SCOPE, whose default of ['repo'] it calls very permissive, and GITHUB_ORG_ID, which restricts login to members of one GitHub organization and provisions accounts for new users. Google and LDAP paths exist too; the LDAP one requires editing config/initializers/devise.rb and adding an initializer before it will work.

Where Errbit is the wrong tool

Errbit stores errors and shows them to you. If you want alerting that pages someone at 3am, distributed tracing, span-level performance data, or release-health tracking tied to deploys, none of that is in the README, and the feature set described there is grouping, backtraces and a UI. Teams that have moved to OpenTelemetry-style instrumentation are not the audience.

The second limitation is operational. You are running a Rails app and a MongoDB database. That means backups, upgrades, a reverse proxy, TLS, and a MongoDB version you keep current. The README points at docs/deployment.md for deployment notes, but the repository does not hide the cost: the app is intended for people with experience deploying and maintaining Rails applications. A two-person team with no Ruby background will spend more time on the server than the errors it collects.

Third, the fingerprinter is a one-way door in practice. Changing it affects only new notices, and refingerprinting old ones is a separate rake task. If you tune grouping aggressively after six months of traffic, expect a period where the UI shows both old and new groupings side by side.

Finally, the README does not document rollback, data retention or a supported upgrade path between Errbit versions. There is a RELEASE.md in the repository and releases are tagged, most recently v0.11.5, but the README itself is silent on how to move an existing database forward. Treat that as something to work out from the release notes and the repository history rather than from the front page.

Errbit compared with Sentry and with Airbrake itself

The obvious alternative is a hosted error tracker, and the honest comparison is about who owns the data and who owns the pager. With Airbrake's own service, you point the same airbrake gem at their endpoint and someone else runs the storage, the UI and the upgrades. Errbit keeps the client-side integration nearly identical, because it implements the same API, and moves everything else onto your servers. The trade is straightforward: you keep the notices and you take on the operations.

Sentry is the other comparison worth making, and the difference is in the integration model rather than the feature list. Sentry's own SDKs are the primary path, with a different wire format and a different set of concepts; Errbit's selling point is that an application already instrumented with an Airbrake client needs no code change beyond the host it reports to. If your codebase is full of airbrake gem calls and you want to stop paying for the hosted endpoint without touching every one of them, Errbit is the shorter path. If you are starting fresh and want tracing and performance data in the same tool, Errbit is not that tool.

Within the self-hosted space, the practical question is whether you already run MongoDB. Errbit's data store is MongoDB >= 7.0 and nothing else, per the requirements list. A team standardized on PostgreSQL would be adding a second database engine purely for error notices.

Maintenance, licensing and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-09-23. Releases are tagged and reasonably close together: v0.11.3 on 2026-07-18, v0.11.4 on 2026-08-13, v0.11.5 on 2026-09-08. That cadence suggests the project is still being worked on, but the README gives no compatibility matrix for jumping versions, so the safe assumption is that an upgrade means reading the release notes and the diff between tags. There is a RELEASE.md in the repository that presumably describes the maintainers' own process.

The upgrade cost that is documented is the refingerprinting task. Any change to how notices are grouped, whether global or per app, only applies going forward, and bundle exec rails errbit:notice_refingerprint is the tool for rewriting history. Plan for that if you change the fingerprinter on a database with real traffic.

Licensing is MIT, per the repository's LICENSE file. That is permissive and imposes no copyleft obligation on your application code. It says nothing about the licences of the gems in Gemfile.lock or of the MongoDB server you run alongside it, and those are separate questions. The repository also carries a SECURITY.md, which is where a security report should go rather than into a public issue. None of this is legal advice; if the distinction between the MIT licence on Errbit and the licences of its dependencies matters to your organisation, that is a question for whoever handles licensing.

Editorial conclusion

Adopt Errbit if you already run Rails and MongoDB and you want error notices from Airbrake-instrumented apps landing on infrastructure you control. Do not adopt it if you have no Ruby or MongoDB operational experience, or if you need a hosted service with no server to keep patched. Before committing, verify that the airbrake client you actually ship points at a configurable host, confirm your MongoDB version is 7.0 or newer, and decide up front which fingerprinter you want, because the README states that changing it only affects notices that arrive after the change.

Frequently asked questions

Official sources

1. errbit/errbit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases