Cronjob funktioniert nicht: Ursachen und Lösungen

Ein Cronjob ist in cPanel eingerichtet, aber die erwartete Aufgabe wird nicht ausgeführt? Dann solltest du Zeitplan, Befehl und das aufgerufene Skript getrennt voneinander prüfen.

Ein besonders häufiger Fehler bei der Diagnose besteht darin, einen nicht funktionierenden Cronjob automatisch mit einem fehlerhaften Zeitplan gleichzusetzen. Tatsächlich kann cPanel den Cronjob korrekt starten, während erst der ausgeführte Befehl oder das aufgerufene Skript fehlschlägt.

In dieser Anleitung zeigen wir dir, wie du einen nicht funktionierenden Cronjob systematisch untersuchst und typische Fehler bei Zeitplan, Pfaden, PHP-Version, Berechtigungen, Ausgaben und WordPress WP-Cron findest.

Grundregel: Prüfe zuerst, ob der Cronjob gestartet wird. Prüfe danach, ob der eingetragene Befehl funktioniert. Erst danach untersuchst du die eigentliche Anwendung. So vermeidest du Änderungen an mehreren technischen Ebenen gleichzeitig.

Die drei Ebenen eines Cronjob-Problems #

Für eine saubere Fehlersuche solltest du drei Bereiche voneinander unterscheiden:

1. Zeitplan
   ↓
Wird der Cronjob zum erwarteten Zeitpunkt gestartet?

2. Befehl
   ↓
Kann der eingetragene Befehl ausgeführt werden?

3. Anwendung
   ↓
Funktioniert das aufgerufene Skript selbst korrekt?

Diese Unterscheidung ist entscheidend.

Ein Cronjob kann beispielsweise pünktlich gestartet werden, aber wegen eines falschen Dateipfads sofort abbrechen. Ebenso kann PHP korrekt gestartet werden, während das PHP-Skript selbst einen Fatal Error erzeugt.

1. Cronjob in cPanel kontrollieren #

Melde dich bei deinem CURIAWEB-cPanel an und öffne:

Erweiterte Optionen → Cronjobs

Kontrolliere zunächst, ob der betreffende Cronjob tatsächlich in der Liste der vorhandenen Cronjobs eingetragen ist.

Prüfe anschließend den vollständigen Eintrag – insbesondere Zeitplan und Befehl.

Wenn du noch unsicher bist, wie ein Cronjob korrekt eingerichtet wird, findest du die Grundlagen unter Cronjob in cPanel erstellen und Zeitplan richtig einstellen.

2. Zeitplan genau prüfen #

Ein Cron-Zeitplan besteht aus fünf Feldern:

Minute Stunde Tag Monat Wochentag

Ein täglicher Cronjob um 03:00 Uhr kann beispielsweise so aussehen:

0 3 * * *

Ein Cronjob alle fünf Minuten:

*/5 * * * *

Kontrolliere die Werte Zeichen für Zeichen.

Minute und Stunde verwechselt #

Ein häufiger Fehler ist die Verwechslung der ersten beiden Felder.

Beispielsweise:

30 3 * * *

bedeutet grundsätzlich täglich um 03:30 Uhr.

Die Reihenfolge lautet nicht Stunde und Minute, sondern:

Minute → Stunde

Tag des Monats und Wochentag nicht verwechseln #

Auch diese beiden Felder haben unterschiedliche Bedeutungen.

Beispielsweise:

0 6 * * 1

steht grundsätzlich für eine Ausführung montags um 06:00 Uhr.

Dagegen:

0 6 1 * *

steht grundsätzlich für eine Ausführung am ersten Tag eines Monats um 06:00 Uhr.

3. Serverzeit beziehungsweise Zeitzone berücksichtigen #

Wenn der Cronjob funktioniert, aber scheinbar zur falschen Uhrzeit läuft, solltest du die für die Cron-Ausführung maßgebliche Zeitzone prüfen.

Die lokale Uhrzeit deines Computers und die vom Server verwendete Zeit müssen nicht identisch sein.

Praxis-Tipp: Wenn ein Cronjob zuverlässig ausgeführt wird, aber immer beispielsweise eine oder zwei Stunden vom erwarteten Zeitpunkt abweicht, ist die Zeitzone einer der ersten Punkte, die du kontrollieren solltest.

Sommer- und Winterzeit beachten #

Bei Aufgaben, die zwingend zu einer bestimmten lokalen Uhrzeit laufen sollen, kann auch die Umstellung zwischen Sommer- und Winterzeit relevant sein.

Verändere einen ansonsten funktionierenden Zeitplan deshalb nicht sofort auf Verdacht, wenn sich die beobachtete Ausführungszeit verschoben hat.

4. Vollständigen Cron-Befehl kontrollieren #

