WordPress Cronjob läuft nicht: Ursachen finden und zuverlässig beheben

Wenn der WordPress Cronjob nicht läuft, werden geplante Beiträge, automatische Aktualisierungen, E-Mails, Bereinigungen oder Aufgaben von Plugins möglicherweise verspätet oder gar nicht ausgeführt. In diesem Ratgeber erfährst Du, wie WP-Cron funktioniert, welche Ursachen häufig dahinterstecken und wie Du den Fehler systematisch eingrenzt, ohne vorschnell Dateien oder Datenbankeinträge zu verändern.

Passende WordPress Hilfe zum Thema

Was bedeutet WP-Cron in WordPress?

Achte im Bild auf die getrennten Prüfbereiche für Website-Zustand, geplante Ereignisse und Protokolle. Diese Trennung hilft Dir, den Auslöser eines Cronjobs von einem Fehler in der eigentlichen Aufgabe zu unterscheiden.

WordPress verwendet standardmäßig keinen klassischen Server-Cronjob für geplante Aufgaben. Stattdessen nutzt das System WP-Cron. Dabei handelt es sich um eine WordPress-interne Aufgabenplanung, die bei einem Seitenaufruf angestoßen werden kann. WordPress prüft, ob fällige Ereignisse vorhanden sind, und versucht anschließend, diese auszuführen.

Zu solchen Ereignissen gehören beispielsweise die Veröffentlichung eines geplanten Beitrags, automatische Updates, geplante Wartungsaufgaben, Cache-Bereinigungen oder Aufgaben von Plugins. WP-Cron ist deshalb kein einzelner Prozess, den Du einfach dauerhaft im Hintergrund startest. Es ist vielmehr eine Kombination aus gespeicherten Ereignissen und einem Auslöser, der diese Ereignisse verarbeitet.

Der Unterschied zwischen WP-Cron und einem echten Server-Cronjob ist wichtig:

• WP-Cron: wird typischerweise durch Seitenaufrufe ausgelöst und läuft innerhalb der WordPress-Umgebung.
• Server-Cronjob: wird vom Betriebssystem oder Hosting-Panel zu einem festgelegten Zeitpunkt gestartet.

Auf einer stark besuchten Website kann WP-Cron ausreichend regelmäßig angestoßen werden. Bei einer kleinen Website mit wenigen Zugriffen kann ein Ereignis dagegen lange warten. Zusätzlich können Sicherheits- oder Performance-Einstellungen die interne Ausführung verhindern.

Woran erkennst Du, dass der WordPress Cronjob nicht läuft?

Ein defekter WP-Cron fällt nicht immer sofort durch eine Fehlermeldung auf. Häufig erkennst Du das Problem an verspäteten oder ausbleibenden Aufgaben. Typische Hinweise sind:

• Geplante Beiträge bleiben im Status „Geplant“, obwohl der Veröffentlichungszeitpunkt erreicht ist.
• Ein Plugin führt geplante Synchronisierungen, Importe oder Exporte nicht aus.
• Automatische Plugin- oder Theme-Aktualisierungen starten nicht.
• Wiederkehrende E-Mails werden nicht oder mit deutlicher Verzögerung versendet.
• Temporäre Daten, Protokolle oder Datenbankeinträge werden nicht bereinigt.
• Ein Plugin zeigt fällige oder fehlgeschlagene Hintergrundaufgaben an.
• Im Website-Zustand von WordPress erscheint ein Hinweis auf geplante Ereignisse oder Loopback-Anfragen.

Bevor Du eine Änderung vornimmst, solltest Du prüfen, ob tatsächlich ein Ausführungsproblem vorliegt. Ein einzelnes verspätetes Ereignis kann auch durch eine hohe Serverlast, eine langsame externe Schnittstelle oder einen Fehler in einem Plugin verursacht werden. Entscheidend ist, ob mehrere unabhängige geplante Aufgaben betroffen sind.

Die wichtigsten Ursachen im Überblick

Wenn der WordPress Cronjob nicht läuft, kommen mehrere Ebenen infrage. Die Ursache kann in WordPress selbst, in einem Plugin, im Theme, in der Serverkonfiguration oder beim Hosting liegen. Eine strukturierte Prüfung spart Zeit und verhindert, dass Du nur Symptome behandelst.

