Cron-Tester: Cron-Ausdrücke prüfen, Termine sehen und in systemd-Timer umrechnen

Ein Cronjob, der zur falschen Zeit oder gar nicht läuft, fällt oft erst auf, wenn das Backup fehlt. Der Cron-Tester auf s-edv.com übersetzt einen Cron-Ausdruck in Klartext, listet die nächsten zehn Ausführungen auf, erzeugt die passenden crontab-Zeilen und rechnet den Zeitplan in einen systemd-Timer um. Diese Anleitung richtet sich an Admins und Entwickler in kleinen und mittleren Betrieben, die Wartungsaufgaben, Datenbank-Dumps oder Berichte auf Linux-Servern planen. Sie zeigt die Bedienung, erklärt die Warnungen des Tools und beschreibt, wie Sie das Ergebnis mit systemd-analyze auf dem Server gegenprüfen.

Voraussetzungen

• Ein aktueller Browser für das Tool.
• Für den Einsatz: ein Linux-Server oder eine VM mit Shell-Zugang, auf dem cron (etwa cronie oder das Debian-Paket cron) oder systemd läuft. Für die Gegenprobe genügt systemd-analyze, das auf jedem systemd-System vorhanden ist; getestet wurde mit systemd 259 unter Ubuntu.
• Root- oder sudo-Rechte, wenn Sie Einträge unter /etc/cron.d/ oder Units unter /etc/systemd/system/ anlegen.
• Ein Skript mit absolutem Pfad, das Sie planen wollen, zum Beispiel /usr/local/bin/backup.sh.
• Grundkenntnisse zu crontab. Wer neu einsteigt, liest zuerst Cron und crontab richtig nutzen.

Ein kleiner Server mit einem Kern und 1 GB RAM reicht für geplante Aufgaben völlig; entscheidend ist die Last des Skripts selbst.

Schritt 1: Den Aufbau eines Cron-Ausdrucks verstehen

Eine crontab-Zeile besteht aus fünf Zeitfeldern und dem Befehl: Minute (0 bis 59), Stunde (0 bis 23), Tag des Monats (1 bis 31), Monat (1 bis 12 oder JAN bis DEC) und Wochentag (0 bis 7, wobei 0 und 7 Sonntag sind, alternativ SUN bis SAT). cron prüft jede Minute, ob die aktuelle Uhrzeit zu allen Feldern passt. Ein * steht für jeden Wert, das Komma trennt Listen, der Bindestrich bildet Bereiche, der Schrägstrich Schritte. */15 in der Minute bedeutet also 0, 15, 30 und 45.

Öffnen Sie den Cron-Tester. Das Eingabefeld „Cron-Ausdruck“ trägt die Beschriftung „Minute · Stunde · Tag · Monat · Wochentag“ und ist mit dem Beispiel */15 9-17 * * 1-5 vorbelegt. Die Seite gibt an, komplett im Browser zu laufen; im Test entstanden beim Eingeben keine weiteren Netzwerkanfragen.

Verifizieren: Unter dem Feld steht „Gültiger Ausdruck“, die fünf Kacheln zeigen etwa „alle 15 Min.: 0, 15, 30, 45“ und den Wochentagsbereich Montag bis Freitag, und der Klartext lautet „Alle 15 Minuten, zwischen 09:00 und 17:59 Uhr, montags bis freitags.“

Schritt 2: Ausdruck eingeben oder Vorlage wählen

Tippen Sie Ihren Ausdruck ein oder klicken Sie eine der Vorlagen: „alle 5 Minuten“, „stündlich“, „täglich 03:00“, „Mo bis Fr 08:00“ (auf der Seite mit Bindestrich), „sonntags 02:30“, „monatlich am 1.“, „alle 6 Stunden“, „Bürozeiten“ und „beim Systemstart“ (@reboot). Kurzformen wie @daily oder @weekly löst das Tool auf und nennt die Langform, etwa „@weekly ist die Kurzform für „0 0 * * 0““. Wochentags- und Monatsnamen wie MON-FRI oder JAN,JUL werden ebenfalls verstanden.

