Cron toutes les heures

L'expression

0 * * * *  /chemin/vers/commande
@hourly     /chemin/vers/commande

Le premier champ vaut 0, donc la tâche part à la minute zéro. Le deuxième champ vaut *, donc toutes les heures sont autorisées.

Variantes

• 15 * * * * : à la minute 15 de chaque heure.
• 0 */2 * * * : toutes les 2 heures.
• 0 9-18 * * 1-5 : chaque heure, pendant les horaires ouvrés.

Choisir la minute de déclenchement

0 * * * * est clair, mais l'heure pile n'est pas toujours le meilleur choix. Beaucoup de services lancent leurs tâches à :00 : rotations de logs, exports, sauvegardes, contrôles de monitoring. Si votre job appelle une API ou une base déjà sollicitée, choisissez une minute décalée comme 7 * * * * ou 23 * * * *. Le sens reste "toutes les heures", mais la charge se répartit mieux.

Cette approche est utile pour les traitements non urgents : rafraîchir un cache, agréger des statistiques, récupérer un flux ou envoyer un digest. Pour une tâche liée à un reporting humain, une exécution à :05 ou :10 peut aussi laisser le temps aux systèmes sources de finir leurs propres traitements horaires. Une expression cron doit refléter le rythme métier, pas seulement la forme la plus courte.

Si plusieurs jobs horaires existent sur le même serveur, répartissez-les volontairement : un à :05, un à :17, un à :41. Cette simple convention rend les graphes de charge plus propres et facilite l'analyse quand un traitement ralentit. Elle évite aussi les fausses alertes liées à un pic parfaitement prévisible.

Toutes les heures ou toutes les N heures

Le champ heure accepte lui aussi les pas. 0 */2 * * * signifie toutes les deux heures, à la minute 0. 0 */6 * * * déclenche à 00:00, 06:00, 12:00 et 18:00. C'est pratique pour des contrôles moins fréquents, comme une vérification de certificat, une purge légère ou une synchronisation d'annuaire.

Si vous voulez une série qui ne démarre pas à minuit, utilisez une plage. 0 1-23/6 * * * déclenche à 01:00, 07:00, 13:00 et 19:00. Cette syntaxe est plus précise, mais aussi moins lisible. Dans une crontab de production, ajoutez un commentaire au-dessus de ce type de ligne. Le générateur peut confirmer les prochaines dates, mais la personne qui maintiendra la crontab appréciera une explication directe.

Restreindre aux jours et horaires métier

Un cron horaire permanent peut produire beaucoup d'exécutions inutiles. Si le job n'a de sens que lorsque l'équipe travaille, ajoutez une plage d'heures et de jours : 0 8-18 * * 1-5. Cette expression lance la tâche chaque heure de 8 h à 18 h du lundi au vendredi. Pour un support client avec activité le samedi, 0 8-12 * * 1-6 couvre les matinées du lundi au samedi.

Cron ne connaît pas les jours fériés. Si vous devez éviter les jours non travaillés en France, en Belgique ou au Canada, placez la logique dans le script. Le cron peut lancer tous les jours ouvrés théoriques, puis le script vérifie un calendrier. Cette séparation garde l'expression simple et rend les règles locales plus faciles à modifier.

Surveiller un cron horaire

Une tâche horaire échoue 24 fois par jour si elle est cassée. Il faut donc éviter les crons silencieux. Redirigez les sorties, remontez les erreurs dans votre monitoring, et prévoyez un message clair quand le script ne peut pas terminer. Les tâches horaires sont souvent perçues comme "peu critiques", jusqu'au jour où un cache n'est plus rafraîchi ou un rapport n'est plus envoyé.

Vérifiez aussi les hypothèses d'environnement. Cron ne charge pas toujours les mêmes fichiers de profil que votre session shell. Les variables comme PATH, NODE_ENV, PYTHONPATH ou les secrets applicatifs peuvent manquer. Utilisez des chemins absolus et chargez explicitement les fichiers d'environnement nécessaires. Une expression correcte ne suffit pas si la commande ne peut pas s'exécuter dans le contexte réel de cron.

Pour les jobs qui produisent un indicateur métier, ajoutez une vérification externe : fichier attendu, ligne créée en base, compteur mis à jour ou ping de fin d'exécution. Un cron peut être lancé à l'heure sans que le traitement ait réellement réussi. Cette différence entre "déclenché" et "terminé" est essentielle en production.

Valider la forme courte @hourly

@hourly est pratique, mais 0 * * * * reste plus explicite dans une documentation ou une revue d'exploitation. Si vous utilisez l'alias, gardez un commentaire qui précise la minute de départ et le fuseau attendu. Le générateur accepte les deux formes pour aider à comparer la lecture humaine et la ligne réellement copiée.