Beobachtung	Mögliche Ursache	Erster sinnvoller Schritt
Geplante Beiträge bleiben liegen	WP-Cron wird nicht ausgelöst oder ist deaktiviert	WordPress-Einstellungen und Cron-Ereignisse prüfen
Nur ein Plugin ist betroffen	Plugin-Fehler oder falsche Plugin-Konfiguration	Plugin-Protokoll und geplante Aufgaben untersuchen
Aufgaben laufen nur bei Besuchern	Unregelmäßige Seitenaufrufe oder blockierte Cron-Anfragen	Loopback-Anfragen und Serverzugriff prüfen
Aufgaben laufen gar nicht	WP-Cron deaktiviert, REST- oder Loopback-Problem, Serverfehler	Konfiguration, Protokolle und Hosting prüfen
Aufgaben starten, brechen aber ab	Timeout, PHP-Fehler, Speichergrenze oder externe API	PHP- und WordPress-Fehlerprotokolle auswerten

Schritt-für-Schritt: WordPress Cronjob prüfen

1. Geplante Aufgabe konkret identifizieren

Beginne nicht mit einer pauschalen Änderung an der Website. Notiere zuerst, welche Aufgabe ausbleibt, zu welchem Zeitpunkt sie fällig war und welches Plugin oder welcher WordPress-Bereich dafür verantwortlich ist. Bei geplanten Beiträgen ist die Ursache möglicherweise eine andere als bei einem WooCommerce-Import oder einer externen Schnittstelle.

Prüfe außerdem, ob die Aufgabe wirklich geplant und nicht versehentlich deaktiviert wurde. Manche Plugins besitzen eigene Optionen für Hintergrundverarbeitung, Synchronisierung oder automatische Bereinigung. Eine deaktivierte Funktion sieht von außen oft wie ein defekter Cronjob aus.

2. Den Website-Zustand kontrollieren

WordPress stellt unter Werkzeuge > Website-Zustand technische Prüfungen bereit. Dort können unter anderem Loopback-Anfragen, geplante Ereignisse, REST-API-Probleme und kritische PHP-Fehler angezeigt werden.

Loopback-Anfragen sind besonders relevant, weil WordPress für bestimmte interne Vorgänge eine Anfrage an die eigene Website ausführt. Wenn der Server diese Anfrage blockiert, zu lange warten lässt oder mit einem Fehler beantwortet, können geplante Aufgaben ausfallen. Ein grüner Website-Zustand schließt allerdings nicht jede Cron-Ursache aus. Er ist ein wichtiger Hinweis, aber keine vollständige Diagnose.

3. Cron-Ereignisse mit einem geeigneten Werkzeug ansehen

Für die Analyse kann ein etabliertes Verwaltungswerkzeug für WP-Cron hilfreich sein. Solche Werkzeuge zeigen, welche Ereignisse vorhanden sind, wann sie zuletzt ausgeführt wurden und wann die nächste Ausführung geplant ist. Zusätzlich lassen sich häufig einzelne Ereignisse testweise auslösen.

Gehe dabei vorsichtig vor. Das manuelle Ausführen einer Aufgabe kann beispielsweise eine E-Mail versenden, einen Import starten oder eine externe Schnittstelle ansprechen. Nutze die Funktion zunächst nur bei einer Aufgabe, deren Wirkung Du kennst. Änderungen an wiederkehrenden Ereignissen solltest Du dokumentieren, damit Du den Ausgangszustand wiederherstellen kannst.

4. Prüfen, ob WP-Cron deaktiviert wurde

In der Datei wp-config.php kann WP-Cron mit der Konstante DISABLE_WP_CRON deaktiviert werden. Eine solche Einstellung kann sinnvoll sein, wenn stattdessen ein echter Server-Cronjob eingerichtet wurde. Sie verursacht jedoch Probleme, wenn kein alternativer Auslöser vorhanden ist.

Eine typische Konfiguration sieht sinngemäß so aus:

define( 'DISABLE_WP_CRON', true );

