WordPress Cron betreiben: Auslöser, Jobs und echte Ergebnisse

WP Cron ist eine Aufgabenliste mit Auslöser

WordPress verwendet geplante Aufgaben für viele Funktionen, die nicht bei jedem Besuch direkt erledigt werden sollen. Dazu gehören etwa Prüfungen auf Updates, geplante Veröffentlichungen und Aufgaben von Plugins. Die WordPress Dokumentation zu Cron erklärt den wichtigen Unterschied zum ständig vom System geplanten Ablauf: WP Cron wird im üblichen Betrieb durch Seitenaufrufe angestoßen. Bei wenig Besuch kann eine fällige Aufgabe deshalb später beginnen als der eingetragene Zeitpunkt vermuten lässt. Für Betreiber folgt daraus kein pauschaler Defekt, sondern eine Frage nach der nötigen Verlässlichkeit. Ein nächtlicher Export mit festem Termin braucht einen bewusster geplanten Auslöser als eine wenig zeitkritische interne Prüfung.

Beginnen Sie mit einer Liste der wichtigen Aufgaben. Notieren Sie Hook, Zweck, gewünschtes Intervall, erwartetes Ergebnis und zuständige Erweiterung. Eine lange technische Liste ist noch kein Betriebsplan. Ein unbekannter Hook kann zu einem Plugin gehören, das längst entfernt wurde, oder zu einem weiterhin wichtigen Dienst. Löschen Sie solche Einträge deshalb nicht auf Verdacht. Klären Sie deren Ursprung und Wirkung. Für die Abnahme brauchen Sie außerdem einen Erfolgshinweis: ein veröffentlichter Beitrag, eine neue Exportdatei oder ein aktualisierter Datenstand. Nur die Anwesenheit eines nächsten Termins beweist nicht, dass die Aufgabe in der vorherigen Runde tatsächlich ausgeführt wurde.

Den Auslöser zur Website passend wählen

Ein Systemjob kann den WordPress Aufgabenlauf in einem festgelegten Intervall anstoßen. Die WordPress Anleitung zur Verbindung mit dem Systemplaner beschreibt diese Umstellung und die Option DISABLE_WP_CRON. Diese Option beendet den normalen Seitenaufruf als Auslöser; sie ist deshalb kein alleiniger Schritt zur Verbesserung. Zuerst wird ein funktionierender Ersatz eingerichtet und geprüft. Erst dann wird der bisherige Auslöser bewusst abgelöst. Wenn beide Schritte vertauscht werden, kann die Website äußerlich normal wirken, während Hintergrundaufgaben still liegen bleiben. Der Bericht sollte daher den neuen Auslöser und dessen tatsächlich beobachteten Lauf zusammen nennen.

Ein geplanter HTTP Aufruf und ein direkter Aufruf über PHP oder WP CLI haben unterschiedliche Voraussetzungen. HTTP benutzt DNS, TLS, Weiterleitung und den Zugriffsschutz der Domain. Ein lokaler Aufruf benötigt passende Dateien, Rechte und Laufzeit. Wählen Sie den Weg nach den Möglichkeiten der eigenen Umgebung und dokumentieren Sie ihn. Ein geschützter Entwurf kann einen direkten lokalen Weg nutzen, ohne eine allgemeine Ausnahme für Besucher zu öffnen. Umgekehrt kann ein zulässiger HTTP Weg für ein einfaches Abo praktischer sein. Entscheidend ist, dass der tatsächliche Job unter seinen echten Bedingungen funktioniert und seine Fehler sichtbar werden. Eine einmalige manuelle Ausführung aus einer anderen Umgebung genügt dafür nicht.

Benutzer, Pfad und PHP gemeinsam prüfen

Ein Systemjob sollte unter dem vorgesehenen Websitebenutzer arbeiten. Root ist für normale WordPress Aufgaben häufig nicht nötig und kann neue Dateien mit unpassendem Besitzer erzeugen. Prüfen Sie den ausführenden Benutzer, das Arbeitsverzeichnis und den vollständigen Weg zum PHP Programm oder zu WP CLI. Die PHP Auswahl der Website muss nicht mit dem Standard im Terminal übereinstimmen. Nach einem Versionswechsel kann ein Job deshalb unter der alten Laufzeit weiterlaufen. Unser Ratgeber zum PHP Wechsel behandelt beide Wege gemeinsam. Tragen Sie die konkrete Laufzeit in das Betriebsblatt ein, damit der Hintergrundweg beim nächsten Update nicht vergessen wird.

