Shopware Problemlösung

Shopware Scheduled Tasks funktionieren nicht

Wiederkehrende Shopware-Aufgaben werden nicht oder nur verspätet ausgeführt, obwohl sie in der Aufgabenliste vorhanden sind. Diese Anleitung zeigt, wie Status, letzte und nächste Ausführung, Cronjob, PHP-Pfad, Arbeitsverzeichnis, Message Queue, Berechtigungen und Logdateien systematisch geprüft werden.

Shopware 6 Scheduled Tasks und Cronjobs Bearbeitungszeit: etwa 20 bis 60 Minuten
Fehlerbild

Geplante Aufgaben bleiben überfällig, werden übersprungen oder laufen nur bei geöffnetem Administrationsbereich.

Häufige Ursache

Der Scheduled-Task-Runner, die Message Queue oder der zugehörige Cronjob wird nicht zuverlässig ausgeführt.

Wichtig

Scheduled Tasks planen Aufgaben ein. Die Message Queue muss diese anschließend tatsächlich abarbeiten.

Inhaltsverzeichnis

  1. Bedeutung der Scheduled Tasks
  2. Fehlerbild eingrenzen
  3. Statusliste aufrufen
  4. Statusangaben verstehen
  5. Manuellen Test durchführen
  6. Message Queue prüfen
  7. Cronjob kontrollieren
  8. PHP-Pfad und Verzeichnis prüfen
  9. Berechtigungen und Limits prüfen
  10. Parallele Aufrufe vermeiden
  11. Logs auswerten
  12. Dauerhaften Betrieb einrichten
  13. Abschlusskontrolle

1. Was Shopware Scheduled Tasks ausführen

Scheduled Tasks sind wiederkehrende Hintergrundaufgaben in Shopware 6. Erweiterungen und Shopware selbst registrieren Aufgaben mit einem festen Ausführungsintervall. Dazu können beispielsweise Aufräumarbeiten, Indexierungen, Sitemap-Aktualisierungen, Datenimporte oder Aufgaben von Plugins gehören.

Der Befehl scheduled-task:run prüft, welche Aufgaben fällig sind, und übergibt sie zur weiteren Verarbeitung. Viele dieser Aufgaben werden nicht vollständig im Scheduled-Task-Prozess selbst ausgeführt, sondern als Nachrichten in die Message Queue gestellt.

Scheduled Tasks und Message Queue sind zwei Prozesse

Ein funktionierender Scheduled-Task-Runner allein reicht nicht aus. Werden die erzeugten Nachrichten nicht durch einen Queue-Worker verarbeitet, bleiben die eigentlichen Arbeiten trotzdem liegen.

Prozess Aufgabe Typischer CLI-Befehl
Scheduled Tasks Fällige wiederkehrende Aufgaben erkennen und einplanen scheduled-task:run
Message Queue Asynchrone Nachrichten und eingeplante Aufgaben abarbeiten messenger:consume
Cronjob oder Dienst Beide CLI-Prozesse regelmäßig oder dauerhaft starten Server- beziehungsweise Hosting-Konfiguration

2. Fehlerbild zuerst eingrenzen

Vor Änderungen an Cronjobs oder Serverkonfiguration muss festgestellt werden, welche Aufgaben betroffen sind und seit wann die Verarbeitung ausbleibt.

  • Sind alle Scheduled Tasks betroffen oder nur einzelne?
  • Liegt die letzte Ausführung deutlich in der Vergangenheit?
  • Ist die nächste Ausführung bereits überfällig?
  • Bleiben Aufgaben dauerhaft im Status „running“ oder „queued“?
  • Zeigen mehrere Aufgaben den Status „skipped“?
  • Funktioniert die Verarbeitung nur bei geöffneter Administration?
  • Trat der Fehler nach einem Update, Plugin-Wechsel oder Serverumzug auf?
  • Wurde der PHP-Pfad oder das Shopware-Verzeichnis geändert?
Nicht sofort Datenbankeinträge ändern

Die Tabelle der Scheduled Tasks enthält Status- und Zeitwerte. Eine direkte Änderung kann Sperren und tatsächliche Ursachen verdecken. Zuerst CLI-Ausgabe, Cronjob und Logs prüfen.

3. Scheduled-Task-Status mit der CLI anzeigen

Wechseln Sie zuerst in das Hauptverzeichnis der Shopware-Installation. Dort befinden sich unter anderem die Verzeichnisse bin, config, public und var.

1

In das Shopware-Verzeichnis wechseln

