Erfahre, wie du eine Web-App entwirfst und baust, die SLA-Konformität zuverlässig verfolgt: Metriken definieren, Events sammeln, Ergebnisse berechnen, bei Verstößen alarmieren und revisionssicher berichten.
SLA-Konformität bedeutet, die messbaren Zusagen in einem Service Level Agreement (SLA) — einem Vertrag zwischen Anbieter und Kunde — einzuhalten. Die Aufgabe deiner App ist es, eine einfache Frage mit Belegen zu beantworten: Haben wir gehalten, was wir versprochen haben, für diesen Kunden, in diesem Zeitraum?
Es hilft, drei verwandte Begriffe zu trennen:
Die meisten SLA-Tracking-Web-Apps starten mit einer kleinen Menge an Kennzahlen, die sich auf reale operative Daten abbilden lassen:
Verschiedene Nutzer brauchen dieselbe Wahrheit, präsentiert aber anders:
Dieses Produkt geht um Tracking, Nachweis und Reporting: Signale sammeln, vereinbarte Regeln anwenden und revisionsfähige Ergebnisse erzeugen. Es garantiert nicht Performance; es misst sie — präzise, konsistent und so, dass du das Ergebnis später verteidigen kannst.
Bevor du Tabellen entwirfst oder Code schreibst, sei schmerzhaft klar darüber, was „Konformität“ für dein Geschäft bedeutet. Die meisten SLA-Tracking-Probleme sind keine technischen, sondern Anforderungsprobleme.
Fange an, die Wahrheitsquellen zu sammeln:
Schreibe diese als explizite Regeln auf. Wenn sich eine Regel nicht klar formulieren lässt, kann sie nicht zuverlässig berechnet werden.
Liste die realen „Dinge“, die eine SLA-Zahl beeinflussen können:
Identifiziere außerdem, wer was braucht: Support will Echtzeit-Risiken sehen, Manager wöchentliche Rollups, Kunden einfache Zusammenfassungen (oft für eine Statusseite).
Halte den Umfang klein. Wähle das Minimum, das das System Ende-zu-Ende beweist, zum Beispiel:
Erstelle eine einseitige Checkliste, die du später testen kannst:
Erfolg sieht so aus: Zwei Personen berechnen denselben Beispielmonat manuell und deine App liefert exakt dasselbe Ergebnis.
Ein korrekter SLA-Tracker beginnt mit einem Datenmodell, das erklären kann, warum eine Zahl so ist, wie sie ist. Wenn du eine monatliche Verfügbarkeitszahl nicht bis zu den exakten Events und Regeln zurückverfolgen kannst, wirst du Kundenstreitigkeiten und interne Unsicherheit haben.
Mindestens solltest du modellieren:
Eine nützliche Beziehung ist: customer → service → SLA policy (möglicherweise über einen Plan). Incidents und Events referenzieren dann Service und Kunde.
Zeitfehler sind die Hauptursache falscher SLA-Mathematik. Speichere:
occurred_at als UTC (Timestamp mit Zeitzonensemantik)received_at (wann dein System es gesehen hat)source (Monitor-Name, Integration, manuell)external_id (zum Deduplizieren von Retries)payload (rohes JSON für zukünftiges Debugging)Speichere außerdem customer.timezone (IANA-String wie America/New_York) für Anzeige und Geschäftszeiten-Logik, aber nutze sie nicht, um Event-Zeiten umzuschreiben.
Wenn Antwortzeit-SLAs außerhalb der Geschäftszeiten pausieren, modellier Kalender explizit:
working_hours pro Kunde (oder pro Region/Service): Wochentag + Start/End-Zeitenholiday_calendar verknüpft mit einer Region oder einem Kunden, mit Datumsbereichen und BezeichnungenHalte Regeln datengetrieben, damit Ops einen Feiertag aktualisieren kann, ohne zu deployen.
Speichere rohe Events in einer append-only-Tabelle und die berechneten Ergebnisse separat (z. B. sla_period_result). Jede Ergebniszeile sollte Periode-Grenzen, Input-Version (Policy-Version + Engine-Version) und Referenzen zu den verwendeten Event-IDs enthalten. Das macht Neuberechnungen sicher und liefert eine Prüfbahn, wenn Kunden fragen: „Welche Ausfall-Minuten habt ihr gezählt?"
Deine SLA-Zahlen sind nur so vertrauenswürdig wie die Events, die du ingestierst. Ziel ist einfach: jede relevante Änderung erfassen (Ausfall gestartet, Incident bestätigt, Service wiederhergestellt) mit konsistenten Zeitstempeln und genügend Kontext, um später Compliance zu berechnen.
Die meisten Teams holen Daten aus einer Mischung von Systemen:
Webhooks sind meist die beste Wahl für Echtzeit-Genauigkeit und geringere Last: das Quellsystem schickt Events an deinen Endpunkt.
Polling ist ein guter Fallback, wenn Webhooks fehlen: deine App fragt periodisch Änderungen seit dem letzten Cursor ab. Du brauchst Rate-Limit-Handling und sorgfältige „since“-Logik.
CSV-Import hilft bei Backfills und Migrationen. Behandle es als erstklassigen Ingestionspfad, damit du historische Perioden ohne Hacks neu verarbeiten kannst.
Normalisiere alles in eine einzige interne „Event“-Form, auch wenn die Upstream-Payloads unterschiedlich sind:
event_id (erforderlich): eindeutig und stabil bei Retries. Bevorzuge die Event-GUID der Quelle; sonst generiere einen deterministischen Hash.source (erforderlich): z. B. datadog, servicenow, manual.event_type (erforderlich): z. B. incident_opened, incident_acknowledged, service_down, service_up.occurred_at (erforderlich): Zeitpunkt, wann das Event passiert ist (nicht wann du es erhalten hast), mit Zeitzone.received_at (system): wann deine App es ingestiert hat.service_id (erforderlich): der SLA-relevante Service, den das Event betrifft.incident_id (optional, aber empfohlen): verknüpft mehrere Events zu einem Incident.attributes (optional): Priorität, Region, Kundensegment usw.Speichere event_id mit einer Unique-Constraint, um Ingestion idempotent zu machen: Retries erzeugen keine Duplikate.
Verwerfe oder quarantäniere Events, die:
occurred_at weit in der Zukunft liegt.service_id abbildbar sind (oder erzeuge einen expliziten „unmapped“-Workflow).event_id duplizieren.Diese Disziplin erspart spätere Diskussionen über SLA-Berichte — weil du saubere, nachvollziehbare Eingaben vorweisen kannst.
Deine Berechnungs-Engine ist der Ort, an dem „rohe Events“ zu SLA-Ergebnissen werden, die du verteidigen kannst. Wichtig ist, sie wie Buchhaltung zu behandeln: deterministische Regeln, klare Inputs und eine wiederabspielbare Spur.
Konvertiere alles in einen einzigen geordneten Stream pro Incident (oder pro Service-Impact):
Berechne Dauern, indem du Intervalle aufsummierst, nicht indem du blind zwei Zeitstempel subtrahierst.
Definiere TTFR als die verstrichene „chargeable“-Zeit zwischen incident_start und first_agent_response (oder acknowledged, je nach SLA-Formulierung). Definiere TTR als die verstrichene „chargeable“-Zeit zwischen incident_start und resolved.
„Chargeable“ bedeutet, dass du Intervalle entfernst, die nicht zählen:
Implementationstipp: speichere eine Kalenderfunktion (Geschäftszeiten, Feiertage) und eine Regel-Funktion, die eine Timeline nimmt und die belastbaren Intervalle zurückgibt.
Entscheide vorab, ob du berechnest:
Bei teilweisen Ausfällen: gewichte nach Auswirkung nur, falls dein Vertrag das verlangt; andernfalls behandle „degradiert“ als eigene Verstoßkategorie.
Jede Berechnung sollte reproduzierbar sein. Persistiere:
Wenn Regeln sich ändern, kannst du Neuberechnungen nach Version durchführen, ohne Historie umzuschreiben — entscheidend für Audits und Kundenstreitigkeiten.
Reporting ist der Punkt, an dem SLA-Tracking Vertrauen gewinnt — oder Fragen aufwirft. Deine App sollte klar machen, welcher Zeitraum gemessen wird, welche Minuten zählen und wie die finalen Zahlen abgeleitet wurden.
Unterstütze die üblichen Reporting-Perioden, die Kunden tatsächlich nutzen:
Speichere Perioden als explizite Start/End-Timestamps (nicht "Monat = 3"), damit du Berechnungen später abspielen und erklären kannst.
Eine häufige Verwirrungsquelle ist, ob der Nenner der gesamte Zeitraum oder nur die „berechtigte“ Zeit ist.
Definiere zwei Werte pro Periode:
Dann berechne:
availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes
Wenn eligible minutes null sein können (z. B. ein Service wird nur während Geschäftszeiten überwacht und die Periode enthält keine), definiere die Regel vorab: entweder „N/A“ oder als 100% behandeln — aber sei konsistent und dokumentiere es.
Die meisten SLAs brauchen sowohl eine Prozentzahl als auch ein binäres Ergebnis.
Behalte auch die „distance to breach“ (verbleibendes Downtime-Budget), damit Dashboards vor dem Überschreiten der Schwelle warnen können.
Behalte immer die rohen Eingaben (inkludierte/ausgeschlossene Events und Anpassungen), damit jeder Bericht die Frage beantworten kann: „Warum ist diese Zahl so?“ ohne vage Erklärungen.
Deine Berechnungs-Engine kann perfekt sein und trotzdem Nutzer verlieren, wenn die UI nicht sofort die Basisfrage beantwortet: „Erfüllen wir das SLA gerade, und warum?“ Gestalte die App so, dass jeder Bildschirm mit einem klaren Status beginnt und es den Leuten ermöglicht, in die Zahlen und die rohen Events hineinzuzoomen, die sie erzeugt haben.
Übersichts-Dashboard (für Operatoren und Manager). Führe mit einigen Kacheln an: Compliance des aktuellen Zeitraums, Verfügbarkeit, Antwortzeit-Compliance und „verbleibende Zeit bis zum Verstoß“, wo anwendbar. Verwende explizite Labels (z. B. „Verfügbarkeit (aktueller Monat)“ statt nur „Uptime“). Wenn du mehrere SLAs pro Kunde unterstützt, zeige zuerst den schlechtesten Status und erlaube Ausklappen.
Kundendetail (für Account-Teams und kundenorientiertes Reporting). Eine Kunden-Seite sollte alle Services und SLA-Tiers dieses Kunden zusammenfassen, mit einfachem Pass/Warn/Fail-Status und einer kurzen Erklärung (z. B. „2 gezählte Incidents; 18m Downtime gezählt"). Füge Links zu /status (falls du eine kundenfreundliche Statusseite anbietest) und zu einem Report-Export hinzu.
Service-Detail (für tiefe Untersuchungen). Zeige hier die exakten SLA-Regeln, das Berechnungsfenster und eine Aufschlüsselung, wie die Konformitätszahl gebildet wurde. Enthält ein Diagramm der Verfügbarkeit über die Zeit und eine Liste der Incidents, die zur SLA gezählt wurden.
Incident-Timeline (für Audits). Eine einzelne Incident-Ansicht sollte eine Timeline der Events zeigen (erkannt, bestätigt, mitigiert, gelöst) und welche Zeitstempel für „Antwort“ und „Lösung“ verwendet wurden.
Mache Filter konsistent über alle Bildschirme: Datumsspanne, Kunde, Service, Tier und Schweregrad. Verwende überall dieselben Einheiten (Minuten vs. Sekunden; Prozentsätze mit denselben Nachkommastellen). Wenn Nutzer die Datumsspanne ändern, aktualisiere jeden Wert auf der Seite, damit es keine Inkonsistenzen gibt.
Jede Zusammenfassungsmetrik sollte einen „Warum?“-Pfad haben:
Zeige Tooltipps sparsam, um Begriffe wie „Ausgeschlossene Downtime“ oder „Geschäftszeiten“ zu definieren, und zeige den genauen Regeltext auf der Service-Seite, damit niemand raten muss.
Bevorzuge klare Sprache statt Abkürzungen („Antwortzeit“ statt „MTTA“, es sei denn, deine Nutzer erwarten Abkürzungen). Kombiniere Farbe mit Textlabels („At risk: 92% des Error-Budgets verwendet“), um Mehrdeutigkeiten zu vermeiden. Falls deine App Audit-Logs unterstützt, füge eine kleine Box „Zuletzt geändert“ an den SLA-Regeln hinzu, die zu /audit verlinkt, damit Nutzer verifizieren können, wann Definitionen geändert wurden.
Alerting ist der Punkt, an dem deine SLA-Tracking-Web-App aufhört, passiv zu berichten, und Teams hilft, Strafen zu vermeiden. Die besten Alerts sind zeitnah, spezifisch und handlungsorientiert — sie sagen jemandem was als Nächstes zu tun ist, nicht nur, dass etwas „schlecht“ ist.
Beginne mit drei Trigger-Typen:
Mache Trigger pro Kunde/Service/SLA konfigurierbar, da verschiedene Verträge unterschiedliche Toleranzen haben.
Sende Alerts dorthin, wo Leute tatsächlich reagieren:
Jeder Alert sollte Deep-Links enthalten wie /alerts, /customers/{id}, /services/{id} und die Incident- oder Event-Detailseite, damit Reagierende die Zahlen schnell verifizieren können.
Implementiere Deduplizierung, indem du Alerts mit demselben Key (Kunde + Service + SLA + Periode) gruppierst und Wiederholungen für ein Cooldown-Fenster unterdrückst.
Füge Ruhezeiten (pro Team-Zeitzone) hinzu, damit nicht-kritische „approaching breach“-Alerts bis zu Geschäftszeiten warten, während „breach occurred“ Ruhezeiten bei hoher Schwere überschreiben kann.
Unterstütze schließlich Eskalationsregeln (z. B. On-Call nach 10 Minuten benachrichtigen, Manager nach 30 Minuten eskalieren), damit Alerts nicht in einem Postfach hängen bleiben.
SLA-Daten sind sensibel, weil sie interne Performance und kundenspezifische Berechtigungen offenlegen können. Behandle Zugriffskontrolle als Teil der SLA-Mathematik: derselbe Incident kann unterschiedliche Konformitätsergebnisse erzeugen, je nachdem, welche SLA auf einen Kunden angewendet wird.
Halte Rollen einfach und erweitere sie später granularer:
Ein praktikabler Default ist RBAC + Tenant-Scoping:
Sei explizit bezüglich kundenspezifischer Daten:
Starte mit E-Mail/Passwort und erfordere MFA für interne Rollen. Plane SSO später (SAML/OIDC) ein, indem du Identität (wer sie sind) von Autorisierung (was sie sehen/dürfen) trennst. Für Integrationen gib API-Keys an Service-Accounts mit engen Scopes und Rotationsunterstützung aus.
Füge unveränderliche Audit-Einträge hinzu für:
Speichere wer, was sich geändert hat (vorher/nachher), wann, wo (IP/User-Agent) und eine Korrelations-ID. Mache Audit-Logs durchsuchbar und exportierbar (z. B. /settings/audit-log).
Eine SLA-Tracking-App ist selten eine Insel. Du willst eine API, die Monitoring-Tools, Ticketing-Systeme und interne Workflows Incidents, Events erstellen und Reports ziehen lässt, ohne manuelle Arbeit.
Nutze einen versionierten Basis-Pfad (z. B. /api/v1/...), damit du Payloads weiterentwickeln kannst, ohne bestehende Integrationen zu brechen.
Essentielle Endpunkte, die die meisten Anwendungsfälle abdecken:
POST /api/v1/events zum Ingest von Statusänderungen (up/down, Latenzproben, Wartungsfenster). GET /api/v1/events für Audits und Debugging.POST /api/v1/incidents, PATCH /api/v1/incidents/{id} (acknowledge, resolve, assign), GET /api/v1/incidents.GET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id} zum Verwalten von Verträgen und Schwellen.GET /api/v1/reports/sla?service_id=...&from=...&to=... für Compliance-Zusammenfassungen.POST /api/v1/alerts/subscriptions zum Verwalten von Webhooks/E-Mail-Zielen; GET /api/v1/alerts für Alert-Historie.Wähle eine Konvention und nutze sie überall. Zum Beispiel: limit, cursor-Paginierung plus Standardfilter wie service_id, sla_id, status, from und to. Halte die Sortierung vorhersehbar (z. B. sort=-created_at).
Gib strukturierte Fehler mit stabilen Feldern zurück:
{ "error": { "code": "VALIDATION_ERROR", "message": "service_id is required", "fields": { "service_id": "missing" } } }
Nutze klare HTTP-Statuscodes (400 Validierung, 401/403 Auth, 404 nicht gefunden, 409 Konflikt, 429 Rate Limit). Für Event-Ingestion erwäge Idempotenz (Idempotency-Key), damit Retries keine Incidents duplizieren.
Setze angemessene Rate Limits pro Token (striktere Limits für Ingest-Endpunkte), sanitisiere Eingaben und validiere Zeitstempel/Zeitzonen. Bevorzuge scope-basierte API-Tokens (read-only Reporting vs. write-Zugriff auf Incidents) und logge immer, wer welchen Endpunkt aufgerufen hat (Details in deinem Audit-Log-Abschnitt unter /blog/audit-logs).
SLA-Zahlen sind nur nützlich, wenn Leute ihnen vertrauen. Tests für eine SLA-Tracking-Web-App sollten weniger auf „lädt die Seite“ fokussieren und mehr auf „verhält sich Zeitmathematik exakt wie der Vertrag sagt“. Behandle deine Berechnungsregeln wie ein Produkt-Feature mit einer eigenen Test-Suite.
Beginne damit, deine Berechnungs-Engine unitzgetestet mit deterministischen Inputs zu testen: eine Timeline von Events (Incident geöffnet, bestätigt, mitigiert, gelöst) und ein klar definiertes SLA-Regelset.
Nutze feste Zeitstempel und „freeze time“, damit Tests nicht von der aktuellen Uhrzeit abhängen. Decke Edge-Cases ab, die oft SLA-Berichte brechen:
Füge einige E2E-Tests hinzu, die den kompletten Flow durchlaufen: Events ingestieren → Konformität berechnen → Report generieren → UI rendern. Diese fangen Diskrepanzen zwischen „was die Engine berechnet hat“ und „was das Dashboard zeigt“. Halte die Szenarien wenige, aber mit hohem Wert und assertiere auf finale Zahlen (Verfügbarkeit %, Verstoß ja/nein, Zeit bis Ack).
Erzeuge Test-Fixtures für Geschäftszeiten, Feiertage und Zeitzonen. Du willst reproduzierbare Fälle wie „Incident tritt Freitag 17:55 Ortszeit auf“ und „Feiertag verschiebt Antwortzeit-Zählung".
Tests enden nicht mit dem Deploy. Füge Monitoring für Job-Fehler, Queue-/Backlog-Größe, Neuberechnungsdauer und Fehlerquoten hinzu. Wenn Ingestion hinterherhinkt oder ein Nachtjob fehlschlägt, kann dein SLA-Report falsch sein, selbst wenn der Code korrekt ist.
Eine SLA-Tracking-App zu liefern geht weniger um ausgefallene Infrastruktur als um vorhersehbaren Betrieb: deine Berechnungen müssen pünktlich laufen, Daten müssen sicher sein und Berichte reproduzierbar.
Starte mit Managed-Services, damit du dich auf Korrektheit konzentrieren kannst.
Halte Umgebungen minimal: dev → staging → prod, jeweils mit eigener DB und Secrets.
SLA-Tracking ist nicht rein Request/Response; es hängt von geplanten Aufgaben ab.
Führe Jobs über einen Worker-Prozess + Queue oder einen managed Scheduler aus, der interne Endpunkte aufruft. Mache Jobs idempotent (retry-safe) und logge jeden Lauf für Auditzwecke.
Definiere Retention nach Datentyp: behalte abgeleitete Compliance-Ergebnisse länger als rohe Events. Biete Exporte zuerst als CSV an (schnell, transparent), später PDF-Templates. Sei klar: Exporte sind „Best-Effort-Formatierung“, die DB bleibt die Quelle der Wahrheit.
Wenn du dein Datenmodell, den Ingest-Flow und die Reporting-UI schnell validieren willst, kann eine Vibe-Coding-Plattform wie Koder.ai helfen, ein End-to-End-Prototyp ohne vollständigen Engineering-Aufwand zu erstellen. Da Koder.ai komplette Anwendungen per Chat generiert (Web-UI plus Backend), ist es praktisch, um schnell zu realisieren:
Sobald Anforderungen und Berechnungen bewiesen sind (der schwierige Teil), kannst du iterieren, den Quellcode exportieren und in einen traditionelleren Build-&-Operate-Workflow überführen — wobei Features wie Snapshots und Rollback während schneller Iteration erhalten bleiben.
Ein SLA-Tracker beantwortet eine Frage mit Belegen: wurden die vertraglichen Zusagen für einen bestimmten Kunden und Zeitraum erfüllt?
In der Praxis bedeutet das, rohe Signale einzusammeln (Monitoring, Tickets, manuelle Updates), die Kundenregeln anzuwenden (Geschäftszeiten, Ausschlüsse) und ein revisionssicheres Pass/Fail mit unterstützenden Details zu erzeugen.
Verwende:
Modelliere sie getrennt, damit du Zuverlässigkeit mit SLOs verbessern kannst, ohne versehentlich die vertragliche Berichterstattung (SLA) zu verändern.
Ein gutes MVP verfolgt in der Regel 1–3 Kennzahlen Ende-zu-Ende:
Diese Anforderungen zwingen dich früh zu Implementationen für Perioden, Kalender und Ausschlüsse — die kniffligen Teile.
Fehler in Anforderungen entstehen meist durch unausgesprochene Regeln. Sammle und dokumentiere:
Wenn sich eine Regel nicht klar formulieren lässt, versuche nicht, sie im Code zu „erkennen“ — kläre sie zuerst mit den Stakeholdern.
Beginne mit einfachen, expliziten Entitäten:
Ziel ist Nachvollziehbarkeit: jede gemeldete Zahl sollte auf und verweisen können.
Speichere Zeitstempel korrekt und konsistent:
occurred_at in UTC mit Zeitzonenkontextreceived_at (wann dein System es gesehen hat)Mache Reporting-Perioden explizit (Start/Ende-Zeitstempel), damit Berichte reproduzierbar sind — auch bei DST-Übergängen.
Normalisiere alles in ein einheitliches internes Event-Format mit stabiler eindeutiger ID:
event_id (einzigartig, stabil bei Retries)source, event_type, , Berechne Dauern, indem du Intervalle auf einer Zeitachse aufsummierst, nicht indem du einfach zwei Zeitstempel subtrahierst.
Definiere explizit, welche Zeit „chargeable“ ist, indem du Intervalle entfernst, die nicht zählen, z. B.:
Speichere die abgeleiteten Intervalle und die Begründungscodes, damit du genau erklären kannst, was gezählt wurde.
Verfolge zwei Nenner explizit:
Dann berechne:
availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes
Lege außerdem fest, was passiert, wenn eligible_minutes null ist (z. B. ). Dokumentiere diese Regel und wende sie konsistent an.
Lass die UI die Frage beantworten: „Erfüllen wir das SLA gerade, und warum?“ auf den ersten Blick:
Bei Alerts: priorisiere handlungsorientierte Trigger — Approaching breach, Breach occurred, wiederholte Verstöße — und verlinke auf relevante Seiten wie oder .
occurred_atservice_idincident_id und attributesErzwinge Idempotenz durch eine Unique-Constraint auf event_id. Für fehlende Zuordnungen oder out-of-order-Ankünfte: quarantäne/markieren — nicht stillschweigend „korrigieren“.
/customers/{id}/services/{id}