Uptime-Check-Intervall wählen: 1, 3 oder 5 Minuten?

Was das Prüfintervall tatsächlich aussagt

Das Intervall ist der Abstand zwischen zwei Prüfungen. Es ist nicht die Zeit bis zum Alarm — und genau diese Verwechslung steckt hinter den meisten Bauchentscheidungen. Ein Ausfall richtet sich nicht nach Ihrem Prüfplan. Er beginnt irgendwann zwischen zwei Prüfungen, und in erster Näherung ohne Vorliebe für einen bestimmten Zeitpunkt.

Daraus folgt eine einfache Rechnung. Nehmen wir an, der Ausfallbeginn liegt gleichverteilt zwischen zwei Prüfungen. Im günstigsten Fall fällt der Dienst unmittelbar vor der nächsten Prüfung aus — die Verzögerung geht gegen null. Im ungünstigsten Fall fällt er unmittelbar nach einer erfolgreichen Prüfung aus, und es vergeht ein volles Intervall n, bis die nächste Prüfung überhaupt hinsieht. Über viele Vorfälle gemittelt landet man bei n/2, im schlechtesten Fall bei n. Bei fünf Minuten sind das 2,5 Minuten im Mittel und 5 Minuten im schlechtesten Fall; bei einer Minute 30 Sekunden und 60 Sekunden.

Wichtig ist, was dieser Wert beschreibt: den Zeitpunkt der ersten fehlgeschlagenen Prüfung, nicht den Alarm. Zwischen beiden liegt in jedem ernsthaften Setup noch die Bestätigung — und die kostet weitere Intervalle. Wer „fünf Minuten" einstellt und „nach spätestens fünf Minuten alarmiert" versteht, hat den größeren Teil der Rechnung noch vor sich.

Die Rechnung: Intervall plus Bestätigungsrunden

Kaum ein Monitoring alarmiert beim ersten Fehlschlag — zu Recht. Ein verworfenes Paket, ein TCP-Reset oder eine kurz überlastete Firewall genügen für ein einzelnes down, ohne dass ein Nutzer je etwas gemerkt hätte. Deshalb verlangen Monitoring-Systeme mehrere aufeinanderfolgende Fehlschläge, bevor sie melden. Warum das Rauschen ohne diesen Filter unerträglich wird, führt der Beitrag zum Zähmen von Flapping-Alerts im Detail aus.

Diese Bestätigung ist nicht gratis, sie wird in Zeit bezahlt. Nennen wir n das Intervall und c die Zahl der verlangten aufeinanderfolgenden Fehlschläge. Die erste fehlgeschlagene Prüfung kommt im Mittel nach n/2, jede weitere Bestätigung kostet ein volles Intervall. Daraus werden zwei kompakte Formeln:

• Erkennung im Mittel = n/2 + (c − 1) × n — der Wert, den Sie über viele Vorfälle hinweg erwarten dürfen.
• Erkennung im schlechtesten Fall = c × n — der Wert, mit dem Sie in Ihrem SLO rechnen sollten.
• Plus Timeout: Ein hängender Server gilt erst nach Ablauf des Timeouts als ausgefallen. Dieser Wert addiert sich auf jede Runde und fehlt in den meisten Bauchrechnungen.

Setzt man übliche Kombinationen ein, ergibt sich ein Bild, das viele überrascht. Der Anteil bezieht sich auf das Fehlerbudget von rund 43 Minuten, das ein SLO von 99,9 Prozent über 30 Tage lässt (Google SRE Workbook, Kapitel 5) — die Herleitung folgt im nächsten Abschnitt.

Die Zeile, an der die meisten Diskussionen kippen, ist die vorletzte. Ein Fünf-Minuten-Intervall mit zwei Bestätigungen — eine vollkommen gängige Standardeinstellung — erkennt im Mittel nach 7,5 Minuten und im schlechtesten Fall nach 10 Minuten. Das ist das Doppelte dessen, was die Zahl „5" suggeriert, und es ist erst der Anfang der Wiederherstellungszeit: Benachrichtigung, Zurkenntnisnahme, Diagnose und Behebung kommen obendrauf.

Der blinde Fleck: Ausfälle, die zwischen die Prüfungen passen

Bis hier ging es um die Frage, wie spät ein Ausfall erkannt wird. Die unangenehmere Frage lautet, ob er überhaupt erkannt wird. Stichprobenartiges Messen hat eine strukturelle Eigenschaft: Ereignisse, die kürzer als der Messabstand sind, können vollständig durch das Raster fallen. Das SRE Book beschreibt denselben Effekt für Metriken — eine Beobachtung der CPU-Last über eine Minute zeige nicht einmal recht langlebige Spitzen, die hohe Tail-Latenzen verursachen (Google SRE Book, Kapitel 6). Auch Kapitel 4 warnt, dass eine über ein Fenster gemittelte Messung eine momentane Last verbergen kann, die doppelt so hoch ist wie der Durchschnitt (Google SRE Book, Kapitel 4).

