Shopware-Logdateien verwalten: was in var/log liegt, warum es wächst und wie Sie es begrenzen

Ein Shopware-Shop schreibt Logs an zwei Orte: in Dateien unter var/log und in eine Tabelle der Datenbank. Für die Datenbank räumt Shopware selbst auf. Für die Dateien tut es das in der Standardkonfiguration nicht. Das merkt man meist erst, wenn der Speicherplatz knapp wird oder jemand fragt, wie lange Logs eigentlich aufbewahrt werden.

Wie Sie eine einzelne Fehlerzeile finden und lesen, beschreibt der Ratgeber Shopware zeigt einen Fehler 500. Hier geht es um Ablage, Rotation, Aufbewahrung und Speicherplatz.

Die Log-Konfiguration haben wir im Kern von Shopware 6.6.10.6 und 6.7.2.2 gelesen und mit den Versionen 6.6.10.30 und 6.7.16.0 abgeglichen; sie ist in allen vier gleich. Das Verhalten haben wir am 11.11.2026 in Wegwerf-Containern beider Versionen im Produktivmodus nachgestellt. Beide verhielten sich gleich.

Zwei Orte, zwei Regeln

Nicht in dieser Tabelle stehen die Logs von Webserver und PHP. Sie liegen beim Hosting, und dort gelten dessen Regeln.

Was im Produktivmodus in die Datei kommt

Mit APP_ENV=prod sammelt Shopware die Meldungen einer Anfrage zunächst im Speicher. Erst wenn eine Meldung der Ebene error oder höher dazukommt, schreibt es in die Datei, und auch dann nur Einträge ab error. Hinweise und Warnungen bleiben draußen. Das hält die Dateien klein.

Drei Dinge fehlen deshalb im Log, obwohl man sie dort vermuten würde:

• Seiten, die es nicht gibt. Die Ausnahme für den Status 404 steht in Shopwares Ausschlussliste. In unserem Test hinterließ der Aufruf einer nicht vorhandenen Adresse keinen Eintrag.
• Erwartbare Fehler. Für eine Reihe von Fehlercodes setzt Shopware die Ebene auf notice herab, darunter falsche Anmeldedaten im Kundenkonto und abgebrochene Zahlungen. Im Produktivmodus erscheinen sie damit nicht mehr in der Datei.
• Fehler vor Shopware. Scheitert eine Anfrage am Webserver oder an PHP selbst, schreibt Shopware nichts.

Fehler auf der Kommandozeile landen dagegen in derselben Datei. Ein unbekannter Befehl erzeugte in unserem Test diesen Eintrag (gekürzt):

[2026-11-11T13:12:38+00:00] console.CRITICAL: Error thrown while running command "'pixup:gibt-es-nicht'". Message: "There are no commands defined in the "pixup" namespace."

Die Datei hieß prod-2026-11-11.log. Eine Datei entsteht nur an Tagen, an denen etwas geschrieben wird. An einem Tag ohne Fehler gibt es keine.

Warum var/log trotzdem wächst

Für den Produktivmodus richtet Shopware einen Handler vom Typ rotating_file ein. „Rotierend“ heißt hier: je Tag eine neue Datei. Eine Obergrenze für die Zahl der Dateien setzt die Konfiguration im Kern nicht. Dann gilt der Standardwert des MonologBundles, und der ist 0. Für Monolog bedeutet 0: unbegrenzt.

In unserem Test haben wir 20 ältere Tagesdateien angelegt und danach einen Fehler ausgelöst. Es entstand die Datei des aktuellen Tages, gelöscht wurde nichts. Am Ende lagen 22 Dateien im Verzeichnis: die 20 angelegten, eine, die schon im Container-Image lag, und die neue. In 6.6.10.6 und in 6.7.2.2 war das Ergebnis gleich.

Ein Shop mit wenigen Fehlern merkt davon lange nichts. Bei einem Shop, der täglich Fehler schreibt, etwa durch ein fehlerhaftes Plugin, wächst das Verzeichnis jeden Tag weiter.

Ein Wert, der nichts bewirkt

