Geplante Aufgaben (Scheduled Tasks) und Cronjobs in Shopware 6

von Der Atilla | Aug. 3, 2026 | Alle, Shopware 6, Shopware Entwicklung | 0 Kommentare

Cronjobs richtig einrichten, Warteschlangen im Blick behalten, Rückstand rechtzeitig erkennen: Wer einen Shopware-6-Shop produktiv betreibt, kommt am Thema Shopware 6 Scheduled Tasks nicht vorbei. Ob automatische Bestandsprüfungen, Sitemap-Generierung, E-Mail-Versand oder Cleanup-Jobs – all das läuft über das interne Scheduled-Task-System, das ohne funktionierende Cronjob-Konfiguration schlicht stillsteht. In diesem Artikel zeigen wir, wie die Zwei-Cronjob-Architektur aus Bordmitteln korrekt aufgesetzt wird, welche Store-Plugins die Verwaltung erleichtern, und welche Fehlerbilder in der Praxis immer wieder auftauchen. Referenz-Setup ist Shopware 6.7.x (aktuell 6.7.9.0) mit PHP 8.4.

Was auf den ersten Blick nach einer reinen Infrastruktur-Fußnote aussieht, hat in der Praxis oft handfeste Folgen: Bleibt ein Cronjob falsch konfiguriert oder fällt der Consumer-Prozess unbemerkt aus, stapeln sich fällige Aufgaben in der Warteschlange, ohne dass das im Shop-Frontend sofort auffällt. Bestellbestätigungen verzögern sich, Sitemaps veralten, und Aufräum-Jobs bleiben liegen. Wer einmal verstanden hat, wie die beiden Cronjobs zusammenspielen und woran man einen wachsenden Rückstand frühzeitig erkennt, kann solche Situationen in der Regel vermeiden, statt sie erst über Kundenbeschwerden zu bemerken.

Shopware 6 Scheduled Tasks – was steckt dahinter und wie funktioniert das System?
Shopware 6 Scheduled Tasks mit Bordmitteln einrichten (Lösung A)
Shopware 6 Scheduled Tasks per Store-Plugin verwalten (Lösung B)
Shopware 6 Scheduled Tasks: typische Fehlerbilder aus der Praxis
FAQ zu Scheduled Tasks und Cronjobs in Shopware 6
Quellen und weiterführende Links

1. Shopware 6 Scheduled Tasks – was steckt dahinter und wie funktioniert das System?

Scheduled Tasks sind Shopwares eingebauter Mechanismus für wiederkehrende Hintergrundjobs. Jeder Task ist in der Datenbanktabelle scheduled_task hinterlegt, unter anderem mit den Spalten name, run_interval, status, last_execution_time und next_execution_time. Kern-Plugins und -Module registrieren dort ihre eigenen Tasks, etwa für die Sitemap-Generierung oder für Aufräumarbeiten in Log-Tabellen. Auch eigene Plugins können über das Scheduled-Task-System eigene Jobs registrieren – das ist im offiziellen Entwicklerleitfaden dokumentiert.

Damit ein fälliger Task tatsächlich ausgeführt wird, braucht es zwei getrennte Mechanismen:

Etwas, das regelmäßig prüft, ob ein Task laut next_execution_time fällig ist, und ihn bei Fälligkeit in die Message-Queue einreiht.
Einen Worker-Prozess, der die Message-Queue tatsächlich abarbeitet und die eingereihten Jobs ausführt.

Genau diese zwei Rollen übernehmen in der Produktivumgebung zwei unterschiedliche Konsolenbefehle, die häufig verwechselt werden – dazu gleich mehr.

Zurück zur Übersicht

2. Shopware 6 Scheduled Tasks mit Bordmitteln einrichten (Lösung A)

Die Zwei-Cronjob-Standardarchitektur

Für den Produktivbetrieb ist nach wie vor die Zwei-Cronjob-Architektur der empfohlene Weg. Wichtig dabei: Die beiden Befehle haben unterschiedliche Aufgaben und unterschiedliche Flags – hier passieren in der Praxis die meisten Konfigurationsfehler, weil Flags des einen Befehls versehentlich beim anderen verwendet werden.

