Request Visibility for Rails

Rails Ruby

Following the Request: Visualizing What Really Happens Inside a Rails Application

Performance problems are rarely caused by a single line of code.

More often, they're the result of many small pieces adding up—database queries, cache misses, rendering time, middleware, HTTP calls, and background work. Over the years, I've found myself repeatedly asking the same question when investigating slow requests:

Where did the time actually go?

That question ultimately led me to build RequestTrail, a lightweight tracing library for Rails and Rack applications.

The Problem with Request Timing

Most applications already log request duration:

Completed 200 OK in 142ms

That's useful, but it only tells part of the story.

When a request is slow, developers immediately start asking:

  • Was it the database?
  • Did we hit the cache?
  • Was view rendering expensive?
  • Did an external API call block the request?
  • Is there an N+1 query hiding somewhere?

Answering those questions usually means jumping between logs, adding temporary instrumentation, or reaching for heavier observability tools.

Sometimes you don't need a full distributed tracing platform.

You just want a quick answer to:

What happened during this request?

Introducing RequestTrail

RequestTrail traces requests as they move through your application and produces a concise summary showing where time was spent.

It captures information about:

  • SQL queries
  • Cache activity
  • View rendering
  • Outbound HTTP calls
  • Middleware and controller execution
  • Background jobs

The goal wasn't to replace OpenTelemetry or a full APM platform.

Instead, the goal was to provide a simple, lightweight way to understand application behavior directly from your logs.

Getting Started

Installation is straightforward:

gem "request_trail"

In Rails, that's all you need.

RequestTrail automatically inserts itself into the middleware stack and begins collecting information.

After each request, it produces output similar to:

[RequestTrail] GET /orders 142ms
  controller 104ms
    sql       38ms (7 queries)
    cache      2ms
    view      22ms

Instead of seeing only total request time, you gain a much clearer picture of what contributed to that number.

Seeing Requests Like a Flame Graph

One of the ideas behind RequestTrail was making performance information easier to visualize.

Rather than reading dozens of log entries, RequestTrail can produce flame-graph style output that highlights where time is concentrated.

This provides a quick visual understanding of a request without requiring external tools or dashboards.

The result is something closer to a miniature performance profile embedded directly in your logs.

Finding Hidden Problems

Many performance issues aren't obvious until they become severe.

RequestTrail helps surface things like:

  • Excessive SQL queries.
  • N+1 patterns.
  • Slow external API calls.
  • Cache inefficiencies.
  • Expensive controller actions.

Having these details appear automatically after every request makes performance problems easier to discover before they become production incidents.

Beyond HTTP Requests

Although the project started with Rails requests, modern applications do far more than respond to web traffic.

Background jobs are equally important.

RequestTrail can also trace:

  • Sidekiq workers.
  • ActiveJob jobs.
  • Plain Rack applications.

This makes it possible to use the same approach across multiple parts of an application instead of maintaining different monitoring solutions.

Structured Logs for Modern Systems

Not every team consumes logs through the terminal.

For applications using Datadog, Splunk, or centralized log aggregation, RequestTrail can emit structured JSON, making the information easier to search and analyze.

This allows lightweight request tracing without introducing additional infrastructure.

Why I Built It

I wanted something that would answer a simple question:

Why was this request slow?

Without requiring:

  • A heavy APM platform.
  • Complex setup.
  • External services.
  • Dozens of temporary log statements.

I wanted visibility that lived where developers already spend much of their time:

the application logs.

RequestTrail is the result.

Because sometimes understanding a request shouldn't require opening another dashboard.

Sometimes the answer should already be waiting in the log file.