SLA-Streit mit dem Kunden: Wessen Messung am Ende zählt

Die Prozentzahl ist die unwichtigste Zahl im Vertrag

Eine Verfügbarkeitszusage besteht aus vier Angaben, und der Prozentwert ist die letzte davon. Davor stehen der Messpunkt, der Bezugszeitraum und die Festlegung, was überhaupt als Ausfall gilt. Fehlt eine dieser drei Angaben, steht im Vertrag zwar eine Zahl, aber kein Verfahren, mit dem sie sich nachrechnen lässt. Die IT-Recht Kanzlei setzt in ihrem Beitrag zum Servicelevelagreement genau hier an: "Die Parteien haben zunächst zu definieren, wann das IT-System als nicht verfügbar angesehen wird."

Das klingt selbstverständlich und ist es in der Praxis selten. In den meisten Angeboten steht der Prozentwert im Fettdruck und der Rest gar nicht. Wie sich Prozentwerte in Minuten und Stunden übersetzen, ist an anderer Stelle beschrieben: Prozentwerte in Minuten umrechnen zeigt die Tabelle dazu. Dieser Beitrag beginnt eine Ebene davor, bei der Frage, wessen Messung überhaupt die Grundlage der Rechnung ist.

• Messpunkt - von welchem Ort aus, über welchen Weg und mit welchem Verfahren abgefragt wird.
• Bezugszeitraum - Monat, Quartal oder Jahr; die IT-Recht Kanzlei nennt dazu: "Als Zeiteinheiten werden typischerweise Minuten, Stunden, Tage, Monate, Quartale oder Jahre verwendet."
• Ausfalldefinition - welcher Zustand als Nichtverfügbarkeit zählt und ab welcher Dauer.
• Prozentwert - die Zahl, die ohne die drei Angaben davor nichts trägt.

Wer diese Reihenfolge einhält, verhandelt am Ende schneller. Der Prozentwert ist Verhandlungssache, die drei Festlegungen davor sind Handwerk. Und sie kosten im Entwurf zusammen keine Seite Text.

Der Messpunkt: dieselbe Website, vier verschiedene Zahlen

Zwischen dem Dienst im Rechenzentrum und dem Browser des Kunden liegen mehrere Schichten, und jede davon kann für sich ausfallen: die Anwendung, die Lastverteilung, das Netz des Anbieters, die Namensauflösung, das Zertifikat, das vorgelagerte Auslieferungsnetz. Ein Messpunkt im eigenen Rechenzentrum sieht nur die erste Schicht. Ein Messpunkt außerhalb sieht das, was ein Besucher auch sieht.

Deshalb entsteht der typische SLA-Streit nicht aus einer falschen Zahl, sondern aus zwei richtigen. Der Anbieter misst intern und kommt auf 99,98 Prozent, der Kunde misst von außen und kommt auf 99,62 Prozent. Beide Werte stimmen in ihrem jeweiligen Bezugsrahmen, aber nur einer beschreibt, was der Endkunde erlebt hat. Warum eine einzelne Messstelle dafür nicht ausreicht, ist in warum ein einzelner Standort nicht genügt ausgeführt.

Die IT-Recht Kanzlei geht beim Berichtswesen einen Schritt weiter und benennt das Vertrauensproblem offen: "Berichte des Anbieters, die dieser selbst erstellt, beruhen auf Vertrauen." Ihr Vorschlag ist eindeutig: "Es ist daher sinnvoll, dass die Berichte nicht vom Anbieter, sondern von einem Dritten erstellt oder selbst aus dem System in einer Weise generiert werden, die nicht manipuliert werden kann." Genau diese Rolle füllt eine unabhängige Messstelle aus. Uptime-Monitoring von mehreren Standorten liefert eine Zahl, die keine der beiden Vertragsparteien allein erzeugt, und nimmt der Diskussion damit ihren Ausgangspunkt.

Was als Ausfall zählt, entscheidet über die halbe Zahl

Ein Server, der auf jede Anfrage mit Status 200 antwortet, gilt in vielen Verträgen als verfügbar. Das ist die schwächste aller denkbaren Definitionen. RFC 9110 beschreibt den Statuscode knapp: "The 200 (OK) status code indicates that the request has succeeded." Über den Inhalt der Antwort sagt er nichts. Eine Fehlerseite mit Status 200 erfüllt die Zusage formal und den Zweck nicht: Seiten, die trotz Fehler 200 melden beschreibt das Muster und seine Folgen.

