Was ein Prüfer fragt und Ihr SLA-Report nicht beantwortet

Ein Prüfer streitet selten über Ihren Uptime-Prozentsatz. Er fragt, woher die Zahl stammt. Die meisten SLA-Reports beantworten die erste Frage und nicht die zweite.

Die Zahl oben auf einem SLA-Report ist eine Behauptung: 99,95 Prozent, dieses Quartal, belegt. Ein Prüfer, der Einkauf eines Kunden oder eine Aufsicht, die Pflichten aus DORA oder NIS2 abarbeitet, zweifelt die Zahl selbst meist nicht an. Gefragt wird etwas Schwierigeres: Woher wissen Sie das?

Diese Frage ist keine Pedanterie. DORA gilt seit dem 17. Januar 2025, mit Meldefristen von vier Stunden, 72 Stunden und einem Monat für schwerwiegende Incidents. NIS2 zieht weit über hunderttausend Unternehmen in der EU in Meldepflichten, geschätzt 30.000 bis 40.000 allein in Deutschland, und nur etwa 39 Prozent davon hatten sich bis zur Frist im März 2026 registriert (Zahlen zur deutschen Umsetzung, BSI, 2026). Wer 2026 nach Nachweisen zu Ihrer Verfügbarkeit fragt, arbeitet an diesen Rahmenwerken entlang und ist darauf trainiert, eine Behauptung zu prüfen statt sie zu übernehmen. Drei Lücken tauchen dabei immer wieder auf. So finden Sie sie im eigenen Report, bevor es jemand anderes tut.

Die Frage hinter der Zahl

Verfügbarkeit ehrlich zu messen ist unbequem, weil das gemessene System oft dasselbe ist, das misst, und weil der Report häufig im Nachhinein aus Erinnerung, Slack-Threads und CSV-Exporten zusammengesetzt wird. Ein Prüfer arbeitet sich deshalb vom Prozentwert rückwärts: Welche Fenster zählten als Ausfallzeit, welche wurden ausgeschlossen und warum, und wer hat die Zeitstempel festgehalten. Ein Report, der diese drei Fragen nicht sauber beantwortet, gilt nicht als falsch. Er gilt als unzuverlässig, und das ist schlimmer, denn ab da steht jede andere Zahl auf der Seite in Zweifel.

Lücke eins: gerundete Fenster

Viele Reports räumen Ausfälle zu runden Zahlen auf. Aus einem Fenster wird “etwa 15 Minuten”, oder alles unter 10 Minuten fällt als Rauschen weg. Das liest sich sauber und lässt sich nicht rekonstruieren, und genau das ist das Problem. Aus einem geglätteten Fenster kann ein Prüfer den Prozentwert nicht nachrechnen.

Was auf dem Spiel steht, ist reine Arithmetik. Ein Ziel von 99,95 Prozent lässt über ein Quartal mit 91 Tagen rund 65 Minuten Budget für Ausfallzeit, verteilt auf 131.040 Minuten. Ein einziges falsch gerundetes Fenster kann eine echte Überschreitung verdecken oder eine erfinden. Wird ein Incident von 7 Minuten und 12 Sekunden als “ungefähr 15 Minuten” erfasst, haben Sie Ihre eigene Ausfallzeit ohne Not um fast acht Minuten zu hoch angesetzt. Runden Sie ihn stattdessen auf null ab, haben Sie still einen Nachweis gelöscht, den eine Aufsicht später mit einer Kundenbeschwerde abgleichen kann.

So schließen Sie sie. Halten Sie die echten Grenzen sekundengenau fest und lassen Sie den Prozentwert daraus folgen. Das Fenster ist das Fenster. Auf 15 Minuten gerundet sieht es nicht hübscher aus, und haltbar ist es dann nicht mehr.

Lücke zwei: stille Ausschlüsse

Jede ernsthafte SLA-Berechnung schließt etwas aus: angekündigte Wartung, Fenster höherer Gewalt, eine Abhängigkeit außerhalb Ihrer Kontrolle. Ausschlüsse sind legitim. Stille Ausschlüsse sind es nicht.

Das Anzeichen, auf das ein Prüfer achtet, ist ein Ausschluss, der sich keiner Ankündigung vor dem Beginn des Fensters zuordnen lässt. Ein Wartungsfenster, das ohne Beleg des Ankündigungszeitpunkts aus der Rechnung genommen wurde, ist von einer nachträglichen Korrektur nicht zu unterscheiden, und sobald ein einzelner Ausschluss nachträglich wirkt, wirken alle so. So wird aus einer guten Uptime-Zahl ein Glaubwürdigkeitsproblem.

