WP-Cron ist kein Uhrwerk: Warum geplante WordPress-Jobs zu spät laufen können

Ein Beitrag ist für 08:00 Uhr geplant. Um 08:17 Uhr steht er immer noch auf „geplant“. Das Backup sollte nachts laufen, die Shop-Automation hängt hinterher und ein Plugin meldet plötzlich einen verpassten Termin.

Dann kommt schnell der Satz: „Aber der Cronjob ist doch eingerichtet.“

Bei WordPress ist genau das die Stelle, an der Begriffe irreführend werden können. WP-Cron ist kein dauerhaft laufender System-Cron. Standardmäßig prüft WordPress bei Seitenaufrufen, ob geplante Aufgaben fällig sind. Wenn zur vorgesehenen Zeit niemand die Website aufruft, kann ein Event erst beim nächsten passenden Aufruf angestoßen werden.

Für eine kleine Inhaltsseite ist das oft völlig ausreichend. Für Shops, Memberships, Newsletter, Importe, Backups oder zeitkritische Veröffentlichungen sollte man daraus aber keine Garantie ableiten.

Was WP-Cron tatsächlich macht

WordPress nutzt WP-Cron für zeitbasierte Aufgaben. Dazu gehören Funktionen des Core wie Update-Prüfungen und geplante Beiträge; Plugins hängen häufig eigene Jobs an dasselbe System.

Der entscheidende Unterschied zu einem klassischen System-Scheduler: WP-Cron läuft nicht kontinuierlich im Hintergrund. Bei einem Seitenaufruf wird geprüft, welche Events fällig sind. WordPress beschreibt selbst das Beispiel, dass ein für 14:00 Uhr geplantes Event erst um 17:00 Uhr laufen kann, wenn bis dahin kein Seitenaufruf stattfindet.

Das bedeutet nicht, dass WP-Cron „kaputt“ ist. Es bedeutet, dass sein Ausführungsmodell verstanden und zum Einsatzzweck passend betrieben werden muss.

Wo daraus ein echtes Betriebsproblem wird

1. Niedriger oder unregelmäßiger Traffic

Eine Unternehmensseite kann nachts praktisch keine Aufrufe haben. Ein Job, der um 03:00 Uhr fällig wird, hat dann möglicherweise keinen natürlichen Trigger.

2. Zeitkritische Prozesse

„Irgendwann nach 08:00 Uhr“ ist etwas anderes als „um 08:00 Uhr“. Geplante Kampagnen, Produktfreigaben, Datenimporte oder externe Synchronisationen können von verlässlichen Zeitfenstern abhängen.

3. Cron wird bewusst deaktiviert – ohne Ersatz

DISABLE_WP_CRON kann sinnvoll sein, wenn ein echter System-Scheduler übernimmt. Problematisch wird es, wenn die Konstante nach einer Migration, Performance-Optimierung oder Hosting-Änderung bestehen bleibt, aber der externe Trigger fehlt.

4. Loopback- oder HTTP-Probleme

WP-Cron muss sich selbst anstoßen können. Authentifizierung vor der Website, Firewall-Regeln, DNS-Probleme oder andere Infrastrukturänderungen können diesen Mechanismus stören. WP-CLI kann den Spawn-Mechanismus gezielt testen.

5. Ein Plugin hinterlässt alte oder überfällige Events

Plugins können eigene Hooks registrieren. Nach Updates, Deaktivierungen oder schlecht implementierten Änderungen können verwaiste oder auffällig häufige Events zurückbleiben. WordPress Site Health prüft ausdrücklich, ob geplante Events wie vorgesehen laufen und weist auch auf mögliche verwaiste Events hin.

Der sinnvollere Audit: Nicht „Ist Cron aktiv?“, sondern „Laufen die wichtigen Jobs?“

Ein brauchbarer WordPress-Check beginnt nicht bei einer einzelnen Konstante in wp-config.php. Er beginnt bei den Geschäftsprozessen.

Fragen Sie zuerst:

• Welche Funktionen hängen überhaupt von WP-Cron ab?
• Welche davon dürfen Minuten oder Stunden verspätet laufen?
• Welche Jobs sind geschäftskritisch?
• Welche Plugins planen eigene Events?
• Wer merkt, wenn ein Event wiederholt ausfällt?
• Gibt es einen externen Scheduler – und wird dessen Erfolg überwacht?

Erst danach lohnt der Blick in die Technik.

Fünf konkrete technische Checks

1. Spawn-System testen

Mit WP-CLI lässt sich prüfen, ob das WP-Cron-Spawning grundsätzlich funktioniert:

wp cron test

