Lösung zu Magento 2 versendet keine E-Mails – nach PHP-Umstellung oder Ausfall Cronjob

Magento 2 versendet keine E-Mails nach PHP-Umstellung oder (unbemerktem) Ausfall des Cronjobs?

Wenn ein Magento 2 Onlineshop plötzlich keine E-Mails wie z.B. Bestellbestätigungen, Rechnungen oder Versandmails mehr versendet, wird oft zuerst beim SMTP-Server gesucht. Das ist verständlich. E-Mail-Problem klingt nach Mailserver-Problem.

In der Praxis liegt die Ursache aber manchmal an einer ganz anderen Stelle. Der Magento Cronjob läuft nicht mehr korrekt.

Die schnelle Einordnung

Ein besonders tückischer Fall entsteht nach einer PHP-Umstellung. Der Shop selbst funktioniert im Browser scheinbar normal. Das Backend ist erreichbar. Kunden können bestellen. Nur die E-Mails bleiben aus. Wenn die Bestellmails NICHT über Cron-Job verschickt werden, fällt es sogar noch länger nicht auf.

Der Grund kann sein, dass der Cronjob weiterhin eine alte oder falsche PHP-Version aufruft. Im Hintergrund läuft der Versand von E-Mails per Cronjob somit nicht, aber es fällt über Wochen?Monate? womöglich nicht auf.

Der Knackpunkt für den Fall PHP-Umstellung sieht z.B. so aus:

* * * * * /usr/bin/php8.2 /var/www/magento/bin/magento cron:run 2>&1 | grep -v "Ran jobs by schedule" >> /var/www/magento/var/log/magento.cron.log

Wenn /usr/bin/php8.2 auf dem Server nicht mehr existiert oder nicht mehr zur Magento-Installation passt, läuft der Cronjob nicht sauber. Genau dadurch können geplante Magento-Aufgaben stehen bleiben. Dazu kann auch der Mailversand gehören.

Generell Cron Jobs in Magento

Magento 2 verarbeitet viele Aufgaben nicht direkt beim Seitenaufruf, sondern zeitgesteuert im Hintergrund. Dafür gibt es Cronjobs.

Das betrifft unter anderem:

• Bestellbestätigungen
• Rechnungs-E-Mails
• Versandbenachrichtigungen
• Newsletter
• Preisregeln
• Indexer
• Sitemap-Erstellung
• bestimmte Aufgaben von Erweiterungen
• Wartungs- und Aufräumprozesse

Wenn der Cronjob ausfällt, merkt man das nicht immer sofort. Der Shop kann weiterhin erreichbar sein. Genau das macht den Fehler gefährlich. Man sieht keine weiße Seite, keinen klassischen Totalausfall und oft auch keine direkte Fehlermeldung im Magento Admin.

Stattdessen entsteht ein schleichendes Problem. Kunden warten womöglich auf Bestellbestätigungen. Der Shopbetreiber bekommt keine internen Kopien. Prozesse bleiben liegen. Im schlimmsten Fall betrifft es womöglich sogar nur "unwichtige" Abläufe, die weder Kunden noch Shopbetreiber über lange Zeit auffalln.

SMTP ist nicht immer schuld

Bei fehlendem Mailversand wird häufig zuerst das SMTP-Modul geprüft. Das kann richtig sein. Es kann aber auch in die falsche Richtung führen.

Eine einfache Einordnung hilft:

Symptom	Wahrscheinlicher Bereich
Keine Bestellmails, keine Rechnungen, keine Versandmails	Cronjob oder Queue
Mail wird laut Log versendet, kommt aber nicht an	SMTP, Spamfilter, SPF, DKIM, DMARC
Nur bestimmte Empfänger sind betroffen	Zustellbarkeit oder Mailserver-Reputation
Nur ein E-Mail-Typ fehlt	Magento Sales E-Mail Konfiguration
Nur ein Drittanbieter-Modul sendet nicht	Erweiterung, Cron-Gruppe oder Queue
Alle Cronprozesse sind auffällig	PHP CLI, Crontab oder Serverkonfiguration

Der Unterschied ist wichtig. Ein SMTP-Test kann erfolgreich sein, obwohl Magento die eigentlichen Bestellmails gar nicht verarbeitet. Dann ist der Mailserver erreichbar, aber Magento liefert ihm nichts.

Warum der Fehler nach einer PHP-Umstellung häufig (unentdeckt) passiert

