Wann statt crontab ein anderer Scheduler sinnvoll ist
crontab war jahrzehntelang der Standard für die Zeitplanung unter Unix, doch heute gibt es je nach Zweck viele Alternativen zur Auswahl. Wichtig ist: Der Zeitplan-Ausdruck selbst verwendet meist dieselbe 5-Feld-cron-Syntax. Egal welche Plattform Sie also einsetzen, den Ausdruck können Sie zuerst mit diesem Tool überprüfen.
systemd-Timer sind die Standardalternative unter modernem Linux. Anders als cron kann man die Ausführungsprotokolle direkt mit journalctl einsehen, sie erlauben die Verwaltung von Abhängigkeiten zu Service-Units und mit der Option Persistent=true das Nachholen verpasster Aufgaben nach dem Start, während das System ausgeschaltet war. Allerdings ist die Zeitangabe nicht die cron-Syntax, sondern das OnCalendar-Format, das man separat erlernen muss.
Cloud- und Serverless-Scheduler sind in verwalteten Umgebungen beliebt. AWS EventBridge Scheduler, GCP Cloud Scheduler, Vercel Cron, Cloudflare Cron Triggers und andere nehmen meist standardmäßige cron-Ausdrücke unverändert entgegen, und man muss keinen Server selbst verwalten. Man sollte jedoch unbedingt beachten, dass die Ausführungszeitzone in der Regel UTC ist.
CI-Pipeline-Zeitpläne werden ebenfalls häufig genutzt. Das on: schedule von GitHub Actions oder die Pipeline-Zeitpläne von GitLab CI eignen sich gut, um Repository-Aufgaben (Tests, Deployment, Berichte) periodisch auszuführen. Sie verwenden die cron-Syntax, basieren aber auf UTC und können sich wegen der Runner-Wartezeit um einige Minuten gegenüber dem exakten Zeitpunkt verzögern.
Die Auswahlkriterien sind einfach. Für eine Aufgabe, die auf einem einzelnen Linux-Server läuft, sind cron oder systemd-Timer naheliegend; möchte man ohne eigenen Server verwaltet ausführen, ein Cloud-Scheduler; für eine mit dem Repository verknüpfte Aufgabe ein CI-Zeitplan. Prüfen Sie in jedem Fall die nächsten Ausführungszeitpunkte des Zeitplan-Strings mit diesem Interpreter, bevor Sie ihn einfügen.