Cron-Ausdrücke Ein praktischer Referenz mit echten Beispielen

Ein Cron-Ausdruck besteht aus fünf durch Leerzeichen getrennten Feldern, die einem Unix-Planer sagen, wann ein Befehl ausgeführt werden soll. Fünf Felder, eine Handvoll Sonderzeichen und einige gängige Muster – das ist das gesamte mentale Modell. Dieser Referenztext behandelt die Syntax, die Zeichen, die Menschen verunsichern, und die Zeitpläne, die Entwickler tatsächlich verwenden.

Die fünf Felder

Der Standard-Cron verwendet fünf positionelle Felder:

* * * * *
│ │ │ │ └─ Day of week   (0–7, Sunday = 0 or 7)
│ │ │ └─── Month         (1–12)
│ │ └───── Day of month  (1–31)
│ └─────── Hour          (0–23)
└───────── Minute        (0–59)

AWS EventBridge und Java’s Quartz-Planer fügen ein Sekunden Feld am Anfang hinzu, wodurch insgesamt sechs Felder entstehen. Alle anderen Felder verschieben sich nach rechts. Dies verursacht Probleme bei Entwicklern, die zwischen Umgebungen wechseln – ein Quartz-Ausdruck, der in eine Standard-crontab eingefügt wird, wird auf falscher Zeitplanung ausgeführt, ohne dass eine Warnung erscheint.

Verwenden Sie fünf-Feld-POSIX-Cron, es sei denn, Ihre Plattform erfordert explizit sechs Felder.

Spezielle Zeichen

Zeichen	Bedeutung	Beispiel
*	Jeder Wert – passt auf jedes Einheit	* * * * * – jedes Minute
,	Werteliste	0 9,17 * * * – um 9 Uhr und um 17 Uhr
-	Reichweite	0 9-17 * * * – jede Stunde von 9 Uhr bis 17 Uhr
/	Schrittintervall	*/15 * * * * – alle 15 Minuten
?	Kein spezifischer Wert (nur Quartz/AWS)	0 0 15 * ? – der 15. Tag jedes Monats, jeder Wochentag
L	Letzter Wert (nur Quartz/AWS)	0 0 L * ? – letzter Tag jedes Monats
W	Nächster Wochentag (nur Quartz/AWS)	0 0 15W * ? – nächster Wochentag zum 15. Tag

Standard crontab erkennt nur *, ,, -und /. Wenn Sie ?, L, oder W in einem Ausdruck sehen, wurde er für Quartz oder AWS EventBridge geschrieben – geben Sie ihn nicht unverändert in eine Linux-crontab ein.

Die Referenztabelle: Zeitpläne, die Entwickler tatsächlich verwenden

Dies ist der Teil, den Sie sich bookmarken sollten. Erstellen und validieren Sie alle dieser Ausdrücke mit dem IO Tools Cron-Ausdruck-Generator.

Beschreibung	Cron-Ausdruck	Hinweise
Jede Minute	* * * * *	selten geeignet in der Produktion
Alle 5 Minuten	*/5 * * * *	Health-Checks, kurze Poll-Zyklen
Alle 15 Minuten	*/15 * * * *	Cache-Heizung, Feed-Synchronisierung
Jede 30 Minuten	*/30 * * * *	Äquivalent zu 0,30 * * * *
Jede Stunde (auf der Stunde)	0 * * * *	Funktions zu :00 jeder Stunde
Jede 6 Stunden	0 */6 * * *	Daten-Synchronisierung, inkrementelle Exporte
Täglich um Mitternacht UTC	0 0 * * *	Standard-Täglicher Batch-Trigger
Täglich um 9 Uhr UTC	0 9 * * *	Morgens Berichtsgenerierung
Wochentage um 9 Uhr UTC	0 9 * * 1-5	Business-Stunden-Aufgaben (Montag bis Freitag)
Wochentage um 8:30 Uhr UTC	30 8 * * 1-5	Vor-standup-Berichtsversand
Jeden Sonntag um 2 Uhr	0 2 * * 0	Wöchentliche Wartung, außerhalb der Spitzenzeiten Backups
Erster Tag jedes Monats	0 0 1 * *	Monatliche Abrechnungen, wiederkehrende Berichte
1. Januar um Mitternacht	0 0 1 1 *	Jährliche Reset-Aufgaben, Jahresbeginn-Aufgaben

Das Zeitzone-Problem

Cron hat keine Zeitzone-Bewusstsein. Es läuft in der Zeitzone, in der der Server konfiguriert ist – auf den meisten Linux-Systemen ist das UTC. Das ist in der Regel in Ordnung, bis Sie Aufgaben mit Geschäftsstunden verbinden oder Benutzer aus verschiedenen Regionen bemerken, warum der „9-Uhr-Bericht“ um 14 Uhr eintrifft.

Die sichersten Standardwerte:

• Stellen Sie Ihren Server auf UTC ein. Konvertieren Sie in die lokale Zeit in der Anwendungslogik, nicht im Cron-Ausdruck.
• Kommentieren Sie jede Cron-Aufgabe mit der effektiven lokalen Zeit, damit der nächste Leser der crontab nicht raten muss.
• Wenn Sie Cloud-Planer (AWS EventBridge, Google Cloud Scheduler) verwenden, überprüfen Sie das Zeitzone-Feld – die meisten unterstützen IANA-Zeitzone-Namen direkt, was die Unklarheit beseitigt.

# Always comment with the effective local time
# Runs daily at midnight UTC (= 8pm EST / 5pm PST)
0 0 * * * /usr/bin/python3 /opt/scripts/daily_report.py

Testen: Berechnen Sie die nächsten Ausführungen vor der Bereitstellung

Die Bereitstellung einer Cron-Aufgabe, um zu entdecken, dass sie jede Minute statt jede Stunde ausgeführt wird, ist ein Ritus der Passage. Vermeiden Sie es.

Der IO Tools Cron-Next-Run-Rechner zeigt genau, wann Ihr Ausdruck das nächste Mal ausgeführt wird – fügen Sie Ihren Ausdruck ein und erhalten Sie die nächsten zehn Ausführungszeiten, bevor Sie einen Server berühren.

Für die Befehlszeilenversion der Validierung:

# Install croniter (Python) for quick expression testing
pip install croniter

python3 -c "
from croniter import croniter
from datetime import datetime

cron = croniter('*/15 * * * *', datetime.utcnow())
for _ in range(5):
    print(cron.get_next(datetime))
"

Hinzufügen einer Cron-Aufgabe auf Linux

# Open the crontab editor for the current user
crontab -e

# Format: minute hour day month weekday command
# Run backup script daily at 2:30am UTC
30 2 * * * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1

# Run a Python script every 5 minutes
*/5 * * * * /usr/bin/python3 /home/user/scripts/sync.py

# View current crontab entries
crontab -l

# Edit another user's crontab (requires root)
crontab -u www-data -e

Der 2>&1 am Ende der Sicherungszeile leitet stderr in stdout, sodass beide in die Protokolldatei gelangen. Ohne es wird cron-Fehler in die Mailspool geschrieben – und niemand prüft das.

GitHub Actions geplante Workflow

GitHub Actions verwendet denselben fünf-Feld-Cron-Syntax, immer in UTC. Es gibt keine Zeitzone-Überschreibung.

name: Nightly Data Export

on:
  schedule:
    # Runs at 1:00 AM UTC every weekday
    - cron: "0 1 * * 1-5"
  workflow_dispatch: # Allow manual trigger

jobs:
  export:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run export script
        run: python scripts/export.py

Eine Besonderheit: GitHub Actions geplante Workflows können bei hoher Belastung bis zu 15 Minuten verzögert werden. Vertrauen Sie ihnen nicht für Aufgaben, die präzise Timing erfordern.

Wenn Cron nicht ausreicht

Standard-Cron erfüllt die meisten Anwendungsfälle auf einem einzelnen Server. Seine Grenzen werden zu Problemen bei Skalierung:

• Keine Wiederholung bei Fehlern. Wenn die Aufgabe abstürzt, wird die nächste Ausführung zum nächsten geplanten Zeitpunkt – es gibt keine automatische Wiederholung.
• Kein verteiltes Sperren. Mehrere Server, die dieselbe crontab ausführen, starten die gleiche Aufgabe gleichzeitig.
• Keine Sichtbarkeit. Es gibt kein integriertes Dashboard für die Ausführungsverlauf, Fehlerwarnungen oder Dauerverfolgung.

Problem	Bessere Alternative
Wiederholungslogik und Aufgabenwartezeiten	Celery Beat (Python), Sidekiq-Cron (Ruby)
Cloud-native Planung mit Wiederholung	AWS EventBridge + Lambda, Google Cloud Scheduler
CI/CD-Pipeline-Trigger	GitHub Actions-Pläne
Beobachtbare Aufgabenkoordination	Airflow, Prefect, Temporal

Für Skripte auf einem einzelnen Server ist Cron immer noch das richtige Werkzeug – es ist einfach, zuverlässig und hat keine Abhängigkeiten. Für alles, was Wiederholungsgarantien, verteilte Ausführung oder Fehlerbeobachtung benötigt, zahlt sich ein dedizierter Aufgabenwartezeiten schnell aus.

Verwenden Sie die Cron-Ausdrucksgenerator um Ihr nächstes Zeitplan zu erstellen, ohne die Syntax zu merken, und das Cron-Nächster-Lauf-Rechner um zu überprüfen, dass es dann genau dann ausgeführt wird, wie erwartet.

Das könnte Ihnen auch gefallen