Passer au contenu 
WordPress Cronjobs tombent en panne sous la charge, lorsque les appels de pages bloquent le programmateur interne, que les caches interceptent les demandes ou que les limites d'hébergement coupent les longues tâches. Je présente les causes, les conséquences et les solutions concrètes pour que les tâches telles que les mises à jour, les sauvegardes et les contributions planifiées fonctionnent de manière fiable.
Points centraux
Pour commencer, je résume brièvement et clairement les aspects les plus importants avant d'aller plus loin et d'expliquer les étapes concrètes que j'utilise de manière productive. Identification des problèmes et Causes sont au centre des préoccupations.
- MécaniqueWP-Cron se déclenche lors des appels de page au lieu de se déclencher via System-Cron.
- DernierTrafic élevé et „wordpress cron load“ génèrent des délais d'attente.
- Mise en cache: La mise en cache complète du CDN arrête l'exécution de Cron.
- Limites: les timeouts PHP et les budgets de ressources interrompent les tâches.
- remède: Server-Cron, intervalles propres, logging et tuning.
WP-Cron en bref : appel de page au lieu du service système
Je commence par la Idée de baseWordPress vérifie à chaque appel de page si des tâches planifiées sont dues et les déclenche par requête HTTP interne vers wp-cron.php. Cette approche compense l'absence d'accès à de véritables crones de serveurs, mais crée une dépendance vis-à-vis du Trafic. Si un site ne reçoit que peu de visiteurs, les tâches sont retardées ou ne fonctionnent pas du tout. Si un CDN traite chaque demande à partir du cache, PHP ne se charge pas et WP-Cron reste muet. Cela explique pourquoi les publications planifiées, les tâches de messagerie ou les sauvegardes ne semblent pas fiables sur certaines installations. Plus les plugins enregistrent de tâches supplémentaires, plus la file d'attente s'épaissit et plus l'exécution devient vulnérable.
Pourquoi Last fait basculer les cronjobs
Si le flux de visiteurs augmente, les vérifications de Cron augmentent également, et donc les Charge du serveur. Davantage de demandes simultanées se disputent le travail PHP, les E/S et la base de données, ce qui entraîne des retards dans les appels Cron. Les latences s'accumulent, les tâches se bloquent les unes les autres et les longues tâches quittent le créneau horaire. Dans les configurations de production, je m'occupe systématiquement de ce problème, car WP-Cron sur les sites de production est souvent à l'origine des temps de réponse lents. En cas de charge élevée, les ralentissements sont directement corrélés à des déclencheurs Cron surchargés. De plus, les tâches mal écrites aggravent la situation, car elles lancent des scans de la base de données qui mobilisent encore plus de ressources.
Limites d'hébergement et leurs conséquences
De nombreux hébergeurs utilisent un Timeout PHP de 30 à 60 secondes ; si une tâche dépasse ce seuil, le système l'arrête brutalement. Cela concerne les tâches de migration, les exportations importantes, le traitement des images ou les e-mails de masse. memory_limit, les limites de processus et les limites de taux ont un effet similaire sur les loopbacks HTTP. Si, en plus, le trafic est faible, les événements dus s'accumulent et sont retardés ou ne fonctionnent pas du tout. C'est pourquoi je vérifie d'abord les limites et les logs avant de modifier l'application. Cela me permet de voir si l'environnement provoque des goulets d'étranglement ou si certaines tâches sont inefficaces.
Contrôle rapide : causes, symptômes, solutions
L'aperçu suivant m'aide à séparer les images d'erreur de manière structurée et à agir de manière ciblée au lieu d'expérimenter sans plan. Chaque ligne montre une Cause, un signe visible Symptôme et une mesure immédiate.
| Cause | Symptôme typique | mesure immédiate |
|---|---|---|
| CDN/proxy inversé dessert 100% à partir du cache | Les contributions planifiées apparaissent en retard | Découpler WP-Cron, mettre en place un vrai Server-Cron |
| Délai d'attente PHP (30-60 s) | Sauvegardes/exportations annulées | Augmenter le timeout, diviser la tâche en lots plus petits |
| Trop d'événements Cron | Latence perceptible lors des pics de trafic | Étendre les intervalles, supprimer les événements inutiles |
| Requêtes SQL inefficaces | L'utilisation de la base de données fait un bond en avant | Définir des index, alléger les SELECT, mettre en cache |
| Site web à faible trafic | Des retards de plusieurs heures | Exécuter System-Cron toutes les 15-60 minutes |
Je complète le contrôle par des métriques réelles issues des logs et du monitoring pour vérifier les hypothèses et Cause clairement à démontrer. Le tableau ne remplace pas une mesure, il la canalise. Ce n'est que lorsque je sais si le délai d'attente, le cache ou la base de données sont limitants que je mets en place la mesure appropriée. Ensuite, je fais des tests répétés et je vérifie s'il y a des effets secondaires. Ainsi, je limite les dépenses et je résous le problème de manière durable.
Les meilleures pratiques : De WP-Cron à Server-Cron
Je commence par désactiver le déclencheur basé sur la page avec DISABLE_WP_CRON dans le wp-config.php : define(‚DISABLE_WP_CRON‘, true) ;. Ensuite, je mets en place un véritable cron système qui appelle wp-cron.php de manière cyclique (par exemple par curl toutes les 5 minutes en cas de fort trafic, toutes les heures en cas de faible trafic). Cela me permet de découpler les exécutions du flux de visiteurs et de lisser les Dernier. En parallèle, je limite les appels simultanés afin d'éviter les tempêtes Cron. Si j'attends des pics, j'augmente le nombre de travailleurs PHP et j'adapte les délais. En cas de trafic fluctuant, je réduis ainsi le nombre de connexions. charge irrégulière du CPU et évite les réactions en chaîne.
Intervalles, conception des tâches et base de données
Je vérifie que chaque événement est Intervalle et j'étire les fréquences chaque fois que c'est possible. Au lieu de scanner chaque minute, je le fais toutes les heures ou tous les jours si la tâche n'a pas besoin d'une valeur en temps réel. Je divise les longues tâches en petits lots qui s'exécutent en toute sécurité dans le cadre du délai d'attente PHP. Lors de l'accès à la base de données, je définis des index, je réduis les colonnes et je renonce aux scans complets. Je mets en cache les données fréquentes afin d'intercepter les répétitions et d'éviter les Base de données de travail inutile. Les temps d'exécution sont ainsi réduits et les exécutions Cron restent prévisibles.
Diagnostic dans la pratique : créer de la visibilité
Avant de faire des travaux, je veux des informations fiables. Données de diagnostic. Je commence par l'affichage de l'historique du site WordPress et j'active la journalisation (WP_DEBUG_LOG) pour rendre visibles les erreurs PHP lors des appels Cron. Ensuite, je liste les événements échus et planifiés ainsi que leurs durées. Dans les workflows de production, j'utilise pour cela des étapes répétables :
- Déclencher les événements échus par WP-CLI : wp cron event run -due-now
- Lister les événements planifiés : wp cron event list
- Définir ses propres points de mesure : Enregistrer l'heure de début/fin dans la tâche, y compris la mémoire des pics
- Vérifier la page de la base de données : Identifier les SELECT longs et ajouter les index nécessaires
Si Site-Health indique „Exécution retardée de Cron“, j'évalue les journaux d'accès à wp-cron.php, les codes de réponse et la durée. 429/503 indiquent des limites de débit ou de ressources, 401/403 des blocages par Auth, Firewall ou WAF. Je vérifie si les demandes de bouclage sont autorisées en interne et si le nom d'hôte se résout correctement. En outre, je consulte l'option „cron“ de wp_options pour évaluer la taille et l'âge de la file d'attente et identifier les hooks de fonction qui échouent de manière répétée.
Configuration robuste du cron serveur : HTTP, WP-CLI et verrouillage
Pour les environnements productifs, je préfère un Cron du serveur via WP-CLI plutôt qu'un appel HTTP pur, car cela me permet de lancer PHP directement et de moins dépendre du serveur web/proxy. Exemples de variantes qui ont fait leurs preuves :
- HTTP variable, avec budget temps et mise en veille : curl -sS https://domain.tld/wp-cron.php?doing_wp_cron=1 -max-time 55 -connect-timeout 5 >/dev/null
- WP-CLI directement : cd /chemin/vers/installation && /usr/bin/wp cron event run -due-now -quiet
- Éviter les chevauchements : flock -n /tmp/wp-cron.lock -c „/usr/bin/wp cron event run -due-now -quiet“.“
- Augmenter les ressources de manière ciblée : php -d memory_limit=512M -d max_execution_time=300 wp-cli.phar cron event run -due-now
Avec flock, j'évite les démarrages parallèles qui, sinon, conduisent à des exécutions doubles et à des accès concurrents à la base de données. Dans le cas de plusieurs instances (par ex. Blue/Green, conteneurs), je ne fais exécuter le cron que sur un seul hôte et je le désactive sur les autres. J'évite ainsi les conditions de course dans la file d'attente.
Loopbacks, Auth et pare-feux : des blocages typiques
Si les cronjobs sont en „attente“, c'est souvent le serveur interne qui bloque. Loopback. Je vérifie si Basic-Auth, des restrictions IP ou un WAF empêchent les requêtes vers wp-cron.php. Dans les configurations de staging sécurisées, j'exclue wp-cron.php de l'authentification ou j'autorise les loopbacks comme exception. Si les appels HTTP externes sont restreints, je m'assure que mon propre domaine ne figure pas sur la liste de blocage. Comme solution de secours, ALTERNATE_WP_CRON peut aider à court terme, mais je ne l'utilise que temporairement et je le retire dès qu'un cron de serveur propre est actif.
Chevauchements et idempotence : sécuriser les tâches
De nombreux problèmes résultent exécutions simultanées de la même tâche. C'est pourquoi j'intègre des verrouillages par tâche (par exemple via Transient/Option), je vérifie avant le démarrage si une exécution est déjà active et je termine le deuxième appel à temps. En même temps, je rends les tâches idempotentes : si une étape est lancée deux fois, elle n'entraîne pas de doublons dans les e-mails, les fichiers ou les entrées de la base de données. Pour les tâches par lots, j'enregistre des décalages/marqueurs afin de contrôler proprement les suites et d'intercepter les répétitions. Cela réduit les dommages indirects lorsqu'une exécution cron s'arrête inopinément et redémarre plus tard.
Mise à l'échelle : multiserveurs, conteneurs et multisite
Dans les environnements distribués, j'exploite exactement un Un programme d'exécution Cron. Il peut s'agir d'un conteneur de travail séparé ou d'un nœud fixe qui déclenche tous les événements dus via WP-CLI. Les systèmes de fichiers partagés ou les caches distribués aident à maintenir la cohérence des statuts et des verrous entre les instances. Dans les configurations multisite, je vérifie que Cron est proprement planifié pour chaque réseau de sous-site et que les événements réseau n'inondent pas la file d'attente globale de manière incontrôlée. En outre, je m'assure que les fuseaux horaires par site sont corrects afin que les publications et les plages horaires soient correctes.
Heures et fuseaux horaires : éviter les „missed schedule
Un facteur sous-estimé est Fuseaux horaires et le changement d'heure d'été. WordPress planifie les articles dans le fuseau horaire du site, alors que les serveurs fonctionnent souvent en UTC. Je compense les deux, je vérifie les paramètres du fuseau horaire lors des déploiements et je tiens compte des changements d'heure dans le plan éditorial. Si „Missed schedule“ se produit, je vérifie si la cronqueue est surchargée, si les hooks de publication échouent ou si l'heure du serveur dérive. Un „wp cron event run -due-now“ ultérieur décharge la file d'attente pendant que je corrige la cause réelle (cache, timeout, fuseau horaire incorrect).
Développement, mise en place et déploiements
Dans les environnements de staging, je désactive les tâches productives (e-mails, exportations, webhooks) afin d'éviter le déclenchement d'actions involontaires. Je règle DISABLE_WP_CRON sur true et j'exploite mon propre cron de test avec de longs intervalles. Avant la mise en service, je vide la file d'attente, j'exécute manuellement les tâches critiques une fois et je surveille les logs de près. Après les déploiements, une exécution ciblée „due-now“ déclenche les nouveaux hooks avant que les caches ne redeviennent agressifs. J'évite ainsi les surprises et je garde la phase d'introduction tranquille.
Gestion des erreurs, backoff et répétitions
Les pannes arrivent. Je les prévois en Retries avec backoff : réessayer après un court laps de temps, puis avec un intervalle croissant. Je documente les étapes qui ont échoué avec des codes clairs et le contexte (input, durée, mémoire, SQL, code HTTP). Après N tentatives infructueuses, je marque l'événement comme „stuck“ et m'en informe par une alerte. Cette séparation évite les boucles sans fin et me donne le temps de corriger la cause réelle sans encombrer la file d'attente.
Outils : WP Crontrol et Action Scheduler
Pour le quotidien Contrôle j'utilise WP Crontrol pour voir, mettre en pause ou reprogrammer des événements directement dans WordPress. Je détecte ainsi les hooks en suspens, les entrées en double ou les intervalles erronés. Pour les grands processus, j'utilise Action Scheduler, qui divise les tâches en petites actions et les consigne proprement. Si une action tombe en panne, je la redémarre de manière ciblée sans mettre en danger l'ensemble de la chaîne. Cela réduit les pics, car je n'impose pas un monolithe mais Tâches partielles répartir de manière tactique. Ainsi, les déploiements et les fenêtres de maintenance restent prévisibles.
Hébergement partagé, mise en cache et CDNs
Dans les environnements partagés, les appels Cron entrent rapidement en conflit avec Limites, que je ne contrôle pas directement. Lorsque le CDN et le cache de pages complet sont activés, aucun appel de page ne déclenche le WP-Cron. Je contourne cela avec un cron système et veille à ce que les demandes de bouclage soient accessibles. Là où Cron ne déclenche pas de manière fiable, je vérifie les politiques de réseau, Basic-Auth et les pare-feux. Un test avec appel direct de curl montre si les demandes arrivent techniquement à destination. Pour des informations de fond et des alternatives, je vous renvoie à Tâches cron dans l'hébergement mutualisé, Le site Internet de l'OFSP est très intéressant, car il décrit de manière compacte les écueils typiques.
Monitoring et maintenance au quotidien
Je garde les Site-Health-En effet, WordPress signale de manière visible les exécutions Cron en retard. En outre, j'écris des logs afin d'évaluer statistiquement la durée, les erreurs et les répétitions. Cela permet de mettre en évidence des anomalies qui passeraient sinon inaperçues dans le travail quotidien. Je supprime ou réinitialise les événements obsolètes ou qui échouent durablement afin de maintenir une file d'attente légère. Des alertes par e-mail ou Slack m'informent lorsqu'une tâche échoue plusieurs fois. J'interviens ainsi avant que des conséquences telles que des mises à jour manquées ou des e-mails non envoyés ne causent des dommages.
Conclusion : ma démarche en bref
Tout d'abord, je découple Cron des appels de page, je mets en place un Cron du serveur et je vérifie l'accessibilité par curl. Ensuite, j'optimise les intervalles, je divise les longues tâches en lots et je réduis la charge de la base de données. Je mets en place une journalisation, j'examine les chemins d'erreur et j'adapte les limites de manière à ce qu'aucune tâche n'échoue à cause du délai d'attente. Si nécessaire, j'utilise Action Scheduler, car il divise de manière fiable les longs processus en parties contrôlables. Ensuite, je mesure les effets et j'allège la liste Cron jusqu'à ce que la file d'attente reste propre. Ainsi, les tâches planifiées se déroulent de manière fiable, même si les Dernier augmente ou les caches fonctionnent de manière agressive.
