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

Der Ausdruck */10 * * * *

*/10 * * * * führt einen Job sechsmal pro Stunde aus, in den Minuten 0, 10, 20, 30, 40 und 50, und wiederholt sich jede Stunde, jeden Tag. Über 24 Stunden sind das 144 Ausführungen. Es liegt in der Mitte des üblichen Schrittintervalls: häufiger als */15 oder */30, weniger anspruchsvoll als */5.

Die Syntax */10 verwendet den Schritt Operator. Im Minutenfeld deckt * den Bereich 0 bis 59 ab, und /10 wählt jeden 10. Wert ab 0 aus. Das Ergebnis ist immer dieselben sechs Minutenmarken, unabhängig davon, wann der Daemon startet.

Vergleich mit benachbarten Intervallen

Der Sprung von */5 auf */10 halbiert die Anzahl der Läufe. Für Jobs, bei denen eine Latenz von 5 Minuten akzeptabel ist, 15 Minuten aber zu langsam sind, ist 10 Minuten ein praktischer Mittelweg, der den Ressourcenverbrauch halbiert.

Wann 10 Minuten die richtige Wahl sind

Externes API Polling ohne Webhooks

Viele APIs bieten keine Push Benachrichtigungen. Wenn du Änderungen innerhalb eines 10 Minuten Fensters erkennen musst und die API ein Rate Limit hat, das ein 5 Minuten Polling belasten würde, ist */10 eine gute Wahl. Du erhältst 144 API Aufrufe pro Tag statt 288.

Batch Verarbeitung mit mäßigem Durchsatz

Wenn du eine Warteschlange von Elementen verarbeitest und eine Verzögerung von 10 Minuten akzeptabel ist, vermeidet */10 den Overhead häufigerer Zeitplanung, während die Warteschlange unter Kontrolle bleibt. Überwache die Warteschlangentiefe im Laufe der Zeit. Wenn sie stetig wächst, ist das Intervall zu lang.

Interne Monitoring Prüfungen

Infrastrukturprüfungen (Speicherplatz, Prozesszahlen, Warteschlangentiefenwarnungen), die eine Benachrichtigung auslösen, wenn ein Schwellenwert überschritten wird, müssen nicht alle 5 Minuten laufen. Ein 10 Minuten Fenster erkennt die meisten Verschlechterungstrends früh genug, um zu handeln, ohne die Monitoring Infrastruktur zu überlasten.

Datensynchronisation von sich langsam ändernden Quellen

Wenn sich die zu synchronisierenden Daten höchstens alle paar Minuten ändern, bedeutet ein 10 Minuten Sync Intervall, dass du nie mehr als einen Zyklus zurückliegst. Für Referenzdaten oder Konfigurationssynchronisation ist dies normalerweise mehr als ausreichend.

Die Startminute versetzen

Der Standard */10 löst immer um :00, :10, :20, :30, :40, :50 aus. Wenn auf einem Server mehrere Jobs laufen und alle */10 verwenden, starten sie alle gleichzeitig zu diesen Minutenmarken. Dies kann zu Lastspitzen führen.

Um sie zu verteilen, verwende die Start/Schritt Syntax:

*/10 * * * *    /opt/jobs/job-a     # löst um :00, :10, :20 aus...
2/10 * * * *    /opt/jobs/job-b     # löst um :02, :12, :22 aus...
5/10 * * * *    /opt/jobs/job-c     # löst um :05, :15, :25 aus...

Jeder Job hat jetzt seinen eigenen 2 Minuten Offset. Die Last wird gleichmäßig über jedes 10 Minuten Fenster verteilt, anstatt gleichzeitig einzuschlagen.

Die Expansion überprüfen

Um zu bestätigen, wozu */10 * * * * expandiert, verwende Python:

from croniter import croniter
from datetime import datetime

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

Dies gibt die nächsten 6 Ausführungszeiten aus. Alle 6 fallen innerhalb der nächsten 60 Minuten, genau 10 Minuten auseinander.

Du kannst den aktiven Zeitplan auch auf einem laufenden System überprüfen:

# Prüfe, welche Minutenmarken aktiv sind
echo "*/10 * * * *" | awk '{print $1}' | tr ',' '\n'
# Oder verwende einen Cron Parser wie systemd-analyze
systemd-analyze calendar "*/10:0" 2>/dev/null || true

Wann aufrüsten oder herabstufen

Wenn der Job durchgängig in unter 30 Sekunden abgeschlossen ist und die Ausgabe selten benötigt wird, erwäge */15. Du verlierst 48 Läufe pro Tag, gewinnst aber Spielraum.

Wenn eine 10 Minuten Lücke zu sichtbarer Veralterung in einem Dashboard oder einer benutzerorientierten Funktion führt, reduziere auf */5. Frage aber zuerst, ob ein push basierter Ansatz (Webhooks, Server-Sent Events, WebSocket) das Polling vollständig überflüssig machen würde.