Cron / Crontab erklärt — Zeitsteuerung für Linux-Server

Direkte Antwort: Cron ist ein Linux-Daemon, der Befehle nach Zeitplan ausführt. Der Plan steht in der Crontab-Datei und folgt einer 5-Felder-Syntax (Minute Stunde Tag Monat Wochentag). OpenClaws Heartbeat-System ist eine LLM-fähige Erweiterung dieses Konzepts.

Was ist Cron?

Cron ist eines der ältesten und nützlichsten Tools in Linux. Es ist ein Daemon, der im Hintergrund läuft und zeitgesteuert Befehle ausführt. Egal ob du jeden Morgen um 3 Uhr ein Backup machen willst, alle 15 Minuten Logs rotierst oder einmal pro Woche eine Statistik generierst — Cron erledigt das.

Die Konfiguration läuft über die Crontab ("cron table"), eine Datei mit einer Zeile pro geplantem Job. Jede Zeile beschreibt: "Wann soll was ausgeführt werden?"

Kontext

Cron ist seit den 1970er-Jahren Bestandteil von Unix-Systemen. Trotz vieler Alternativen (systemd-Timer, At, Anacron) bleibt Cron der De-facto-Standard für simple Zeitsteuerung. Auf Hetzner-VPS und allen gängigen Linux-Distributionen ist es vorinstalliert.

Im Kontext von OpenClaw ist Cron weiterhin nützlich für nicht-LLM-Aufgaben: Backups, Log-Rotation, Server-Wartung. Für Aufgaben, die KI-Logik brauchen, nutzt du den eingebauten Heartbeat.

Cron-Syntax

Eine Crontab-Zeile hat fünf Zeit-Felder gefolgt vom Befehl:

*  *  *  *  *  /pfad/zum/befehl
|  |  |  |  |
|  |  |  |  +-- Wochentag (0-7, 0+7 = Sonntag)
|  |  |  +----- Monat (1-12)
|  |  +-------- Tag im Monat (1-31)
|  +----------- Stunde (0-23)
+-------------- Minute (0-59)

Sonderzeichen:

• * — jeder Wert
• */5 — alle 5 (z.B. alle 5 Minuten)
• 1,15,30 — diese spezifischen Werte
• 1-5 — Bereich (Montag bis Freitag)

Praxis-Beispiel

Eine Crontab editierst du mit:

crontab -e

Beispiele für Cron-Einträge:

# Jeden Tag um 03:00 Uhr ein Backup laufen lassen
0 3 * * * /home/user/backup.sh

# Alle 15 Minuten Logs rotieren
*/15 * * * * /usr/local/bin/log-rotate

# Montag bis Freitag um 09:00 Uhr ein Briefing generieren
0 9 * * 1-5 /home/user/briefing.sh

# Jeden Sonntag um 04:00 Uhr volle Diskspace-Aufräumung
0 4 * * 0 /home/user/cleanup.sh

# Alle 30 Minuten OpenClaw Memory-Backup
*/30 * * * * cp ~/.openclaw/memory.json ~/backups/memory-$(date +\%H\%M).json

Cron schickt die Ausgabe per Mail an den User (falls Mail eingerichtet) oder verschluckt sie. Praxis-Tipp: Output explizit in Logfiles umleiten:

0 3 * * * /home/user/backup.sh >> /var/log/backup.log 2>&1

Cron-Verzeichnisse statt Crontab

Neben der per-User-Crontab gibt es System-Cron-Verzeichnisse:

| Verzeichnis | Wann | | --- | --- | | /etc/cron.hourly/ | jede Stunde | | /etc/cron.daily/ | täglich | | /etc/cron.weekly/ | wöchentlich | | /etc/cron.monthly/ | monatlich |

Skripte hier reinlegen und sie laufen automatisch — ohne Crontab-Eintrag.

Cron vs. systemd Timer

Moderne Systeme bieten systemd-Timer als Alternative:

| Aspekt | Cron | systemd Timer | | --- | --- | --- | | Syntax | Kompakt, kryptisch | Verbose YAML/INI | | Logs | Mail oder selbst routen | journalctl integriert | | Abhängigkeiten | Keine | After=, Wants= etc. | | Persistenz | Verpasste Jobs verloren | Persistent=true möglich | | Reboots | Job verfällt | Catch-Up nach Reboot |

Für simple Zeitsteuerung bleibt Cron schlanker. Für komplexere Service-Orchestrierung greifen viele zu systemd-Timern.

Cron vs. OpenClaw Heartbeat

Cron triggert "dumme" Befehle. Heartbeat triggert KI-Prompts. Wenn du z.B. willst, dass der Agent jeden Morgen ein intelligentes Briefing erstellt mit Wetter + Kalender + News-Highlights, ist Heartbeat richtig. Wenn du nur ein Backup-Skript starten willst, ist Cron richtig.

Heartbeat ist also nicht Cron-Ersatz, sondern Cron-Ergänzung: Beides läuft auf demselben Server, beides erfüllt unterschiedliche Bedürfnisse.

Häufige Fehler / Stolperfallen

1. Falsches Environment: Cron startet mit minimalem PATH. Wenn dein Skript node oder python nutzt, kann es sein, dass es nicht gefunden wird. Lösung: vollständige Pfade nutzen oder PATH in Crontab setzen.
2. Logs verloren: Ohne explizites Logging weißt du nie, ob Jobs laufen. Immer >> logfile 2>&1 anhängen.
3. Zeitzone falsch: Cron läuft in System-Zeitzone. Wenn dein Server UTC, du aber CET denkst, feuern Jobs zur falschen Stunde. timedatectl oder CRON_TZ=Europe/Berlin nutzen.
4. Überlappende Jobs: Wenn ein Backup länger als 5 Min dauert und alle 5 Min gestartet wird, frisst sich das System auf. flock oder Lock-Files nutzen.
5. Test schwierig: Cron-Bugs zeigen sich erst nach Tagen. Während Entwicklung manuell starten, nicht auf Cron warten.

Cron-Helper: crontab.guru

Für die Cron-Syntax, die selbst Profis manchmal verwirrt, gibt es crontab.guru. Du tippst einen Cron-String ein und siehst sofort in Klartext, wann der Job feuern wird. Pflicht-Bookmark.

Cron im OpenClaw-Kontext

Auf einem typischen OpenClaw-Server sind Cron-Jobs sinnvoll für:

• Tägliche Backups der Soul.md, User.md, Memory
• Log-Rotation für journalctl und Custom-Logs
• Periodisches Cleanup von Temp-Files
• Re-Indexierung deiner RAG-Vector-DB
• Renewal von SSL-Zertifikaten (auch wenn certbot dafür eigene Timer hat)

Heartbeats übernehmen alles, was KI-Logik braucht. Die Trennung ist sauber: Cron für Infrastruktur, Heartbeat für Inhalt.

Verwandte Begriffe

• Heartbeat
• systemd
• Gateway
• Skills

Cron + Heartbeat im Detail: Modul 5 der Masterclass.