Wenn der Zeitplan stimmt, kontrolliere den eigentlichen Befehl.

Ein PHP-Cronjob kann schematisch beispielsweise so aufgebaut sein:

/pfad/zur/php-binary /home/CPANELUSER/public_html/script.php

Schon ein falsches Zeichen, ein nicht vorhandenes Verzeichnis oder eine falsche PHP-Binary kann dazu führen, dass der Befehl nicht funktioniert.

Wichtig: Verwende nicht einfach einen Cron-Befehl aus einer Anleitung eines anderen Hosting-Anbieters. PHP-Pfade und Verzeichnisstrukturen können sich unterscheiden.

5. Absolute Pfade prüfen #

Cronjobs sollten möglichst mit eindeutigen absoluten Pfaden arbeiten.

Ein Dateipfad kann schematisch so aussehen:

/home/CPANELUSER/public_html/script.php

Ein Eintrag wie:

script.php

ist dagegen ein relativer Pfad und setzt voraus, dass das richtige Arbeitsverzeichnis verwendet wird.

Genau diese Annahme kann bei einer automatischen Cron-Ausführung falsch sein.

Falsches Document Root #

Bei einem Hosting-Account mit mehreren Domains muss sich eine Website nicht zwingend unter public_html befinden.

Eine zusätzliche Domain oder Subdomain kann beispielsweise ein eigenes Document Root besitzen.

Wenn der Cronjob eine Datei der falschen Website beziehungsweise eines falschen Verzeichnisses aufruft, kann der Befehl fehlschlagen oder sogar eine andere Installation ansprechen.

Die Verzeichnisstruktur kannst du mit dem cPanel-Dateimanager kontrollieren.

6. Prüfen, ob die Datei tatsächlich existiert #

Öffne im cPanel-Dateimanager das im Cronjob angegebene Verzeichnis.

Kontrolliere:

• Existiert die Datei?
• Stimmt der Dateiname exakt?
• Stimmt die Groß- und Kleinschreibung?
• Liegt die Datei im angegebenen Verzeichnis?

Linux-Dateisysteme unterscheiden grundsätzlich zwischen Groß- und Kleinschreibung.

Beispielsweise können:

cron.php
Cron.php
CRON.php

unterschiedliche Dateinamen sein.

7. „No such file or directory“ beheben #

Eine Meldung wie:

No such file or directory

weist häufig darauf hin, dass eine angegebene Datei oder ein Programm unter dem verwendeten Pfad nicht gefunden wurde.

Prüfe dann insbesondere:

• Pfad zur PHP-Binary
• Pfad zum Skript
• Dateiname
• Document Root
• ob die Datei nach einer Migration verschoben wurde

8. „Command not found“ beheben #

Eine Meldung wie:

command not found

bedeutet grundsätzlich, dass das aufgerufene Kommando nicht gefunden werden konnte.

Das kann beispielsweise passieren, wenn ein Cronjob nur:

php script.php

verwendet und sich darauf verlässt, dass das gewünschte PHP automatisch über den Suchpfad gefunden wird.

Bei Cronjobs ist es zuverlässiger, die tatsächlich benötigte ausführbare Datei beziehungsweise den von der Anwendung vorgesehenen vollständigen Befehl zu verwenden.

9. PHP-Binary überprüfen #

Bei PHP-Cronjobs muss geklärt sein, welche PHP-Version das Skript ausführen soll.

Die PHP-Version einer Website und die PHP-Version eines Kommandozeilenaufrufs sind nicht automatisch identisch.

Wenn deine Website beispielsweise mit einer bestimmten PHP-Version funktioniert, der Cronjob aber eine andere PHP-Binary verwendet, kann das Skript beim automatischen Aufruf Fehler erzeugen.

Die PHP-Version einer Domain verwaltest du bei CURIAWEB grundsätzlich über den MultiPHP-Manager.

Wichtig: Der MultiPHP-Manager bestimmt die Web-PHP-Konfiguration der Domain. Bei einem CLI-Cronjob muss trotzdem separat geprüft werden, welche PHP-Binary im Cron-Befehl aufgerufen wird.

10. PHP-Version des Cronjobs nicht mit php -v erraten #

Ein allgemeiner Aufruf wie:

php -v

zeigt die PHP-Version des dabei aufgelösten CLI-Befehls.

Das beweist nicht automatisch, dass:

• die Website dieselbe PHP-Version verwendet
• der Cronjob dieselbe PHP-Binary verwendet
• die benötigten PHP-Erweiterungen identisch sind

Entscheidend ist der tatsächlich im Cronjob verwendete Befehl.

11. Fehlende PHP-Erweiterungen prüfen #