Eine belastbare Ausfalldefinition steht deshalb auf drei Beinen: Statuscode, Inhaltsprüfung und Antwortzeit. Für den harten Fall ist RFC 9110 eindeutig: "The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method." Der weiche Fall ist der, den die IT-Recht Kanzlei so beschreibt: "Die Leistung kann verfügbar sein, jedoch in ihrer Qualität nicht den bestehenden oder vereinbarten Erwartungen des Kunden entsprechen." Auch dieser Zustand lässt sich messen, aber nur, wenn er vorher benannt wurde.

{
  "messpunkte": ["fra", "hel", "ash"],
  "intervall_sekunden": 60,
  "erfolg": {
    "status": [200, 204],
    "inhalt_enthaelt": "Warenkorb",
    "antwortzeit_ms_max": 4000
  },
  "ausfall_beginnt_bei": {
    "fehlversuche": 2,
    "standorte_gleichzeitig": 2
  },
  "bezugszeitraum": "kalendermonat",
  "wartungsfenster": [
    { "tag": "So", "von": "02:00", "bis": "04:00", "zone": "Europe/Berlin", "max_std_monat": 4 }
  ]
}

Ein solcher Block ist keine Vertragsanlage, aber er zeigt, wie wenig Text nötig ist, damit eine Zusage nachrechenbar wird. Ob zusätzlich der vollständige Seitenaufbau in einem echten Browser gemessen wird oder nur die Antwort des Servers, ist eine bewusste Entscheidung: Browser-Monitoring misst das eine, API-Monitoring das andere. Wichtig ist, dass der Vertrag sagt, welches von beiden gemeint ist.

Das Prüfintervall gehört in dieselbe Festlegung. Wer alle fünf Minuten prüft, erkennt einen Ausfall im Mittel nach zweieinhalb Minuten und rundet ihn in der Auswertung auf das Raster; wer jede Minute prüft, bekommt eine feinere Kurve und mehr Datenpunkte. Prüfintervall und Erkennungszeit rechnet den Zusammenhang durch.

Der Bezugszeitraum verschiebt die Toleranz um Tage

Dieselbe Prozentzahl bedeutet in verschiedenen Bezugszeiträumen etwas völlig anderes. Die IT-Recht Kanzlei rechnet es vor: "Wäre aber eine Verfügbarkeit von 99 % rund um die Uhr pro Monat vereinbart, dann dürfte selbst bei Monaten mit 31 Tagen das System in einem Monat maximal 7,44 Stunden nicht zur Verfügung stehen." Im Jahresbezug kippt das Verhältnis: "Wäre vereinbart, dass das System rund um die Uhr (24 Stunden) im ganzen Jahr zur Verfügung zu stehen hat (= 8736 Stunden), bedeutete eine 99% Verfügbarkeit pro Jahr einen hinzunehmenden Ausfall von 87,36 Stunden."

Diese 87,36 Stunden sind mehr als drei volle Tage, und nichts im Vertrag verbietet, sie an einem Stück zu nehmen. Die Empfehlung der Kanzlei fällt entsprechend aus: "Bei Hochverfügbarkeitssystemen ist es daher für den Kunden empfehlenswert, kürzere Bezugszeiten zu vereinbaren." Ein Monatsbezug begrenzt den Einzelschaden, ein Jahresbezug glättet ihn weg.

• Monatsbezug - eine Zusage von 99 Prozent lässt 7,44 Stunden zu (IT-Recht Kanzlei); der einzelne Vorfall bleibt in der Abrechnung sichtbar.
• Quartalsbezug - dreifache Toleranz; ein schlechter Monat wird von zwei guten getragen, die Credits fallen seltener an.
• Jahresbezug - dieselbe Zusage lässt 87,36 Stunden zu (IT-Recht Kanzlei); ein dreitägiger Ausfall bleibt rechnerisch vertragskonform.

Wer als Anbieter auf dem Jahresbezug besteht, macht damit auch die eigene Kennzahl unbrauchbar: ein Ausfall im Januar ist im Dezember statistisch verschwunden, im Gedächtnis des Kunden aber nicht. Eine Abrechnung je Monat trifft beide Interessen besser, weil sie die Kennzahl in der Nähe des Ereignisses hält, an das sich noch jemand erinnert.

Wartungsfenster: geplant, begrenzt, angekündigt

