Cronjob einrichten: Aufgaben automatisch zur richtigen Zeit

Einen Cronjob einrichten heißt, dem Server zu sagen: Führe diesen Befehl zu dieser Zeit aus, immer wieder, ohne dass jemand daneben sitzt. So laufen nächtliche Backups, der Versand von Newslettern, das Leeren von Caches oder die geplanten Beiträge in WordPress. Auf dem Webspace geht das meist über ein Formular im Kundenmenü, auf einem eigenen Server über die Datei crontab. In beiden Fällen ist die Zeitangabe gleich aufgebaut, und die meisten Fehler entstehen an denselben drei Stellen.

Was ein Cronjob ist

Cron ist ein Dienst, der auf fast jedem Linux-Server läuft. Er schaut jede Minute in seine Liste von Aufgaben und startet alles, dessen Zeit gekommen ist. Eine Aufgabe heißt Cronjob, die Liste heißt Crontab. Jeder Benutzer hat seine eigene Crontab, die Befehle laufen mit seinen Rechten.

Wichtig für das Verständnis, bevor Sie einen Cronjob einrichten: Er läuft ohne Browser und ohne Besucher. Er ruft ein Skript direkt auf dem Server auf oder holt eine Adresse ab. Was das Skript ausgibt, sieht niemand, außer Sie leiten es in eine Datei oder eine Mail.

Die Zeitangabe lesen und schreiben

Jede Zeile einer Crontab beginnt mit fünf Feldern für die Zeit, danach folgt der Befehl. Die Felder stehen für Minute, Stunde, Tag im Monat, Monat und Wochentag. Ein Sternchen bedeutet „jeder“. Wer einen Cronjob einrichten will, braucht nur diese fünf Felder zu verstehen.

# Minute Stunde Tag Monat Wochentag  Befehl
30 3 * * *     /home/kunde/bin/backup.sh       # täglich um 3:30 Uhr
*/15 * * * *   /usr/bin/php /home/kunde/cron.php  # alle 15 Minuten
0 7 * * 1      /home/kunde/bin/bericht.sh      # montags um 7:00 Uhr
0 2 1 * *      /home/kunde/bin/aufraeumen.sh   # am Ersten des Monats um 2:00 Uhr

Beim Wochentag steht 0 und 7 für Sonntag, 1 für Montag. Mit Kommas geben Sie mehrere Werte an, etwa 0 8,12,18 * * * für dreimal am Tag. Ein Bindestrich steht für einen Bereich, 1-5 heißt Montag bis Freitag. Wenn Sie unsicher sind, prüfen Sie Ihre Angabe mit einem Hilfsmittel wie crontab.guru, das die Zeile in Worte übersetzt.

Achten Sie auf die Zeitzone. Viele Server laufen auf UTC. Ein Job für 3 Uhr startet dann im Sommer um 5 Uhr deutscher Zeit. Ob das stört, hängt von der Aufgabe ab. Den Server-Zeitpunkt zeigt der Befehl date.

Cronjob einrichten im Kundenmenü

Beim Shared Hosting haben Sie in der Regel keinen Zugriff auf die Crontab, dafür gibt es ein Formular. In Plesk heißt es „Geplante Aufgaben“, in cPanel „Cron Jobs“, bei anderen Anbietern oft „Cronjobs“ oder „Zeitgesteuerte Aufgaben“. Meist wählen Sie zwischen drei Arten:

• Befehl ausführen: ein Shell-Befehl oder Skript auf dem Webspace.
• PHP-Skript ausführen: Sie geben den Pfad zur Datei an und wählen die PHP-Version.
• Adresse abrufen: Der Server ruft eine URL auf, so als ob ein Besucher käme.

Manche günstigen Tarife erlauben Cronjobs nur stündlich oder gar nicht. Steht in der Tarifbeschreibung nichts dazu, fragen Sie vor dem Vertrag nach. Für einen Shop oder eine Seite mit Newsletter ist das ein wichtiges Merkmal. Ob Sie einen Cronjob einrichten können und in welchem Takt, steht oft erst in den technischen Details des Tarifs.

Cronjob einrichten auf dem eigenen Server

