SLI — Service Level Indicators

Auf dieser Seite erfahren Sie, welche Service Level Indicators (SLI) wir für Kundenprojekte einsetzen, wie wir sie messen und wo die Grenzen dieser Messungen liegen. Wir veröffentlichen diese Informationen, damit Sie als Kunde nicht nur die Zielwerte, sondern auch die Methodik, die Einschränkungen und die Interpretation der Metriken nachvollziehen können.

Diese Seite dient der Information. Die aufgeführten SLI- und SLO-Werte sind typische Richtwerte für betreute Projekte und ersetzen nicht die individuellen Vereinbarungen aus Vertrag, SOW und SLA.

Wie lesen Sie diese Seite SLI, SLO, SLA Was wir messen Tools Error Budget Support-Pläne Vorfälle Glossar

So lesen Sie diese Seite

SLI sind messbare Kennzahlen — keine Marketingversprechen.

SLO auf dieser Seite sind Richtwerte für typische Szenarien; die endgültigen Zielwerte werden nach dem Onboarding und einer Architekturanalyse festgelegt.

Datenquellen hängen von der Projektkonfiguration ab: externe synthetische Checks, Infrastrukturmetriken, APM und CI-Audits.

Geplante Wartungsfenster, höhere Gewalt und Ausfälle externer Dienste können gemäß Vertragsbedingungen aus den Berechnungen ausgenommen werden.

Die tatsächliche Berichterstattung und der Zugang zu Dashboards richten sich nach dem gewählten Support-Plan.

Warum SLI für Ihr Unternehmen wichtig sind

Wenn ein Kunde sein Projekt in die Betreuung gibt, lautet die Erwartung meist ganz einfach: Die Website oder Anwendung soll stabil, schnell und vorhersehbar laufen. Aber die Formulierung „läuft alles normal" ist für ein professionelles Qualitätsmanagement zu vage. SLI übersetzen sie in messbare Kennzahlen, die man prüfen, vergleichen und datenbasiert besprechen kann.

Was passiert gerade?

Echtzeit-Monitoring erfasst jede Abweichung sofort.

Wie stabil war der Service im Zeitverlauf?

Historische Daten zeigen Trends und saisonale Muster.

Wann müssen wir eingreifen?

Schwellenwerte lösen Alarme aus, bevor der Nutzer ein Problem bemerkt.

Der praktische Nutzen von SLI für Ihr Unternehmen: weniger Unsicherheit, früheres Erkennen von Leistungseinbußen und die Möglichkeit, Entscheidungen zur Weiterentwicklung Ihres Projekts auf Basis von Fakten statt Bauchgefühl zu treffen.

SLI, SLO, SLA — wie hängt das zusammen?

Die drei Ebenen der Servicequalität bauen aufeinander auf: von der Messung — zu den Zielen — zu den Verpflichtungen.

SLI — Service Level Indicator

Was wir messen.

Numerische Kennzahlen, die das tatsächliche Nutzererlebnis widerspiegeln: Verfügbarkeit, Antwortzeiten, Fehlerquoten, Core Web Vitals. SLI sind Fakten, die von Monitoring-Tools erfasst werden — keine subjektiven Einschätzungen.

SLO — Service Level Objective

Worauf wir hinarbeiten.

Interne Zielwerte für jeden SLI. Zum Beispiel: „API-Antwortzeit — maximal 300 ms für 95 % der Anfragen". SLO setzen die Qualitätslatte, die wir täglich überwachen und vierteljährlich überprüfen.

SLA — Service Level Agreement

Was wir garantieren.

Formelle Verpflichtungen, die vertraglich festgehalten werden. Wenn SLO unser interner Standard ist, dann ist das SLA ein Versprechen an den Kunden — mit Verantwortung bei Nichteinhaltung. Mehr zu unserem SLA

Grundprinzip: SLI liefern die Daten für SLO, SLO bilden die Grundlage für SLA. Ohne verlässliche Indikatoren sind alle Garantien nur leere Worte. Deshalb fangen wir bei den Messungen an.

