WP-Cron vs cron serveur : fiabiliser les tâches planifiées sur WordPress

WP-Cron : comment ça marche et quelles sont ses limites ?

WP-Cron n’est pas un démon système. Il s’exécute lorsqu’une page est chargée. À ce moment, WordPress vérifie si des événements planifiés sont arrivés à échéance, puis tente de les lancer en arrière-plan via wp-cron.php. C’est pratique en mutualisé, mais loin d’être fiable.

• Dépendant du trafic : sans visite, pas de déclenchement. La nuit, le week‑end, ou sur un site B2B peu fréquenté, des jobs critiques peuvent être oubliés.
• Irrespect des horaires : une tâche planifiée à 02:00 peut partir à 03:17 si la première visite survient à ce moment.
• Risque de chevauchement : plusieurs hits simultanés peuvent tenter de déclencher wp-cron.php, d’où des verrous et de la surcharge.
• Reverse proxy / cache agressif : certaines protections bloquent l’appel interne à wp-cron.php ou l’isolent derrière des règles de firewall.
• Temps d’exécution limité : via le SAPI web, tu es plus sensible aux limites de temps, mémoire, et à la latence réseau que via le CLI.

Sur un site e‑commerce, ces limites deviennent visibles : abandon de paniers non relancés, synchronisations produits retardées, emails transactionnels en décalage, et une file d’Action Scheduler qui gonfle. Sur un site vitrine peu fréquenté, les sauvegardes « quotidiennes » ne le sont plus vraiment. La solution : découpler le déclenchement des tâches de la visite utilisateur et confier la planification à l’horloge système.

Quand passer d’un WP-Cron à un cron serveur WordPress ?

Si tu constates l’un des symptômes suivants, il est temps de basculer :

• Des événements planifiés « Missed schedule » ou souvent en retard.
• Une file Action Scheduler contenant des milliers d’actions « Pending » ou « Failed ».
• Des sauvegardes, envois d’email ou imports planifiés qui sautent régulièrement.
• Des pics CPU liés à des déclenchements concurrents de wp-cron.php.
• Un environnement avec peu de trafic ou, à l’inverse, derrière un WAF/proxy strict.

Passer au cron serveur te garantit une exécution à intervalles réguliers, une meilleure isolation des ressources (via PHP CLI), moins de contention et un diagnostic plus clair en cas de problème (logs système, codes de retour, etc.).

Étapes concrètes pour fiabiliser WP-Cron avec un cron système (crontab)

1) Désactiver le déclenchement automatique de WP-Cron

Dans wp-config.php, désactive l’auto-déclenchement pour éviter les courses :

define('DISABLE_WP_CRON', true);

Cette ligne empêche WordPress d’appeler wp-cron.php à chaque visite. À partir de là, c’est ton cron serveur qui prend la main.

2) Choisir une méthode d’appel fiable

Deux approches solides :

1. WP‑CLI (recommandé) : exécute les événements dus via PHP CLI, plus stable et verbeux.
2. Appel direct de wp-cron.php via curl ou wget.

3) Exemples de crontab (méthode WP‑CLI)

Sur ton serveur (utilisateur adéquat), édite la crontab :

crontab -e

Ajoute une exécution toutes les minutes (fortement recommandé pour ne rien rater) :

* * * * * /usr/bin/php -d memory_limit=512M /var/www/html/wp-cli.phar --path=/var/www/html cron event run --due-now &>> /var/log/wp-cron.log

Variantes selon l’emplacement de PHP et de WP-CLI :

* * * * * /usr/local/bin/wp --path=/home/site/public_html cron event run --due-now &>> /home/site/logs/wp-cron.log# ou avec un wrapper bash* * * * * cd /var/www/site && /usr/bin/wp cron event run --due-now &>> /var/log/wp-cron.log

Bonnes pratiques :

• Vérifie which php et which wp pour les bons chemins.
• Augmente la mémoire si nécessaire (-d memory_limit=512M pour des sites WooCommerce/CRM).
• Redirige la sortie vers un log dédié pour diagnostiquer (/var/log/wp-cron.log).

4) Exemples de crontab (méthode curl/wget)

Si WP‑CLI n’est pas disponible :

