Cron Job Helper — Manual

Vollständige Funktionsbeschreibung des Cron Job Helpers: Cron-Syntax, der visuelle Builder, Presets, Klartext-Vorschau, Web-Cron-Generator, CMS-Rezepte und Docker/DDEV.

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

Dieses Manual beschreibt den Cron Job Helper vollständig: die Cron-Syntax, die das Tool versteht, jeden der fünf Reiter und die Befehle, die dabei entstehen. Die Oberfläche ist auf Englisch — die Tab- und Feld-Bezeichnungen werden hier in ihrer englischen Original-Schreibweise genannt (mit deutscher Erläuterung), damit du dich im Interface wiederfindest.

Die Cron-Syntax: fünf Felder

Ein klassischer Cron-Ausdruck besteht aus fünf durch Leerzeichen getrennten Feldern, gefolgt vom auszuführenden Befehl. Das Tool zeigt das im Reference-Tab als Diagramm:

┌─────────── minute (0–59)
│ ┌───────── hour (0–23)
│ │ ┌─────── day of month (1–31)
│ │ │ ┌───── month (1–12)
│ │ │ │ ┌─── day of week (0–6, Sun=0)
│ │ │ │ │
* * * * *  command to execute

Die erlaubten Werte und Sonderzeichen pro Feld:

Feld Werte Sonderzeichen
Minute 0–59 * , - /
Stunde (Hour) 0–23 * , - /
Tag des Monats (Day of Month) 1–31 * , - / ? L W
Monat (Month) 1–12 oder JAN–DEC * , - /
Wochentag (Day of Week) 0–6 oder SUN–SAT * , - / ? L #

Beim Wochentag ist Sonntag = 0. Manche Cron-Implementierungen erlauben zusätzlich 7 für Sonntag und die Drei-Buchstaben-Namen (SUN, MON, …); das Tool nimmt im Manual Input auch Namen wie sun entgegen.

Die Sonderzeichen

