Cronjobs einrichten: Automatisierung auf dem Webserver

1. Was sind Cronjobs?

Ein Cronjob ist ein zeitgesteuerter Befehl, der vom Betriebssystem automatisch zu bestimmten Zeiten oder Intervallen ausgefuehrt wird. Der Name kommt von Cron – einem Unix-Daemon, der seit den 1970er-Jahren fuer die Zeitplanung von Aufgaben auf Unix/Linux-Systemen zustaendig ist. Crontab steht fuer "Cron Table" – die Konfigurationsdatei, in der Cronjobs definiert werden.

Cronjobs laufen im Hintergrund ohne Benutzerinteraktion – ideal fuer Aufgaben, die regelmaessig erledigt werden muessen: Backups erstellen, Logs rotieren, Caches leeren, E-Mails versenden, Datenbanken optimieren oder externe APIs abfragen.

2. Die Crontab-Syntax verstehen

Jede Zeile in der Crontab definiert einen Cronjob und folgt einem festen Format mit fuenf Zeitfeldern gefolgt vom auszufuehrenden Befehl:

* * * * * /pfad/zum/befehl

Die fuenf Felder stehen fuer:

Spezielle Zeichen in der Crontab:

Praxisbeispiele: Crontab-Ausdruecke

# Jede Minute ausfuehren
* * * * * /pfad/zum/skript.sh

# Taeglich um 2:30 Uhr
30 2 * * * /pfad/zum/backup.sh

# Jeden Montag um 8 Uhr
0 8 * * 1 /pfad/zum/wochenbericht.sh

# Alle 15 Minuten
*/15 * * * * /pfad/zum/check.sh

# Monatlich am 1., um 3 Uhr
0 3 1 * * /pfad/zum/monatsabschluss.sh

# Werktags (Mo-Fr) um 9 Uhr
0 9 * * 1-5 /pfad/zum/tagesstart.sh

3. Cronjobs einrichten: Crontab bearbeiten

Per SSH (Linux/VPS)

Die einfachste Methode bei SSH-Zugang: Die Crontab des aktuellen Benutzers bearbeiten:

crontab -e

Das oeffnet die Crontab im Standard-Editor (meist nano oder vi). Weitere nuetzliche Befehle:

# Aktuelle Crontab anzeigen
crontab -l

# Crontab loeschen (Vorsicht!)
crontab -r

# Crontab fuer anderen Benutzer anzeigen (als Root)
crontab -l -u www-data

Ueber das Hosting-Control-Panel

Viele Shared-Hosting-Anbieter bieten Cronjob-Verwaltung direkt im Kundencenter oder Plesk/cPanel. Dort kannst du Cronjobs per Formular anlegen ohne direkte Crontab-Bearbeitung. Die Felder sind dieselben: Minute, Stunde, Tag, Monat, Wochentag, Befehl. Einige Anbieter beschraenken die minimale Ausfuehrungsfrequenz (z.B. maximal stuendlich statt jede Minute) aus Performance-Gruenden.

4. Typische Anwendungsszenarien fuer Cronjobs

Automatische Datenbankbackups

# Taeglich um 3 Uhr: MySQL-Datenbank sichern
0 3 * * * /usr/bin/mysqldump -u dbuser -pdbpasswort dbname > /backup/db_$(date +\%Y\%m\%d).sql

Wichtig: Das Passwort direkt in der Crontab ist nicht ideal – besser eine ~/.my.cnf Datei mit den Zugangsdaten nutzen und chmod 600 setzen.

Cache leeren (z.B. bei WordPress)

# Taeglich um 4 Uhr: WP-CLI Cache leeren
0 4 * * * /usr/local/bin/wp --path=/var/www/html/wordpress cache flush

Log-Rotation und Bereinigung

# Woechentlich: Alte Logs aelter als 30 Tage loeschen
0 2 * * 0 /usr/bin/find /var/log/meinapp/ -name "*.log" -mtime +30 -delete

Laravel Scheduler (Cronjob fuer alle Laravel-Tasks)