Für Uptime-Checks lässt sich das exakt beziffern. Ein Ausfall der Dauer d, der zufällig im Prüfraster liegt, wird von einer Prüfung mit Intervall n mit der Wahrscheinlichkeit d/n getroffen, solange d kleiner als n ist. Ist d größer oder gleich n, liegt mindestens eine Prüfung im Ausfallfenster — er wird also erfasst.

Nun kommt die Bestätigung hinzu — und verschärft den blinden Fleck erheblich. Damit c aufeinanderfolgende Prüfungen im Abstand n allesamt fehlschlagen, muss der Ausfall mindestens die Spanne zwischen der ersten und der letzten dieser Prüfungen überdecken. Daraus folgt eine harte Untergrenze: Meldbar ist ein Ausfall erst, wenn er länger dauert als (c − 1) × n.

• 1 Minute, 2 Bestätigungen: Ausfälle unter 1 Minute lösen keinen Alarm aus.
• 1 Minute, 3 Bestätigungen: Untergrenze 2 Minuten.
• 3 Minuten, 2 Bestätigungen: Untergrenze 3 Minuten.
• 5 Minuten, 2 Bestätigungen: Ein Ausfall von 4 Minuten kann grundsätzlich nicht gemeldet werden — er passt zwischen zwei Prüfungen hindurch.
• 5 Minuten, 3 Bestätigungen: Untergrenze 10 Minuten. Alles darunter bleibt für die Alarmierung unsichtbar.

Gegenprobe am Fehlerbudget

Bis hier sind das Rechenübungen. Zur Entscheidung werden sie erst, wenn man sie gegen das Fehlerbudget hält. Das Site Reliability Workbook formuliert den Zusammenhang unmissverständlich: Bei einem SLO von 99,9 Prozent über ein Fenster von 30 Tagen verbraucht eine konstante Fehlerrate von 0,1 Prozent exakt das gesamte Fehlerbudget — eine Burn-Rate von 1 (Google SRE Workbook, Kapitel 5). Dieselbe Referenztabelle rechnet den Extremfall vor: eine Burn-Rate von 1.000, also 100 Prozent Fehlerrate, erschöpft das Budget in 43 Minuten (Google SRE Workbook, Kapitel 5). Das ist der ganze Spielraum, den 99,9 Prozent im Monat lassen.

Vor diesem Hintergrund liest sich die Tabelle aus dem zweiten Abschnitt anders. Ein einziger Vorfall, der mit einem Fünf-Minuten-Intervall und zwei Bestätigungen im schlechtesten Fall erkannt wird, verbraucht allein für die Erkennung rund 23 Prozent des Monatsbudgets. Bei drei Bestätigungen sind es knapp 35 Prozent. Zwei solche Vorfälle im Monat, und das Budget ist aufgebraucht, bevor irgendjemand mit der Behebung begonnen hat.

Die Gegenprobe wird noch deutlicher, wenn man den Entwurfspunkt der Referenzalarme danebenlegt. Das Workbook empfiehlt für ein 99,9-Prozent-SLO einen Page-Alarm bei einer Burn-Rate von 14,4 über ein Ein-Stunden-Fenster, was einem Budgetverbrauch von 2 Prozent zum Alarmzeitpunkt entspricht; eine zweite Page-Stufe bei Burn-Rate 6 über 6 Stunden entspricht 5 Prozent, ein Ticket bei Burn-Rate 1 über 3 Tage 10 Prozent (Google SRE Workbook, Kapitel 5). Zwei Prozent von 43,2 Minuten sind rund 0,9 Minuten. Der Alarm ist also darauf ausgelegt, bei einem Totalausfall nach ungefähr einer Minute zu feuern.

Wenn die Alarmlogik auf einen Budgetverbrauch von zwei Prozent ausgelegt ist, die Erkennung aber allein dreiundzwanzig Prozent kostet, dann ist nicht die Alarmlogik das Problem. Dann ist das Intervall die Bremse, und jede Feinjustierung an den Schwellen darüber ist Kosmetik.

— Projekterfahrung

