WP-Cron prüfen: Verspätete Jobs, Laufzeit und Rückstau

Cookbook: Ziel und Ergebnis

Du erkennst verspätete, doppelte oder lange laufende Hintergrundjobs und ordnest sie dem auslösenden Plugin zu. WP-Cron ist ein ereignisgetriggerter Scheduler, kein ständig laufender Systemdienst.

Rezept: Schritt für Schritt

1. Unter Werkzeuge → Website-Zustand nach fehlgeschlagenen geplanten Ereignissen suchen.
2. Mit wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence Bestand exportieren.
3. Überfällige Hooks nicht sofort massenhaft ausführen: Eigentümer, erwartete Laufzeit und externe Abhängigkeiten klären.
4. Einzelnen unkritischen Hook kontrolliert ausführen und PHP-/DB-/HTTP-Zeit sowie Fehlerlog beobachten.

Rechenweg oder Entscheidungsregel

Verspätung = tatsächlicher Start − geplanter Zeitpunkt\nRückstaurate = neu fällige Jobs pro Minute − abgearbeitete Jobs pro Minute

Bleibt die Rückstaurate positiv, wächst der Stau. Häufige Besucheraufrufe garantieren keinen pünktlichen Start; sehr seltene Besuche verzögern Jobs zusätzlich.

Praxisbeispiel

Ein fünfminütiger Hook ist seit 45 Minuten überfällig und benötigt 70 s. Bei einem 5-Minuten-Takt wäre Laufzeit allein noch tragbar; blockierende HTTP-Time-outs oder parallele Lock-Probleme können den Rückstau erklären. Erst den Hook reparieren, dann Scheduler-Takt ändern.

Prüfen, ob es funktioniert

• Keine dauerhaft überfälligen Kern-/Shop-Jobs.
• Ein wiederholter Hook überlappt nicht mit seiner vorherigen Instanz.
• Cron-Ausführung erzeugt keine HTTP-Timeouts, Mail-Duplikate oder PHP-Fatal-Errors.

Rollback

Nur selbst erzeugte Testereignisse entfernen. Deaktivierte Plugins können ihre Hooks beim vorgesehenen Deinstallationsweg bereinigen. Bei manueller Ausführung keine erneute Ausführung starten, solange Lock oder Prozess noch aktiv ist.

Funktionsweise

WP-Cron ist kein dauerhaft laufender Systemdienst. WordPress prüft bei Seitenaufrufen, ob Ereignisse fällig sind. Auf wenig besuchten Sites können Jobs später laufen; auf stark besuchten Sites verhindert WordPress parallele Starts über Sperrmechanismen, doch schwere Jobs bleiben eine Lastquelle.

Diagnose

1. Website-Zustand auf verspätete Ereignisse und Loopback-Probleme prüfen.
2. Fällige Hooks, Intervall, Laufzeit und Besitzer inventarisieren.
3. Bei Rückstau den verursachenden Job/Plugin-Fehler beheben, nicht nur häufiger triggern.
4. Externe API-Aufrufe, Backups, Bildverarbeitung und Mailqueues getrennt betrachten.

Wann nichts geändert werden muss

WordPress weist selbst darauf hin, dass das System performancebewusst ist und ein Ersatz nicht zwingend ist. Eine kleine, funktionierende Website gewinnt durch pauschales Abschalten kaum.

Erfolgskontrolle

Geplante Beiträge, Mails, Updates und Plugin-Aufgaben müssen zuverlässig laufen. Miss Jobdauer und Serverlast; verschwundene Warnungen allein beweisen keine fachlich korrekte Ausführung.

Quellen und Prüfstand

• WordPress: Cron-Handbuch
• WordPress: PHP-Optimierung und Cron

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.