Bei einer PHP-Umstellung wird meist geprüft, ob der Shop im Browser funktioniert. Die Startseite wird geladen. Der Checkout wird getestet. Das Backend wird geöffnet. Vielleicht werden auch einige wichtige Erweiterungen kurz kontrolliert.

Was gerne übersehen wird: Magento läuft nicht nur über den Webserver.

Es gibt auch die PHP-Version für die Kommandozeile. Diese wird häufig als PHP CLI bezeichnet. Genau diese PHP-Version nutzt der Cronjob.

Das bedeutet: Ein Shop kann im Browser bereits mit PHP 8.3 oder PHP 8.4 laufen, während der Cronjob weiterhin versucht, /usr/bin/php8.2 auszuführen. Wenn diese Version nach der Serverumstellung entfernt wurde, zeigt sich das Problem erst bei den Hintergrundprozessen.

Das ist ungefähr so, als würde vorne im Laden alles modernisiert, aber im Lager steht noch der alte Schlüsselplan. Die Tür sieht gut aus. Nur kommt hinten niemand mehr rein.

Was an dieser Crontab problematisch sein kann

Diese Zeile ist grundsätzlich typisch für Magento und oft schlicht auch bereits das Problem/Lösung:

* * * * * /usr/bin/php8.2 /var/www/magento/bin/magento cron:run 2>&1 | grep -v "Ran jobs by schedule" >> /var/www/magento/var/log/magento.cron.log

Problematisch wird sie, wenn einer dieser Punkte zutrifft:

• /usr/bin/php8.2 existiert nicht mehr
• PHP 8.2 ist zwar vorhanden, aber nicht mehr die richtige Version für den Shop
• die CLI-PHP-Version unterscheidet sich von der Webserver-PHP-Version
• der Pfad zu Magento ist nicht mehr korrekt
• der Cronjob läuft unter dem falschen Systembenutzer
• Rechte oder Umgebungsvariablen passen nach der Umstellung nicht mehr
• mehrere Crontabs existieren und die falsche wird geprüft

Gerade die ersten beiden Punkte sind häufig. Nach einem Update wird die alte PHP-Version entfernt oder deaktiviert. Der Cronjob bleibt aber unverändert. Oder ein PHP Skript wird ausgelöst jedoch in der veralteten PHP-Version.

Dann ruft der Server jede Minute eine PHP-Version auf, die es gar nicht mehr gibt und/oder versucht mit einer veralteten Version ein PHP-Skript auszuführen.

Typische Symptome im Magento Shop für Probleme mit Cronjob

Ein defekter Cronjob zeigt sich selten nur an einer Stelle. Häufig gibt es mehrere Auffälligkeiten.

Typische Hinweise sind:

Beobachtung	Mögliche Bedeutung
Kunden erhalten keine Bestellbestätigung	Sales E-Mails werden nicht verarbeitet
Rechnungs- oder Versandmails fehlen	Cron oder E-Mail-Queue bleibt stehen
Newsletter werden nicht versendet	Newsletter-Cron läuft nicht
Preisregeln greifen verzögert	geplante Magento-Aufgaben werden nicht ausgeführt
Indexer bleiben stehen	Cron verarbeitet Index-Aufgaben nicht
Erweiterungen reagieren nicht wie erwartet	Modulaufgaben hängen am Cron
Erweiterungen verschicken keine E-Mails	Magento Erweiterungen schicken keine E-Mails
Im Admin ist die Bestellung sichtbar, aber die Mail fehlt	Shopprozess funktioniert, Hintergrundprozess nicht

Wichtig ist: Der Fehler muss nicht sofort den gesamten Shop lahmlegen. Genau deswegen wird er oft zu spät bemerkt.

Warum Magento Mails vom Cronjob abhängen können

Magento kann E-Mails direkt oder asynchron versenden. Bei asynchronem Versand werden E-Mails nicht sofort während der Bestellung bzw. "Auslösung" verschickt, sondern im Hintergrund gesammelt und dann per Cron-Job verarbeitet.

Das ist aus Performance-Sicht sinnvoll. z.B. der Checkout soll möglichst schnell bleiben. Niemand möchte, dass ein Kunde im Checkout warten muss, weil gerade ein Mailserver langsam antwortet.

Der Nachteil: Wenn der Hintergrundprozess nicht läuft, bleiben die E-Mails liegen.

Das betrifft besonders typische Sales E-Mails:

• Order Confirmation
• Invoice E-Mail
• Shipment E-Mail
• Credit Memo E-Mail
• interne E-Mail-Kopien
• E-Mails aus Erweiterungen

