Plattform-Uptime · letzte 30 Tage · gewichtet
—,%
Gewichteter Durchschnitt über alle Plattform-Komponenten — kritische Dienste tragen voll, wichtige zur Hälfte. Die Zahl rechnet ab dem ersten Probe-Sample, ohne 30-Tage-Vorlauf.
I · Übersicht
Status-Daten werden gesammelt
Phase-1-Skeleton ist live; die Probe-Pipeline und das Komponenten-Inventar werden verbunden, sobald die dedizierte REOSA Staging-Datenbank provisioniert wurde.
II · Komponenten
Neun Dienste in zwei Verantwortungsfeldern.
Plattform-Surfaces, die unsere Kunden direkt nutzen. KI-Provider, durch die wir Inferenz routen. Jede Latenz ist ein 60-Sekunden- Mittel der p95-Probe; ein Klick auf eine Zeile öffnet den Komponenten-Verlauf.
Komponenten-Inventar wird geladen
Die Komponenten-Tabelle ist mit der dedizierten Status- Datenbank verbunden, aktuell sind aber noch keine Einträge gesetzt. Sobald das Seed gelaufen ist, erscheinen hier App-Plattform · API · Auth Service · Marketing-Site · Developer Portal sowie die KI-Provider Google Gemini · Anthropic Claude · Mistral · Moonshot Kimi.
Externe Dienste (Stripe, Resend, Cloudflare) und DB/Storage- Internas werden bewusst nicht öffentlich getrackt.
III · Verfügbarkeit
Tag-für-Tag-Verlauf, klickbar pro Komponente.
Eine Zelle pro Tag, gefärbt nach schlechtestem Probe-Status. Tage ohne Probe-Daten bleiben grau — die Heatmap zeigt sofort alle Komponenten, nicht erst wenn Historie aufgebaut ist.
Komponenten-Inventar nicht geladen
Sobald das Status-Komponenten-Seed gelaufen ist, erscheint hier eine 90-Tage-Heatmap — eine Zeile pro überwachter Plattform-Komponente und KI-Provider.
IV · Kennzahlen
Was die Plattform misst — und mit welchen Zahlen sie lebt.
Risiko-Index
Daten werden gesammelt — der Risiko-Index erscheint sobald genug Probe-Samples und Incident-Historie vorliegen.
Ergänzende Reaktionszeiten · 30 / 90 Tage
Wir auditieren uns selbst. Diese Zahlen aktualisieren sich automatisch aus jedem öffentlichen Incident. Niedriger ist besser.
Noch keine abgeschlossenen Incidents in den letzten 90 Tagen — gute Nachricht. Die Zahlen erscheinen automatisch sobald Incident-Historie vorhanden ist.
V · SLA & Refund
Wenn wir versagen, lassen wir die Folgen nicht euch tragen.
Drei Plan-Schwellen, eine Live-Verfügbarkeit. Refunds laufen als zusätzliche Credits, einzeln per E-Mail geprüft — bewusst manuell, gegen Bot-Claims.
SLA & Refund-Versprechen
rolling 30 d · gewichtetFällt die Plattform-Verfügbarkeit unter die für deinen Plan vereinbarte Schwelle, kannst du eine Refund-Anfrage stellen. Die Erstattung läuft als zusätzliche Credits, nicht in Geld — und sie wird einzeln per E-Mail geprüft, nicht automatisiert.
Plan-Schwellen
- Compact60%
Einsteiger-Plan · 60 % Schwelle
- Standard80%
Der 90 %-Default · 80 % Schwelle
- Max · Max+85%
White-Label · 85 % Schwelle
Plattform-weite Verfügbarkeit · live
—Compact · 60 %Standard · 80 %Max · Max+ · 85 %
wird gesammelt
Refund-relevant? support@localhost — schreib uns deine Tenant-Slug und welche Tools du nutzt, dann rechnen wir dein genutztes Komponenten-Bündel im Abrechnungs-Fenster nach.
Refund = zusätzliche Credits · keine Geld-Erstattung · keine Pro-rata-Berechnung
Plattform-Mittel = gewichteter Durchschnitt der Verfügbarkeits-Quoten über kritische Komponenten (×1) und wichtige Komponenten (×0,5). Interne Telemetrie zählt nicht in das Versprechen — eine Sentry- Outage bricht keine Tenant-Funktion.
VI · Abhängigkeiten
Wenn ein Dienst stockt, was sonst noch fällt.
Cascade sichtbar gemacht — kein blindes Suchen während eines Vorfalls. Pfeile zeigen die Fall-Richtung; Dicke entspricht der Anzahl abhängiger Dienste.
Keine Komponenten geseedet — Topologie wird sichtbar sobald die dedizierte Status-Datenbank provisioniert ist.
VII · Benachrichtigung
Wir senden, wenn etwas passiert.
Drei Wege — Atom für Reader und IDE-Plugins, RSS für Slack und Teams, E-Mail für jeden anderen. Phase 2 bringt Webhook-Delivery für Tenant-Aggregator-Tools.