Auf einem vServer oder Root-Server bearbeiten Sie die Crontab Ihres Benutzers mit crontab -e. Beim ersten Aufruf fragt das System nach einem Editor, für Einsteiger ist nano die einfachste Wahl. Fügen Sie die Zeile ein, speichern Sie, fertig. Mit crontab -l sehen Sie die aktuelle Liste. Wie Sie per SSH auf den Server kommen, zeigt der Ratgeber zum SSH-Zugang.

Aufgaben, die als Root laufen müssen, gehören in die Crontab von Root (sudo crontab -e) oder als Datei nach /etc/cron.d/. In diesen Dateien steht zwischen Zeit und Befehl zusätzlich der Benutzer:

# /etc/cron.d/datenbank-export
15 2 * * * root /usr/local/bin/db-export.sh

Auf modernen Systemen gibt es als Alternative die Timer von systemd. Sie protokollieren jeden Lauf im Journal und holen verpasste Läufe nach, wenn der Server zur geplanten Zeit aus war. Ein Timer besteht aus zwei kleinen Dateien, einem Dienst und dem Zeitplan:

# /etc/systemd/system/db-export.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/db-export.sh

# /etc/systemd/system/db-export.timer
[Timer]
OnCalendar=*-*-* 02:15:00
Persistent=true

[Install]
WantedBy=timers.target

Mit sudo systemctl enable --now db-export.timer ist er aktiv, und systemctl list-timers zeigt den nächsten Lauf. Für ein, zwei einfache Aufgaben bleibt Cron übersichtlicher, für wichtige Aufgaben auf eigenen Servern lohnen sich Timer.

Die drei häufigsten Fehler, wenn Sie einen Cronjob einrichten

1. Relative Pfade. Ein Cronjob startet nicht in Ihrem Projektordner und kennt nicht dieselben Einstellungen wie Ihre SSH-Sitzung. Der Suchpfad für Programme ist sehr kurz. Schreiben Sie deshalb immer den vollen Pfad, also /usr/bin/php statt php und /home/kunde/cron.php statt cron.php. Den Pfad zu einem Programm zeigt which php. Wechselt Ihr Skript selbst in Ordner, setzen Sie davor ein cd /home/kunde/projekt &&.

2. Falsche PHP-Version. Auf dem Webspace laufen oft mehrere PHP-Versionen nebeneinander. Die Website nutzt vielleicht PHP 8.3, der Befehl php in der Konsole aber eine ältere Version. Im Kundenmenü wählen Sie die Version direkt aus. In der Konsole nehmen Sie den vollen Pfad, den Ihr Anbieter nennt, zum Beispiel /usr/bin/php8.3. Mehr zum Prüfen der Version steht im Ratgeber PHP-Version ändern.

3. Prozent-Zeichen. In der Crontab hat % eine Sonderbedeutung und beendet den Befehl. Ein Dateiname mit $(date +%F) funktioniert in der Konsole, im Cronjob nicht. Schreiben Sie \% oder legen Sie den Befehl in ein eigenes Skript.

Einen neuen Cronjob testen

Verlassen Sie sich nie darauf, dass ein neuer Job von selbst klappt. So prüfen Sie ihn in fünf Minuten:

1. Führen Sie den Befehl einmal von Hand in der Konsole aus, genau so, wie er in der Crontab steht. Läuft er dort nicht, läuft er auch im Cronjob nicht.
2. Tragen Sie den Job mit einer Zeit in zwei oder drei Minuten ein, zum Beispiel 47 14 * * *, wenn es gerade 14:44 Uhr ist.
3. Hängen Sie eine Umleitung in eine Protokolldatei an, wie im nächsten Abschnitt beschrieben.
4. Warten Sie die Zeit ab und lesen Sie die Datei, etwa mit tail -n 20 /home/kunde/logs/cron.log, oder im Dateimanager des Kundenmenüs.
5. Stellen Sie danach den endgültigen Takt ein.

Auf einem eigenen Server sehen Sie im Systemprotokoll zusätzlich, ob Cron den Job überhaupt gestartet hat. Unter Debian und Ubuntu zeigt das journalctl -u cron --since "10 min ago". Steht dort der Start, aber im eigenen Protokoll nichts, liegt der Fehler im Befehl selbst.

