Automatisierung wiederkehrender Aufgaben mit Cron-Jobs

Dec 8, 2025 · 4 min read

Automatisierung wiederkehrender Aufgaben mit Cron-Jobs

Sie haben ein Skript geschrieben, das alte Logs löscht, eine Datenbank sichert oder einen Cache aufwärmt. Es funktioniert einwandfrei, wenn Sie es manuell ausführen. Jetzt soll es jede Nacht um 2 Uhr ohne Ihr Zutun laufen. Hier wird cron unverzichtbar.

Cron bleibt das Standardwerkzeug für die Planung von Skripten auf modernen Linux-Systemen. Zu verstehen, wie es funktioniert – und wann Alternativen sinnvoll sind – erspart Ihnen stille Fehler und Debugging-Kopfschmerzen.

Wichtigste Erkenntnisse

Cron ist ein zeitbasierter Job-Scheduler, der in Unix-ähnliche Systeme integriert ist und Befehle in festgelegten Intervallen mithilfe einer Fünf-Felder-Syntax ausführt
Verwenden Sie immer absolute Pfade in Cron-Jobs, da cron mit einer minimalen Umgebung läuft, die Ihre benutzerdefinierten PATH-Einstellungen nicht enthält
Fügen Sie Logging hinzu, verhindern Sie Job-Überschneidungen mit flock und beachten Sie Zeitzonenprobleme, um stille Fehler zu vermeiden
Für containerisierte oder Cloud-native Umgebungen sollten Sie Kubernetes CronJobs, AWS EventBridge oder anwendungsbasierte Scheduler anstelle von traditionellem cron in Betracht ziehen

Was ist Cron und wie funktioniert es?

Cron ist ein zeitbasierter Job-Scheduler, der in Unix-ähnliche Systeme integriert ist. Ein Hintergrund-Daemon liest Konfigurationsdateien (Crontabs) und führt Befehle in festgelegten Intervallen aus.

Es gibt zwei Arten von Crontabs:

Benutzer-Crontabs: Jeder Benutzer verwaltet seinen eigenen Zeitplan über crontab -e
System-Crontabs: Befinden sich in /etc/crontab und /etc/cron.d/, enthalten ein Benutzernamen-Feld und verwalten systemweite Aufgaben

Der Cron-Daemon prüft diese Dateien jede Minute und führt alle Jobs aus, deren Zeitplan mit der aktuellen Zeit übereinstimmt.

Cron-Syntax verstehen

Jeder Cron-Job folgt einer Zeitspezifikation mit fünf Feldern:

┌───────────── Minute (0-59)
│ ┌───────────── Stunde (0-23)
│ │ ┌───────────── Tag des Monats (1-31)
│ │ │ ┌───────────── Monat (1-12)
│ │ │ │ ┌───────────── Wochentag (0-6, Sonntag=0)
│ │ │ │ │
* * * * * /pfad/zum/befehl

Praktische Beispiele:

# Backup-Skript täglich um 2 Uhr nachts ausführen
0 2 * * * /home/deploy/scripts/backup.sh

# Temporäre Dateien jeden Sonntag um 3 Uhr morgens löschen
0 3 * * 0 /usr/bin/find /tmp -type f -mtime +7 -delete

# Alle 15 Minuten während der Geschäftszeiten, nur an Werktagen
*/15 9-17 * * 1-5 /home/deploy/scripts/health-check.sh

Nutzen Sie crontab.guru, um Ausdrücke vor dem Deployment zu validieren.

Wesentliche Best Practices für die Automatisierung von Aufgaben mit Cron-Jobs

Absolute Pfade verwenden

Cron läuft mit einer minimalen Umgebung. Ihr PATH enthält wahrscheinlich nicht /usr/local/bin oder benutzerdefinierte Verzeichnisse. Geben Sie immer vollständige Pfade an:

# Falsch - kann stillschweigend fehlschlagen
0 2 * * * backup.sh

# Richtig
0 2 * * * /home/deploy/scripts/backup.sh

Crons eingeschränkte Umgebung verstehen

Cron lädt Ihre .bashrc oder .profile nicht. Versionsmanager wie nvm, rbenv oder pyenv sind nicht verfügbar. Laden Sie sie entweder explizit oder verwenden Sie absolute Pfade zu spezifischen Binärdateien.

Logging und Alerting hinzufügen

Ohne Ausgabeumleitung bleiben Cron-Fehler unbemerkt:

0 2 * * * /home/deploy/scripts/backup.sh >> /var/log/backup.log 2>&1

Für kritische Jobs integrieren Sie Monitoring-Dienste wie Healthchecks.io oder Cronitor.

Überschneidende Jobs verhindern

Langläufige Tasks könnten noch ausgeführt werden, wenn die nächste geplante Ausführung startet. Verwenden Sie flock, um Überschneidungen zu verhindern:

