JTL-Shop Cron-Jobs verwalten: Volle Kontrolle mit Resources & Health

„Läuft mein Cron-Job eigentlich wirklich?" – diese Frage hat sich vermutlich jeder JTL-Shopbetreiber schon mal gestellt. Im Standard-Backend siehst Du, welche Jobs angelegt sind, vielleicht noch eine Frequenz, einen geplanten nächsten Start. Aber ob der Job tatsächlich sauber durchgelaufen ist? Eher Bauchgefühl als Gewissheit. Und wenn was schiefläuft, merkst Du es oft erst dann, wenn es zu spät ist oder Google Deine Produkte schon aus dem Merchant Center entfernt hat.

In diesem Beitrag erfährst Du, wie das Cron-System im JTL-Shop tickt, wofür Du es brauchst, welche typischen Stolpersteine es gibt – und wie Du Deine JTL-Cron-Jobs zuverlässig verwalten kannst.

Cron-Jobs im JTL-Shop sind kleine Hintergrundprozesse, die automatisch wiederkehrende Aufgaben erledigen – ohne dass Du sie aktiv anstoßen musst. Sie laufen still vor sich hin und kümmern sich um Dinge wie das Berechnen Deiner Bestseller, die DSGVO-konforme Anonymisierung alter Kundendaten oder den zeitversetzten Versand von Mails.

Auch viele Plugins greifen auf Cron-Jobs zurück. Unser eigenes DZM Reloadify-Plugin zum Beispiel synchronisiert über Cron-Jobs regelmäßig Produkte, Bestellungen und abgebrochene Warenkörbe mit dem Newsletter-Tool. Oder das klassische Google-Export-Plugin: Hier erzeugt ein Cron-Job in festen Abständen die Produktfeed-Datei, die das Google Merchant Center anschließend abruft. Ohne den Job keine aktuelle Datei – und ohne aktuelle Datei keine frischen Produktdaten bei Google Shopping.

Im Backend findest Du alle Cron-Jobs unter Administration > System > Cron. Dort siehst Du eine Übersicht aller angelegten Jobs, kannst neue hinzufügen und einzelne Einträge konfigurieren – also Frequenz und Startzeit festlegen.

Klingt nach einer soliden Mechanik. Aber was passiert eigentlich, wenn so ein Job mal nicht durchläuft?

Die JTL-Standard-Verwaltung zeigt Dir, welche Jobs angelegt sind, einen einfachen Status und ein paar Aktionen. Das ist solide, aber im Detail bleibt einiges im Dunkeln. Hier die typischen Stolpersteine, die im Tagesgeschäft am meisten Ärger machen.

Cron-Jobs sind im JTL-Shop zwar zeitlich terminiert, ausgelöst werden sie aber nicht durch einen echten Scheduler, sondern durch Aufrufe in Deinem Shop. Im Standard wird der Cron-Job-Handler alle 10 Seitenaufrufe getriggert, prüft die Queue und arbeitet anstehende Jobs ab. Solange viel los ist im Shop, läuft alles. Sobald die Besucherzahlen runtergehen – nachts, am Wochenende, in der Sommerflaute – werden Jobs verzögert oder im schlimmsten Fall gar nicht ausgeführt. Umgekehrt kann diese Mechanik bei Bot-Wellen für unnötig hohen Server-Traffic sorgen, weil bei jedem zehnten Aufruf der Handler anrollt.

Ein Zombie-Cron-Job ist ein Job, der laut Datenbank als laufend markiert ist, dessen Prozess aber nicht mehr aktiv ist. Das passiert zum Beispiel, wenn ein Job mitten in der Ausführung abbricht und das Lockfile nicht sauber freigegeben wird. Die Queue denkt: „Der läuft ja noch" – und blockiert ihn dauerhaft. Der JTL-Standard zeigt zwar einen „Läuft aktuell"-Status, erkennt Zombies aber nicht als solche. Du wunderst Dich nur, warum der Job nie wieder anspringt.

Im Standard siehst Du den letzten Start, den nächsten geplanten Start und den aktuellen Status. Aber was passiert während der Ausführung? Wenn ein Job mitten im Lauf einen Fehler wirft, das Memory-Limit sprengt oder unsauber endet, bekommst Du im Backend keinen direkten Hinweis. Du müsstest in die JTL-Logs einsteigen – die in vielen Setups gar nicht so umfangreich konfiguriert sind. Was Dir bleibt: hoffen. Im E-Commerce keine besonders solide Strategie.

Steht Dein Shop im Wartungsmodus, laufen die Cron-Jobs nicht. Klingt logisch, vergisst man aber nach Wartungsarbeiten gerne mal. Und auch nach JTL- oder Plugin-Updates haken Cron-Jobs immer wieder. Im JTL-Forum ist das ein Dauerthema – mit dem unangenehmen Beigeschmack, dass Du es oft erst Tage später bemerkst.

Genau hier kommt unser kostenloses Plugin DZM Resources & Health ins Spiel. Es ist in wenigen Minuten installiert und bringt Dir genau die Transparenz und Eingriffsmöglichkeiten, die der Standard nicht liefert. Es ersetzt den JTL-Standard nicht, sondern legt sich als Cockpit darüber.

Anders als im Standard hast Du nicht nur „Schnellstmöglich starten" oder ein einzelnes Reset, sondern fünf granulare Aktionen pro Job:

1. Sofort ausführen – umgeht die JTL-Queue komplett und führt den Job direkt aus
   
   
2. ASAP setzen – läuft mit dem nächsten regulären Queue-Durchlauf
   
   
3. Soft Reset – setzt den Status zurück (perfekt bei Zombies). Der Eintrag bleibt in der Queue und muss nicht neu getriggert werden
   
   
4. Hard Reset – entfernt den Eintrag aus der Queue. Der Cron-Job bleibt erhalten und kommt beim nächsten Trigger normal wieder rein
   
   
5. Komplett löschen – löscht den Cron-Job inklusive aller zugehörigen Queue-Einträge unwiderruflich. Muss bei Bedarf neu eingerichtet werden

Die Unterscheidung zwischen Soft- und Hard-Reset ist im Alltag echtes Gold wert: Soft Reset reicht meist, um einen Zombie wieder gangbar zu machen, Hard Reset nutzt Du, wenn die Queue grundlegend bereinigt werden soll.

Das vielleicht stärkste Feature: Live-Logs. Wenn ein Job klemmt oder Du einfach nachschauen willst, was bei der Ausführung wirklich passiert, kannst Du den Durchlauf direkt live beobachten und Errors in Echtzeit erkennen. Damit ist Schluss mit dem Stochern in JTL-Standard-Logs. Voraussetzung dafür: Die Error Logs sind in der JTL-Config aktiviert.

Kurz gesagt: DZM Resources & Health ist ein kostenloses JTL-Shop-Plugin, das ab Version 1.10.7 einen vollständigen Cron-Job-Manager bietet – inklusive Zombie-Erkennung, Live-Logs und granularer Aktionen. Kombiniert mit einem echten Server-Cron-Job (siehe Praxistipp weiter oben) hast Du sowohl zuverlässige Auslösung als auch volle Sicht und Kontrolle über alles, was im Hintergrund Deines Shops läuft.