Aller au contenu
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉAvancé
MÉTIERSaaS multi-tenant
POURÉquipes de devs
POURDevs backend
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
SECTEURSaaS
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉAvancé
MÉTIERSaaS multi-tenant
POURÉquipes de devs
POURDevs backend
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
SECTEURSaaS
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉAvancé
MÉTIERSaaS multi-tenant
POURÉquipes de devs
POURDevs backend
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
SECTEURSaaS
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉAvancé
MÉTIERSaaS multi-tenant
POURÉquipes de devs
POURDevs backend
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
SECTEURSaaS
Retour aux cas d'usage
BYO cron / planning par tenant

Laissez vos clients définir leur propre cron.

vos clients tapent l'expression cron. vous la POST dans le crontab de leur container. Pas de queue partagée à arbitrer, pas d'intervalle minimal à imposer, pas de ticket support sur « pourquoi mon job n'a pas tourné le lundi en pic ».

Lire la doc API Cron

Le client tape dans votre UI. vous POST dans son container.

votre page de paramètres affiche un champ. Le conteneur du tenant expose une API Cron. Submit transmet un seul POST. Pas de scheduler global, pas de logique de filtrage par tenant, pas de plafond « max 100 jobs sur tous les clients ».

your-backend → tenant-conteneur
POST /users/root/entries
// le submit du formulaire relaie l'expression du client telle quelle
POST https://acme-cron.hoody.com/users/root/entries
Content-Type: application/json

{
  "schedule": "0 9 * * 1-5",
  "command": "/jobs/sync_crm.sh",
  "comment": "Sync Salesforce contacts",
  "enabled": true
}
tenant-conteneur → your-backend
201 Created
HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": "sch_8a3f1c",
  "schedule": "0 9 * * 1-5",
  "next_run": "2026-05-04T09:00:00Z",
  "enabled": true
}

// le planning est désormais dans le crontab de ce tenant et nulle part ailleurs

Le service Hoody Cron tourne dans chaque conteneur tenant avec des entrées managées et de l'isolation par utilisateur. Le planning vit là où le travail tourne.

Ce que le BYO cron vous donne et qu'un scheduler partagé ne peut pas.

Quand le planning vit à côté du travail, les règles du multi-tenant scheduling changent. Les contraintes sont locales. Le rayon d'impact est local. Les fonctionnalités sont locales.

pas de queue partagée

Pas de taxe d'arbitrage

Pas de pool de threads global à se disputer. votre tenant le plus exigeant tourne toutes les minutes et ne prive jamais les plus calmes — ils ne sont pas dans le même crontab.

self-service

Les clients se servent seuls, vous ne validez pas

vous cessez d'être le gardien de « est-ce que */1 * * * * est autorisé pour votre tier ? ». Leur conteneur, leur cron, leur facture CPU. votre boîte de support se vide.

lié au conteneur

Le planning voyage avec le tenant

Snapshot du conteneur tenant, snapshot du crontab. Rollback, restore, fork — les plannings suivent. Pas d'état de scheduler externe à synchroniser.

Scheduler multi-tenant partagé vs cron lié au container.

La différence se voit en trois endroits : l'expérience client, votre charge de support, et la surface d'ingénierie.

axescheduler partagéBYO cron conteneur
Ce que le client peut choisir
minimum 5 minutes, jours ouvrés seulement, pas d'exécutions concurrentesverrouillé par tier, règles d'arbitrage, reports en heures de pointe
Toute expression cron 5 champs que son conteneur peut gérer*/1 * * * * s'il le veut ; son CPU paie pour
Où la validation se passe
votre code, avant persist, contre un modèle de queue globaleregex + check de capacité + check de tier + check de chevauchement
Le daemon cron du conteneur parse l'expressionsyntaxe seule ; la capacité est celle d'un conteneur, pas de la flotte
Rayon d'impact en cas d'échec
Le job lent d'un tenant cale la queue pour tousincidents de ressources partagées, alerting sur la profondeur de queue
Le cron d'un conteneur ralentit un seul tenantisolation au niveau kernel ; le reste de la flotte ne s'en aperçoit pas

La version scheduler partagé de cette feature est une mer de réserves. La version BYO est un champ à cinq champs.

Ce qui disparaît quand le cron est par tenant.

Trois chiffres qui changent le jour où vous arrêtez de faire tourner une queue globale. Chacun correspond à une fonctionnalité que vous n'avez plus à coder ou à exploiter.

  1. règles de validation à maintenir0

    Plus d'intervalle minimum verrouillé par tier, plus de max-jobs-par-tenant, plus de boutons d'arbitrage. Le conteneur est la limite.

  2. POST par création de planning1×

    Le client tape, vous transmettez, le conteneur parse. Le submit de la page settings est un seul appel REST, pas une orchestration.

  3. champs que le client possède5

    minute · heure · jour-du-mois · mois · jour-de-la-semaine. Plus les macros (@hourly, @daily). POSIX standard, pas votre DSL.

Les chiffres reflètent le modèle BYO lié au conteneur — les entrées cron réelles scalent avec le CPU de chaque conteneur et le forfait du client.

L'expression cron du client est la sienne, pas à vous de la valider contre une queue globale.

scheduler partagéBYO cron par tenant
avantif (tier !== 'enterprise' && interval < 5min) reject()taxe de validation : chaque client payait pour le pire client
aprèsPOST /users/root/entries → 201 Createdle planning vit dans son conteneur ; son CPU, ses règles
Voir l'API Cron

Ce que ça remplace.

Les pièces d'infra qu'un cron BYO lié au conteneur met discrètement à la retraite.

  • schedulers multi-tenants partagéspas de queue globale à arbitrer
  • Quartz avec filtrage par tenantpas de colonne tenant_id sur chaque ligne de job
  • UIs cron-as-config maisonles clients tapent, le conteneur parse
  • Airflow managé par le fournisseurpas de service DAG pour une expression à 5 champs
  • Sidekiq partagé avec throttlingpas de rate limiter global entre tenants
  • BullMQ avec queues par tenantpas de Redis à entretenir par client

Arrêtez d'être le gardien du planning de quelqu'un d'autre. Donnez-lui le champ cron, donnez le travail à son container.

Lire la doc

Lis les autres