Cron toutes les 5 minutes

L'expression

*/5 * * * *  /chemin/vers/commande

Le premier champ est la minute. */5 déclenche aux minutes 0, 5, 10, 15, 20, jusqu'à 55. Les autres champs à * signifient chaque heure, chaque jour, chaque mois et chaque jour de semaine.

Variantes utiles

• */5 9-17 * * 1-5 : toutes les 5 minutes pendant les heures ouvrées.
• 2-59/5 * * * * : toutes les 5 minutes avec un décalage à :02, :07, :12.
• */5 * * * 0,6 : toutes les 5 minutes le week-end.
• 0 */5 * * * : attention, toutes les 5 heures.

Erreur fréquente

Mettre */5 dans le deuxième champ change complètement le sens : le deuxième champ est l'heure. Pour un intervalle de minutes, le pas doit rester dans le premier champ.

Quand utiliser un intervalle de 5 minutes

Un cron toutes les 5 minutes est adapté aux tâches rapides qui doivent réagir souvent sans nécessiter de temps réel strict. C'est un bon choix pour vérifier une file de messages, rafraîchir un cache, synchroniser un petit flux, envoyer un heartbeat ou relancer une importation légère. L'intervalle est assez court pour limiter l'attente utilisateur, mais assez long pour éviter de transformer cron en boucle permanente.

Il faut toutefois mesurer la durée réelle du traitement. Si le script prend parfois 7 ou 8 minutes, */5 * * * * peut déclencher une nouvelle instance avant la fin de la précédente. Sur une machine peu chargée, cela peut passer inaperçu au début, puis créer des doublons ou une consommation CPU inutile. Pour une tâche qui manipule des paiements, des mails ou des exports clients, ajoutez un verrou avec flock, un fichier lock ou un contrôle applicatif.

Limiter aux heures utiles

Beaucoup de recherches "cron 5 min" cachent en réalité un besoin plus précis : toutes les 5 minutes, mais seulement pendant une plage horaire. Pour éviter de lancer une tâche inutile toute la nuit, restreignez le champ heure. */5 8-20 * * * couvre 08:00 à 20:55. Pour une activité de bureau du lundi au vendredi, utilisez */5 9-17 * * 1-5. Le dernier champ limite aux jours de semaine, sans notion de jours fériés.

Attention à l'inclusion des bornes. Une plage 9-17 inclut l'heure 17, donc la dernière exécution se produit à 17:55. Si vous voulez terminer strictement avant 18:00, c'est parfait. Si vous voulez arrêter à 17:00 pile, utilisez plutôt */5 9-16 * * 1-5 ou une logique de contrôle dans le script.

Décaler pour éviter les pics

Les minutes multiples de 5 sont très populaires. Sur un parc de serveurs, beaucoup de jobs partent à :00, :05, :10 et ainsi de suite. Si votre tâche appelle une API externe ou une base partagée, vous pouvez réduire les pics en décalant l'exécution. 2-59/5 * * * * déclenche à :02, :07, :12, :17, etc. Le rythme reste de 5 minutes, mais vous évitez le sommet de l'heure.

Cette technique est utile pour les crawlers internes, les synchronisations SaaS et les webhooks rejoués par lot. Elle ne garantit pas une distribution parfaite, mais elle améliore souvent la stabilité sans infrastructure supplémentaire. Dans une équipe, documentez ce choix : le décalage peut surprendre quelqu'un qui s'attend à voir une exécution exactement à :00.

Tester le résultat réel

Avant de mettre en production, collez l'expression dans le générateur et regardez les prochaines exécutions. Vous devez voir une série régulière toutes les 5 minutes. Ensuite, testez la commande séparément dans le même environnement que cron si possible. Cron utilise souvent un PATH minimal ; une commande qui marche dans votre terminal peut échouer si elle dépend d'une variable d'environnement, d'un répertoire courant ou d'une version de langage chargée par votre shell.

Préférez des chemins absolus : /usr/bin/php, /usr/local/bin/node, /opt/app/scripts/job.sh. Redirigez les logs avec >> /var/log/mon-job.log 2>&1. Un cron fréquent sans logs est difficile à diagnostiquer, car une erreur peut se répéter 288 fois par jour sans trace exploitable.

Quand éviter */5

Si le traitement ne sert qu'à préparer un rapport, une exécution toutes les 15 ou 30 minutes peut suffire. Gardez */5 pour les besoins où la fraîcheur a une vraie valeur : relance de file d'attente, contrôle de disponibilité, synchronisation courte ou surveillance applicative. Un intervalle trop agressif rend les logs bruyants et complique le diagnostic.