Ein PHP-Skript kann korrekt installiert sein und trotzdem fehlschlagen, wenn die verwendete PHP-Umgebung eine benötigte Erweiterung nicht bereitstellt.

Typische Fehlermeldungen können auf nicht vorhandene Klassen oder Funktionen hinweisen.

Prüfe dann zuerst, welche PHP-Version beziehungsweise PHP-Umgebung der Cronjob tatsächlich verwendet.

Weitere Informationen findest du unter PHP-Erweiterungen in cPanel aktivieren und verwalten.

12. Unterschiedliche PHP-Konfigurationen berücksichtigen #

Ein PHP-Skript kann über die Website funktionieren und über einen CLI-Cronjob trotzdem ein anderes Verhalten zeigen.

Der Grund kann sein, dass Web-PHP und CLI-PHP unterschiedliche Konfigurationen verwenden.

Dazu können beispielsweise Unterschiede bei:

PHP-Version
PHP-Erweiterungen
memory_limit
Konfigurationsdateien
Umgebungsvariablen

gehören.

Übertrage deshalb nicht automatisch jede Web-PHP-Einstellung auf einen CLI-Cronjob.

13. „Permission denied“ beheben #

Eine Meldung wie:

Permission denied

weist auf ein Berechtigungsproblem hin.

Die genaue Ursache hängt davon ab, was ausgeführt beziehungsweise geöffnet werden soll.

Prüfe insbesondere:

• Dateiberechtigungen
• Verzeichnisberechtigungen
• ob das Skript direkt ausgeführt oder über einen Interpreter aufgerufen wird
• ob das Skript Dateien schreiben oder verändern muss

Grundlagen dazu findest du unter Dateiberechtigungen 644 und 755 in cPanel richtig einstellen.

Achtung: Setze Dateiberechtigungen nicht pauschal auf 777, um einen Fehler zu umgehen. Damit wird die eigentliche Ursache nicht sauber gelöst und die Konfiguration kann unnötig unsicher werden.

14. Prüfen, ob das Skript Schreibrechte benötigt #

Ein Cronjob kann das PHP-Skript erfolgreich starten, während das Skript selbst beim Schreiben einer Datei fehlschlägt.

Das betrifft beispielsweise Prozesse, die:

• Cache-Dateien erzeugen
• Exporte speichern
• Importdateien verschieben
• Logdateien schreiben
• temporäre Dateien erstellen

Prüfe dann die Berechtigungen des konkreten Zielverzeichnisses.

15. Cron-Ausgabe nicht sofort verwerfen #

Bei der Fehlersuche ist die Ausgabe des Cronjobs eine der wichtigsten Informationsquellen.

Wenn dein Befehl beispielsweise mit:

> /dev/null 2>&1

endet, werden Standardausgabe und Fehlerausgabe verworfen.

Das ist bei einem fehlerhaften Cronjob ungünstig.

Praxis-Tipp: Entferne während der Diagnose eine bewusst eingerichtete Ausgabeunterdrückung vorübergehend, sofern dies für den betreffenden Befehl sinnvoll und sicher ist. So kannst du die tatsächliche Fehlermeldung sehen.

16. Standardausgabe und Fehlerausgabe unterscheiden #

Linux-Kommandos können grundsätzlich zwei relevante Ausgabekanäle verwenden:

stdout
→ normale Ausgabe

stderr
→ Fehlermeldungen

Wenn nur die normale Ausgabe umgeleitet wird, kann eine Fehlermeldung weiterhin an anderer Stelle erscheinen.

Die Schreibweise:

2>&1

leitet die Fehlerausgabe an dasselbe Ziel wie die Standardausgabe weiter.

17. Cron-Ausgabe vorübergehend protokollieren #

Bei einem eigenen Skript kann es für die Diagnose sinnvoll sein, Ausgaben vorübergehend in eine Logdatei zu schreiben.

Schematisch:

BEFEHL >> /home/CPANELUSER/logs/cron-test.log 2>&1

Damit werden normale Ausgaben und Fehlermeldungen an eine Datei angehängt.

Verwende einen existierenden und beschreibbaren Pfad.

Wichtig: Eine solche Diagnose-Logdatei sollte kontrolliert und nach der Fehlersuche entfernt oder sinnvoll verwaltet werden. Häufig ausgeführte Cronjobs können Logdateien schnell anwachsen lassen.

18. E-Mail-Ausgaben des Cronjobs prüfen #

cPanel kann Cron-Ausgaben an eine konfigurierte E-Mail-Adresse senden.

Wenn du diese Funktion verwendest, kontrolliere auch den Spam-Ordner des betreffenden Postfachs.

Eine Cron-E-Mail kann beispielsweise eine Fehlermeldung enthalten, die unmittelbar auf einen falschen Pfad oder einen PHP-Fehler hinweist.

