Fix Issue #2639: "Served asset log messages are pretty annoying!" by adding config variable #3795

wants to merge 1 commit into


None yet

Addresses issue #2639 (#2639) -- there are many assets related log messages and no config variable to hide them. Example log lines:

Started GET "/assets/logo.png" for at 2011-11-24 01:22:02 -0800
Served asset /logo.png - 200 OK (1ms)

With these commits, both asset related logger messages (Sprockets and Rack) can be hidden with a config variable. By default the messages still appear.

To hide the messages, add this line to e.g. application.rb:

config.assets.logger = false

Note: This is a replacement for #3741 (closed), squashed into one commit and no longer hiding the messages by default.

I did some benchmarking. There seems to be a small performance boost from the commit, since it causes Rack to use the Rails logger less frequently.

This gist ( includes a file for the benchmarking code and files for sample output both with and without the config variable config.assets.logger = false.

In each benchmark report, the first and third lines use before_dispatch(env) as it was before my commit, and the second and fourth lines use before_dispatch(env) (renamed before_dispatch_modified(env) here) from my commit. I repeat each, in alternating order, to help account for normal benchmarking fluctuations.

If you include config.assets.logger = false there are fewer calls to the Rails logger and that results in slightly improved performance. For users who do not include the config variable, there is no performance cost (as measured by the benchmark module).

Without the config line specified, the conditional that I added immediately evaluates to true in every case. In the benchmarking reports, sometimes the before_dispatch(env) is faster, sometimes before_dispatch_modified(env) is.

Started GET "/assets/application.css?body=1" for at 2011-11-29 03:04:24 -0800

Started GET "/assets/application.css?body=1" for at 2011-11-29 03:04:24 -0800

Started GET "/assets/application.css?body=1" for at 2011-11-29 03:04:24 -0800

Started GET "/assets/application.css?body=1" for at 2011-11-29 03:04:24 -0800
Served asset /application.css - 200 OK (1ms)
      user     system      total        real
  0.000000   0.000000   0.000000 (  0.000178)
  0.000000   0.000000   0.000000 (  0.000125)
  0.000000   0.000000   0.000000 (  0.000088)
  0.000000   0.000000   0.000000 (  0.000091)

With the config line config.assets.logger = false included, sometimes the conditional evaluates to true and logs (if the path doesn't start with "/assets/"), sometimes to false (if it does start with "/assets/"). Performance is consistently faster than without the config line for false evaluations, and true evaluations have results that are similar to the no-config results.

Started GET "/assets/application.css?body=1" for at 2011-11-29 03:03:18 -0800

Started GET "/assets/application.css?body=1" for at 2011-11-29 03:03:18 -0800
      user     system      total        real
  0.000000   0.000000   0.000000 (  0.000191)
  0.000000   0.000000   0.000000 (  0.000075)
  0.000000   0.000000   0.000000 (  0.000114)
  0.000000   0.000000   0.000000 (  0.000063)

So there seems to be a side benefit of a performance gain of a few ten-thousandths of a second for each request.

@drogus drogus commented on the diff Dec 10, 2011
@@ -21,8 +21,12 @@ def before_dispatch(env)
request =
path = request.filtered_path
- info "\n\nStarted #{request.request_method} \"#{path}\" " \
- "for #{request.ip} at #{}"
+ # If config.assets.logger is set to false, only log non-assets related requests
+ if ((Rails.application.config.assets.logger != false) ||
drogus Dec 10, 2011 Member

You should not use Rails.application here, please see how it's done in case of other similar options:

/cc @josevalim


can you send a PR for master branch instead of 3-1-stable?


Can we PLEASE get something like this in before 3.2 final?


I don't think we should mute both loggers, just one. That said, +1 for config.assets.logger but besides setting it to false, we could also configure sprockets logger through it and therefore use the same logger as Rails, but with increased severity. In other words, I am fine with changes in sprockets/railties (and they could be improved) but I don't think we should change rails/rack/logger. Thanks.

How do we suppress the request log messages without changing rails/rack/logger? The purpose here is to get rid of ALL log messages related to assets. Having these in the log makes it much less useful for development.


We are not special casing the rails logger middleware to get rid of it. As I said, I will gladly accept a patch that allows you to turn off sprockets logger, but we won t special case the middleware.


Someone please submit a new pull request, because I think the original author won't.

@josevalim josevalim closed this Dec 29, 2011

+1 to @electrum: How do we suppress the request log messages without changing rails/rack/logger? I agree with @josevalim that special casing the logger middleware, but in the meantime, it would be great if we could get rid of logging the requests that are served by assets.

j-manu commented Jan 18, 2012

@josevalim If the change is not made in rails/rack/logger then the only other place it can be made is ?

In that case if the user sets a custom logger, the log file will again contain the requests. So IMO the logical place to change it is rack logger since it will work for all loggers.

Correct me If I'm wrong :)


Let me rephrase: Rails won't special case any of the loggers or logger related middlewares to not log specific routes. If you want, you can inherit from the Rails::Rack::Logger in your app and special case it. Meanwhile, to be a bit less verbose, Rails added an option to change Sprockets logger, so you can set it to a higher level like warn/fatal.

ahoward commented Mar 14, 2012

this is really unfortunate. we should not be required to use monkey patches like this:

it's not uncommon, in real apps, to want to shut the logger up for a bit.

ahoward commented Mar 14, 2012

er. should not be...

The current state of this is terrible. You should not have to jump through hoops to make the logger actually useful. 99% of the time you don't want your development logs filled up with noise from the assets being requested. The rails server log is functionally broken as it stands.

If you want to maintain the purity of the logger, then maybe it can be monkey patched within the development environment configuration.

aspiers commented Mar 4, 2013

@MarcoPeraza is absolutely right. Whatever happened to "convention over configuration"?! The cleanest solution I can find out there is the quiet_assets gem which monkey-patches Rails::Rack::Logger. If so, that's a sad state of affairs indeed, considering the large number of developers who have fallen foul of this.

@josevalim, your comment above has been linked to at least twice, by @guilleiguaran here and here as "details about why we won't silent the request logs", but that's very misleading, because your comment doesn't cover why this functionality won't be implemented at all; it simply says that it won't be.

By "you can inherit from the Rails::Rack::Logger in your app and special case it", you seem to be suggesting that every single Rails developer who doesn't want spam in their development log should become a Rack specialist and reinvent the same wheel?! Maybe that wasn't the message you intended, but that's how it comes across.

I see that sprockets will log more silently in Rails 4.0. That's great, but what about ActionPack?

To be clear, I am not necessarily disagreeing with your decision not to make Rails special-case middleware. But given the number of developers who have been bitten by this, I am strongly disagreeing with how this is being handled in terms of (a) finding an alternative user-friendly solution, and (b) communication and documentation of that solution. When a solution based on monkey-patching receives over 240 up-votes on StackOverflow then that is a sure sign that something has gone badly wrong.

csmuc commented Mar 19, 2013

@aspiers thank you for the words, this is as far as you can get from the initial Rails spirit IMO

so did this happen on master (re #4512) or not happen?

jechols commented Mar 6, 2015

I think this is precisely why Apache (and others) have a separate log for the mundane stuff (requests) vs. errors. Maybe that would be a better solution for an issue like this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment