Service Level Agreement (SLA)
Support-Anfragen (Incidents) dürfen ausschließlich durch den benannten Workspace Admin (Tenant Owner) des Kunden über das offizielle CausaNova-Support-Portal eingereicht werden.[cite: 29] Anfragen von regulären SaaS-Endanwendern (Consumern) werden aus Sicherheitsgründen abgewiesen und müssen durch den internen IT-Support des Kunden qualifiziert werden.[cite: 29]
1. Abgrenzung: Infrastruktur vs. Applikation
Bei Buchung der LB 0a (Managed Cloud) wird die zugrundeliegende Infrastruktur (physische Server, Strom, Kühlung, Backbone-Routing) durch die IONOS SE bereitgestellt. CausaNova gewährleistet die Infrastruktur-Uptime als Back-to-Back-Garantie basierend auf den Hochverfügbarkeits-SLAs (bis zu 99,99 %) des Rechenzentrumsbetreibers.
CausaNova garantiert die funktionale Lauffähigkeit der eigenen Software-Applikationen (Frontend, Backend, APIs, BPMN-Engine). Ein Software-Fehler liegt vor, wenn die CausaNova-Container aufgrund von Code-Bugs abstürzen (HTTP 5xx-Fehler), obwohl die IONOS-Infrastruktur fehlerfrei arbeitet.
Betreibt der Kunde das System selbst (LB 0b), entfällt die Infrastruktur-Garantie vollständig.[cite: 29] Das SLA beschränkt sich strikt auf Level 3 Support für Software-Bugs innerhalb der übergebenen CausaNova-Container.[cite: 29] CausaNova leistet keinen Support für Hardware-, Netzwerk- oder Kubernetes-Ausfälle des Kunden.[cite: 29]
Die CausaNova AI Pilots und der Swarm greifen via API auf externe Sprachmodelle (z.B. OpenAI, Anthropic, lokale IONOS-LLMs) zu. Ausfälle oder Latenzen dieser Drittanbieter-APIs gelten als Höhere Gewalt. Sie fließen nicht in die Uptime-Berechnung der CausaNova-Plattform ein und berechtigen nicht zu Service Credits.
2. Messmethodik der Verfügbarkeit (Uptime)
Die Systemverfügbarkeit (nur anwendbar bei Buchung von LB 0a: Managed Cloud) wird pro Kalendermonat berechnet:[cite: 29]
((Gesamte Minuten – Anrechenbarer Ausfall) / Gesamte Minuten) × 100[cite: 29]
- Anrechenbarer Ausfall: Das Portal oder die Backend-API antwortet anhaltend (länger als 5 zusammenhängende Minuten) mit server-seitigen Fehlern (HTTP 5xx) oder die Datenbank ist nicht erreichbar.
-
Nicht anrechenbar (Kein SLA-Bruch):
(a) Ausfälle externer LLM-Provider.
(b) Geplante, vorab angekündigte Wartungsfenster (Maintenance).
(c) Spin-up Latenzen beim automatischen Skalieren von Nodes (Auto-Scaling, ca. 2-5 Minuten).[cite: 29]
(d) Abstürze, die durch Endlosschleifen im kunden-eigenen DSL-Code oder BPMN-Prozess verursacht wurden.[cite: 29]
3. Severity Level (Fehlerklassen)
| Level | Definition | Response Time (Erstantwort)* | Restoration Target (Ziel-Lösung)* |
|---|---|---|---|
| Sev 1 (Kritisch) | Totalausfall des Workspaces. Datenbank nicht erreichbar. Kein funktionaler Workaround möglich.[cite: 29] | Gemäß SLA Tier[cite: 29] | < 12 Stunden[cite: 29] |
| Sev 2 (Hoch) | Wichtige Kernfunktion gestört (z.B. Ausführung von Workflows bricht ab), System ist aber anderweitig operativ nutzbar.[cite: 29] | Gemäß SLA Tier[cite: 29] | < 24 Stunden[cite: 29] |
| Sev 3 (Normal) | Einzelne UI-Bugs, kosmetische Fehler oder verlangsamte Ladezeiten ohne operativen Stillstand.[cite: 29] | Gemäß SLA Tier[cite: 29] | Nächstes reguläres Release[cite: 29] |
4. SLA Tiers & Service Credits (Gutschriften)
| SLA Tier | Garantierte Uptime | Sev 1 Response | Service Credits bei Verfehlung |
|---|---|---|---|
| Tier 1: Standard | 99,0 % (nur LB 0a)[cite: 29] | < 48h (Werktags)[cite: 29] | Keine finanzielle Kompensation.[cite: 29] |
| Tier 2: Pro | 99,5 % (nur LB 0a)[cite: 29] | < 12h (Werktags)[cite: 29] | < 99,5 % = 10 % Monats-Gutschrift auf die betroffene Komponente.[cite: 29] |
| Tier 3: Enterprise | 99,9 % (nur LB 0a)[cite: 29] | < 4h (24/7)[cite: 29] | < 99,9 % = 10 % Credit | < 99,0 % = 50 % Credit (Maximal-Deckelung) + Sonderkündigungsrecht.[cite: 29] |