Wenn diese Einstellung aktiv ist, muss zuverlässig ein Server-Cronjob eingerichtet sein. Entferne die Konstante nicht blind auf einer produktiven Website. Es kann sein, dass der Hoster oder eine technische Betreuung den externen Cronjob bewusst eingerichtet hat. Prüfe zuerst, wie die Website betrieben wird und ob ein alternativer Mechanismus dokumentiert ist.

5. Blockierte Loopback- oder HTTP-Anfragen untersuchen

WordPress kann geplante Aufgaben über interne HTTP-Anfragen anstoßen. Sicherheitsplugins, Web Application Firewalls, HTTP-Authentifizierung, restriktive Serverregeln oder falsch konfigurierte DNS-Einstellungen können diese Anfragen blockieren.

Prüfe insbesondere:

• ob die Website intern über HTTPS erreichbar ist und das Zertifikat korrekt erkannt wird,
• ob eine Basic- oder Passwort-Authentifizierung die interne Anfrage schützt,
• ob Sicherheitsregeln Anfragen von der eigenen Server-IP ablehnen,
• ob Redirects zwischen HTTP und HTTPS in einer Schleife enden,
• ob DNS und Hostname auf dem Server korrekt aufgelöst werden,
• ob ein Firewall- oder Hosting-Filter interne Requests begrenzt.

Ein Zugriff im Browser beweist nicht automatisch, dass eine interne Anfrage funktioniert. Der Browser und der Server können unterschiedliche DNS-Auflösungen, Netzwerkwege oder Berechtigungen verwenden.

Server-Cronjob als zuverlässige Alternative

Bei Websites mit wenigen Zugriffen oder vielen zeitkritischen Aufgaben kann ein echter Server-Cronjob besser geeignet sein. Dabei wird WP-Cron nicht mehr zufällig durch Besucher ausgelöst, sondern in einem festen Intervall vom Server gestartet. Das verbessert die Planbarkeit, beseitigt aber nicht automatisch Fehler in Plugins oder externen Schnittstellen.

Das Prinzip besteht aus zwei Teilen:

1. Die automatische Ausführung von WP-Cron durch normale Seitenaufrufe wird deaktiviert.
2. Der Server ruft WordPress regelmäßig über einen passenden Cron-Befehl auf.

Je nach Hosting stehen dafür ein Hosting-Panel, eine Kommandozeile oder eine spezielle Verwaltung des Anbieters zur Verfügung. Die genaue Einrichtung hängt vom Server, der PHP-Version, dem Pfad zur WordPress-Installation und den verfügbaren Rechten ab.

Auf einem Server mit WP-CLI kann die Verarbeitung beispielsweise über einen passenden Befehl erfolgen. Dabei sollte der Befehl immer an die konkrete Umgebung angepasst und zunächst in einer kontrollierten Umgebung getestet werden. Ein ungeprüft übernommener Befehl kann auf dem falschen Pfad laufen, die falsche PHP-Version verwenden oder unerwartete Ausgaben erzeugen.

Wichtig ist außerdem die Wahl des Intervalls. Ein zu kurzes Intervall kann unnötige Serverlast erzeugen, während ein zu langes Intervall Aufgaben verzögert. Die passende Einstellung richtet sich nach der Anzahl, Dringlichkeit und Laufzeit der geplanten Aufgaben.

Typische Fehler und passende Lösungen

WP-Cron wurde deaktiviert, aber kein Server-Cronjob eingerichtet

Das ist eine der häufigsten Konstellationen. Die Website soll angeblich mit einem echten Cronjob arbeiten, tatsächlich wurde aber nur die interne Ausführung abgeschaltet. Die Lösung besteht darin, den externen Auslöser nachweisbar einzurichten oder WP-Cron wieder zu aktivieren. Vorher solltest Du prüfen, ob bereits fällige Ereignisse vorhanden sind.

Ein Plugin erzeugt fehlerhafte oder doppelte Ereignisse

Ein Plugin kann Cron-Ereignisse falsch registrieren, alte Ereignisse nicht entfernen oder bei jedem Seitenaufruf neue Einträge hinzufügen. Dadurch entstehen doppelte Ausführungen, unnötige Last oder eine ständig wachsende Liste geplanter Aufgaben.

