Cron-Ausdruck erklären – Crontab im Klartext

Cron-Ausdrücke im Klartext lesen

Gib eine Crontab-Zeile ein und erhalte sofort einen deutschen Satz dazu, dazu jedes der fünf Felder einzeln erklärt und die nächsten Ausführungszeitpunkte. Der Erklärer kennt Stern, Liste, Bereich, Schrittweite, die Namenskürzel MON-FRI und JAN-DEC sowie alle Kurzformen von @hourly bis @reboot. Alles rechnet dein Browser, nichts wird hochgeladen.

Wie liest man die fünf Felder?

Von links nach rechts: Minute (0–59), Stunde (0–23), Tag im Monat (1–31), Monat (1–12), Wochentag (0–7). Danach folgt der Befehl. Ein Stern bedeutet „jeder Wert“. 0 3 * * * heißt also: Minute 0, Stunde 3, jeder Tag, jeder Monat, jeder Wochentag – täglich um 3 Uhr.

Der mit Abstand häufigste Tippfehler ist die vertauschte Reihenfolge am Anfang. Gesprochen sagt man „neun Uhr dreißig“, geschrieben steht aber die Minute vorn: 30 9 * * *. Wer 9 30 * * * einträgt, bekommt keinen Fehler, sondern einen Auftrag, der nie läuft, weil es keine Stunde 30 gibt – in strengeren Umsetzungen dagegen eine abgelehnte Zeile.

Was bedeuten Stern, Komma, Bindestrich und Schrägstrich?

Vier Zeichen decken die gesamte Syntax ab:

• * – jeder Wert des Feldes.
• 1,15 – eine Liste einzelner Werte.
• 1-5 – ein Bereich, beide Enden eingeschlossen.
• */5 – eine Schrittweite auf einem Bereich.

Die Schrittweite ist die einzige Stelle mit einer echten Stolperfalle: Sie beginnt am Anfang des Bereichs, nicht bei null. 10-20/3 trifft deshalb 10, 13, 16 und 19 und nicht 12, 15 und 18. Außerdem setzt jede Schrittweite zu Beginn des Feldes neu an. */7 im Minutenfeld feuert zu 0, 7, 14 … 56 – und dann wieder zu 0, also schon vier Minuten später. Nur Teiler von 60 ergeben über die Stundengrenze hinweg einen gleichmäßigen Takt.

Warum läuft der Auftrag an mehr Tagen als geplant?

Weil Cron zwei Felder für den Tag hat und sie mit ODER verknüpft, sobald beide eingeschränkt sind. Die Handbuchseite crontab(5) formuliert es so: Sind sowohl Tag im Monat als auch Wochentag gesetzt, läuft der Befehl, wenn eines von beiden passt.

0 0 13 * 5 bedeutet damit „am 13. und an jedem Freitag“, nicht „nur an Freitag, dem 13.“ – statt einer Handvoll Termine im Jahr sind es rund sechzig. Freitag, der 13., lässt sich in Cron überhaupt nicht ausdrücken; dafür braucht es eine Datumsprüfung im Skript. Sobald dieser Fall eintritt, weist der Erklärer oben ausdrücklich darauf hin.

In welcher Zeitzone läuft ein Cronjob?

In der des Servers. Cron rechnet keine Zeitzonen um, es vergleicht die Felder mit der lokalen Uhr der Maschine. Dieselbe Zeile feuert auf einem Server in UTC also zu einem anderen Moment als auf einem in Berliner Zeit. Die Terminvorschau in diesem Werkzeug nutzt notgedrungen die Uhr deines Geräts – prüfe mit timedatectl oder date, was auf dem Zielsystem gilt.

Rund um die Zeitumstellung wird es unangenehm: Im Frühjahr fällt eine Stunde aus, im Herbst kommt eine doppelt vor. Was dann mit einem Auftrag in dieser Stunde passiert, hängt von der Cron-Variante ab; Vixie-artige Umsetzungen holen ausgefallene, fest terminierte Läufe nach der Vorwärts-Umstellung nach. Verlass dich nicht darauf. Server in UTC zu betreiben ist die ruhigere Lösung, und ein Wartungsfenster um 4 Uhr statt um 2:30 Uhr erspart die Frage ganz.

Welche Kurzformen gibt es?

@hourly, @daily (gleichbedeutend mit @midnight), @weekly, @monthly, @yearly (gleichbedeutend mit @annually) und @reboot. Alle bis auf die letzte werden beim Einlesen in genau fünf Felder übersetzt: @daily ist 0 0 * * *, @weekly ist 0 0 * * 0, @monthly ist 0 0 1 * *. @reboot hat keinen Zeitplan – der Auftrag läuft einmal, wenn der Cron-Dienst startet.

Für Intervalle unterhalb einer Stunde gibt es keine Kurzform; alle fünf Minuten schreibt man */5 * * * *. Und feiner als eine Minute geht klassisches Cron nicht: Ein Sekundenfeld existiert nicht. Cron gehört seit Version 7 Unix (1979) zum Standard-Werkzeugkasten, die heute auf Linux verbreiteten Varianten gehen auf Paul Vixies Neuimplementierung von 1987 zurück – an den fünf Feldern hat sich seither nichts geändert.

Warum läuft mein Skript im Terminal, aber nicht per Cron?

Fast immer an der Umgebung. Cron startet Aufträge mit einer sehr kargen Umgebung: PATH ist typischerweise nur /usr/bin:/bin, dein Login-Profil wird nicht gelesen, und HOME sowie die Sprachumgebung können anders aussehen als in deiner Sitzung. Drei Gewohnheiten beheben die meisten Fälle:

1. Absolute Pfade für Befehle und für Dateien verwenden.
2. Ausgabe umlenken, etwa mit >> /var/log/meinjob.log 2>&1 – sonst landet ein Fehler bestenfalls in einer lokalen Mail, die niemand liest.
3. Das Prozentzeichen maskieren: In einer Crontab beendet ein nacktes % die Befehlszeile und leitet die Eingabe ein. Ein Datumsformat wie date +%Y-%m-%d muss deshalb als date +\%Y-\%m-\%d geschrieben werden.

Privat und offline-fähig

Das Zerlegen des Ausdrucks, die Beschreibung und die Terminvorschau laufen vollständig auf deinem Gerät. Nichts wird übertragen, nichts gespeichert, und nach dem Laden funktioniert die Seite auch im Flugmodus. In einer Crontab-Zeile stehen regelmäßig Rechnernamen, absolute Pfade und Zugangsschlüssel – die haben auf einem fremden Server nichts verloren.