Ein praktisches Beispiel für den Anfang ist ein nächtlicher Export der Datenbank. Legen Sie das Skript /home/kunde/bin/db-export.sh an, machen Sie es mit chmod 700 ausführbar und tragen Sie es um 2:15 Uhr ein:

#!/bin/sh
cd /home/kunde/backup || exit 1
mysqldump --defaults-extra-file=/home/kunde/.my.cnf meine_db | gzip > db-$(date +%F).sql.gz
find /home/kunde/backup -name 'db-*.sql.gz' -mtime +14 -delete

Die Zugangsdaten stehen in der Datei .my.cnf, die nur Sie lesen dürfen, und nicht im Skript. Die letzte Zeile löscht Exporte, die älter als 14 Tage sind. Im Skript ist das Prozentzeichen erlaubt, nur direkt in der Crontab nicht. Wie Sie die Exporte zusätzlich an einen zweiten Ort bringen, steht im Ratgeber zum Website-Backup.

Ausgaben und Fehlermeldungen steuern

Was ein Cronjob ausgibt, schickt Cron per Mail an den Benutzer, sofern ein Mailversand eingerichtet ist. Im Kundenmenü gibt es dafür meist ein Feld für die Empfängeradresse. In der Crontab setzen Sie dafür ganz oben eine Zeile MAILTO=sie@beispiel.de. Das ist nützlich, solange nur Fehler kommen. Läuft ein Job alle fünf Minuten und schreibt jedes Mal etwas, ist das Postfach schnell voll.

Besser ist eine Protokolldatei. Hängen Sie an den Befehl >> /home/kunde/logs/cron.log 2>&1 an. Dann landen normale Ausgaben und Fehler in der Datei, und Sie können nachlesen, was passiert ist. Wer Ausgaben komplett verwirft, mit > /dev/null 2>&1, merkt nicht, wenn der Job seit Wochen scheitert. Für wichtige Aufgaben wie Backups lohnt sich ein Dienst, der Alarm schlägt, wenn ein erwarteter Lauf ausbleibt. Wie das geht, steht im Ratgeber zum Website-Monitoring.

WordPress: WP-Cron durch einen echten Cronjob ersetzen

WordPress hat einen eigenen Zeitplaner namens WP-Cron. Er läuft nicht von selbst, sondern bei jedem Seitenaufruf. Auf Seiten mit wenig Besuchern werden geplante Beiträge dann zu spät veröffentlicht. Auf Seiten mit viel Verkehr kostet die ständige Prüfung Rechenzeit. In beiden Fällen ist ein echter Cronjob die bessere Lösung.

Schalten Sie dazu in der wp-config.php den eingebauten Auslöser ab:

define( 'DISABLE_WP_CRON', true );

Danach den Cronjob einrichten, der alle fünf bis fünfzehn Minuten die Aufgaben startet. Mit WP-CLI geht das ohne Umweg über den Webserver:

*/10 * * * * cd /home/kunde/htdocs && /usr/local/bin/wp cron event run --due-now --quiet

Ohne WP-CLI rufen Sie stattdessen die Adresse https://ihre-domain.de/wp-cron.php über die Abruf-Funktion im Kundenmenü auf. Shops mit WooCommerce profitieren besonders, weil dort viele Hintergrundaufgaben wie E-Mails zu Bestellungen über diesen Zeitplaner laufen.

Cronjob einrichten: Sicherheit und Last im Blick

• Skripte außerhalb des Webordners: Ein Skript, das nur per Cron laufen soll, gehört nicht in den öffentlichen Ordner. Sonst kann es jeder Besucher aufrufen.
• Doppelte Läufe verhindern: Dauert ein Job länger als der Abstand zum nächsten, laufen zwei gleichzeitig. Auf Servern hilft flock: /usr/bin/flock -n /tmp/export.lock /usr/local/bin/export.sh startet nur, wenn der vorige Lauf fertig ist.
• Schwere Aufgaben in die Nacht: Backups und große Exporte belasten Festplatte und Datenbank. Legen Sie sie in ruhige Zeiten und nicht alle auf dieselbe Minute.
• Nicht häufiger als nötig: Ein Job, der jede Minute läuft, aber nur einmal am Tag etwas zu tun hat, verschwendet Rechenzeit. Auf geteilten Servern zählt das gegen Ihre Grenzen.