Pulse is Live
APM that tells you why it's slow
"Why is the app slow?"
The most dreaded question in software. Because the answer is almost never obvious.
The APM problem
Every APM tool shows you dashboards:
- Response time: 245ms
- Throughput: 1,234 rpm
- Error rate: 0.3%
Great. Numbers. But when your response time jumps to 2 seconds, those dashboards don't tell you why. They tell you that.
So you start the investigation. Click through traces. Stare at flame graphs. Guess at bottlenecks. It's slow, tedious work.
I've spent hours on investigations that should have taken minutes.
The question I kept asking
Every time I had a performance problem, I'd end up asking Claude for help.
"Here's the trace. Why is this endpoint slow?"
And Claude would analyze it beautifully. Find the N+1 query. Spot the missing index. Notice the inefficient serialization.
But first, I had to find the trace. Export it. Copy it. Paste it. Give Claude enough context to understand.
The investigation was the bottleneck. Not the analysis.
Pulse changes that
Ask Claude: "Why is the app slow today?"
Claude queries Pulse directly. Analyzes the traces. Cross-references with Recall logs and Reflex errors. Responds:
"Response times increased 3x starting at 2:15 PM. The slowdown is in OrdersController#index. Specifically, the N+1 query on line 42 is hitting the database 847 times per request instead of once. Here's the fix with includes..."
Not just "it's slow." Why it's slow. And how to fix it.
What Pulse tracks
Every request. Full timing breakdown:
- Controller time
- Database time
- View rendering time
- External API calls
Every query. With performance data:
- Query text
- Execution time
- Rows returned
- Where it was called from
Background jobs. Whatever you use—Sidekiq, ActiveJob, Resque:
- Queue time
- Execution time
- Success/failure rates
External services. APIs, Redis, S3, everything:
- Response times
- Error rates
- Retry patterns
The Rails integration
# Gemfile
gem 'brainzlab'
# config/initializers/brainzlab.rb
BrainzLab.configure do |config|
config.pulse_url = "http://pulse.localhost"
end
# That's it. Automatic instrumentation.
No manual spans. No code changes. Pulse instruments Rails automatically.
Controllers, database queries, view rendering, external HTTP calls—all captured without touching your code.
The killer feature: correlation
This is what makes Pulse different from New Relic or Datadog.
Every trace links to:
- Recall logs from the same request
- Reflex errors that occurred
- Other traces from the same user session
Click a slow request, see everything that happened.
"Why was this request slow?" becomes answerable in seconds, not hours.
Distributed tracing
Running microservices? Pulse tracks requests across service boundaries.
Request hits API gateway → forwards to users service → calls billing service → returns.
One trace shows the full journey. Trace IDs propagate automatically. No manual correlation needed.
Try it
# Already have the stack?
docker-compose up -d pulse
# Starting fresh?
git clone https://github.com/brainz-lab/stack.git
cd stack && ./scripts/setup.sh
docker-compose up -d pulse timescaledb redis traefik
Open http://pulse.localhost.
The observability trio is complete
With Pulse live, the core stack is done:
- Recall — What happened (logs)
- Reflex — What broke (errors)
- Pulse — What's slow (performance)
Three products that work together. One AI that can query them all.
Next up: Signal (alerting) to tie everything together and actually tell you when something's wrong.
— Andres