--- title: "Cronjobs in WordPress überwachen: Geplante Aufgaben prüfen und Fehler bei WP-Cron beheben" date: 2026-09-30T22:09:55+02:00 modified: 2026-11-08T21:17:14+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-cronjobs-ueberwachen-wp-cron-fehler-beheben keywords: - WordPress - WP-Cron - WP-CLI - Monitoring - Wartung reading_time: 9 --- # Cronjobs in WordPress überwachen: Geplante Aufgaben prüfen und Fehler bei WP-Cron beheben Viele Aufgaben in WordPress laufen zeitgesteuert: geplante Beiträge veröffentlichen, nach Updates suchen, automatische Updates einspielen, abgelaufene Daten löschen, Backups von Plugins starten. All das steuert WP-Cron, ein Zeitplaner, der nicht vom Betriebssystem, sondern von Seitenaufrufen angestoßen wird. Fällt er aus, bleibt das zunächst unsichtbar. Erst Wochen später fällt auf, dass ein Beitrag nicht erschienen ist, das Backup-Plugin seit Tagen nicht gesichert hat oder Sicherheitsupdates liegen geblieben sind. Diese Anleitung zeigt, wie Sie geplante Aufgaben sichtbar machen, die typischen Ursachen für Ausfälle erkennen und beheben und WP-Cron dauerhaft überwachen. Alle Befehle und Meldungen stammen aus einem Test mit WordPress 7.1.2 und WP-CLI. **Kurzfassung:** Prüfen Sie zuerst unter **Werkzeuge → Website-Zustand**, ob WordPress ein überfälliges oder fehlgeschlagenes Ereignis meldet. `wp cron event list` und `wp cron test` zeigen, welche Aufgaben anstehen und ob WordPress sich selbst aufrufen kann. Die häufigste Ursache für Ausfälle ist eine gescheiterte Loopback-Anfrage, etwa durch Firewall, Passwortschutz oder DNS. Zuverlässiger als WP-Cron ist ein Cronjob des Servers mit WP-CLI. Eine kleine Prüfung auf Ereignisse, die seit über einer Stunde überfällig sind, meldet künftige Ausfälle automatisch. ## Voraussetzungen - [ ] **WordPress:** eine aktuelle Version, getestet mit WordPress 7.1.2 auf PHP 8.4. - [ ] **Rolle:** Administrator im WordPress-Backend. - [ ] **Zugang:** SSH mit WP-CLI für die Schritte 2, 5 und 6. Getestet mit WP-CLI 2.12.0. Ohne SSH nutzen Sie das Plugin WP Crontrol aus Schritt 3. - [ ] **Server-Cron:** für Schritt 5 die Möglichkeit, Cronjobs anzulegen, per `crontab` oder in der Verwaltungsoberfläche Ihres Hosters. - [ ] **Backup:** eine aktuelle Sicherung von Dateien und Datenbank, bevor Sie Ereignisse löschen oder `wp-config.php` ändern. ## Schritt 1: Den Website-Zustand prüfen WordPress prüft den Zeitplaner selbst. Öffnen Sie **Werkzeuge → Website-Zustand**. Dort erscheinen je nach Zustand zwei Meldungen: - **„Ein geplantes Ereignis ist überfällig“:** Ein Ereignis ist fällig und steht noch aus. Bei aktivem WP-Cron gilt es bereits ab Fälligkeit als verspätet; bei abgeschaltetem WP-Cron liegt diese Grenze bei 15 Minuten. WordPress nennt den Hook, im Test `recovery_mode_clean_expired_keys`. - **„Ein geplantes Ereignis ist fehlgeschlagen“:** Ein Ereignis ist deutlich überfällig. Bei aktivem WP-Cron liegt die Grenze bei fünf Minuten, bei abgeschaltetem WP-Cron (`DISABLE_WP_CRON`) bei einer Stunde. Das steht so im Quelltext der Klasse `WP_Site_Health`. Wichtig ist eine dritte, als kritisch markierte Meldung: Die Website konnte eine Loopback-Anfrage nicht abschließen. WordPress startet WP-Cron, indem es sich selbst per HTTP aufruft. Gelingt das nicht, laufen geplante Aufgaben nur noch, wenn jemand anders sie anstößt. Der Website-Zustand nennt die genaue Fehlermeldung, zum Beispiel „cURL error 7: Failed to connect to 127.0.0.1:21540 after 0 ms: Could not connect to server“. > **Prüfen:** Sie wissen, ob der Website-Zustand eine der drei Meldungen zeigt, und haben den genannten Hook und die Fehlermeldung notiert. ## Schritt 2: Geplante Ereignisse mit WP-CLI ansehen WP-CLI zeigt alle Ereignisse mit Fälligkeit und Wiederholung: ```bash $ wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence ``` ```plaintext hook next_run_gmt next_run_relative recurrence recovery_mode_clean_expired_keys 2026-09-30 20:04:23 now 1 day wp_privacy_delete_old_export_files 2026-09-30 20:04:23 now 1 hour wp_version_check 2026-09-30 21:04:22 59 minutes 29 seconds 12 hours wp_update_plugins 2026-09-30 21:34:22 1 hour 29 minutes 12 hours wp_site_health_scheduled_check 2026-10-01 20:04:23 23 hours 59 minutes 1 week ``` Steht bei vielen Ereignissen dauerhaft `now`, laufen sie nicht. Einzelne `now`-Einträge direkt nach der Installation oder nach langer Ruhe sind normal, sie werden beim nächsten Durchlauf abgearbeitet. Danach testen Sie, ob WordPress WP-Cron starten kann: ```bash $ wp cron test ``` Ist der Selbstaufruf blockiert, lautet das Ergebnis zum Beispiel „Error: WP-Cron spawn failed with error: cURL error 7: Failed to connect to 127.0.0.1:21540 after 0 ms: Could not connect to server“. Ist WP-Cron absichtlich abgeschaltet, meldet der Befehl „Error: The DISABLE_WP_CRON constant is set to true. WP-Cron spawning is disabled.“ Das ist dann kein Fehler, sofern ein Server-Cronjob die Aufgabe übernimmt. > **Prüfen:** `wp cron test` meldet einen Erfolg oder eine konkrete Fehlermeldung, und in der Ereignisliste sehen Sie, welche Hooks überfällig sind. ## Schritt 3: Ereignisse im Backend mit WP Crontrol prüfen Ohne SSH-Zugang zeigt das Plugin [WP Crontrol](https://wordpress.org/plugins/wp-crontrol/) dieselben Informationen im Backend. Die Version 1.21.2 setzt laut Plugin-Seite mindestens WordPress 6.6 und PHP 7.4 voraus. 1. Installieren und aktivieren Sie das Plugin unter **Plugins → Plugin hinzufügen**. 2. Öffnen Sie **Werkzeuge → Cron-Ereignisse**. Die Tabelle zeigt die Spalten „Hook“, „Nächste Ausführung (UTC)“, „Zeitplan“ und „Aktion“. 3. Überfällige Ereignisse erkennen Sie an Angaben wie „vor 2 Stunden“ in der Spalte „Nächste Ausführung (UTC)“. Kann WordPress WP-Cron nicht starten, zeigt WP Crontrol oben einen Hinweis, dass beim Aufruf des WP-Cron-Systems ein Problem auftrat. Darunter steht die technische Ursache. Die Filter „Ereignisse ohne Aktionen“ und „Eigene Ereignisse“ helfen beim Aufräumen. Ein Ereignis ohne Aktion stammt meist von einem gelöschten Plugin. Im Test zeigte die Spalte „Aktion“ für ein solches Ereignis „Keine“. Solche Ereignisse löschen Sie über den Link „Löschen“ in der Zeile. Ereignisse des WordPress-Cores kennzeichnet das Plugin mit „Dies ist ein Ereignis des WordPress-Cores und kann nicht entfernt werden“. > **Prüfen:** Unter **Werkzeuge → Cron-Ereignisse** erscheint kein Hinweis auf ein Problem beim Aufruf, und es gibt keine Ereignisse, die seit Stunden überfällig sind. ## Schritt 4: Typische Ursachen beheben Die meisten Ausfälle gehen auf eine dieser Ursachen zurück: - **Loopback blockiert:** Der Server erreicht die eigene Domain nicht, etwa weil DNS intern auf eine falsche Adresse zeigt, eine Firewall ausgehende Verbindungen auf Port 443 sperrt oder ein vorgeschalteter Passwortschutz (HTTP-Authentifizierung) die Anfrage an `wp-cron.php` abweist. Testen Sie vom Server aus mit `curl -I https://www.ihre-firma.de/wp-cron.php`. Ein Passwortschutz vor der ganzen Website muss `wp-cron.php` ausnehmen oder durch einen Server-Cronjob ersetzt werden. - **Zu wenig Besucher:** WP-Cron läuft nur bei Seitenaufrufen. Eine Website mit wenigen Besuchern in der Nacht führt nächtliche Aufgaben erst morgens aus. - **Seiten-Cache:** Liefert ein Cache jede Seite aus, ohne WordPress zu starten, wird WP-Cron nicht angestoßen. - **Hängende Sperre:** Während eines Durchlaufs setzt WordPress den Transient `doing_cron`. Ein neuer Durchlauf startet erst, wenn die Sperre abgelaufen ist, standardmäßig nach 60 Sekunden (`WP_CRON_LOCK_TIMEOUT`). Prüfen können Sie sie mit `wp transient get doing_cron`. - **Abgebrochene Aufgaben:** Ein Ereignis, das in einen PHP-Fehler oder ein Zeitlimit läuft, blockiert die folgenden Ereignisse desselben Durchlaufs. Das PHP-Fehlerprotokoll nennt den Hook. Überfällige Ereignisse holen Sie nach der Korrektur von Hand nach: ```bash $ wp cron event run --due-now ``` ```plaintext Executed the cron event 'recovery_mode_clean_expired_keys' in 0.016s. Executed the cron event 'wp_privacy_delete_old_export_files' in 0.01s. Executed the cron event 'wp_privacy_personal_data_cleanup_requests' in 0.012s. Executed the cron event 'wp_delete_temp_updater_backups' in 0.04s. Success: Executed a total of 4 cron events. ``` > **Prüfen:** `wp cron test` meldet keinen Fehler mehr, und `wp cron event list` zeigt bei keinem Ereignis mehr dauerhaft `now`. ## Schritt 5: WP-Cron durch einen Server-Cronjob ergänzen Die zuverlässigste Lösung für Unternehmenswebsites ist ein Cronjob des Betriebssystems, der fällige Ereignisse regelmäßig mit WP-CLI ausführt. Dann hängt nichts mehr von Besuchern, Cache oder Loopback ab. Die Einrichtung mit allen Details beschreibt [WP-Cron durch echten System-Cron ersetzen](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten). Kurz zusammengefasst: ```bash $ wp config set DISABLE_WP_CRON true --raw ``` ```plaintext */5 * * * * cd /var/www/html && wp cron event run --due-now --quiet ``` Führen Sie den Cronjob als der Benutzer aus, dem die WordPress-Dateien gehören, nicht als root. Passen Sie den Pfad an Ihre Installation an. Achtung: Mit `DISABLE_WP_CRON` ohne funktionierenden Cronjob läuft gar nichts mehr. Im Test meldete der Website-Zustand nach dem Setzen der Konstante bei einem zwei Stunden alten Ereignis „Ein geplantes Ereignis ist fehlgeschlagen“, bis `wp cron event run --due-now` es ausführte. > **Prüfen:** Nach fünf bis zehn Minuten zeigt `wp cron event list` keine überfälligen Ereignisse, und der Website-Zustand meldet keine Probleme mit geplanten Ereignissen. ## Schritt 6: Überfällige Ereignisse automatisch melden Damit ein Ausfall nicht wieder wochenlang unbemerkt bleibt, prüfen Sie regelmäßig, ob Ereignisse seit mehr als einer Stunde überfällig sind. Der folgende WP-CLI-Aufruf gibt in diesem Fall die betroffenen Hooks aus und endet mit Exit-Code 1, sonst bleibt er stumm: ```bash $ wp eval '$grenze = time() - HOUR_IN_SECONDS; $alt = []; foreach ( _get_cron_array() as $t => $hooks ) { if ( $t < $grenze ) { foreach ( $hooks as $hook => $x ) { $alt[] = $hook . " seit " . gmdate( "Y-m-d H:i", $t ) . " UTC"; } } } if ( $alt ) { echo "UEBERFAELLIG: " . implode( ", ", $alt ) . "\n"; exit( 1 ); }' ``` Im Test mit einem absichtlich zwei Stunden alten Ereignis lautete die Ausgabe „UEBERFAELLIG: s_edv_verwaist seit 2026-09-30 18:06 UTC“ mit Exit-Code 1. Nach dem Ausführen des Ereignisses blieb die Ausgabe leer, Exit-Code 0. `_get_cron_array()` ist eine interne WordPress-Funktion. Sie ist seit Jahren stabil, prüfen Sie den Aufruf nach größeren Updates trotzdem kurz. Speichern Sie den Aufruf als Shell-Skript und lassen Sie dieses stündlich durch die Crontab starten. Prozentzeichen in den Datumsformaten dürfen nicht unverändert direkt in der Crontab stehen, weil cron sie als Zeilenumbrüche behandelt. Mit gesetztem `MAILTO` verschickt `cron` eine E-Mail, sobald eine Ausgabe entsteht. Alternativ melden Sie den Erfolg an einen Dienst wie Healthchecks, der sich meldet, wenn die Rückmeldung ausbleibt, siehe [Healthchecks: Cronjobs und Backups überwachen](https://s-edv.com/anleitungen/healthchecks-synology-cronjob-backup-monitoring). Das deckt auch den Fall ab, dass der Server-Cronjob selbst ausfällt. Geplante Aufgaben sind Teil der laufenden Pflege: Hängen sie, bleiben Updates und Backups liegen. Wer diese Kontrolle nicht selbst im Kalender halten möchte, kann Updates und Backups abgeben: Die [WordPress-Wartung von wordpressupdate.de](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=86) spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein und sichert die Website wöchentlich auf externen Speicher. > **Prüfen:** Die Prüfung liefert im Normalbetrieb keine Ausgabe und Exit-Code 0. Mit einem absichtlich angelegten, überfälligen Testereignis kommt eine Meldung an. ## Typische Fehler **„cURL error 7: Failed to connect …“** Der Server erreicht die eigene Adresse nicht. DNS, Firewall und `/etc/hosts` prüfen oder auf einen Server-Cronjob umstellen. **„cURL error 28“ bei `wp cron test`** Zeitüberschreitung beim Selbstaufruf, oft durch überlasteten Server oder blockierte Anfragen. **„The DISABLE_WP_CRON constant is set to true“** WP-Cron ist abgeschaltet. Das ist korrekt, wenn ein Server-Cronjob läuft, sonst Konstante entfernen. **„Error: Invalid cron event …“** Der Hook existiert nicht (mehr). Im Test erschien die Meldung, nachdem das Ereignis bereits durch `--due-now` ausgeführt und entfernt war. **Server-Cronjob läuft als root** WP-CLI verweigert den Start ohne `--allow-root`, und Dateien gehören danach root. Cronjob als Webserver-Benutzer anlegen. **Beiträge erscheinen trotz funktionierendem Cron nicht** Zeitzone unter **Einstellungen → Allgemein** prüfen. `wp cron event list` zeigt Zeiten in UTC. ## Häufige Fragen ### Belastet ein Cronjob alle fünf Minuten den Server? In der Regel nicht. Ohne fällige Ereignisse lädt der Aufruf WordPress, stellt fest, dass nichts ansteht, und endet. ### Darf ich unbekannte Ereignisse löschen? Nur solche ohne Aktion, die also zu keinem aktiven Plugin gehören. Ereignisse aktiver Plugins werden meist neu angelegt oder fehlen dem Plugin danach. Legen Sie vorher ein Backup an. ### Reicht die Uptime-Überwachung nicht aus? Nein. Die Website kann erreichbar sein, während geplante Aufgaben seit Tagen stehen. Beide Prüfungen ergänzen sich, siehe [Uptime-Überwachung für WordPress](https://s-edv.com/anleitungen/wordpress-uptime-ueberwachung-ausfaelle-frueh-erkennen). ## Fazit Ausfälle von WP-Cron bleiben lange unsichtbar, lassen sich aber mit Bordmitteln erkennen: Website-Zustand, `wp cron event list`, `wp cron test` und bei Bedarf WP Crontrol. Die häufigste Ursache ist ein gescheiterter Selbstaufruf, die robusteste Lösung ein Server-Cronjob mit WP-CLI. Eine stündliche Prüfung auf überfällige Ereignisse sorgt dafür, dass Sie den nächsten Ausfall selbst bemerken. Soll die technische Pflege mit Updates und Backups dauerhaft jemand übernehmen, finden Sie das bei der [WordPress-Wartung von Marcel Schönfelder](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=86). ## Weiterführende Anleitungen und Quellen - [WP-Cron durch echten System-Cron ersetzen](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten) - [Uptime-Überwachung für WordPress](https://s-edv.com/anleitungen/wordpress-uptime-ueberwachung-ausfaelle-frueh-erkennen) - [Healthchecks: Cronjobs und Backups überwachen](https://s-edv.com/anleitungen/healthchecks-synology-cronjob-backup-monitoring) - [WordPress Plugin Handbook: Cron](https://developer.wordpress.org/plugins/cron/) - [WP-CLI: wp cron](https://developer.wordpress.org/cli/commands/cron/) - [WP Crontrol auf wordpress.org](https://wordpress.org/plugins/wp-crontrol/)