19. Cronjob manuell ausführen #

Wenn du SSH-Zugriff besitzt und der Befehl gefahrlos manuell ausgeführt werden kann, ist ein manueller Test sehr hilfreich.

Führe dabei möglichst genau den Befehl aus, der auch im Cronjob eingetragen ist.

Damit kannst du zwei Fälle unterscheiden:

Befehl funktioniert manuell nicht
→ Problem liegt wahrscheinlich im Befehl oder Skript

Befehl funktioniert manuell
→ Cron-Umgebung oder Zeitplan genauer untersuchen

Achtung: Führe einen Import, Versandprozess, Zahlungsprozess oder eine andere verändernde Aufgabe nicht testweise mehrfach aus, wenn du deren Verhalten bei Wiederholung nicht kennst.

20. Manuell funktioniert – als Cronjob nicht #

Wenn derselbe Befehl in einer interaktiven Shell funktioniert, als Cronjob aber nicht, solltest du insbesondere die Ausführungsumgebung untersuchen.

Cronjobs besitzen möglicherweise nicht dieselben Umgebungsvariablen wie deine interaktive SSH-Sitzung.

Relevant sind beispielsweise:

• PATH
• Arbeitsverzeichnis
• PHP-Binary
• weitere Umgebungsvariablen

Verwende deshalb möglichst vollständige Pfade zu Programmen und Dateien.

21. Arbeitsverzeichnis des Skripts prüfen #

Manche Skripte verwenden intern relative Dateipfade.

Beispielsweise:

include 'config.php';

oder sie erwarten Dateien relativ zum aktuellen Arbeitsverzeichnis.

Wenn das Skript in einer anderen Umgebung gestartet wird, kann dies zu Problemen führen.

Eine robuste Anwendung sollte benötigte Pfade eindeutig behandeln. Bei einer fremden Anwendung solltest du deren vorgesehene Cron-Anweisung verwenden.

22. HTTP-Aufruf funktioniert, CLI-Aufruf nicht #

Manche Anwendungen stellen für Cron-Aufgaben eine URL bereit.

Ein HTTP-Aufruf und ein direkter PHP-CLI-Aufruf sind technisch nicht identisch.

HTTP:
Cron → HTTP/HTTPS → Webserver → Anwendung

CLI:
Cron → PHP-Binary → PHP-Skript

Wenn der Hersteller ausdrücklich einen HTTP-Aufruf vorsieht, solltest du diesen nicht ohne technischen Grund durch einen direkten PHP-Aufruf ersetzen.

23. CLI funktioniert, HTTP-Aufruf nicht #

Umgekehrt kann ein direkter PHP-Aufruf funktionieren, während ein HTTP-Aufruf fehlschlägt.

Bei einem HTTP-Aufruf kommen zusätzliche Komponenten hinzu:

• DNS
• Webserver
• HTTPS
• Weiterleitungen
• Zugriffsschutz
• Anwendungsrouting

Prüfe deshalb, welche Aufrufart die Anwendung tatsächlich vorsieht.

24. HTTP-Cronjob erhält 403 Forbidden #

Wenn ein Cronjob eine URL aufruft und dabei einen:

403 Forbidden

erhält, erreicht der HTTP-Aufruf grundsätzlich den Webserver, wird aber nicht wie erwartet zugelassen.

Die Ursache kann beispielsweise in Zugriffsschutz, Sicherheitsregeln oder der Anwendung liegen.

Die systematische Diagnose behandeln wir unter 403 Forbidden beheben.

25. HTTP-Cronjob erhält 500 Internal Server Error #

Ein:

500 Internal Server Error

weist auf einen serverseitigen Fehler während der Verarbeitung hin.

Der Cronjob kann in diesem Fall durchaus korrekt gestartet worden sein. Der Fehler entsteht erst beim HTTP-Aufruf beziehungsweise in der Anwendung.

Weitere Schritte findest du unter 500 Internal Server Error beheben.

26. PHP Fatal Error untersuchen #

Wenn die Ausgabe einen PHP Fatal Error enthält, ist der Zeitplan normalerweise nicht das primäre Problem.

Entscheidend ist dann die konkrete PHP-Fehlermeldung.

Mögliche Ursachen sind beispielsweise:

• inkompatible PHP-Version
• fehlende PHP-Erweiterung
• fehlerhafter Anwendungscode
• fehlende Datei
• Speicherproblem

Ändere nicht mehrere PHP-Einstellungen gleichzeitig, sondern arbeite anhand der konkreten Fehlermeldung.

27. „Allowed memory size exhausted“ #

Eine Meldung wie:

Allowed memory size ... exhausted

weist darauf hin, dass der PHP-Prozess sein verfügbares Speicherlimit erreicht hat.

