Telesink Rails Requests Integration

23 Apr, 2026 / GitHub (★23) · X · Bluesky

After shipping the ActiveJob integration a couple of days ago, I realized I still had a blind spot right at the center of every Rails app: the actual HTTP requests.

Background jobs are important, but the requests are what drive everything. When something feels slow or off in production, I want to see the request that triggered it — immediately, without tailing logs or opening another monitoring tab.

The new gem telesink-rails-requests does exactly that. Drop it in, and every request processed by Rails gets turned into a structured event in your Telesink feed. No manual instrumentation, no custom middleware to maintain.

Telesink dashboard showing logged Ruby on Rails requests

What each request event contains

The integration listens to Rails’ standard request instrumentation and forwards these fields for every request:

HTTP method and the full path (including any query string)
Response status code
Controller name and action
Three timing values: total duration, database time, and view time
Client IP address, User-Agent string, and the request ID (the one Rails generates by default)

Because it reuses the core Telesink Ruby SDK, the events respect the same idempotency keys and tagging rules you already have in place. If you’ve set up a dedicated sink for jobs, you can do the same for requests so your main feed stays uncluttered.

Installation and setup

Add the gem to your Gemfile:

gem "telesink-rails-requests"

Then:

bundle install

That’s it. The gem registers itself automatically and starts sending events on the next request. It picks up TELESINK_ENDPOINT from your environment (the same one the Ruby SDK and the ActiveJob gem use).

If you prefer to keep request events separate (I do), just set:

export TELESINK_REQUESTS_ENDPOINT=https://app.telesink.com/api/v1/sinks/your_requests_sink_token/events

Works the same way for self-hosted Telesink instances.

How it actually works

Under the hood it subscribes to the process_action.action_controller notification that Rails already fires for every request. No extra threads, no monkey-patching of core classes, and no measurable overhead beyond the tiny cost of formatting and sending the event (the same payload size the SDK already handles elsewhere).

It gracefully does nothing if the Telesink endpoint isn’t configured, so you can keep the gem in your development and test environments without any surprises.

Practical value I’m already getting from it

In my own apps I now see slow requests appear live next to the jobs they enqueue. When a 500 pops up, I immediately know the exact controller/action, the request ID to grep logs with, and whether the time was spent in the database or the view layer. It makes correlating issues across requests and background work trivial.

For teams that already run Telesink, this closes the last major gap in the “what happened in my Rails app just now” picture without adding another vendor or complex configuration.

The source is at github.com/telesink/telesink-rails-requests and is MIT licensed. Feedback or pull requests are welcome — especially if you have ideas for additional context that would be useful in high-traffic Rails apps.

Follow along on X at @kyrylo.