La tâche cron ne fonctionne pas : causes et solutions

Une tâche cron est configurée dans cPanel, mais la tâche attendue ne s'exécute pas ? Vous devez alors vérifier séparément le calendrier, la commande et le script appelé.

Une erreur particulièrement fréquente lors du diagnostic consiste à assimiler automatiquement un cronjob qui ne fonctionne pas à un calendrier défectueux. En réalité, cPanel peut lancer correctement le cronjob, alors que c'est seulement la commande exécutée ou le script appelé qui échoue.

Dans ce guide, nous vous montrons comment analyser systématiquement un cronjob qui ne fonctionne pas et identifier les erreurs typiques concernant le calendrier, les chemins, la version de PHP, les permissions, les sorties et WordPress WP-Cron.

Règle de base : Vérifie d'abord si la tâche cron est lancée. Vérifie ensuite si la commande enregistrée fonctionne. Ce n'est qu'après que tu examines l'application elle-même. Tu évites ainsi de faire des modifications sur plusieurs niveaux techniques en même temps.

Les trois niveaux d'un problème de cronjob #

Pour un dépannage efficace, vous devez distinguer trois domaines :

1. Calendrier
   ↓
Le cronjob est-il exécuté à l'heure prévue ?

2. Commande
   ↓
La commande saisie peut-elle être exécutée ?

3. Application
   ↓
Le script appelé fonctionne-t-il correctement lui-même ?

Cette distinction est cruciale.

Un cronjob peut par exemple être lancé à l'heure prévue, mais s'interrompre immédiatement en raison d'un chemin de fichier erroné. De même, PHP peut démarrer correctement, tandis que le script PHP lui-même génère une erreur fatale.

1. Vérifier la tâche cron dans cPanel #

Connecte-toi à ton cPanel CURIAWEB et ouvre :

Options avancées → Tâches Cron

Vérifiez d'abord si le cronjob en question figure effectivement dans la liste des cronjobs existants.

Vérifiez ensuite l'entrée complète, en particulier le calendrier et la commande.

Si vous ne savez toujours pas comment configurer correctement une tâche cron, vous trouverez les bases sur Créer une tâche cron dans cPanel et configurer correctement le calendrier.

2. Vérifier le calendrier avec précision #

Un calendrier cron se compose de cinq champs :

Minute, heure, jour, mois, jour de la semaine

Un cronjob quotidien à 03h00 peut par exemple ressembler à ceci :

0 3 * * *

Un travail cron toutes les cinq minutes :

*/5 * * * *

Vérifiez les valeurs caractère par caractère.

Minute et heure confondues #

Une erreur fréquente est la confusion des deux premiers champs.

Par exemple :

30 3 * * *

signifie en principe tous les jours à 03h30.

L'ordre n'est pas l'heure et la minute, mais :

Minute → Heure

Ne pas confondre le jour du mois et le jour de la semaine #

Ces deux champs ont également des significations différentes.

Par exemple :

0 6 * * 1

correspond par principe à une exécution le lundi à 06h00.

En revanche :

0 6 1 * *

signifie généralement une exécution le premier jour d'un mois à 06:00.

3. Prendre en compte l'heure du serveur ou le fuseau horaire #

Si le travail cron fonctionne mais semble s'exécuter à la mauvaise heure, vous devriez vérifier le fuseau horaire pertinent pour l'exécution de cron.

L'heure locale de votre ordinateur et celle utilisée par le serveur ne doivent pas nécessairement être identiques.

Conseil pratique : Si une tâche cron s'exécute de manière fiable mais diffère toujours d'une ou deux heures de l'heure prévue, le fuseau horaire est l'un des premiers points que vous devez vérifier.

Tenir compte de l'heure d'été et d'hiver #

Pour les tâches qui doivent impérativement s'exécuter à une heure locale précise, le passage à l'heure d'été ou d'hiver peut également être pertinent.

Ne modifiez donc pas immédiatement un planning par ailleurs fonctionnel sur de simples suppositions si le temps d'exécution observé a changé.

4. Contrôler la commande cron complète #

Si le calendrier est correct, vérifie la commande proprement dite.

Un cronjob PHP peut par exemple être structuré schématiquement de cette manière :

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

Un seul caractère erroné, un répertoire inexistant ou un mauvais binaire PHP peut empêcher la commande de fonctionner.

Important : N'utilisez pas simplement une commande cron tirée du guide d'un autre hébergeur. Les chemins PHP et les structures de répertoires peuvent différer.

5. Vérifier les chemins absolus #

Les tâches cron doivent de préférence utiliser des chemins absoluts explicites.

Un chemin de fichier peut se présenter schématiquement ainsi :

/home/CPANELUSER/public_html/script.php

Une entrée telle que :

script.php

est en revanche un chemin relatif et suppose que le répertoire de travail approprié est utilisé.

C'est précisément cette hypothèse qui peut être fausse lors d'une exécution automatique par cron.

Mauvaise racine de document #

Sur un compte d'hébergement avec plusieurs domaines, un site Web ne doit pas nécessairement se trouver sous public_html se trouver.

Un domaine ou un sous-domaine supplémentaire peut par exemple posséder sa propre racine de document.

Si le cronjob appelle un fichier du mauvais site Web ou d'un mauvais répertoire, la commande peut échouer ou même cibler une autre installation.

Vous pouvez consulter la structure des répertoires avec Gestionnaire de fichiers cPanel contrôler.

