See exactly why your
Rails app is slow.
DeadBro gives you real-time request traces, automatic N+1 detection, slow SQL and optional plan-only EXPLAIN, and error tracking — purpose-built for Rails. Not a generic APM bolted onto Ruby.
Rails performance problems are invisible until they're not.
Your app passes all its tests. Queries look fine in development. Then you deploy, traffic picks up, and something silently degrades. Response times creep up. Users start dropping off. By the time you notice in your logs, you've already lost them.
The problem is that Rails performance issues — N+1 queries, slow SQL without an index, memory growth, cache misses — are nearly impossible to reproduce locally. They only show up in production, under real load, with real data. You need instrumentation that runs where your users are.
N+1 queries
ActiveRecord makes them trivially easy to write and nearly invisible in development. A page that renders in 80ms locally fires 200 queries in production against real data.
Slow SQL
A query that's fast on 10,000 rows becomes a full table scan on 10 million. Without production query analysis, you won't see it coming.
Memory bloat
Ruby's GC doesn't always return memory to the OS. Long-running processes grow slowly, quietly, until your dyno restarts at 3am.
Silent errors
Exceptions that get rescued and logged — but never triaged. Users encounter broken states you don't know about.
Deploy regressions
A deploy introduces a slow query or bumps memory 20%. You find out three days later when support tickets arrive.
Background job delays
Sidekiq queues back up. Jobs retry silently. You have no visibility into which jobs are slow and why.
Generic APMs like Datadog and New Relic can tell you that something's slow. DeadBro tells you why — with Rails-native instrumentation that understands ActiveRecord, Action View, and your job queues natively.
Automatic N+1 detection — no configuration required.
The dead_bro agent patches ActiveRecord's query execution at the lowest level. It tracks the call stack behind every SQL statement and detects when the same query pattern repeats across a collection — the classic N+1 signature.
When it finds one, it flags the request in your dashboard with the exact line of Ruby that triggered it, the number of queries fired, and the total time wasted. No bullet gem. No test-only detection. This works in production, on real data.
Most N+1s are one-line fixes once you know where they are: add includes(:association) to the right query. The hard part was always finding them. DeadBro handles that.
# The controller you wrote def index @posts = Post.all end # The view you wrote <% @posts.each do |post| %> <%= post.author.name %> <% end %> # What actually runs in production SELECT * FROM posts -- 1 SELECT * FROM users WHERE id=1 -- 2 SELECT * FROM users WHERE id=2 -- 3 ... 97 more queries # DeadBro flags this immediately: # ⚠ N+1 detected — PostsController#index # posts#each → user.name # 101 queries · 340ms wasted # app/views/posts/index.html.erb:4 # The fix @posts = Post.includes(:author).all # 2 queries · 8ms
See the query plan, not just the query time.
Knowing a query took 2,400ms is useful. Knowing it did a sequential scan of 8 million rows because the index is on the wrong column is actionable.
On Pro and Enterprise, DeadBro can capture a plan-only EXPLAIN for slow SELECT queries after you enable it in your app, and surfaces the results alongside the request trace. You see the execution plan — seq scans, index scans, hash joins, sort operations — without needing database access or a separate tool.
Pair it with the SQL backtrace — DeadBro links every slow query back to the Rails code that generated it — and you go from "the database is slow" to "line 47 of ReportsController#show needs a composite index on [account_id, created_at]" with less guesswork.
# Slow query caught by DeadBro # PostsController#index · 2,488ms SELECT posts.*, users.name FROM posts JOIN users ON posts.user_id = users.id WHERE posts.account_id = $1 ORDER BY posts.created_at DESC LIMIT 25 # EXPLAIN plan output (when enabled) Sort (cost=124589.45 rows=25) Sort Key: posts.created_at DESC -> Seq Scan on posts (cost=0 rows=4182901) Filter: account_id = 1 # DeadBro recommendation: # Missing index on posts(account_id, created_at) # Estimated improvement: 200x add_index :posts, [:account_id, :created_at]
Every slow request, broken down to the millisecond.
DeadBro traces every controller action from the moment a request hits your Rails router to the moment the response goes out. Inside each trace: time spent in SQL, time rendering views, time in external HTTP calls, time in cache reads — broken down to the individual query and partial.
P50, P95, and P99 response times for every endpoint. So you know whether your 800ms average is hiding a 4,000ms 99th percentile that's quietly causing timeouts for a fraction of your users.
The TimeBro timeline stitches together deploys, traffic spikes, error rates, and performance changes on a shared axis — so "why did things slow down Thursday afternoon" has a visual answer instead of a log-grepping expedition.
# Request trace — PostsController#show # Total: 847ms Controller action 847ms ├─ SQL queries 612ms │ ├─ Post.find 8ms │ ├─ comments (N+1 ⚠) 580ms ← flagged │ └─ user lookup 24ms ├─ View rendering 198ms │ ├─ posts/show 12ms │ ├─ comments/_list 174ms ← slow partial │ └─ layouts/application 12ms ├─ Cache 18ms │ └─ miss: sidebar_stats └─ External HTTP 19ms # P50: 210ms P95: 847ms P99: 1,240ms # Endpoint health: needs attention
Errors with full context — not just a stack trace.
When an exception fires in your Rails app, DeadBro captures it with the full stack trace, the request that triggered it, the parameters, the session data, and the user context. No more "reproduce this in development" when you have everything production gave you.
Errors are grouped by fingerprint, so you see 847 occurrences of the same NoMethodError as one item — not 847 separate alerts. And when you deploy a fix, DeadBro marks the error as resolved and alerts you if it regresses.
On Growth and above, Slack can alert your team when a new error occurs. You find out about new exceptions in seconds, not when a user emails support.
NoMethodError: undefined method `name' for nil (NilClass) Backtrace: app/views/posts/_card.html.erb:12 <%= post.author.name %> app/controllers/posts_controller.rb:8 @posts = Post.published Request context: GET /posts · 500 · 140ms User: user_id=8821 (signed in) Params: { page: "2", sort: "recent" } Occurrences: 847 times · first seen 2h ago Affecting ~12% of /posts traffic Slack alert sent: #alerts · 14:22 · @oncall "New error: NoMethodError in posts#index"
Everything else your Rails app needs watched.
Performance monitoring isn't just request traces. DeadBro covers the parts that typical APMs treat as add-ons.
Background job monitoring
Sidekiq, Delayed::Job, and ActiveJob are first-class citizens in DeadBro. Every job execution is traced the same way as a web request — queue time, execution time, retries, and failures are all visible.
Deploy tracking
Every deploy is marked on your performance and error timeline. Correlating "response times spiked at 14:30" with "deploy went out at 14:28" takes one glance, not a log archaeology expedition.
Uptime monitoring (Is It Dead)
Built-in uptime checks with a public status page — no separate tool needed. Monitor endpoints, get alerted when they go down, and show users a status page during incidents. Included in every plan.
System monitor
On Enterprise, see CPU, memory, disk, and Sidekiq queue depth alongside request metrics — so you can see memory climbing before it triggers an R14 at 3am.
User activity tracing
On Pro and Enterprise, inspect captured requests linked to a user ID before an error — useful for support tickets and bug reports.
Request log viewer
Logs linked to the requests that generated them. Instead of grepping timestamps, click the request and see its log output in context alongside the trace.
Live in after setup.
No agents to configure. No custom dashboards to build. No YAML to write. Three steps and your app is instrumented.
Add the gem
Add the gem from GitHub to your Gemfile and run bundle install.
Configure the initializer
Run bin/rails generate dead_bro:install and set your API key from the dashboard.
Deploy and watch
Your next production deploy starts sending traces. N+1s, slow queries, and errors appear in real time.
# Gemfile gem 'dead_bro', git: 'https://github.com/rubydevro/dead_bro.git' # Terminal bundle install bin/rails generate dead_bro:install # config/initializers/dead_bro.rb DeadBro.configure do |cfg| cfg.api_key = ENV["DEAD_BRO_API_KEY"] end # Deploy. Open the dashboard. # Send a few requests to see captured data. # # ✓ ActiveRecord instrumented # ✓ Action Controller instrumented # ✓ Action View instrumented # ✓ ActiveJob / Sidekiq instrumented # ✓ N+1 detection active # ✓ Error tracking active
DeadBro plans at a glance
Pay for what you use. No hidden fees for extra containers or servers.
Choose monitoring around the questions you need to answer.
Compare how each tool explains a slow Rails request, shows repeated SQL, and links an error to the request that produced it. Check the current plan limits and run the same workflow on your own app before deciding.
See our Datadog guide · New Relic guide · AppSignal guide · Scout APM guide
Common questions about Rails performance monitoring.
What is Rails performance monitoring?
Rails performance monitoring means tracking how your app handles requests in production — measuring response times, identifying slow database queries, detecting N+1 query patterns, catching errors, and correlating performance changes with deploys. A Rails APM instruments your app from the inside so you see what's actually happening, not just what your load balancer reports.
What's the difference between a Rails APM and a generic APM?
When comparing Rails APM tools, check which framework events they capture in your app and how easy it is to move from a slow endpoint to a specific request, SQL query, view, or background job. DeadBro focuses on that Rails workflow, including ActiveRecord query detail, Action View timing, supported job integrations, and automatic N+1 detection.
What causes N+1 queries and how does DeadBro detect them?
An N+1 happens when your view or controller loads a collection and then triggers a separate database query per record to fetch an association. For 100 posts that each call post.author.name without preloading, that's 101 queries instead of 2. DeadBro patches ActiveRecord's query executor, tracks the call stack behind each SQL statement, and recognises repeated patterns automatically — flagging the request, the query count, the total wasted time, and the exact line of Ruby responsible.
Does monitoring add overhead to my app?
The agent is open source, so you can inspect what it records in your app. The Free and Starter plans allow up to 25% and 50% request sampling respectively; Growth and Pro allow up to 100%. Actual overhead depends on your app and which instrumentation you enable.
How is DeadBro different from just reading the Rails log?
Rails logs give you a flat list of queries and render times for individual requests. They don't aggregate across thousands of requests, they don't detect patterns (like N+1s that only appear under load), they don't link a slow query back to the line of view code that triggered it, and they don't alert you in Slack when something breaks at 2am. DeadBro does all of those things.
What happens when I hit my request limit?
DeadBro spreads your monthly allowance evenly across the month. If you hit your daily share, monitoring pauses for the rest of that day and resumes automatically the next morning. You're never charged overage fees. Consistently hitting the cap is a clear signal to upgrade — and you can do that any time from the dashboard.
Where is my data stored?
DeadBro runs on dedicated bare-metal servers in Europe — not AWS, Azure, or Google Cloud. Your traces, errors, and performance data stay in the EU. This matters for teams with GDPR obligations or data residency requirements.
Your Rails app is trying to tell you something.
Start listening in after setup. Free tier, no credit card, 50,000 requests a month — forever.
Free forever · No credit card · EU-hosted · Cancel anytime