The Easiest Way to Monitor Ruby: Automatic Instrumentation

Milica Maksimović
Tom de Bruijn

Milica Maksimović and Tom de Bruijn on

The Easiest Way to Monitor Ruby: Automatic Instrumentation

Setting up a proper monitoring overview over your application's performance is a complex task. Normally, you'd first need to figure out what you need to monitor, then instrument your code, and finally make sense of all the data that has been emitted.

However, with a few things set in place, and an APM that natively supports Ruby, it's easier than ever to take this step. In this post, we'll show you how you can do it too.

Automatic Instrumentation - Handsfree APM Setup

To discover which pieces of your code are causing your performance issues, you’ll need to add instrumentation to it. That way, you can break down all the actions and measure which ones are the slowest.

With AppSignal’s automatic instrumentation, we take away as much manual work as we can. Just run a few commands through the CLI, and you’ll be set.

Our monitoring agent detects the different parts of your infrastructure and automatically instruments it. This enables AppSignal app to digest, process, monitor, and show you the graphs and dashboards you need the most.

That means that for example for the graphql gem for Ruby, AppSignal will instrument every GraphQL request that comes in, meaning it will provide a breakdown of all events in the request.

Out-of-the-box Instrumentation

We've made a list of all the tools AppSignal supports. It's pretty extensive:

Rails featuresAction Mailer
Rails featuresAction Cable
Rails featuresActive Record
Rails featuresActive Job
Rails featuresCaching
Supported through ActiveRecordPostgreSQL, MySQL, SQLite, etc.
Heroku integrationHeroku PostgreSQL
Web serverPuma
Web serverUnicorn
Standard libraryNet::HTTP
Background jobQue
Background jobSidekiq
Background jobDelayed Job
Background jobResque
Background jobShoryuken

As I've said, the list is pretty long, which is why we won't dive into each and every tool in this post.

Web Frameworks and APIs

AppSignal supports instrumentation of web requests in Ruby on Rails, Padrino, and Sinatra out-of-the-box. APIs using Grape or the GraphQL gem are also supported.

Ruby on Rails

The AppSignal integration for Rails works by tracking exceptions and performance in requests. When an error occurs in a controller during a request AppSignal will report it. Performance issues will be based on the duration of a request and create a timeline of events detailing which parts of the application took the longest.


It's even possible to track how long it took for HTTP requests to arrive at the Rails app through a loadbalancer of web server. If it's not on by default, set up the request queue time tracking header and AppSignal will automatically graph the queue time.

queue time


AppSignal supports the graphql gem for Ruby. It will instrument every GraphQL request that comes in and provide a breakdown of all events in the request. You'll be able to see how long it took to parse, validate and execute your resolvers. Events from the app's web framework and database calls are of course included in this breakdown.

Screenshot of event timeline

This is great for those who wish to debug GraphQL queries that seem to take a long time, and you're not sure where the slowdown could be occurring. Don't forget about our anomaly triggers here also - these can be very useful for alerting when the query time reaches a certain threshold.

Sinatra, Padrino and Grape

Sinatra, Padrino and Grape are web and API frameworks for Ruby that can be part of an app in different ways. They are either a standalone app or mounted on a larger Rails app. Depending on how the app is mounted on a web server some different installation steps are needed for Sinatra, Padrino and Grape.

Once installed Sinatra, Padrino, Grape requests are all instrumented: errors and performance measurements are reported when traffic hits the API. Every (API) endpoint is its own action in AppSignal to easily find which endpoint encountered which error. As with Rails apps the performance breakdown provides insight in what database queries or other parts or the app were slower than others.


Active Record and other ORMs

To see how long a request took querying the database, open a incident detail page. On top of the page the types of events recorded in the request are broken down per group. Here you can see how much time in total was spend on what type of operation.


If we zoom in further on the performance of this sample, further down the page you'll find a timeline of all events in the request in the order they occurred. This provides you with an overview of each query that was executed and which ones are taking the longest.


The integration shows you the tracing for database calls, so you can see what query is the root of your evil (or genius) 😉


N+1 queries

Worried there may be N+1 queries occurring in the request and that's what is slowing it down? If we detect N+1 queries a warning will appear in the event timeline for those events that were detected.



With Redis integration, you'll see your calls to Redis appear in the Event Timeline:

Screenshot of event timeline

You'll also be able to see the name of the command sent to Redis and the address of the Redis instance that the query was made to:

Screenshot of event timeline flyout

This is great news for those who wish to debug long running calls to a Redis cache. You can even set an anomaly trigger to send an alert on requests that run for a super long time!

Background Jobs

Whenever a background job is queued with Sidekiq, Delayed::Job, Resque, Shoryuken and Que AppSignal will automatically report errors and performance measurements. All Active Job adapters are also supported, and some background job libraries like Sidekiq and Delayed::Job report even more metadata from the libraries themselves.


Sending emails with Action Mailer

If Rails mailers using Action Mailer are set up to deliver_later they will also be routed through Active Job and can count on the same level of instrumentation.


Using Action Cable in your Rails app? AppSignal automatically reports errors and performance measurements for messages and subscriptions. Every message is instrumented separately so even long running channels will report all activity. They are grouped per action giving a clear overview of how each individual action is performing.

👋 If you liked this, take a look at other Ruby (on Rails) performance articles in our Ruby performance monitoring checklist.

Try AppSignal: Monitoring Made Easy And Sweet 🍪

Over the past 7 years, we've helped thousands of developers to automatically instrument their code, and we'd love you to try us out as well. When you do, feel free to reach out, we'll send you a free box of stroopwafels as well.

PS. If you are helping the world with a great OSS project, we help you back with a free AppSignal account. Spread the word to the maintainers you value!

Milica Maksimović
Tom de Bruijn

Tom de Bruijn

Tom is a developer at AppSignal, organizer, and writer from Amsterdam, The Netherlands.

All articles by Tom de Bruijn

Become our next author!

Find out more

AppSignal monitors your apps

AppSignal provides insights for Ruby, Rails, Elixir, Phoenix, Node.js, Express and many other frameworks and libraries. We are located in beautiful Amsterdam. We love stroopwafels. If you do too, let us know. We might send you some!

Discover AppSignal
AppSignal monitors your apps