What Ruby Logging Best Practices Leave Out

The gap between "our logs follow every best practice" and "I can actually find what's wrong, fast" is what I want to write about here. I'll go through the standard checklist first, because it's genuinely worth doing. Then I want to talk about the part that checklist doesn't cover.

The Ruby logging best practices I actually follow (and you should too)

Before I get into what logging can't do, I want to give the checklist its due. These aren't controversial, and I use all of them.

✓ Use log levels the way they're meant to be used

Not everything is error. Here's the split I use:

• debug — noisy, dev-only detail (variable state, query params)
• info — normal application flow (user logged in, job started)
• warn — something's off but the app is still working (deprecated method call, a retry that succeeded)
• error — something failed and needs attention
• fatal — the process is going down

If your production logs are 90% error, that's not a badge of honor, it's noise, and it trains everyone to tune out the log level entirely.

✓ Log structured data, not string soup

Compare:

logger.info("User #{user.id} placed order #{order.id} for $#{order.total}")

to:

logger.info(event: "order_placed", user_id: user.id, order_id: order.id, total: order.total)

The second one is actually queryable. I can filter, aggregate, and alert on it. The first one is just a sentence a computer has to guess at.

✓ Attach context to every entry

Request ID, user ID, environment, and anything else I'd want if I were staring at this line out of context at 3am. If a log line doesn't tell me whose request this was or which deploy it happened under, I'm doing a lot more Slack-message-archaeology than I need to.

✓ Never log PII or secrets

No passwords, tokens, full credit card numbers, or anything that turns log storage into a compliance headache. I scrub it before it hits the logger, not after.

✓ Set log levels per environment

Debug-level everything in development, something saner (info or warn) in production. Nobody needs a play-by-play of every ActiveRecord query in prod.

✓ Use a real logging library

Ruby's built-in Logger, Lograge for Rails request logs, or Semantic Logger if I want structured output out of the box. puts is fine for a 5 min local debug session and nothing else.

✓ Watch your volume

Every log line has a cost: storage, ingestion, and my own ability to find anything in the pile. A stray logger.info inside a loop or an N+1 query can quietly 10x log volume before anyone notices the bill.

Do all of that and I promise you'll have genuinely good logs. That's not nothing. But it's also not the whole job.

What this checklist quietly assumes

Here's the thing none of these tips say out loud: they all assume I am the one reading the logs, in real time, already knowing roughly what I'm looking for.

That's a fine assumption when I'm debugging locally. It falls apart the moment I'm on call, three services are throwing errors at once, and the one log line that actually explains the outage is sitting on line 40,000 of a scroll, indistinguishable from a hundred other lines that look almost the same.

Every item on that checklist above is still true, but none of it lives at the layer where these happen:

Grouping

Knowing that these 200 log lines are actually the same underlying failure, not 200 different problems.

Deduplication

A way to tell "this happened once" from "this is happening to every user right now."

Alerting tied to actual impact

Something that pings me when error rate spikes, not just when a single error-level line gets written somewhere.

Prioritization

A way to tell a shrug-worthy edge case from the thing quietly taking down checkout.

A perfectly well-structured log line still just sits there, unless something is actively watching, grouping, and surfacing it. Logging and error tracking are solving different problems, and it helps to see them side by side:

That's the layer I've come to rely on Rollbar for, and it's the reason I don't stop at "good logging" as the whole strategy.

Where Rollbar picks up from here

This is the part I actually wanted to write about. Once my Ruby logs are clean, the next problem is turning a pile of individually-correct log lines into "here's the one thing that's actually broken, right now, and here's how many people it's hitting." That's a different job from logging, and it's the one Rollbar is built for.

If you'd rather watch this than read it, here's a quick walkthrough of tracking and fixing Rails errors in Rollbar:

Grouping and deduplication, automatically

Rollbar fingerprints errors so the same underlying failure gets grouped together instead of showing up as a hundred near-identical entries. Instead of scrolling through duplicates, I see one item: this error, this many occurrences, this many users affected.

Full context, not just a line

Every error comes with the surrounding context - stack trace, request data, deploy version, environment - so I'm not reconstructing what happened from a bare log line and a timestamp.

Alerting on what matters

Rollbar alerts on error rate and impact, not just on the existence of an error-level log line, so a spike gets flagged instead of scrolling by.

And now, Rollbar can help fix the error too

The newest piece, and honestly the one I'm most interested in, is Rollbar Resolve. Once Rollbar has identified and grouped an error, Resolve takes it from there:

1. Reviews the codebase to understand the context around the error
2. Identifies what's actually going wrong, not just where it surfaced
3. Applies a fix in an isolated environment, away from my own in-progress work
4. Runs the test suite against the fix before anything is proposed
5. Opens a pull request - already validated, not a theoretical patch

I still review and approve every fix like I would any teammate's PR and I control which errors Resolve is allowed to touch.

There's also Root Cause Analysis, which is available now: it looks at related errors across front-end and back-end projects (instead of investigating each in isolation) and hands me a root cause analysis attached to every error involved - so I'm not just told that something broke, but why, before I've opened a single log file.

That's the piece good logging was never going to give me on its own. Logs tell me what happened. Rollbar tells me what matters and, increasingly, helps me fix it.

The takeaway

Good logging is necessary. It's just not the whole job. I still do the checklist - log levels, structure, context, no PII, sane volume - because none of what comes after works without that foundation. But if my plan for "something broke in production" is still "grep the logs and hope I find it fast enough," the gap isn't in my logging practices. It's in what happens after the log line gets written, and that's the part I've handed off to Rollbar.

If you want to see exactly how Rollbar plugs into a Ruby app's logs, Rollbar's Ruby docs walk through setup end to end.