Was wir messen

Wir erfassen Metriken, die sich auf das Nutzererlebnis, die Servicestabilität und die Steuerbarkeit des Supports auswirken. Der Umfang kann je nach Projekt variieren, aber die grundlegenden Indikatoren und Berechnungsprinzipien bleiben einheitlich.

Kernindikatoren

Indikator	Was er zeigt	Wie wir messen	Richtwert (SLO)
Uptime (Verfügbarkeit)	Anteil der Zeit, in der der Service erreichbar ist und korrekt antwortet	Anteil erfolgreicher HTTP-Antworten (2xx/3xx) an der Gesamtzahl synthetischer Checks	≥ 99,5 % (Standard), ≥ 99,8 % (Ziel)
Latency (Antwortzeit)	Geschwindigkeit der Serverantwort auf eine Nutzeranfrage	Perzentile P50, P95, P99 über alle Anfragen im Zeitraum	P95 < 300 ms (API), P95 < 2 s (Seite)
Error Rate (Fehlerquote)	Anteil der Anfragen, die mit einem Serverfehler enden	Prozentsatz der 5xx-Antworten an der Gesamtzahl der Anfragen	< 0,1 %
First Response Time	Wie schnell das Team auf ein eingehendes Ticket reagiert	Zeit von der Ticketerstellung bis zur ersten inhaltlichen Antwort	≤ 20 Min. (S1, Geschäftszeiten)

Core Web Vitals

Google nutzt Core Web Vitals als Rankingfaktor. Wir tracken sie separat, weil sie sich direkt auf SEO und Conversion auswirken.

Metrik	Was sie misst	Schwelle „gut"	Unser Tool
LCP (Largest Contentful Paint)	Ladegeschwindigkeit des Hauptinhalts der Seite	≤ 2,5 s	Lighthouse CI
INP (Interaction to Next Paint)	Reaktionsfähigkeit der Seite auf Nutzerinteraktionen	≤ 200 ms	Lighthouse CI
CLS (Cumulative Layout Shift)	Visuelle Stabilität — keine „springenden" Elemente	≤ 0,1	Lighthouse CI

Lighthouse CI läuft automatisch in der Deployment-Pipeline. Wenn sich Core Web Vitals nach einem Update verschlechtern, erfahren wir das, bevor es sich auf die Suchpositionen auswirkt.

Ergänzende Indikatoren

Indikator	Was er zeigt	Richtwert (SLO)
TTMR (Time to Mitigation/Restore)	Zeit vom Beginn eines Vorfalls bis zur Wiederherstellung	≤ 4 Std. (S1), ≤ 8 Std. (S2)
Deployment Success Rate	Anteil der Deployments ohne Servicebeeinträchtigung	≥ 99 %
Saturation (Auslastung)	Nutzung der Serverressourcen: CPU, RAM, Festplatte	CPU idle > 10 %, RAM < 85 %, Festplatte > 10 % frei
SSL/Domain Expiry	Überwachung der Laufzeiten von Zertifikaten und Domains	Warnung ≥ 30 Tage vor Ablauf

Die Werte in den obigen Tabellen dienen als Basisrichtwerte. Für ein konkretes Projekt werden sie nach dem Onboarding, der Architekturanalyse, dem Lastprofil und der Kritikalität der Geschäftsprozesse angepasst.

Wie wir messen: Tools und Methodik

Die Aussagekraft von Metriken hängt nicht nur vom Tool ab, sondern auch von der Art der Anwendung: Prüffrequenz, Alarmkonfiguration, Monitoring-Standorte, Aufbewahrungsdauer der Daten und korrekte Interpretation. Deshalb setzen wir auf eine Kombination aus externem synthetischem Monitoring und Analysen auf Infrastruktur- und Anwendungsebene.

Grafana-Übersichtsdashboard mit den wichtigsten Projektmetriken

UptimeRobot — externes Verfügbarkeitsmonitoring

Synthetische Checks von mehreren geografischen Standorten alle 1–5 Minuten:

HTTP/HTTPS, Ping, Port-Checks, DNS- und SSL-Monitoring
Sofortige Benachrichtigungen bei Ausfall via E-Mail, Slack, Telegram
Historische Uptime-Daten für die Berichterstattung
Öffentliche Statusseiten für Transparenz gegenüber Nutzern

Grafana — Verfügbarkeitshistorie eines Projekts — Grafana — Verfügbarkeits- und Health-Status-Historie des Projekts

Grafana + Prometheus — Visualisierung und Analyse

Prometheus sammelt Metriken von Servern und Anwendungen, Grafana visualisiert sie auf konfigurierbaren Dashboards:

Latency (P50, P95, P99), Error Rate, Throughput — in Echtzeit
Monitoring der Serverressourcen: CPU, RAM, Festplatte, Netzwerk
Konfigurierbare Alarme bei Überschreitung von Schwellenwerten
Historische Trends zur Erkennung von Verschlechterungen, bevor sie zum Vorfall werden

Grafana — Dashboard Latency und Error Rate — Dashboard Latency und Error Rate

Grafana — aggregierte Anwendungslogs — Aggregierte Anwendungslogs

Laravel Nightwatch — Monitoring auf Anwendungsebene

Tiefgreifende Instrumentierung von Laravel-Anwendungen — direkt von den Framework-Entwicklern:

Tracing jeder Anfrage vom Eingang bis zur Antwort
Erkennung langsamer SQL-Abfragen und Engpässe in Warteschlangen
Echtzeit-Monitoring von Exceptions und Fehlern
Überwachung von Hintergrundaufgaben und Cron-Zeitplänen

Hinweis: Bei einzelnen Projekten wird als Alternative zu Nightwatch New Relic APM eingesetzt — eine umfassende Plattform für Performance-Monitoring. Die Toolwahl richtet sich nach der Projektarchitektur und den Kundenanforderungen.

Laravel Nightwatch — Request-Tracing — Request-Tracing

Laravel Nightwatch — Request-Liste mit Zeitstempeln — Request-Liste

Laravel Nightwatch — Exception-Details mit Stack Trace — Exception mit Stack Trace

Lighthouse CI — Kontrolle der Core Web Vitals

Automatisches Performance-Audit bei jedem Deployment:

Ausführung in der CI/CD-Pipeline von Bitbucket Pipelines
Vergleich der Metriken mit dem vorherigen Release — Regressionen fallen sofort auf
LCP, INP, CLS sowie Accessibility- und SEO-Audit
Blockierung des Deployments bei kritischer Verschlechterung der Werte

Methodik

Für Webanwendungen verwenden wir den RED-Ansatz (Rate, Errors, Duration) — drei Schlüsselsignale, die als Erste auf eine Verschlechterung des Nutzererlebnisses reagieren. Für Infrastrukturmetriken nutzen wir den ergänzenden USE-Ansatz (Utilization, Saturation, Errors).

Aus Nutzersicht

Nicht interne Serverwerte, sondern das reale Erlebnis: Seitenladezeiten, Erfolg von Aktionen, Wartezeiten.

Perzentile statt Durchschnitte

P95 und P99 zeigen das schlechteste Erlebnis realer Nutzer, nicht den „Durchschnitt über alle Patienten".

Kontinuierlich, rund um die Uhr

Metriken werden 24/7 erfasst, nicht nur während der Geschäftszeiten.

Vierteljährliche Überprüfung der Schwellenwerte

Nach jedem bedeutsamen Vorfall und bei Änderungen im Lastprofil.

Error Budget — das Budget für zulässige Fehler

Kein Service läuft komplett störungsfrei. Das Error Budget ist ein Engineering-Ansatz, der diese Realität in eine steuerbare Größe übersetzt: das zulässige Maß an Ausfallzeit oder Fehlern innerhalb eines Zeitraums, bei dem der Service im Rahmen des SLO bleibt.

