Generator · Linux
Cron-Generator
Fünf Felder entscheiden, wann cron einen Befehl startet — und genau dort passieren die typischen Fehler: ein * zu viel, ein vergessenes Prozentzeichen, die falsche Zeitzone. Hier baust du die Zeile, liest sie in Worten und siehst die nächsten fünf Ausführungen in der Zeitzone deines Servers. Ausgeführt oder gespeichert wird nichts.
Beispiel laden
Zeitplan
* = jeder Wert · 1,15 = Liste · 1-5 = Bereich · */10 = alle 10 · 8-18/2 = alle 2 im Bereich
Vorhandene Zeile einfügen und erklären lassen
In Worten
Um 03:15 Uhr, täglich
Zeile für crontab -e
15 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1Mit crontab -e öffnen, Zeile am Ende einfügen, speichern. Prüfen mit crontab -l. Für Root-Aufgaben sudo crontab -e.
Nächste Ausführungen (Europe/Berlin)
Wird berechnet …
Berechnet in deinem Browser ab dem aktuellen Zeitpunkt. Verhalten bei der Zeitumstellung wie in man 8 cron von Debian beschrieben.
Die fünf Felder
Eine crontab-Zeile beginnt mit Minute, Stunde, Tag des Monats, Monat und Wochentag, danach folgt der Befehl. 15 3 * * * heißt also „um 3:15 Uhr an jedem Tag“. Ein * steht für jeden Wert, */15 für jeden fünfzehnten, 1-5 für einen Bereich und 1,15 für eine Liste. Beim Wochentag sind 0 und 7 beide Sonntag.
Die Falle mit Tag und Wochentag
Schränkst du Tag des Monats und Wochentag ein, startet cron den Befehl, sobald eines der beiden passt. 0 0 13 * 5 läuft deshalb an jedem 13. und zusätzlich an jedem Freitag — nicht nur an Freitagen, die auf einen 13. fallen. So steht es in man 5 crontab; der Generator weist darauf hin und zeigt es in der Vorschau.
Zeitzone und Zeitumstellung
cron kennt nur die Uhr des Servers. Läuft der Server in UTC, startet 0 3 * * * im Sommer um 5 Uhr deutscher Zeit. Bei der Umstellung auf Sommerzeit gibt es 2:00 bis 2:59 Uhr nicht: Jobs mit fester Uhrzeit in dieser Stunde startet cron kurz nach der Umstellung, und in der doppelten Stunde im Herbst laufen sie nur einmal. Ausdrücke mit * in Minute oder Stunde folgen dagegen einfach der Uhr.
Häufige Fragen
Warum läuft mein Cronjob nicht, obwohl er von Hand funktioniert?
Meist liegt es an der Umgebung: cron startet mit einem sehr kurzen PATH, ohne deine Shell-Einstellungen und im Heimatverzeichnis des Benutzers. Volle Pfade zu Programmen und Dateien lösen das. Der zweite Klassiker ist ein unmaskiertes Prozentzeichen, etwa in date +%F — cron schneidet den Befehl dort ab.
Wo sehe ich, ob ein Cronjob gelaufen ist?
Auf Debian und Ubuntu protokolliert cron jeden Start im Systemjournal, abrufbar mit journalctl -u cron. Die Ausgabe des Befehls selbst steht dort nicht — die verschickt cron per Mail oder du leitest sie in eine Logdatei um.
crontab -e oder /etc/cron.d?
crontab -e bearbeitet die persönliche Tabelle eines Benutzers, die Zeile hat kein Benutzerfeld. Dateien in /etc/cron.d gehören zum System, brauchen nach den Zeitfeldern den Benutzer und einen Dateinamen ohne Punkt. Für Aufgaben, die ein Paket oder eine Konfigurationsverwaltung ausrollt, ist /etc/cron.d übersichtlicher.
Ist ein systemd-Timer die bessere Wahl?
Für Aufgaben, die verpasste Läufe nachholen, Abhängigkeiten haben oder sauber im Journal landen sollen, oft ja. Für einen einfachen nächtlichen Befehl ist cron weiterhin völlig ausreichend und schneller eingerichtet.
Passende Tools
chmod-Rechner →
Rechte per Klick setzen und zwischen 750, rwxr-x--- und chmod-Befehl umrechnen — mit Erklärung für Datei und Verzeichnis, Sonderbits und Warnung vor 777.
systemctl Command Builder →
Dienste starten, stoppen und in den Autostart nehmen — von status bis enable --now, jede Aktion erklärt.
journalctl Command Builder →
System-Logs gezielt lesen: nach Dienst, Zeitraum und Priorität filtern — inklusive Logs des vorherigen Boots.