Daraus lässt sich eine brauchbare Faustregel ableiten: Die Erkennung eines einzelnen Vorfalls sollte höchstens rund zehn Prozent des Monatsbudgets kosten. Bei 99,9 Prozent sind das etwa 4,3 Minuten im schlechtesten Fall. Ein Minutenintervall mit zwei Bestätigungen (2 Minuten) hält diese Grenze bequem ein, mit drei Bestätigungen (3 Minuten) ebenfalls. Ein Drei-Minuten-Intervall mit zwei Bestätigungen (6 Minuten) reißt sie bereits, ein Fünf-Minuten-Intervall deutlich. Wer tiefer in die Budget-Logik einsteigen möchte, findet sie im Beitrag zu Error-Budget und Burn-Rate-Alerts ausführlich hergeleitet.

Was der Minutentakt kostet

Wenn kürzer besser erkennt — warum dann nicht alles auf den kürzestmöglichen Takt stellen? Weil das Intervall auf der anderen Seite der Waage ebenfalls bezahlt wird, und zwar in vier Währungen. Bemerkenswerterweise zieht das SRE Book die Grenze deutlich früher, als die meisten Bauchentscheidungen es tun: Häufiger als ein- bis zweimal pro Minute auf einen 200-Status zu prüfen, sei vermutlich unnötig häufig (Google SRE Book, Kapitel 6). Dasselbe Kapitel hält fest, dass die Prüfung der Festplattenfüllung für einen Dienst mit 99,9-Prozent-Ziel häufiger als alle ein bis zwei Minuten vermutlich überflüssig ist (Google SRE Book, Kapitel 6), und dass sekündliche Messungen der CPU-Last zwar interessante Daten liefern mögen, in Erhebung, Speicherung und Auswertung aber sehr teuer werden können (Google SRE Book, Kapitel 6). Ein Minutentakt ist nach dieser Lesart bereits am oberen Ende des Sinnvollen, nicht am unteren.

Die dritte Währung ist die teuerste. Das SRE Book beziffert sie unmissverständlich: Einen Menschen zu alarmieren sei eine recht teure Verwendung seiner Arbeitszeit (Google SRE Book, Kapitel 6). Ein Alarm, der fällt, ohne handlungsfähig zu sein, senkt den Wert aller künftigen Alarme. Das Intervall zu verkürzen, ohne die Bestätigung mitzudenken, kauft also Erkennungszeit gegen Glaubwürdigkeit — ein schlechter Tausch. Wie sich Schwellen und Kanäle sauber staffeln lassen, zeigt der Beitrag zum richtigen Konfigurieren von Monitoring-Alerts.

Bestätigung vom zweiten Standort statt kürzerem Intervall

Damit kommt der eigentliche Punkt dieses Artikels. Es gibt zwei grundsätzlich verschiedene Wege, einen Ausfall zu bestätigen — und sie haben völlig unterschiedliche Preisschilder.

1. Zeitliche Bestätigung: Man wartet auf weitere aufeinanderfolgende Fehlschläge desselben Prüfpunkts. Preis: (c − 1) × n Minuten zusätzliche Erkennungszeit. Gefiltert werden transiente Störungen am Ziel.
2. Räumliche Bestätigung: Mehrere Standorte prüfen im selben Takt, und ein Ausfall gilt erst als bestätigt, wenn mehrere von ihnen ihn sehen. Preis: nahezu keine zusätzliche Zeit, weil parallel geprüft wird. Gefiltert werden lokale Netz-, Routing- und Peering-Probleme des Prüfknotens.

Der Unterschied ist entscheidend, weil beide Verfahren dieselbe Kennzahl verbessern, aber nur eines davon dafür bezahlt. Das Workbook unterscheidet vier Attribute einer Alarmierungsstrategie: Precision — der Anteil der erkannten Ereignisse, die bedeutsam waren; Recall — der Anteil der bedeutsamen Ereignisse, die erkannt wurden; Detection time — wie lange es dauert, bis benachrichtigt wird; und Reset time — wie lange Alarme nach der Behebung weiterfeuern (Google SRE Workbook, Kapitel 5).

In dieser Sprache formuliert: Zeitliche Bestätigung erkauft Precision mit Detection time. Räumliche Bestätigung erkauft Precision mit Infrastruktur — die Detection time bleibt praktisch unberührt. Wer Fehlalarme senken will und dafür nur am Zähler c dreht, verschlechtert also zwangsläufig die Erkennungszeit. Wer stattdessen einen zweiten Standort hinzunimmt, bekommt die Precision, ohne die Zeit zu bezahlen.

Die letzte Zeile verdient Aufmerksamkeit. Ein einzelner Prüfknoten kann grundsätzlich nicht unterscheiden, ob der Dienst ausgefallen ist oder ob nur der Weg dorthin gestört war. Erst mehrere Perspektiven machen aus dieser Frage eine beantwortbare. Warum eine einzelne Messstelle dafür strukturell zu wenig ist, vertieft der Beitrag zu den Vorteilen von Multi-Location-Monitoring.

