Crontab-Syntax unter Linux: Ein praktischer Guide für 2026

Du hast ein Backup-Skript. Es funktioniert, wenn du es von Hand ausführst. Jetzt soll es jede Nacht um 2 Uhr morgens laufen, ohne dass du das Terminal betreuen musst. Hier kommt Cron ins Spiel, und die richtige Crontab-Syntax macht den Unterschied zwischen einem Skript aus, das planmäßig ausgeführt wird, und einem Skript, das stillschweigend nichts tut, während du schläfst.

Dieser Guide behandelt alles, was du brauchst: das Crontab-Format und die Feldwerte, die Sonderzeichen, die die Planung flexibel machen, die wenigen Crontab-Befehle, die du tatsächlich verwenden wirst, sowie echte Beispiele, die du kopieren und anpassen kannst. Kein Füllmaterial, kein unnötiger Schnickschnack.

Was ist Crontab und ein Cron-Job

Drei Begriffe werden abwechselnd verwendet, und das sollte nicht der Fall sein.

Cron-Daemon (crond) ist der Hintergrundprozess, der jede Minute aufwacht, nach geplanten Arbeiten sucht und alles ausführt, was fällig ist. Er macht dies auf Unix-Systemen seit den 1970er Jahren. Du interagierst nicht direkt mit ihm.

Cron-Job ist jede einzelne Aufgabe, die du über Cron geplant hast. Eine Datenbanksicherung um Mitternacht, eine Protokollrotation sonntags, ein Gesundheitscheck-Ping alle fünf Minuten. Jede einzelne ist ein Cron-Job.

Crontab (kurz für „Cron-Tabelle“) ist die Datei, in der diese Jobs gespeichert sind. Eine Zeile pro Job. Jede Zeile teilt dem Cron-Daemon genau mit, welcher Befehl wann ausgeführt werden soll.

Wie lautet die Crontab-Syntax

Die Crontab-Syntax ist das strukturierte Format, das du verwendest, um zu definieren, wann ein Cron-Job ausgelöst werden soll. Jede Zeile in deiner Crontab-Datei folgt demselben Muster: fünf Zeit-/Datumsfelder, dann der Befehl. Der Cron-Daemon liest diese Zeilen, analysiert die Felder und gleicht sie einmal pro Minute mit der aktuellen Systemzeit ab. Wenn die Syntax falsch ist, passiert nichts. Kein Fehler, keine Warnung. Nur Stille.

Crontab-Format und Feldwerte

Jeder Crontab-Eintrag verwendet fünf Felder vor dem Befehl. Sie erscheinen immer in dieser Reihenfolge:

Alle fünf Felder sind Pflichtfelder. Wenn dir ein bestimmtes Feld egal ist, fülle es mit einem Sternchen (*). Wenn du ein Feld leer lässt, wird der Eintrag ungültig und cron informiert dich nicht darüber.

Crontab-Sonderzeichen erklärt

Mit reinen Zahlen kommst du nur begrenzt weit. Diese Sonderzeichen machen Cron-Ausdrücke flexibel genug, um echte Planungsanforderungen zu erfüllen:

Kurze Notiz: L, W, # und ? werden nicht von jeder Cron-Implementierung unterstützt. Der Standard-Linux-Crontab (Vixie-Cron) erkennt sie nicht. Du findest sie in Quartz-basierten Schedulern und einigen erweiterten Cron-Varianten. Bleib bei *, Kommas, Bindestrichen und Schrägstrichen, wenn du eine portable Syntax möchtest.

Wichtige Crontab-Befehle

Du benötigst nur vier Crontab-Befehle. Das ist alles. Hier sind sie:

• crontab -e öffnet deine Crontab-Datei zur Bearbeitung. Wenn du noch keine hast, wird eine neue Datei erstellt. Beim ersten Mal wirst du gefragt, welchen Texteditor du bevorzugst.
• crontab -l listet alle deine aktuellen Crontab-Einträge auf. Verwende es, um den tatsächlichen Ausführungsplan zu überprüfen, denn Raten führt um 3 Uhr morgens zu Fehlern.
• crontab -r löscht deine gesamte Crontab-Datei. Nicht einen einzelnen Eintrag. Die gesamte Datei. Endgültig weg. Keine Bestätigungsaufforderung.
• crontab -ri macht dasselbe wie -r, fragt aber zuerst. Verwende diesen Befehl. Immer.