Prüfe dabei unbedingt, welche PHP-Umgebung den Cronjob ausführt.

Die Web-PHP-Einstellungen einer Domain müssen nicht automatisch für einen PHP-CLI-Prozess gelten.

Grundlagen zu den PHP-Limits findest du unter PHP Memory Limit, Upload-Größe und Ausführungszeit einstellen.

28. Laufzeit und Timeouts richtig einordnen #

Wenn ein Cronjob bei einer längeren Aufgabe abbricht, kann die Laufzeit eine Rolle spielen.

Unterscheide dabei zwischen:

• Limits der verwendeten PHP-Umgebung
• Limits beziehungsweise Verhalten der Anwendung
• externen Diensten
• Hosting-Ressourcen

Ein CLI-Prozess verhält sich hinsichtlich PHP-Limits nicht zwingend identisch mit einem normalen Webseitenaufruf.

29. Externe API antwortet nicht #

Ein Cronjob kann technisch korrekt funktionieren und trotzdem seine Aufgabe nicht abschließen, wenn das Skript von einem externen Dienst abhängig ist.

Beispiele sind:

• externe APIs
• Warenwirtschaftssysteme
• CRM-Systeme
• Zahlungsdienste
• externe Datenquellen

Prüfe in diesem Fall die Ausgabe beziehungsweise das Anwendungslog auf Verbindungsfehler, Authentifizierungsprobleme oder Zeitüberschreitungen.

30. Zugangsdaten oder API-Schlüssel prüfen #

Wenn ein Cronjob Daten mit einem externen System austauscht, können ungültige oder abgelaufene Zugangsdaten die Ursache sein.

Typische Fehler sind beispielsweise:

Unauthorized
Authentication failed
Invalid API key
Access denied

Speichere sensible Zugangsdaten nicht ungeschützt direkt im Cron-Befehl.

31. Cronjob startet zu häufig #

Ein Cronjob kann technisch funktionieren und trotzdem Probleme verursachen, wenn er zu häufig gestartet wird.

Beispiel:

Start alle 5 Minuten
Laufzeit 12 Minuten

Dann kann eine neue Instanz gestartet werden, während die vorherige noch läuft.

32. Überlappende Prozesse erkennen #

Mehrere gleichzeitig laufende Instanzen können beispielsweise zu folgenden Problemen führen:

• doppelte Verarbeitung
• gesperrte Dateien
• Datenbankkonflikte
• erhöhte CPU-Auslastung
• höherem Speicherverbrauch
• externen API-Limits

Prüfe bei lang laufenden Aufgaben deshalb, ob das Intervall zur tatsächlichen Laufzeit passt.

33. Anwendung gegen parallele Ausführung absichern #

Professionelle Anwendungen verwenden für bestimmte Aufgaben Mechanismen, die eine parallele Ausführung verhindern können.

Das kann beispielsweise über Lock-Dateien, Datenbankstatus oder andere Sperrmechanismen erfolgen.

Implementiere solche Mechanismen nicht auf Verdacht in fremde Anwendungen. Prüfe zuerst deren Dokumentation.

34. Hosting-Ressourcen kontrollieren #

Ein Cronjob kann CPU, Arbeitsspeicher, Prozesse und Datenbankressourcen beanspruchen.

Bei häufigen oder umfangreichen Aufgaben kann deshalb die Ressourcennutzung relevant sein.

Wie du CloudLinux-Werte kontrollierst, erklären wir unter CloudLinux Ressourcennutzung in cPanel verstehen.

35. Resource Limit Is Reached #

Wenn deine Website oder Anwendung gleichzeitig Hinweise auf ausgeschöpfte Hosting-Ressourcen zeigt, sollte dies separat untersucht werden.

Ein Cronjob kann eine Lastspitze auslösen oder mit einer bereits vorhandenen hohen Auslastung zusammenfallen.

Die gezielte Diagnose behandeln wir unter Resource Limit Is Reached: CloudLinux-Limits erkennen und beheben.

36. Mehrere Cronjobs starten gleichzeitig #

Wenn mehrere ressourcenintensive Cronjobs exakt zur gleichen Minute starten, kann eine unnötige Lastspitze entstehen.

Beispielsweise:

03:00 → Import
03:00 → Export
03:00 → Synchronisation
03:00 → Statistikverarbeitung

Wenn die Anwendungen zeitlich flexibel sind, können unterschiedliche Startzeiten sinnvoller sein.

Ändere vorgegebene Intervalle einer Anwendung jedoch nicht ohne Prüfung.

37. Cronjob funktioniert nach Website-Umzug nicht mehr #

Nach einem Hosting- oder Website-Umzug gehören Cronjobs zu den Konfigurationen, die separat kontrolliert werden sollten.

Insbesondere absolute Pfade können sich geändert haben.