Sie dürfen auch eine komplette crontab-Zeile einfügen. Bei 30 2 * * 0 /usr/local/bin/backup.sh --full übernahm das Tool den Befehl im Test automatisch in das Feld „Befehl“ weiter unten.

Praxisbeispiel: Eine Arztpraxis möchte den Datenbank-Dump werktags um 21:30 Uhr und den Vollabgleich auf das NAS sonntags um 03:00 Uhr. Die Ausdrücke lauten 30 21 * * 1-5 und 0 3 * * 0.

Das Tool weist auf Feinheiten hin: Bei 5/15 erklärt es, dass nicht alle cron-Varianten diese Kurzform verstehen und 5-59/15 überall gilt. Bei */7 warnt es, dass 60 nicht durch 7 teilbar ist und nach Minute 56 bereits nach 4 Minuten Minute 0 folgt.

Verifizieren: Der Klartext beschreibt genau das, was Sie meinen, und unter den Kacheln erscheint keine Warnung, die Sie nicht verstehen.

Schritt 3: Die nächsten Ausführungen kontrollieren

Die Tabelle „Nächste 10 Ausführungen“ zeigt Nummer, Wochentag, Datum, Uhrzeit mit Zeitzonenkürzel (MESZ oder MEZ) und den Abstand zu jetzt. Über die Umschaltung „Europe/Berlin“ und „UTC“ sehen Sie die Termine so, wie ein Server in der jeweiligen Zeitzone sie ausführt. Viele Cloud-Server laufen in UTC; dort startet 0 3 * * * im Sommer um 05:00 Uhr deutscher Zeit. Prüfen Sie die Zeitzone des Servers mit:

timedatectl | grep "Time zone"

Die Suche reicht laut Tool „bis 5 Jahre voraus“. Für 30 2 29 2 * findet es nur einen Termin, den 29.02.2028, und meldet „Nur 1 Termine in den nächsten 5 Jahren“. Für einen Tag, den es nie gibt, etwa 0 2 31 4 *, erscheint die Warnung, dass es diesen Tag in den gewählten Monaten nicht gibt und der Auftrag nie läuft

Besonders hilfreich ist die Darstellung der Zeitumstellung. Bei 30 2 28 3 * zeigt das Tool für den 28.03.2027 die Zeit 03:00 MESZ mit dem Vermerk „nachgeholt: 02:30 Uhr fällt durch die Zeitumstellung aus“. Bei 30 2 * * 0 markiert es den 25.10.2026 mit dem Hinweis, dass die Stunde doppelt vorkommt und die feste Zeit nur einmal ausgeführt wird. Das Tool betont, dass dies dem Verhalten von Vixie-cron und cronie entspricht und andere Varianten abweichen können. Kritische Jobs wie Backups legen Sie deshalb besser nicht zwischen 02:00 und 03:00 Uhr.

Verifizieren: Die ersten Termine stimmen mit Ihrer Erwartung überein, und in der Ansicht der Server-Zeitzone liegen sie nicht in einem Wartungsfenster anderer Systeme.

Schritt 4: Die Falle mit Tag und Wochentag vermeiden

Die häufigste Überraschung: Sind Tag des Monats und Wochentag beide eingeschränkt, verknüpft cron sie mit ODER. Der Ausdruck 0 8 1-7 * 1 läuft deshalb nicht nur am ersten Montag, sondern an den Tagen 1 bis 7 und zusätzlich an jedem Montag. Das Tool zeigt das klar: Klartext „Vom 1. bis 7. jedes Monats und außerdem montags, jeweils um 08:00 Uhr“, dazu eine Warnung und in der Terminliste sieben Tage in Folge. Als Lösung nennt es, den Wochentag im Befehl zu prüfen:

0 8 1-7 * * [ "$(date +\%u)" -eq 1 ] && /usr/local/bin/monatsbericht.sh

