Ein Zeitplan braucht mehr als einen plausiblen Ausdruck. Dieselben fünf Felder können in unterschiedlichen Zeitzonen verschiedene Zeitpunkte ergeben. Auch ein gültiger Ausdruck kann die fachliche Anforderung falsch wiedergeben. Halte deshalb vor der Einrichtung fest, was passieren soll, welche Uhr maßgeblich ist und woran du ein korrektes Ergebnis erkennst.
Der Cron-Generator unterstützt diese Prüfung. Er validiert einen unterstützten Unix-Ausdruck und zeigt passende Termine an. Er installiert keine Crontab, verbindet sich mit keinem Server und führt keine Aufgaben aus. Das Ergebnis dient zur Prüfung einer Konfiguration, die du anschließend im zuständigen Ausführungssystem einrichtest.
Übersetze die Anforderung in eine Kalenderregel
Ein Team benötigt beispielsweise jeden Werktag um 09:00 Uhr einen Bericht für sein Büro in Madrid. Kläre zuerst, ob Werktag hier Montag bis Freitag oder den tatsächlichen Betriebskalender bezeichnet. Cron kann die erste Definition abbilden. Feiertage, Betriebsschließungen und ausnahmsweise gearbeitete Samstage benötigen zusätzliche Anwendungslogik. Ohne diese Unterscheidung kann ein technisch korrekter Ausdruck unerwünschte Berichte erzeugen.
Die fünf Felder lauten Minute, Stunde, Tag des Monats, Monat und Wochentag, in dieser Reihenfolge. Der Bericht ergibt 0 9 * * 1-5, während Europe/Madrid separat ausgewählt wird. Die Voreinstellung des Tools ist UTC. Wer sie unverändert lässt, beschreibt neun Uhr UTC und damit eine andere Anforderung als neun Uhr auf der örtlichen Uhr in Madrid.
Bewahre Ausdruck, Zone und erwartetes Verhalten gemeinsam auf. Ein Bildschirmfoto der fünf Felder verliert einen Teil der Konfiguration. Ergänze einen Satz zu Feiertagen und zum späteren Ausführungssystem, damit eine andere Person die Kalenderregel und ihren betrieblichen Zusammenhang nachvollziehen kann.
Beginne mit einem wiederholbaren Beispiel
Verwende zunächst diese festen Eingaben:
Ausdruck: */15 * * * *
Zone: UTC
Nach: 2026-01-01T00:00:00Z
Erste Treffer:
2026-01-01T00:15:00Z
2026-01-01T00:30:00Z
2026-01-01T00:45:00Z
Das sind historische Prüfdaten und keine kommenden Ausführungen relativ zu deinem Lesezeitpunkt. Die Grenze „nach“ ist exklusiv: Der passende Zeitpunkt genau um Mitternacht wird ausgeschlossen. Das Minutenfeld wählt null, fünfzehn, dreißig und fünfundvierzig innerhalb jeder Stunde. In den folgenden Stunden wiederholen sich diese Positionen.
Notiere alle drei Ergebnisse, bevor du etwas änderst. Interpretiert das Produktionssystem dieselben Eingaben anders, untersuche dessen Cron-Dialekt, Bezugszeitpunkt und Zeitzone. Den Ausdruck so lange zu verschieben, bis der erste Termin bequem aussieht, kann einen Fehler verbergen, der an der nächsten Tagesgrenze wieder auftritt.
Prüfe anschließend den Bericht für Montag bis Freitag. Betrachte mehrere Termine, insbesondere den Übergang von Freitag auf Montag. Die Vorschau liefert konkrete Kalenderdaten; die schriftliche Anforderung zeigt, welche davon für den geplanten Ablauf entscheidend sind. So lässt sich die fachliche Prüfung auch von jemandem nachvollziehen, der den Ausdruck nicht selbst geschrieben hat.
Prüfe die Felder einzeln
Öffne das Tool und gib fünf Felder ohne Befehl, Benutzername oder Umgebungsdefinition ein. Wähle die Zeitzone ausdrücklich aus. Behebe Validierungsfehler, bevor du Termine interpretierst. Ein altes Ergebnis in deinen Notizen belegt nicht das Verhalten eines neuen, ungültigen Ausdrucks.
Baue die Regel schrittweise auf. Beginne mit Minute und Stunde und schränke anschließend Wochentage oder Monatstage ein. Nutze Listen für einzelne Werte, Bereiche für zusammenhängende Mengen und Schritte für wiederkehrende Positionen innerhalb eines Feldes. Kontrolliere nach jeder Änderung, ob Ausdruck und Termine weiterhin der ursprünglichen Absicht entsprechen.
Für einen wichtigen Zeitplan sammelst du Beispiele vom Monatsanfang und Monatsende, von einer Wochenendgrenze und von einer Zeitumstellung, sofern die Zone eine kennt. Bewahre UTC-Zeitpunkte neben den lokalen Darstellungen auf. Damit kannst du später Ausführungsprotokolle vergleichen, ohne den damals geltenden Versatz für eine mehrdeutige Uhrzeit rekonstruieren zu müssen.
Lies die Dokumentation des Zielsystems, bevor du den Ausdruck übernimmst. Eine Vorschau für fünf Felder beweist keine Kompatibilität mit einem Parser für sechs Felder, einer anbieterspezifischen Syntax oder einem Dienst, der seine Zeitzone aus einer anderen Einstellung bezieht.
Verstehe Mengen, Schritte und die Tagesfelder
Ein Stern erlaubt jeden Wert eines Feldes. Eine Liste wie 1,3,5 wählt einzelne Werte; ein Bereich wie 1-5 schließt beide Grenzen ein. Ein Schritt gilt innerhalb des Feldes und misst keine fortlaufende Dauer seit der letzten Ausführung. Deshalb wählt */35 im Minutenfeld Minute null und fünfunddreißig jeder Stunde. Über die Stundengrenze hinweg beträgt der Abstand fünfundzwanzig Minuten.
Die beiden Tagesfelder verdienen eine eigene Prüfung. Beginnt keines mit einem Stern, verwendet das Tool die Unix-Verknüpfung OR: Ein passender Monatstag oder ein passender Wochentag genügt. 0 9 1 * 1 bezeichnet neun Uhr am ersten Tag jedes Monats und an jedem Montag. Es bedeutet nicht ausschließlich Monate, deren erster Tag ein Montag ist. Beginnt eines mit *, auch bei */n, müssen beide Auswahlen passen. Deshalb wählt 0 9 */1 * 1 die Montage; ersetzt du */1 durch 1-31, wechselt die Verknüpfung zu OR.
Das Crontab-Handbuch von Cronie erläutert diese Konzepte und weitere Varianten. UtilX unterstützt bewusst einen numerischen Ausschnitt: Zahlen, Sterne, Listen, Bereiche und Schritte. Eine im allgemeinen Handbuch beschriebene Erweiterung ist deshalb nicht automatisch in diesem Tool verfügbar.
Erkenne plausible Regeln mit falscher Bedeutung
Ein sechstes Feld verursacht häufig Verwechslungen. Manche Planer setzen Sekunden an den Anfang, andere ergänzen ein Jahr. Ein beliebiges Feld zu entfernen kann die Regel unbemerkt ändern. Bestimme den ursprünglichen Dialekt, übersetze die fachliche Anforderung und überprüfe Termine im Zielsystem. Namen, Makros sowie Erweiterungen wie L, W, # und ? gehören nicht zum unterstützten Eingabeformat.
Ein weiterer Fehler ist die Kombination aus Monatstag und Wochentag in der Erwartung einer AND-Bedingung. Prüfe einen Termin, der nur eines der Felder erfüllt. Dieser Fall zeigt das Missverständnis deutlicher als ein erster Treffer, der zufällig beide Bedingungen erfüllt.
Auch eine leere oder unvollständige Vorschau verlangt Interpretation. Die Kalenderkombination kann unmöglich oder so selten sein, dass innerhalb von fünf Jahren keine zehn Treffer vorkommen. Eine unvollständige Liste beweist nicht, dass die Aufgabe niemals laufen kann. Untersuche Validierung, Zeitzone und Kalenderanforderung getrennt, bevor du den Ausdruck veränderst.
Untersuche Zeitumstellungen anhand konkreter Zeitpunkte
Eine benannte Zone enthält regionale Regeln; ein fester Versatz beschreibt eine Beziehung zu UTC. Europe/Madrid ist daher nicht dasselbe wie ein dauerhaft unveränderter Versatz. Die Zeitzonendatenbank der IANA pflegt regionale Änderungen, deren Aktualisierungen über die Laufzeitumgebung verfügbar werden. Zukunftsberechnungen beruhen auf den dort vorhandenen Regeln.
Der tägliche Ausdruck 30 2 * * * in Europe/Madrid zeigt, warum der konkrete Parser geprüft werden muss. Am 29. März 2026 wird die nicht vorhandene Uhrzeit 02:30 auf 03:30 Ortszeit verschoben, also 01:30Z. Am 25. Oktober 2026 wird die erste 02:30 gewählt, 00:30Z; die zweite kommt nicht hinzu. Dieses Ergebnis gilt für die geprüfte tägliche Regel und ist keine pauschale Aussage über alle Cron-Ausdrücke.
Vergleiche dieses Verhalten mit dem tatsächlichen Ausführungssystem. Für einen Bericht zur örtlichen Büroöffnung drückt eine regionale Zone die Anforderung aus. Für einen ausdrücklich in UTC vereinbarten Ablauf bleibt UTC maßgeblich. Dokumentiere die Entscheidung, damit ein Serverwechsel nicht unbemerkt den erwarteten Kalender verändert.
Trenne Terminberechnung und Ausführung
Das Tool sucht höchstens zehn folgende Termine innerhalb von fünf Jahren und akzeptiert Ausdrücke mit höchstens 256 Zeichen. Es berechnet nicht den gesamten zukünftigen Kalender einer Aufgabe. Seltene Regeln können in diesem Zeitraum weniger Treffer liefern; unmögliche Kombinationen brauchen eine Korrektur statt einer unbegrenzt längeren Suche.
Die Seite führt keine Befehle aus, speichert keine geplanten Aufgaben und garantiert keine Zustellung. Sie erkennt auch nicht, ob sich Ausführungen überlappen, ob der Rechner abgeschaltet sein wird oder ob Wiederholungsversuche doppelte Berichte erzeugen. Diese Eigenschaften gehören zum Executor und zur Anwendung.
Wenn genau ein Bericht je Geschäftsperiode erforderlich ist, entwirf und teste diese Eigenschaft separat. Der Kalenderausdruck ist ein Teil der Lösung, zusammen mit Ausführungsnachweisen, Fehlerbehandlung und einer eindeutigen Definition des verarbeiteten Zeitraums. Ein passender Termin allein erfüllt noch keine fachliche Zusage über den fertigen Bericht.
Bewahre nachvollziehbare Prüfdaten auf
Speichere Ausdruck, Zeitzone, Ausgangszeitpunkt und repräsentative erwartete Termine. Prüfe Wochen- und Monatsgrenzen, OR bei eingeschränkten Tagesfeldern und relevante Zeitumstellungen. Halte fest, ob die Anforderung UTC oder einer lokalen Uhr folgt und wie Feiertage behandelt werden, die Cron nicht erkennt.
Für das feste Beispiel müssen nach Mitternacht am 1. Januar 2026 die UTC-Zeiten 00:15, 00:30 und 00:45 erscheinen. Vergleiche die reale Konfiguration vor der Aktivierung mit dem Zielsystem. Halte betriebliche Tests getrennt, damit ein korrekt berechneter Zeitpunkt nicht mit einem erfolgreich zugestellten Bericht verwechselt wird.
Quellen: Crontab-Handbuch von Cronie und IANA-Zeitzonendatenbank.