Wer Server betreibt, kennt das Problem: Wiederkehrende Aufgaben kosten Zeit, werden vergessen oder laufen mal auf dem falschen System. Ein Cronjob löst genau das, indem er Abläufe zuverlässig nach Zeitplan ausführt, egal ob Backup, Report oder Cleanup. Gerade in DevOps und Betrieb hilft das, Routinearbeit zu standardisieren und Lastspitzen zu glätten, zum Beispiel wenn mehrere Cron-Jobs nicht alle zur vollen Stunde starten. In diesem Beitrag schauen wir uns an, wie Cronjobs funktionieren, wie man sie sauber definiert und wie man typische Fehler schnell findet.
Was ist ein Cronjob?
Ein Cronjob ist eine zeitgesteuerte Aufgabe unter Unix und Linux, die vom Cron-Daemon im Hintergrund ausgeführt wird. Typisch sind drei Bausteine: ein Skript oder Programm, der geplante Aufruf und eine definierte Ausgabe, etwa in eine Logdatei oder per E-Mail. In vielen Admin-Setups spricht man dabei auch von Linux-Cron, weil Cron dort seit Jahrzehnten ein Standardwerkzeug ist.
Crontab: Wo Cronjobs definiert werden
Die Zeitpläne liegen in der Crontab. Man unterscheidet grob zwischen User-Crontab und System-Crontab. Mit crontab -e bearbeitest du die User-Crontab des aktuellen Users, also genau den Bereich, in dem die meisten Team-Workflows starten. System-Crontabs liegen dagegen unter /etc/crontab und als einzelne Dateien unter /etc/cron.d/*. Dort gibt es ein zusätzliches Feld für den Benutzer, unter dessen Kontext der Job laufen soll.
Grundsyntax der Crontab-Zeile
Eine Zeile in der Crontab besteht aus fünf Zeitfeldern und dem Befehl. Die Felder sind Minute, Stunde, Tag im Monat, Monat, Wochentag, danach folgt der auszuführende Command. In Crontab Linux sind drei Muster besonders wichtig:
- Stern * bedeutet: immer.
- Listen wie 1,15 bedeuten: zu diesen Werten.
- Intervalle wie */10 bedeuten: alle 10 Einheiten.
Beispiele:
# Jede Minute
* * * * * /usr/local/bin/healthcheck.sh
# Um 03:15 Uhr jeden Montag
15 3 * * 1 /usr/local/bin/report.sh
# Alle 10 Minuten
*/10 * * * * /usr/local/bin/sync.sh
Vordefinierte Zeit-Events
Neben den klassischen Feldern kennt die Crontab auch vordefinierte Events, die lesbarer sind. In vielen Teams werden sie genutzt, um Missverständnisse zu vermeiden, besonders bei Cron-Job-Linux-Setups:
- @reboot: startet beim Boot, praktisch für Warmup oder Cache-Aufbau.
- @hourly: einmal pro Stunde, gut für kleine Metrik-Jobs.
- @daily: täglich, häufig für Backups oder Reports.
- @weekly: wöchentlich, etwa für Cleanup mit geringer Dringlichkeit.
- @monthly: monatlich, zum Beispiel Rechnungs- oder Archivläufe.
Wie funktioniert ein Cronjob?
Der Cronjob selbst ist die geplante Aufgabe, Cron ist der Motor dahinter. Der Cron-Daemon liest die Zeitpläne aus der Crontab, prüft jede Minute die fälligen Einträge und startet Jobs nicht interaktiv. Das ist wichtig: Ein Job läuft ohne Terminal, ohne Shell-Profil und oft mit deutlich weniger Umgebungsvariablen, als du es von Hand gewohnt bist. Genau deshalb stolpert man bei Linux-Cron häufig über Pfade, Rechte und unerwartete Ausgaben, wenn man den Job das erste Mal produktiv laufen lässt.
Wichtige Umgebungsvariablen
Bei Cronjobs machen drei Variablen in der Praxis den Unterschied zwischen “läuft immer” und “läuft nur bei mir”:
- PATH: Cron hat oft einen minimalen PATH. Wenn dein Skript php, Python oder curl nutzt, setze entweder absolute Pfade oder definiere PATH explizit.
- SHELL: bestimmt, welche Shell den Befehl ausführt. Wenn du Bash-Features nutzt, ist /bin/bash oft sinnvoll.
- MAILTO: steuert, ob Cron die Ausgabe per Mail verschickt. Das ist nützlich zum Debuggen, aber in der Produktion oft zu laut.
Ein Beispiel für Kopfzeilen:
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=""Damit steuerst du Verhalten und Erwartungshaltung deiner Cron-Job-Linux-Jobs sehr gezielt.
Cronjob erstellen unter Linux
Wenn du einen Cronjob erstellen willst, hilft ein klarer Ablauf. So vermeidest du typische Anfängerfehler und hast von Anfang an saubere Logs für spätere Analysen. Auch bei mehreren geplanten Tasks, etwa für Backups, Reports oder Rotationen, lohnt sich ein standardisiertes Vorgehen. So gehst du unter Linux pragmatisch vor:
- Skript ablegen
Lege das Skript an einen festen Ort, zum Beispiel /usr/local/bin/. Vermeide Pfade in Home-Verzeichnissen, wenn der Job später als anderer User laufen soll. - Rechte setzen
Mache das Skript ausführbar:
chmod +x /usr/local/bin/backup.sh- Job in die User-Crontab eintragen
Öffne die Crontab:
crontab -e- Eintrag hinzufügen
Zum Beispiel täglich um 06:00:
0 6 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1- Test und Logging
Starte das Skript einmal manuell. Prüfe, ob alle Pfade stimmen und ob das Logging wirklich schreibt. Gerade bei einem Linux-Cron-Job ist der manuelle Test ein schneller Reality-Check.
Typische Aufgaben für Cronjobs
Cronjobs eignen sich für Aufgaben, die regelmäßig laufen sollen und keinen interaktiven Input brauchen. Typische Beispiele im Serverbetrieb sind:
- Backups von Dateien oder Datenbanken
- Datenbank-Bereinigung und Archivierung
- Generierung von Statistiken und Reports
- Fetching von RSS oder Feeds
- Inhalte planen und veröffentlichen
- Newsletter-Versand über interne Tools
- Rechnungen erzeugen oder exportieren
- Updates, Cache-Warmups, Healthchecks
Ein Praxis-Tipp: Wenn mehrere Jobs viel IO erzeugen, verteile sie zeitlich. Zwei Backups um 02:00 können eine Lastspitze erzeugen, während ein Backup um 02:00 und das zweite um 02:20 die Kurve glättet.
Ausgabe der Cronjobs steuern
Standardmäßig schickt Cron die Ausgabe eines Jobs oft per E-Mail an den User. Das ist praktisch, aber schnell unübersichtlich. Für Cronjobs haben sich vier pragmatische Varianten etabliert:
- In eine Logdatei schreiben
/usr/local/bin/task.sh >> /var/log/task.log 2>&1- Ausgabe unterdrücken
/usr/local/bin/task.sh > /dev/null 2>&1- Mail abschalten über Kopfzeile
MAILTO=""- In Syslog schreiben mit Logger
/usr/local/bin/backup.sh 2>&1 | /usr/bin/logger -t backupGerade im Cron-Job-Linux-Alltag ist Syslog oft angenehmer, weil du zentrale Log-Tools nutzen kannst. Für reine Batch-Jobs reicht häufig eine eigene Logdatei, solange Rotationen geplant sind.
System-Crontab und Cronjob-Dateien
Neben der User-Crontab gibt es die systemweiten Stellen. Für Crontab Linux sind das typischerweise:
- /etc/crontab
- /etc/cron.d/
Zusätzlich existieren häufig periodische Ordner:
- /etc/cron.hourly
- /etc/cron.daily
- /etc/cron.weekly
- /etc/cron.monthly
Diese Ordner sind praktisch, wenn du Jobs “periodisch“ statt “minutengenau“ organisieren willst. Für komplexere Zeitpläne bleibt die klassische Crontab meist klarer.
Cronjob-Beispiele aus der Praxis
Hier ein paar konkrete Zeilen aus der Praxis. Die Syntax wiederhole ich nicht, der Fokus liegt auf typischen Mustern und sauberen Logs.
Beispiel 1: Tägliches Backup um 06:00
0 6 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1Zweck: Backup läuft außerhalb typischer Business-Peaks und schreibt nachvollziehbar ins Log, passend für einen stabilen Cron-Job-Linux-Ablauf.
Beispiel 2: Alle 30 Minuten eine Aufgabe
*/30 * * * * /usr/local/bin/pull_metrics.sh >> /var/log/metrics.log 2>&1Zweck: Gute Balance aus Aktualität und Last. Wenn das Skript 20 Sekunden braucht, bleibt genug Puffer. Wenn es aber 40 Minuten läuft, droht Job-Overlap, dann brauchst du Locking. Das ist ein klassischer Fall beim Erstellen eines Cron-Jobs.
Beispiel 3: Erinnerungs-E-Mails zu zwei Uhrzeiten
0 9,15 * * 1-5 /usr/local/bin/reminder_mail.sh >> /var/log/reminder.log 2>&1Zweck: Zwei feste Zeiten, nur werktags. Für Teams, die mehrere Cron-Jobs parallel betreiben, ist diese Lesbarkeit Gold wert.
Beispiel 4: Cleanup oder Logrotation mit Logging
30 2 * * * /usr/local/bin/cleanup.sh >> /var/log/cleanup.log 2>&1Zweck: Cleanup nachts, mit eigener Logdatei. Bei Cronjobs ist “Beweisführung” oft wichtiger als Perfektion, deshalb ist Logging hier bewusst dabei.
Häufige Fehler und schnelle Checks
Bei Cronjob-Setups sind viele Probleme banal, aber kosten Zeit, wenn man sie nicht systematisch prüft. Die wichtigsten Stolpersteine plus schnelle Lösungen:
- Absolute Pfade und “sauberes” Umfeld
Nutze volle Pfade wie /usr/bin/php oder /bin/bash. Wenn nötig, setze PATH in der Crontab explizit. - Zeitzone und DST
Prüfe, welche Zeitzone der Server nutzt. Sommer- und Winterzeit können Jobs verschieben. Als Option kannst du CRON_TZ=Europe/Berlin setzen, wenn du die Zeitzone gezielt steuern willst, besonders bei globalen Setups mit Cron Job Linux. - Job-Overlap vermeiden
Wenn das Intervall kürzer ist als die Laufzeit, laufen Jobs parallel. Das erzeugt doppelte Last und manchmal kaputte Daten. Nutze Flock oder eine Lock-Datei:
*/10 * * * * flock -n /tmp/job.lock /usr/local/bin/heavy_job.sh >> /var/log/heavy_job.log 2>&1Ein kurzes Rechenbeispiel: Läuft ein Job 12 Minuten, ist aber auf alle 10 Minuten geplant, dann starten innerhalb einer Stunde bis zu 6 Läufe, von denen sich mehrere überlappen. Selbst wenn jeder Lauf nur 15 Prozent CPU braucht, kann daraus eine echte Lastspitze werden.
- Rechte und Interpreter
Prüfe Ausführungsrechte, Shebang und Shell. Ein Skript ohne #!/bin/bash kann in Cron anders laufen als im Terminal. Genau hier entstehen viele “läuft bei mir“-Bugs, gerade in Linux-Cron-Umgebungen.
Logs schnell prüfen
Wenn du wissen willst, ob Cronjobs wirklich gelaufen sind, helfen ein paar Standardpfade. Die genaue Ablage hängt von Distribution und Logging-Setup ab:
- RHEL, CentOS, Alma, Rocky: oft /var/log/cron
- Debian, Ubuntu: häufig in /var/log/syslog, filtern mit grep CRON
- systemd-Systeme: journalctl -u cron oder journalctl -u crond
Der typische Startpunkt: zuerst nach dem Jobnamen oder Tag suchen, dann die Exit-Codes und Fehlerausgaben prüfen. In Crontab-Linux-Projekten lohnt sich außerdem, jeden wichtigen Job in eine eigene Logdatei zu schreiben, mindestens während der Einführungsphase.
Mini-Referenz: Nützliche Befehle
Ein paar Befehle, die du im Alltag unter Linux rund um die Crontab ständig brauchst:
crontab -e # User-Crontab bearbeiten
crontab -l # User-Crontab anzeigen
crontab -r # User-Crontab löschen (Vorsicht, alles weg)Als Admin, um die Crontab eines Users zu sehen:
crontab -u USER -lCronjobs planbar und nachvollziehbar betreiben
Cronjobs sind am stärksten, wenn sie planbar und überprüfbar bleiben. Wähle Zeitfenster, die zur Infrastruktur passen, sorge für Logging oder Syslog-Einträge, teste Änderungen kurz im Kleinen und halte Pfade sowie Variablen sauber. Wenn Jobs länger laufen können, verhindere parallele Läufe, sonst entstehen schleichende Lastspitzen und schwer erklärbare Fehlerbilder. Wer so vorgeht, kann einen Cronjob erstellen und später auch ohne Bauchgefühl beurteilen, ob Automatisierung wirklich stabil läuft.
Häufig gestellte Fragen
Cronjob oder Crontab: Was ist der Unterschied?
Ein Cronjob ist die geplante Aufgabe, also der Eintrag, der zu einem bestimmten Zeitpunkt ausgeführt wird. Die Crontab ist die Datei, in der Zeitplan und Befehl stehen. Mit crontab -e bearbeitest du die User-Crontab deines Accounts. In Teams ist das meist der erste Schritt, bevor man systemweite Einträge unter /etc/crontab oder in /etc/cron.d/ pflegt.
Wie deaktiviere oder stoppe ich einen Cronjob schnell?
Drei schnelle Optionen für Cronjob und Cronjobs:
- Zeile auskommentieren, indem du am Anfang # setzt.
- Eintrag entfernen über crontab -e.
- Komplett löschen mit crontab -r. Das ist radikal, deshalb vorher die aktuelle Liste mit crontab -l sichern oder kopieren. Wenn du viele Jobs verwaltest, lohnt sich eine kleine Backup-Routine für die Konfiguration.
Wie setze ich eine andere Zeitzone nur für einen Job?
Du kannst CRON_TZ=Europe/Berlin oberhalb der Jobzeile setzen. Das gilt dann für die folgenden Einträge, je nach Implementierung auch nur für einen bestimmten Abschnitt. Achte auf die Auswirkungen der Sommer- und Winterzeit: Bei Zeitumstellungen können Läufe ausfallen oder doppelt stattfinden. In größeren Umgebungen mit vielen Cronjobs ist es oft sinnvoll, Zeitpläne in UTC zu definieren und die Anzeige nur im Monitoring lokal umzusetzen.
Wie verhindere ich parallele Läufe bei Intervallen?
Wenn die Laufzeit länger sein kann als das Intervall, nutze Flock:
*/5 * * * * flock -n /tmp/job.lock /usr/local/bin/job.sh >> /var/log/job.log 2>&1Das ist in der Praxis eine bewährte Methode für Cronjobs in Produktion, vor allem bei IO-lastigen Tasks.
Wo prüfe ich, ob ein Cronjob wirklich gelaufen ist?
Für Cronjobs gibt es drei schnelle Wege:
- /var/log/cron auf RHEL, CentOS, Alma, Rocky
- /var/log/syslog auf Debian, Ubuntu, filtern mit grep CRON
- journalctl -u cron oder journalctl -u crond auf systemd-Systemen
Alternativ kannst du die Ausgabe in eine Logdatei umleiten oder mit logger ins Systemlog schreiben. Wenn du zusätzlich noch einen „Start“- und “Ende“-Logeintrag im Skript selbst setzt, wird die Fehlersuche deutlich einfacher, besonders bei Linux-Cron-Aufgaben, die nur selten laufen.