Das Prozentzeichen muss in der crontab maskiert sein, weil cron ein unmaskiertes % als Zeilenende wertet. Einen letzten Tag des Monats kennt cron ebenfalls nicht; das Tool schlägt dafür bei Tagen ab 29 eine Prüfung mit date -d tomorrow vor.

Verifizieren: In der Terminliste erscheinen nur die gewünschten Tage. Bei der Variante mit Prüfung im Befehl zeigt das Tool zwar täglich 1 bis 7 an; ob der Befehl wirklich nur montags arbeitet, testen Sie im Terminal mit date +%u (1 = Montag).

Schritt 5: crontab-Zeile übernehmen

Tragen Sie im Feld „Befehl“ (Hinweis „wird nicht gespeichert“) den absoluten Pfad Ihres Skripts ein. Das Tool erzeugt drei Varianten mit eigener Kopierschaltfläche:

• „crontab -e“: persönliche crontab des Benutzers, zum Beispiel 0 3 * * * /usr/local/bin/backup.sh.
• „/etc/cron.d/“: System-crontab mit Benutzerspalte, also 0 3 * * * root /usr/local/bin/backup.sh.
• „Mit Protokoll“: hängt >> "$HOME/mein-job.log" 2>&1 an, damit Ausgabe und Fehler in einer Datei landen statt per Mail.

Für eine Datei unter /etc/cron.d/ gilt: Unter Debian und Ubuntu ignoriert cron Dateinamen mit Punkt, also /etc/cron.d/backup statt backup.cron. Bei der Protokollvariante in /etc/cron.d/ sollten Sie $HOME durch einen festen Pfad wie /var/log/backup.log ersetzen, damit klar ist, wo die Datei liegt. cron startet Befehle mit einer sehr kleinen Umgebung; das Tool weist darauf hin, dass PATH meist nur /usr/bin und /bin enthält und .bashrc nicht gelesen wird.

crontab -e        # Zeile einfügen, speichern
crontab -l        # Kontrolle
grep CRON /var/log/syslog | tail -5     # Debian/Ubuntu
journalctl -u cron --since today        # alternativ (Dienst heißt unter RHEL crond)

Verifizieren: crontab -l zeigt die neue Zeile, und nach dem ersten Termin finden Sie im Syslog bzw. Journal einen Eintrag mit Ihrem Befehl sowie eine gefüllte Protokolldatei.

Schritt 6: Alternativ als systemd-Timer planen

Auf Systemen mit systemd sind Timer oft die bessere Wahl: Ausgaben landen im Journal, systemctl list-timers zeigt alle nächsten Läufe, und Persistent=true holt Termine nach, die ein ausgeschalteter Rechner verpasst hat. Der Bereich „systemd-Timer“ zeigt die Zeile „OnCalendar“, einen Prüfbefehl unter „Prüfen“ und mit „Units kopieren“ beide Dateien als Vorlage, mein-job.timer und mein-job.service mit Type=oneshot und Ihrem Befehl als ExecStart.

Beispiele aus dem Test: */15 9-17 * * 1-5 wird zu Mon..Fri *-*-* 09..17:00/15:00, 0 0 1 * * zu *-*-01 00:00:00 mit dem Hinweis „systemd-Kurzform: monthly“, */7 * * * * zu einer Minutenliste *:00,07,14,21,28,35,42,49,56:00. Für die ODER-Falle aus Schritt 4 erzeugt das Tool zwei OnCalendar-Zeilen, weil systemd Datum und Wochentag in einem Ausdruck immer mit UND verknüpft. Für @reboot liefert es OnBootSec=1min statt OnCalendar.

systemd-analyze calendar --iterations=3 'Mon..Fri *-*-* 09..17:00/15:00'
sudo systemctl daemon-reload
sudo systemctl enable --now mein-job.timer
systemctl list-timers mein-job.timer

