Cron Job Helper — Beispiele

Cron-Ausdrücke mit Erklärung: täglich, alle 15 Minuten, werktags, @reboot, Crontab-Zeile prüfen, Sommerzeit — plus Web-Cron-, CMS- und DDEV-Beispiel.

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

Das Manual erklärt jeden Reiter im Detail. Diese Seite zeigt konkrete Ausdrücke — was sie bedeuten, wie du sie im Builder zusammenklickst und worauf du beim Lesen der Next Scheduled Runs achtest. Die Oberfläche ist auf Englisch; Feld- und Button-Namen stehen deshalb im Original.

Beispiel 1: Täglich um 3 Uhr nachts

Der Klassiker für Backups und Wartung — laufen lassen, wenn wenig los ist.

0 3 * * *

So baust du ihn: Im Builder setzt du Minute auf Specific value 0, Hour auf Specific value 3, die übrigen drei Felder bleiben auf Every. Schneller geht es über den Preset Daily 3 AM. Die Klartext-Zeile bestätigt „At 03:00“, und die Next Scheduled Runs zeigen den jeweils nächsten 03:00-Termin — in der Zeitzone, die du unter Time zone of the server eingestellt hast. Lies: Minute 0, Stunde 3, jeden Tag, jeden Monat, jeden Wochentag.

Beispiel 2: Alle 15 Minuten

Typisch für Queue-Worker, Web-Cron-Aufrufe oder Scheduler-Anstöße.

*/15 * * * *

Im Builder stellst du Minute auf Every N Minutes (/N)* und trägst 15 ein — oder klickst den Preset Every 15 min. Das */15 heißt „alle 15 Einheiten“, die Minuten 0, 15, 30 und 45 jeder Stunde; der Klartext lautet „Every 15 minutes“. Achtung beim Schrittwert: */15 rechnet vom Feld-Minimum (0) aus, nicht ab „jetzt“. Weil 15 die Stunde glatt teilt, bleibt der Abstand auch über die volle Stunde gleich — bei */7 wäre das nicht so (siehe Beispiel 7).

Beispiel 3: Werktags zur vollen Stunde während der Bürozeit

Nur Montag bis Freitag, nur 9–17 Uhr — z. B. für Aufgaben, die an Mitarbeitende oder Kundinnen gekoppelt sind.

0 9-17 * * 1-5

Hier kombinierst du zwei Modi: Hour auf Range (A–B) mit 9–17 und Day of Week auf Range (A–B) mit 1–5 (Montag = 1, Freitag = 5). Minute steht auf 0. Ergebnis: zur vollen Stunde, von 9 bis 17 Uhr, an Werktagen — im Klartext „At minute 0, during hours 9–17, on Mon–Fri“. Statt 1-5 kannst du im Modus List / custom auch mon-fri schreiben; das Tool versteht die Namen. Wer nur einmal werktags will (etwa 08:30), nimmt 30 8 * * 1-5.

Beispiel 4: Monatlich am 1. um 4 Uhr

Monatsabschlüsse, Reports, Log-Rotation.

0 4 1 * *

Minute 0, Hour 4, Day of Month Specific value 1, Monat und Wochentag bleiben *. Das läuft am ersten Tag jedes Monats um 04:00 („At 04:00, on day 1 of the month“). Würdest du zusätzlich den Wochentag einschränken, etwa auf 1, liefe der Job am 1. und an jedem Montag — das Tool zeigt das im Klartext als „OR … (either one matches)“. Verwandt: der Preset Monthly 1st (0 0 1 * *) für Mitternacht, oder @monthly als Spezialstring im Manual Input.

Beispiel 5: Einmal beim Systemstart — @reboot

Manche Jobs sollen nicht zu einer Uhrzeit, sondern einmalig beim Hochfahren starten — etwa einen Worker oder ein Aufräum-Skript anstoßen.

@reboot

Tippe @reboot in das Manual Input-Feld. Das Tool erkennt den Spezialstring, beschreibt ihn als „Once, when the cron daemon starts (system boot)“ und zeigt in den Next Scheduled Runs keine Termine, sondern den Hinweis, dass der Job nur beim Start des Cron-Daemons läuft — denn @reboot hat keinen wiederkehrenden Zeitplan, der sich in die Zukunft rechnen ließe. Anders als die übrigen @-Strings lässt sich @reboot deshalb auch nicht in fünf Felder auflösen; der Copy-Button kopiert es unverändert als @reboot.

Beispiel 6: Wochenende um Mitternacht

Samstag und Sonntag, jeweils 00:00 — über eine Liste im Wochentag-Feld.

0 0 * * 6,0

Day of Week auf List / custom mit 6,0 (Samstag = 6, Sonntag = 0), Minute und Stunde auf 0. Der Preset Weekends setzt genau das; der Klartext lautet „At 00:00, on Sat, Sun“. Sonntag darfst du auch als 7 notieren — 6,7 oder sat,sun ergeben im Tool dieselben Läufe. Der Preset nutzt die 0-Schreibweise.

Beispiel 7: Eine ganze Crontab-Zeile prüfen

Du hast eine Zeile aus einer bestehenden Crontab geerbt und willst wissen, wann sie wirklich läuft:

*/7 * * * *  /usr/bin/php /var/www/html/bin/cleanup.php