Der erste Cronjob plant fällige Tasks ein:

*/5 * * * * php bin/console scheduled-task:run --no-wait

scheduled-task:run unterstützt laut aktueller Dokumentation nur das Flag --no-wait (seit 6.5.5.0). Ohne dieses Flag würde der Befehl im Vordergrund auf die nächste Fälligkeit warten und den Cronjob-Prozess blockieren – bei einem 5-Minuten-Intervall ist --no-wait deshalb Pflicht: Der Befehl prüft, plant ein, was fällig ist, und beendet sich sofort wieder.

Der zweite Prozess arbeitet die Message-Queue tatsächlich ab:

php bin/console messenger:consume async low_priority --time-limit=60 --memory-limit=128M

--time-limit und --memory-limit gehören zu messenger:consume, nicht zu scheduled-task:run. Dieser Consumer-Prozess sollte entweder dauerhaft über einen Supervisor-Prozess laufen oder per Cronjob in kurzen Abständen neu angestoßen werden, damit er sich nach Erreichen des Zeit- oder Speicherlimits sauber beendet und neu startet, statt unkontrolliert zu wachsen.

Überlappende Läufe vermeiden

Ein Detail, das in der Praxis gerne übersehen wird: Läuft ein Cronjob-Intervall kürzer als die tatsächliche Ausführungszeit des jeweiligen Befehls, können sich mehrere Instanzen desselben Prozesses überlappen. Bei scheduled-task:run --no-wait ist das dank des Flags unkritisch, weil sich der Befehl sofort wieder beendet. Beim langlaufenden messenger:consume-Prozess sollte dagegen sichergestellt sein, dass der Cronjob, der ihn neu anstößt, nicht startet, während eine vorherige Instanz noch aktiv ist – klassischerweise über einen Lock-Mechanismus auf Betriebssystemebene (etwa flock) oder über einen Supervisor, der den Prozess dauerhaft am Leben hält, statt ihn zyklisch neu zu starten. Welche Variante passt, hängt vom Hosting-Setup ab und ist eine allgemeine Linux-Betriebspraxis, keine Shopware-spezifische Vorgabe.

Admin-Worker deaktivieren

Standardmäßig verarbeitet Shopware die Queue zusätzlich über einen im Admin-Interface laufenden JavaScript-Worker (Admin-Worker) – praktisch für die lokale Entwicklung, in der Produktion aber unzuverlässig, weil er nur läuft, während ein Admin-Tab geöffnet ist. Sobald echte Cronjobs eingerichtet sind, sollte der Admin-Worker deaktiviert werden, in config/packages/shopware.yaml:

shopware:
  admin_worker:
    enable_admin_worker: false

Weitere relevante Nachbar-Keys unter admin_worker:

poll_interval – Standardwert 20 (Sekunden)
memory_limit – Standardwert 128M
transports – Standardwert ["async", "low_priority"]

enable_queue_stats_worker ist als Nachbar-Konfigurationsschlüssel als deprecated markiert (Ablösung in Shopware 6.8 durch shopware.messenger.stats.enabled) – enable_admin_worker selbst ist davon nicht betroffen und bleibt der zentrale Schalter.

Admin-Bereich Einstellungen/System mit der Übersicht der geplanten Aufgaben (Scheduled Tasks) inkl. Status- und Zeitspalten

Neue Debug- und Wartungsbefehle seit 6.7.2.0

Für gezieltes Debugging einzelner Tasks stehen seit Shopware 6.7.2.0 zusätzliche Console-Commands zur Verfügung, die im Alltag oft übersehen werden:

scheduled-task:run-single <name> – führt genau einen benannten Task sofort aus, unabhängig von seiner Fälligkeit.
scheduled-task:schedule <name> – plant einen Task gezielt neu ein.
scheduled-task:deactivate <name> – deaktiviert einen einzelnen Task, ohne den gesamten Scheduler anzufassen.

