// feature_overview

Built for Rails.
Every feature.

Not a generic APM with a Rails plugin bolted on. Every feature is designed around how Rails actually works — its request lifecycle, ActiveRecord patterns, job queues, and more.

⚡ N+1 Query Detection

Catch the silent
performance killer

N+1 queries are the most common performance issue in Rails apps, and the hardest to spot in code review. 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.

  • Real-time N+1 detection across all controller actions and 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
  • Works with ActiveRecord, Sequel, and raw SQL patterns
  • Historical trend: are your N+1s getting worse or better over time?
47× avg query reduction after fix
<1ms detection overhead
N+1 Alerts · PostsController#index
Active N+1 Issues ⚡ 3 detected today
GET /posts 47 extra queries
SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1
+2.1s overhead PostsController#index:24 last seen 3m ago
GET /api/feed 18 extra queries
SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = $1
+840ms overhead Api::FeedController#index:51 last seen 12m ago
GET /dashboard 9 extra queries
SELECT "comments".* FROM "comments" WHERE "comments"."user_id" = $1
+210ms overhead DashboardController#index:8 last seen 1h ago

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 Verify the fix in real time

Push your includes() patch and watch the query count drop on the same endpoint within seconds. No more deploying hopefully and waiting for tomorrow's P99 chart to confirm the regression is gone.

🔴 Error Tracking

Know before
your users do

Full Rails exception capture across your entire stack — web requests, background jobs, Action Mailer, ActiveRecord callbacks, and more. Every error ships with a full stack trace, request context, session data, and the user who experienced it.

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 environment: params, headers, session, cookies
  • User identity attached to each error occurrence
  • Smart error grouping and deduplication by fingerprint
  • First seen / last seen / occurrence frequency per error
  • Slack and email alerts with configurable severity routing
  • Mark errors as resolved — auto-reopen if they recur
<2s error-to-alert time
100% of exceptions captured
Error Feed · my_app · production
ActiveRecord::RecordNotFound
Couldn't find User with 'id'=84291 (maybe trying deleted record?)
app/controllers/users_controller.rb:18:in `show'
app/controllers/application_controller.rb:44
● 23 occurrences last 5 mins 14 users affected
NoMethodError
undefined method `avatar_url' for nil:NilClass
app/views/posts/_post.html.erb:7:in `_app_views_...'
app/controllers/posts_controller.rb:32:in `index'
● 7 occurrences last 22 mins 7 users affected
ActionController::InvalidAuthenticityToken
ActionController::InvalidAuthenticityToken in SessionsController#create
actionpack (7.1.3) lib/action_controller/request_forgery_protection.rb:218
● 2 occurrences 1h ago 2 users affected

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.

📊 Performance Analytics

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.

Every request is sampled and stored with a full breakdown. You can drill into any individual request trace to see a waterfall of every query, cache call, and render that made it up.

  • 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?
Performance · Last 24h
Response Time P99 · 24h window
142ms
P50
487ms
P95
1.2s
P99
98.7%
Cache Hit

01 Deploy markers

Every deploy is automatically marked on your performance timeline. Immediately see whether a new release improved or regressed your P99 response times.

02 Memory profiling

Track heap size, object allocation count, and GC runs over time. Spot memory leaks before they become OOM kills — especially important on Heroku and Fly.io.

03 Side-by-side request comparison

Pin any two requests next to each other — 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.

🔔 Smart Alerting

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.

Different thresholds, severities, and time windows per stream. Different rules per environment, so staging noise doesn't drown out production signals.

  • APM & error alerts — new exceptions, error rate spikes, slow endpoints, and weekly N+1 digests, delivered to Slack and email
  • Server monitoring alerts — CPU, memory, disk, and queue depth thresholds sent straight to your phone via Pushover
  • Uptime alerts — the moment a check goes down (email and Pushover), plus an auto-recovery ping when it comes back
  • Threshold-based rules: P99 > Xms, error rate > Y%, memory > Z%, custom time windows
  • Alert fatigue prevention — deduplication, cooldown periods, and per-rule rate limits
  • Scheduled maintenance windows — suppress alerts during deploys
  • Per-environment overrides — staging never pages, production always does
Alert Rules · my_app
🔴
Error rate spike → Slack #alerts-prod
APM alert · error rate > 5% over 2-minute window · Severity: Critical
⚡ Last fired: 2h ago · 3 times today
📧
N+1 weekly digest → email
APM alert · every Monday 09:00 · all new N+1 queries from the past week
⚡ Next: Monday 09:00
📱
High memory on web-02 → Pushover
Server monitor · heap > 85% sustained 10 min · Severity: Warning
⚡ Last fired: Yesterday 14:23
🚨
Uptime check down → email + Pushover
Uptime alert · 3 consecutive failures · auto-recovery ping when it's back
⚡ Last fired: Never (new rule)
👤 User Activity Tracking

Track activity,
not identities

When a customer says "the app is slow for me," you shouldn't have to guess — and we shouldn't have to know who they are. DeadBro groups every request, error, and N+1 against an opaque user ID, so you can pull up an entire day of their traffic in one view.

The ID is picked up automatically from Warden — the same layer Devise, Sorcery, and most Rails auth gems sit on top of. No user_context lambda to write, no email or name leaving your app.

  • All requests for a given user, grouped by day — open a date and drill into their slowest one
  • Errors filtered by user ID — every exception a specific person hit, in order
  • Per-user performance — find the customer whose requests are 5× slower than your average
  • Zero configuration — Warden-aware out of the box, works with Devise and most Rails auth gems
  • Anonymized on our side — we store an opaque user ID, never an email, name, or other PII
  • Automatic scrubbing of passwords, tokens, and card numbers from params and headers
  • GDPR-friendly retention with per-user deletion via the API
0 config picked up from Warden
ID-only no emails or names stored
User Activity · Today
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
🌍 Environment Monitoring

Production, staging,
all in one place

One DeadBro account covers all your environments. Each environment gets its own dashboard, its own alert rules, and its own data retention policy. 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.

  • Unlimited environments per account (prod, staging, review apps, dev)
  • Auto-detection via RAILS_ENV — no configuration needed
  • Per-environment alert rules — staging won't page your on-call
  • Side-by-side performance comparison across environments
  • Review app support for Heroku and Render preview environments
  • Per-environment data retention settings to control storage costs
Environments · my_app
Production ● LIVE
P99 latency1,247ms
Error rate0.8%
Req / min842
Staging ● ACTIVE
P99 latency448ms
Error rate0.1%
Req / min12
PR #418 ● REVIEW
P99 latency382ms
Error rate0%
Req / min3
Development ● LOCAL
P99 latencyN/A
Errors today24
N+1 detected11

Ready to see your app clearly?

Add gem 'dead_bro', an initializer with your API key, and get full observability in a few minutes.

Get Started Free

No credit card. No enterprise sales call. Gem, initializer, GO!