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

Der Ausdruck */15 * * * *

*/15 * * * * löst viermal pro Stunde aus (um :00, :15, :30 und :45), insgesamt 96 Ausführungen pro Tag. Die Schrittsyntax */15 teilt den Minutenfeldbereich (0 bis 59) in 15er Schritte beginnend bei 0, was genau vier Slots pro Stunde ergibt, die mit den Viertelstunden der Uhr übereinstimmen.

Diese Ausrichtung ist kein Zufall. Viertelstundengrenzen bilden direkt ab, wie Menschen Zeit lesen und wie viele SLA Fenster definiert sind. Ein “15 Minuten Check” ist sowohl maschineneffizient als auch für Menschen lesbar.

Warum 15 Minuten ein Goldlöckchen Intervall ist

An den Extremen sind die Kompromisse offensichtlich: * * * * * läuft für die meisten Jobs zu oft, 0 * * * * hinterlässt eine Lücke von einer Stunde. Die interessante Frage ist, wo dazwischen der richtige Standard liegt.

*/5 (12/Stunde, 288/Tag) ist hervorragend für alles mit strengem SLA oder kritischem Pfad, aber 3x teurer als */15 in Bezug auf Ausführungen. */10 (6/Stunde) ist ein vernünftiger Mittelpunkt. */15 gewinnt als Standard, weil:

• 96 Läufe/Tag sind in den meisten Ressourcenbudgets unsichtbar. Datenbankverbindungen, API Aufrufe, Logzeilen. 96 pro Tag verursachen selten Rauschen.
• Das 15 Minuten Erkennungsfenster ist für die meisten nicht kritischen Hintergrundarbeiten akzeptabel. Wenn ein Sync fehlschlägt, wiederholt er sich innerhalb von 15 Minuten. Wenn eine Metrik veraltet, aktualisiert sie sich innerhalb von 15 Minuten.
• Die Viertelstundenausrichtung erleichtert die Log Inspektion. Beim Debuggen ist das Filtern von Logs auf das letzte 15 Minuten Fenster intuitiv.

Praktische Anwendungsfälle

Kubernetes CronJobs für interne Aufgaben

Die K8s CronJob Dokumentation verwendet */15 als Standard Beispielintervall. Für periodische Bereinigungsaufgaben, Cache Invalidierung oder interne Health Reporting, das keine Unter-5-Minuten Aktualität benötigt, ist */15 ein zuverlässiger Standard.

CI Pipeline geplante Prüfungen

Nächtliche Builds sind üblich, aber einige Teams führen auch einen leichten “Smoke Test” CronJob auf dem Deploy aus, der alle 15 Minuten ausgelöst wird. Er erkennt Regressionen schneller als ein nächtlicher Build, ohne die Kosten einer vollständigen Suite pro Commit.

SLA Compliance Prüfungen

Wenn dein SLA Fenster in Stunden gemessen wird, gibt dir ein 15 Minuten Intervall vier Datenpunkte pro Stunde, genug, um eine Verletzung zu erkennen und zu alarmieren, bevor das Fenster schließt, ohne übermäßiges Alarmrauschen zu erzeugen.

Daten Pipeline Polling

Für ETL Pipelines, die aus einem Quellsystem lesen und in ein Warehouse schreiben, ist 15 Minuten oft die richtige Kadenz, wenn die Quelle nach einem ähnlichen Zeitplan aktualisiert wird. Überprüfe die Aktualisierungshäufigkeit der Quelle, bevor du dein Intervall wählst.

Kombinieren mit Stunden und Tageseinschränkungen

Die Stärke von */15 ist, wie sauber es sich mit anderen Feldeinschränkungen kombinieren lässt:

*/15 9-17 * * 1-5       # alle 15 Min, 9 bis 17 Uhr, nur Werktage
*/15 * * * 1-5           # alle 15 Min, 24h, nur Werktage
0,15,30,45 8,12,16 * * * # dreimal täglich, zur Viertelstunde
*/15 0-6 * * *           # alle 15 Min, nur nachts (Nebenzeiten)

Das letzte Beispiel ist nützlich für Batch Jobs, die häufig laufen sollen, aber nur bei geringer Systemlast: nächtliche Verarbeitungsfenster, Datenmigrationen außerhalb der Spitzenzeiten oder Jobs, die mit dem Tagesverkehr konkurrieren würden.

Vergleichstabelle

“Max Erkennungsverzögerung” ist die schlechteste Zeit zwischen dem Auftreten eines Fehlers und dem nächsten Cron Lauf, der ihn erkennen würde. Für eine 15 Minuten SLA Anforderung ist */15 das Mindestintervall. Du benötigst */5 oder besser, um Spielraum zu haben.

Ausführungszeiten überprüfen

Um die nächsten 8 Ausführungszeiten für */15 * * * * anzuzeigen (zwei volle Stunden):

from croniter import croniter
from datetime import datetime

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

Auf einem System mit aktiver crontab bestätige, dass der Job zu den erwarteten Zeiten läuft:

journalctl -u cron --since "1 hour ago" | grep myjob

Du solltest genau 4 Einträge pro Stunde sehen. Wenn du weniger siehst, schlägt der Job möglicherweise still fehl. Überprüfe den Exit Code deines Skripts und stelle sicher, dass cron ein gültiges MAILTO gesetzt hat, damit Fehler gemeldet werden.