Cron as Code

Le cron en code,
de bout en bout

Q: Puis-je l'utiliser dans mon pipeline CI/CD ?

Oui — c'est le workflow recommandé. La GitHub Action steadycron/action@v1 exécute plan sur les pull requests (en publiant un commentaire persistant) et apply au merge — pour YAML (tool: yaml) comme pour Terraform (tool: terraform). Voir le guide de configuration CI/CD.

Q: Mes clés API ou secrets sont-ils un jour stockés en code ?

Non. Dans le manifeste, les placeholders ${ENV_VAR} sont substitués par la CLI au moment de l'application, et les valeurs {{template_var}} sont résolues côté serveur à l'exécution — steadycron export génère les deux automatiquement. En Terraform, les secrets sont déclarés comme des variables sensitive et fournies au moment de l'apply.

Déclarez chaque tâche, monitor, canal et règle d'alerte en YAML ou Terraform. Examinez les changements dans des pull requests, appliquez-les depuis GitHub Actions, et observez l'exécution depuis votre application avec les SDK .NET et Python — tout depuis un seul dépôt.

Démarrer gratuitement Lire la documentation

Offre gratuite — sans carte bancaire.

1
Déclarer

Déclarez tâches, monitors, canaux & règles.

YAMLTerraform
2
Réconcilier

validate → plan → apply. Aucune dérive.

CLIProvider
3
Déployer

Plan à chaque PR, apply au merge.

GitHub Actions
4
Observer

Observez l'exécution depuis votre app.

.NETPython

1 · Déclarer

Choisissez votre dialecte.
Même résultat.

Un seul fichier déclare tout votre compte — tâches HTTP, monitors heartbeat, canaux d'alerte, règles, tags et variables. Écrivez-le comme un manifeste YAML ou comme du HCL Terraform ; les deux expriment les mêmes ressources et réconcilient de la même façon.

Utilisez le manifeste si vous voulez un seul fichier autonome. Tournez-vous vers Terraform si le cron doit vivre aux côtés du reste de votre infrastructure. La parité est le propos — aucun des deux n'est un citoyen de seconde classe.

Référence du manifeste Provider Terraform

# steadycron.yaml — your whole account as code
version: 2
namespace: prod

channels:
  - id: ops-slack
    kind: slack
    config:
      webhook_url: ${SLACK_WEBHOOK_URL}

jobs:
  - id: weekly-digest
    kind: http
    method: POST
    url: https://api.myapp.com/jobs/digest
    schedule: "0 9 * * 1"
    timezone: Europe/Berlin
    timeout: 120
    retries: 3
    rules:
      - channel: ops-slack
        trigger: on_failure

  - id: nightly-db-backup
    kind: heartbeat
    schedule: "0 2 * * *"
    grace: 1800

# main.tf — the same account, in HCL
resource "steadycron_alert_channel" "ops_slack" {
  name              = "ops-slack"
  kind              = "slack"
  slack_webhook_url = var.slack_webhook_url
}

resource "steadycron_http_job" "weekly_digest" {
  name            = "weekly-digest"
  method          = "POST"
  url             = "https://api.myapp.com/jobs/digest"
  cron_expression = "0 9 * * 1"
  timezone        = "Europe/Berlin"
  timeout_seconds = 120
  max_retries     = 3
}

resource "steadycron_alert_rule" "digest_failure" {
  job_id     = steadycron_http_job.weekly_digest.id
  channel_id = steadycron_alert_channel.ops_slack.id
  trigger    = "on_failure"
}

resource "steadycron_heartbeat_monitor" "db_backup" {
  name            = "nightly-db-backup"
  key             = "nightly-db-backup"
  cron_expression = "0 2 * * *"
  grace_seconds   = 1800
}

Terminal

$ steadycron validate steadycron.yaml
✓ 2 jobs · 1 channel · 1 rule — no errors

$ steadycron plan steadycron.yaml --namespace prod
  ~ weekly-digest      update     retries: 2 → 3
  + nightly-db-backup  create     heartbeat · 0 2 * * *
  1 to update · 1 to create

$ steadycron sync steadycron.yaml --namespace prod
✓ applied — account now matches the manifest

2 · Réconcilier

validate → plan → apply. Aucune surprise.

La CLI steadycron réconcilie votre compte pour correspondre au manifeste. plan montre exactement ce qui changerait, sync l'applique de manière transactionnelle, et --prune supprime ce que vous avez retiré — limité à un namespace pour que le rayon d'impact soit toujours explicite.

→export adopte un compte existant dans un manifeste en quelques secondes.
→import crontab / import vercel migrent les plannings existants.
→Vous utilisez Terraform ? terraform plan / apply / import pilotent exactement le même cycle.

Workflow CLI & IaC

3 · Déployer

Plan à chaque PR. Apply au merge.

La GitHub Action steadycron/action@v1 publie un commentaire de plan persistant sur chaque pull request — les relecteurs voient exactement quelles tâches, monitors, canaux et règles un changement introduit — puis l'applique au merge. Votre branche principale est la source de vérité.

La même action pilote les deux outils : définissez tool: yaml pour les manifestes ou tool: terraform pour le HCL.