Über die Dependency-Injection-Konfiguration sind außerdem scheduled-task:list und scheduled-task:register als Commands registriert. Für welche Version diese beiden exakt eingeführt wurden, ist nicht per Changelog verifiziert – vor einem Einsatz in älteren Installationen lohnt sich ein kurzer Test mit bin/console list scheduled-task auf der jeweiligen Zielversion.

Sitemap-Sonderfall

Die Sitemap-Generierung läuft standardmäßig ebenfalls als Scheduled Task – bei größeren Katalogen kann das während Stoßzeiten unerwünschte Last erzeugen. Der eingebaute Sitemap-Task lässt sich gezielt abschalten:

shopware:
  sitemap:
    scheduled_task:
      enabled: false

Stattdessen lässt sich die Sitemap-Generierung über einen eigenen, zeitlich unabhängigen Cronjob in verkehrsarmen Zeiten anstoßen, etwa nachts:

0 3 * * * php bin/console sitemap:generate

Ausblick: Symfony Scheduler (experimentell)

Seit Shopware 6.6 existiert mit messenger:consume scheduler_shopware ein alternativer, auf dem Symfony Scheduler basierender Weg, der den separaten scheduled-task:run-Cronjob ersetzen würde. Der Haken: Dieser Scheduler liest die scheduled_task-Tabelle nur beim Start des Consumer-Prozesses ein – Änderungen an Intervallen greifen also erst nach einem Neustart. Die Dokumentation bezeichnet diesen Weg seit 6.6 als experimentell; ob das für 6.7.9.0 unverändert gilt, ist nicht separat geprüft. Für den Produktivbetrieb bleibt deshalb die Zwei-Cronjob-Architektur der empfohlene Standardweg, der Symfony-Scheduler-Ansatz eher ein Punkt zum Beobachten.

Zurück zur Übersicht

3. Shopware 6 Scheduled Tasks per Store-Plugin verwalten (Lösung B)

Wer die Zeitpunkte einzelner Scheduled Tasks im Admin steuern, den Verarbeitungsstatus überwachen oder bei Fehlern automatisch alarmiert werden will, ohne selbst in der Datenbank zu hantieren, findet im Shopware Store mehrere spezialisierte Plugins. Die folgenden vier wurden am 03.08.2026 direkt auf den jeweiligen Store-Seiten geprüft:

Plugin	Anbieter	SW-6.7-kompatibel	Preis (Stand 03.08.2026)	Fokus
Cron Manager for Shopware 6	brainstation	Ja (6.2.0-RC1 – 6.7.12.2)	35,10 €/Jahr (2,93 €/Monat) oder 3,90 €/Monat bei monatlicher Kündbarkeit	Zeitpunkte von Scheduled Tasks direkt im Admin steuern, ohne DB-Eingriff
Scheduled Task Management	Kraftware	Ja (6.7.0.0 – 6.7.12.2, gezielt für 6.7 gebaut)	39,99 €/Jahr oder 3,99 €/Monat	Timeline-Ansicht mit Logging, Steuerung von Hintergrundprozessen
Scheduled Task Monitoring	GOLLE IT	Ja (praktisch ab 6.6+, Store-Angabe nennt bereits 6.5.0.0)	23,88 €/Jahr (1,92 €/Monat) oder 1,99 €/Monat	Kein Zeitsteuerungs-Tool, sondern E-Mail-Alarm bei fehlgeschlagenen Tasks plus Auto-Restart
Scheduled Tasks and Message Queue Administration	neofonie	Nein (Store nennt nur bis 6.6.0.0, letztes Update 30.01.2024)	kostenlos	Nur als Negativbeispiel bzw. für ältere Installationen relevant