# Laravel Scheduler: Jede Minute laufen lassen
* * * * * /usr/bin/php /var/www/html/artisan schedule:run >> /dev/null 2>&1

Bei Laravel genuegt ein Cronjob fuer alle geplanten Tasks – der Laravel Scheduler entscheidet intern, welche Tasks gerade ausfuehren sollen.

Website-Verfuegbarkeit pruefen

# Alle 5 Minuten: Website-Status pruefen, bei Fehler Mail senden
*/5 * * * * /usr/bin/curl -sf https://meinedomain.de > /dev/null || echo "Website down!" | mail -s "Alert" admin@meinedomain.de

5. Ausgaben und Logging von Cronjobs

Standardmaessig schickt Cron die Ausgabe eines Cronjobs per E-Mail an den Systembenutzer – oft unerwuenscht. Hier sind die Optionen:

Ausgaben umleiten

# Alle Ausgaben (stdout + stderr) in Log-Datei schreiben
0 3 * * * /pfad/zum/skript.sh >> /var/log/meinbackup.log 2>&1

# Alle Ausgaben verwerfen (kein Log, keine Mail)
0 3 * * * /pfad/zum/skript.sh > /dev/null 2>&1

# Nur Fehler loggen, normale Ausgaben verwerfen
0 3 * * * /pfad/zum/skript.sh > /dev/null 2>> /var/log/fehler.log

MAILTO deaktivieren

# Am Anfang der Crontab: Mail-Ausgabe fuer alle Jobs deaktivieren
MAILTO=""

6. Cronjobs debuggen: Wenn es nicht klappt

Cronjobs, die im Terminal funktionieren, aber als Cronjob fehlschlagen – ein klassisches Problem. Die haeufigsten Ursachen:

• Relativer Pfad: Cronjob nutzt relativen Pfad, der beim Cron-Start nicht existiert
• Fehlende Umgebungsvariablen: PATH, HOME oder andere Variablen fehlen
• Berechtigungsprobleme: Das Skript hat keine Ausfuehr-Berechtigung (chmod +x skript.sh)
• PHP-Version: System-PHP weicht von manuell gesetzter PHP-Version ab
• Sonderzeichen: % in Crontab muss als \% escapet werden

Cronjob manuell testen

# Skript mit der minimalen Cron-Umgebung testen
env -i HOME=/root PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /pfad/zum/skript.sh

Cron-Systemlog pruefen

# Ubuntu/Debian: Cron-Aktivitaeten im Syslog
grep CRON /var/log/syslog | tail -20

# CentOS/RHEL: Cron-Log direkt
tail -20 /var/log/cron

7. Cronjobs im Shared Hosting: Einschraenkungen und Alternativen

Shared-Hosting-Anbieter beschraenken Cronjobs oft aus Stabilitaets- und Performance-Gruenden:

Stand Mai 2026. Konditionen direkt beim Anbieter pruefen.

Alternative: URL-basierte Cronjobs

Einige Anbieter erlauben nur URL-Aufrufe statt Shell-Befehle. Dabei wird eine URL aufgerufen, die ein PHP-Skript ausloest:

*/30 * * * * curl -s https://meinedomain.de/cron/daily-task.php > /dev/null

Schuetze diese URLs durch einen geheimen Token, damit sie nicht von aussen missbraucht werden koennen: https://meinedomain.de/cron/daily-task.php?token=GEHEIMER_TOKEN

8. Fazit: Cronjobs als solides Fundament fuer Automatisierung

Cronjobs sind ein unverzichtbares Werkzeug fuer jeden, der Server oder Websites ernsthaft betreibt. Die Crontab-Syntax erscheint zuerst kryptisch, ist aber schnell gelernt – und mit Tools wie crontab.guru sind selbst komplexe Zeitausdruecke leicht zu formulieren.

Fuer volle Kontrolle ueber Cronjobs – insbesondere fuer kurze Intervalle, Root-Befehle und Systemd-Integration – ist ein VPS die richtige Wahl. Hetzner und netcup bieten zuverlaessige Linux-Server zu guenstigen Preisen mit uneingeschraenktem Cron-Zugang.