XICTRAQ setzt genau darauf: Die Erreichbarkeit wird aus drei verteilten EU-Rechenzentren in Nürnberg, Helsinki und Falkenstein geprüft, und ein Ausfall gilt erst mit dem Konsens von zwei der drei Knoten als bestätigt. Weil die drei Knoten parallel messen, kostet diese Bestätigung keine zusätzliche Runde. Die Intervalle reichen von 5 Minuten im Free-Plan über 1 Minute in Starter und Business bis zu 30 Sekunden im Agency-Plan.

Die nützlichste Reihenfolge im Betrieb lautet: erst Standort-Konsens, dann Bestätigungsrunden, dann Intervall. Wer sie umdreht und mit dem Intervall beginnt, kauft die teuerste Verbesserung zuerst und die billigste zuletzt.

— Projekterfahrung

Entscheidungsrahmen: Ausfallkosten und SLO statt Bauchgefühl

Damit lässt sich die Ausgangsfrage endlich sauber beantworten — nicht mit einer Zahl, sondern mit einer Rechnung. Der Nutzen einer Intervall-Verkürzung ist die eingesparte Erkennungszeit, bewertet mit dem, was eine Minute Ausfall kostet:

Ein Rechenbeispiel — ausdrücklich mit angenommenen Werten, nicht mit erhobenen: Ein Shop setzt in der Hauptzeit 40 Euro Deckungsbeitrag pro Minute um und hatte im letzten Jahr sechs meldepflichtige Vorfälle. Der Wechsel von 5 Minuten auf 1 Minute bei jeweils zwei Bestätigungen senkt die mittlere Erkennungszeit von 7,5 auf 1,5 Minuten, spart also 6 Minuten je Vorfall. Sechs Vorfälle × 6 Minuten × 40 Euro ergeben rund 1.440 Euro im Jahr. Gegen diesen Betrag ist der Aufpreis des Tarifs zu halten — und gegen ihn allein, nicht gegen ein Sicherheitsgefühl. Die vollständige Systematik dieser Rechnung führt der Beitrag zum Berechnen des Monitoring-ROI aus.

Die zweite Prüfung ist die Gegenprobe am SLO aus dem vierten Abschnitt: Die Erkennung im schlechtesten Fall sollte spürbar unter dem Monatsbudget bleiben. Beide Prüfungen zusammen führen zu einer Einordnung nach Dienstprofil statt nach Bauchgefühl.

Zwei Werte in dieser Tabelle sind bewusst qualitativ gehalten. Die Ausfallkosten pro Minute lassen sich nicht allgemeingültig beziffern — sie hängen von Geschäftsmodell, Tageszeit und Saison ab, und jede fremde Zahl an dieser Stelle wäre geraten. Beim SLO gilt derselbe Vorbehalt: Kapitel 4 des SRE Book empfiehlt, Ziele einfach zu halten und Absolutwerte zu vermeiden, und erinnert daran, dass Verfügbarkeiten von 99 und 99,999 Prozent als „zwei Neunen" und „fünf Neunen" bezeichnet werden — für die Google Compute Engine wird dort ein Ziel von 99,95 Prozent genannt (Google SRE Book, Kapitel 4). Ein Vergleich üblicher Zusagen findet sich im Beitrag zu Uptime-Garantien im Hosting-Vergleich; welche Intervalle in welchem Tarif enthalten sind, zeigt die Übersicht der Pläne.

Intervall, Bestätigung und Timeout zusammen einstellen

In der Praxis ist das Intervall einer von drei Reglern, die zusammengehören. Wer nur an einem dreht, erzeugt Nebenwirkungen an den anderen beiden. Die folgende Reihenfolge hat sich bewährt (Projekterfahrung):