Deaktiviere ein verdächtiges Plugin nicht ohne Vorbereitung, wenn es wichtige Daten verarbeitet. Erstelle ein aktuelles Backup, prüfe die Auswirkungen und untersuche zunächst die Ereignisse sowie das Plugin-Protokoll. Wenn mehrere Aufgaben desselben Plugins betroffen sind, liegt der Fehler wahrscheinlich eher in dessen Konfiguration oder Programmierung als im globalen WP-Cron.

Ein Cron-Ereignis läuft, aber der eigentliche Vorgang scheitert

Die Anzeige eines Cron-Ereignisses bedeutet nicht, dass die Aufgabe erfolgreich abgeschlossen wurde. Ein Import kann gestartet werden und anschließend an einer API-Antwort, einem Berechtigungsfehler, einem PHP-Timeout oder einem ungültigen Datensatz scheitern.

Prüfe deshalb, ob das Ereignis einen Fehler protokolliert. Ergänzend können WordPress- und PHP-Logs Hinweise liefern. Aktivierte Debug-Protokollierung sollte auf einer produktiven Website sorgfältig gehandhabt werden, weil Fehlermeldungen interne Informationen enthalten können. Protokolle gehören nicht dauerhaft öffentlich erreichbar in das Webverzeichnis.

Die Website hat zu wenig echte Seitenaufrufe

Wenn WP-Cron durch Seitenaufrufe ausgelöst wird, kann eine wenig besuchte Website fällige Aufgaben verspätet bearbeiten. Das ist kein klassischer Programmfehler, sondern eine Eigenschaft des Standardmechanismus. Ein Server-Cronjob kann hier für eine gleichmäßigere Ausführung sorgen.

Cache oder Sicherheitsplugin verhindert die Ausführung

Cache-Systeme sind normalerweise nicht allein für ausgebliebene Cronjobs verantwortlich, können aber interne Anfragen, dynamische Endpunkte oder bestimmte Cookies beeinflussen. Sicherheitsplugins können außerdem REST-Anfragen, XML-RPC, Loopback-Anfragen oder administrative Endpunkte einschränken.

Verändere nicht mehrere Sicherheitsregeln gleichzeitig. Teste eine Anpassung nach der anderen, dokumentiere die Änderung und prüfe anschließend, ob die Aufgabe tatsächlich erfolgreich verarbeitet wurde. Eine pauschale Deaktivierung aller Schutzfunktionen ist keine nachhaltige Fehlerbehebung.

Technische Prüfung mit Logs und Debugging

Wenn die bisherigen Schritte keine eindeutige Ursache ergeben, solltest Du die beteiligten Ebenen voneinander trennen. Zuerst wird geprüft, ob der Cron-Auslöser startet. Danach folgt die Frage, ob WordPress das Ereignis verarbeitet. Abschließend wird untersucht, ob die Aufgabe selbst erfolgreich beendet wird.

Prüfebene	Frage	Mögliche Hinweise
Auslöser	Wird WP-Cron oder der Server-Cronjob gestartet?	Server-Logs, Cron-Protokoll, WP-CLI-Ausgabe
WordPress	Ist das Ereignis registriert und fällig?	Cron-Verwaltung, Website-Zustand, Plugin-Einstellungen
PHP	Bricht der Code während der Ausführung ab?	Fatal Error, Speicherfehler, Timeout
Externe Dienste	Antwortet eine API oder ein Mailserver?	HTTP-Status, Authentifizierung, Zeitüberschreitung
Datenbank	Kann die Aufgabe lesen oder schreiben?	SQL-Fehler, gesperrte Tabellen, fehlende Berechtigungen

Bei der Fehlersuche ist ein möglichst kleiner Test sinnvoll. Wähle eine überschaubare Aufgabe, führe sie kontrolliert aus und beobachte Logs, Serverlast und Ergebnis. So lässt sich besser unterscheiden, ob das Problem beim Zeitplan oder bei der eigentlichen Funktion liegt.

WordPress Cronjob und Performance

