Fehler in WordPress: action_scheduler_run_queue wird zu spät ausgeführt
Unter Werkzeuge -> Website-Zustand erscheint folgende Meldung:
Deutsch: Das geplante Ereignis, action_scheduler_run_queue, wird zu spät ausgeführt. Deine Website funktioniert noch, aber das kann darauf hindeuten, dass die Planung von Beiträgen oder automatisierten Updates nicht wie beabsichtigt funktioniert.
Englisch: The scheduled event, action_scheduler_run_queue, is late to run. Your site still works, but this may indicate that scheduling posts or automated updates may not work as intended.
Was ist action_scheduler_run_queue?
Der Action Scheduler ist eine in WordPress (vor allem in WooCommerce und anderen großen Plugins) eingesetzte Hintergrundbibliothek zum Planen und Ausführen zeitgesteuerter Aufgaben (Cron-Jobs) mit Hilfe der action_scheduler_run_queue. Er ersetzt oder ergänzt den nativen WP-Cron und verwaltet eine Queue („Warteschlange“) aller geplanten Aktionen.
Funktionsweise des action_scheduler_run_queue
Der Action Scheduler in WordPress legt geplante Aufgaben als auszuführen markiert in der Datenbanktabelle wp_actionscheduler_actions ab. WordPress prüft bei jedem Seitenaufruf ob solche Aufgaben zur Ausführung bereitstehen. Sobald eine Aufgabe fällig ist, wird sie über den Hook action_scheduler_run_queue gestartet und verarbeitet. Der Seitenaufruf kann über einen echten Besucher erfolgen oder über einen dafür eingerichteten Cron-Job auf dem Server.
Eingesetzt wird der Action Scheduler vor allem bei wiederkehrenden oder zeitgesteuerten Prozessen im Hintergrund. Dazu zählen zum Beispiel das automatische Versenden von E-Mails wie Bestellbestätigungen, das Löschen veralteter Zwischenspeicher (Transienten), das Erstellen und Versenden regelmäßiger Reports oder Exporte, das Erstellen von Backups oder das Überprüfen von Zahlungseingängen und Abonnementverlängerungen.
Was passiert wenn action_scheduler_run_queue zu spät ausgeführt wird?
Wenn Du den Fehler action_scheduler_run_queue wird zu spät ausgeführt nicht behebst sind die Konsequenzen:
- Verpasste oder verzögerte E-Mails: Automatisch versandte Nachrichten (Bestätigungsemails, Newsletter) erreichen Deine Kunden verspätet oder gar nicht.
- Fehlende Automatisierungen: Aufgaben wie Lagerbestands-Checks oder Abo-Verlängerungen bleiben aus.
- Geplante Beiträge werden nicht veröffentlicht.
- Wachsende Queue: Ein Rückstand lässt sich langfristig nur schwer aufholen und führt zu Dauerschleifen.
- Performance-Einbrüche: Eine überfüllte Cron-Queue belastet Datenbank und Server, was die gesamte Website verlangsamt.
- Potenzielle Sicherheitsrisiken: Sicherheitsrelevante Updates oder Scans werden unter Umständen nie ausgeführt.
- Nicht ausgeführte oder abgebrochene, unvollständige Backups.
Daher sollte die Cron-Queue des Action Schedulers stets zuverlässig und zeitnah laufen. Eine saubere Server-Konfiguration, echte Server Cron-Jobs und regelmäßige Wartung sind wichtig, um einen reibungslosen Betrieb Deiner WordPress-basierten Webseite sicherzustellen.
Mögliche Ursachen für eine zu späte Ausführung
Ein häufiger Grund dafür, dass action_scheduler_run_queue zu spät ausgeführt wird, liegt in der Art und Weise wie WordPress standardmäßig mit geplanten Aufgaben umgeht. Hier mögliche Ursachen und Symptome absteigend nach Wahrscheinlichkeit.
Keine oder wenig Besucher auf der Webseite
Standardmäßig ist der WordPress-Cron (wp-cron.php) so eingerichtet, dass er nur bei Seitenaufrufen ausgelöst wird. Dieser Mechanismus wird nur selten angestoßen wenn Deine Website jedoch nur wenige Besucher hat oder Crawler und Bots blockiert sind.
Ursache: Durch wenige Seitenaufrufe werden anstehende Aufgaben nicht abgearbeitet und summieren sich.
Symptom: Kaum bis wenig Besucher auf der Webseite. Viele „pending“ – Einträge in der Datenbanktabelle wp_actionscheduler_actions. Sie verbleiben als „pending“ und ihre Verarbeitung erfolgt mitunter erst Stunden oder Tage später.
Große oder rückständige Queue
Wenn sich viele Aufgaben in der Warteschlange ansammeln zum Beispiel durch wenige Besucher oder nach einem Serverausfall, benötigt der Scheduler deutlich mehr Zeit zur Abarbeitung. Auch Updates erzeugen das massenhaft neue Tasks. Dadurch geraten laufende Prozesse ins Stocken und neu geplante Aufgaben werden mit ansteigender Verzögerung ausgeführt. In extremen Fällen entsteht eine Endlosschleife aus unbearbeiteten Aufgaben.
Ursache: Zu viele Aktionen stauen sich in der Tabelle wp_actionscheduler_actions und der Scheduler braucht sehr lange um den Rückstand aufzuholen.
Symptom: Laufende Tasks pausieren oder laufen in Dauerschleife, neue Aufgaben verzögern sich oder werden nicht mehr ausgeführt.
Deaktivierter oder beschädigter WP-Cron
In manchen Fällen wurde in der wp-config.php der WordPress-Cron manuell deaktiviert durch folgenden Eintrag:
define('DISABLE_WP_CRON', true); Wenn in diesem Fall kein externer System-Cronjob eingerichtet wurde, finden gar keine geplanten Cron-Läufe mehr statt. Auch kann es sein, dass Plugins interne Cron-Hooks überschreiben oder beschädigen. Dies verhindert, dass der Action Scheduler korrekt ausgelöst wird.
Ursache: In der wp-config.php wurde DISABLE_WP_CRON auf true gesetzt ohne einen Ersatz-Cron einzurichten. Auch ist es möglich, dass interne Cron-Hooks durch andere Plugins überschrieben wurden.
Symptom: Kein Cron-Lauf, kein Trigger für den Action Scheduler, auch bei Seitenaufruf keine abgearbeiteten Aufgaben in der Tabelle wp_actionscheduler_actions
Hohe Serverlast oder Ressourcen-Engpässe
Vor allem bei günstigem Shared Hosting kann es zu Engpässen bei CPU-Leistung oder Arbeitsspeicher kommen. Wenn viele Prozesse gleichzeitig laufen oder Dein Hostinganbieter strenge Zeitlimits setzt (z. B. bei der max_execution_time), werden Cron-Prozesse unterbrochen oder verzögert. Das betrifft insbesondere Aufgaben mit größerem Datenumfang oder vielen Einzelschritten.
Ursache: Shared Hosting mit CPU- oder Memory-Limits und gleichzeitig viele Prozesse, die den Server belasten.
Symptom: WP Cron-Jobs werden abgebrochen, Skriptabläufe verlangsamt oder Zeitlimits erreicht (z. B. max_execution_time). In den Error Logs (z. B. error_log bei Apache oder php_error.log) findest Du Hinweise auf abgebrochene Skripte, Zeitüberschreitungen (max_execution_time exceeded), Speicherüberschreitungen (Allowed memory size exhausted) oder fehlgeschlagene Datenbankverbindungen.
Konflikte mit Plugins oder Themes
Manche Plugins oder Themes registrieren eigene Cron-Hooks oder verändern die Hook-Priorität von action_scheduler_run_queue. Das kann dazu führen, dass Aufgaben entweder gar nicht oder doppelt ausgeführt werden. Zudem kann die Ausführungsreihenfolge durcheinandergeraten, was wiederum andere Prozesse abbricht, blockiert oder verzögert.
Ursache: Andere Plugins registrieren eigene Cron-Hooks oder ändern die Priorität von action_scheduler_run_queue.
Symptom: Falsche Hook-Reihenfolge, doppelte oder fehlerhafte Ausführungen. Bei aktiviertem Debug-Modus werden Fehlermeldungen aktiviert. Besonders verdächtig sind Fatal Errors, die den Scheduler unterbrechen. Beispielsweise bei Hook-Registrierungen oder inkompatiblen Methodenaufrufen.
Datenbank- oder Tabellenprobleme
Auch technische Probleme mit der Datenbank können den Action Scheduler ausbremsen. Dazu zählen beschädigte oder fragmentierte Tabellen, fehlende Indizes oder sogenannte InnoDB-Lock-Konflikte. Diese führen zu langen Abfragezeiten oder sogar zu unterbrochenen Cron-Abläufen, wenn bestimmte Aktionen blockiert werden oder in einen Deadlock geraten.
Ursache: Beschädigte oder nicht optimierte Tabellen, fehlende Indizes, InnoDB-Lock-Konflikte.
Symptom: Lange Abfragezeiten, Deadlocks, Cron-Abarbeitung wird unterbrochen. Bei aktiviertem Debug-Modus sind Fehler wie „MySQL server has gone away“, „Lock wait timeout exceeded“ oder „Deadlock found when trying to get lock“ sind eindeutige Hinweise auf Datenbankprobleme.
Lösungen für das Problem action_scheduler_run_queue wird zu spät ausgeführt
Basierend auf meiner Sortierung nach Priorität würde ich nacheinander folgende Blöcke prüfen:
1. Entsteht der Fehler durch wenige Besucher oder einem deaktivierten WP-Cron?
- Hat die Webseite Traffic / Besucher?
- Wie viele Aufgaben stehen als „pending“ in der Datenbanktabelle wp_actionscheduler_actions?
- Wird die Anzahl dieser „pending“ – Aufgaben weniger wenn Du die Webseite selbst aufrufst?
Die Lösung hier wäre auf dem Server einen echten Cronjob einzurichten, der den Scheduler unabhängig von Besucher-Seitenaufrufen anstößt. Empfehlung für den Crontab-Eintrag:
*/5 * * * * wget -q -O - https://deine-domain.de/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Die Ausführung wäre alle 5 Minuten. Wenn es besonders viele zeitkritische Aufgaben gibt (z. B. viele Abonnements oder Exporte), kann das Intervall auf alle 1 Minute gesetzt werden:
* * * * * wget -q -O - https://deine-domain.de/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Cronjobs können mit einer Server-Verwaltungssoftware wie Plesk einfach erstellt werden:
- Die gewünschte Domain auswählen und auf „Geplante Aufgaben“ klicken.
- Auf „Aufgabe hinzufügen“ klicken
- „Benutzerdefinierter Befehl„, folgendes einfügen und die Häufigkeit auf 5 bis 1 Minute festlegen:
wget -q -O - https://deine-domain.de/wp-cron.php?doing_wp_cron > /dev/null 2>&1
2. Hohe Serverlast, Datenbankprobleme oder Plugin-Konflikte
Jetzt wird es etwas komplizierter.
Hohe Serverlast / Ressourcenprobleme
Um diese Probleme und beiden folgenden Probleme zu identifizieren, hilft es den Debug-Modus in WordPress zu aktivieren. Am besten ist es die Debug-Meldungen nicht auf der Webseite auszugeben sondern in eine Datei zu protokollieren. Öffne dazu die Datei wp-config.php im Hauptverzeichnis Deiner WordPress-Installation über FTP oder einen Dateimanager Deines Hostings und füge folgenden Code vor der Zeile „/* That’s all, stop editing! Happy publishing. */“ in die Datei ein oder passe ihn an wenn schon Einträge vorhanden sind:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 ); /* That's all, stop editing! Happy publishing. */
Die Logeinträge werden beim Aufrufen Deiner Webseite in die Datei /wp-content/debug.log geschrieben. Wenn Du fertig bist mit dem Debuggen setzt Du WP_DEBUG wieder auf false um die Protokollierung zu deaktivieren.
Öffne die Datei /wp-content/debug.log über FTP oder einen Dateimanager und prüfe:
Sind Einträge vorhanden wie etwa „Fatal error: Maximum execution time of 30 seconds exceeded„, „Allowed memory size of xxx bytes exhausted“ oder „504 Gateway Timeout„?
Der Lösungsweg:
Prüfe die PHP-Einstellungen „max_execution_time„, „memory_limit„, „max_input_vars„, „max_input_time„, „post_max_size“ und „upload_max_filesize„. Diese Werte kannst Du in der Datei php.ini, in der Datei .user.ini oder oft direkt im Plesk-Panel / beim Hosting unter „PHP-Einstellungen“ prüfen und anpassen.
Empfohlene Werte bei WordPress mit WooCommerce sind:
memory_limit = 512M max_execution_time = 300 max_input_vars = 3000 max_input_time = 120 post_max_size = 64M upload_max_filesize = 64M
Oft lassen sich bei Shared-Hosting die Ressourcen nicht entsprechend erhöhen. Ein Shared-Hosting ist grundsätzlich keine gute Wahl für eine produktive WordPress-Installation. Falls Du an einem vernünftigen Hosting interessiert bist dann melde Dich gerne über mein Kontaktformular.
Datenbankprobleme
Fehler bei SQL-Abfragen, Locks oder Verbindungsprobleme zeigen sich mit folgenden Einträgen in der Datei debug.log:
„WordPress database error Deadlock found when trying to get lock„, „MySQL server has gone away„, „Lock wait timeout exceeded; try restarting transaction“ oder „Table ‚wp_actionscheduler_actions‘ is marked as crashed and should be repaired„.
Der Lösungsweg:
- Datenbank-Backup erstellen.
- Tabellen prüfen und reparieren mit phpMyAdmin oder über SSH.
- Bei großen Action Scheduler-Tabellen kann ein fehlender Index (z. B. auf scheduled_date_gmt) zu extrem langsamen Abfragen führen. Falls nicht vorhanden können per SQL – wenn Du weißt was Du tust – fehlende Indizes hinzugefügt werden.
- Shared-Hosting prüfen und einen Umzug auf ein leistungsfähiges Hosting vornehmen.
Plugin- oder Theme-Konflikte
Typischerweise sind nicht definierte Funktionen, doppelte Hooks oder inkompatible Aufrufe in der Datei debug.log zu finden mit Einträgen wie „Call to undefined function xyz()„, „Cannot redeclare function xyz()“ oder „Do not call action ‚init‘ twice!„.
Der Lösungsweg:
- Log lesen, vielleicht steht dort schon ein Plugin oder Theme im Fehlerpfad
- Plugins prüfen, eventuell alle deaktivieren und nacheinander aktivieren um die Fehlerquelle zu finden.
- Theme testweise zu einem aktuellen WordPress-Standard-Theme wechseln
So kannst Du den Übeltäter identifizieren und eventuell Alternativen abwägen. Falls Du Hilfe benötigst:
20 Jahre Erfahrung mit WordPress
Seit WordPress 1.2 (Mai 2004).
Hilfe bei Fehlern oder Problemen mit WordPress, Plugins, Themes, Widgets, Snippets und vielem mehr!
Du hast in Tom einen kompetenten Web-Developer mit umfangreichen Programmierkenntnissen als Ansprechpartner.
Tom hilft Dir schnell und unkompliziert!
Hinterlasse eine Nachricht über das unten stehende Formular.
Sende Tom eine Email und er meldet sich bald möglichst
Versuche Dein Anliegen konkret zu beschreiben:
Telefonischer WordPress Support
Tom im Büro anrufen unter:
Telefon: +49 (0)7961 / 564237
(Festnetz; Kosten abhängig von Deinem Tarif)
Tom ist nicht immer telefonisch zu erreichen. Sende in dem Fall Deine Telefonnummer über das Kontaktformular .