Shell 
cd /pfad/zum/shopware-verzeichnis
2

Liste der Scheduled Tasks anzeigen

Shopware CLI 
bin/console scheduled-task:list

Mit festem PHP-Pfad:

Shopware CLI mit PHP-Pfad 
/usr/bin/php bin/console scheduled-task:list

Die Ausgabe enthält je nach Shopware-Version unter anderem den Namen, die nächste Ausführung, die letzte Ausführung, das Intervall und den aktuellen Status.

Beispielhafte Ausgabe 
+---------------------------+---------------------------+---------------------------+--------------+-----------+
| Name                      | Next execution            | Last execution            | Run interval | Status    |
+---------------------------+---------------------------+---------------------------+--------------+-----------+
| log_entry.cleanup         | 2026-07-29T22:10:00+00:00 | 2026-07-28T22:10:03+00:00 | 86400        | scheduled |
| shopware.invalidate_cache | 2026-07-29T21:55:00+00:00 | 2026-07-29T21:53:01+00:00 | 120          | scheduled |
+---------------------------+---------------------------+---------------------------+--------------+-----------+
Zeitangaben beachten

Die CLI-Ausgabe kann UTC-Zeit anzeigen, während Server, Shopware und Administration eine andere Zeitzone verwenden. Entscheidend ist, ob die Abstände zum hinterlegten Intervall plausibel sind.

4. Status, letzte und nächste Ausführung verstehen

Status oder Feld Bedeutung Prüfung
scheduled Die Aufgabe ist registriert und für eine kommende beziehungsweise fällige Ausführung vorgesehen. Nächste und letzte Ausführung mit dem Intervall vergleichen.
running Die Aufgabe wurde zur Verarbeitung übernommen. Kurzzeitig ist dieser Status normal. Bleibt er dauerhaft bestehen, Logs und laufende Prozesse prüfen.
queued Die Aufgabe wurde eingeplant und wartet auf die weitere Verarbeitung. Message Queue und Queue-Worker kontrollieren.
skipped Die Aufgabe wurde bei einer Ausführung nicht erneut gestartet, beispielsweise wegen einer bestehenden Verarbeitung oder Sperre. Parallele Runner, Laufzeit und vorherige Fehler prüfen.
Last execution Zeitpunkt der letzten registrierten Ausführung. Darf nicht über mehrere erwartete Intervalle unverändert bleiben.
Next execution Berechneter Zeitpunkt der nächsten fälligen Ausführung. Liegt er lange in der Vergangenheit, läuft der Runner nicht korrekt.
Run interval Ausführungsabstand in Sekunden. Mit letzter und nächster Ausführung abgleichen.
Statusbezeichnungen können abweichen

Umfang und Darstellung der Statusausgabe können sich zwischen Shopware-Versionen und Erweiterungen unterscheiden. Entscheidend sind dauerhaft überfällige Zeitpunkte, wiederkehrende Fehler und eine ausbleibende fachliche Verarbeitung.

5. Scheduled Tasks manuell testen

Mit einem begrenzten Testlauf lässt sich feststellen, ob der Scheduled-Task-Runner grundsätzlich startet und ob unmittelbar ein Fehler ausgegeben wird.

Shopware CLI 
bin/console scheduled-task:run --time-limit=60

Mit festem PHP-Pfad:

Shopware CLI mit PHP-Pfad 
/usr/bin/php bin/console scheduled-task:run --time-limit=60

Der Parameter --time-limit=60 beendet den Prozess nach ungefähr 60 Sekunden. Das ist bei diesem Test beabsichtigt und kein Fehler.

Nach dem Test erneut die Liste prüfen

Shopware CLI 
bin/console scheduled-task:list
  • Hat sich die letzte Ausführung eines fälligen Tasks geändert?
  • Wurde die nächste Ausführung neu berechnet?
  • Erscheint eine Exception direkt in der Konsole?
  • Wurden Nachrichten an die Message Queue übergeben?
  • Funktioniert die zugehörige Aufgabe nach Verarbeitung der Queue?
Manueller Lauf funktioniert

Ändern sich die Zeitwerte nach dem manuellen Aufruf, liegt die Ursache meistens nicht bei der Registrierung der Tasks, sondern beim automatischen Start durch Cronjob, Dienst oder Hosting.

6. Message Queue anschließend prüfen

Scheduled Tasks und Queue-Worker müssen gemeinsam funktionieren. Nach dem manuellen Scheduled-Task-Lauf sollte deshalb auch die Message Queue testweise abgearbeitet werden.

