Cron führt unter Linux Befehle oder Skripte zu festgelegten Zeiten aus, etwa Backups, Prüfjobs, Aufräumarbeiten oder Berichte. Die meisten Probleme entstehen nicht durch die Zeitangabe, sondern durch Pfade, Benutzerkontext oder fehlendes Logging.

Diese Anleitung beginnt deshalb mit einem Testjob, dessen Ausführung Sie prüfen können, und behandelt danach Zeitfelder, Sonderstrings, System-Crontabs, Umgebung und Logging.

Voraussetzungen

Ein Linux-System mit installiertem Cron-Daemon, zum Beispiel cron auf Debian/Ubuntu oder crond auf RHEL/Fedora/Rocky
Terminalzugang zu Ihrem Benutzerkonto
Für systemweite Cron-Jobs unter /etc/crontab oder /etc/cron.d/ zusätzlich sudo-Rechte
Prüfen, ob der Dienst läuft: systemctl is-active cron (RHEL-Familie: crond) liefert active

Schritt 1: Einen einfachen Testjob vorbereiten

Legen Sie zuerst ein kleines Skript an, das eine Zeile mit Zeitstempel in eine Datei schreibt. So sehen Sie später sofort, ob Cron es ausgeführt hat.

mkdir -p ~/cron-test
nano ~/cron-test/testjob.sh

Inhalt des Skripts:

#!/bin/bash
echo "Cron lief: $(date '+%F %T')" >> /tmp/cron-test.log

Machen Sie das Skript ausführbar:

chmod 700 ~/cron-test/testjob.sh

Verifizieren: ls -l ~/cron-test/testjob.sh zeigt -rwx------, und ~/cron-test/testjob.sh && tail -1 /tmp/cron-test.log gibt eine Zeile Cron lief: … aus. Fehlt das x, kann Cron das Skript nicht direkt starten.

Schritt 2: Die fünf Zeitfelder verstehen

Ein klassischer Cron-Eintrag besteht aus fünf Zeitfeldern und danach dem eigentlichen Befehl:

Minute  Stunde  Tag  Monat  Wochentag  Befehl
*       *       *    *      *          /pfad/zum/befehl

Die Bedeutung der Felder:

Feld	Werte	Bedeutung
Minute	0-59	Minute innerhalb der Stunde
Stunde	0-23	Stunde des Tages
Tag	1-31	Kalendertag des Monats
Monat	1-12	Monat des Jahres
Wochentag	0-7	0 oder 7 = Sonntag, 1 = Montag bis 6 = Samstag

Ein Sternchen bedeutet: jeder mögliche Wert. Sind Tag und Wochentag eingeschränkt, läuft der Job, wenn eines von beiden passt: 0 8 1 * 1 startet am 1. des Monats und an jedem Montag. Beispiele:

# Täglich um 02:30 Uhr
30 2 * * * /usr/local/bin/backup.sh

# Jeden Montag um 08:00 Uhr
0 8 * * 1 /home/user/wochenbericht.sh

# Am 1. jedes Monats um Mitternacht
0 0 1 * * /usr/local/bin/monatsjob.sh

Verifizieren: Sie können 30 2 * * * lesen als: Minute 30, Stunde 2, jeden Tag, jeden Monat, an jedem Wochentag, also täglich um 02:30 Uhr in der Zeitzone des Systems (timedatectl zeigt sie).

Schritt 3: Die eigene Crontab mit crontab -e bearbeiten

Ihre persönliche Crontab bearbeiten Sie immer über crontab -e, nicht direkt in einer Datei. Beim ersten Aufruf fragt Debian/Ubuntu nach dem Editor; nano ist für den Einstieg am einfachsten.

crontab -e

Fügen Sie dort für den ersten Testjob diese Zeile ein:

*/2 * * * * /home/BENUTZER/cron-test/testjob.sh

Ersetzen Sie BENUTZER durch Ihren Benutzernamen (whoami). Der Job läuft dann alle zwei Minuten; die letzte Zeile der Crontab muss mit einem Zeilenumbruch enden.

Wichtig:

Nutzen Sie absolute Pfade
Cron kennt Ihre gewohnte Shell-Umgebung nicht (Schritt 7)
Ein % in der Befehlszeile gilt als Zeilenumbruch; schreiben Sie \% oder verlagern Sie den Befehl in ein Skript
Bearbeiten Sie keine Dateien unter /var/spool/cron/ direkt

Die gespeicherte Crontab zeigen Sie so an:

crontab -l

Verifizieren: crontab -l zeigt Ihren Eintrag. Beim Speichern meldet crontab installing new crontab; eine Meldung wie bad minute weist auf einen Syntaxfehler hin.

Schritt 4: Erste Muster mit Listen, Bereichen und Schrittweiten lesen

Neben festen Uhrzeiten kennt Cron drei häufige Muster:

Schrittweite wie */5 = alle 5 Einheiten
Bereich wie 1-5 = von 1 bis 5
Liste wie 0,15,30,45 = genau diese Werte

# Alle 5 Minuten
*/5 * * * * /usr/bin/python3 /home/user/check.py

# Um 00, 15, 30 und 45 Minuten jeder Stunde
0,15,30,45 * * * * /usr/local/bin/ping_check.sh

# Montag bis Freitag alle 3 Stunden
0 */3 * * 1-5 /opt/cleanup.sh

# Nur in den ersten 30 Minuten jeder Stunde, alle 5 Minuten
0-30/5 * * * * /usr/local/bin/kurzcheck.sh

Verifizieren: Sie lesen */5 * * * * als „alle fünf Minuten“ und 1-5 im Wochentagsfeld als Montag bis Freitag.

Schritt 5: Sonderstrings wie @reboot und @daily einordnen

Für Standardfälle ersetzen Sonderstrings die fünf Zeitfelder:

Sonderstring	Bedeutung
`@reboot`	Einmal nach dem Systemstart
`@hourly`	Jede Stunde (`0 * * * *`)
`@daily`	Täglich um Mitternacht (`0 0 * * *`)
`@weekly`	Sonntags um Mitternacht (`0 0 * * 0`)
`@monthly`	Am 1. um Mitternacht (`0 0 1 * *`)
`@yearly`	Am 1. Januar um Mitternacht (`0 0 1 1 *`)

@reboot /usr/local/bin/startvpn.sh
@daily /usr/local/bin/cleanup.sh >> $HOME/cleanup.log 2>&1

Verifizieren: @reboot läuft nicht zu einer Uhrzeit, sondern einmal beim Start des Cron-Dienstes. Netzwerk und Mounts sind dann nicht immer bereit; für Dienste mit Abhängigkeiten ist ein systemd-Service die bessere Wahl.

Schritt 6: System-Crontab und /etc/cron.d/ verstehen

Neben der persönlichen Crontab gibt es systemweite Varianten. Der entscheidende Unterschied: Dort gibt es ein zusätzliches Feld für den Benutzernamen.

Minute  Stunde  Tag  Monat  Wochentag  USERNAME  Befehl

Beispiele:

# Systemweiter Backup-Job als root
0 2 * * * root /usr/local/bin/backup.sh

# Cleanup werktags alle 3 Stunden als postgres
0 */3 * * 1-5 postgres /opt/cleanup.sh >> /var/log/pg.log 2>&1

Für eigene systemweite Jobs legen Sie eine Datei in /etc/cron.d/ an, statt /etc/crontab zu bearbeiten. Die Datei muss root gehören, darf nicht für Gruppe oder andere beschreibbar sein (chmod 644), und ihr Name darf unter Debian/Ubuntu keinen Punkt enthalten (backup, nicht backup.cron).

ls -la /etc/cron.d/
sudo cat /etc/crontab

Außerdem gibt es die Verzeichnisse /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly und /etc/cron.monthly. Dort liegen ausführbare Skripte, die run-parts aufruft; unter Debian/Ubuntu werden Dateinamen mit Punkt (z. B. backup.sh) ignoriert.

Verifizieren: ls -l /etc/cron.d/ zeigt Ihre Datei mit -rw-r--r-- root root; run-parts --test /etc/cron.daily listet die Skripte, die tatsächlich laufen würden.

Schritt 7: PATH, SHELL und Umgebung richtig einordnen

Die häufigste Fehlerquelle bei Cron ist nicht die Zeitangabe, sondern die Umgebung. Cron startet Jobs mit deutlich weniger Kontext als Ihre normale Shell.

PATH ist oft minimal
SHELL ist häufig /bin/sh und nicht Bash
HOME und andere Variablen können anders wirken als erwartet
Ihre .bashrc oder .profile wird nicht geladen

Nutzen Sie deshalb absolute Pfade (command -v python3 zeigt den Pfad) und setzen Sie Variablen am Anfang der Crontab:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
MAILTO=""

*/5 * * * * /usr/bin/python3 /home/user/job.py >> /home/user/job.log 2>&1

Verifizieren: Ein Testeintrag * * * * * env > /tmp/cron-env.txt zeigt nach einer Minute die tatsächliche Cron-Umgebung. Vergleichen Sie PATH darin mit echo $PATH im Terminal und entfernen Sie den Eintrag danach wieder.

Schritt 8: Logging, MAILTO und Fehlerprüfung nutzen

Leiten Sie die Ausgabe in eine Logdatei, auf die der ausführende Benutzer Schreibrechte hat (in /var/log nur root):

*/5 * * * * /usr/local/bin/check.sh >> $HOME/check.log 2>&1