Ein Cronjob kann die Ladezeit einer normalen Anfrage beeinflussen, wenn eine umfangreiche Aufgabe während eines Seitenaufrufs startet. Besonders große Datenimporte, Bildverarbeitung, Datenbankbereinigungen oder externe Synchronisierungen können lange laufen.

Wenn sich solche Aufgaben überlappen, steigt die Serverlast. Mögliche Folgen sind verzögerte Admin-Seiten, Timeouts oder konkurrierende Änderungen an denselben Daten. Bei umfangreichen Websites sollten Aufgaben deshalb in kleinere Arbeitsschritte aufgeteilt werden. Ein Plugin kann beispielsweise pro Lauf nur eine begrenzte Anzahl Datensätze verarbeiten und den nächsten Abschnitt für einen späteren Lauf vormerken.

Eine technische Optimierung sollte nicht nur die Häufigkeit des Cronjobs verändern. Prüfe auch die Laufzeit der Aufgabe, die Größe einzelner Datenpakete, die Zahl externer Anfragen und die Möglichkeit, bereits verarbeitete Elemente eindeutig zu markieren. So werden doppelte Verarbeitung und unnötige Wiederholungen vermieden.

Praxisbeispiel: Geplanter Beitrag wird nicht veröffentlicht

Angenommen, ein geplanter Beitrag bleibt nach dem vorgesehenen Zeitpunkt im Status „Geplant“. Zuerst prüfst Du, ob nur dieser Beitrag betroffen ist oder auch andere geplante Aufgaben. Anschließend kontrollierst Du den Website-Zustand und siehst in einer Cron-Verwaltung nach, ob ein Ereignis für die Beitragsplanung fällig ist.

Ist WP-Cron deaktiviert, ohne dass ein Server-Cronjob vorhanden ist, liegt die Ursache wahrscheinlich dort. Ist das Ereignis vorhanden und wird regelmäßig verarbeitet, kann ein anderer Fehler vorliegen. Dann kommen beispielsweise ein PHP-Fehler, ein Plugin-Konflikt oder eine beschädigte geplante Aufgabe infrage.

Der nächste Test sollte kontrolliert erfolgen: Sichere zunächst die Website, prüfe die Protokolle und löse die konkrete Aufgabe nur dann manuell aus, wenn ihre Wirkung bekannt ist. Wenn die manuelle Ausführung funktioniert, aber automatische Läufe ausbleiben, liegt der Schwerpunkt der Analyse beim Auslöser. Wenn auch die manuelle Ausführung scheitert, muss die Funktion selbst untersucht werden.

Was Du vor Änderungen beachten solltest

• Erstelle vor Eingriffen in Konfiguration, Datenbank oder Plugins ein aktuelles Backup.
• Teste riskantere Anpassungen möglichst zuerst in einer Staging-Umgebung.
• Ändere nicht gleichzeitig Cron-Konfiguration, Sicherheitsregeln und Plugin-Versionen.
• Dokumentiere aktive Konstanten, Server-Cronjobs und relevante Plugin-Einstellungen.
• Prüfe nach einer Änderung nicht nur den Zeitplan, sondern das tatsächliche Ergebnis der Aufgabe.
• Entferne keine Cron-Ereignisse, wenn Du ihre Funktion oder Herkunft nicht kennst.

Besondere Vorsicht ist bei WooCommerce, Newsletter-Versand, Bestandsabgleichen und externen Schnittstellen nötig. Ein manuell gestarteter Vorgang kann reale Bestellungen, Nachrichten oder Datenübertragungen auslösen. Bei sicherheits- oder geschäftskritischen Aufgaben sollte die Analyse nachvollziehbar protokolliert werden.

FAQ

Warum läuft mein WordPress Cronjob nur manchmal?

WP-Cron wird standardmäßig häufig durch Seitenaufrufe ausgelöst. Bei unregelmäßigem Traffic kann eine Aufgabe deshalb verspätet starten. Zusätzlich können einzelne Ausführungen durch Serverlast, Timeouts, Sicherheitsregeln oder Plugin-Fehler scheitern. Ein echter Server-Cronjob kann die zeitliche Auslösung zuverlässiger machen.