Unter Plesk kann die Shell eines geplanten Jobs dessen Sicht auf das Dateisystem beeinflussen. Die Plesk Dokumentation zur Job Shell beschreibt diese Grenze. Ein absoluter Pfad aus einer administrativen Sitzung kann in einer eingeschränkten Umgebung nicht genauso sichtbar sein. Testen Sie deshalb mit dem vorgesehenen Benutzer und dem tatsächlichen Startweg. Notieren Sie außerdem, wo die Ausgabe landet. Wenn ein Job ohne beobachtbaren Fehlerkanal läuft, bleibt ein fehlgeschlagener Start leicht unbemerkt. Ein erfolgreich gespeicherter Eintrag in der Oberfläche belegt nur die Konfiguration und nicht die spätere Ausführung.

Erst lesen, dann gezielt ausführen

WP CLI kann die Aufgabenliste anzeigen und fällige Ereignisse ausführen. Die offizielle Dokumentation zum Ausführen von Cron Ereignissen nennt dafür die passenden Optionen. Für eine Bestandsprüfung wird zuerst die Liste gelesen. Ein Run Befehl ist dagegen eine echte Ausführung und kann Nachrichten, Exporte oder externe Änderungen auslösen. Verwenden Sie ihn mit bekanntem Zweck und passenden Testbedingungen. In einer kopierten Vorschau müssen solche Nebenwirkungen vorher begrenzt werden. Die Funktion eines Hooks wird nicht dadurch harmlos, dass er über ein Kommandozeilenwerkzeug statt über einen Besucheraufruf gestartet wird.

wp --path=/path/to/wordpress cron event list
wp --path=/path/to/wordpress cron event run --due-now

Der Pfad im Beispiel ist ein Platzhalter. Die Befehle müssen in einer passenden Umgebung mit der beabsichtigten Laufzeit und dem vorgesehenen Benutzer arbeiten. Lesen Sie die Ausgabe und den Rückgabecode, aber prüfen Sie zusätzlich das fachliche Ergebnis. Ein Exportjob kann erfolgreich starten und trotzdem keine Datei schreiben, weil seine Datenquelle leer oder sein Ziel falsch ist. Eine geplante Veröffentlichung kann aus anderen Gründen nicht sichtbar sein, etwa weil ein Cache die ältere Antwort liefert. Verbinden Sie deshalb die technische Ausführung mit einem konkreten Postcheck. So wird aus der Jobliste ein belegter Ablauf mit einer Wirkung, die zur Aufgabe der Website passt.

Fälligkeit und Zeitzone richtig lesen

Ein Termin kann in der Websitezeit, in einer Werkzeugausgabe oder im Systemlog unterschiedlich dargestellt sein. Notieren Sie deshalb die Zeitbasis und prüfen Sie, ob die Anzeige in lokaler Zeit oder UTC erfolgt. Bei einem Vorfall ist die Zuordnung sonst unnötig schwierig: Der Betreiber erwartet einen Lauf um zwei Uhr, das Log zeigt einen anderen Wert und beide Angaben können denselben Zeitpunkt meinen. Auch die Umstellung auf Sommer oder Winterzeit beeinflusst die Erwartungen an lokal geplante Aufgaben. Für wichtige feste Termine muss klar sein, welches Verhalten vorgesehen ist. Eine wiederkehrende Aufgabe nach Intervall und eine Aufgabe zu einer bestimmten Ortszeit sind nicht immer derselbe Bedarf.

Überfällige Aufgaben sind ein sinnvoller Hinweis, aber ihre Bedeutung hängt vom Zweck ab. Eine kleine Verspätung bei einer selten gebrauchten Prüfung kann akzeptabel sein, ein nicht erzeugter täglicher Bericht möglicherweise nicht. Definieren Sie deshalb den tolerierten Zeitraum pro wichtigen Job. Vermeiden Sie einen Alarm auf jede technische Abweichung, wenn daraus keine Handlung folgt. Die Anleitung zur Alarmierung verbindet Messwert, Schwelle und zuständige Person. Für Cron kann der passende Messwert das Alter der letzten erfolgreich erzeugten Datei sein. Das prüft die tatsächliche Wirkung oft besser als die bloße Existenz einer geplanten Zeile im System.