Für Entscheider ist dabei nicht entscheidend, ob der technische Mechanismus intern als Cron, Queue oder Consumer bezeichnet wird. Entscheidend ist die Wirkung: Der Kunde bekommt keine Nachricht. Das erzeugt Supportaufwand und Vertrauen geht verloren.

Warum der Shop trotzdem erreichbar sein kann

Viele erwarten bei einer falschen PHP-Version einen direkten Totalausfall. Bei Cronproblemen ist das aber nicht zwingend der Fall.

Der Webserver nutzt seine eigene PHP-Konfiguration. Der Cronjob nutzt die PHP-Version, die in der Crontab eingetragen ist.

Das können zwei verschiedene Dinge sein.

Vereinfacht gesagt:

Bereich	Typische Nutzung
Web-PHP	Frontend, Backend, Checkout, Kundenkonto
PHP CLI	Cronjobs, Magento CLI, Indexer, Deploy-Befehle, Wartung
Crontab	zeitgesteuerter Aufruf von Magento Aufgaben

Wenn nur die Crontab falsch ist, kann der Shop nach außen normal wirken. Genau das macht die Fehlersuche schwerer.

Wie der Fehler geprüft wird

Der erste Schritt ist immer die Prüfung der Crontab. Dabei muss die Crontab des richtigen Systembenutzers geprüft werden. Bei Magento ist das meist der Benutzer, dem auch die Magento-Dateien gehören.

Typische Prüfungen sind:

crontab -l

Danach sollte geprüft werden, welche PHP-Versionen auf dem Server vorhanden sind:

which php
php -v
/usr/bin/php8.2 -v
/usr/bin/php8.3 -v
/usr/bin/php8.4 -v

Wenn bei /usr/bin/php8.2 -v bereits ein Fehler erscheint, ist die Ursache sehr wahrscheinlich gefunden.

Auch ein manueller Test des Magento Cronjobs ist sinnvoll:

cd /var/www/magento
/usr/bin/php8.2 bin/magento cron:run

Oder mit der tatsächlich korrekten PHP-Version:

cd /var/www/magento
/usr/bin/php8.3 bin/magento cron:run

Wichtig: Die richtige PHP-Version hängt von der Magento-Version, den installierten Erweiterungen und der Serverumgebung ab. Daher sollte nicht blind irgendein PHP-Pfad eingetragen werden.

Welche Logs helfen bei der Diagnose?

Bei diesem Fehler sind mehrere Logdateien interessant.

Typische Stellen sind Magento-Logs

/var/www/magento/var/log/magento.cron.log
/var/www/magento/var/log/system.log
/var/www/magento/var/log/exception.log

Je nach Server kommen weitere Server-Logs hinzu:

/var/log/syslog
/var/log/cron
/var/log/messages

Auffällige Fehlermeldungen können zum Beispiel sein:

/usr/bin/php8.2: No such file or directory
php8.2: command not found
/bin/sh: 1: /usr/bin/php8.2: not found
Could not open input file: bin/magento
PHP Fatal error

Auch die Datenbanktabelle cron_schedule in Magento (Cron Table) kann Hinweise liefern. Dort sieht man, ob Jobs geplant, ausgeführt, verpasst oder mit Fehler beendet wurden.

Typische Statuswerte sind:

• pending
• running
• success
• missed
• error

Wenn viele Jobs auf missed oder error stehen, sollte der Cronjob genauer geprüft werden.

Was bei der Korrektur beachtet werden sollte

Die naheliegende Lösung ist, die Crontab auf die richtige PHP-Version anzupassen.

Aus:

* * * * * /usr/bin/php8.2 /var/www/magento/bin/magento cron:run 2>&1 | grep -v "Ran jobs by schedule" >> /var/www/magento/var/log/magento.cron.log

kann je nach Server zum Beispiel werden:

* * * * * /usr/bin/php8.3 /var/www/magento/bin/magento cron:run 2>&1 | grep -v "Ran jobs by schedule" >> /var/www/magento/var/log/magento.cron.log

Das ist aber nur dann korrekt, wenn PHP 8.3 zur Magento-Version und zur Serverumgebung passt.

Vor der Änderung sollte geprüft werden:

• Welche Magento-Version läuft?
• Welche PHP-Version wird offiziell unterstützt?
• Welche PHP-Version nutzt der Webserver?
• Welche PHP-Version nutzt die Kommandozeile?
• Unter welchem Benutzer läuft der Cronjob?
• Sind Dateirechte und Pfade korrekt?
• Gibt es mehrere Magento-Installationen auf dem Server?
• Gibt es mehrere Crontabs?