Configuration CI/CD

steadycron bot a commenté ce PR

Plan : 1 mise à jour · 1 création · 1 suppression

~ weekly-digest      update   retries: 2 → 3
+ invoice-reminder   create   http · 0 17 * * 5
- old-report         delete   (removed from manifest)

# .github/workflows/cron.yml
- uses: steadycron/action@v1
  with:
    command: plan          # 'apply' on merge to main
    manifest: steadycron.yaml
    comment-on-pr: "true"
  env:
    STEADYCRON_API_KEY: ${{ secrets.STEADYCRON_API_KEY }}

4 · Observer

La tâche et le code qui la surveille — même key, même dépôt.

Déclarez un monitor heartbeat avec un key stable en YAML ou Terraform. Référencez exactement ce key depuis votre application avec le SDK .NET ou Python. SteadyCron sait alors quand la tâche a démarré, réussi, échoué, ou ne s'est jamais exécutée.

Les SDK ne créent jamais de monitors — ils résolvent le key avec une clé API en lecture seule, et les pings sont fire-and-forget : une panne de surveillance n'interrompt jamais votre tâche. Planning, règles d'alerte et instrumentation vivent ensemble, en code.

SDK Python SDK .NET Surveillance heartbeat

Dans votre manifeste / HCL

key: nightly-db-backup

import steadycron

@steadycron.job("nightly-db-backup")   # same key
def backup():
    run_backup()   # start · success · fail — automatic

// same key as the manifest
await monitor.TrackAsync("nightly-db-backup", async ct =>
{
    await RunBackupAsync(ct);
});

Le cycle complet en code

Planning, surveillance, routage d'alertes et instrumentation côté application — un dépôt, une revue, un déploiement.

Hébergé en UE, conforme RGPD

Fonctionne sur Hetzner en Allemagne, régi par le droit allemand. Aucun sous-traitant américain pour l'exécution cron ou les données des tâches.

Des outils que vous utilisez déjà

YAML ou Terraform, une CLI dédiée, une GitHub Action et des SDK officiels — pas de DSL maison, pas de dépendance à une console.

FAQ

Questions fréquentes

Manifeste YAML ou Terraform — lequel utiliser ?

Celui que votre équipe a déjà standardisé. Le manifeste YAML avec la CLI steadycron est autonome et ne nécessite aucun autre outillage ; le provider Terraform s'intègre naturellement si vous utilisez déjà Terraform. Les deux expriment les mêmes ressources et partagent le même cycle plan / apply / import. Gérez une ressource donnée avec un seul outil, pas les deux.

Puis-je l'utiliser dans mon pipeline CI/CD ?

Oui — c'est le workflow recommandé. La GitHub Action steadycron/action@v1 exécute plan sur les pull requests (en publiant un commentaire persistant) et apply au merge — pour YAML (tool: yaml) comme pour Terraform (tool: terraform). Voir le guide de configuration CI/CD.

Les SDK .NET et Python créent-ils les monitors ?

Non. Les SDK ne font qu'envoyer des pings — ils résolvent un monitor par son key stable en utilisant une clé API en lecture seule. Déclarez d'abord le monitor heartbeat en YAML ou Terraform, puis référencez ce même key depuis le code de votre application.

Mes clés API ou secrets sont-ils un jour stockés en code ?

Non. Dans le manifeste, les placeholders ${ENV_VAR} sont substitués par la CLI au moment de l'application, et les valeurs {{template_var}} sont résolues côté serveur à l'exécution — steadycron export génère les deux automatiquement. En Terraform, les secrets sont déclarés comme des variables sensitive et fournies au moment de l'apply.

Gérer les tâches en code remplace-t-il le tableau de bord ?

Non. Les namespaces permettent aux tâches gérées en code et aux tâches créées via le tableau de bord de coexister dans un même compte. Seules les ressources dans le namespace de votre manifeste sont concernées par --prune — tout le reste est laissé intact.

Qu'arrive-t-il à mon URL de ping heartbeat si je renomme une tâche ?

Rien ne change. L'URL de ping de chaque tâche est liée à son id / key stable, pas à son nom affiché — un renommage n'est donc qu'un renommage, et vos scripts et références SDK continuent de fonctionner.

Une plateforme, trois métiers

Exécution HTTP

Appelez vos endpoints à l’heure prévue — réessais, délais et journaux complets.

Surveillance heartbeat

Surveillez les tâches que vous exécutez partout ; soyez alerté dès qu’une se tait.

Cron as code

Vous êtes ici

Déclarez chaque tâche, moniteur et alerte en YAML ou Terraform.

Des tâches cron qui vivent dans votre dépôt

Inscrivez-vous, exportez votre compte actuel, et committez votre premier manifeste en quelques minutes — en YAML ou en Terraform.

Démarrer gratuitement Lire la documentation

Offre gratuite — sans carte bancaire
YAML ou Terraform — support équivalent
Hébergé en UE, conforme RGPD

Le cron en code,de bout en bout

Déclarer

Réconcilier

Déployer

Observer

Choisissez votre dialecte.Même résultat.