Cron Job Helper — Tipps & Tricks

Zurück zur Übersicht: Cron Job Helper · Tool live öffnen: www.jpkc.com/tools/cron/

Das Manual erklärt jeden Reiter, die Beispiele zeigen konkrete Ausdrücke. Hier geht es um das, was beim Cron-Schreiben gern schiefgeht — die Fallen, die man erst beim dritten verpassten Lauf bemerkt.

Die berüchtigte OR-Logik bei Tag-des-Monats und Wochentag

Die wichtigste Cron-Falle überhaupt: Wenn du sowohl das Feld Day of Month als auch das Feld Day of Week einschränkst (also keines auf * steht), verknüpft der klassische Unix-Cron sie mit ODER, nicht mit UND. Der Job läuft dann an jedem Tag, der eine der beiden Bedingungen erfüllt.

Beispiel:

0 0 13 * 5

Das läuft nicht „nur an einem Freitag, den 13.", sondern an jedem 13. des Monats UND zusätzlich an jedem Freitag. Willst du „Freitag, der 13.", geht das mit Standard-Cron nicht in einer Zeile.

Praktische Konsequenz: Schränke immer nur eines der beiden Tag-Felder ein und lass das andere auf *. Die Klartext-Vorschau des Builders formuliert solche Fälle als „on day-of-month X and weekday Y" — verlass dich bei der Bedeutung trotzdem auf die OR-Regel des echten Cron, denn so verhält sich der Daemon auf dem Server.

Cron läuft in der Server-Zeitzone — nicht deiner

Cron nutzt die Zeitzone des Servers (oft UTC), nicht deine lokale. Ein 0 3 * * * ist „3 Uhr Serverzeit". Zwei Dinge folgen daraus:

Auf dem System kannst du die Zeitzone der Crontab mit CRON_TZ=Europe/Berlin am Anfang der Datei festlegen (so empfiehlt es auch der General Best Practices-Block des Tools). In Containern setzt du stattdessen TZ=Europe/Berlin als Umgebungsvariable — sonst läuft der Container in UTC.
Die Next Scheduled Runs im Builder rechnen in der Zeitzone deines Browsers. Diese Vorschau ist eine bequeme Schätzung, aber nicht zwingend identisch mit dem, was der Server tut. Plane in Serverzeit, wenn es auf die Stunde ankommt.

Output unterdrücken: MAILTO vs. /dev/null

Standardmäßig schickt Cron jede Ausgabe (stdout und stderr) eines Jobs per Mail an den lokalen Systembenutzer. Ein gesprächiges Skript flutet so das Postfach. Es gibt zwei Hebel, die der Reference-Tab klar trennt:

MAILTO="" am Anfang der Crontab schaltet die Mails global für die ganze Datei ab.
> /dev/null 2>&1 hinter dem Befehl unterdrückt die Ausgabe pro Job — und verhindert zusätzlich, dass ein Prozess an einer vollen Mail-Queue hängenbleibt.

Für Web-Cron-Jobs ist die Kombination beider am robustesten. Wichtig dabei: > /dev/null 2>&1 leitet auch stderr (2>) um — > /dev/null allein würde Fehlermeldungen weiterhin mailen.

Absolute Pfade verwenden

Cron startet mit einer minimalen Umgebung: $PATH ist meist nur /usr/bin:/bin, dein interaktives Profil (.bashrc, nvm, rbenv …) wird nicht geladen. Ein Befehl, der in deiner Shell läuft, kann im Cron stumm scheitern, weil das Binary nicht gefunden wird. Deshalb: absolute Pfade zu Interpreter und Skript (/usr/bin/php /var/www/html/artisan …) statt bloß php …. Wenn ein Skript bestimmte Umgebungsvariablen braucht, setze sie explizit am Anfang der Crontab.

Den Benutzer angeben (bei system-weiten Crontabs)

In /etc/crontab und Dateien unter /etc/cron.d/ steht vor dem Befehl der Benutzername — z. B. www-data. Das ist ein häufiger Stolperstein: In der persönlichen Crontab (crontab -e) gibt es dieses Feld nicht (der Job läuft als der jeweilige Benutzer), in den system-weiten Dateien ist es Pflicht. Die CMS-Rezepte des Tools zeigen die system-weite Form mit www-data.

Überlappende Läufe verhindern (flock)

Wenn ein Job länger braucht als sein Intervall (z. B. ein */5-Import, der manchmal 7 Minuten dauert), startet Cron den nächsten Lauf trotzdem — zwei Instanzen rennen parallel und können sich gegenseitig in die Quere kommen. Sperre dagegen mit flock:

*/5 * * * *  flock -n /tmp/mycron.lock php /var/www/html/artisan schedule:run >> /dev/null 2>&1

flock -n startet den Job nur, wenn die Lock-Datei frei ist, und überspringt ihn sonst. Das Tool nennt diesen Kniff im General Best Practices-Block.

Web-Cron vs. System-Cron — wann was

Der Web Cron-Tab erzeugt Jobs, die per curl/wget eine URL aufrufen — der Zeitplan läuft also weiterhin im System-Cron, nur der Befehl ist ein HTTP-Request. Wann lohnt sich das?

Web-Cron ist die richtige Wahl auf Shared Hosting, wo du keinen Shell-Zugriff oder keine Kontrolle über CLI-Tools hast, und für CMS-Endpunkte, die ohnehin per HTTP angestoßen werden (wp-cron.php, Drupals /cron/KEY).
System-Cron mit CLI (WP-CLI, Drush, artisan, console) ist schneller, robuster und umgeht den Webserver-Timeout. Wo du Shell-Zugriff hast, ist er die bessere Wahl — der CMS & Frameworks-Tab empfiehlt durchweg den CLI-Weg.

Schützt du einen Web-Cron-Endpunkt, denk an die Web Cron Tips aus dem Tool: immer -s (silent) bei curl, Ausgabe in eine Logdatei, die URL mit Token/IP-Restriktion/Basic-Auth absichern, einen Timeout setzen und ausschließlich HTTPS verwenden, damit Zugangsdaten nicht im Klartext gehen.

Quartz-Zeichen funktionieren nicht im Unix-Cron

Die Reference-Tabelle listet ?, L, W und # und markiert sie ausdrücklich als Quartz. Diese Zeichen gehören zum Java-Quartz-Scheduler (und einigen Cron-Derivaten), nicht zum normalen Unix-cron. Ein 0 0 L * * („letzter Tag des Monats") oder 5#3 („3. Freitag") wird von vixie-/cronie-Cron nicht verstanden. Nutze sie nur, wenn dein Ziel-Scheduler Quartz-Syntax spricht; für eine klassische crontab bleib bei * , - /.

Container: nach stdout loggen

In Docker/Podman solltest du Cron-Ausgabe nach /proc/1/fd/1 (bzw. stdout) schreiben, damit sie in docker logs auftaucht — sonst verschwindet sie im Nichts. Und denk an die Zeitzone: ohne TZ läuft der Container in UTC. Beides steht in den Container Cron Tips des Tools.

Mit anderen JPKCom-Tools kombinieren

Docker-Tools — wenn du die Container-Muster aus dem Docker / DDEV-Tab in ein echtes Setup gießt.
Zeit- & Timestamp-Tools — um die Server-Zeitzone und Unix-Timestamps zu klären, bevor du dich auf eine Uhrzeit festlegst.

Mehr Kontext: die Übersicht zum großen Bild, das Manual für jeden Reiter und die Beispiele für konkrete Ausdrücke. Ausprobieren kannst du alles direkt im Tool.