Nach der Änderung sollte der Cronjob nicht einfach vergessen werden. Er sollte aktiv getestet werden.

Eine sinnvolle Prüfsequenz nach der Anpassung

Nach einer Korrektur bietet sich eine kurze Prüfkette an.

1. Crontab kontrollieren
2. PHP-Version über CLI prüfen
3. Magento Cron manuell ausführen
4. Logdateien prüfen
5. cron_schedule kontrollieren
6. Testbestellung bzw. fehlende E-Mail Prozess durchführen
7. Entsprechende E-Mail prüfen
8. Generelle Funktionstest (Mail
9. weitere geplante Magento-Aufgaben beobachten

Erst wenn neue Cronjobs erfolgreich laufen und die E-Mails wieder sauber versendet werden, ist das Problem wirklich behoben.

Welche Folgeschäden entstehen können

Ein defekter Cronjob wirkt auf den ersten Blick wie ein technisches Detail. Für den Shopbetrieb kann er aber sehr praktische Folgen haben.

Mögliche Auswirkungen sind:

• mehr Rückfragen im Kundenservice
• Unsicherheit beim Kunden nach der Bestellung
• manuelle Nacharbeit bei Rechnungen und Versandinformationen
• Verzögerungen bei Preisregeln oder Katalogprozessen
• fehlerhafte oder verspätete Newsletter
• Probleme mit Erweiterungen, die Cronjobs nutzen
• schlechtere interne Kontrolle über Bestellprozesse

Gerade bei B2B-Shops kann das unangenehm werden. Wenn ein Geschäftskunde keine Bestellbestätigung erhält, fragt er nicht immer freundlich nach. Manchmal landet die Anfrage direkt bei Einkauf, Vertrieb oder Geschäftsführung.

Das ist dann der Moment, in dem ein kleiner Cronjob plötzlich sehr groß wirkt.

Warum dieser Fehler in Wartungsroutinen gehört

Nach einer PHP-Umstellung sollte nicht nur der sichtbare Shop geprüft werden. Magento braucht eine technische Nachkontrolle im Hintergrund.

Zu einer sinnvollen Checkliste gehören:

• Frontend prüfen
• Backend prüfen
• Checkout testen
• Zahlungsarten testen
• Versandarten testen
• PHP CLI prüfen
• Magento Cronjobs prüfen
• Logs prüfen
• Indexer prüfen
• Mailversand prüfen
• Queue und Consumer prüfen
• wichtige Erweiterungen prüfen

Der Cronjob ist dabei kein Randthema. Er ist einer der zentralen Taktgeber im Magento-System.

Wann eine Magento-Agentur helfen sollte

Wenn nach einer PHP-Umstellung keine Magento E-Mails mehr versendet werden, sollte die Ursache systematisch eingegrenzt werden. Einfach nur eine andere PHP-Version in die Crontab zu schreiben, kann funktionieren. Es kann aber auch neue Probleme erzeugen.

Sinnvoll ist eine technische Prüfung, wenn:

• der Shop geschäftskritisch ist
• Bestellmails fehlen
• mehrere Cronjobs Fehler zeigen
• unklar ist, welche PHP-Version korrekt ist
• der Server mehrere PHP-Versionen nutzt
• der Shop durch Erweiterungen stark angepasst wurde
• nach einem Hostingwechsel Probleme auftreten
• keine saubere Dokumentation der Serverumgebung vorhanden ist

Bei KonVis prüfen wir solche Fehler im Zusammenspiel aus Magento-Version, PHP CLI, Webserver, Cron, Logs, Queue, Erweiterungen und Mailkonfiguration. Genau dort entstehen in echten Shops die meisten Fehler. Diese entstehen zwischen Update, Server, Modul und Tagesgeschäft.

FAQ zu Magento Mailversand und Cronjob

Warum versendet Magento 2 keine Bestellbestätigung?

Eine häufige Ursache ist ein nicht laufender Cronjob, besonders wenn der asynchrone E-Mail-Versand aktiv ist. Es kommen aber auch SMTP-Probleme, falsche Sales E-Mail Einstellungen, deaktivierte Mailkommunikation oder Fehler in Erweiterungen infrage.

Kann eine Cronjob von einer Minute auf die andere ausfallen?

Leider ja. Insbesondere bei in unseren Augen schlechten Magento-Hostern haben wir es laufend erlebt. Ein Cronjob fällt aus durch z.B. Überlastung de Servers oder ähnliches. Eigentlich kann geprüft werden, ob Cronjobs laufen und automatisch neugestartet werden. Wenn das nicht passiert, kann jedoch ein Cronjob "von selbst" ausfallen mit allen Folgen.

Kann ein Cronjob ohne jegliche Änderungen am Shop ausfallen?

Leider ja vgl. vorherige Antwort. Der Cronjob kann durch andere Faktoren innerhalb des Hostings ausfallen. Wenn dieser dann nicht automatisch neugestartet wird und Hoster-Support informiert wird, kann ein Cronjob unbemerkt und ohne jegliche Änderung am Shop "von selbst" ausfallen.

Kann eine falsche PHP-Version im Cronjob den Mailversand stoppen

Ja. Wenn die Crontab eine PHP-Version aufruft, die nicht mehr existiert oder nicht zur Magento-Installation passt, kann bin/magento cron:run fehlschlagen. Dann werden geplante Aufgaben nicht korrekt verarbeitet.

Warum funktioniert der Shop im Browser trotzdem

Weil Webserver-PHP und PHP CLI getrennt sein können. Der Shop kann im Browser mit einer funktionierenden PHP-Version laufen, während der Cronjob auf der Kommandozeile eine andere PHP-Version nutzt.

Wo steht der Magento Cronjob

Der Cronjob steht in der Crontab des jeweiligen Systembenutzers. Häufig lässt er sich mit crontab -l anzeigen. Wichtig ist, die Crontab des richtigen Benutzers zu prüfen.

Welche Logdatei ist bei Magento Cronproblemen wichtig

Häufig hilfreich sind var/log/magento.cron.log, var/log/system.log und var/log/exception.log. Zusätzlich können Systemlogs des Servers Hinweise liefern.

Ist ein erfolgreicher SMTP-Test ein Beweis, dass Magento Mails versendet

Nein. Ein SMTP-Test zeigt nur, dass der Mailserver grundsätzlich erreichbar sein kann. Wenn Magento die E-Mails wegen eines Cron- oder Queue-Problems nicht verarbeitet, kann der SMTP-Test trotzdem erfolgreich sein.

Was bedeutet cron_schedule in Magento

cron_schedule ist eine Magento-Datenbanktabelle, in der geplante und ausgeführte Cronjobs erfasst werden. Sie hilft bei der Diagnose, wenn Jobs hängen bleiben, verpasst werden oder mit Fehler abbrechen.

Sollte man nach jedem PHP Update den Magento Cronjob prüfen

Ja. Nach einer PHP-Umstellung sollte immer geprüft werden, ob die PHP-Version in der Crontab noch korrekt ist und ob bin/magento cron:run ohne Fehler läuft.

Fazit

Wenn Magento 2 nach einer PHP-Umstellung keine E-Mails mehr versendet, muss nicht automatisch der Mailserver schuld sein. Ein sehr realistischer Auslöser ist ein defekter Cronjob.

Wenn Magento 2 von einer Minute zur anderen keine Mails mehr verschickt, kann es bei (in unseren Augen meist schlechtes Hosting), leider auch passieren.

Besonders verdächtig ist eine Crontab, die noch eine alte PHP-Version aufruft, zum Beispiel /usr/bin/php8.2, obwohl diese Version auf dem Server nicht mehr vorhanden ist oder nicht mehr zur Magento-Installation passt.

Der Shop kann trotzdem erreichbar sein. Genau deshalb wird der Fehler häufig übersehen.

Die Lösung beginnt mit einer sauberen Prüfung von Crontab, PHP CLI, Magento Logs und Cron-Historie. Danach lässt sich der Cronjob gezielt korrigieren und testen oder schlicht neustarten.

Für Shopbetreiber ist die wichtigste Erkenntnis: Nach PHP-Updates reicht ein kurzer Blick ins Frontend nicht aus. Magento arbeitet viel im Hintergrund. Und wenn dieser Hintergrund steht, merkt es oft zuerst der Kunde.

Sie möchten weitere Informationen Magento Betreuung?

Sprechen Sie uns gerne für ein unverbindliches und natürlich kostenlose Gespräch an zur Betreuung Ihres Magent Onlineshops

Weitere Informationen finden Sie auch hier:

Informationen zu Magento Betreuung und Verbesserungen

Informationen zu Programmierung individueller Magento Erweiterungen (Funktionen)

Informationen zu Magento Schnittstellen Programmierung