Das deckt 99 % dessen ab, was du tun wirst. Bearbeiten, auflisten und gelegentlich löschen.

Verwendung von Crontab anhand von Beispielen

So weit die Theorie. Jetzt erstellen wir echte Crontab-Einträge. Öffne deine Crontab-Datei:

crontab -e

Wenn du es zum ersten Mal öffnest, wirst du von deinem System aufgefordert, einen Editor auszuwählen. Wähle Nano, wenn du es so einfach wie möglich haben willst. Du landest in einer Textdatei, in der jede neue Zeile zu einem neuen Cron-Job wird.

Beachte Folgendes: Crontab verwendet die aktuelle Zeitzone deines Systems. Wenn dein Server auf UTC eingestellt ist und du für „9 Uhr“ planst, ist das 9 Uhr UTC, nicht deine lokale Zeit. Überprüfe es mit timedatectl, wenn du unsicher sind.

Plane einen Cron-Job zu einem bestimmten Zeitpunkt

Angenommen, du möchtest am 10. Juni um 8:30 Uhr ein Shell-Skript ausführen. Hier ist der Eintrag:

30 08 10 06 * /home/user/superbackup.sh

Minute 30, Stunde 08, Tag 10, Monat 06, beliebiger Wochentag. Ganz einfach. Das Sternchen im Feld „Tag der Woche“ bedeutet „an jedem Tag“.

Crontab-Einträge mit crontab -l anzeigen

Möchtest du sehen, was bereits geplant ist? Führe aus:

crontab -l

Dadurch wird jede Zeile in deiner Crontab-Datei an das Terminal ausgegeben. Wenn die Ausgabe leer ist, hast du keine Cron-Jobs. Ganz einfach.

Crontab-Einträge bearbeiten

Musst du einen Zeitplan ändern oder einen Pfad korrigieren? Derselbe Befehl, mit dem du es erstellt hast:

crontab -e

Suche die Zeile, bearbeite sie, speichere ab und beende. Der Cron-Daemon übernimmt Änderungen automatisch. Ein Neustart ist nicht erforderlich.

Einen Cron-Job jede Minute ausführen

Fünf Sternchen, dann dein Befehl. Das ist das Muster für den Minutentakt:

* * * * * /home/user/systemhealthcheck.sh

Dies wird einmal pro Minute, jede Minute, jede Stunde, jeden Tag ausgelöst. Verwende es zur Überwachung von Skripten oder zur schnellen Abfrage. Verwende es nicht für ressourcenlastige Aufgaben, sonst wird dein Server dich hassen.

Einen täglichen Cron-Job planen

Der @daily Shortcut führt einen Befehl einmal pro Tag um Mitternacht (00:00) aus:

@daily /home/user/systemcleanup.sh

Es ist sauberer, als 0 0 * * * zu schreiben und bedeutet dasselbe. Es gibt auch @weekly (Sonntag um Mitternacht), @hourly (Minute 0 jeder Stunde), und @annually (1. Januar um Mitternacht).

Plane einen Cron-Job für einen Zeitraum

Benötigst du ein Skript, das nur während der Geschäftszeiten ausgeführt werden soll? Verwende im Stundenfeld einen Bindestrich:

00 08-17 * * * /home/user/sync.sh

Dies läuft zu jeder vollen Stunde von 8 bis 17 Uhr, jeden Tag. Nur am Wochenende? Füge einen Wochentagsbereich hinzu:

00 08-17 * * 6-0 /home/user/sync.sh

Jetzt wird es nur von Samstag (6) bis Sonntag (0) ausgeführt.

Monatliche und jährliche Cron-Zeitpläne

Die @monthly Verknüpfung führt einen Job um Mitternacht am 1. eines jeden Monats aus:

@monthly /home/user/monthlyreport.sh

Entspricht 0 0 1 * *. Und @yearly (oder @annually) wird am 1. Januar um Mitternacht ausgeführt. Gut geeignet für Zertifikatsverlängerungen, jährliche Protokollarchive oder alles, was du genau einmal im Jahr benötigst.

Führe mehrmals täglich einen Cron-Job aus

