Cron as Code

Cron als Code,
Ende zu Ende

Q: Kann ich das in meiner CI/CD-Pipeline nutzen?

Ja — das ist der empfohlene Workflow. Die GitHub Action steadycron/action@v1 führt plan bei Pull Requests aus (mit einem aktualisierenden Kommentar) und apply beim Merge — für YAML (tool: yaml) und Terraform (tool: terraform). Siehe die CI/CD-Einrichtungsanleitung.

Q: Werden meine API-Schlüssel oder Secrets jemals als Code gespeichert?

Nein. Im Manifest werden ${ENV_VAR}-Platzhalter von der CLI zum Zeitpunkt der Anwendung ersetzt, und {{template_var}}-Werte werden serverseitig zur Laufzeit aufgelöst — steadycron export erzeugt beides automatisch. In Terraform werden Secrets als sensitive-Variablen deklariert und beim Apply bereitgestellt.

Deklarieren Sie jeden Job, Monitor, Kanal und jede Alert-Regel in YAML oder Terraform. Überprüfen Sie Änderungen in Pull Requests, wenden Sie sie aus GitHub Actions an, und beobachten Sie den Lauf aus Ihrer Anwendung heraus mit den .NET- und Python-SDKs — alles aus einem Repository.

Kostenlos starten Dokumentation lesen

Kostenloser Tarif — keine Kreditkarte erforderlich.

1
Deklarieren

Jobs, Monitore, Kanäle & Regeln deklarieren.

YAMLTerraform
2
Abgleichen

validate → plan → apply. Keine Drift.

CLIProvider
3
Ausrollen

Plan bei jedem PR, Apply beim Merge.

GitHub Actions
4
Beobachten

Den Lauf aus Ihrer Anwendung beobachten.

.NETPython

1 · Deklarieren

Wählen Sie Ihren Dialekt.
Gleiches Ergebnis.

Eine Datei deklariert Ihr gesamtes Konto — HTTP-Jobs, Heartbeat-Monitore, Alert-Kanäle, Regeln, Tags und Variablen. Schreiben Sie sie als YAML-Manifest oder als Terraform-HCL; beide drücken dieselben Ressourcen aus und gleichen auf demselben Weg ab.

Nutzen Sie das Manifest, wenn Sie eine einzige, eigenständige Datei möchten. Greifen Sie zu Terraform, wenn Cron neben dem Rest Ihrer Infrastruktur leben soll. Die Gleichwertigkeit ist der Punkt — keines von beiden ist zweite Wahl.

Manifest-Referenz Terraform-Provider

# 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 · Abgleichen

validate → plan → apply. Keine Überraschungen.

Die steadycron-CLI gleicht Ihr Konto mit dem Manifest ab. plan zeigt genau, was sich ändern würde, sync wendet es transaktional an, und --prune löscht, was Sie entfernt haben — begrenzt auf einen Namespace, sodass der Wirkungsradius immer eindeutig ist.

→export übernimmt ein bestehendes Konto in Sekunden in ein Manifest.
→import crontab / import vercel migrieren bestehende Zeitpläne.
→Nutzen Sie Terraform? terraform plan / apply / import treiben genau denselben Kreislauf an.

CLI- & IaC-Workflow

3 · Ausrollen

Plan bei jedem PR. Apply beim Merge.

Die GitHub Action steadycron/action@v1 postet einen aktualisierenden Plan-Kommentar an jedem Pull Request — Reviewer sehen genau, welche Jobs, Monitore, Kanäle und Regeln eine Änderung einführt — und wendet sie dann beim Merge an. Ihr Main-Branch ist die Quelle der Wahrheit.

Dieselbe Action steuert beide Werkzeuge: setzen Sie tool: yaml für Manifeste oder tool: terraform für HCL.

CI/CD-Einrichtung

steadycron Bot hat diesen PR kommentiert

Plan: 1 Update · 1 Erstellung · 1 Löschung

~ 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 · Beobachten

Der Job und der Code, der ihn beobachtet — gleicher Key, gleiches Repository.

Deklarieren Sie einen Heartbeat-Monitor mit einem stabilen key in YAML oder Terraform. Referenzieren Sie genau diesen Key aus Ihrer Anwendung mit dem .NET- oder Python-SDK. SteadyCron weiß dann, wann der Job gestartet, erfolgreich war, fehlgeschlagen ist oder nie lief.

Die SDKs erstellen niemals Monitore — sie lösen den Key mit einem Nur-Lesen-API-Schlüssel auf, und Pings sind Fire-and-Forget: Ein Ausfall des Monitorings legt nie Ihren Job lahm. Zeitplan, Alert-Regeln und Instrumentierung leben gemeinsam als Code.

Python-SDK .NET-SDK Heartbeat-Monitoring

