Fehlerprotokolle in Magento 2 analysieren: Deadlocks, 500er & var/log

Es ist Montagmorgen, der Kaffee dampft noch, und ein Kunde meldet einen „weißen Bildschirm” im Checkout. Du loggst dich per SSH auf den Server ein — und dann? In Magento 2 steckt die Antwort fast immer in den Logs. Die Frage ist nur, in welcher Datei, und wie du aus einem 40 Zeilen langen Stack Trace die eine Zeile herausfischst, die zählt. Genau das schauen wir uns hier an: welche Log-Datei wofür zuständig ist, wie du 500er-Errors und Deadlocks aufspürst, und mit welchen Befehlen du in zwei Minuten weiter bist statt in zwei Stunden.

Vorab eine Einordnung: Log-Analyse ist kein Selbstzweck. Ein Fehler, der im Checkout zuschlägt, ist ein abgebrochener Kauf — und der fällt erst auf, wenn der Umsatz schon weg ist. Wer seine Logs proaktiv im Blick hat, sieht das Problem oft, bevor der erste Kunde anruft. Das ist der Unterschied zwischen reagieren und vorbeugen.

Wo Magento 2 seine Fehler hinschreibt: var/log im Überblick

Magento 2 protokolliert über Monolog in den Ordner var/log. Dort landet fast alles, was im Hintergrund passiert. Welche Datei für was zuständig ist:

Datei	Inhalt
exception.log	Kritische Ausnahmen mit Stack Trace. Dein erster Anlaufpunkt, wenn etwas hart abbricht.
system.log	Warnungen und Hinweise. Selten sofort fatal, aber ein guter Frühwarn-Indikator.
debug.log	Detail-Logs für Entwickler. Nur im Developer-Mode aktiv, sonst aus Speichergründen still.
cron.log	Status der Hintergrundjobs — Indexierung, E-Mail-Versand, Reindex.
payment.log	Kommunikation mit Zahlungsanbietern. Pflichtlektüre, wenn Zahlungen fehlschlagen.

Du musst kein Profi sein, um diese Dateien zu lesen. Drei Shell-Befehle reichen für 90 % der Fälle:

tail -f var/log/exception.log              # live mitlesen, während du den Fehler reproduzierst
grep -i "critical" var/log/system.log      # nach Schweregrad filtern
grep "2026-06-11 09:1" var/log/exception.log   # auf einen Zeitraum eingrenzen

Der Trick liegt im Zeitstempel. Wenn ein Kunde dir sagt „kurz nach neun ging nichts mehr”, grenzt grep auf die Minute genau ein und du sparst dir das Scrollen durch tausende Zeilen. Stimmt der Zeitstempel im Log mit der Kundenmeldung überein, hast du den Übeltäter meist schon.

exception.log lesen: den Stack Trace entschlüsseln

Die exception.log ist bei schweren Fehlern dein wichtigster Freund. Stürzt ein Modul ab oder läuft eine Datenbankabfrage ins Leere, schreibt Magento einen Stack Trace hinein — diese verschachtelte Liste aus Klassen- und Dateinamen, die auf den ersten Blick wie Buchstabensalat wirkt.

Lies sie von oben nach unten. Die erste Zeile nennt die eigentliche Fehlermeldung (TypeError, Could not save, Class does not exist). Darunter folgt der Pfad durch den Code — und hier liegt die wichtigste Information: Tauchen in den Pfaden Namen von Drittanbieter-Modulen auf (vendor/acme/modul-xy/...), ist selten Magento selbst das Problem, sondern eine Erweiterung, die nicht sauber programmiert wurde. Wie stark Drittanbieter-Module auf Stabilität und Sicherheit durchschlagen, haben wir in Auswirkungen von Drittanbieter-Modulen auf einen Hyvä-Shop ausführlicher beschrieben.

Die system.log dagegen sammelt Dinge, die noch nicht crashen, aber stören — veraltete Methoden, fehlende Templates, nicht aufgelöste Abhängigkeiten. Ein Shop, dessen system.log minütlich Warnungen produziert, läuft vielleicht noch. Stabil ist anders.

Der 500 Internal Server Error: eine Ebene tiefer suchen

Nichts ist auskunftsfreudiger als ein „500 Internal Server Error” — er sagt dir genau nichts. Das Tückische: Bei einem echten 500er findest du in den Magento-Logs oft gar nichts, weil der Webserver oder der PHP-Prozess abbricht, bevor Magento überhaupt zum Schreiben kommt. Du musst also eine Ebene tiefer.

Die Server-Logs liegen außerhalb des Magento-Verzeichnisses, typischerweise hier:

tail -50 /var/log/nginx/error.log          # oder /var/log/apache2/error.log
tail -50 /var/log/php8.3-fpm.log           # PHP-FPM, Version je nach Setup

Die häufigsten Ursachen für einen 500er in Magento 2:

• Memory Limit überschritten — PHP bricht ab, im FPM-Log steht Allowed memory size … exhausted. Magento 2.4 will mindestens 2 GB memory_limit für viele CLI-Tasks.
• Falsche Dateiberechtigungen — Magento ist pingelig bei den Rechten auf var/, generated/ und pub/static/. Nach einem Deploy gerne mal kaputt.
• PHP-Version inkompatibel — eine Extension verlangt eine neuere PHP-Version, als auf dem Server läuft.
• Kaputte .htaccess oder nginx-Config — ein Tippfehler legt den ganzen Shop lahm.

