See what is happening
inside your Rails app.
Explore request performance, SQL queries, errors, alerts, and user activity. Availability varies by plan; compare plans for limits and included features. The examples below use illustrative data.
Catch the silent
performance killer
N+1 queries can make a Rails page slow even when individual queries look fast. DeadBro detects them automatically at runtime — no configuration, no Bullet gem, no manual log parsing.
When a request triggers repeated database queries inside a loop — User.find(id) called 47 times instead of a single where(id:) — DeadBro flags it, links it to the exact controller action, and shows you the repeated SQL.
- ✓N+1 detection in captured requests and supported background jobs
- ✓Full SQL query text with count of repeated executions per request
- ✓Traces linked to exact controller#action and file line number
- ✓Threshold configuration — only alert above N occurrences
- ✓Detects repeated ActiveRecord query patterns
- ✓Historical trend: are your N+1s getting worse or better over time?
01 Hidden in views & serializers
Most N+1s don't live in the controller — they hide in _post.html.erb partials, JSON serializers, and helper methods. DeadBro follows the trace through the view layer, so you land on the exact line firing repeated queries — not just the action that rendered it.
02 Background jobs too
N+1 queries don't only happen in web requests. DeadBro instruments Sidekiq, Delayed::Job, and ActiveJob workers with the same depth as web requests.
03 Check the fix after deployment
Push your includes() patch and compare query counts on captured requests from the same endpoint. See whether your change reduced database work.
Know before
your users do
Investigate captured Rails exceptions from web requests and supported background jobs. Each error includes a stack trace and available request context. Sensitive values are redacted; user context depends on your app configuration.
DeadBro groups similar errors intelligently — so a bug in a shared helper that fires 500 times doesn't flood your inbox with 500 duplicate alerts. You see one alert, with an occurrence count that updates in real time.
- ✓Automatic exception capture — no manual rescue blocks needed
- ✓Full Rails stack trace with source code context per frame
- ✓Request context with sensitive values redacted
- ✓User context when your app supplies an ID
- ✓Smart error grouping and deduplication by fingerprint
- ✓First seen / last seen / occurrence frequency per error
- ✓Email alerts; Slack alerts on Growth and above
- ✓Mark errors as resolved — auto-reopen if they recur
app/controllers/application_controller.rb:44
app/controllers/posts_controller.rb:32:in `index'
01 Smart grouping
Errors are fingerprinted by exception class, message pattern, and stack frame — not just by message string. Errors that should be grouped together, are.
02 Resolve & reopen
Mark an error as resolved after a deploy. If the same error fires again in a future release, DeadBro automatically reopens it and re-alerts you.
03 Job-aware tracking
Sidekiq job failures include the job class, arguments, queue name, retry count, and full backtrace — everything you need to reproduce and fix the issue.
Deep visibility into
every millisecond
Beyond simple response times — DeadBro breaks down exactly where your Rails requests spend their time. Database time, view rendering, cache hits and misses, external HTTP calls, background jobs. See the full picture.
Captured requests include a timing breakdown. Sampling depends on your plan. Drill into an individual trace to see recorded queries, cache calls, and renders that contributed to its duration.
- ✓P50, P95, P99 response time tracking per endpoint
- ✓SQL query breakdown — total time, query count, slowest queries
- ✓Cache hit/miss ratio per cache store and key pattern
- ✓Memory usage over time — heap growth, GC pressure, object allocations
- ✓External HTTP call tracking (Faraday, Net::HTTP, HTTParty)
- ✓Slowest endpoints ranked by cumulative impact, not just max latency
- ✓Side-by-side deploy comparison — did performance improve after that PR?
01 Deploy markers
On Starter and above, deploy markers appear on your performance timeline. Immediately see whether a new release improved or regressed your P99 response times.
02 Memory profiling
On Growth and above, inspect memory and GC activity over time. Spot memory leaks before they become OOM kills — especially important on Heroku and Fly.io.
03 Side-by-side request comparison
On Pro and Enterprise, compare two requests side by side — a fast one and a slow one on the same endpoint — and diff their SQL timing, query count, cache ratio, and view render breakdown row by row. Pinpoint exactly where the slow request lost its seconds.
Three alert streams.
Routed where they belong.
Not every spike deserves a 3 AM wake-up. DeadBro splits alerts into three streams — each routed to the channel that fits its urgency — so your team chat, your inbox, and your phone each get the right level of noise.
Choose relevant thresholds and notification channels for your plan. Review alerts alongside the environment they came from.
- ✓APM and error alerts by email; Slack delivery on Growth and above
- ✓Server resource alerts on Enterprise, with Pushover notifications when configured
- ✓Uptime incident and recovery notifications by email or configured Pushover
- ✓Threshold-based rules: P99 > Xms, error rate > Y%, memory > Z%, custom time windows
- ✓Alert fatigue prevention — deduplication, cooldown periods, and per-rule rate limits
- ✓Configure alert rules for the signals that matter to your team
- ✓Review alerts in the context of the monitored environment
Track activity,
not identities
When a customer says "the app is slow for me," user activity on Pro and Enterprise helps you investigate captured requests and errors linked to their user ID. Sampling and retention determine how much history is available.
On Pro and Enterprise, DeadBro can associate requests with a user ID from supported authentication integrations. Avoid sending personal details in custom fields.
- ✓Captured requests for a given user, grouped by day — open a date and drill into their slowest one
- ✓Filter captured errors by user ID to investigate a person's experience
- ✓Per-user performance — find the customer whose requests are 5× slower than your average
- ✓Warden-aware user IDs when the integration is available
- ✓User activity uses an ID; avoid adding personal details to custom context
- ✓Automatic scrubbing of passwords, tokens, and card numbers from params and headers
- ✓Retention follows your account plan
| USER ID | REQUESTS | AVG | ERRORS | LAST SEEN |
|---|---|---|---|---|
| #user_4821 | 142 | 182ms | 2 | 11m ago |
| #user_12087 | 47 | 1,247ms | 0 | 23m ago |
| #user_874 | 318 | 244ms | 0 | 4m ago |
| #user_29413 | 89 | 3,812ms | 7 | 1h ago |
| #user_5610 | 23 | 198ms | 0 | 2h ago |
Production, staging,
all in one place
One DeadBro account can show multiple environments for an application. You can filter monitoring data by environment. Retention follows your account plan. No cross-contamination. No guessing which environment a trace came from.
DeadBro auto-detects your Rails environment via RAILS_ENV and segments all data accordingly. Staging noise stays in staging. Production data is always front and center.
- ✓Environment labels for production, staging, and other Rails environments
- ✓Auto-detection via RAILS_ENV — no configuration needed
- ✓Alerts show the environment where they occurred
- ✓Filter performance data by environment
- ✓Identify preview environments by their Rails environment label
- ✓Plan-based data retention for every environment
Ready to see your app clearly?
Create an account, add the gem and your API key, then send requests to see captured data. Features depend on your plan.
Get Started FreeFree plan available. No credit card required.