* * * * * curl -s https://www.ton-site.fr/wp-cron.php?doing_wp_cron=1 &>> /var/log/wp-cron-http.log# ou* * * * * wget -q -O - https://www.ton-site.fr/wp-cron.php?doing_wp_cron=1 &>> /var/log/wp-cron-http.log

Ajoute une protection (clé secrète, IP allowlist, Basic Auth) pour éviter un appel externe abusif. Sur un site derrière Basic Auth, ajoute -u user:pass à curl.

5) Fréquence et granularité

• Toutes les minutes si tu veux respecter au mieux les échéances (recommandé pour e‑commerce).
• Toutes les 5 minutes pour des sites standards, si aucune tâche critique à la minute près.
• Crée des crontabs séparées pour les tâches lourdes (ex. sync import) pour éviter de bloquer les jobs rapides.

6) Versions PHP CLI vs FPM

Assure-toi que la version PHP CLI est cohérente avec celle utilisée par le site (FPM/Apache). Une différence majeure peut provoquer des erreurs subtiles (extensions manquantes, limites différentes). Vérifie avec php -v et ajuste le chemin (/usr/bin/php8.2 par exemple).

Piloter et débugger avec WP‑CLI cron

WP‑CLI fournit des commandes puissantes pour voir, tester et exécuter les événements WordPress.

# Lister les événements planifiéswp cron event list --fields=hook,next_run,recurrence --format=table# Lister les récurrences (schedules)wp cron schedule list# Forcer l’exécution des événements arrivés à échéancewp cron event run --due-now# Tester la boucle interne de WP-Cronwp cron test

Astuce : si un hook plante, capture son erreur en ajoutant --quiet pour les succès et en journalisant uniquement les sorties non‑nulles. Tu peux aussi exécuter un hook précis :

wp cron event run woocommerce_cleanup_sessions

Pour automatiser le diagnostic, programme une tâche hebdo qui exporte la liste des événements et envoie une alerte si des délais dépassent un seuil.

Action Scheduler : la file d’attente de nombreux plugins (dont WooCommerce)

De nombreux plugins (WooCommerce, automatisations marketing, abonnements, etc.) utilisent Action Scheduler. C’est une file d’attente résiliente avec réessaies, groupes (queues) et backoff. Quand WP‑Cron n’est pas fiable, la file grossit et tout se décale.

Où le trouver et quoi surveiller

• Dans l’admin : Outils > Scheduled Actions (ou WooCommerce > Status > Scheduled Actions).
• Surveille les colonnes Pending, Failed, Completed, les groupes (ex. woocommerce), et l’attempts.

Si beaucoup d’actions restent en Pending, c’est souvent un signe que WP‑Cron ne déclenche pas assez souvent ou que certains hooks échouent.

Débugger une file saturée

1. Basculer au cron serveur si ce n’est pas fait (fréquence à 1 minute).
2. Augmenter la mémoire via PHP CLI pour éviter les fatal errors silencieuses.
3. Exécuter les dues avec wp cron event run --due-now et observer le log.
4. Identifier le hook fautif : filtre par groupe/hook dans Scheduled Actions, exécute manuellement, lis wp-content/debug.log si WP_DEBUG_LOG est actif.
5. Répartir les charges : si un import massif tourne à 1 min, réduis le batch (ex. 100 → 25) et isole le job lourd dans un cron dédié.

Action Scheduler gère des « claims » (réservations) pour éviter le chevauchement. Si un worker se bloque (process tué, timeout), certaines actions peuvent rester claimées. Un redémarrage via WP‑CLI et une fréquence plus élevée résolvent souvent le problème.

Monitoring et alertes : ne rate plus une exécution

Mettre un cron système ne suffit pas : il faut le surveiller. Quelques approches simples et efficaces.

1) Journalisation côté serveur

Redirige la sortie de WP‑CLI vers un fichier dédié et fais tourner logrotate. Exemple :

* * * * * /usr/local/bin/wp --path=/var/www/site cron event run --due-now 1>> /var/log/wp-cron.log 2>> /var/log/wp-cron.err

Inspecte régulièrement les erreurs. Déclenche une alerte si le fichier n’a pas bougé depuis X minutes (cron en panne) ou si le nombre d’erreurs dépasse un seuil.

2) Healthcheck « battement de cœur »