In Ihrem Manifest / 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);
});

Der gesamte Kreislauf als Code

Zeitplan, Monitoring, Alert-Routing und die Instrumentierung in der App — ein Repository, ein Review, ein Deploy.

EU-gehostet, DSGVO-konform

Läuft auf Hetzner in Deutschland, nach deutschem Recht. Keine US-Subunternehmer für Cron-Ausführung oder Job-Daten.

Werkzeuge, die Sie bereits nutzen

YAML oder Terraform, eine dedizierte CLI, eine GitHub Action und First-Party-SDKs — keine eigene DSL, keine Bindung an eine Konsole.

FAQ

Häufige Fragen

YAML-Manifest oder Terraform — was soll ich nutzen?

Was auch immer sich Ihr Team schon als Standard ausgesucht hat. Das YAML-Manifest mit der steadycron-CLI ist eigenständig und braucht kein weiteres Tooling; der Terraform-Provider passt natürlich, wenn Sie schon Terraform einsetzen. Beide drücken dieselben Ressourcen aus und teilen sich denselben plan / apply / import-Kreislauf. Verwalten Sie eine bestimmte Ressource mit einem Werkzeug, nicht beiden.

Kann ich das in meiner CI/CD-Pipeline nutzen?

Ja — das ist der empfohlene Workflow. Die GitHub Action steadycron/action@v1 führt plan bei Pull Requests aus (mit einem aktualisierenden Kommentar) und apply beim Merge — für YAML (tool: yaml) und Terraform (tool: terraform). Siehe die CI/CD-Einrichtungsanleitung.

Erstellen die .NET- und Python-SDKs die Monitore?

Nein. Die SDKs senden nur Pings — sie lösen einen Monitor über seinen stabilen key mit einem Nur-Lesen-API-Schlüssel auf. Deklarieren Sie den Heartbeat-Monitor zuerst in YAML oder Terraform und referenzieren Sie denselben Key dann aus Ihrem Anwendungscode.

Werden meine API-Schlüssel oder Secrets jemals als Code gespeichert?

Nein. Im Manifest werden ${ENV_VAR}-Platzhalter von der CLI zum Zeitpunkt der Anwendung ersetzt, und {{template_var}}-Werte werden serverseitig zur Laufzeit aufgelöst — steadycron export erzeugt beides automatisch. In Terraform werden Secrets als sensitive-Variablen deklariert und beim Apply bereitgestellt.

Ersetzt die Verwaltung von Jobs als Code das Dashboard?

Nein. Namespaces lassen code-verwaltete und im Dashboard erstellte Jobs in einem Konto koexistieren. Nur Ressourcen innerhalb des Namespace Ihres Manifests werden von --prune berührt — alles andere bleibt unangetastet.

Was passiert mit meiner Heartbeat-Ping-URL, wenn ich einen Job umbenenne?

Nichts ändert sich. Die Ping-URL jedes Jobs ist an seine stabile id / key gebunden, nicht an seinen Anzeigenamen — eine Umbenennung ist also nur eine Umbenennung, und Ihre Skripte und SDK-Referenzen funktionieren weiter.

Eine Plattform, drei Aufgaben

HTTP-Ausführung

Endpunkte planmäßig aufrufen — Wiederholungen, Timeouts und vollständige Laufprotokolle.

Heartbeat-Monitoring

Überwachen Sie Jobs, die Sie überall betreiben — Alarm, sobald einer verstummt.

Cron as Code

Sie sind hier

Jeden Job, Monitor und Alert in YAML oder Terraform definieren.

Cronjobs, die in Ihrem Repository leben

Registrieren Sie sich, exportieren Sie Ihr aktuelles Konto und committen Sie Ihr erstes Manifest in wenigen Minuten — in YAML oder Terraform.

Kostenlos starten Dokumentation lesen

Kostenloser Tarif — keine Kreditkarte
YAML oder Terraform — gleichwertig unterstützt
EU-gehostet, DSGVO-konform

Cron als Code,Ende zu Ende

Deklarieren

Abgleichen

Ausrollen

Beobachten

Wählen Sie Ihren Dialekt.Gleiches Ergebnis.

validate → plan → apply. Keine Überraschungen.

Plan bei jedem PR. Apply beim Merge.

Der Job und der Code, der ihn beobachtet — gleicher Key, gleiches Repository.

Warum SteadyCron für Cron as Code

Der gesamte Kreislauf als Code

EU-gehostet, DSGVO-konform

Werkzeuge, die Sie bereits nutzen

Häufige Fragen

HTTP-Ausführung

Heartbeat-Monitoring

Cron as Code

Cronjobs, die in Ihrem Repository leben

Cron als Code,
Ende zu Ende

Wählen Sie Ihren Dialekt.
Gleiches Ergebnis.