Ist WP-Cron dasselbe wie ein Cronjob auf dem Server?

Nein. WP-Cron ist eine WordPress-interne Aufgabenplanung, die typischerweise bei einer Anfrage an die Website angestoßen wird. Ein Server-Cronjob wird dagegen von der Serverumgebung nach einem Zeitplan gestartet. Beide Mechanismen können zusammenwirken, sollten aber nicht unkoordiniert parallel dieselben Aufgaben ausführen.

Wie kann ich feststellen, ob WP-Cron deaktiviert ist?

Prüfe die WordPress-Konfiguration auf die Konstante DISABLE_WP_CRON und untersuche die vorhandenen Cron-Ereignisse. Auch der Website-Zustand und die Serverkonfiguration können Hinweise liefern. Wenn Du keinen Zugriff auf die Serverdateien hast, kann die technische Betreuung oder der Hosting-Support klären, ob ein externer Cronjob aktiv ist.

Kann ein Plugin den WordPress Cronjob blockieren?

Ja. Ein Plugin kann Fehler bei der Registrierung oder Verarbeitung von Aufgaben verursachen. Sicherheitsplugins können außerdem interne Anfragen einschränken. Wenn nur Aufgaben eines bestimmten Plugins betroffen sind, solltest Du dessen Einstellungen, Protokolle und Kompatibilität prüfen, statt den gesamten WP-Cron pauschal zu verändern.

Warum wird ein Cron-Ereignis als fällig angezeigt, aber nicht erledigt?

Das kann bedeuten, dass der Auslöser nicht startet, die Verarbeitung abbricht oder die Aufgabe nach einem Fehler erneut fällig bleibt. Prüfe Logs, PHP-Fehler, die Serverlast und die konkrete Funktion des Plugins. Ein fälliger Eintrag allein sagt noch nicht aus, an welcher Stelle die Ausführung scheitert.

Sollte ich WP-Cron immer durch einen Server-Cronjob ersetzen?

Nicht zwingend. Für kleine Websites mit unkritischen Aufgaben kann der Standardmechanismus ausreichen. Ein Server-Cronjob ist besonders interessant, wenn die Website wenig besucht wird, Aufgaben zeitnah ausgeführt werden müssen oder umfangreiche Hintergrundprozesse regelmäßig anfallen. Die Entscheidung sollte zur Hosting-Umgebung und zum tatsächlichen Aufgabenprofil passen.

Kann ich fällige Cronjobs einfach löschen?

Das solltest Du nur tun, wenn Du die Herkunft und Funktion des Ereignisses kennst. Das Löschen kann eine geplante Bereinigung, Synchronisierung oder andere Plugin-Funktion dauerhaft unterbrechen. Sichere vorher die Website und dokumentiere, welche Änderung Du vorgenommen hast.

Wann brauche ich professionelle Unterstützung?

Unterstützung ist sinnvoll, wenn mehrere Aufgaben betroffen sind, Logs auf Server- oder PHP-Fehler hinweisen, externe Schnittstellen beteiligt sind oder Änderungen an produktiven Bestellungen, E-Mails und Daten möglich wären. Auch bei fehlendem Serverzugriff kann eine gezielte technische Prüfung schneller sein als wiederholtes Ausprobieren.

Fazit

Wenn der WordPress Cronjob nicht läuft, solltest Du zuerst die konkrete betroffene Aufgabe identifizieren und anschließend Auslöser, WordPress-Ereignis und eigentliche Verarbeitung getrennt prüfen. Häufige Ursachen sind ein deaktivierter WP-Cron ohne Ersatz, fehlende Seitenaufrufe, blockierte Loopback-Anfragen, Plugin-Fehler oder technische Probleme bei PHP, Datenbank und externen Schnittstellen.

Arbeite mit Backups, Protokollen und kleinen kontrollierten Tests. Bei wenig besuchten Websites oder zeitkritischen Aufgaben kann ein sauber eingerichteter Server-Cronjob die bessere Grundlage sein. Entscheidend ist nicht nur, dass ein Ereignis gestartet wird, sondern dass die geplante Aufgabe vollständig und ohne unerwartete Nebenwirkungen abgeschlossen wird.