Ein alter Cronjob kann beispielsweise weiterhin auf:

/home/ALTERUSER/...

zeigen, obwohl die Anwendung inzwischen unter einem anderen Accountpfad liegt.

38. Cronjob nach Domainwechsel prüfen #

Wenn der Cronjob eine URL aufruft, kann ein Domainwechsel ebenfalls relevant sein.

Kontrolliere dann:

• Hostname
• HTTPS
• Weiterleitungen
• Pfad der Cron-URL
• Zugriffsschutz

Ein alter HTTP-Cronjob kann ansonsten weiterhin eine nicht mehr gültige Adresse aufrufen.

39. Cronjob funktioniert nach PHP-Wechsel nicht mehr #

Wenn das Problem unmittelbar nach einer Änderung der PHP-Version auftritt, solltest du prüfen, welche PHP-Binary der Cronjob verwendet.

Ein fest eingetragener CLI-Pfad wird durch die Änderung der Web-PHP-Version nicht zwangsläufig automatisch angepasst.

Prüfe zusätzlich, ob die Anwendung und ihre benötigten Erweiterungen mit der verwendeten PHP-Version kompatibel sind.

40. Cronjob funktioniert nach Update nicht mehr #

Wenn eine Anwendung unmittelbar nach einem Update ihre Cron-Aufgabe nicht mehr korrekt verarbeitet, notiere:

• welche Anwendung aktualisiert wurde
• welche Version vorher verwendet wurde
• welche Version jetzt verwendet wird
• welche Fehlermeldung der Cronjob erzeugt

Prüfe anschließend die Dokumentation beziehungsweise Systemanforderungen der Anwendung.

Verändere nicht gleichzeitig Cron-Syntax, PHP-Version und Dateiberechtigungen, wenn der Fehler eindeutig erst nach einem Software-Update begonnen hat.

41. WordPress WP-Cron funktioniert nicht #

WordPress verwendet standardmäßig WP-Cron für geplante Aufgaben.

WP-Cron ist kein klassischer Linux-Cronjob. Geplante Aufgaben werden standardmäßig im Zusammenhang mit Website-Aufrufen angestoßen.

Wenn WordPress-Aufgaben verspätet oder gar nicht ausgeführt werden, solltest du deshalb zunächst klären, ob:

• der normale WP-Cron verwendet wird
• WP-Cron bewusst deaktiviert wurde
• ein echter Server-Cron als Ersatz eingerichtet wurde
• dieser Server-Cron tatsächlich funktioniert

42. DISABLE_WP_CRON prüfen #

In der WordPress-Datei wp-config.php kann beispielsweise folgende Einstellung vorhanden sein:

define( 'DISABLE_WP_CRON', true );

Damit wird der normale WordPress-Aufrufmechanismus für WP-Cron deaktiviert.

Das ist nur sinnvoll, wenn bewusst ein anderer zuverlässiger Mechanismus für die geplanten WordPress-Aufgaben eingerichtet wurde.

Achtung: Entferne oder ändere DISABLE_WP_CRON nicht blind. Prüfe zuerst, warum die Einstellung gesetzt wurde und ob ein Server-Cronjob als Ersatz existiert.

43. Server-Cron für WordPress vorhanden, Aufgaben laufen trotzdem nicht #

Wenn ein echter Cronjob WordPress regelmäßig anstoßen soll, prüfe zunächst, ob dieser Cronjob selbst erfolgreich ausgeführt wird.

Danach muss geprüft werden, ob WordPress die fälligen Aufgaben tatsächlich verarbeitet.

Damit trennst du erneut:

Server-Cron funktioniert?
        ↓
WordPress wird erreicht?
        ↓
WP-Cron verarbeitet fällige Aufgaben?
        ↓
Einzelne Anwendung verarbeitet ihre Aufgabe?

44. WooCommerce-Aufgabe wird nicht ausgeführt #

WooCommerce und Erweiterungen können geplante Hintergrundaufgaben verwenden.

Wenn eine bestimmte Shop-Aufgabe ausbleibt, bedeutet das nicht automatisch, dass der cPanel-Cronjob fehlerhaft ist.

Prüfe zunächst, auf welcher Ebene die betreffende Aufgabe geplant und verarbeitet wird.

Bei WordPress-/WooCommerce-Systemen kann zusätzlich das interne System für geplante Aktionen eine Rolle spielen.

45. Cronjob verschickt eine große Menge E-Mails #

Wenn ein Cronjob E-Mails auslöst, solltest du bei Tests besonders vorsichtig sein.

Ein auf jede Minute gesetzter Test-Cronjob kann ansonsten dieselbe Versandfunktion wiederholt auslösen.