2>&1 leitet auch Fehlermeldungen in dieselbe Datei. Ohne Umleitung verschickt Cron die Ausgabe per Mail an den Benutzer, sofern ein Mailsystem installiert ist; MAILTO="" schaltet das ab und verwirft die Ausgabe.

Alternativ schicken Sie die Ausgabe an Syslog:

*/5 * * * * /usr/local/bin/check.sh 2>&1 | /usr/bin/logger -t CRONJOB

Zum Prüfen eignen sich je nach Distribution zum Beispiel:

# Debian / Ubuntu (Debian 12 hat ohne rsyslog kein /var/log/syslog)
sudo journalctl -u cron --since "10 min ago"

# RHEL / Rocky
sudo journalctl -u crond --since "10 min ago"   # oder: sudo grep CRON /var/log/cron

# Ausgaben von logger
sudo journalctl -t CRONJOB

Für den Testjob aus Schritt 1 prüfen Sie direkt, ob Cron geschrieben hat:

cat /tmp/cron-test.log

Verifizieren: Der Schritt ist erfolgreich, wenn in /tmp/cron-test.log nach ein paar Minuten neue Zeilen mit Zeitstempel auftauchen. Im Journal steht je Lauf eine Zeile mit CMD (/home/BENUTZER/cron-test/testjob.sh). Danach entfernen Sie den Testjob mit crontab -e wieder.

Schritt 9: Was sich mit systemd-Timern anders löst

systemd-Timer sind die Alternative zu Cron. Sie schreiben automatisch ins Journal, holen verpasste Läufe nach dem Einschalten nach (Persistent=true) und berücksichtigen Abhängigkeiten wie das Netzwerk. Für einfache, regelmäßige Aufgaben bleibt Cron der schnellere Weg.

Verifizieren: systemctl list-timers zeigt, welche Aufgaben auf Ihrem System bereits als Timer laufen, etwa apt-daily.timer oder logrotate.timer.

Troubleshooting

Job läuft nicht: Mit crontab -l prüfen, ob der Eintrag gespeichert ist.
Befehl funktioniert im Terminal, aber nicht in Cron: PATH, SHELL oder fehlende absolute Pfade prüfen (Schritt 7).
Befehl mit date +%F bricht ab: % in der Crontab als \% schreiben.
Skript wird nicht ausgeführt: Prüfen, ob es ausführbar ist und ob der Shebang passt.
Keine Logs sichtbar: Ausgabe bewusst in eine Logdatei oder an Syslog leiten.
Job in /etc/cron.d/ läuft nicht: Benutzerfeld fehlt, Dateiname enthält einen Punkt, oder die Datei gehört nicht root bzw. ist für andere beschreibbar.
Skript in /etc/cron.daily wird ignoriert: Datei nicht ausführbar oder Name mit Punkt (.sh); prüfen mit run-parts --test /etc/cron.daily.

Häufige Fragen

Was ist der Unterschied zwischen Cron und crontab?

Cron ist der Dienst, der Jobs ausführt. crontab ist das Werkzeug, mit dem Sie Ihre Jobliste bearbeiten.

Warum sollte ich meine Crontab nicht direkt in Spool-Dateien bearbeiten?

crontab -e prüft die Syntax beim Speichern und setzt die Rechte korrekt. Direkte Änderungen an den Spool-Dateien umgehen beides.

Warum funktioniert ein Job manuell, aber nicht automatisch?

Weil Cron in einer anderen Umgebung läuft. Meist fehlen absolute Pfade oder es wird die falsche Shell vorausgesetzt.

Wann nutze ich /etc/cron.d statt crontab -e?

Wenn ein Job systemweit laufen oder unter einem bestimmten Benutzer ausgeführt werden soll und Sie ihn zentral, etwa per Konfigurationsmanagement, verwalten.

Warum ist Logging bei Cron so wichtig?

Weil ein Cronjob oft ohne sichtbares Fenster läuft. Ohne Logdatei oder Journal-Eintrag bemerken Sie Fehler erst, wenn das Ergebnis fehlt.

Wann ist ein systemd-Timer sinnvoller?

Wenn verpasste Läufe nachgeholt werden sollen, der Job von Netzwerk oder Mounts abhängt oder Sie Logs zentral im Journal brauchen.

Fazit

Legen Sie zuerst einen Testjob an, speichern Sie die Crontab mit crontab -e, leiten Sie die Ausgabe in ein Log und prüfen Sie, ob sie ankommt. Erst danach setzen Sie produktive Skripte ein.

Den zweiten Weg zur Automatisierung beschreibt die Anleitung zu systemd-Services. Für Rechte an Skripten, Logdateien und Verzeichnissen hilft Linux-Benutzer, Gruppen und Rechte verstehen.

Weiterführende Anleitungen und Quellen

Quellen: crontab(5), man7.org, cron(8), man7.org, crond(8), man7.org, run-parts(8), manpages.debian.org.