SLA-Monitoring: So messen und berichten Sie 99,9 % Uptime

„Wir garantieren 99,9 % Uptime.“ Das versprechen viele SaaS-Unternehmen. Wie viele können es belegen? SLA-Monitoring verwandelt das Versprechen von Marketing in eine messbare, berichtspflichtige Verpflichtung.

Uptime-SLAs verstehen

Was bedeutet „99,9 % Uptime“ wirklich?

Die Zahlen klingen beeindruckend — der Unterschied zwischen den „Neunen“ ist groß:

| SLA | jährliche Downtime | monatliche Downtime |
|-----|-------------------|---------------------|
| 99 % | 3 Tage, 15 Stunden | 7 Stunden, 18 Min. |
| 99,5 % | 1 Tag, 19 Stunden | 3 Std., 39 Min. |
| 99,9 % | 8 Std., 46 Min. | 43 Min., 50 Sek. |
| 99,95 % | 4 Std., 23 Min. | 21 Min., 55 Sek. |
| 99,99 % | 52 Min., 36 Sek. | 4 Min., 23 Sek. |

Bei 99,9 % haben Sie weniger als 44 Minuten erlaubte Downtime pro Monat — inklusive geplanter Wartung, Überraschungsausfällen und Teil-Beeinträchtigungen. Das ist ein knappes Budget.

SLA vs. SLO vs. SLI

Die Begriffe werden oft verwechselt:

• SLI (Service Level Indicator) — die gemessene Metrik: Uptime-Prozentsatz, Antwortzeit, Fehlerrate.
• SLO (Service Level Objective) — Ihr internes Ziel: „API soll 99,95 % der Zeit verfügbar sein.“
• SLA (Service Level Agreement) — die vertragliche Verpflichtung mit finanziellen Folgen: „Unter 99,9 % Uptime erhalten Kundinnen Service Credits.“

Ihr SLO sollte strenger sein als Ihr SLA. Versprechen Sie 99,9 %, sollte das interne Ziel 99,95 % oder höher sein — Puffer vor finanziellen SLA-Verstößen.

Uptime messen

Die Grundformel

```
Uptime % = ((Gesamtminuten − Downtime-Minuten) / Gesamtminuten) × 100
```

Für einen 30-Tage-Monat (43.200 Minuten):

• 20 Minuten Downtime = 99,954 % Uptime
• 44 Minuten Downtime = 99,898 % Uptime (Verstoß bei 99,9 %-SLA)
• 120 Minuten Downtime = 99,722 % Uptime

Was zählt als Downtime?

Hier wird es nuanciert. Ihr SLA sollte klar definieren:

Zählt typischerweise als Downtime:

• vollständige Nichtverfügbarkeit (5xx, Timeouts)
• starke Performance-Degradation (Antwortzeiten > 10× normal)
• Authentifizierungsfehler, die Zugang verhindern
• Datenverlust oder -korruption

Typischerweise ausgenommen:

• geplante Wartungsfenster (mit Vorankündigung)
• höhere Gewalt (Naturkatastrophen, große Internet-Störungen)
• vom Kunden verursachte Probleme (falsch konfigurierte API-Calls)
• Drittanbieter außerhalb Ihrer Kontrolle

Diese Definitionen im SLA dokumentieren — Unklarheit nützt niemandem.

Monitoring für SLA-Konformität

Für belastbare Uptime-Messungen:

Häufig prüfen: 1- oder 30-Sekunden-Intervalle liefern präzise Downtime. Bei 5-Minuten-Intervallen ist die Messung nur auf ±5 Minuten genau — bei 44 Minuten Budget pro Monat spürbar.

Mehrere Standorte: Ein Ausfall nur in Europa ist trotzdem Downtime. Multi-Region-Monitoring erfasst lokale Probleme.

Uptime pro Component: Ihr SLA kann den Gesamtdienst abdecken — pro Component zu tracken zeigt schwache Glieder: „API 99,99 %, Webhook-Zustellung nur 99,7 %.“

