Der Scheduler läuft nicht — und du merkst es monatelang nicht.

Wie der Scheduler arbeitet.

Im Backend legst du Aufgaben an und gibst an, wann sie laufen sollen. Das klingt nach einer Automatik, ist aber nur eine Liste: TYPO3 selbst startet nichts. Ausgeführt wird die Liste von einem Cronjob — einem wiederkehrenden Aufruf, den der Server selbst anstößt, üblicherweise alle fünf Minuten.

Daraus folgt der häufigste Fehler überhaupt: Jemand richtet im Backend Aufgaben ein, freut sich, und niemand hat je einen Cronjob eingerichtet. Die Aufgaben stehen dann jahrelang in der Liste, mit dem Vermerk, dass sie „als Nächstes“ laufen — und laufen nie.

Prüfen, ob er läuft.

1. Scheduler-Modul öffnen. Dort steht je Aufgabe die letzte Ausführung. Liegt sie Wochen zurück oder fehlt ganz, hast du die Antwort.
2. Auf den Hinweis achten: Ist kein Cronjob eingerichtet, zeigt TYPO3 im Scheduler meist eine entsprechende Warnung.
3. Testlauf aus dem Backend: Eine Aufgabe lässt sich von Hand starten. Läuft sie dort durch, ist die Aufgabe in Ordnung und nur die Automatik fehlt.
4. Beim Hoster nachsehen, ob ein Cronjob eingetragen ist und was er aufruft.

Schritt drei trennt die beiden Fehlerarten sauber: Aufgabe kaputt oder Automatik fehlt. Das spart den größten Teil der Sucherei.

Den Cronjob einrichten.

Bei den meisten Hostern geht das im Kundenbereich: Zeitpunkt und aufzurufender Befehl eintragen. Der Aufruf unterscheidet sich je nach Installationsart.

Einige Hoster bieten statt eines echten Cronjobs nur einen Aufruf über eine Webadresse an. Das funktioniert auch, ist aber langsamer und läuft in die Zeitgrenzen des Webservers — für große Aufgaben wie Datenmigrationen reicht es oft nicht.

Fünf Minuten sind ein guter Standard. Kürzere Abstände bringen selten etwas und erzeugen Last; längere führen dazu, dass zeitkritische Aufgaben hinterherhinken.

Die PHP-Version auf der Kommandozeile.

Der Klassiker, der am meisten Zeit kostet: Im Webserver läuft eine andere PHP-Version als auf der Kommandozeile. Die Website funktioniert, der Cronjob bricht ab — oder umgekehrt. Fehlermeldungen dazu sind oft kryptisch und weisen nicht auf die Version hin.

Prüfen lässt sich das, indem im Cronjob nicht einfach php aufgerufen wird, sondern der vollständige Pfad zur passenden Version. Bei vielen Hostern gibt es mehrere installierte Versionen nebeneinander. Im Zweifel beim Support erfragen, welcher Pfad zur eingestellten Webserver-Version gehört — das ist eine Standardfrage und in zwei Minuten beantwortet (Hosting-Anforderungen).

Fehlgeschlagene Aufgaben.

Läuft der Cronjob, aber einzelne Aufgaben scheitern, zeigt das Scheduler-Modul sie als fehlerhaft an — mit Meldung. Typische Ursachen:

Die dritte Zeile ist häufig: Eine Aufgabe gehört zu einer Extension, die irgendwann deaktiviert wurde. Die Aufgabe bleibt in der Liste stehen und scheitert bei jedem Durchlauf. Solche Karteileichen gehören gelöscht, sonst verstopfen sie die Fehlerübersicht und man übersieht die echten Probleme.

Zeitüberschreitungen.

Große Aufgaben — Indexierung einer großen Website, Datenmigration nach einem Upgrade, Aufräumen einer jahrelang gewachsenen Datenbank — brauchen länger als die üblichen Limits erlauben. Der Cronjob bricht dann mitten im Vorgang ab, und beim nächsten Lauf beginnt er von vorn, ohne je fertig zu werden.