Shopware 6.5 und neuer

Shopware CLI 
bin/console messenger:consume async low_priority --time-limit=60
Shopware CLI mit PHP-Pfad 
/usr/bin/php bin/console messenger:consume async low_priority --time-limit=60

Ältere Shopware-Versionen vor 6.5

Älterer Receiver 
bin/console messenger:consume default --time-limit=60
Receiver nicht vermischen

Der ältere Receiver default ist für aktuelle Shopware-Versionen nicht die richtige Vorgabe. Vorhandene Cronjobs nach einem Update auf Shopware 6.5 oder neuer entsprechend kontrollieren.

Bleiben Aufgaben im Status „queued“ oder zeigt sich die fachliche Wirkung erst nach diesem manuellen Queue-Aufruf, muss der dauerhafte Queue-Worker korrigiert werden.

Eine ausführliche Diagnose folgt auf der geplanten Wissensseite Shopware Message Queue hängt.

7. Automatischen Cronjob kontrollieren

Funktioniert der manuelle CLI-Aufruf, aber die Zeitwerte bleiben später wieder stehen, wird der automatische Aufruf nicht zuverlässig gestartet.

Vorhandene Cronjobs des aktuellen Benutzers anzeigen

Shell 
crontab -l

Bei Hosting-Oberflächen werden Cronjobs häufig nicht über crontab, sondern im Kundenmenü verwaltet. Dort müssen Befehl, Intervall, PHP-Version, Arbeitsverzeichnis und Fehlerausgabe geprüft werden.

Testweise Ausgabe in eine Logdatei schreiben

Cronjob-Diagnose 
* * * * * cd /pfad/zum/shopware-verzeichnis && /usr/bin/php bin/console scheduled-task:run --time-limit=55 >> /pfad/zum/shopware-verzeichnis/var/log/scheduled-task-cron.log 2>&1
Pfade zwingend anpassen

/usr/bin/php und /pfad/zum/shopware-verzeichnis sind Beispiele. Falsche Pfade führen dazu, dass der Cronjob zwar angelegt ist, den Shopware-Befehl aber nicht ausführt.

Diagnose-Log kontrollieren

Shell 
tail -n 200 var/log/scheduled-task-cron.log

8. PHP-Pfad und Arbeitsverzeichnis prüfen

Verwendeten PHP-Pfad anzeigen

Shell 
which php

CLI-PHP-Version kontrollieren

Shell 
/usr/bin/php -v

Die PHP-Version der Kommandozeile kann von der PHP-Version des Webservers abweichen. Der Cronjob muss eine mit der installierten Shopware-Version kompatible CLI-PHP-Version verwenden.

Shopware-Verzeichnis prüfen

Shell 
pwd
ls -lah
test -f bin/console && echo "bin/console gefunden"

Shopware-Konsole mit absolutem Pfad testen

Shell 
/usr/bin/php /pfad/zum/shopware-verzeichnis/bin/console scheduled-task:list
Absoluter Pfad vermeidet typische Cronfehler

Cronjobs besitzen oft eine reduzierte Umgebung und starten nicht im Shopware-Verzeichnis. Ein explizites cd oder ein absoluter Pfad zur Datei bin/console verhindert diese Fehlerklasse.

9. Benutzer, Berechtigungen und Zeitlimits prüfen

Der Cronjob sollte möglichst unter demselben Systembenutzer laufen, der auch für die Shopware-Dateien und regulären CLI-Arbeiten vorgesehen ist. Unterschiedliche Benutzer können Schreibrechte und Dateibesitz im Verzeichnis var verändern.

Aktuellen Benutzer anzeigen

Shell 
whoami

Rechte wichtiger Verzeichnisse prüfen

Shell 
ls -ld var var/cache var/log public
  • Der Cronjob-Benutzer kann in var/cache schreiben.
  • Der Cronjob-Benutzer kann in var/log schreiben.
  • PHP-CLI besitzt die notwendigen Erweiterungen.
  • Das Hosting beendet Prozesse nicht vorzeitig.
  • Speicherlimit und maximale Laufzeit sind ausreichend.
  • Es besteht genügend freier Speicherplatz.

Freien Speicherplatz prüfen

Shell 
df -h
Keine pauschalen chmod-Befehle verwenden

Rechte und Eigentümer hängen vom Hosting ab. Globale Schreibrechte wie chmod -R 777 sind keine geeignete Fehlerbehebung und verschlechtern die Sicherheit.