Achtung: Verwende für Versand-, Newsletter-, Rechnungs- oder Benachrichtigungsprozesse kein aggressives Testintervall, solange du nicht weißt, wie die Anwendung Mehrfachausführungen verhindert.

46. Cronjob erzeugt doppelte Datensätze #

Doppelte Datensätze können ein Hinweis darauf sein, dass:

• der Cronjob mehrfach eingerichtet wurde
• mehrere identische Prozesse parallel laufen
• die Anwendung selbst keinen Schutz gegen doppelte Verarbeitung besitzt
• ein Server-Cron und ein weiterer Scheduler dieselbe Aufgabe auslösen

Prüfe zuerst die Liste der vorhandenen Cronjobs und anschließend die Anwendungskonfiguration.

47. Prüfen, ob derselbe Cronjob doppelt vorhanden ist #

Kontrolliere unter:

Erweiterte Optionen → Cronjobs

ob derselbe oder ein nahezu identischer Befehl mehrfach eingetragen wurde.

Das kann beispielsweise nach einer Migration oder manuellen Neueinrichtung passieren.

Lösche einen Eintrag nur, wenn du sicher weißt, dass es sich tatsächlich um eine unnötige Dublette handelt.

48. Cronjob wurde gelöscht #

Wenn eine Anwendung plötzlich keine geplanten Aufgaben mehr verarbeitet, kontrolliere auch, ob der benötigte Cronjob noch vorhanden ist.

Das kann beispielsweise nach einer Bereinigung, Migration oder manuellen Änderung relevant sein.

Ein gelöschter Cronjob wird nicht automatisch dadurch wiederhergestellt, dass die Anwendung weiterhin installiert ist.

49. Alte Cronjobs nach Deinstallation einer Anwendung #

Umgekehrt können Cronjobs bestehen bleiben, obwohl die zugehörige Anwendung nicht mehr vorhanden ist.

Dann kann der Cronjob regelmäßig einen nicht mehr existierenden Pfad aufrufen und fortlaufend Fehlermeldungen erzeugen.

Prüfe bei der Entfernung einer Anwendung deshalb auch, ob dazugehörige Cronjobs noch benötigt werden.

50. Cronjob nicht durch permanentes Ausprobieren reparieren #

Wenn ein Cronjob nicht funktioniert, solltest du nicht gleichzeitig:

Zeitplan ändern
PHP-Version ändern
Dateirechte ändern
Skript verschieben
PHP-Limits ändern
Cron-Befehl ersetzen

Danach lässt sich kaum noch feststellen, welche Änderung tatsächlich relevant war.

Arbeite stattdessen vom Cronjob zur Anwendung:

Zeitplan
→ Befehl
→ Pfade
→ Ausführungsumgebung
→ Fehlermeldung
→ Anwendung

Typische Fehlermeldungen richtig einordnen #

Fehlermeldung / Problem	Zuerst prüfen
command not found	Befehl und vollständiger Pfad zur ausführbaren Datei
No such file or directory	Dateipfad, Dateiname und Document Root
Permission denied	Datei-/Verzeichnisrechte und Ausführungsart
PHP Fatal Error	konkrete PHP-Meldung, PHP-Version und Anwendung
Allowed memory size exhausted	PHP-Umgebung und Speicherbedarf
Cronjob läuft zur falschen Uhrzeit	Zeitplan und Zeitzone
Manuell funktioniert, Cron nicht	absolute Pfade und Cron-Umgebung
HTTP-Aufruf liefert 403	Zugriffsschutz, Sicherheitsregeln und Anwendung
HTTP-Aufruf liefert 500	Server-/PHP-/Anwendungsfehler und Logs
Aufgabe wird doppelt ausgeführt	doppelte Cronjobs und überlappende Prozesse
Nach Umzug funktioniert Cron nicht	absolute Pfade und Domain
Nach PHP-Wechsel funktioniert Cron nicht	PHP-Binary und benötigte Extensions

Systematische Diagnose in zehn Schritten #

1. Öffne Erweiterte Optionen → Cronjobs und kontrolliere, ob der Cronjob vorhanden ist.
2. Prüfe Minute, Stunde, Tag, Monat und Wochentag.
3. Berücksichtige die für die Ausführung maßgebliche Zeitzone.
4. Kontrolliere den vollständigen Befehl.
5. Prüfe alle absoluten Datei- und Programmpfade.
6. Kontrolliere bei PHP-Skripten die verwendete PHP-Binary.
7. Entferne für die Diagnose gegebenenfalls bewusst eingerichtete Ausgabeunterdrückung.
8. Notiere die vollständige Fehlermeldung.
9. Teste den Befehl – sofern gefahrlos möglich – manuell.
10. Untersuche erst danach die Anwendung selbst.

Wenn keine Fehlermeldung vorhanden ist #