Das Tool unterscheidet die Standard-Vixie-Cron-Zeichen von den erweiterten Quartz-Zeichen (?, L, W, #), die im Reference-Tab ausdrücklich als Quartz markiert sind — sie funktionieren in Java-/Quartz-Schedulern, aber nicht im normalen Unix-cron:

Zeichen Bedeutung Beispiel
* jeder Wert * * * * * → jede Minute
, Werteliste 0,15,30,45 → zur Minute :00 :15 :30 :45
- Bereich 1-5 (Wochentag) → Mo–Fr
/ Schritt/Intervall */5 → alle 5 Einheiten
? kein bestimmter Wert (Quartz) 0 12 ? * MON
L letzter (Quartz) L im Tag-des-Monats → letzter Tag
W nächster Werktag (Quartz) 15W → Werktag nächstens am 15.
# n-ter Wochentag (Quartz) 5#3 → 3. Freitag

Spezialstrings

Statt fünf Felder akzeptiert Cron auch @-Kürzel. Das Tool kennt sie im Manual Input und löst sie auf:

String Entspricht Bedeutung
@reboot einmal beim Systemstart
@yearly / @annually 0 0 1 1 * einmal jährlich, 1. Januar
@monthly 0 0 1 * * einmal monatlich, am 1. um Mitternacht
@weekly 0 0 * * 0 einmal wöchentlich, Sonntag Mitternacht
@daily / @midnight 0 0 * * * einmal täglich um Mitternacht
@hourly 0 * * * * einmal pro Stunde

@reboot hat keinen kalkulierbaren Zeitplan — die Next Scheduled Runs zeigen dafür entsprechend keine Vorschau, sondern den Hinweis, dass der Job nur beim Systemstart läuft.

Reiter 1 — Builder

Der Builder ist das Herzstück. Oben steht die Cron Expression: der aktuelle Ausdruck (Standard * * * * *), darunter die Feldbeschriftung und eine Klartext-Beschreibung, was der Ausdruck tut. Ein Copy-Button kopiert den Ausdruck in die Zwischenablage.

Die Feld-Karten

Darunter liegt für jedes der fünf Felder eine Karte (Minute, Hour, Day of Month, Month, Day of Week) mit einem Auswahlmenü für den Modus:

  • Every <Feld> — jeder Wert (*).
  • Every N <Feld>s (*/N) — Schritt: ein Zahlenfeld erscheint, daraus wird */N.
  • Specific value — ein fester Einzelwert; ein Zahlenfeld im erlaubten Bereich des Feldes.
  • Range (A–B) — ein Bereich; zwei Felder From/to erzeugen A-B.
  • List (A,B,C) — eine kommagetrennte Liste, z. B. 0,15,30,45.

Jede Änderung aktualisiert sofort den Ausdruck oben, die Klartext-Beschreibung und die Liste der nächsten Läufe.

Manual Input

Wer den Ausdruck lieber direkt eintippt, nutzt das Feld Manual Input. Es akzeptiert fünf leerzeichengetrennte Felder (z. B. */5 * * * *) oder einen Spezialstring (@daily). Ist die Eingabe ungültig (weniger als fünf Felder), erscheint eine rote Fehlermeldung. Eine gültige Eingabe synchronisiert die Feld-Karten zurück, sodass Builder und Texteingabe immer denselben Stand zeigen.

Quick Presets

Rechts liegen 16 Quick Presets als Buttons, die einen Ausdruck per Klick setzen:

Every minute (* * * * *), Every 5 min (*/5 * * * *), Every 15 min (*/15 * * * *), Every 30 min (*/30 * * * *), Every hour (0 * * * *), Every 2 hours (0 */2 * * *), Every 6 hours (0 */6 * * *), Every 12 hours (0 */12 * * *), Daily midnight (0 0 * * *), Daily 3 AM (0 3 * * *), Weekly (Sun) (0 0 * * 0), Weekly (Mon) (0 0 * * 1), Monthly 1st (0 0 1 * *), Yearly Jan 1st (0 0 1 1 *), Weekdays 9 AM (0 9 * * 1-5) und Weekends (0 0 * * 6,0).

Next Scheduled Runs

Ebenfalls rechts berechnet das Tool die nächsten Ausführungszeitpunkte (bis zu acht) aus dem aktuellen Ausdruck — mit Datum, Uhrzeit und einer relativen Angabe (in 5 min, in 2h, in 3d …). Die Berechnung schaut bis zu einem Jahr in die Zukunft; findet sie in diesem Fenster keinen Treffer, meldet sie das. Diese Vorschau ist eine clientseitige Schätzung auf Basis der Browser-Uhrzeit (lokale Zeitzone), kein Server-Lauf — siehe dazu die Tipps zur Zeitzonen-Frage.

Reiter 2 — Web Cron

Der Web Cron-Tab erzeugt einen Cron-Job, der per HTTP eine URL aufruft, statt ein lokales Skript zu starten — praktisch für Shared Hosting oder CMS-Aufgaben. Du konfigurierst links, rechts entstehen live zwei Ausgaben: die Generated Crontab Line (komplette Zeile mit Zeitplan) und Command only (nur der Befehl).

Die Konfigurationsfelder:

  • Toolcurl (recommended) oder wget.
  • URL to call — die aufzurufende Adresse.
  • Cron schedule — der Zeitplan (Standard */15 * * * *); baue ihn im Builder und füge ihn hier ein.
  • Timeout (sec) — Standard 30, Bereich 5–300. Wird zu --max-time (curl) bzw. --timeout= (wget).
  • HTTP MethodGET oder POST (POST-X POST).
  • Log file path (optional) — hängt >> "datei" 2>&1 an.
  • User-Agent (optional) — -A (curl) bzw. --user-agent= (wget).
  • HTTP Auth User / Pass (optional) — -u "user:pass" (curl) bzw. --user/--password (wget).
  • Silent mode (Standard aktiv) — unterdrückt die Ausgabe (-s bei curl, -q bei wget). Ist Silent aus, hängt curl zusätzlich -w "%{http_code}" an, um den HTTP-Status auszugeben.
  • Skip SSL verification-k (curl) bzw. --no-check-certificate (wget); nur für Testzwecke.

Eine typische erzeugte curl-Zeile sieht so aus:

*/15 * * * *  curl -s --max-time 30 -o /dev/null "https://example.com/cron/run" > /dev/null 2>&1

Der Tab enthält außerdem einen Block Web Cron Tips mit sechs Hinweisen — u. a.: bei curl auf Shared Hosting immer -s benutzen (sonst mailt Cron bei jedem Lauf die volle Antwort), Ausgabe in eine Logdatei umleiten, die URL mit Token/IP-Restriktion/Basic-Auth schützen, einen Timeout setzen, den HTTP-Status prüfen und stets HTTPS verwenden.

Reiter 3 — CMS & Frameworks

Hier liefert das Tool fertige Crontab-Rezepte für fünf Systeme, jeweils mit Copy-Button. Der Tenor überall: Den eingebauten oder pseudo-zeitgesteuerten Scheduler durch einen echten System-Cron ersetzen oder anstoßen.

WordPress

WordPress nutzt WP-Cron, das bei Seitenaufrufen feuert — auf traffic-schwachen Seiten unzuverlässig. Empfehlung: WP-Cron in wp-config.php per define( 'DISABLE_WP_CRON', true ); abschalten und durch einen echten Cron ersetzen, bevorzugt via WP-CLI (wp cron event run --due-now …), alternativ via curl auf wp-cron.php.

TYPO3

TYPO3 nutzt die Scheduler-Extension, die ein echter Cron anstoßen muss. Empfohlen ist der TYPO3-CLI-Weg (vendor/bin/typo3 scheduler:run, ab v10), für ältere Versionen die eID-Methode via curl. Das Tool weist darauf hin, dass die eID-Methode veraltet und in v12 entfernt ist.

Drupal

Drupal nutzt Cron-Hooks (hook_cron()), angestoßen via Drush (vendor/bin/drush cron) oder per curl mit dem Cron-Key (aus Administration → Configuration → System → Cron). Das Tool empfiehlt, das eingebaute Automated Cron-Modul für volle Kontrolle zu deaktivieren.

Laravel

Laravels Task Scheduler braucht nur eine einzige Crontab-Zeile (php artisan schedule:run, jede Minute) — alle Aufgaben werden im Code (app/Console/Kernel.php bzw. ab v9 in routes/console.php) definiert. Der Tab zeigt Beispiel-Task-Definitionen und den Vordergrund-Modus schedule:work.

Symfony

Symfony nutzt Console Commands, je Befehl eine eigene Crontab-Zeile (bin/console …). Ab Symfony 6.3 gibt es die Scheduler-Komponente, angetrieben über einen Worker (messenger:consume scheduler_default). Hinweis des Tools: aus Cron immer --no-ansi und --no-interaction setzen.

General Best Practices

Ein eigener Block sammelt sieben allgemeine Regeln: absolute Pfade verwenden (Cron hat ein minimales $PATH, also /usr/bin/php statt php); in /etc/crontab bzw. /etc/cron.d/ den Benutzer angeben; die Ausgabe umleiten (>> /var/log/cron.log 2>&1 oder /dev/null); gegen Überlappung locken (flock); den Befehl vorab manuell als Cron-Benutzer testen; cron.d gegenüber crontab bevorzugen (datei-basiert, versionierbar); und die Zeitzone beachten (CRON_TZ=Europe/Berlin am Anfang der Crontab).

Reiter 4 — Docker / DDEV

Dieser Tab sammelt Muster für Cron in Containern.

Docker & Podman

Drei Wege plus Podman:

  • Option 1 — Cron im Container: im Dockerfile einen Cron-Daemon installieren (z. B. dcron auf Alpine), die crontab-Datei einkopieren und crond im Entrypoint starten. Tipp: Ausgabe nach /proc/1/fd/1 schreiben, damit sie im Docker-stdout-Log erscheint.
  • Option 2 — dedizierter Cron-Container: in Docker Compose einen separaten Service mit demselben Image/Volume und command: ["crond", "-f", "-l", "2"].
  • Option 3 — docker exec vom Host: der Host-Crontab ruft docker exec -t my_app … in den laufenden Container.
  • Podman (rootless): analog per podman exec; zusätzlich loginctl enable-linger $USER, damit User-Dienste und Cron einen Logout überleben.

DDEV

Drei DDEV-Varianten plus CMS-Beispiele:

  • Option 1 — Host-Cron + ddev exec: funktioniert nur, wenn das Projekt läuft (ddev start) — das Tool empfiehlt eine ddev describe | grep running-Prüfung.
  • Option 2 — eigener DDEV-Service (empfohlen): .ddev/docker-compose.cron.yaml mit einem Schleifen-Container (while true; … sleep 60).
  • Option 3 — DDEV-Hook (post-start): ein post-start-Hook in .ddev/config.yaml; einfach, aber der Prozess endet beim Container-Neustart.
  • Dazu fertige Zeilen für WordPress in DDEV (ddev wp cron event run --due-now) und TYPO3 in DDEV (ddev typo3 scheduler:run).

Ein Block Container Cron Tips ergänzt: Cron im Container nach Möglichkeit vermeiden (lieber dedizierter Container), nach stdout loggen, die Zeitzone setzen (TZ=Europe/Berlin, sonst UTC), Health-Checks nutzen und lokal (DDEV) wie in Produktion denselben Scheduler-Weg verwenden.

Reiter 5 — Reference

Ein reines Nachschlagewerk, jederzeit ohne Eingabe nutzbar: das oben gezeigte Syntax-Diagramm, die Feld- und Sonderzeichen-Tabellen, die Spezialstring-Tabelle, eine Tabelle Common Examples (häufige Ausdrücke), Useful Commands (crontab -e, crontab -l, crontab -r, crontab -u www-data -e, ls /etc/cron.d/, systemctl status cron, grep CRON /var/log/syslog, run-parts /etc/cron.hourly) und der MAILTO-Abschnitt.

MAILTO — E-Mail-Benachrichtigungen

Standardmäßig mailt Cron jede Ausgabe (stdout/stderr) eines Jobs an den lokalen Systembenutzer. Die Variable MAILTO am Anfang der Crontab steuert das:

Einstellung Wirkung
MAILTO="" schaltet alle Cron-Mails global ab
MAILTO="admin@example.com" sendet die Ausgabe an eine Adresse
MAILTO="root" sendet an den lokalen root (Standard)

Das Tool grenzt beide Mechanismen ab: MAILTO="" unterdrückt Mails global für die ganze Crontab, > /dev/null 2>&1 unterdrückt die Ausgabe pro Befehl 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.


Für die Zielgruppen und das große Bild siehe die Übersicht. Konkrete Ausdrücke stehen in den Beispielen, die typischen Fallen in den Tipps & Tricks. Ausprobieren kannst du alles direkt im Tool.