Mit durch Kommas getrennten Werten kannst du mehrere bestimmte Zeiten festlegen. Fünfmal am Tag um 12 Uhr, 15 Uhr, 17 Uhr, 19 Uhr und 21 Uhr:

0 12,15,17,19,21 * * * /home/user/report.sh

Jeder Wert im Stundenfeld ist ein separater Trigger. Das Minutenfeld ist 0, sodass es zu Beginn jeder dieser Stunden ausgeführt wird.

Führe einen Befehl nach dem Systemneustart aus

Die @reboot Direktive führt einen Befehl einmalig sofort nach dem Systemstart aus:

@reboot /home/user/startservices.sh

Perfekt zum Starten von Hintergrund-Daemons, zum erneuten Einrichten von SSH-Tunneln oder zum Starten von Überwachungsagenten, die keine systemd-Dienstdateien haben. Es wird nur beim Booten ausgeführt, nicht beim Neustart des Cron-Daemons.

Speicherort der Crontab-Datei unter Linux

Wo sich die eigentlichen Crontab-Dateien auf der Festplatte befinden, hängt von deinem Betriebssystem ab:

• Debian/Ubuntu – /var/spool/cron/crontabs/
• Red Hat/CentOS/Fedora – /var/spool/cron/
• macOS – /var/at/tabs/

Du kannst sie dir direkt ansehen, aber wenn du sie von Hand bearbeitest, umgehst du die Syntaxüberprüfung von Cron. Bleibe bei crontab -e.

Zusätzliche Crontab-Konfiguration

Die Grundlagen decken die meisten Anwendungsfälle ab. Aber wenn deine Cron-Jobs zahlreicher werden, benötigst du Protokollierung, E-Mail-Kontrolle und eine ordnungsgemäße Umgebungseinrichtung.

Erstelle eine Crontab-Protokolldatei

Standardmäßig geht die Ausgabe des Cron-Jobs verloren, sofern du sie nicht erfasst. Leite stdout und stderr in eine Protokolldatei um:

* * * * * /home/user/script.sh >> /var/log/cronjob.log 2>&1

Die >> hängt an, anstatt zu überschreiben, sodass du eine fortlaufende Historie behältst. Die 2>&1 sendet Fehlermeldungen in dieselbe Datei wie die Standardausgabe. Ohne dies kann dein Skript wochenlang stillschweigend ausfallen und du erfährst es erst, wenn etwas nachgelagertes kaputtgeht.

Crontab-E-Mail-Benachrichtigungen deaktivieren

Cron sendet für jeden Job, der eine Ausgabe erzeugt, eine E-Mail an den Benutzer. Auf einem ausgelasteten System ist das eine Menge lokaler E-Mails, die niemand liest. Unterdrücke es, indem du Folgendes hinzufügst:

>/dev/null 2>&1

Füge dies am Ende jeder Cron-Job-Zeile hinzu. Es sendet sowohl stdout als auch stderr an /dev/null. Stelle einfach sicher, dass du die Protokollierung tatsächlich separat eingerichtet hast, sonst fliegst du blind.

Crontab-Umgebungsvariablen

Cron lädt dein Shell-Profil nicht. Das bedeutet, dass deine PATH-, SHELL- und anderen Umgebungsvariablen standardmäßig nur minimal gesetzt sind. Definiere sie oben in deiner Crontab-Datei:

• PATH – sagt Cron, wo es ausführbare Dateien findet. Standardmäßig ist es normalerweise nur /usr/bin:/bin, weshalb /usr/local/bin-Skripte unerwartet fehlschlagen.
• SHELL – legt fest, welche Shell Cron verwendet. Standardmäßig /bin/sh und nicht bash. Wenn deine Skripte Bash-Funktionen verwenden, setze dies auf /bin/bash.
• LOGNAME – der Benutzername, der den Crontab besitzt. Stammt von /etc/passwd.
• HOME – das Home-Verzeichnis des Crontab-Eigentümers. Ebenfalls von /etc/passwd.

Lege sie wie jede Shell-Variable oben in deiner Crontab fest, vor deinen Jobeinträgen:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin

* * * * * /home/user/script.sh

Das ist der mit Abstand häufigste Grund, warum Cron-Jobs interaktiv funktionieren, aber fehlschlagen, wenn sie geplant sind. Überprüfe zuerst deinen PATH. Immer.