Cron toutes les 30 minutes

L'expression

*/30 * * * *  /chemin/vers/commande

Elle s'exécute à la minute 0 et à la minute 30 de chaque heure. La variante 0,30 * * * * est équivalente et parfois plus explicite pour une équipe.

Variantes

• 15,45 * * * * : deux fois par heure, décalé de 15 minutes.
• */30 7-22 * * * : toutes les 30 minutes de 7 h à 22 h.
• */30 * * * 1-5 : chaque demi-heure du lundi au vendredi.

*/30 ou 0,30 : quelle écriture choisir ?

Les deux expressions sont équivalentes dans le champ minute. */30 est compact et habituel pour les personnes qui lisent souvent des crontabs. 0,30 est plus explicite pour une équipe moins familière avec la syntaxe des pas. Si la page de configuration est relue par des profils non techniques, la liste peut être préférable, car elle montre directement les minutes concernées.

Le choix devient important quand l'intervalle ne démarre pas à zéro. 15,45 * * * * est plus clair que certaines écritures à base de plage et de pas. Pour une tâche qui doit partir à la demi-heure décalée, par exemple après la fin d'un traitement externe, la liste explicite limite les ambiguïtés. Le générateur affiche les prochaines dates, ce qui permet de valider immédiatement les deux formes.

Dans une documentation interne, indiquez les deux formes une fois, puis choisissez une convention unique pour tout le projet.

Cas d'usage typiques

Un cron toutes les 30 minutes convient aux tâches régulières qui tolèrent un délai raisonnable : import de commandes, génération de mini-rapports, vérification de certificats, synchronisation de fichiers, nettoyage de sessions ou contrôle d'un service externe. Il est moins agressif qu'un intervalle de 5 ou 15 minutes, mais reste suffisamment fréquent pour beaucoup d'applications internes.

Pour un site e-commerce, vous pouvez l'utiliser pour synchroniser un inventaire avec un ERP. Pour une équipe data, il peut déclencher une extraction légère vers un entrepôt. Pour une application SaaS, il peut envoyer les notifications groupées deux fois par heure. Dans chaque cas, le bon intervalle dépend de la fraîcheur attendue par l'utilisateur et du coût du traitement. Si personne ne consulte les données plus d'une fois par heure, un cron toutes les 30 minutes est souvent déjà confortable.

Limiter la plage horaire

L'expression */30 * * * * fonctionne jour et nuit. Si le traitement n'a de valeur qu'en journée, limitez l'heure. */30 8-19 * * 1-5 déclenche toutes les demi-heures du lundi au vendredi pendant une plage de travail. Si vous souhaitez inclure le samedi matin, vous pouvez écrire */30 8-12 * * 1-6. Le dernier champ reste le meilleur endroit pour exprimer les jours.

Gardez en tête que la plage d'heures inclut l'heure de fin. 8-19 déclenche à 19:00 et 19:30. Si cette dernière exécution est trop tardive, réduisez la plage ou ajoutez une condition dans le script. Cron exprime très bien des règles simples ; dès que la règle devient "jusqu'à 19:15 sauf le dernier jour du mois", un script de contrôle devient plus lisible.

Production : durée, idempotence et erreurs

Un traitement lancé toutes les demi-heures doit pouvoir être rejoué sans casser les données. C'est ce qu'on appelle l'idempotence : si le cron relance une synchronisation après une erreur, elle ne doit pas créer de doublons. Utilisez des identifiants stables, des dates de dernière synchronisation ou des statuts de traitement. Cron ne sait pas si la commande précédente a réussi ; il relance simplement selon l'horaire prévu.

Surveillez aussi la durée. Si un job prend 25 minutes quand tout va bien, la marge avant le passage suivant est faible. Un pic de charge peut suffire à provoquer un chevauchement. Ajoutez un verrou, ou passez à une exécution horaire. Les expressions cron les plus fiables sont celles qui laissent une marge confortable entre deux lancements.

Pour un traitement qui dépend d'un fichier entrant, vérifiez que le fichier est complet avant de le consommer. Une exécution à :30 peut tomber pendant qu'un autre système écrit encore les données.

À contrôler dans le générateur

Après avoir choisi */30, regardez les prochaines exécutions pour confirmer le fuseau horaire et les minutes exactes. C'est particulièrement important sur un serveur cloud configuré en UTC ou dans un outil qui affiche les dates en heure locale. Une expression correcte peut sembler décalée si l'environnement n'utilise pas le fuseau attendu par l'équipe.