Soixante conteneurs sur un seul serveur
Une seule machine bare-metal fait tourner des dizaines à des centaines de conteneurs Hoody. La déduplication KSM et BTRFS rend le coût marginal quasi nul.
Postez une entrée cron lundi avec expires_at à vendredi 09:00. Le job page votre téléphone toutes les 30 minutes pendant quatre jours, puis se supprime au moment où le shift se termine. Le prochain d'astreinte poste la sienne. Pas de PagerDuty, pas de config scheduler partagée, pas de rappel de calendrier pour la désactiver.
l'entrée qui page m.dossantos existe seulement tant que m.dossantos est d'astreinte
Trois points dans la semaine. L'existence de l'entrée cron suit le shift exactement — pas de chevauchement, pas de trou, pas de ligne crontab orpheline.
Un curl avec schedule */30, command pointant sur hoody-notifications/push/me, et expires_at = vendredi 09:00:00Z. Le serveur renvoie l'id e7d3.
Toutes les 30 minutes pendant quatre jours, l'entrée tourne et ping hoody-notifications. Seulement votre appareil. Le canal d'équipe reste calme.
À 09:00:00Z le service cron supprime e7d3. Le tick de 09:30 n'a rien à déclencher. Le prochain d'astreinte a déjà posté la sienne.
Chaque astreinte écrit un POST quand son shift commence. Le champ expires_at est tout le protocole de passation — le service cron fait le nettoyage, à la seconde près.
Tout le protocole de rotation tient en deux appels HTTP par semaine. L'astreinte poste lundi, liste vendredi, voit que l'entrée a déjà disparu. Il n'y a pas de fichier de schedule partagé à merger.
# monday 09:00 — i'm on call until friday 09:00 curl -X POST \ https://oncall.containers.hoody.com/users/me/entries \ -H "Content-Type: application/json" \ -d '["schedule":"*/30 * * * *","command":"curl -fsS hoody-notifications/push/m.dossantos","comment":"on-call wk19","expires_at":"2026-05-08T09:00:00Z"]' # response HTTP/1.1 201 Created { "id":"e7d3", "expires_at":"2026-05-08T09:00:00Z", "enabled":true }
# friday 09:01 — the next on-call took over curl GET https://oncall.containers.hoody.com/users/me/entries HTTP/1.1 200 OK [ // my entry e7d3 is gone — it expired // at 09:00 sharp. j.okafor's new // entry took over at 09:00:30. ] # no slack thread, no calendar reminder
Aucun service de scheduler partagé n'est impliqué. L'entrée cron appartient à l'ingénieur ; rien dans le setup du prochain d'astreinte ne dépend du précédent qui aurait nettoyé.
Une entrée d'astreinte qui possède sa propre durée de vie élimine trois classes d'erreurs que les configs PagerDuty et les rappels de calendrier ne peuvent pas.
Parce que la commande de l'entrée pointe sur votre endpoint de notification personnel, les escalades vont sur votre téléphone pendant la durée de votre shift, et seulement ça. Pas de spam accidentel sur le canal d'équipe à 3h du matin.
Il n'y a pas d'escalation_policy.yaml que tout le monde touche. Chaque ingénieur possède son entrée. Deux astreintes dans des fuseaux horaires différents ne peuvent pas entrer en conflit en éditant le même fichier.
Quand vendredi 09:00 arrive vous ne demandes pas 'attends, je reçois encore ces pings ?' L'entrée a déjà disparu. Vérifier la passation est un GET qui renvoie une ligne en moins.
Les chiffres viennent de l'API Hoody Cron. Vraies limites, pas inventées.
L'auto-expiration tourne contre l'horloge système. Un expires_at à 09:00:00Z supprime dans la même minute que le tick cron — pas de latence janitor de 5 minutes.
Expressions cron standard à 5 champs plus les macros @hourly / @daily / @weekly. */30 * * * * est ce qui se déclenche toutes les 30 minutes pendant votre shift.
Chaque utilisateur système a son propre crontab. L'entrée du prochain d'astreinte vit sous son propre /users/[name]/entries — sans jamais toucher à la tienne.
Limites selon l'API Hoody Cron : entrées managées en JSON CRUD avec UUID et expires_at ; accès au crontab brut disponible par utilisateur ; isolation crontab par utilisateur intégrée.
Quand le shift se termine, l'entrée cron aussi — automatiquement.
Les outils standard quand vous voulez des rotations d'astreinte. Chacun te facture un service, un repo de config et un rituel de passation. Une entrée cron avec expires_at te facture un POST.
Arrêtez de désactiver les lignes crontab le vendredi matin. Mettez expires_at le lundi et oubliez-le.