Geplante Wartung ist kein Ausfall, wenn der Vertrag das so sagt. Die IT-Recht Kanzlei weist darauf hin: "Bei Vereinbarung einer hohen Verfügbarkeit sollte der Provider darauf achten, dass Wartungsfenster bei der Verfügbarkeitsmessung berücksichtigt werden." Die Betonung liegt auf Fenster: Lage, Höchstdauer und Vorlauf der Ankündigung gehören hinein. Eine Klausel, die Wartung jederzeit und unbegrenzt erlaubt, höhlt die Zusage aus; § 307 Absatz 1 Satz 2 BGB stellt dazu klar, dass sich eine unangemessene Benachteiligung "auch daraus ergeben" kann, "dass die Bestimmung nicht klar und verständlich ist."

Technisch gehört zum Wartungsfenster der passende Statuscode. RFC 9110 beschreibt genau diesen Fall: "The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay." Wie sich das sauber umsetzen lässt, steht in 503 und Retry-After richtig setzen; dass ein vereinbartes Fenster auch in der Messung hinterlegt sein muss, damit es keine Fehlalarme erzeugt, in Wartungsfenster im Monitoring hinterlegen.

Reaktionszeit und Wiederherstellungszeit sind zwei Fristen

Neben der Verfügbarkeit stehen in einem SLA meist zwei Fristen, und sie werden regelmäßig verwechselt. Die IT-Recht Kanzlei trennt sie sauber: "Die Reaktionszeit ist der Zeitraum, innerhalb dessen der Provider mit den Störungs- bzw. Mängelbehebungsarbeiten zu beginnen hat." Und daneben: "Die Wiederherstellungszeit ist der Zeitraum, innerhalb dessen der Provider die Störungsbehebungs- bzw. Mängelbehebungsarbeiten erfolgreich abzuschließen hat." Eine Zusage, die nur eine der beiden Fristen nennt, lässt die andere offen.

Beide Fristen brauchen einen Startpunkt, sonst laufen sie nie los. Auch das steht im selben Beitrag: "Es ist stets von wesentlicher Bedeutung zu vereinbaren, wann der jeweilige Zeitraum beginnt (z.B mit dem Zugang der Störungs- bzw. Mängelmeldung) und während welcher Zeit er läuft." Ein automatischer Alarm mit Zeitstempel ist an dieser Stelle mehr wert als jede spätere Rekonstruktion aus Mailverläufen: Benachrichtigungen mit Zeitstempel dokumentieren den Zugang der Meldung, ohne dass jemand daran denken muss.

Sinnvoll ist außerdem, nicht jede Störung gleich zu behandeln. Die Kanzlei empfiehlt Abstufungen: "In diesen Fällen ist mit Störungsklassen zu arbeiten und für Störungen der Priorität II (behinderte Gebrauchsfähigkeit) und III (leichte Störung) eine entsprechende Minderung der Vergütung zu vereinbaren." Ein Totalausfall des Bestellvorgangs und ein langsam ladender Bildbereich sind nicht dasselbe Ereignis und brauchen nicht dieselbe Rechtsfolge.

Die zweite Zeile zeigt, dass ein einzelner Knoten ausfiel, während die Adresse insgesamt noch antwortete. Solche Abfragen ersetzen keinen Bericht, aber sie beantworten im Zweifel schneller als jede Rückfrage per Mail, ob überhaupt gemessen wurde und was gemessen wurde. Der Zeitstempel in der dritten Zeile gehört in dieselbe Notiz, sonst ist die Messung in einer Woche nicht mehr einzuordnen.

Service Credits: Vertragsstrafe oder pauschalierter Schadensersatz

Wird die Zusage verfehlt, folgt die Rechtsfolge. In der Praxis heißt sie Service Credit und ist rechtlich fast immer eines von zwei Dingen. Die IT-Recht Kanzlei zieht die Grenze: "Eine Vertragsstrafe ist abzugrenzen vom pauschalierten Schadensersatz, welcher lediglich der Beweiserleichterung und Prozessökonomie dient." Der Unterschied ist nicht akademisch, er entscheidet über die Wirksamkeit der Klausel und über die Frage, ob daneben noch ein weitergehender Schaden geltend gemacht werden kann.

Für die Vertragsstrafe gilt § 339 Satz 1 BGB: "Verspricht der Schuldner dem Gläubiger für den Fall, dass er seine Verbindlichkeit nicht oder nicht in gehöriger Weise erfüllt, die Zahlung einer Geldsumme als Strafe, so ist die Strafe verwirkt, wenn er in Verzug kommt." Dazu kommt eine Falle, die in laufenden Verträgen regelmäßig zuschlägt. § 341 Absatz 3 BGB bestimmt: "Nimmt der Gläubiger die Erfüllung an, so kann er die Strafe nur verlangen, wenn er sich das Recht dazu bei der Annahme vorbehält." Wer die Monatsrechnung vorbehaltlos begleicht, kann den Credit für denselben Monat verlieren.