6. Vérifier si le fichier existe effectivement #

Ouvrez le répertoire spécifié dans la tâche cron dans le gestionnaire de fichiers cPanel.

Vérifie :

• Le fichier existe-t-il ?
• Le nom du fichier est-il exact ?
• La casse est-elle correcte ?
• Le fichier se trouve-t-il dans le répertoire spécifié ?

Les systèmes de fichiers Linux font fondamentalement une distinction entre les majuscules et les minuscules.

Par exemple, les éléments suivants peuvent :

cron.php

être des noms de fichiers différents.

7. Résoudre l'erreur „ No such file or directory “ #

Un message tel que :

Aucun fichier ou dossier de ce nom

indique souvent qu'un fichier ou un programme spécifié n'a pas été trouvé sous le chemin utilisé.

Vérifie ensuite en particulier :

• Chemin d'accès au binaire PHP
• Chemin du script
• Nom de fichier
• Racine du document
• si le fichier a été déplacé après une migration

8. Résoudre l'erreur „ Commande introuvable “ #

Un message tel que :

commande introuvable

signifie généralement que la commande appelée n'a pas pu être trouvée.

Cela peut par exemple se produire si un cronjob se contente de :

php script.php

utilisé et en s'en remettant au fait que le PHP souhaité soit automatiquement trouvé via le chemin de recherche.

Avec les tâches cron, il est plus fiable d'utiliser l'exécutable réellement requis ou la commande complète prévue par l'application.

9. Vérifier le binaire PHP #

Pour les tâches cron PHP, il faut déterminer quelle version de PHP doit exécuter le script.

La version PHP d'un site Web et la version PHP d'une commande en ligne ne sont pas automatiquement identiques.

Par exemple, si votre site Web fonctionne avec une version spécifique de PHP, mais que la tâche cron utilise un autre binaire PHP, le script peut générer des erreurs lors de son exécution automatique.

Vous gérez fondamentalement la version PHP d'un domaine sur CURIAWEB via le MultiPHP-Manager.

Important : Le gestionnaire MultiPHP détermine la configuration PHP Web du domaine. Dans le cas d'une tâche cron CLI, il faut tout de même vérifier séparément quel binaire PHP est appelé dans la commande cron.

10. Ne pas deviner la version PHP de la tâche cron avec php -v #

Un appel général tel que :

php -v

affiche la version PHP de la commande CLI ainsi résolue.

Cela ne prouve pas automatiquement que :

• le site Web utilise la même version de PHP
• le cronjob utilise le même binaire PHP
• les extensions PHP requises sont identiques

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.

Tu trouveras plus d'informations sur Activer et gérer les extensions PHP dans cPanel.

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 #

Un message tel que :

Accès refusé

weist auf ein Berechtigungsproblem hin.

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

Vérifie en particulier :

• Autorisations de fichiers
• Autorisations de répertoire
• 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 Définir correctement les autorisations de fichiers 644 et 755 dans cPanel.

Attention : Ne définissez pas les autorisations de fichiers de manière globale sur 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.

Conseil pratique : 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.

Schématiquement :

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.

Important : 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

Attention : 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.

Sont pertinents, par exemple :

• 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.

Par exemple :

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
• Redirections
• Protection contre l'accès non autorisé
• 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 Interdit

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 Résoudre l'erreur 403 Forbidden.

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

Un

500 Erreur interne du serveur

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.

Vous trouverez de plus amples informations sur Résoudre l'erreur interne du serveur 500.

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.

Les causes possibles sont par exemple :

• inkompatible PHP-Version
• extension PHP manquante
• fehlerhafter Anwendungscode
• fehlende Datei
• Speicherproblem

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

27. „Allowed memory size exhausted“ #

Un message tel que :

Taille de mémoire autorisée ... épuisée

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 Définir la limite de mémoire PHP, la taille de téléchargement et le temps d'exécution.

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
• Ressources d'hébergement

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.

Les exemples sont :

• APIs externes
• Warenwirtschaftssysteme
• Systèmes CRM
• 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.

Exemple :

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 Comprendre l'utilisation des ressources CloudLinux dans cPanel.

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 Limite de ressources atteinte : identifier et corriger les limites CloudLinux.

36. Mehrere Cronjobs starten gleichzeitig #

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

Par exemple :

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:

• Nom d'hôte
• HTTPS
• Redirections
• Pfad der Cron-URL
• Protection contre l'accès non autorisé

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.

Attention : 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.

Attention : 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:

Options avancées → Tâches Cron

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	Vérifier d'abord
commande introuvable	Befehl und vollständiger Pfad zur ausführbaren Datei
Aucun fichier ou dossier de ce nom	Dateipfad, Dateiname und Document Root
Accès refusé	Datei-/Verzeichnisrechte und Ausführungsart
Erreur fatale PHP	konkrete PHP-Meldung, PHP-Version und Anwendung
Taille de mémoire autorisée épuisée	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. Ouvrir Options avancées → Tâches Cron 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
• durée
• überlappende Prozesse
• APIs externes
• 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 Lire le journal des erreurs cPanel et trouver les erreurs du site Web.

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.

Quand devez-vous contacter le support CURIAWEB ? #

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:

• domaine ou application concerné
• 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
• message d'erreur complet
• 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

Consigne de sécurité : 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.

Résumé #

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 commande introuvable, Aucun fichier ou dossier de ce nom ou Accès refusé 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.