Get more from DeadBro

“It’s slow” is a starting point.

Application performance monitoring (APM) shows what happened inside your Rails app. Pair it with uptime checks and resource metrics to understand both what users experience and where to investigate.

Start with one app and one important user journey. Collector availability, sampling limits, and advanced features depend on your plan.

From a Rails app to your first trace.

1. Create your account and application

   Create an account, open Applications, and add your app. Copy its API key from the application settings.

2. Install the gem

   Add this to your Rails app’s Gemfile:

   gem "dead_bro", git: "https://github.com/rubydevro/dead_bro.git"

   Then install the dependency and generate the initializer:

   bundle install
   bin/rails generate dead_bro:install

3. Configure the key and restart

   Set DEAD_BRO_API_KEY in your deployment’s environment or secret store. The generated config/initializers/dead_bro.rb reads it like this:

   DeadBro.configure do |config|
     config.api_key = ENV["DEAD_BRO_API_KEY"]
   end

   Deploy and restart your web and worker processes so they load the gem and key. Use the same DEAD_BRO_DEPLOY_ID, such as the release’s Git SHA, across replicas in a rollout to keep deploy history grouped correctly.

4. Send traffic and verify the connection

   Visit a real controller action in your app, then return to DeadBro and open the application’s captured requests. Look for the endpoint you just visited and inspect its timing and SQL. Run a normal background job to verify worker reporting too.

   In application settings, review the sample rate and excluded controllers or jobs. Settings reach the gem through successful metric or heartbeat responses, so changes are not instantaneous.

Your first milestone: one request you recognize, in the expected environment, with useful timing data. Get this working before enabling additional collectors.

Give each monitor a job.

Start with the signals you can act on. A healthy uptime check tells you your endpoint responds; request traces tell you whether the work behind it is slow.

Close the alerting loop: connect the relevant app or uptime check to Slack, send a test notification, and agree who responds. Review noisy thresholds after you have seen normal traffic. Slack setup →

Follow the evidence to a fix.

1. Narrow the incident

   Choose the app, environment, and time window. Start with the affected endpoint, error, or job. Check deploy history to see whether the change began around a release.

2. Open a representative request

   Inspect a slow or failing sample and compare it with a healthy one for the same action. Look at total duration, SQL, rendering, and the exception backtrace when present. One unusual sample is a clue; repeated patterns make a stronger case.

3. Identify where the work goes

   Repeated SQL?

   Check N+1 flags and query call stacks. Look for association loading inside a loop, then test eager loading with includes or preload.

   One expensive query?

   Inspect its SQL and call site. If EXPLAIN capture is enabled locally, use the captured plan to investigate scans and indexes. Plans contain estimates; validate changes with measured timings.

   Rendering or memory?

   Look for repeated partials, large result sets, or unnecessary object creation. Correlate request memory with process trends; one memory increase alone does not establish a leak.

   An exception or failed job?

   Read the message and backtrace, find the application frame, and inspect available request or job context. Reproduce the same input path in development.

4. Measure a small change locally

   Use DeadBro.analyze in a Rails console to inspect a block’s time, SQL, and memory without sending its analysis to DeadBro. For example, adapt this query to your own models:

   result = DeadBro.analyze("load users with profiles") do
     User.where(active: true).includes(:profile).limit(100).to_a
   end
   
   result.total_time_ms
   result.sql_count
   result.most_queries
   result.longest_queries

   Run the original and changed versions with comparable data. The block executes normally, so use development or test data for operations that change records.

5. Deploy, then verify under real traffic

   Compare the same endpoint and similar time windows before and after the release. Check duration, query count, and errors alongside traffic and sampling settings. Keep watching long enough to include the conditions that triggered the problem.

Not seeing what you expected?