Beim pauschalierten Schadensersatz greift im Verbrauchergeschäft § 309 Nummer 5 Buchstabe b BGB: unwirksam ist eine Pauschale, wenn "dem anderen Vertragsteil nicht ausdrücklich der Nachweis gestattet wird, ein Schaden oder eine Wertminderung sei überhaupt nicht entstanden oder wesentlich niedriger als die Pauschale". Zwischen Unternehmen gilt diese Vorschrift nicht unmittelbar; § 310 Absatz 1 Satz 1 BGB nimmt die Klauselverbote aus: "§ 305 Absatz 2 und 3, § 308 Nummer 1, 2 bis 9 und § 309 finden keine Anwendung auf Allgemeine Geschäftsbedingungen, die gegenüber einem Unternehmer, einer juristischen Person des öffentlichen Rechts oder einem öffentlich-rechtlichen Sondervermögen verwendet werden."

Entwarnung ist das nicht. Die Inhaltskontrolle nach § 307 BGB bleibt auch im unternehmerischen Verkehr anwendbar, und die Unklarheitenregel gilt ohnehin: § 305c Absatz 2 BGB lautet "Zweifel bei der Auslegung Allgemeiner Geschäftsbedingungen gehen zu Lasten des Verwenders." Wer eine Klausel schreibt, trägt ihr Auslegungsrisiko. Für die Praxis heißt das: je genauer die Ausfalldefinition, desto kleiner das Risiko der eigenen Klausel.

Eine dritte Rechtsfolge wird bei der Verhandlung oft übersehen. Die IT-Recht Kanzlei nennt sie ausdrücklich: "Eine weitere Möglichkeit der Sanktion ist die Kündigung des SLA aus wichtigem Grund." Für einen Kunden, dessen Geschäft an der Erreichbarkeit hängt, ist ein Sonderkündigungsrecht nach mehreren verfehlten Monaten meist wertvoller als jeder Credit.

Die Fünf-Prozent-Grenze und was 2024 dazukam

Für die Höhe gibt es eine Zahl, die seit über zwanzig Jahren steht. Die IT-Recht Kanzlei fasst sie zusammen: "Nach der Rechtsprechung des BGH sind Vertragstrafen in AGB unwirksam, wenn sie die Höchstgrenze von 5% des Auftragswertes überschreiten (BGH vom 23.01.2003 – VII ZR 210/01)." Die Kanzlei GÖRG datiert dieselbe Entscheidung in ihrem Legal Update vom Oktober 2024 so: "Im Jahr 2003 stellte der BGH fest, dass eine Vertragsstrafe von 5 Prozent der Auftragssumme gerade noch zulässig sei."

Im Februar 2024 hat der Bundesgerichtshof nachgelegt, und zwar an der Bezugsgröße. Das Legal Update beschreibt es so: "Der Bundesgerichtshof stellte mit Urteil vom 15. Februar 2024 – VII ZR 42/22 fest, dass bei einem Einheitspreisvertrag eine Vertragsstrafe in Höhe von 5 Prozent, die an die ursprünglich vereinbarte Auftragssumme anknüpft, als AGB des Auftraggebers unwirksam ist, da sie den Auftragnehmer unangemessen benachteiligt." Die Begründung trifft jeden, der Service Credits an eine Planzahl hängt: "Hierdurch sei die Grenze des Zumutbaren überschritten und die Klausel damit insgesamt unwirksam."

Beide Entscheidungen sind zum Bauvertragsrecht ergangen. Die Wertung zur Höchstgrenze in Allgemeinen Geschäftsbedingungen wird darüber hinaus herangezogen; die IT-Recht Kanzlei führt sie in ihrem Beitrag zum Servicelevelagreement ausdrücklich für IT-Verträge an. Für ein SLA folgt daraus zweierlei. Erstens braucht die Obergrenze eine Bezugsgröße, die am Ende auch stimmt, also die tatsächlich abgerechnete Vergütung des betroffenen Zeitraums und nicht die Summe aus dem Angebotsschreiben. Zweitens ist eine zu weit gefasste Klausel kein kleineres Problem als eine fehlende, weil sie insgesamt entfällt und das Gesetz übrig bleibt. Das Legal Update zieht die praktische Folgerung: "Vor dem Hintergrund der Entscheidung bedarf es zwingend einer Überprüfung und gegebenenfalls einer Anpassung der Vertragsstrafenklauseln bereits bestehender Verträge oder von Vertragsmustern."

