Von Crontab migrieren

Eine Crontab feuert und vergisst. Es gibt keine Wiederholungsversuche, keine Timeouts, keinen Alert, wenn das Skript still scheitert, und kein Protokoll darüber, was gelaufen ist oder was es zurückgegeben hat. Diese Anleitung zeigt, wie eine typische Crontab auf ein SteadyCron-Manifest abgebildet wird, und erklärt, was Sie dabei gewinnen.

Eine typische Crontab

# /etc/cron.d/myapp
MAILTO=""

# Weekly digest — every Monday at 09:00 Berlin time
0 9 * * 1 www-data /var/www/myapp/bin/send-digest.sh

# Nightly DB backup — every day at 02:00
0 2 * * * www-data /var/www/myapp/bin/backup.sh >> /var/log/backup.log 2>&1

# 15-minute health sweep
*/15 * * * * www-data /var/www/myapp/bin/health-check.sh

Das entsprechende SteadyCron-Manifest

namespace: myapp

channels:
  - id: team-email
    kind: email
    email: oncall@myapp.com

jobs:
  # HTTP-Job: SteadyCron ruft den Endpunkt direkt auf.
  # Wiederholt bei Fehler; benachrichtigt über den Kanal, wenn es weiter fehlschlägt.
  - id: weekly-digest
    name: Weekly digest email
    kind: http
    method: POST
    url: https://api.myapp.com/jobs/send-digest
    schedule: "0 9 * * 1"
    timezone: Europe/Berlin
    timeout: 120
    retries: 3
    channel: team-email

  # Heartbeat: Das Backup-Skript pingt SteadyCron nach dem Abschluss.
  # SteadyCron alarmiert, wenn der Ping ausbleibt oder zu spät kommt.
  - id: nightly-backup
    name: Nightly DB backup
    kind: heartbeat
    schedule: "0 2 * * *"
    grace: 1800
    channel: team-email

  # Heartbeat: Das Health-Check-Skript pingt nach jedem Lauf.
  - id: health-sweep
    name: 15-minute health sweep
    kind: heartbeat
    schedule: "*/15 * * * *"
    grace: 120
    channel: team-email

Mapping-Regeln

Crontab-Konzept	SteadyCron-Äquivalent
Zeitplan-Ausdruck	schedule — gleiche 5-Feld-Cron-Syntax
MAILTO="" (E-Mail unterdrücken)	channel-Feld weglassen (keine Alerts)
Zeitzone via TZ=-Umgebungsvariable	timezone-Feld pro Job
Skript, das einen Endpunkt aufruft	kind: http-Job
Skript, das Sie kontrollieren (läuft auf Ihrem Server)	kind: heartbeat — Skript pingt SteadyCron bei Erfolg
Weiterleitung in Log-Datei	SteadyCron speichert vollständige Anfrage-/Antwort-Logs; keine Weiterleitung nötig
2>&1 (stderr erfassen)	SteadyCron erfasst sowohl Status als auch Body aus HTTP-Antworten

HTTP-Job vs. Heartbeat: Was soll ich verwenden?

Verwenden Sie kind: http, wenn Ihre Cron-Logik hinter einem HTTP-Endpunkt steckt, den Sie besitzen. SteadyCron ruft ihn nach Zeitplan auf, behandelt Wiederholungsversuche, protokolliert die Antwort und alarmiert bei Fehler. Ihr Crontab-Eintrag und das Shell-Skript werden überflüssig — der Endpunkt ist der Job.

Verwenden Sie kind: heartbeat, wenn:

• Das Skript direkt auf einem Server läuft (Shell, Python, PHP usw.)
• Sie keinen HTTP-Endpunkt exponieren können oder möchten
• Das Skript bereits existiert und Sie nur ein Monitoring wünschen

Für Heartbeats fügen Sie einen einzelnen curl-Aufruf zur SteadyCron-Ping-URL am Ende Ihres Skripts hinzu:

#!/bin/bash
set -euo pipefail

# ... Ihre Backup-Logik ...

# Erfolg an SteadyCron melden
curl -fsS https://ping.steadycron.com/{your-token}

Snippets für Python, Ruby, PHP, Node.js und weitere finden Sie unter Ping aus jeder Sprache.

Was Sie gewinnen

	Crontab	SteadyCron
Alerts bei Fehler	Nein	Ja — E-Mail, Slack, Discord, Telegram, Webhook
Alerts bei ausgebliebenem Lauf	Nein	Ja — mit konfigurierbarer Grace-Period
Wiederholungsversuche	Nein	Ja — pro Job konfigurierbar
Timeout-Durchsetzung	Nein	Ja — pro Job
Ausführungslog	Nein (Log-Rotation)	Ja — vollständige Anfrage-/Antwort-Historie
Versionskontrolle	Kaum	Ja — Manifest liegt in Ihrem Repository
Zeitzone pro Job	Über TZ=-Workarounds	Natives timezone-Feld
PR-Review für Änderungen	Nein	Ja — steadycron plan in CI

Nächste Schritte

1. Manifest anwenden: steadycron sync manifests/myapp.yaml
2. Für Heartbeat-Jobs: Ping-URL in Ihre Skripte einfügen
3. CI für Reviews einrichten: CI/CD-Einrichtung
4. Für bestehende Dashboard-Jobs: Zu IaC migrieren