In der Shopware-Konfiguration steht unter shopware.logger der Wert file_rotation_count: 14. Der Name legt nahe, dass er die Zahl der Logdateien begrenzt. Im Code von 6.6.10.6 und 6.7.2.2 und im Quelltext von 6.7.16.0 wird der Wert aber nur deklariert; keine andere Stelle liest ihn. Wer ihn ändert, ändert an var/log nichts.

Die Zahl der Dateien begrenzen

Die Grenze setzen Sie in der Monolog-Konfiguration Ihres Projekts. Legen Sie die Datei config/packages/prod/monolog.yaml an oder ergänzen Sie sie:

monolog:
    handlers:
        nested:
            max_files: 14

nested ist der Name, den Shopware dem schreibenden Handler im Kern gibt. Ihre Angabe ergänzt dessen Einstellungen, der Rest bleibt, wie er ist. Danach den Cache leeren:

bin/console cache:clear

In unserem Test lagen nach dem nächsten Fehlereintrag noch 14 Dateien im Verzeichnis: die Datei des aktuellen Tages und die 13 jüngsten älteren. Die übrigen, auch die aus dem Image, waren gelöscht.

Drei Dinge sollten Sie dabei wissen:

1. Gezählt werden Dateien, nicht Tage. Weil an fehlerfreien Tagen keine Datei entsteht, reichen 14 Dateien oft deutlich weiter zurück als 14 Tage.
2. Aufgeräumt wird beim Anlegen einer neuen Datei. Das passiert mit dem ersten Eintrag eines Tages. Die Grenze wirkt also nicht sofort nach dem Deployment, sondern beim nächsten Fehler an einem neuen Tag.
3. Sortiert wird nach Dateinamen. Gelöscht werden die ältesten Dateien, die zum Muster prod- plus Datum passen. Andere Dateien in var/log bleiben unberührt.

Die Konfigurationsdatei gehört ins Projekt-Repository, damit sie beim nächsten Deployment nicht verloren geht. Hat Ihr Shop bereits eine eigene Monolog-Konfiguration oder rotiert Ihr Hosting var/log selbst, etwa mit logrotate, stimmen Sie beides ab. Sonst greifen zwei Regeln auf dieselben Dateien zu.

Ereignis-Logs in der Datenbank

Ein Teil der Logs landet nicht in einer Datei, sondern in der Tabelle log_entry. In der Administration finden Sie ihn unter Einstellungen > System > Ereignis-Logs. Dorthin schreibt Shopware unter anderem Flow-Ereignisse mit einer Logstufe und fehlgeschlagene Mails.

Für diese Tabelle gibt es eine eigene Aufräumregel. Die geplante Aufgabe log_entry.cleanup läuft täglich und löscht:

Der Wert -1 schaltet die jeweilige Regel ab. Beide Standardwerte haben wir in 6.6.10.6 und 6.7.2.2 direkt in der Datenbank gelesen.

Das Aufräumen funktioniert nur, wenn die geplanten Aufgaben laufen. Steht der Scheduled-Task-Runner, wächst auch die Tabelle log_entry ohne Grenze. Woran das liegen kann, beschreibt Warum ein Scheduled Task nicht läuft.

Speicherplatz prüfen

Diese Befehle lesen nur und ändern nichts. Sie laufen im Hauptverzeichnis des Shops:

du -sh var/log
ls -lh var/log | tail -n 20
ls var/log | grep -c '^prod-'

Der erste zeigt die Größe des Verzeichnisses, der zweite die letzten Dateien mit Größe, der dritte die Zahl der Tagesdateien. Ist eine einzelne Tagesdatei auffällig groß, lohnt ein Blick hinein. Oft wiederholt sich derselbe Fehler tausendfach. Dann ist nicht das Log das Problem, sondern der Fehler.

Läuft der Datenträger voll, kann Shopware gar nicht mehr schreiben, auch kein Log. Ein Fehler 500 ohne Logeintrag kann genau das bedeuten.

Shopware schreibt im Produktivmodus eine Logdatei je Tag mit Fehlern und löscht in der Standardkonfiguration keine. Eine Zeile max_files begrenzt das. Die Ereignis-Logs in der Datenbank räumt Shopware selbst auf, solange die geplanten Aufgaben laufen.

Wer die Logs seines Shops nicht selbst im Blick behalten will: Auf der Seite Shopware Support beschreiben wir, wie wir Shops betreuen.