Drei Wege: die Limits für die Kommandozeile erhöhen, was oft großzügiger möglich ist als für den Webserver; die Aufgabe in kleinere Pakete teilen, wenn sie das unterstützt; oder sie einmalig von Hand über die Kommandozeile laufen lassen, wo sich Limits gezielt setzen lassen (Speicherlimit).

Benachrichtigung bei Fehlern.

Ein Scheduler ohne Benachrichtigung ist halb nutzlos: Niemand schaut regelmäßig in die Liste. Je Aufgabe lässt sich eine E-Mail-Adresse hinterlegen, an die bei einem Fehler eine Nachricht geht. Das gehört eingerichtet — und dann muss der Mailversand funktionieren, sonst landet die Warnung im Nichts (Mailversand).

Zusätzlich sinnvoll ist eine Überwachung von außen für den Cronjob selbst: Ein Dienst, der meldet, wenn sich ein erwarteter Aufruf nicht gemeldet hat. Damit merkst du auch, wenn der Cronjob insgesamt ausfällt — und nicht nur eine einzelne Aufgabe.

Was ausfällt, wenn er nicht läuft.

• Aufräumen: Protokolle, Verlauf, Sitzungen und gelöschte Datensätze wachsen unbegrenzt (Datenbank).
• Datenmigration nach Upgrades bleibt hängen — mit widersprüchlichen Daten als Folge (Update-Fehler).
• Suchindex veraltet, neue Inhalte werden nicht gefunden (Suche).
• Löschfristen werden nicht umgesetzt — ein Datenschutzthema (Datenschutz).
• Importe und Schnittstellen laufen nicht.
• Geplante Veröffentlichungen erscheinen nicht zum Termin.
• Benachrichtigungen werden nicht verschickt.

Der vorletzte Punkt fällt am schnellsten auf: Eine Seite, die zu einem Termin online gehen sollte, bleibt unsichtbar. Alles andere bleibt lange unbemerkt — und wird dann als „TYPO3 ist langsam“ wahrgenommen (Tempo).

Welche Aufgaben sinnvoll sind.

1. Tabellen aufräumen: Protokolle und Verlaufsdaten auf einen sinnvollen Zeitraum begrenzen.
2. Gelöschte Datensätze endgültig entfernen — nach einer Frist, die zum Löschkonzept passt.
3. Alte Sitzungen und temporäre Dateien bereinigen.
4. Suchindex aktualisieren, falls eine Suche im Einsatz ist.
5. Verarbeitete Bilder gelegentlich bereinigen.
6. Dateiindex abgleichen, wenn Dateien auch außerhalb des Backends landen.

Diese sechs decken den Normalbetrieb ab. Wichtig ist, sie nicht alle zur selben Minute laufen zu lassen — sonst entsteht alle fünf Minuten eine Lastspitze. Versetzte Zeiten und nächtliche Läufe für die großen Aufgaben sind die ruhigere Variante.

Wenn du nicht weiterkommst.

Wenn Aufgaben nicht laufen oder du nicht weißt, ob ein Cronjob existiert, prüfe ich das und richte es ein. Schreib mir mit Domain, TYPO3-Version und einer kurzen Beschreibung — du bekommst eine ehrliche Einschätzung, ob ich der Richtige bin. Den Überblick über alle Themen gibt TYPO3-Fehler beheben. Wenn sich am Ende herausstellt, dass ein Wechsel die bessere Lösung ist: TYPO3 zu WordPress.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Web-Entwickler aus Quakenbrück. Mein Schwerpunkt liegt auf WordPress — an TYPO3-Installationen arbeite ich dort, wo es um Betrieb und Fehlersuche geht: Ausfälle, Serverthemen, Datenbank, Mailversand, Updates und die Frage, wie es mit einer alten Installation weitergehen soll. Das sind die Probleme, bei denen die Ursache meist nicht im System selbst liegt, sondern darunter. Geht es um tiefe Entwicklung in TYPO3 — eigene Extensions, komplexe Mehrsprachigkeit, große Redaktionssysteme —, sage ich dir das offen und empfehle jemanden, der genau das macht. Ehrlich beraten heißt für mich auch, eine Anfrage abzugeben.