Logster: a log viewer you mount inside a Rails app

An exception reporter that lives inside the application

Logster is described in the README as an embedded Ruby exception reporting service that admins can view on live websites, at a path like http://example.com/logs. The word embedded is the whole design decision. There is no separate service to sign up for, no project key to paste into a dashboard, and no data leaving your infrastructure, because the log viewer is a Rack application mounted inside the one you already have. The audience is a team that wants a live error view on its own domain and is unwilling to ship application exceptions to a third-party error tracker, whether for compliance reasons, for a data-residency requirement, or simply for cost. The gem is MIT licensed, the default branch is main, and the last push to the repository was on 2026-10-21. The project also maintains a website directory and a client-app directory in the repository, which tells you the browser side of the viewer is a separate front end rather than server-rendered pages.

Redis is the storage layer, and the Gemfile says so

The installation is two gems and a bundle. The README tells you to add these lines to your application's Gemfile.

gem 'redis'
gem 'logster'

And then to execute the bundle command.

$ bundle

The redis dependency is not incidental, it is the store where the messages live, so an application that wants Logster needs a Redis instance. That is a real operational dependency for what looks like a UI addition, and it is the first thing to check. The gem also pulls in the pieces a Rack application needs for the viewer, and the repository layout shows the shape of it: lib/ for the gem, client-app/ for the browser application, assets/ for the compiled front end, a build_client_app.sh script and a frontend_assets.rb file for building and serving those assets, and a dev_server_process.rb for local development. The gemspec and the Gemfile are at the top level, with gemfiles/ holding alternative dependency sets and test/ holding the test suite.

Mounting the viewer behind your own admin check

The web interface is a Rack app you mount, and the README's example shows the constraint wrapper that keeps it out of reach of ordinary visitors.

constraints lambda { |req| req.session["admin"] } do
  mount Logster::Web => "/logs"
end

The point of the constraints block is that Logster does not authenticate anybody itself. Your application's session is what decides whether the request reaches the viewer. A second, optional layer exists in the configuration, where Logster.config.authorize_request is described as an optional defense-in-depth authorization callback that receives the Rack environment and must return a truthy value to allow access. The documentation is explicit that the application must still mount Logster behind its normal administrator authentication constraint, so the callback is a second check rather than a replacement. There is also a default for the environments the gem runs in: development and production only, which you widen in config/application.rb with Logster.set_environments([:development, :staging, :production]) when you want staging to report as well.

Grouping, truncation and the limits that bite

Several configuration options exist purely to stop the log from growing without bound, and they are the settings you will argue about. Logster.config.maximum_message_length caps the length of log messages shown in the info tab and in the message rows, with a default of 2000, and anything longer is truncated with an ellipsis. Logster.config.maximum_message_size_bytes caps the size of a message object, with a default of 10,000, and when a message exceeds it Logster first removes all occurrences of the gems_dir path from the backtrace and recomputes, and only then removes as many characters as needed from the backtrace. The documentation explicitly discourages setting that limit to a really low value, because a message needs a minimum amount of data to make sense, and the closer the limit sits to that minimum the more backtrace you lose. Logster.config.max_env_bytes caps the size of env with a default of 1000, keeping the biggest subset of key-value pairs that fits, and always keeping a key named time.

Grouping similar messages and keeping a bounded env list

Two more options deal with repetition. Logster.config.allow_grouping enables grouping of similar messages into one message with an array of env hashes holding the grouped entries, where similar means identical backtraces, severity and log message, which is the standard definition of a duplicate error. The size of that array is bounded by Logster.config.max_env_count_per_message, with a default of 50. When the limit is reached and another similar message arrives, Logster removes the oldest env hash from the grouping message and adds the new one, so the grouping keeps the most recent context rather than growing. A related option is Logster.config.application_version, a unique identifier for the version of your app, which the solve function takes into account when suppressing errors, so an error already reported for one release is not re-reported for every deploy of the same code.

Backtrace links to GitHub and the custom pattern editor

The feature that makes Logster more than a text log is Logster.config.project_directories, an array of hashes mapping paths on the local filesystem to GitHub repository URLs. When it is enabled, Logster parses backtraces and constructs a GitHub URL for the exact file and line number of each backtrace line. The README's Rails example maps Rails.root.to_s to a repository URL, and notes that the constructed links use the master branch, with a main_app option that instead uses the application_version attribute from the env tab so the link points at the exact version of the app that produced the message. The feature can be switched off with Logster.config.enable_backtrace_links. Alongside it there is Logster.config.enable_custom_patterns_via_ui, which turns on a settings page at /settings where you can add suppression and grouping patterns, so you can teach the viewer to ignore a noisy exception without a deploy.

JavaScript error reporting and the HTTP request rules

Client-side errors can be reported too, through Logster.config.enable_js_error_reporting, with Logster.config.rate_limit_error_reporting controlling automatic one minute rate limiting for that reporting. The request rules for the viewer are described in a dedicated section, and they matter if you write your own integration. The supplied browser client sends mutating viewer requests with their required HTTP methods and the X-Requested-With: XMLHttpRequest header, and custom viewer integrations must do the same. JavaScript error reports may use that header or a browser-verified Sec-Fetch-Site: same-origin request, which allows same-origin navigator.sendBeacon reporting. Cross-site fetch metadata and mismatching origins from clients without same-origin fetch metadata are rejected. The rates themselves are registered as callbacks, and the buckets available are one minute and one hour.

Logster.register_rate_limit_per_minute(Logger::WARN, 60) do |rate|
  puts "O no! The error rate is now #{rate} errors/min"
end

A second form registers several severities at once, with an array of levels against an hourly bucket.

Supported versions, and a conflict that bites at install time

Logster supports maintained release series only, and the list is short: Ruby 3.3, 3.4 and 4.0, Rails 8.0 and 8.1, Rack 3.1 and 3.2, redis-rb 6.x and Redis Open Source 8.10. The rule behind the list is stated plainly, that support for a release series ends when its upstream security support ends, and Ruby head is tested proactively with the CI matrix named as the source of truth for the combinations covered. That last point is the practical instruction: rather than trusting a version list in a README, read the CI matrix to see what is actually exercised.

There is one installation trap documented at the end. If you see the error No such middleware to insert before: ActionDispatch::DebugExceptions after installing Logster, then you are using a conflicting gem such as better_errors or web-console, and the fix is to remove or disable the conflict rather than to change Logster. A gem that inserts middleware into the Rails stack can collide with another gem that does the same, and the error message points at the other gem rather than at yours.

Editorial conclusion

Logster fits a Rails or Rack application that wants its own error log interface on its own domain, with no external service account and no data leaving the infrastructure, and that already runs Redis. It does not fit a team that needs a hosted error tracker with alerting to a third party, and it does not fit a Stack-agnostic app with no Redis, since the gem is written for rack and the install instructions add a redis dependency. Before you adopt it, read the maximum_message_length and maximum_message_size_bytes defaults, because the truncation behaviour is aggressive enough to remove backtrace lines, and mount Logster::Web behind your administrator authentication constraint as the documentation requires rather than relying on authorize_request alone.

Frequently asked questions

Official sources

1. discourse/logster on GitHub
2. Issues
3. License: MIT
4. README