Exemples cron prêts à copier

Intervalles courants

Quotidien et hebdomadaire

Mensuel et annuel

• 0 0 1 * * : le 1er de chaque mois à minuit.
• 30 2 1 * * : le 1er de chaque mois à 02:30.
• 0 0 1 1 * : le 1er janvier à minuit.
• 0 6 15 1,4,7,10 * : le 15 de chaque trimestre à 06:00.

Exemples pour sauvegardes

Une sauvegarde quotidienne simple peut utiliser 30 2 * * *, ce qui évite le pic de minuit. Pour une sauvegarde hebdomadaire complète, 0 3 * * 0 lance le dimanche à 03:00. Pour une sauvegarde mensuelle d'archive, 0 4 1 * * cible le premier jour du mois à 04:00. Ces horaires sont volontairement nocturnes, mais ils doivent être adaptés à l'activité réelle du serveur.

La commande doit être robuste. Une ligne comme 0 3 * * 0 /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1 garde une trace des erreurs. Si la sauvegarde peut durer longtemps, ajoutez un verrou pour éviter deux exécutions simultanées. Pour les sauvegardes critiques, cron ne suffit pas : vérifiez aussi la présence du fichier produit, la taille, la restauration possible et l'envoi d'une alerte en cas d'échec.

Exemples pour rapports et notifications

Un rapport d'équipe est souvent lié au calendrier humain. 0 8 * * 1 envoie un rapport chaque lundi matin. 0 18 * * 5 produit un récapitulatif de fin de semaine le vendredi soir. 30 7 * * 1-5 peut préparer un tableau de bord avant l'arrivée des équipes. Ces expressions sont plus utiles qu'un simple @weekly, car elles documentent le moment exact attendu.

Pour les notifications, évitez les horaires qui dérangent les utilisateurs. Un cron qui envoie des mails à minuit peut être techniquement correct mais mauvais côté produit. Restreignez aux heures ouvrées si le message concerne une action humaine. Si les destinataires sont répartis sur plusieurs fuseaux horaires, cron devient vite insuffisant : déclenchez un traitement régulier, puis laissez l'application décider qui doit recevoir quoi selon son fuseau local.

Exemples pour synchronisations API

Les synchronisations API utilisent souvent des intervalles courts. */15 * * * * convient à une synchronisation modérée. */5 * * * * est utile si la fraîcheur est importante, mais il consomme trois fois plus d'appels. 7-59/15 * * * * décale les appels pour éviter les pics à :00, :15, :30 et :45.

Avant de choisir l'intervalle, regardez les quotas de l'API, la durée moyenne du job et le volume de données modifiées. Si l'API propose des webhooks, cron peut servir de filet de sécurité plutôt que de mécanisme principal. Une bonne stratégie consiste à écouter les événements en temps réel, puis à lancer un cron horaire ou quotidien de réconciliation pour corriger les oublis. L'expression cron reste simple, mais l'architecture devient plus fiable.

Adapter un exemple avant de le copier

Un exemple cron trouvé en ligne doit toujours être adapté. Vérifiez le fuseau horaire, le chemin de la commande, l'utilisateur d'exécution, les variables d'environnement et le comportement en cas d'échec. Les exemples de cette page montrent le rythme, pas toute la configuration système. Dans une crontab utilisateur, cinq champs précèdent la commande. Dans /etc/crontab ou /etc/cron.d, un champ utilisateur peut être nécessaire.

Utilisez le générateur pour confirmer les prochaines exécutions, puis testez la commande seule. Ajoutez des chemins absolus et des logs. Si la tâche modifie des données, rendez-la idempotente afin qu'une relance ne crée pas de doublons. Les expressions comme 0 9 * * 1-5 sont faciles à copier ; la qualité en production dépend surtout de la commande et de sa capacité à échouer proprement.

Gardez aussi une convention de nommage. Un script appelé weekly-report.sh ou sync-orders-every-15-min.sh rend la crontab plus compréhensible qu'une commande générique sans contexte.

Construire votre propre exemple

Si aucun exemple ne correspond exactement, partez de la question métier : fréquence, heure, jours autorisés, fuseau horaire et durée maximale. Écrivez ensuite les champs dans cet ordre, puis vérifiez la série dans le générateur. Cette méthode fonctionne mieux qu'une recherche au hasard, surtout pour les expressions longues comme un cron de semaine, un cron mensuel décalé ou un traitement qui doit éviter le week-end.