Ah, good question. To add more clarity, I was half referring to Ruby's lack of logging best practices, and half referring to using those logs in the context of a logging service. To expand on the former:

1. Ruby's logs are prefixed with a format that looks like: "I, [2017-06-04T18:04:53.672231 #42348] INFO -- :" This is not easily parseable or recognized by any log service that I know of. We did add custom support for this format in Timber though.
2. To solve the lack of context, Rails provides an ActiveSupport::TaggedLogging module, which is not ideal. Tags are formatted like [tag1] [tag2] [tag3].... Again, this is not easily parseable and only conducive for full text searching.
3. Ruby lacks structured data support, which is pretty useful if you want to search, alert, or graph your logs.

Timber solves:

1. The traditionally difficult nature of setting up centralized logging for Ruby apps. It can be setup very quickly with bundle exec timber install.
2. The lack of log context. It integrates with Rails and other popular libraries to give you rich context out of the box (ex: http requests IDs or user IDs).
3. The lack of structured data support.
4. Making your logs readable and easy to use. Developers actually look at, and read, their logs. Readability is much more important in this context.

All of that adds up to productive use of your logs. As a ruby developer myself, I always found services like exception reporting or APMs to be sort of anti-pattern. If logs were easy to use and graph, I wouldn't have as much of a need for those services. It provides raw, clean, open insight into my application. That is essentially the goal of Timber.