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.

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. Im Labor erschienen dort zwei Meldungen, je nach Zustand:

• „Ein geplantes Ereignis ist überfällig“: Ein Ereignis sollte vor mehr als fünf Minuten laufen und steht noch aus. 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, im Labor „cURL error 7: Failed to connect to 127.0.0.1:21540 after 0 ms: Could not connect to server“.

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

wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence

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:

wp cron test

Im Labor lautete das Ergebnis „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.

Verifizieren: 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 dieselben Informationen im Backend. Stand 30.09.2026 ist Version 1.21.2 aktuell, laut Plugin-Seite ab WordPress 6.6 und PHP 7.4.

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

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

wp cron event run --due-now

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.

Verifizieren: 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. Kurz zusammengefasst:

wp config set DISABLE_WP_CRON true --raw

*/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 Labor 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.

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

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.

Tragen Sie die Prüfung stündlich in die Crontab ein. 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. 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 spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein und sichert die Website wöchentlich auf externen Speicher.

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

Testumfang

Getestet in einer Laborinstanz mit WordPress 7.1.2, PHP 8.4 und WP-CLI 2.12.0: wp cron event list, wp cron test mit fehlgeschlagenem Loopback und mit DISABLE_WP_CRON, Meldungen des Website-Zustands für überfällige und fehlgeschlagene Ereignisse, WP Crontrol 1.21.2 mit deutscher Übersetzung, wp cron event run --due-now, doing_cron-Transient und die Prüfung auf überfällige Ereignisse mit Exit-Codes. Nicht getestet: der Server-Cronjob über einen längeren Zeitraum und der Mailversand über cron.

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.

Weiterführende Anleitungen und Quellen

• WP-Cron durch echten System-Cron ersetzen
• Uptime-Überwachung für WordPress
• Healthchecks: Cronjobs und Backups überwachen
• WordPress Plugin Handbook: Cron
• WP-CLI: wp cron
• WP Crontrol auf wordpress.org