Wartungsfenster ausschließen: Wenn geplante Wartung im SLA erlaubt ist, sollte Ihr Tool Wartungsfenster unterstützen, die nicht gegen Uptime zählen.

Ein SLA-Report aufbauen

Wesentliche Metriken

Jeder SLA-Report sollte enthalten:

1. Gesamt-Uptime-Prozentsatz — die Kernzahl.
2. Anzahl der Incidents — wie oft der Dienst ausfiel.
3. Gesamtdowntime — Minuten/Stunden Nichtverfügbarkeit.
4. MTTD (Mean Time to Detect) — wie schnell jedes Problem erkannt wurde.
5. MTTR (Mean Time to Recovery) — wie schnell behoben.
6. Längster Einzel-Incident — der schlimmste Ausfall in der Periode.
7. Trend-Vergleich — zur Vorperiode.

Berichts-Rhythmus

• Monatlich: Standard für viele SLAs — Metriken plus Incident-Liste mit Zeitstempeln und Beschreibungen.
• Quartalsweise: Business-Review — Trends, Verbesserungen, Investitionen.
• Jährlich: strategische Übersicht für Leadership und Enterprise-Kundinnen — Jahr-über-Jahr, Zuverlässigkeits-Roadmap.

Reports nutzbar machen

„99,94 % Uptime“ allein reicht nicht. Ergänzen Sie:

• Incident-Aufschlüsselung: Was passierte, wie erkannt, wie behoben, was gegen Wiederholung unternommen wird.
• Error-Budget-Tracking: Bei 99,9 %-SLA und 30 von 44 erlaubten Downtime-Minuten verbraucht — das Team weiß: riskante Deployments vorsichtiger angehen.
• Trend-Analyse: Verbessert oder verschlechtert sich die Uptime? Werden Incidents häufiger oder seltener?

Strategien für hohe Uptime

Error-Budget-Management

Das Error-Budget aus Googles SRE-Framework: Differenz zwischen 100 % und Ihrem SLO-Ziel.

Bei 99,9 %-SLO über 30 Tage beträgt das Budget 43 Minuten.

Mit Budget können Sie schnell liefern, experimentieren, kalkulierte Risiken eingehen. Wenn das Budget knapp wird: langsamer deployen, mehr testen, Fokus auf Zuverlässigkeit.

In die richtigen Bereiche investieren

Nicht jede Verbesserung der Uptime ist gleich wertvoll. Fokus auf:

1. Single Points of Failure eliminieren — Datenbank ohne Replica, Server ohne Failover, DNS ohne Backup.
2. Deployment-Risiko senken — Blue-Green, Canary, automatische Rollbacks.
3. Erkennung beschleunigen — schnellere Erkennung = kürzere Ausfälle. 15 Sekunden vs. 5 Minuten kann SLA-Einhaltung vs. Verstoß bedeuten.
4. Recovery automatisieren — selbstheilende Systeme, Neustarts, Traffic-Umleitung, Skalierung.

Status Page für Transparenz

Eine öffentliche Status Page verbessert Uptime nicht direkt — aber die Wahrnehmung:

• proaktive Kommunikation bei Incidents schafft Vertrauen
• Incident-Historie zeigt Bilanz
• Subscriber-Updates halten Kundinnen informiert
• Transparenz reduziert Support-Volumen

Fazit

SLA-Monitoring geht nicht nur um Vertragskonformität — es baut eine Kultur der Zuverlässigkeit. Wenn Sie Uptime rigoros messen, transparent berichten und Ihr Error Budget bewusst steuern, entsteht eine Feedback-Schleife, die den Dienst kontinuierlich verbessert.

Starten Sie mit klaren Uptime-Zielen, präzisem Monitoring und ehrlicher Berichterstattung — die Zahlen folgen.

Ihr SLA präzise tracken. Kostenlos monitoren — detaillierte Uptime-Reports, Incident-Tracking und Status Pages inklusive.