Select a Category
Collect Logs > Controlling Verbosity

Controlling Verbosity

Rails

By default, Rails logs are extremely verbose. For example, every partial rendered generates a log message, even in production. Most of the verbosity is rarely useful, and often it’s simply noise that has no value at all.

Here are a few recommendations which improve the signal:noise. We’re happy to help implement or tweak any of these.

Improve formatting

Log 1 line per request: use a gem like lograge or a Rails initializer like this one to generate far denser log messages, usually with no loss in information detail. For example:

1.2.3.4 GET /path 200 OK BlahController#action HTML 938.2 (DB 11.8, View 719.7) {params} {optional params set in flash[:log]}

See:

Reduce noise

To filter noise, you can filter log messages at the sender or on Papertrail (log filtering). Some ideas what to filter:

  • Static asset requests: Disable logging requests for static assets (asset pipeline). In Rails >= 4.2.7, use config.assets.quiet. In older Rails versions or Rails apps using a non-Sprockets asset pipeline, try the quiet_assets gem or remote_syslog’s exclude_patterns.
  • Unnecessary actions: disable logging requests for certain actions, like with the ciunas gem or silencer. If the vast majority of your requests are for a single action or group of actions (for example, a monitoring action or a very simple GET API request), and you don’t use those messages, the log messages are noise that only distract from real visibility. Please note that ciunas is not thread-safe (and silencer is only thread-safe in Rails >= 4.2.6).

See:

Control verbosity

  • Confirm existing verbosity: make sure your app is not unintentionally logging at DEBUG level. This is much more common than it sounds. DEBUG is the default when a new Logger class is instantiated and the level is not changed. Often a new Logger is instantiated during deployment. Here’s more on Heroku log levels. Also, Rails 5 changes the default production log level from INFO to DEBUG.
  • Decrease verbosity: move to INFO or WARN log level in production. By default, Rails 4.2 and prior use INFO log level in production and DEBUG in other environments. Rails 5 and after use DEBUG everywhere. For almost all apps, INFO is more appropriate in production, and for many apps, WARN is. Even in situations where one actually wants extreme visibility, Rails’ default DEBUG output is probably not the right choice; not many administrators need a list of every partial rendered in a given view.
The scripts are not supported under any SolarWinds support program or service. The scripts are provided AS IS without warranty of any kind. SolarWinds further disclaims all warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The risk arising out of the use or performance of the scripts and documentation stays with you. In no event shall SolarWinds or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the scripts or documentation.

Datasheet Help Contact @papertrailapp Legal Documents California Privacy Rights Software Services Agreement Privacy Notice GDPR Resource Center SolarWinds Subscription Center

© 2026 SolarWinds Worldwide, LLC. All rights reserved.