• SLO zuerst festlegen. Das Monatsbudget in Minuten ausrechnen und daraus die maximal vertretbare Erkennungszeit ableiten — etwa zehn Prozent des Budgets je Vorfall.
• Standort-Konsens aktivieren, bevor am Intervall gedreht wird. Er senkt Fehlalarme, ohne Erkennungszeit zu kosten. Das ist die einzige Stelle im System mit dieser Eigenschaft.
• Bestätigungen bewusst wählen. Zwei aufeinanderfolgende Fehlschläge filtern die meisten Einzelaussetzer. Drei sind bei kurzen Intervallen vertretbar und bei fünf Minuten teuer.
• Timeout kleiner als das Intervall halten. Ein Timeout von 30 Sekunden bei einem 30-Sekunden-Intervall lässt Prüfungen ineinanderlaufen. Als Orientierung: Timeout höchstens ein Drittel des Intervalls.
• Timeout in die Erkennungszeit einrechnen. Ein hängender Server wird erst nach dessen Ablauf als ausgefallen gewertet — bei jeder Runde erneut.
• Prüfzeitpunkte versetzen. Läuft der Monitor exakt im Takt von Cronjobs oder Deployments, misst er systematisch die falschen Momente.
• Wartungsfenster definieren. Geplante Downtime soll das Fehlerbudget nicht belasten und keinen Page auslösen.
• Nach Kritikalität staffeln. Die Statusseite braucht nicht denselben Takt wie der Checkout. Das Intervall ist ein Regler pro Dienst, keine globale Einstellung.

Was danach kommt, entscheidet über den Rest der Wiederherstellungszeit. Die Erkennung ist nur der erste Summand: Benachrichtigung, Zurkenntnisnahme und Eskalation folgen, und schlecht gestaffelte Eskalation kann jede gewonnene Minute wieder auffressen. Der Beitrag zu Incident-Management und Eskalation behandelt diese Kette im Detail. Für die Kommunikation nach außen empfiehlt sich zusätzlich eine Statusseite mit belastbarer Historie, damit die gemessene Verfügbarkeit nachvollziehbar bleibt.

Diese Nachvollziehbarkeit ist zunehmend keine Kür mehr. Wer Verfügbarkeit gegenüber Auftraggebern belegen muss, braucht eine lückenlose, datierte Historie statt einer Behauptung — welche Nachweise in der Lieferkette erwartet werden, ordnet der Beitrag zu NIS2-Nachweisen für Dienstleister ein. Dieselbe Betriebsdisziplin, die hier bei Intervall und Bestätigung greift, gilt auch beim Umgang mit Schwachstellen: Auch dort entscheidet die Reaktionszeit, wie der Beitrag zu EUVD- und CVE-Feeds zeigt.

Zur Einordnung der gemessenen Werte hilft schließlich der Blick über den Uptime-Check hinaus. Das SRE Book fasst die Beobachtung eines Dienstes in vier goldenen Signalen zusammen: Latenz, Traffic, Fehler und Sättigung (Google SRE Book, Kapitel 6). Ein Uptime-Check deckt davon einen Ausschnitt ab. Steigende Latenz oder Sättigung kündigen einen Ausfall häufig an, bevor die Erreichbarkeitsprüfung überhaupt anschlägt — weshalb Antwortzeit-Trends und Timing-Wasserfall die eigentliche Frühwarnung liefern und das Intervall entlasten (Projekterfahrung).

Das Intervall bewusst wählen statt aufzurüsten

Die Frage nach 1, 3 oder 5 Minuten hat keine allgemeingültige Antwort — aber sie hat eine nachvollziehbare Herleitung. Das Intervall n liefert eine Erkennung von n/2 im Mittel und n im schlechtesten Fall, die Bestätigungsrunden addieren jeweils ein volles Intervall, der Timeout kommt obendrauf, und Ausfälle unterhalb von (c − 1) × n bleiben für die Alarmierung unsichtbar. Gegen diese Summe steht ein Fehlerbudget von rund 43 Minuten im Monat bei 99,9 Prozent (Google SRE Workbook, Kapitel 5). Wer beide Zahlen nebeneinanderlegt, braucht kein Bauchgefühl mehr.

Ebenso wichtig ist die Gegenrichtung: Der Minutentakt ist kein Selbstzweck. Das SRE Book zieht die Grenze des Sinnvollen bei ein- bis zweimal pro Minute (Google SRE Book, Kapitel 6), und jede zusätzliche Prüfung erzeugt Last, Rauschen und Gelegenheiten für Fehlalarme. Der wirksamere Hebel gegen Fehlalarme liegt ohnehin woanders — im Konsens mehrerer Standorte, der Precision verbessert, ohne Erkennungszeit zu kosten.

Praktisch heißt das: Legen Sie das SLO fest, rechnen Sie das Budget in Minuten um, wählen Sie das Intervall so, dass die Erkennung im schlechtesten Fall einen kleinen Teil davon beansprucht — und schalten Sie den Standort-Konsens ein, bevor Sie über kürzere Takte nachdenken. Wie sich das konkret anfühlt, lässt sich in der Live-Demo des Dashboards ohne Registrierung ansehen; welche Intervalle die Tarife abdecken, steht in der Preisübersicht.

Häufig gestellte Fragen zum Uptime-Check-Intervall