Wenn du keinerlei Ausgabe erhältst, solltest du zuerst prüfen, ob diese bewusst unterdrückt wird.

Suche im Cron-Befehl beispielsweise nach:

/dev/null

Prüfe außerdem, ob Cron-Ausgaben per E-Mail zugestellt werden und ob die Anwendung eine eigene Logdatei besitzt.

Bei einem eigenen Skript kann eine vorübergehende kontrollierte Protokollierung hilfreich sein.

Wenn der Cronjob sporadisch funktioniert #

Ein Cronjob, der nicht immer fehlschlägt, benötigt eine andere Betrachtung als ein grundsätzlich falscher Befehl.

Prüfe bei sporadischen Problemen insbesondere:

• Ressourcenauslastung
• Laufzeit
• überlappende Prozesse
• externe APIs
• Netzwerkabhängigkeiten
• wechselnde Eingabedaten
• Anwendungslogs zum konkreten Fehlerzeitpunkt

Notiere möglichst den genauen Zeitpunkt eines Fehlers. Dadurch lassen sich Logs und Ressourcenwerte wesentlich besser zuordnen.

cPanel Error Log richtig einordnen #

Bei Fehlern einer über den Webserver aufgerufenen Anwendung kann das cPanel-Fehlerprotokoll wichtige Hinweise enthalten.

Die Auswertung erklären wir unter cPanel Error Log lesen und Website-Fehler finden.

Ein direkt über PHP-CLI ausgeführter Cronjob muss seine Fehler jedoch nicht zwingend in demselben Webserver-Log protokollieren. Deshalb solltest du zusätzlich die Cron-Ausgabe und anwendungseigene Logs prüfen.

Wann solltest du den CURIAWEB-Support kontaktieren? #

Wenn du Zeitplan, Befehl, Pfade und Ausgaben kontrolliert hast, der Cronjob aber weiterhin nicht wie erwartet funktioniert, dokumentiere das Problem möglichst konkret.

Für eine technische Analyse sind insbesondere folgende Angaben hilfreich:

• betroffene Domain beziehungsweise Anwendung
• eingestellter Cron-Zeitplan
• vollständiger Cron-Befehl ohne vertrauliche Daten
• erwartetes Verhalten
• tatsächliches Verhalten
• ungefähre oder genaue Zeit der letzten fehlerhaften Ausführung
• vollständige Fehlermeldung
• verwendete PHP-Binary beziehungsweise PHP-Version, falls relevant
• ob der identische Befehl manuell funktioniert
• ob der Cronjob früher funktioniert hat
• welche Änderung unmittelbar vor dem Problem vorgenommen wurde

Sicherheitshinweis: Entferne Passwörter, API-Schlüssel, Tokens und andere Zugangsdaten aus dem Cron-Befehl, bevor du ihn weitergibst. Übermittle solche vertraulichen Informationen nicht unnötig.

Zusammenfassung #

Wenn ein Cronjob nicht funktioniert, solltest du zuerst feststellen, auf welcher Ebene das Problem entsteht. Ein Cronjob besteht nicht nur aus seinem Zeitplan: cPanel startet einen Befehl, der wiederum ein Skript oder eine andere Anwendung ausführt.

Kontrolliere deshalb zuerst den Cron-Zeitplan und die Zeitzone. Prüfe danach den vollständigen Befehl, absolute Pfade und bei PHP-Skripten die tatsächlich verwendete PHP-Binary.

Meldungen wie command not found, No such file or directory oder Permission denied geben bereits wichtige Hinweise auf die Ursache. PHP Fatal Errors müssen dagegen anhand der konkreten PHP-Meldung untersucht werden.

Unterdrücke Fehlermeldungen während der Diagnose nicht vorschnell mit /dev/null. Cron-Ausgaben, Logdateien und ein kontrollierter manueller Test sind häufig die schnellsten Wege zur Ursache.

Wenn ein Befehl manuell funktioniert, als Cronjob aber nicht, solltest du insbesondere absolute Pfade, PHP-Binary, Arbeitsverzeichnis und Umgebungsvariablen berücksichtigen.

Bei WordPress muss zusätzlich zwischen dem WordPress-eigenen WP-Cron und einem echten Server-Cronjob unterschieden werden. Ist DISABLE_WP_CRON aktiviert, muss ein funktionierender alternativer Mechanismus vorhanden sein.

Bei sporadischen Fehlern solltest du außerdem Ressourcenverbrauch, überlappende Prozesse und externe Abhängigkeiten untersuchen.

Die wichtigste Regel für eine effiziente Fehlersuche lautet: Nicht alles gleichzeitig verändern. Prüfe Zeitplan → Befehl → Pfade → Ausführungsumgebung → Fehlermeldung → Anwendung in genau dieser Reihenfolge.