Überlappung und Laufdauer beachten

Ein Job kann länger dauern als sein geplantes Startintervall. Wenn dann ein weiterer Lauf beginnt, können mehrere Aufgaben dieselben Daten gleichzeitig bearbeiten oder zusätzliche Last erzeugen. Prüfen Sie, wie die konkrete Anwendung solche Überschneidungen behandelt. WP Cron besitzt eigene Mechanismen für den Start, aber eine umfangreiche Pluginaufgabe braucht trotzdem ein klares Verhalten bei Abbruch und erneuter Ausführung. Für direkt gestartete eigene Abläufe kann eine passende Sperre nötig sein. Eine Sperre ist jedoch nur dann nützlich, wenn veraltete Zustände erkannt und kontrolliert aufgelöst werden. Löschen Sie eine Sperrdatei nicht blind, solange die ursprüngliche Aufgabe möglicherweise noch läuft.

Beobachten Sie die Dauer des schweren Ablaufs und die Wirkung auf die Website. Ein großer Import kann Datenbank und PHP Pool belasten, obwohl sein eigener Job erfolgreich endet. Stimmen Sie Startzeiten mit Backups und anderen Wartungsaufgaben ab. Eine Verschiebung kann Lastspitzen entzerren, ersetzt aber keine Prüfung der eigentlichen Ressourcen. Wenn ein Job regelmäßig sehr lange braucht, klären Sie Datenumfang und Ablauf mit dem Entwickler. Möglicherweise ist eine Verarbeitung in kleineren Teilen besser geeignet. Der Ratgeber zur Kapazität hilft, wiederkehrende Aufgaben in den Verlauf der gesamten Website einzuordnen und ihre Wirkung nachvollziehbar zu messen.

HTTP Auslöser bis zur Anwendung prüfen

Bei einem HTTP Job kann bereits der Weg vor WordPress scheitern. Eine falsche DNS Antwort, ein abgelaufenes Zertifikat oder eine neue Sperrseite verhindert den vorgesehenen Aufruf. Prüfen Sie den tatsächlich verwendeten Namen und die Antwort. Eine HTTP Verbindung mit Status 200 ist kein vollständiger Beleg, wenn der Inhalt nur eine vorgeschaltete Standardseite zeigt. Weiterleitungen können zudem den Weg verändern. Nach einer Domain oder TLS Änderung gehört der Job deshalb zur Abnahme. Unser Ratgeber zur TLS Erneuerung beschreibt die passende Trennung von Verbindung, Zertifikat und Inhalt. Der Cron Test setzt diese Kette bis zum eigentlichen Aufgabenergebnis fort.

Zugangsdaten für einen geschützten HTTP Weg gehören nicht offen in eine URL oder ein öffentliches Skript. Klären Sie den vorgesehenen sicheren Mechanismus und begrenzen Sie seine Rechte. Für eine dauerhaft geschützte Vorschau kann ein lokaler Start einfacher zu betreiben sein als eine Sonderregel im äußeren Schutz. Entscheidend bleibt, dass dieser lokale Weg wirklich funktioniert. Eine theoretische Möglichkeit in der Plattform ist kein belegter laufender Job. Halten Sie im Ergebnis fest, welcher Weg aktiv ist, welcher Test erfolgte und welche Aufgabe dabei beobachtet wurde. So werden eine vorbereitete Konfiguration und ein tatsächlich geprüfter Betrieb nicht miteinander verwechselt.

Fehlgeschlagene Aufgaben mit ihrem Ergebnis verbinden

Bei einem fehlenden Ergebnis prüfen Sie zuerst den letzten Start des Systemjobs. Fehlt er, untersuchen Sie Planer, Rechte und Startpfad. Ist er vorhanden, prüfen Sie, ob WordPress erreicht wurde und ob der relevante Hook fällig war. Danach folgen dessen eigene Logs und Abhängigkeiten. Eine Datenbankverbindung oder externe API kann scheitern, obwohl der allgemeine Cron Aufruf funktioniert. Diese Reihenfolge begrenzt die Suche. Notieren Sie den erreichten Schritt und den genauen Fehler. Ein pauschaler Neustart des gesamten Hosts ist für eine einzelne ausgebliebene Exportdatei meist keine passende erste Diagnose und kann wichtige Belege aus dem ursprünglichen Zustand entfernen.