0 * * * * /usr/bin/flock -n /tmp/report.lock /home/deploy/scripts/generate-report.sh

Prinzip der minimalen Rechte anwenden

Führen Sie nicht alles als root aus. Erstellen Sie dedizierte Service-Accounts für spezifische Aufgaben und verwenden Sie Benutzer-Crontabs anstelle systemweiter Konfigurationen.

Auf Zeitzonen- und Sommerzeitprobleme achten

Cron verwendet die Systemzeit. Sommerzeitübergänge können dazu führen, dass Jobs zweimal ausgeführt werden oder ganz ausfallen. Für kritische Planungen sollten Sie UTC in Betracht ziehen.

Cron vs. Systemd-Timer für die Automatisierung

Auf systemd-basierten Distributionen bieten Timer erwägenswerte Vorteile:

Funktion	Cron	Systemd-Timer
Logging	Manuelle Einrichtung	Integriertes journald
Verpasste Ausführungen	Übersprungen	Können nachgeholt werden
Abhängigkeiten	Keine	Vollständige Systemd-Integration
Ressourcenlimits	Manuell	Integrierte cgroups

Für einfache Automatisierung auf Host-Ebene auf einer VM funktioniert cron gut. Wenn Sie Abhängigkeitsverwaltung oder bessere Observability benötigen, lohnt sich der zusätzliche Konfigurationsaufwand für Systemd-Timer.

Cron-Jobs in containerisierten und Cloud-nativen Umgebungen

Traditionelles cron passt nicht sauber in Container. Einen Cron-Daemon neben Ihrer Anwendung laufen zu lassen, verstößt gegen das Prinzip eines Prozesses pro Container.

Bessere Alternativen:

Kubernetes CronJobs: Native Planung für containerisierte Workloads mit integrierter Retry-Logik
AWS EventBridge oder GCP Cloud Scheduler: Lambda-Funktionen oder Cloud Run Services nach Zeitplan auslösen
Anwendungsbasierte Scheduler: Tools wie node-cron für Node.js-Anwendungen

Für Webentwickler kann cron auf einer kleinen VM weiterhin Wartungsskripte auslösen, periodische Reports generieren oder Caches aufwärmen – auch wenn die Hauptanwendung anderswo läuft.

Fazit

Cron eignet sich hervorragend für einfache Automatisierung auf Host-Ebene: Backup-Skripte, Log-Rotation, Zertifikatserneuerungsprüfungen und periodische Aufräumarbeiten. Es ist leichtgewichtig, universell verfügbar und erfordert keine zusätzliche Infrastruktur.

Wählen Sie Alternativen, wenn Sie verteilte Planung, Container-Orchestrierung oder ausgefeilte Fehlerbehandlung benötigen. Die Konzepte bleiben gleich – moderne Scheduler haben die Syntax von cron aus gutem Grund übernommen.

Beginnen Sie mit einem einzelnen gut getesteten Job, fügen Sie ordentliches Logging hinzu und bauen Sie darauf auf.

FAQs

Cron läuft mit einer minimalen Umgebung, die Ihre Shell-Konfigurationsdateien wie .bashrc oder .profile nicht lädt. Das bedeutet, dass Ihre benutzerdefinierten PATH-Einstellungen und Versionsmanager nicht verfügbar sind. Beheben Sie dies, indem Sie absolute Pfade für alle Befehle und Skripte verwenden oder Ihre Umgebungsdateien explizit am Anfang Ihres Cron-Befehls laden.

Prüfen Sie zunächst, ob cron läuft mit systemctl status cron. Überprüfen Sie dann Ihre Crontab-Syntax mit crontab -l. Fügen Sie Logging hinzu, indem Sie die Ausgabe in eine Datei umleiten mit >> /pfad/zur/log 2>&1. Prüfen Sie System-Logs in /var/log/syslog oder /var/log/cron auf Fehlermeldungen. Stellen Sie außerdem sicher, dass Ihr Skript Ausführungsrechte hat.

Benutzer-Crontabs werden pro Benutzer über crontab -e verwaltet und führen Befehle als dieser Benutzer aus. System-Crontabs in /etc/crontab und /etc/cron.d/ enthalten ein zusätzliches Benutzernamen-Feld, das angibt, welcher Benutzer den Befehl ausführt. System-Crontabs werden typischerweise für systemweite Wartungsaufgaben verwendet und erfordern Root-Zugriff zum Bearbeiten.

Verwenden Sie cron für einfache, portable Skripte, die auf verschiedenen Unix-ähnlichen Systemen laufen müssen. Wählen Sie Systemd-Timer, wenn Sie integriertes Logging über journald benötigen, die Möglichkeit, verpasste Ausführungen nachzuholen, Abhängigkeitsverwaltung mit anderen Services oder Ressourcenlimits durch cgroups. Systemd-Timer erfordern mehr Konfiguration, bieten aber bessere Observability.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.