Cron Expression Builder

Cron Ausdruck für alle 5 Minuten: */5 * * * *

Der Cron Ausdruck */5 * * * * führt einen Job alle 5 Minuten aus (12 Mal pro Stunde). Deckt den Schritt Operator, Geschäftszeiten Varianten und systemd Timer Alternativen ab.

100% clientseitig. Deine Daten verlassen niemals deinen Browser.

Minute
Stunde
Tag des Monats
Monat
Wochentag

Every 5 minutes

Nächste 5 Ausführungen
  • 1.Mon, Jun 15, 2026, 12:55
  • 2.Mon, Jun 15, 2026, 13:00
  • 3.Mon, Jun 15, 2026, 13:05
  • 4.Mon, Jun 15, 2026, 13:10
  • 5.Mon, Jun 15, 2026, 13:15
Kurzreferenz
*Beliebiger Wert
,Listentrennzeichen
-Bereich
/Schritt
1-5Bereich 1 bis 5
*/15Alle 15 Einheiten

Verwandte Werkzeuge

Der Ausdruck */5 * * * *

Der Cron Ausdruck */5 * * * * plant einen Job so ein, dass er alle 5 Minuten, jede Stunde, jeden Tag ausgeführt wird. Die fünf Felder sind: Minute, Stunde, Tag des Monats, Monat, Wochentag. Ein * in einem Feld bedeutet “jeder gültige Wert.” Das */5 im Minutenfeld verwendet den Schritt Operator, um jeden 5. Wert auszuwählen.

Der Schritt Operator

Das Zeichen / im Cron wird Schritt Operator genannt. Die Syntax */N bedeutet “alle N Einheiten über den gesamten Bereich.” Für das Minutenfeld:

Du kannst einen Schritt auch auf einen eingeschränkten Bereich anwenden. 10-30/5 expandiert zu 10,15,20,25,30 und löst alle 5 Minuten aus, aber nur innerhalb des Fensters von 10 bis 30. Dies wird seltener benötigt, ist aber in allen großen Cron Implementierungen gültig.

Wozu dies expandiert

*/5 * * * *

Ist exakt äquivalent zu:

0,5,10,15,20,25,30,35,40,45,50,55 * * * *

Beide Formen lösen 12 Mal pro Stunde aus, 288 Mal pro Tag. Wenn du eine der beiden in crontab -e auf einem Linux System einfügst, erhältst du dasselbe Verhalten. Die Schrittform wird in der Praxis bevorzugt, da sie lesbarer und weniger fehleranfällig zu tippen ist.

Wann ein 5-Minuten Zeitplan sinnvoll ist

Health Checks und Uptime Monitoring

Das Anpingen eines Endpunkts alle 5 Minuten erfasst Fehler innerhalb eines 5 Minuten Fensters. Kürzere Intervalle (1 bis 2 Minuten) sind besser für kritische Dienste, aber 5 Minuten ist ein vernünftiger Standard für nicht kritische interne Tools.

Cache Warming und Refresh

Wenn deine Anwendung Daten zwischenspeichert, die nach 10 bis 30 Minuten ablaufen, verhindert ein 5 Minuten Cron, der den Cache vorab lädt und befüllt, dass Cache Fehler nachgelagerte Dienste treffen.

Externes API Polling

Wenn ein Webhook nicht verfügbar ist und du Daten aus einer externen Quelle abrufen musst, ist 5 Minuten oft das kürzeste Intervall, das innerhalb der Rate Limits bleibt. Überprüfe immer die Rate Limit Dokumentation der API, bevor du das Intervall festlegst.

Log Rotation oder Metrik Aggregation

Einige leichte Aggregationsaufgaben (Zähler zusammenfassen, gepufferte Daten leeren) laufen in kurzen Intervallen, bei denen ein 5 Minuten Fenster eine natürliche Bucket Größe darstellt.

Nicht geeignet für: alles, was Subminuten Genauigkeit benötigt. Die Cron Auflösung beträgt 1 Minute. Für Subminuten Jobs verwende einen langlebigen Prozess mit einer internen Sleep Schleife, einen systemd Timer mit OnCalendar=*:0/1 oder einen Job Scheduler wie Celery Beat.

Alternativen und Vergleich

AusdruckLäufe pro StundeTypische Verwendung
*/1 * * * *60Nahezu Echtzeit Polling
*/5 * * * *12Health Checks, Cache Refresh
*/10 * * * *6Mäßiges Polling
*/15 * * * *4Viertelstunden Berichte
*/30 * * * *2Halbstündliche Zusammenfassungen
0 * * * *1Stündliche Jobs

Wenn du zwischen */5 und */10 wählst, frage dich, ob das Erkennen eines Problems 5 Minuten früher den doppelten Aufwand rechtfertigt. Für die meisten Hintergrundjobs ist */10 oder */15 ausreichend und reduziert unnötige Last.

Cron vs systemd Timer

Auf modernen Linux Systemen mit systemd kannst du OnCalendar in einer .timer Unit anstelle von Cron verwenden:

[Timer]
OnCalendar=*:0/5
Persistent=true

OnCalendar=*:0/5 löst in jeder 5. Minute jeder Stunde aus. Die Option Persistent=true führt den Job erneut aus, wenn das System ausgeschaltet war, als er ausgelöst werden sollte. Standard Cron macht dies standardmäßig nicht.

Systemd Timer protokollieren die Ausgabe auch im Journal, was journalctl -u yourjob.timer nützlicher macht als die Suche durch /var/log/syslog. Für neue Systeme sind Timer eine Überlegung wert. Für bestehende crontab lastige Infrastruktur ist die Schrittsyntax kampferprobt und weit verbreitet.

Deinen Zeitplan überprüfen

Um zu prüfen, wann */5 * * * * als nächstes ausgelöst wird, verwende ein Cron Parse Tool oder führe dies in Python aus:

from croniter import croniter
from datetime import datetime

cron = croniter("*/5 * * * *", datetime.now())
for _ in range(5):
    print(cron.get_next(datetime))

Oder in der Befehlszeile mit aktivem crontab Eintrag überprüfe /var/log/syslog oder journalctl, nachdem der Job ausgeführt wurde, um zu bestätigen, dass er zu den erwarteten Zeiten ausgeführt wurde.