Wenn ein erneuter Lauf nötig ist, prüfen Sie zuvor, ob er wiederholbar ist. Ein Export lässt sich vielleicht einfach neu erstellen; eine Nachricht oder externe Bestellung darf nicht doppelt entstehen. Das Verhalten muss zur Aufgabe passen. Ein Entwickler kann dafür eine eindeutige Zustandsprüfung oder einen kontrollierten Fortsetzungsweg vorsehen. Als Betreiber dokumentieren Sie, welche Teile bereits abgeschlossen waren und welcher Teil wiederholt wurde. Die Anleitung zum Incident Runbook hilft, diese Schritte sauber festzuhalten. Der ursprüngliche Fehler bleibt erhalten, auch wenn der manuelle Nachlauf gelingt. Erst die Ursachenprüfung entscheidet, ob der automatische Weg wieder zuverlässig ist.

Nach Änderungen die erste vollständige Runde beobachten

Nach einem Pluginupdate oder PHP Wechsel warten Sie nicht nur auf eine fehlerfreie Startseite. Prüfen Sie die nächste reguläre Runde der wichtigen Aufgaben. Halten Sie Start, Ende und Ergebnis fest. Bei einem seltenen Job kann ein kontrollierter Test sinnvoll sein, sofern seine Nebenwirkungen bekannt sind. Eine zusätzliche Testausführung ersetzt danach nicht die Prüfung, ob der Planer zum vorgesehenen Zeitpunkt läuft. Beide Wege werden getrennt notiert. Der Ratgeber zu sicheren WordPress Updates ergänzt den Ablauf um Sicherung und Abnahme. So bleibt der Hintergrundbetrieb ein sichtbarer Teil des Updates statt einer erst Tage später bemerkten Nebenwirkung.

Prüfen Sie außerdem, ob nach einer Migration alte und neue Umgebung gleichzeitig dieselben externen Aufgaben ausführen. Eine kopierte Website kann gültige Zugangsdaten und aktivierte Jobs enthalten. Deshalb wird ihr Wirkungskreis bereits beim Aufbau begrenzt. Entfernen oder deaktivieren Sie veraltete Jobwege gezielt, wenn der neue Weg abgenommen ist. Dokumentieren Sie, welche Umgebung künftig die Aufgabe besitzt. Diese Zuordnung verhindert doppelte Nachrichten, konkurrierende Exporte und unerklärliche Datenänderungen. Ein eigenes Betriebsblatt pro Domain bleibt dafür wichtig, selbst wenn mehrere Projekte auf derselben Infrastruktur laufen. Die gemeinsame Technik macht ihre Aufgaben und Freigaben nicht automatisch gemeinsam.

Ein kleiner Betriebsnachweis reicht oft aus

Für jeden wichtigen Job kann eine kurze Zeile genügen: Auslöser, Benutzer, Programmweg, Intervall, letzter erfolgreicher Lauf, Ergebnis und Empfänger bei Fehlern. Daneben steht der nächste reguläre Testtermin. Prüfen Sie auch den Fehlerkanal, damit ein Ausfall tatsächlich bemerkt wird. Website oder Cron Nachrichten müssen zum vereinbarten Betrieb passen; in einer Vorschau können sie bewusst unterdrückt sein. In diesem Fall braucht es einen anderen beobachtbaren Weg, etwa ein geschütztes Log und einen manuellen Statuscheck. Ein deaktivierter Mailversand darf nicht dazu führen, dass Fehler vollständig unsichtbar werden. Der Nachweis beschreibt deshalb immer den tatsächlich verwendeten Beobachtungsweg.

Verlässlicher WordPress Cron Betrieb besteht aus einem geprüften Auslöser und einem überprüften Aufgabenergebnis. Die Aufgabenliste ist dafür nur der Ausgangspunkt. Mit bekannten Pfaden, passender Laufzeit und einer kleinen Ergebnisprüfung lassen sich stille Fehler früh erkennen. Zeitkritische Jobs werden bewusst geplant, lange Aufgaben bekommen ein klares Verhalten bei Überschneidung und Wiederholung, und nach Änderungen wird die erste echte Runde beobachtet. Diese Form braucht keine komplizierte Oberfläche. Sie braucht verständliche Zuständigkeit und Belege, die im Alltag erreichbar sind. Damit bleibt der Hintergrundbetrieb genauso überprüfbar wie die Website, die Besucher im Browser sehen.