Füge die komplette Zeile in das Manual Input-Feld ein. Das Tool trennt Zeitplan und Befehl: Die Cron Expression-Karte zeigt die fünf Felder, darunter „Command: /usr/bin/php /var/www/html/bin/cleanup.php“. Der Klartext lautet „At minutes 0, 7, 14, 21, 28, 35, 42, 49, 56 of every hour“, und eine gelbe Warnung erklärt die Falle: Nach Minute 56 kommt wieder Minute 0, die Lücke über die Stundengrenze beträgt 4 statt 7 Minuten. Brauchst du wirklich gleichmäßige Abstände, nimm einen Schritt, der 60 teilt (*/5, */6, */10).

Der Befehl bleibt erhalten, wenn du den Zeitplan danach in den Feld-Karten änderst, und der Copy-Button kopiert die vollständige Zeile.

Beispiel 8: Sommerzeit — 02:30 Uhr in Berlin

Ein Backup soll täglich um 02:30 Uhr laufen, der Server läuft in Europe/Berlin:

30 2 * * *

Wähle unter Time zone of the server die Zeitzone Europe/Berlin (das Tool merkt sich die Wahl). Liegt die Zeitumstellung im März innerhalb der acht angezeigten Läufe, steht am Umstellungssonntag ein Eintrag um 03:00 CEST mit dem Hinweis „DST: 02:30 does not exist — cronie runs it right after the jump“: Die Uhr springt von 02:00 auf 03:00, und cronie holt einen Job mit fester Uhrzeit direkt nach dem Sprung nach. In der Nacht der Rückstellung im Oktober gibt es 02:30 zweimal — der Job läuft trotzdem nur einmal („fixed-time job runs once“).

Anders bei einem Wildcard-Job wie */30 2 * * *: Er folgt der Wanduhr, fällt in der Frühjahrsnacht aus und läuft in der Herbstnacht viermal statt zweimal. Wer solche Effekte vermeiden will, legt Jobs außerhalb von 02:00–03:00 oder lässt den Server in UTC laufen.

Web-Cron-Beispiel: geschützter Endpunkt mit ~/.netrc

Ein Endpunkt hinter HTTP-Basic-Auth soll alle 15 Minuten aufgerufen werden, das Passwort soll aber weder in der Crontab noch in der Prozessliste stehen. Im Web Cron-Tab trägst du die URL ein (https://example.com/cron/run?token=abc%20def), dazu als HTTP Auth User cronuser. Das Feld HTTP Auth Pass lässt du leer, denn das Passwort kommt gleich direkt in die .netrc. Dann setzt du den Haken bei Read credentials from ~/.netrc instead of the command line. Die Generated Crontab Line lautet dann:

*/15 * * * *  curl --fail -sS --max-time 30 --netrc -o /dev/null 'https://example.com/cron/run?token=abc\%20def' > /dev/null 2>&1

Drei Details: Statt -u 'user:pass' steht nur --netrc in der Zeile; das % aus der URL ist als \% maskiert, weil ein nacktes % in der Crontab den Befehl beenden würde (unter Command only steht die unmaskierte Fassung zum Testen in der Shell); und unter der Zeile zeigt das Tool die passende .netrc-Zeile für den Host — mit deinem Benutzer und, weil das Passwort-Feld leer ist, dem Platzhalter YOUR_PASSWORD (mit eingetragenem Passwort stünde dort das echte Passwort):

machine example.com login cronuser password YOUR_PASSWORD

Den Platzhalter ersetzt du durch das echte Passwort, legst die Zeile im Home-Verzeichnis des Cron-Benutzers ab und schützt die Datei mit chmod 600 ~/.netrc. Mit wget als Tool entfallen die Auth-Optionen ganz, weil wget die .netrc von selbst liest.

CMS-Beispiel: WordPress über einen echten Cron statt WP-Cron

WordPress' eingebautes WP-Cron feuert nur bei Seitenaufrufen und ist auf traffic-schwachen Seiten unzuverlässig. Der CMS & Frameworks-Tab zeigt den robusten Weg.

Schritt 1 — WP-Cron in wp-config.php abschalten:

define( 'DISABLE_WP_CRON', true );

Schritt 2 — alle 5 Minuten einen echten Cron via WP-CLI in die Crontab des Webserver-Benutzers eintragen (crontab -u www-data -e):

*/5 * * * *  wp cron event run --due-now --path=/var/www/html --quiet

In dieser persönlichen Crontab gibt es keine Benutzerspalte — der Job läuft automatisch als www-data. Legst du die Zeile stattdessen als Datei unter /etc/cron.d/ ab, gehört der Benutzer zwischen Zeitplan und Befehl (*/5 * * * * www-data wp cron …). Der WP-CLI-Weg ist schneller als ein curl-Aufruf, weil er keinen HTTP-Request braucht. Falls du doch curl willst, liefert der Tab die Alternative auf wp-cron.php.

Docker-Beispiel: Cron in einem DDEV-Projekt

Im Docker / DDEV-Tab steht der einfachste DDEV-Weg: ein Host-Cron, der per ddev exec in den laufenden Container ruft.

*/5 * * * *  cd /home/user/myproject && ddev exec php artisan schedule:run >> /dev/null 2>&1

Wichtig: ddev exec funktioniert nur, wenn das Projekt läuft (ddev start) — sonst schlägt die Zeile fehl. Für einen dauerhaften Lauf unabhängig vom Host-Cron zeigt der Tab als empfohlene Variante einen eigenen DDEV-Service in .ddev/docker-compose.cron.yaml mit einer while true; … sleep 60-Schleife. Für WordPress in DDEV gibt es die fertige Zeile ddev wp cron event run --due-now.


Mehr Kontext: die Übersicht zum großen Bild, das Manual für jeden Reiter und die Tipps & Tricks für die Stolperfallen. Ausprobieren kannst du alles direkt im Tool.