Was macht dieser Cron-Ausdruck eigentlich?

Standard-Cron liest von links nach rechts: Minute, Stunde, Tag des Monats, Monat, Tag der Woche. Manche Scheduler — dieses Tool eingeschlossen — akzeptieren ein optionales vorangestelltes Feld für Sekunden, macht sechs insgesamt. Jedes Feld nimmt eine Zahl, eine kommagetrennte Liste, einen Bereich (1-5), eine Schrittweite (*/15) oder eine Kombination (10-50/10). Die Felder für Monat und Tag der Woche akzeptieren zusätzlich Namen: JAN-DEC sowie SUN-SAT (oder 0-7, wobei sowohl 0 als auch 7 Sonntag bedeuten).

* heißt „jeder beliebige Wert" für dieses Feld — * * * * * feuert jede Minute. */15 heißt „jeder 15. Wert, gezählt ab dem Minimum des Feldes" — bei Minuten also :00, :15, :30, :45.

Schlichtes Cron — das in Ihrer Crontab — hat 5 Felder und als feinste Auflösung einen Lauf pro Minute. Manche Werkzeuge (dieses hier, dazu etwa node-cron) akzeptieren ein sechstes, vorangestelltes Feld für Sekunden; nur damit lässt sich „alle 10 Sekunden" in Cron-Syntax überhaupt ausdrücken. Die beiden sind leicht zu verwechseln: 0 30 2 * * * sieht aus, als könnte es 2:30 meinen, aber bei sechs Feldern ist die erste 0 die Sekunde, und der Zeitplan feuert tatsächlich um 02:30:00 — als 5-Feld-Cron geschrieben wäre das 30 2 * * *. Sich bei der Anzahl der Felder zu verzählen ist die mit Abstand häufigste Art, den richtigen Job zur falschen Zeit einzuplanen.

Die @-Kurzschreibweisen — @hourly, @daily, @weekly, @monthly, @yearly (@annually und @midnight sind Aliase) — werden zu festen Standard-Cron-Ausdrücken expandiert und verhalten sich genauso. @reboot ist ein anderer Fall; siehe unten.

0 0 13 * 5 liest sich wie „am 13., falls das ein Freitag ist" — Freitag, der 13. Ist es aber nicht. Standard-Cron behandelt Tag des Monats und Tag der Woche als ODER, sobald beide eingeschränkt sind: Der Job feuert am 13. jedes Monats und an jedem Freitag, in den meisten Monaten also fünf- oder sechsmal statt des einen Laufs, den Sie vor Augen hatten.

Das beißt nur, wenn beide Felder gleichzeitig eingeschränkt sind. 0 0 13 * * (jeder 13., Tag der Woche als * belassen) bedeutet genau das, wonach es aussieht, und 0 0 * * 5 (jeder Freitag) ebenso. Es ist die Kombination, die stillschweigend von UND auf ODER umschaltet, und sie gehört zu den ältesten Überraschungen in Cron — POSIX schreibt es so vor, jede nennenswerte Cron-Implementierung hält sich daran, und sie erwischt bis heute Leute, die programmieren gelernt haben, als die meisten POSIX-Spezifikationen längst geschrieben waren.

Cron plant in Ortszeit, und Ortszeit verläuft über eine Zeitumstellung hinweg nicht lückenlos. Zweimal im Jahr überspringt irgendwo eine Uhr eine Stunde oder wiederholt sie — und ein Job, der in dieser Stunde eingeplant ist, muss irgendetwas tun, denn „führ ihn trotzdem aus" hat keine eindeutige Bedeutung.

Bei der Umstellung auf Sommerzeit existieren die Ortszeiten der übersprungenen Stunde schlicht nicht. Ein Job, der auf 02:30 gesetzt ist, hat an dem Tag, an dem Europe/Paris von 02:00 auf 03:00 springt, gar kein 02:30, an dem er laufen könnte — dieses Tool meldet diesen Lauf deshalb als übersprungen, statt ihn stillschweigend auf 01:30 oder 03:30 zu schieben, denn jede der beiden Vermutungen wäre mindestens so oft falsch wie richtig.

Bei der Umstellung zurück auf Normalzeit treten die Ortszeiten der wiederholten Stunde zweimal auf. Dieses Tool folgt der Konvention, die jede uns bekannte Cron-Implementierung verwendet: einmal feuern, beim ersten Vorkommen, nicht zweimal.

Die praktische Abhilfe ist langweilig, aber verlässlich: Legen Sie Wartungsjobs außerhalb des Fensters von 00:00 bis 04:00 Uhr, in das die meisten Regionen ihre Zeitumstellung setzen — oder betreiben Sie Ihre Infrastruktur durchgängig in UTC, wo dieser ganze Abschnitt hinfällig ist.

@reboot läuft einmal, beim Start der Maschine — mehr garantiert Cron dafür nicht, und einen „nächsten Lauf" kennt es hier nicht, weil es keinen gibt. Für das übliche Monitoring-Muster „alarmiere mich, wenn das hier nicht nach Plan läuft" taugt das schlecht: Es gibt keinen Plan, also auch nichts, wogegen sich ein Schweigen abgleichen ließe. Wenn ein @reboot-Job wichtig ist — etwa weil er nach einem Absturz Zustand wiederherstellt — dann lohnt sich meist die Überwachung genau dieses Zustands, nicht des Boot-Ereignisses.

Brauche ich dafür ein Konto?

Nein. Es gibt keine Anmeldung und kein nennenswertes Rate-Limit, weil hier nichts einen Server anspricht — sowohl das Parsen als auch die Berechnung der nächsten Läufe passieren in Ihrem Browser.

Speichern Sie die Ausdrücke, die ich teste?

Nein. Nichts, was Sie eintippen, wird irgendwohin gesendet; es gibt also nichts zu speichern und nichts, dessen Löschung Sie von uns verlangen könnten.

Warum zeigt es manchmal weniger als 8 Läufe?

Eine Handvoll Ausdrücke beschreibt einen Zeitplan, der selten oder nie feuert. 0 0 31 2 * (31. Februar) trifft auf kein reales Datum zu und liefert null Läufe. 0 0 29 2 * (29. Februar) trifft nur auf Schaltjahre zu, es kann also einige Jahre Suche dauern, bis der nächste Lauf auftaucht.

Welche Cron-Erweiterungen werden nicht unterstützt?

Die Quartz-Zusätze, die manche Scheduler über POSIX-Cron legen: L (letzter Tag), W (nächstgelegener Werktag), # (n-ter Wochentag des Monats) und ? (kein bestimmter Wert). Dieses Tool weist sie ausdrücklich aus, statt sie stillschweigend als etwas anderes zu lesen.

Mein Server läuft in einer anderen Zeitzone als der hier gewählten — spielt das eine Rolle?

Ja, und es lohnt sich, das nachzusehen. Cron läuft auf einer typischen Linux-Maschine in der am System eingestellten Zeitzone, nicht zwangsläufig in UTC und nicht zwangsläufig in Ihrer. Wählen Sie die Zone, in der die Crontab Ihres Jobs tatsächlich läuft, nicht die, in der Sie gerade sitzen — sonst stimmen die hier gezeigten Laufzeiten nicht mit der Realität überein.