So schließen Sie sie. Jeder Ausschluss trägt seinen eigenen Ankündigungszeitstempel sowie seinen echten Beginn und sein echtes Ende. Ausgeschlossene Zeit steht im Report, als ausgeschlossen gekennzeichnet, und wird nicht daraus entfernt. Wer den Report liest, soll das Wartungsfenster sehen, den Zeitpunkt der Ankündigung sehen und nachvollziehen, dass die Herausnahme vorher entschieden wurde und nicht, nachdem das Ergebnis feststand.

Lücke drei: selbst gemessene Werte

Die dritte Lücke erwarten Teams am wenigsten, denn hier geht es nicht ums Rechnen. Es geht um den Blickwinkel. Stammen Ihre Verfügbarkeitsdaten von einem einzigen Prüfpunkt oder, schlimmer, aus derselben Infrastruktur, die ausgefallen ist, hat ein Prüfer einen berechtigten Einwand: Sie können ein eigenes Netzproblem nicht von einem echten Dienstausfall unterscheiden, und wer den Verlauf im Nachhinein zusammenstellt, kann nicht belegen, dass die Zeitstempel nicht passend gemacht wurden.

So schließen Sie sie. Messen Sie von außerhalb des überwachten Systems und lassen Sie unabhängige Standorte bestätigen, bevor ein Incident gezählt wird. Wenn Prüfpunkte auf mehr als einem Kontinent übereinstimmen, dass ein Dienst nicht erreichbar ist, hat die Frage “lag es an uns oder an denen” eine Antwort, die nicht von gutem Willen abhängt. Lassen Sie das Monitoring-System jedes Ereignis in dem Moment stempeln, in dem es passiert, statt den Ablauf später zu rekonstruieren. Für einen Prüfer zählt nicht, wie ausgefeilt das ist. Es zählt, dass die Aufzeichnung von einer Maschine zur Zeit des Ereignisses geschrieben wurde und nicht von einem Menschen im Nachhinein. Auch deshalb gehört die Messmethodik, nicht nur das Ergebnis, in ein Dokument, das Sie weitergeben können.

Wie ein Report aussieht, der standhält

Drei Eigenschaften, und glanzvoll ist keine davon: echte Fenstergrenzen, sichtbare und vorab angekündigte Ausschlüsse, und eine Messung von außerhalb des Systems, über mehrere Regionen bestätigt. Nichts davon macht Ihre Uptime höher. Es macht sie nachprüfbar, und nur diese Fassung nimmt ein Prüfer ab. Eine schmeichelhafte Zahl, die Sie nicht verteidigen können, ist weniger wert als eine ehrliche, die Sie verteidigen können.

Ein Beleg, kein Screenshot

Das lässt sich leichter zeigen als beschreiben, deshalb veröffentlichen wir einen vollständigen Report. Der SLA-Beispielreport hält ein einzelnes Quartal für einen Demo-Dienst fest, und jede Zahl darin geht auf.

Lesen Sie eine Zeile davon genau. In Frankfurt schlägt um 02:40:42 ein Check fehl. Der Incident öffnet dort nicht. Dreißig Sekunden später stimmen Prüfpunkte in New Jersey und Singapur darin überein, dass der Dienst nicht erreichbar ist, das Quorum bestätigt, und um 02:41:12 öffnet der Incident. Diese Bestätigung ist der Beginn des gezählten Fensters, 02:41:12 bis 02:48:24, nicht der erste fehlgeschlagene Check und keine gerundete Minute. Das 90-minütige Wartungsfenster später im selben Monat ist ausgeschlossen, bleibt aber mit dem Zeitstempel seiner Ankündigung im Report stehen, damit ein Prüfer sieht, dass es geplant und nicht hinterher wegerklärt wurde. Die Brutto-Verfügbarkeit beträgt 99,925 Prozent, nach dem einen kuratierten Ausschluss sind es 99,994 Prozent. Geben Sie den Report einem Kunden, einem Prüfer oder einer Aufsicht, und jeder Schritt lässt sich nachrechnen.

Zum Umfang, damit es klar ist: Kein Monitoring-Produkt erfüllt DORA oder NIS2 an Ihrer Stelle. Einstufung, Meldung und die Fristen bleiben Ihre Verantwortung. Was ein Werkzeug leisten kann, ist der Nachweis zur Verfügbarkeit, nach dem diese Rahmenwerke immer wieder fragen, in einer Form, die einen zweiten Leser übersteht.

Wenn Ihr aktueller Report die drei Fragen oben nicht beantwortet, ist das jetzt eine nützliche Erkenntnis, solange der einzige Preis eine etwas weniger schmeichelhafte Zahl ist. Sie können kostenlos mit dem Monitoring beginnen oder sich zuerst durch das Produkt klicken . Kein Vertriebsgespräch, um zu sehen, wie die Aufzeichnung geführt wird.