Auf einer Test- oder Staging-Instanz hilft der Developer-Mode, weil Magento den Fehler dann direkt im Browser ausgibt statt ihn zu verschlucken:

bin/magento deploy:mode:set developer

Auf Produktivsystemen lässt du den Production-Mode an — dort gehört der Stack Trace ins Log, nicht auf den Bildschirm eines Kunden.

Deadlocks: wenn zwei Prozesse sich gegenseitig blockieren

Stell dir eine enge Kreuzung vor, auf der zwei Autos gleichzeitig in die Mitte fahren — keiner kommt mehr vor oder zurück. Genau das ist ein Datenbank-Deadlock: Zwei Prozesse wollen dieselben Zeilen sperren, in umgekehrter Reihenfolge, und blockieren sich gegenseitig. MySQL bricht dann einen der beiden ab. Im Log steht:

SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock

In Magento 2 passiert das gehäuft während der Indexierung, bei großen Importen oder bei sehr hohem Bestellaufkommen — also genau dann, wenn parallel viel auf dieselben Tabellen (catalog_product_index_price, inventory_*, sales_order) geschrieben wird. Die Tücke: Deadlocks treten oft nur sporadisch unter Last auf und sind im ruhigen Moment nicht reproduzierbar.

Wer tiefer graben will, fragt MySQL direkt:

SHOW ENGINE INNODB STATUS\G   -- Abschnitt "LATEST DETECTED DEADLOCK"

In der Praxis lassen sich die meisten Deadlocks aber schon durch Planung vermeiden:

• Indexer auf „Update on Schedule” statt „Update on Save” stellen — dann reindexiert Magento gebündelt per Cron statt bei jedem Speichern.
• Rechenintensive Cronjobs und Importe aus den Stoßzeiten herausnehmen. Ein Vollimport zur Mittagszeit ist eine Einladung zum Deadlock.
• Message Queue sauber konfigurieren, damit asynchrone Jobs nicht gegen die Indexer laufen.

Unter echtem Lastdruck — Stichwort Black Week — steigt das Deadlock-Risiko spürbar; wie man sich auf solche Traffic-Spitzen vorbereitet, zeigt unsere Blackweek-Checkliste für den Shop.

var/report: die ID auf dem Fehlerbildschirm ist ein Dateiname

Manchmal zeigt Magento dem Kunden „There has been an error processing your request” plus eine lange Nummer. Viele halten das für einen kryptischen Code — dabei ist es schlicht ein Dateiname. Geh in den Ordner var/report und öffne die Datei, die genau so heißt wie die Nummer auf dem Bildschirm:

cat var/report/1234567890123

Darin steht der komplette Fehlerbericht inklusive Stack Trace. Dass Magento das so trennt, ist Absicht: Ein Angreifer soll im Browser keine technischen Interna sehen. Die Details bleiben dem Admin vorbehalten — also dir.

Aus Nachschauen wird Überwachen: die laufende Routine

Logs nur dann zu öffnen, wenn es schon brennt, ist die teure Variante. Ein paar Gewohnheiten, die sich im Alltag bewähren:

• Zeitstempel zuerst. Bei jeder Meldung die exakte Uhrzeit notieren — sie ist dein Filter.
• Log-Größe im Blick behalten. Eine system.log, die plötzlich auf mehrere Gigabyte anwächst, ist selbst schon ein Problem: Sie verlangsamt den Shop und signalisiert, dass irgendwo etwas im Sekundentakt schiefläuft. Log-Rotation einrichten.
• Drittanbieter-Module isolieren. Bei diffusen Fehlern testweise zuletzt installierte Module deaktivieren. Erstaunlich oft sitzt dort die Ursache.
• Cache und Logs nach jedem Deploy prüfen. bin/magento cache:flush und ein kurzer Blick in die Logs gehören zum Deploy dazu.

Wer hier dranbleibt, verwandelt Logs von einem Notfall-Werkzeug in ein Frühwarnsystem.

Was du als nächstes tun kannst

Wenn dein Shop gerade unrund läuft oder du wiederkehrende 500er und Deadlocks vermutest, gibt es zwei pragmatische erste Schritte:

1. Selbst-Diagnose: Reproduziere den Fehler bei laufendem tail -f var/log/exception.log und merk dir den Zeitstempel. Findest du in den Magento-Logs nichts, schau ins nginx-/php-fpm-Log — dort sitzt der 500er.
2. CopeX-Betreuung: Wir übernehmen Monitoring, Log-Analyse und Fehlerbehebung als laufende Magento-Betreuung, damit Deadlocks und 500er auffallen, bevor ein Kunde sie meldet. Kontakt: office@copex.io oder Anfrage stellen.

Verwandte Themen aus unserem Blog: Auswirkungen von Drittanbieter-Modulen auf Stabilität und Sicherheit, Blackweek-Checkliste für den Shop, Sicheres Update- und Patch-Management für Magento.

Jeder Fehler, den du im Log findest und behebst, ist ein verhinderter Warenkorbabbruch. Und ehrlich: Ein gepflegtes var/log sagt mehr über die Gesundheit eines Shops aus als jedes Dashboard.

Quellen / Weiterlesen

• Adobe Commerce Developer Docs — Logging & Debugging (developer.adobe.com/commerce)
• MySQL Reference Manual — InnoDB Deadlocks (dev.mysql.com)
• Monolog — Logging-Library hinter Magento (github.com/Seldaek/monolog)