Follow the Journey
3 min read

Recall is Live

Logs that AI can actually search

This is the one I've wanted to build for years.

Every logging system has the same fundamental problem: when something breaks at 3am, you're the one digging through logs. The fancy dashboards don't help. The complex query languages don't help. It's still you, bleary-eyed, scrolling through text.

What if Claude could do it instead?

The frustration that started this

"Why did the payment fail for user 12345 yesterday?"

Claude's answer, every single time:

"I don't have access to your logs. Could you search your logging system and share what you find?"

So you open Datadog. Write a query. Scroll through thousands of lines. Copy what looks relevant. Paste it into Claude. Wait for analysis.

"Can you also show me what happened right before that?"

Back to Datadog. New query. More scrolling. More copying. More pasting.

I've done this dance hundreds of times. It's inefficient. It's frustrating. And it's completely unnecessary.

The solution

Recall gives Claude direct access to your logs via MCP.

"Why did the payment fail for user 12345 yesterday?"

Claude searches Recall. Finds the relevant entries. Analyzes them. Responds:

"The payment failed because the card was declined with code 'insufficient_funds'. This happened at 2:34 PM. The user had attempted 3 transactions that day, all declined for the same reason. There's also a log entry showing the user updated their payment method at 3:15 PM—so they might have fixed it."

No copying. No pasting. No query syntax. Just ask.

The magic is in the structure

Recall isn't just a log bucket. It stores structured data:

BrainzLab::Recall.info("Payment processed",
  user_id: 123,
  amount: 99.99,
  currency: "USD",
  payment_method: "card",
  card_last4: "4242"
)

Now Claude can search by user_id, filter by amount, group by payment_method. Natural language in, structured queries out.

"Show me all payments over $100 that failed last week" becomes a real query, not a grep nightmare.

Rails integration

If you're on Rails, it's almost embarrassingly simple:

# Gemfile
gem 'brainzlab'

# config/initializers/brainzlab.rb
BrainzLab.configure do |config|
  config.recall_url = "http://recall.localhost"
  config.recall_api_key = ENV['RECALL_INGEST_KEY']
end

Then log like normal:

BrainzLab::Recall.info("User signed up", user_id: user.id)
BrainzLab::Recall.warn("Rate limit approaching", current: 95, max: 100)
BrainzLab::Recall.error("Database connection failed", error: e.message)

Request logging? Automatic middleware. Background job tracking? Built-in. It just works.

Try it now

You can run Recall locally in 5 minutes:

git clone https://github.com/brainz-lab/stack.git
cd stack
./scripts/setup.sh
docker-compose up -d recall timescaledb redis traefik

Open http://recall.localhost and start logging.

Full quickstart guide: /quickstart/recall

The bigger picture

Recall is piece one of the observability puzzle.

Reflex (errors) tells you what broke. Pulse (APM) tells you what's slow. Signal (alerts) tells you when to wake up.

Together, they give Claude complete visibility into your running application.

"Why is the app acting weird today?"

Claude checks Pulse for slow endpoints. Recall for unusual log patterns. Reflex for error spikes. Correlates everything. Gives you the answer.

That's where we're going. Recall is the foundation.

— Andres

Want to follow the journey?

Get Updates