Benennen Sie mein-job vor dem Speichern sinnvoll um, etwa db-dump; Timer und Service müssen denselben Namen tragen. Beachten Sie: systemd rechnet in der Zeitzone des Systems, die UTC-Umschaltung im Tool hilft also auch hier.

Verifizieren: systemd-analyze calendar nennt unter „Next elapse“ dieselben Termine wie die Tabelle im Tool, und systemctl list-timers zeigt den Timer mit seinem nächsten Lauf.

Typische Fehler

• Wert außerhalb des Bereichs: Bei 61 * * * * meldet das Tool „Minute: 61 liegt außerhalb von 0 bis 59.“, bei Stunde 25 und Wochentag 8 entsprechend.
• Falsche Feldzahl: Drei Felder ergeben „Zu wenige Felder: cron erwartet 5“. Bei sechs oder sieben Feldern erkennt das Tool ein Sekundenfeld aus Quartz oder Spring und rät, die Sekunden wegzulassen.
• Schrittweite 0: */0 führt zu „Die Schrittweite muss mindestens 1 sein.“
• Tippfehler im Makro: @hourly2 ergibt „Unbekanntes Makro“ mit Liste der erlaubten Kurzformen.
• Leeres Feld: Das Tool zeigt „Bitte einen Ausdruck eingeben“.
• Job läuft im Terminal, aber nicht unter cron: fehlende absolute Pfade, unmaskiertes % oder fehlende Umgebungsvariablen. Protokollvariante nutzen und die Logdatei lesen.
• Termin in falscher Stunde: Server läuft in UTC. Mit der Umschaltung „UTC“ vergleichen.

Häufige Fragen

Prüft das Tool, ob mein Befehl funktioniert?

Nein. Es bewertet nur den Zeitplan und baut den Befehl in die Vorlagen ein. Ob Skript, Rechte und Pfade stimmen, testen Sie auf dem Server, am besten einmal manuell als der Benutzer, der den Job später ausführt.

Was bedeutet @reboot genau?

Das Tool erklärt es als „Einmal beim Start des cron-Dienstes“ und zeigt keine festen Termine. Ein Neustart nur des cron-Dienstes kann den Befehl also ebenfalls auslösen.

Wie überwache ich, ob ein Cronjob wirklich läuft?

Lassen Sie das Skript am Ende eine Prüf-URL aufrufen. Wie das mit einem eigenen Dienst geht, zeigt Healthchecks: Cronjobs und Backups überwachen.

Testumfang

Getestet wurde das Tool am 1. Oktober 2026 im Browser mit allen Vorlagen, Kurzformen, Monats- und Wochentagsnamen, Zeitumstellungsfällen und mehreren Fehleingaben. Die erzeugten OnCalendar-Ausdrücke haben wir mit systemd-analyze calendar (systemd 259) auf einem Ubuntu-Host in der Zeitzone Europe/Berlin nachgerechnet; die Termine stimmten mit der Tabelle des Tools überein. Die Zeitumstellungstermine und den Wochentag des 29.02.2028 haben wir zusätzlich mit Python und date geprüft.

Fazit

Der Cron-Tester nimmt die Unsicherheit aus Cron-Ausdrücken: Klartext und Terminliste zeigen sofort, ob ein Zeitplan stimmt, und die Hinweise zu Tag-ODER-Wochentag, Schritten und Zeitumstellung fangen typische Fehler ab, bevor sie ein Backup kosten. Mit der systemd-Umrechnung wechseln Sie bei Bedarf ohne Nachschlagen zu Timern. Für Datenbanksicherungen per cron hilft im nächsten Schritt MySQL und PostgreSQL Backup automatisieren mit cron.

Weiterführende Anleitungen und Quellen

• Cron und crontab richtig nutzen: die Grundlagen
• systemd-Service selbst erstellen und verwalten
• Healthchecks auf dem Synology NAS: Cronjobs und Backups überwachen
• MySQL und PostgreSQL Backup automatisieren mit cron
• man-page crontab(5)
• systemd.time(7): Kalenderausdrücke
• systemd.timer(5)
• POSIX: crontab