Control Shopware Logging with Monolog

Exclude redundant messages from your Shopware log files, exclude specific exceptions, and limit exception logging with error log levels using Monolog.


By. Jacob

Edited: 2023-02-14 11:51

One thing I have been surprised by about Shopware, is the fact that I was getting messages in my log about 404 HTTP responses, and many other non-error events. Much later I found out this happens because Shopware uses Monolog, and by default the logging level that is just a bit too aggressive.

For example, if a product or page is not found, then that is not really an error – it is just part of how the internet works when users request non-existent resources – you do not want to be notified about it in your error logs.. However, each time a product or page is not found, an exception such as: NotFoundHttpException and ProductNotFoundException will be thrown and, depending on settings, possibly logged.

Luckily you can turn these irrelevant messages off in the shopware/config/packages/monolog.yaml file by adjusting the log level.

Disable logging

You could use a level: alert to more or less disable most logging, which may be desirable in a stable production environment, but the problem with this is that you will miss actually important (critical) error messages.

            type: fingers_crossed
            action_level: alert
            excluded_http_codes: [404]
            handler: nested
            type: rotating_file
            level: error
            buffer_size: 30
            max_files: 2
      level: error

1. The setting the business_event_handler_buffer to a level of error will disable event logging for events that succeeded.

2. limiting the buffer_size should prevent memory overflows for long lived jobs.

If you must, essentially, a level of alert or emergency will disable most logging by Monolog.


  1. debug: Detailed debug information.
  2. info: Interesting events. Examples: User logs in, SQL logs.
  3. notice: Normal but significant events.
  4. warning: Exceptional occurrences that are not errors. Examples: Use of deprecated APIs, poor use of an API, undesirable things that are not necessarily wrong.
  5. error: Runtime errors that do not require immediate action but should typically be logged and monitored.
  6. critical: Critical conditions. Example: Application component unavailable, unexpected exception.
  7. alert: Action must be taken immediately. Example: Entire website down, database unavailable, etc. This should trigger the SMS alerts and wake you up.
  8. emergency: Emergency: system is unusable.


It is a good idea to leave the logging level on either critical or error in order to catch potentially important errors.

Limit the number of log files

You can also limit the number of log files using the max_files setting in shopware/config/packages/monolog.yaml:

            type: fingers_crossed
            action_level: error # Errors of this level is sent for handling?
            handler: nested
            type: rotating_file
            level: error # Errors of this level is logged?
            max_files: 2 # Max number of log files

Excluding specific exceptions

If adjusting the error level is undesirable, you may also be able to exclude specific exceptions from the log by listing their fully qualified name in config/packages/shopware.yaml.

My shopware.yaml file now includes these exceptions:

            - Symfony\Component\HttpKernel\Exception\NotFoundHttpException
            - Shopware\Core\Content\Product\Exception\ProductNotFoundException
            - Shopware\Core\Content\Category\Exception\CategoryNotFoundException
            - Shopware\Storefront\Framework\Captcha\Exception\CaptchaInvalidException
            - Shopware\Core\Content\Product\SalesChannel\Exception\ProductSortingNotFoundException
            - League\OAuth2\Server\Exception\OAuthServerException

Of course, there are also times you want to investigate 404 errors, but mostly you can safely ignore them, because they are completely normal, and indeed, even expected.

If logs are still spammed

If this does not work, your installation of Shopware might be buggy. I noticed it stopped working after I updated to, and I currently suspect it to be a bug. For HTTP errors, I found you can also exclude them in shopware/config/packages/monolog.yaml. E.g:

            type: fingers_crossed
            action_level: error
            excluded_http_codes: [404] # Exclude 404 messages
            handler: nested
            type: rotating_file
            level: error

I have also noticed the log spammed with OAuthServerException messages; these seem to happen mostly when sessions are invalidated in and; when people are logged out, they still have their browsers open, which then continuously "ping" API endpoints, resulting massively spamming the log file.

I suspect it to be a mistake that OAuthServerException is reported as a critical error, so unfortunately it will be logged even with a level: critical setting.

Harmless exceptions

It looks like quite a few Exceptions about expected situations are logged, in particular Shopware is quite aggressive about logging 404 Not Found messages, even though they are normal, expected, and not super relevant.

I think what we need to note before disabling specific exceptions is the following:

  1. Is the system working?
  2. Is anyone complaining that something does not work?

If you can answer yes and no to the above questions, and the Exception is not otherwise suspicious, then you can go ahead and ignore it, perhaps even disable it so it does not distract from actual errors in your shop.

Feel free to add your own exceptions in the comments!


Well, in my case, these seem to happen when a demo product is disabled, and as such I also do not want Shopware's log to be spammed with these messages. But, there might be cases where you do want to be notified about it, so be careful not to miss important messages. First verify the cause, then disable them in the log if you deem them redundant.


I have investigated these a bit, and what I found is that typically Shopware will complain about a specific category ID. If I look up this ID in the category table of the database, I can tell that the category is inactive, which is probably the cause of the exception, and as such I think it is safe to disable logging for this too.


I am not sure where this comes from, and in fact, I am not even sure we are using a CAPTCHA anywhere on our website. Maybe this comes from the contact form? It looks like another of those non-errors that are logged, and that is totally safe to disable.


Yeah, another Not Found error. I stopped caring at this point and disabled it without further investigation.

It probably happens when a product sorting in the backend returns no results.


This one is absolutely nasty, because it results in massive spam to the log files. I first started noticing it after updating to Shopware, and I suspect it usually has something to do with invalidated sessions. I have no idea why this is logged, because it's usually an expected event that happens all the time. This exception is excluded in examples on Github, like this shopware.yaml file.


  1. Performance Tweaks -
  2. Logging -

Tell us what you think:

  1. Sometimes we may to manually clear cached Shopware files to fix namespace issues.
  2. How to obtain the currently selected API language from Shopware vue components.
  3. How to access file system paths from storefront twig files in Shopware.
  4. How to get or change the currently selected sales channel in an Shopware sw-sales-channel-switch component.
  5. In this tutorial you will learn how to work with Shopware entities in a generic way from PHP, without having to specifically inject the repository in your services.xml file.

More in: Shopware