10. Mehrere parallele Aufrufe vermeiden

Werden Scheduled Tasks gleichzeitig über Admin Worker, mehrere Cronjobs und zusätzliche Dienste gestartet, können sich Prozesse überschneiden. Das führt zu unnötiger Serverlast, Sperren oder übersprungenen Ausführungen.

  • Nur einen vorgesehenen Scheduled-Task-Mechanismus verwenden.
  • Doppelte Cronjob-Einträge entfernen.
  • Hosting-Cronjob und System-Crontab gemeinsam prüfen.
  • Vorhandene Supervisor- oder systemd-Dienste berücksichtigen.
  • Admin Worker nicht zusätzlich als Produktionslösung einplanen.
  • Laufzeit kürzer als das Neustartintervall konfigurieren.

Laufende Shopware-Prozesse anzeigen

Shell 
ps aux | grep -E "scheduled-task:run|messenger:consume" | grep -v grep
Admin Worker richtig einordnen

Die Verarbeitung über die geöffnete Shopware-Administration ist für einen zuverlässigen Produktionsbetrieb nicht geeignet. Server-seitige CLI-Worker laufen unabhängig davon, ob ein Benutzer im Backend angemeldet ist.

11. Shopware-, Cron- und Server-Logs auswerten

Vorhandene Shopware-Logs anzeigen

Shell 
ls -lah var/log/

Aktuelle Produktionseinträge prüfen

Shell 
tail -n 200 var/log/prod-*.log

Nach passenden Fehlerbegriffen suchen

Shell 
grep -RiE "scheduled|messenger|queue|exception|error|lock|timeout|memory" var/log/ | tail -n 200
Fehlerhinweis Mögliche Ursache
Could not open input file: bin/console Falsches Arbeitsverzeichnis oder falscher Pfad
Permission denied Falscher Benutzer oder fehlende Datei- und Verzeichnisrechte
Allowed memory size exhausted PHP-Speicherlimit für die Aufgabe zu niedrig
Maximum execution time exceeded Prozess wird durch ein Zeitlimit beendet
Lock- oder bereits laufender Prozess Paralleler Aufruf oder nicht sauber beendete vorherige Verarbeitung
Transport- oder Messenger-Exception Fehler in der Message Queue oder bei einer konkreten Nachricht
Class, Service oder Handler nicht gefunden Fehlerhafte oder inkompatible Erweiterung
Fehler einer einzelnen Erweiterung

Bricht ein bestimmter Plugin-Task wiederholt ab, zuerst Plugin-Version, Shopware-Kompatibilität und zugehörige Logs prüfen. Das Plugin nicht pauschal im produktiven Shop deaktivieren, bevor Auswirkungen und Wiederherstellungsweg geklärt sind.

12. Scheduled Tasks dauerhaft ausführen

Für kleinere und mittlere Installationen kann ein regelmäßig gestarteter Cronjob ausreichen. Bei größeren Shops sind überwachte, dauerhaft laufende Prozesse über Supervisor, systemd oder die Infrastruktur des Hosters meist stabiler.

Beispiel für einen Scheduled-Task-Cronjob

Cronjob-Beispiel 
* * * * * cd /pfad/zum/shopware-verzeichnis && /usr/bin/php bin/console scheduled-task:run --time-limit=55 >> /dev/null 2>&1

Queue-Worker für Shopware 6.5 und neuer

Cronjob-Beispiel 
* * * * * cd /pfad/zum/shopware-verzeichnis && /usr/bin/php bin/console messenger:consume async low_priority --time-limit=55 --memory-limit=512M >> /dev/null 2>&1
Beispielwerte an das Hosting anpassen

PHP-Pfad, Shopware-Verzeichnis, Speicherlimit, Laufzeit und Ausführungsintervall sind installationsabhängig. Manche Hoster erlauben Cronjobs nur alle fünf Minuten oder stellen eigene Worker bereit.

Admin Worker nur bewusst deaktivieren

Wird die Verarbeitung vollständig auf serverseitige CLI-Worker umgestellt, kann der Admin Worker in einer updatesicheren Shopware-Konfigurationsdatei deaktiviert werden. Diese Umstellung erst durchführen, wenn Scheduled Tasks und Message Queue auf dem Server nachweislich funktionieren.

config/packages/z-shopware.yaml 
shopware:
    admin_worker:
        enable_admin_worker: false
Nicht vor erfolgreichem Servertest deaktivieren