Ziel-Uptime	Zulässige Ausfallzeit pro Monat	Zulässige Ausfallzeit pro Jahr
99,5 %	~3 Std. 39 Min.	~43 Std. 48 Min.
99,8 %	~1 Std. 27 Min.	~17 Std. 31 Min.
99,9 %	~43 Min.	~8 Std. 46 Min.
99,95 %	~22 Min.	~4 Std. 23 Min.

Budget nicht ausgeschöpft

Updates, neue Features und Experimente sind möglich.

Budget wird knapp

Der Fokus verschiebt sich auf Stabilität: nur kritische Fixes, verstärktes Testing.

Budget aufgebraucht

Änderungsstopp bis der Puffer wiederhergestellt ist. Priorität hat die Beseitigung der Ursachen.

Warum das für Sie wichtig ist: Das Error Budget hilft uns, Entscheidungen nicht aus dem Bauch heraus zu treffen („lieber nichts anfassen"), sondern auf Basis von Daten. Das bedeutet: Ihr Projekt entwickelt sich so schnell wie möglich — bei dem von Ihnen gewünschten Zuverlässigkeitsniveau.

Monitoring-Umfang nach Support-Plan

Die Monitoring-Tiefe und der Umfang der erfassten SLI richten sich nach dem gewählten Support-Plan.

Leistung	Basic	Extended	Enterprise
Synthetische Verfügbarkeitschecks (Uptime)	✓	✓	✓
Überwachung von SSL-Zertifikaten und Domains	✓	✓	✓
Benachrichtigungen bei Ausfall	✓	✓	✓
Lighthouse CI (Core Web Vitals)	✓	✓	✓
Latency-Monitoring (P50, P95, P99)	—	✓	✓
Error-Rate-Monitoring	—	✓	✓
Ressourcen-Monitoring (CPU, RAM, Festplatte)	—	Teilweise	✓
APM auf Anwendungsebene (Nightwatch / New Relic)	—	Teilweise	✓
Individuelle Grafana-Dashboards	—	—	✓
Proaktive Benachrichtigungen bei Verschlechterungen	—	✓	✓
Error-Budget-Tracking	—	—	✓
SLI-Berichterstattung	Auf Anfrage	Monatlich	Wöchentlich + QBR
Ziel-Uptime (SLO)	99,5 %	99,5–99,8 %	bis 99,9 %*

* Die Zielwerte des Enterprise-Plans werden individuell nach dem Onboarding und einer Architekturanalyse festgelegt.

Modell zur Einstufung von Vorfällen

Alle Vorfälle werden nach ihrer geschäftlichen Auswirkung klassifiziert. Jedem Schweregrad sind eigene Reaktionsziele zugeordnet.

Stufe	Beschreibung	Erste Reaktion (SLO)	Wiederherstellung (SLO)
S1 — Kritisch	Vollständiger oder teilweiser Ausfall, ein zentraler Geschäftsprozess ist blockiert, Sicherheitsvorfall	≤ 20 Min. (Geschäftszeiten)	≤ 4 Stunden
S2 — Hohe Auswirkung	Erhebliche Beeinträchtigung mit Workarounds, Einfluss auf SEO oder Conversion	≤ 1 Stunde	≤ 8 Stunden
S3 — Mittlere Auswirkung	Defekte mit begrenztem geschäftlichem Einfluss	≤ 4 Stunden	Im laufenden Sprint
S4 — Geringe Auswirkung	Kosmetische Probleme, UX-Verbesserungen	≤ 1 Werktag	Nach Priorität im Backlog

Transparenz und Berichterstattung

SLI haben nur dann einen Wert, wenn sie für den Kunden zugänglich und verständlich sind. Wir verstecken keine Metriken — wir machen sie zur Grundlage gemeinsamer Entscheidungen.

Grafana-Dashboard-Set für Kundenprojekte — Grafana-Dashboard-Set — Beispiel des Umfangs im Enterprise-Plan

Was ein SLI-Bericht enthält

Abschnitt	Inhalt
Uptime im Zeitraum	Tatsächlicher Verfügbarkeitsprozentsatz im Vergleich zum Ziel-SLO
Latency-Trends	Entwicklung der Antwortzeiten (P50, P95) mit Hervorhebung von Anomalien
Error Rate	Fehlerquote mit Aufschlüsselung nach Typ und Quelle
Core Web Vitals	Entwicklung von LCP, INP, CLS und Auswirkungen auf SEO-Rankings
Vorfälle im Zeitraum	Anzahl, Schweregrad, Reaktionszeit und Wiederherstellungsdauer
Error Budget	Wie viel Budget verbraucht wurde und wie viel noch übrig ist
Empfehlungen	Konkrete Maßnahmen zur Verbesserung der Kennzahlen

Berichtsfrequenz

Plan	SLI-Bericht	Format
Basic	Auf Anfrage	Zusammenfassung im Ticketsystem
Extended	Monatlich	PDF + Kommentare
Enterprise	Wöchentlich + vierteljährlicher QBR	Dashboard + PDF + Call

Unser Ansatz für Zuverlässigkeit

SLI sind nicht einfach Zahlen in einem Bericht. Sie bilden die Grundlage einer Engineering-Kultur, die unsere täglichen Entscheidungen bestimmt.

Restore-first

Bei einem Vorfall hat die Wiederherstellung des Betriebs Vorrang — nicht die Ursachenanalyse. Die Untersuchung beginnt erst, wenn der Service wieder läuft.

Keine Geheimnisse

Wenn etwas schiefläuft, erfährt der Kunde das von uns — nicht aus seinem eigenen Monitoring. Proaktive Benachrichtigungen gehören zu unserem Standard.

Blameless Postmortem

Nach jedem bedeutsamen Vorfall — Analyse ohne Schuldzuweisungen. Ziel sind systemische Verbesserungen, keine Sanktionen. Das Ergebnis: konkrete Maßnahmen, um eine Wiederholung zu verhindern.

Automatisiertes Monitoring

Alles, was sich automatisieren lässt, wird automatisiert. Unsere Ingenieure treffen Entscheidungen — statt manuell Grafiken zu prüfen.

Klare Verantwortlichkeiten

Wir übernehmen die Verantwortung für Code, Deployment-Prozesse und Monitoring. Hosting-Infrastruktur, Zugänge und Verträge mit Drittanbietern liegen im Verantwortungsbereich des Kunden. Diese klare Abgrenzung ermöglicht realistische SLO.

Verantwortungsbereiche und Ausnahmen

Eine klare Abgrenzung der Verantwortungsbereiche macht SLI aussagekräftig und interpretierbar. Ohne sie können Metriken und Zielwerte leicht in die Irre führen.

Unser Verantwortungsbereich

Anwendungscode, Deployment und CI/CD-Pipelines

Einrichtung, Pflege und Weiterentwicklung des Monitoring-Systems

Reaktion auf Vorfälle, Root-Cause-Analyse und Korrekturmaßnahmen

Kontrolle der Core Web Vitals und Optimierungsempfehlungen

Verwaltung des Error Budgets und SLI-Berichterstattung

Verantwortungsbereich des Kunden

Hosting-Infrastruktur und DNS, sofern nicht an uns übergeben

Drittanbieter-Services und APIs: Zahlungssysteme, CRM, E-Mail-Provider und andere externe Abhängigkeiten

Verwaltung von Zugängen, Benutzerkonten und internen Sicherheitsrichtlinien

Content, Einstellungen und Nutzeraktionen im Admin-Bereich

Rechtzeitige Bereitstellung von Daten und Zugängen für die Diagnose

Was SLI in der Regel nicht abdecken

Höhere Gewalt

Größere Providerausfälle, Rechenzentrumsausfälle, Naturereignisse.

Geplante Wartung

Im Voraus vereinbarte Wartungsfenster.

Nicht abgestimmte Änderungen

Änderungen durch den Kunden oder Dritte ohne Beteiligung unseres Teams.

Externe Abhängigkeiten außerhalb unserer Kontrolle

Externe APIs, CDN, E-Mail- und Zahlungsdienste.

Die konkreten Verantwortungsbereiche und Ausnahmen werden im Vertrag festgelegt und können je nach Projektarchitektur und gewähltem Support-Plan variieren.

Häufig gestellte Fragen

Was ist der Unterschied zwischen SLI und SLA?

SLA beschreibt Prozesse und formelle Verpflichtungen gegenüber dem Kunden. SLI sind konkrete messbare Kennzahlen: Verfügbarkeit, Geschwindigkeit, Fehler, Stabilität. SLI bilden die technische Grundlage für das SLA.

Kann ich die Metriken meines Projekts in Echtzeit sehen?

Ja. Die Art des Zugangs richtet sich nach dem Support-Plan und der Projektkonfiguration. Für einen Teil der Projekte stehen regelmäßige Berichte zur Verfügung, bei Enterprise-Support separate Dashboards und erweiterte Metrikvisualisierung.

Was passiert, wenn ein SLO verletzt wird?

Wir dokumentieren die Verletzung, informieren den Kunden, führen eine Vorfallanalyse durch und legen Korrekturmaßnahmen fest. Wenn für das Projekt ein SLA mit Service-Credits oder anderen Verpflichtungen gilt, richten sich die weiteren Schritte nach den Bedingungen dieser Vereinbarung.

Wie werden die SLO-Zielwerte für mein Projekt festgelegt?

Nach dem Onboarding bewerten wir Architektur, Infrastruktur, Vorfallhistorie, Lastprofil und die Kritikalität der Geschäftsprozesse. Die Werte auf dieser Seite zeigen unseren typischen Ansatz und stellen keine automatische Garantie für jedes Projekt dar.

Garantieren Sie eine Verfügbarkeit von 100 %?

Nein. Null Ausfallzeit ist in realen Systemen nicht erreichbar. Statt unrealistischer Versprechen arbeiten wir mit messbaren Zielen, tracken das Error Budget und managen Risiken datenbasiert.

Welche Monitoring-Tools setzen Sie ein?

Der Basis-Stack hängt vom Projekt ab, umfasst aber in der Regel UptimeRobot für externe Verfügbarkeitschecks, Grafana und Prometheus für Metriken und Visualisierung, Laravel Nightwatch oder New Relic für APM sowie Lighthouse CI für Performance-Kontrolle und Core Web Vitals.

Was ist ein Error Budget und wozu braucht man es?

Das Error Budget zeigt, wie viel Ausfallzeit oder Fehler im Rahmen des gewählten SLO zulässig sind. Es hilft, Zuverlässigkeit und Entwicklungsgeschwindigkeit in Balance zu halten: Solange das Budget nicht aufgebraucht ist, kann das Produkt zügig weiterentwickelt werden; ist es erschöpft, verschiebt sich der Fokus auf Stabilisierung.

Terminologie

Glossar

APM (Application Performance Monitoring) — eine Kategorie von Tools, die Anwendungscode instrumentieren, um Anfragen zu verfolgen, langsame Abfragen zu erkennen, Exceptions anzuzeigen und die Ressourcennutzung innerhalb der Anwendung zu analysieren. Beispiele: Laravel Nightwatch, New Relic.

Blameless Postmortem — eine strukturierte, schuldfreie Analyse nach einem bedeutsamen Vorfall. Fokussiert auf Zeitablauf, Ursache, beitragende Faktoren und konkrete Maßnahmen zur Vermeidung von Wiederholungen.

CDN (Content Delivery Network) — ein verteiltes Netzwerk von Servern, das statische Ressourcen vom geografisch nächstgelegenen Knoten an Nutzer ausliefert und so die Latenz reduziert.

CI/CD (Continuous Integration / Continuous Delivery) — eine automatisierte Pipeline, die Code bei jedem Commit erstellt, testet und deployt. CI erkennt Regressionen frühzeitig; CD überträgt validierte Änderungen zuverlässig und reproduzierbar in die Produktion.

CLS (Cumulative Layout Shift) — eine Core Web Vitals-Metrik, die unerwartete visuelle Bewegungen von Seitenelementen während des Ladens quantifiziert. Schwelle „gut": ≤ 0,1.

Core Web Vitals — eine von Google definierte Gruppe nutzerzentrierter Metriken — LCP, INP und CLS — die als Suchranking-Signal und Indikator für die wahrgenommene Seitenqualität dienen.

CPU (Central Processing Unit) — die primäre Recheneinheit eines Servers. Hohe CPU-Last ist eines der wichtigsten Signale für Performance-Verschlechterungen.

Deployment Success Rate — der Prozentsatz der Deployments, die ohne Servicebeeinträchtigung oder Ausfall abgeschlossen werden. Richtwert: ≥ 99 %.

DNS (Domain Name System) — das System, das lesbare Domainnamen in Server-IP-Adressen auflöst. DNS-Ausfälle machen eine Website unerreichbar, auch wenn der Server selbst ordnungsgemäß funktioniert.

Error Budget — das zulässige Maß an Servicebeeinträchtigungen innerhalb eines Messzeitraums (typischerweise monatlich oder quartalsweise). Wenn das Budget aufgebraucht ist, werden neue Features eingefroren und der Fokus auf die Wiederherstellung der Zuverlässigkeit gelegt.

Error Rate (Fehlerquote) — der Prozentsatz der Anfragen, die mit einem serverseitigen Fehler enden (typischerweise HTTP-5xx-Antworten). Richtwert: < 0,1 %.

First Response Time — die Zeit von der Ticketerstellung bis zur ersten inhaltlichen Antwort des Support-Teams. Richtwert für S1: ≤ 20 Minuten während der Geschäftszeiten.

INP (Interaction to Next Paint) — eine Core Web Vitals-Metrik zur Messung der Seitenreaktionsfähigkeit: die Verzögerung zwischen einer Nutzerinteraktion und der nächsten visuellen Aktualisierung. Schwelle „gut": ≤ 200 ms.

Latency (Latenz) — die Zeit zwischen dem Absenden einer Anfrage durch den Client und dem Empfang des ersten Antwort-Bytes. Wird typischerweise als Perzentile (P50, P95, P99) statt als Durchschnittswert angegeben.

LCP (Largest Contentful Paint) — eine Core Web Vitals-Metrik, die angibt, wann das größte sichtbare Inhaltselement vollständig gerendert ist. Schwelle „gut": ≤ 2,5 s.

P50 / P95 / P99 (Perzentile) — statistische Maßzahlen für die Latenzverteilung. P95 bedeutet: 95 % der Anfragen wurden innerhalb dieser Zeit abgeschlossen. Perzentile zeigen die Tail-Latenz, die Durchschnittswerte verbergen, und spiegeln die Erfahrung der langsamsten echten Nutzer wider.

QBR (Quarterly Business Review) — ein formelles vierteljährliches Meeting zwischen Dienstleister und Kunde zur Überprüfung von Performance-Daten, SLI/SLO-Ergebnissen, Vorfällen und Plänen für das kommende Quartal.

RAM (Random Access Memory) — der Arbeitsspeicher eines Servers. Hoher RAM-Verbrauch (über 85 %) kann zu Anwendungsverlangsamungen oder Crash-Loops führen.

RCA (Root Cause Analysis) — eine systematische Untersuchung zur Ermittlung der eigentlichen Ursache eines Vorfalls, nicht nur seiner Symptome.

RED (Rate, Errors, Duration) — eine Monitoring-Methodik, die sich auf drei anfragebezogene Signale konzentriert, die am empfindlichsten auf nutzerseitige Verschlechterungen reagieren. Rate = Anfragedurchsatz, Errors = fehlgeschlagene Anfragen, Duration = Latenz.

Restore-first — ein Prinzip der Vorfallbehandlung: Zuerst wird die Dienstverfügbarkeit wiederhergestellt, erst danach die Ursache untersucht.

Saturation (Auslastung) — der Grad, in dem eine Ressource (CPU, RAM, Festplatte, Netzwerk) an ihre Kapazitätsgrenze gelangt. Hohe Auslastung prognostiziert künftige Latenzzunahmen und Ausfälle, bevor explizite Fehler auftreten.

SEO (Search Engine Optimization) — Maßnahmen zur Verbesserung der Sichtbarkeit einer Website in Suchmaschinen-Ergebnissen. Core Web Vitals beeinflussen SEO-Rankings direkt.

SLA (Service Level Agreement) — eine formelle vertragliche Verpflichtung zwischen Dienstleister und Kunde, die Garantien, Verantwortungsmechanismen und Abhilfemaßnahmen bei Nichteinhaltung festlegt.

SLI (Service Level Indicator) — eine quantitative Kennzahl, die eine bestimmte Dimension der Servicequalität aus Nutzersicht erfasst (z. B. Uptime in %, P95-Latenz, Fehlerquote). Die Messungsebene des Qualitätsmanagements.

SLO (Service Level Objective) — ein internes Ziel für einen SLI (z. B. „P95-API-Latenz < 300 ms"). SLOs definieren die Qualitätslatte, an der das Team gemessen wird, und bilden die Grundlage für SLA-Verpflichtungen.

SOW (Statement of Work) — ein Vertragsdokument, das die konkreten Liefergegenstände, Zeitpläne und den Umfang der Arbeit für ein Projekt oder einen Support-Einsatz festlegt, einschließlich konkreter SLO-Zielwerte.

SQL (Structured Query Language) — die Standardsprache für Abfragen und Manipulation relationaler Datenbanken. Langsame SQL-Abfragen sind eine häufige Ursache für Performance-Verschlechterungen in Anwendungen.

SSL (Secure Sockets Layer) — das Vorgängerprotokoll zu TLS, weitgehend als Synonym für HTTPS-zertifikatbasierte Verschlüsselung verwendet. Die Überwachung des SSL-Ablaufdatums verhindert zertifikatbedingte Ausfälle (Warnschwelle: ≥ 30 Tage vor Ablauf).

Throughput (Durchsatz) — die Anzahl der Anfragen, die ein Service pro Zeiteinheit verarbeitet (z. B. Anfragen pro Sekunde). Eines der drei RED-Signale.

TTMR (Time to Mitigation / Restore) — die Zeit vom Erkennen des Vorfalls bis zur vollständigen Wiederherstellung des Dienstes. Richtwert: ≤ 4 Std. für S1, ≤ 8 Std. für S2.

Uptime (Verfügbarkeit) — der Anteil der Zeit, in der ein Service erreichbar ist und korrekt antwortet, ausgedrückt in Prozent. Berechnet als erfolgreiche synthetische Checks geteilt durch Gesamtchecks. Richtwert: ≥ 99,5 %.

USE (Utilization, Saturation, Errors) — eine Monitoring-Methodik für Infrastrukturressourcen. Ergänzt RED, indem sie identifiziert, ob Hardware-Engpässe — nicht die Anwendungslogik — der Flaschenhals sind.

Rechtlicher Hinweis

Die Informationen auf dieser Seite dienen der Beschreibung und stellen kein öffentliches Angebot dar. Die aufgeführten SLI- und SLO-Werte spiegeln unseren typischen Ansatz zur Messung der Servicequalität wider. Konkrete Verpflichtungen, Metriken, Zielwerte und Ausnahmen für jedes Projekt werden im individuellen Vertrag, SOW und Service Level Agreement (SLA) festgehalten.

Möchten Sie mehr erfahren?

Service Level Agreement (SLA)

Dort finden Sie Prozesse, Eskalationswege und formelle Garantien. Zum SLA →

Beispielbericht für Ihren Stack anfordern

Wir erstellen eine Demo auf Basis eines realen Projekts, zugeschnitten auf Ihre Architektur und Technologien. Kontakt aufnehmen →