Die drei erstgenannten Plugins decken unterschiedliche Bedürfnisse ab: Cron Manager und Scheduled Task Management richten sich an Shops, die Ausführungszeitpunkte feinjustieren und den Verlauf einsehen wollen. Scheduled Task Monitoring verfolgt einen anderen Ansatz – es greift nicht in die Steuerung ein, sondern schlägt Alarm, sobald ein Task fehlschlägt, und kann betroffene Jobs automatisch neu anstoßen. Das vierte Plugin von neofonie ist laut Store-Angabe nicht mehr für 6.7 freigegeben und seit Anfang 2024 nicht aktualisiert worden – für aktuelle Installationen also eher ein Hinweis darauf, worauf man beim Kompatibilitäts-Check achten sollte, als eine echte Kaufoption.

Ob die genannten Preise brutto oder netto ausgewiesen sind und wofür das Sternchen (*) auf den jeweiligen Store-Seiten steht, wurde nicht verifiziert – das sollte vor einem tatsächlichen Kauf im Checkout-Flow gegengeprüft werden.
Bewertungszahlen auf den Store-Seiten können sich bis zur Veröffentlichung dieses Artikels noch ändern und sollten bei Bedarf aktuell nachgeschlagen werden.

Zurück zur Übersicht

4. Shopware 6 Scheduled Tasks: typische Fehlerbilder aus der Praxis

Auch mit korrekt eingerichteten Cronjobs häufen sich in Forum und GitHub Issues, die zeigen, wo es in der Praxis hakt. Eine Auswahl belegter Fälle:

„MySQL server has gone away“ bei Cronjob-Umstellung: Ein Nutzer verlagerte auf Shopware 6.7.8.2 scheduled-task:run und messenger:consume in Cronjobs und bekam danach Datenbankverbindungsabbrüche – die Queue lag zeitweise 148 Minuten zurück, einzelne Tasks waren 35 Minuten überfällig. Ein Teil-Fix bestand darin, max_allowed_packet = 1G in der my.cnf zu setzen; laut Diskussion war das aber nur eine partielle Lösung, keine vollständige (Forum, 26.03.2026).
„Scheduled tasks overdue“ mit fast zwölf Stunden Rückstand: In einem anderen Thread wurde ein Rückstand von 11.854 Minuten diskutiert. Als mögliche Ursachen wurden genannt: ein deaktivierter Admin-Worker ohne tatsächlich aktive Cronjobs, fehlgeschlagene Tasks, die Folge-Ausführungen blockieren, sowie hängende Nachrichten in der Dead-Letter-Queue. Als Werkzeug zum Zurücksetzen des Messengers wurde in der Diskussion das Frosh-Tools-Plugin empfohlen (Forum, Februar 2025).
Fehlender Cleanup für die notification-Tabelle: Anders als bei Logs, Webhooks oder der Versionierung existiert für die notification-Tabelle bislang kein automatischer Cleanup-Task – die Tabelle wächst unbegrenzt. Das zugehörige GitHub-Issue #13369 ist zum Zeitpunkt der Recherche noch offen, ohne Maintainer-Feedback (erstellt 06.11.2025).
Neue Telemetrie-Metriken zur Früherkennung: Mit scheduled_task.backlog.max_lateness_seconds und scheduled_task.failed.count wurden zwei Metriken eingeführt, mit denen sich der Zustand des Schedulers unabhängig von der reinen Queue-Tiefe beobachten lässt – nützlich, um einen wachsenden Rückstand zu erkennen, bevor er zum „overdue“-Alarm wird (GitHub-Issue #18162, geschlossen 27.07.2026).

Für die Praxis heißt das: Ein Blick allein auf „läuft der Cronjob“ reicht nicht. Wer regelmäßig next_execution_time und last_execution_time in der scheduled_task-Tabelle prüft oder die genannten Metriken überwacht, erkennt einen wachsenden Rückstand deutlich früher als über eine reine Fehlermeldung im Frontend.

Rückstand ohne Plugin prüfen

Wer keines der oben genannten Store-Plugins einsetzen möchte, kann sich mit einer einfachen Abfrage direkt auf der scheduled_task-Tabelle einen schnellen Überblick verschaffen, welche Tasks überfällig sind:

SELECT name, status, run_interval, last_execution_time, next_execution_time
FROM scheduled_task
WHERE next_execution_time < NOW()
ORDER BY next_execution_time ASC;

Tauchen hier regelmäßig Zeilen mit einem next_execution_time auf, der deutlich in der Vergangenheit liegt, ist das ein Indiz dafür, dass entweder der einplanende Cronjob (scheduled-task:run) oder der abarbeitende Consumer-Prozess (messenger:consume) nicht wie erwartet läuft. Eine solche Abfrage lässt sich problemlos in ein eigenes Monitoring-Skript oder einen Uptime-Check einbauen, unabhängig davon, ob zusätzlich ein Store-Plugin im Einsatz ist.

Checkliste für die Produktivsetzung

Beide Cronjobs (scheduled-task:run --no-wait und messenger:consume) sind im System-Crontab oder über einen Supervisor eingerichtet und laufen nachweislich.
enable_admin_worker ist auf false gesetzt, sobald die Cronjobs zuverlässig laufen.
Der Consumer-Prozess besitzt sinnvolle --time-limit– und --memory-limit-Werte, die zum Hosting-Setup passen.
Es gibt einen Mechanismus, der überlappende messenger:consume-Läufe verhindert (Lock oder Supervisor statt reinem Cronjob-Neustart).
Die Sitemap-Generierung läuft, falls gewünscht, zeitlich unabhängig in einem eigenen, verkehrsarmen Zeitfenster.
Es existiert ein Monitoring – per Store-Plugin, eigener SQL-Abfrage oder den Telemetrie-Metriken –, das einen wachsenden Rückstand meldet, bevor er zum sichtbaren Problem wird.

Zurück zur Übersicht

FAQ zu Scheduled Tasks und Cronjobs in Shopware 6

Wie oft sollte der Cronjob für scheduled-task:run laufen?

Ein Intervall von fünf Minuten (*/5 * * * *) ist die gängige Praxis und deckt die meisten Standard-Tasks ab, ohne unnötige Systemlast zu erzeugen.

Reicht scheduled-task:run allein, oder brauche ich zusätzlich messenger:consume?

Beide werden benötigt. scheduled-task:run --no-wait plant fällige Tasks lediglich in die Queue ein, ausgeführt werden sie erst durch einen laufenden messenger:consume-Prozess.

Muss ich den Admin-Worker manuell abschalten, wenn ich Cronjobs einrichte?

Ja, empfehlenswert ist es. enable_admin_worker steht standardmäßig auf true und sollte in config/packages/shopware.yaml auf false gesetzt werden, sobald echte Cronjobs die Verarbeitung übernehmen.

Was tun bei der Meldung „Scheduled tasks overdue“?

Laut Forum-Diskussionen liegt die Ursache häufig in einem deaktivierten Admin-Worker ohne funktionierende Cronjobs, in fehlgeschlagenen Tasks, die Folge-Ausführungen blockieren, oder in hängenden Dead-Letter-Queue-Nachrichten. Ein Reset der Message-Queue kann helfen, ist aber im Einzelfall zu prüfen.

Ist der Symfony-Scheduler-Weg (scheduler_shopware) schon eine Alternative zu scheduled-task:run?

Für den Produktivbetrieb noch nicht uneingeschränkt: Die Dokumentation bezeichnet ihn seit Version 6.6 als experimentell, und Intervalländerungen erfordern einen Neustart des Consumer-Prozesses, da die Tabelle nur beim Start gelesen wird.

Wie erkenne ich einen Rückstand, ohne ein Store-Plugin zu installieren?

Über eine direkte Abfrage auf die scheduled_task-Tabelle, die nach Tasks mit überfälligem next_execution_time filtert (siehe Abschnitt „Rückstand ohne Plugin prüfen“), oder über die Telemetrie-Metriken scheduled_task.backlog.max_lateness_seconds und scheduled_task.failed.count, sofern diese im eigenen Monitoring-Stack ausgewertet werden.

Zurück zur Übersicht