Der Befehl prüft unter anderem, ob WP-Cron deaktiviert wurde und ob der HTTP-Aufruf zum Starten von Cron erfolgreich ist.

Ein grünes Ergebnis ist nützlich, aber noch kein Beweis dafür, dass jeder einzelne Plugin-Job korrekt arbeitet.

2. Event-Liste ansehen

Mit:

wp cron event list

werden unter anderem Hook, nächste Ausführungszeit und Wiederholung angezeigt. Interessant sind besonders:

• Events, deren nächste Ausführung deutlich in der Vergangenheit liegt,
• unerwartet viele Instanzen desselben Hooks,
• Jobs mit extrem kurzen Intervallen,
• Hooks von Plugins, die gar nicht mehr verwendet werden,
• kritische Jobs, deren nächste Ausführung nicht zum erwarteten Prozess passt.

3. WordPress Site Health ernst nehmen

Site Health besitzt einen eigenen Test für geplante Events. Meldungen über verpasste oder fehlerhafte geplante Aufgaben sind kein kosmetischer Hinweis. Sie zeigen, dass ein Teil der Website-Automation nicht zuverlässig arbeitet.

4. Externen Scheduler verifizieren

Wenn WP-Cron deaktiviert wurde, muss klar dokumentiert sein, wodurch wp-cron.php oder die fälligen Events stattdessen ausgelöst werden. Das kann etwa ein Cronjob des Hosters oder ein anderer System-Scheduler sein.

Dabei reicht „steht im Hostingpanel“ nicht. Prüfen Sie:

• läuft der Task wirklich,
• mit welchem Intervall,
• unter welchem Nutzer,
• gegen welche URL oder welchen PHP-Pfad,
• was bei einem Fehler passiert,
• wo Logs oder Exit-Codes landen.

5. Das Ergebnis des Geschäftsprozesses beobachten

Cron-Monitoring sollte nicht nur sagen, dass ein Trigger ausgeführt wurde. Ein erfolgreicher Aufruf von wp-cron.php beweist nicht automatisch, dass ein nachgelagerter Export, Versand oder API-Sync erfolgreich war.

Für kritische Prozesse braucht es deshalb zusätzlich eine fachliche Kontrolle: Wurde der Feed aktualisiert? Ging die geplante Mail raus? Ist der Import angekommen? Wurde das Backup erzeugt und lässt es sich wiederherstellen?

Wann ein System-Cron sinnvoll ist

WordPress dokumentiert selbst den Wechsel zu einem System-Task-Scheduler für Aufgaben, die pünktlich laufen müssen. Typischerweise wird dabei der normale Page-Load-Trigger mit DISABLE_WP_CRON abgeschaltet und WP-Cron regelmäßig von außen angestoßen.

Das ist besonders sinnvoll, wenn:

• die Website wenig oder stark schwankenden Traffic hat,
• zeitkritische Jobs existieren,
• viele geplante Events anfallen,
• Hosting und Monitoring professionell betrieben werden,
• die Ausführung bewusst von Besuchertraffic entkoppelt werden soll.

Wichtig ist die Reihenfolge: erst den Ersatz einrichten und testen, dann den eingebauten Trigger deaktivieren. Sonst wird aus einer Performance-Optimierung sehr schnell ein stillgelegter Scheduler.

Was Website-Pflichtencheck dabei prüfen würde

Bei einem WordPress-Betriebscheck geht es nicht nur um Plugin-Versionen und sichtbare Fehler. Wir würden auch prüfen, welche geplanten Prozesse existieren, ob WP-Cron zuverlässig ausgelöst wird, ob Events überfällig oder auffällig dupliziert sind, ob ein externer Scheduler korrekt eingerichtet ist und wie kritische Jobs überwacht werden.

Dazu gehört der Zusammenhang zwischen Anwendung und Infrastruktur: Hosting, Loopback-Requests, wp-config.php, WP-CLI, Plugin-Hooks, Logs und das tatsächliche Ergebnis wichtiger Automationen.

Denn eine Website kann jeden Verfügbarkeitscheck bestehen und trotzdem jeden Morgen eine Stunde zu spät arbeiten.

Der kleine Test für heute

Öffnen Sie bei einer WordPress-Seite mit Wartungszugang einmal die geplanten Events und beantworten Sie drei Fragen:

1. Welcher Job ist für das Geschäft am wichtigsten?
2. Wann ist er zuletzt tatsächlich erfolgreich gelaufen?
3. Wer würde merken, wenn er morgen nicht läuft?

Wenn Frage zwei oder drei nur mit „müsste eigentlich“ beantwortet werden kann, ist das kein Grund zur Panik. Es ist ein sehr guter Kandidat für den nächsten technischen Wartungscheck.