Wird der Admin Worker abgeschaltet, ohne dass CLI-Worker zuverlässig laufen, werden Hintergrundaufgaben nicht mehr über die Administration aufgefangen.

13. Abschlusskontrolle

  • scheduled-task:list lässt sich ohne Fehler ausführen.
  • Fällige Tasks erhalten nach dem Testlauf neue Zeitwerte.
  • Die nächste Ausführung liegt plausibel in der Zukunft.
  • Tasks bleiben nicht dauerhaft auf „running“ oder „queued“ stehen.
  • Der Queue-Worker verarbeitet die eingeplanten Nachrichten.
  • Der automatische Cronjob verwendet den richtigen PHP-Pfad.
  • Der Cronjob startet im richtigen Shopware-Verzeichnis.
  • Keine doppelten Cronjobs oder parallelen Dienste sind aktiv.
  • Der ausführende Benutzer besitzt passende Schreibrechte.
  • Shopware- und Cron-Logs enthalten keine neue Exception.
  • Die fachliche Aufgabe wird ohne geöffnetes Backend ausgeführt.
  • Die Verarbeitung bleibt auch nach mehreren Intervallen stabil.
Dauerhafte Funktion bestätigt

Die Störung ist erst behoben, wenn Scheduled Tasks und Message Queue über mehrere Intervalle automatisch laufen und die zugehörigen Funktionen ohne manuellen CLI-Aufruf ausgeführt werden.

Häufige Fragen

Was bedeutet der Status „scheduled“?

Der Task ist registriert und für eine Ausführung vorgesehen. Ob alles funktioniert, zeigt der Vergleich von letzter Ausführung, nächster Ausführung und hinterlegtem Intervall.

Warum bleibt ein Task dauerhaft auf „running“?

Mögliche Ursachen sind ein abgebrochener Prozess, eine lange laufende Aufgabe, eine Sperre oder ein Fehler im zuständigen Handler. Laufende Prozesse und Logs müssen gemeinsam geprüft werden.

Was bedeutet „skipped“ bei einem Scheduled Task?

Die Aufgabe wurde bei diesem Durchlauf nicht erneut gestartet. Das kann bei einer bestehenden oder überlappenden Verarbeitung auftreten. Wiederholt sich der Status, müssen Laufzeit, Sperren und parallele Aufrufe geprüft werden.

Warum reicht scheduled-task:run allein nicht aus?

Der Runner plant fällige Aufgaben ein. Viele Aufgaben werden danach asynchron über die Message Queue verarbeitet. Ohne Queue-Worker bleibt die eigentliche Ausführung aus.

Warum funktionieren Tasks nur bei geöffneter Administration?

Dann übernimmt wahrscheinlich der Admin Worker die Verarbeitung, während kein zuverlässiger serverseitiger CLI-Worker eingerichtet ist. Für den Produktionsbetrieb sollten die Prozesse unabhängig vom Backend laufen.

Welcher Message-Queue-Befehl gilt ab Shopware 6.5?

Für Shopware 6.5 und neuer werden die Receiver async low_priority verwendet. Der ältere Receiver default gehört zu früheren Versionen.

Wie oft sollte der Scheduled-Task-Runner gestartet werden?

Das Intervall muss zu den registrierten Aufgaben und zum Hosting passen. Häufig wird ein minütlicher Start mit begrenzter Laufzeit verwendet. Bei anderen Hosting-Vorgaben kann ein anderes Intervall erforderlich sein.

Verwandte Shopware-Anleitungen

Shopware-Bestellmails werden nicht versendet Mailer, Flow Builder, Message Queue und Zahlungsarten systematisch prüfen. Shopware Message Queue hängt Wartende Nachrichten, Receiver und Queue-Worker untersuchen. Shopware Cronjobs prüfen PHP-Pfad, Arbeitsverzeichnis, Zeitplan und Fehlerausgabe kontrollieren. Technischer Shopware Support Unterstützung bei fehlerhaften Hintergrundprozessen und Serveraufgaben.

Scheduled Tasks laufen weiterhin nicht zuverlässig?

Ich prüfe Scheduled Tasks, Message Queue, Cronjobs, PHP-Pfade, Berechtigungen und Server-Logs direkt in der bestehenden Shopware-Installation.

Technische Prüfung anfragen
Stand: Juli 2026 · Hinweise gelten für selbst gehostete Shopware-6-Installationen. Verfügbare Befehle, Receiver und Statusbezeichnungen können je nach Shopware-Version, Erweiterung und Hosting abweichen.