What Rails versions are supported?

Rails Pulse supports Rails 7.2+ and Ruby 3.1+, and is tested against Rails 7.2, 8.0, and 8.1 on each release. It’s built as a Rails Engine and follows Rails best practices, ensuring compatibility with the latest Rails versions.

Does Rails Pulse impact my application’s performance?

Rails Pulse is designed with minimal performance overhead in mind. It uses Rails’ built-in ActiveSupport::Notifications to collect metrics and writes them to the database on a background thread after the response is sent, so the request thread pays well under a millisecond. You can enable or disable it per environment. See Performance Impact for benchmark numbers.

Does Rails Pulse do error tracking?

Yes, since 0.4.0. Rails Pulse captures unhandled exceptions from web requests and failed background jobs, groups them by class and location, and shows backtraces with source context and filtered request params. Exception messages are redacted using your app’s filter_parameters. It is opt-in: set config.track_exceptions = true.

It is not a replacement for every feature of a dedicated error service. There is no alerting, no issue-tracker integration, and no client-side JavaScript capture. What you get is recurring production errors next to your performance data, stored in your own database, with an LLM-ready summary you can copy. See Exception Tracking.

Can I use a separate database for Rails Pulse?

Yes! Rails Pulse supports two database configurations:

1. Single Database (default) - Stores data in your main application database. Simple setup with zero additional configuration.
2. Separate Database - Use a dedicated database for complete isolation. Supports SQLite, PostgreSQL, and MySQL. Perfect for scaling monitoring independently or using different database engines.

Install with --database=separate flag to use a separate database. See the Database Setup documentation for details.

How do I secure the Rails Pulse dashboard?

Authentication is on by default outside development and test. Set config.authorize to a predicate that receives the controller and returns true to allow, for example ->(controller) { controller.current_user&.admin? }. Anything else is a 403. If you need to redirect visitors to a login page instead, use authentication_method. With nothing configured, Rails Pulse falls back to HTTP Basic against RAILS_PULSE_USERNAME and RAILS_PULSE_PASSWORD.

See the Authentication documentation for examples.

How does data cleanup work?

Rails Pulse offers automatic data archiving with two strategies:

1. Time-based cleanup - Automatically delete records older than a configured period (default: 30 days)
2. Count-based cleanup - Enforce maximum record limits per table to prevent excessive storage use

Schedule the RailsPulse::CleanupJob to run daily, or run cleanup manually with rails rails_pulse:cleanup. The Storage page in the dashboard shows how full each table is.

See the Advanced Configuration for details.

How do I know if something got slower, not just slow?

Rails Pulse compares each route, query, and job against its own history. Detail pages show the current period against the subject’s normal (a traffic-weighted baseline over the last 28 days by default) and, when a regression clears both a ratio and an absolute floor, when it started. Record your deployments and the change point can be lined up against the release that caused it.

Is Rails Pulse free?

Yes! Rails Pulse is completely free and open source under the MIT License. No subscription fees, no usage limits, and no external dependencies. All performance data stays in your database.

How is Rails Pulse different from APM services?

Rails Pulse offers several advantages:

• No external dependencies - Everything runs in your Rails application
• Zero monthly costs - No subscription fees or usage-based pricing
• Data privacy - All metrics and exceptions stay in your database
• Full customization - Complete control over thresholds and interface
• Rails-native - Built specifically for Rails with deep framework integration

Perfect for development, staging, and cost-conscious production monitoring.

Which background job adapters are supported?

Rails Pulse supports all ActiveJob adapters through universal tracking:

• Sidekiq - Enhanced tracking via custom middleware
• Solid Queue - Universal ActiveJob tracking
• Good Job - Universal ActiveJob tracking
• Delayed Job - Enhanced tracking via custom plugin
• Resque - Universal ActiveJob tracking
• Any ActiveJob adapter - Falls back to universal tracking

Job tracking is disabled by default. Enable it with config.track_jobs = true in your initializer.

Can I exclude specific routes or jobs from tracking?

Yes! You can exclude routes, jobs, queries, and more using the configuration:

• config.ignored_routes - Exclude specific routes or patterns
• config.ignored_jobs - Exclude specific job classes
• config.ignored_queues - Exclude specific job queues
• config.track_assets = false - Ignore asset requests

See the Advanced Configuration for examples.

How do I update Rails Pulse?

1. Run bundle update rails_pulse
2. Run rails generate rails_pulse:upgrade to copy new migrations and initializer settings
3. Run rails db:migrate (separate database: rails db:migrate:rails_pulse)
4. Run rails rails_pulse:migrate_routes if the release requires a data backfill (0.4.0 does)
5. Run rails rails_pulse:status, which exits 1 while anything still needs action
6. Restart all processes (web + workers) together

Upgrading from any 0.3.x release to 0.4.0 includes a breaking, irreversible schema change. Back up first and read Upgrading. The changelog lists every change.

Where can I get help or report issues?

We’re here to help:

• GitHub Issues - Report bugs or request features
• GitHub Discussions - Ask questions and share ideas
• Documentation - Full README and guides

Still Have Questions?

Browse Documentation

Explore our complete documentation for detailed guides and examples.

Read Docs →

Get Support

Ask questions on GitHub Discussions or report issues.

GitHub →