Ajoute à la crontab un ping HTTP vers un endpoint de santé après exécution réussie. Des services dédiés de healthcheck peuvent alerter si le ping n’arrive pas dans la fenêtre prévue (pratique et léger).

3) Alerte email sur erreur

Tu peux envelopper la commande WP‑CLI dans un petit script Bash qui envoie un email si le code de retour est non nul.

#!/usr/bin/env bashset -euo pipefailLOG="https://cdn.wp-builders.tech/var/log/wp-cron.err"if ! /usr/local/bin/wp --path=/var/www/site cron event run --due-now >> /var/log/wp-cron.log 2>> "$LOG"; then  mail -s "[ALERTE] Cron WordPress en erreur" admin@domaine.fr < "$LOG"fi

4) Indicateurs applicatifs

Expose une option/entrée en base indiquant la dernière exécution d’un job critique (ex. last_backup_run). Affiche‑la dans ton back‑office (widget Dashboard) et alerte si elle dépasse un seuil.

Fiabilise tes tâches planifiées WordPress

On met en place un cron serveur, WP‑CLI, du monitoring et on corrige les files d’Action Scheduler. Intervention rapide et documentée.

Voir nos offres de maintenance pro

Bonnes pratiques de performance pour le cron WordPress en production

• Exécute souvent, travaille par petits lots : privilégie une fréquence d’1 minute et découpe les tâches lourdes en batchs (moins de timeouts, meilleure UX).
• Évite les verrous globaux : protège chaque job avec un verrou applicatif (ex. wp_using_ext_object_cache() + transients/keys) pour empêcher les chevauchements.
• Sépare les jobs lourds : mets les imports/exports massifs dans une crontab dédiée, avec une fenêtre horaire basse (ex. 01:00–05:00).
• Versionne ta crontab : stocke le fichier dans le dépôt (ou un playbook Ansible) pour tracer les changements.
• Uniformise PHP : garde mêmes extensions et limites entre CLI et FPM (mémoire, max_execution_time, opcache CLI).
• Teste en staging : clone ta prod, lance wp cron test, vérifie Action Scheduler, puis déploie.
• Documente : consigne les hooks critiques, leur fréquence, l’owner, et les indicateurs de santé associés.

Checklist express : migrer de WP‑Cron vers un cron serveur

1. Activer define('DISABLE_WP_CRON', true); dans wp-config.php.
2. Installer/configurer WP‑CLI sur le serveur (ou préparer l’appel HTTP sécurisé vers wp-cron.php).
3. Créer une crontab chaque minute pour wp cron event run --due-now (log dédié).
4. Vérifier la version CLI de PHP et les limites de ressources.
5. Vérifier que les événements s’exécutent à l’heure (commande de test + logs).
6. Ouvrir Action Scheduler, contrôler la diminution des « Pending ».
7. Mettre un healthcheck ou une alerte email si le log n’évolue plus.
8. Documenter le setup et l’ajouter à tes procédures d’ops.

Diagnostic rapide en cas de jobs manqués

• Étape 1 : wp cron event list — repère les hooks échus non exécutés.
• Étape 2 : wp cron event run --due-now — exécute et observe le log.
• Étape 3 : Ouvre Action Scheduler — filtre par « Failed », lis les messages d’erreur.
• Étape 4 : Vérifie les limites PHP CLI (mémoire/timeout) et la version.
• Étape 5 : Inspecte le firewall/WAF et les reverse proxies si appel HTTP.

Ressources officielles utiles

Pour approfondir le fonctionnement du cron WordPress et des commandes WP‑CLI, consulte la documentation officielle :
• Guide du Cron WordPress (developer.wordpress.org)
• Commandes WP‑CLI cron (developer.wordpress.org)

Conclusion

Fiabiliser tes tâches planifiées WordPress avec un cron serveur change la donne : exécution ponctuelle, diagnostics clairs, moins de surprises en prod. Ajoute WP‑CLI pour le pilotage, Action Scheduler pour la résilience et un monitoring léger. C’est une brique essentielle d’une maintenance WordPress professionnelle. Chez WP Builders, on met en place ce setup au quotidien : rapide, documenté, orienté résultat. Tu veux des tâches qui tournent à l’heure, tous les jours, sans stress ? Parlons‑en.