Prüfen Sie, ob WP-Cron aktiviert ist, ob eine auslösende Anfrage entsteht und welche Ereignisse sich verzögern. Ermitteln Sie Hook, Verantwortlichen und den Fehler des Callbacks, nicht nur die Anzahl der Einträge. Bei einem zuverlässigen Server lässt sich WP-Cron über einen System-Cron ausführen; die Aufgaben müssen idempotent sein und überwacht werden.
WP-Cron führt geplante Aufgaben von WordPress aus, zum Beispiel die Veröffentlichung eines Beitrags, das Bereinigen temporärer Daten oder eine Synchronisierung. Im Gegensatz zu einem Systemplaner wird er standardmäßig durch einen Besuch der Website ausgelöst. Auf wenig besuchten Websites kann sich eine Aufgabe verzögern, bei hoher Last können sich Ausführungen dagegen überschneiden oder blockieren. Zudem fügen Plugins eigene Ereignisse hinzu und räumen den Zeitplan nach der Deinstallation nicht immer auf.
Wenn eine E-Mail nicht versendet wird oder ein Import nicht durchläuft, startet das Team oft manuell einen weiteren Versuch, ohne den Status zu prüfen. Dadurch können Duplikate oder eine längere Warteschlange entstehen. Für die Diagnose werden der Name des Hooks, die geplante Zeit, die Argumente, das letzte Ergebnis und die Anwendungslogs benötigt. Bei WooCommerce kann zudem der Action Scheduler zum Einsatz kommen, der über einen eigenen Speicher und eine eigene Administrationsansicht verfügt.
Verstehen Sie die Ausführung und die zeitlichen Erwartungen
WordPress speichert ein Ereignis für den nächstmöglichen Zeitpunkt, doch der Standard-WP-Cron führt es nicht uhrgenau aus. Nach Ablauf der Zeit braucht es eine Anfrage, die die Verarbeitung anstößt. Daher kann eine geplante Veröffentlichung in einem wenig besuchten Intranet verspätet erfolgen. Die Zeitzone der Administration, des Servers und der in UTC gespeicherten Daten muss bei der Diagnose nachvollziehbar sein.
Eine geplante Aufgabe sollte nicht automatisch in jedem Intervall laufen, wenn die vorherige noch arbeitet. Verwenden Sie je nach Aufgabentyp eine Sperre oder eine Warteschlange und legen Sie eine maximale Laufzeit fest. Definieren Sie bei kritischen Integrationen eine akzeptable Verzögerung. Eine Aufgabe, die eine Stunde warten kann, braucht nicht dieselbe Infrastruktur wie die Bestellverarbeitung.
Inventarisieren Sie Hooks, Intervalle und Verantwortliche
Lassen Sie sich die Liste der Ereignisse mit Hook-Name, nächster Ausführung, Intervall und Argumenten anzeigen. Ermitteln Sie das Plugin oder den eigenen Code, der den jeweiligen Hook registriert. Verdächtig sind Ereignisse mit nicht existierendem Callback, ungewöhnlich kurzem Intervall, einer großen Zahl einmaliger Einträge oder Argumenten, die bei jedem Versuch anwachsen. Entfernen Sie einen Hook nicht allein aufgrund eines unbekannten Namens.
Prüfen Sie beim Deaktivieren eines Plugins, ob der Zeitplan korrekt aufgehoben wird. Ein verwaistes Ereignis kann wiederholt Fehler auslösen. Ein eigenes Plugin sollte die Registrierung bei der Aktivierung vornehmen, Duplikate verhindern und bei der Deaktivierung seine Hooks bereinigen. Halten Sie fest, welche Aufgaben geschäftskritisch sind und wohin eine Benachrichtigung geht, wenn sie längere Zeit nicht ausgeführt werden.
- Hook und sein Callback
- Intervall und nächster Zeitpunkt
- Argumente und Schutz vor Duplikaten
- Betrieblicher Verantwortlicher und Priorität
Diagnostizieren Sie Fehler bei Callback und Sperre
Eine Aufgabe kann korrekt geplant sein und dennoch an einem PHP-Fehler, einem Timeout, Speichermangel oder einer API-Antwort scheitern. Aktivieren Sie ein sicheres Logging in eine Datei außerhalb der öffentlichen Ausgabe und führen Sie den betreffenden Hook auf dem Staging-System mit denselben Argumenten aus. Eine Korrelations-ID hilft, einen einzelnen Versuch über die Warteschlange und das externe System hinweg zu verfolgen. Schreiben Sie keine Geheimnisse und keine vollständigen personenbezogenen Daten ins Log.
Ein temporärer Cron-Lock verhindert parallele Ausführungen, doch nach einem Absturz kann ein scheinbar hängender Zustand oder umgekehrt eine parallele Verarbeitung entstehen. Prüfen Sie Zeitpunkt und Eigentümer der Sperre, bevor Sie sie manuell entfernen. Die Aufgabe muss Wiederholungen sicher verkraften, damit der Eingriff keine zweite Bestellung, E-Mail oder Rechnung erzeugt. Ein dauerhafter Fehler sollte in einen sichtbaren Zustand übergehen.
Unterscheiden Sie zwischen WP-Cron und Action Scheduler
Action Scheduler wird von vielen E-Commerce-Erweiterungen zur Verarbeitung von Warteschlangen verwendet und erfasst Aktionen mit den Status pending, complete, failed und canceled. Eine große Anzahl abgeschlossener Einträge muss kein Problem sein, ein wachsendes Alter wartender Aktionen hingegen schon. Prüfen Sie Gruppe, Hook, Anzahl der Versuche und das Log der jeweiligen Aktion. Massenlöschung behebt keinen Callback, der weiterhin fehlschlägt.
Verarbeiten Sie die Queue in Batches, die der Serverkapazität angemessen sind. Eine zu hohe Parallelität kann die Datenbankverbindungen erschöpfen, eine zu geringe hält mit dem Eingang neuer Einträge nicht Schritt. Legen Sie die Aufbewahrung abgeschlossener Einträge nach dem diagnostischen Bedarf fest. Stellen Sie bei einer Website-Migration sicher, dass die alte und die neue Umgebung nicht gleichzeitig gegen dieselben externen Systeme laufen.
- Alter der ältesten wartenden Aktion
- Wiederkehrende Fehlerursache
- Angemessene Batchgröße
- Nur eine aktive Produktionsumgebung
Führen Sie den System-Cron kontrolliert ein
Auf einem verwalteten Server lässt sich die Ausführung bei Seitenaufrufen deaktivieren und WordPress-Cron stattdessen in regelmäßigen Abständen über den System-Scheduler aufrufen. Das verringert die Abhängigkeit vom Besucheraufkommen, jedoch nur, wenn der Server-Job korrekt konfiguriert und überwacht wird. Prüfen Sie zunächst Pfad, Benutzer, Umgebung, Timeout und Logging. Aktivieren Sie nicht unüberlegt beide Wege gleichzeitig.
Erstellen Sie nach der Umstellung ein synthetisches Testereignis und beobachten Sie die Ausführungszeit. Die Benachrichtigung soll einen ausgebliebenen Lauf, eine wachsende Warteschlange und einen wiederholten Fehler eines kritischen Hooks erfassen. Das Runbook erklärt den sicheren manuellen Start und die Prüfung des Ergebnisses. Ein zuverlässiger Scheduler ist einer, dessen Ausfall das Team früher bemerkt als der Kunde.
Häufige Fragen
Warum wurde ein geplanter WordPress-Beitrag nicht pünktlich veröffentlicht?
WP-Cron kann auf einen Besuch warten, deaktiviert sein oder beim Start fehlschlagen. Prüfen Sie Zeitzone, geplantes Ereignis, Cron-Anfrage und PHP-Log. Auf einer Website mit wenig Traffic kann ein überwachter System-Cron helfen.
Darf ich alle fehlgeschlagenen Action-Scheduler-Aufgaben löschen?
Ermitteln Sie zuerst den Hook, den Verantwortlichen und die Ursache. Durch das Löschen geht die Diagnosespur verloren, und die Aufgabe kann erneut angelegt werden. Entscheiden Sie nach der Behebung, welche Aktionen sicher wiederholt, abgebrochen oder im Verlauf belassen werden.
Wie oft sollte der System-Cron für WordPress laufen?
Das Intervall ergibt sich aus der kürzesten erforderlichen Zeit und der Serverkapazität. Es gibt keinen einheitlichen Wert für jede Website. Kritische Prozesse können häufigere Läufe erfordern, gewöhnliche Bereinigungen deutlich seltenere; das Ergebnis sollte überwacht werden.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