Der Bericht, der im Streitfall etwas wert ist

Am Ende des Bezugszeitraums steht eine Zahl, und die Frage ist, woher sie kommt. Die IT-Recht Kanzlei formuliert den Anspruch des Kunden klar: "Der Kunde muss die Möglichkeit erhalten, die Erfüllung der Verfügbarkeitsvereinbarung zu überprüfen." Ein PDF mit einer einzigen Prozentzahl erfüllt das nicht, weil sich daraus nichts nachrechnen lässt.

1. Bezugszeitraum mit Anfangs- und Endzeitpunkt samt Zeitzone.
2. Die verwendete Ausfalldefinition im Wortlaut, nicht als Verweis auf eine Anlage.
3. Jedes Ereignis einzeln: Beginn, Ende, Dauer, betroffene Messpunkte, Statuscode oder Fehlerbild.
4. Die abgezogenen Wartungsfenster, einzeln und mit dem Datum ihrer Ankündigung.
5. Die Rohdatenbasis: Prüfintervall, Zahl der Messungen, Zahl der Fehlversuche.
6. Die Rechnung selbst, so dass die Prozentzahl aus den Zeilen darüber nachvollziehbar entsteht.
7. Eine Frist, innerhalb derer der Empfänger dem Bericht widersprechen kann.

Ein solcher Bericht ist gleichzeitig die Grundlage für die Abrechnung der Credits und die Verteidigung gegen unbegründete Forderungen. Er hilft beiden Seiten, weil er die Diskussion von der Prozentzahl auf die einzelnen Ereignisse verlagert, über die sich sachlich reden lässt. Bericht je Abrechnungszeitraum und eine öffentliche Statusseite für Kunden bedienen dabei zwei verschiedene Bedürfnisse: das Archiv und die Gegenwart.

Ein Service Level Agreement wird selten beim Abschluss genau gelesen und fast immer erst dann, wenn zwei Parteien zwei verschiedene Zahlen für denselben Monat vorlegen.

Wer Ausfälle ihren Ursachen zuordnen kann, verhandelt anders. Ein Einbruch, der mit einer Auslieferung zusammenfällt, ist ein anderer Vorgang als ein Netzproblem im Rechenzentrum: Deploy-Fehler als Ausfallursache beschreibt, wie sich das nachmessen lässt. Und wer eine Website übernimmt oder übergibt, sollte den Messstand mitgeben; Messprotokoll bei der Abnahme zeigt dieselbe Logik für den Zeitpunkt der Abnahme.

Zehn Punkte, die vor der Unterschrift geklärt sein sollten

Die folgende Liste lässt sich in einem einzigen Termin durchgehen, meist in einer halben Stunde. Jeder Punkt, der offenbleibt, ist später eine Auslegungsfrage, und Auslegungsfragen entscheidet im Zweifel nicht die Seite, die die Klausel geschrieben hat.

1. Von welchen Standorten wird gemessen, über welches Protokoll, in welchem Intervall?
2. Wer betreibt die Messstelle, und kann die Gegenseite die Rohdaten einsehen?
3. Welche Statuscodes gelten als Erfolg, und welche Inhaltsprüfung läuft mit?
4. Ab welcher Antwortzeit gilt eine Antwort als Ausfall?
5. Wie viele Fehlversuche von wie vielen Standorten beginnen einen Ausfall, und was beendet ihn?
6. Welcher Bezugszeitraum gilt: Monat, Quartal oder Jahr?
7. Wann liegen Wartungsfenster, wie lange dürfen sie höchstens dauern, wie früh werden sie angekündigt?
8. Wann beginnen Reaktions- und Wiederherstellungszeit, und während welcher Servicezeiten laufen sie?
9. Sind die Credits Vertragsstrafe oder pauschalierter Schadensersatz, und woran bemisst sich die Obergrenze?
10. Welcher Bericht wird wann geliefert, und in welcher Form lässt sich ihm widersprechen?

Sind diese zehn Punkte beantwortet, ist der Rest eine Verhandlung über eine Zahl. Sind sie es nicht, verhandeln beide Seiten über eine Zahl, die noch gar nicht definiert ist. Agenturen, die für mehrere Kunden gleichzeitig Zusagen geben und selbst welche von ihren Hostern entgegennehmen, führen die Punkte am besten einmal zentral und hängen die Messung daran: der Bereich für Agenturen bündelt die Kundenkonten dafür, und der SLA-Bericht je Zeitraum entsteht für jeden Kunden nach demselben Verfahren.