SLOs und Fehlerbudget

Ein SLO (Service Level Objective) ist die Verfügbarkeit, die Sie anstreben, zum Beispiel 99,9 % über 30 Tage. OKStatus macht daraus ein Fehlerbudget — den Ausfall, den dieses Ziel erlaubt —, zeigt, wie viel davon übrig ist, und warnt Sie, bevor es aufgebraucht ist.

Verfügbar in den Tarifen Max und Enterprise. Es gibt eine einzige Einstellung: das Ziel. Das Zeitfenster (30 rollierende Tage), das Budget und die Alarme ergeben sich daraus.

SLA oder SLO?

Das SLA ist, was Sie Ihren Kunden zusagen; es ist das, was die SLA-Berichte messen. Das SLO ist Ihr internes Ziel, meist strenger, damit Sie reagieren, bevor das SLA gefährdet ist. Ein SLO ändert nichts an Ihren Berichten.

Das Fehlerbudget

Das Budget ist der Ausfall, den das Ziel über 30 Tage erlaubt:

Ziel	Erlaubter Ausfall in 30 Tagen
99 %	7 h 12 min
99,5 %	3 h 36 min
99,9 %	43 min
99,95 %	21 min

Jedes Ziel zwischen 50 % und 99,999 % wird akzeptiert.

Was zählt

• Nur Ausfälle, genau wie bei der Uptime bestimmt: Ein Monitor ist ausgefallen, wenn die Mehrheit seiner Regionen den Fehler bestätigt. Ein langsamer Monitor ist nicht ausgefallen — Langsamkeit behandeln die Antwortzeit-Alarme.
• Geplante Wartungen zählen nicht: Ausfall innerhalb eines Wartungsfensters des Monitors bleibt außen vor.
• Das Zeitfenster rollt: Es umfasst immer die letzten 30 Tage. Ein Ausfall gibt seine Zeit 30 Tage später zurück, das Budget füllt sich von selbst.
• Die Verfügbarkeit auf den SLO-Ansichten ist 1 − Ausfall ÷ 30 Tage, damit „Ziel erreicht“ und „Restbudget“ immer übereinstimmen.

Ein Ziel für einen Monitor festlegen

Öffnen Sie den Monitor (Bearbeiten oder Monitor hinzufügen) und gehen Sie zum Schritt Alarme. Unter Verfügbarkeitsziel (SLO) wählen Sie 99 %, 99,5 %, 99,9 % oder 99,95 % oder geben einen eigenen Wert ein. Das Formular zeigt das daraus folgende Budget („43 min Ausfall in 30 Tagen erlaubt“) und, bei einem bestehenden Monitor, ob das Ziel in den letzten 30 Tagen erreicht worden wäre. Keins entfernt das SLO.

Ein Ziel für eine Gruppe festlegen

Eine Gruppe steht oft für einen Dienst: „Zahlungen“ = API + Webhooks + Backoffice. Öffnen Sie die Gruppe (⋯ → Bearbeiten) und wählen Sie ihr Ziel. Die Regel ist einfach: Die Gruppe ist ausgefallen, sobald einer ihrer Monitore es ist. Zwei gleichzeitig ausgefallene Monitore zählen einmal. Jeder Monitor behält sein eigenes SLO, falls er eines hat.

Die Alarme der Gruppe gehen an die Alarmkanäle der Gruppe, die im selben Dialog festgelegt werden.

Viele Monitore auf einmal

• Auf der Seite SLO wählen Sie SLOs festlegen (oder das Menü Typ → Ohne SLO und die Auswahlschaltfläche), markieren die Monitore, wählen ein Ziel und Anwenden. Vor dem Anwenden zeigt die Liste für jeden Monitor, ob er dieses Ziel in den letzten 30 Tagen erreicht hätte.
• In der Monitor-Liste wählen Sie Monitore aus und nutzen SLO ▾ in der Auswahlleiste neben Gruppe ▾.
• Für große Bestände setzen Sie sloTarget über die API oder Terraform (siehe unten).

Wo Sie das Budget sehen

• Die SLO-Seite (Seitenleiste, unter Monitore): alle SLOs, Monitore und Gruppen, das schlechteste zuerst — Ziel, Verfügbarkeit über 30 Tage, Restbudget und wann es im aktuellen Tempo aufgebraucht ist. Die KPI-Zeile zählt die SLOs im Plan, gefährdet und aufgebraucht.
• Die Monitor-Seite: Die Zeitraumleiste zeigt das SLO des Monitors statt des SLA-Ziels der Organisation, und eine Karte Fehlerbudget zeigt den Rest, den verbrauchten Ausfall, die Prognose und das Restbudget über die letzten 30 Tage.
• Der Gruppenkopf in der Monitor-Liste: „SLO 99,5 % · Budget 71 %“.

Ein SLO ist gefährdet, wenn weniger als 25 % seines Budgets übrig sind oder es im Tempo der letzten 7 Tage innerhalb von 7 Tagen aufgebraucht wäre.

Alarme

Drei Hinweise, nichts einzustellen. Sie gehen an die Kanäle des Monitors (oder der Gruppe), höchstens einer pro Auswertung (alle 5 Minuten):

Hinweis	Gesendet, wenn
Schneller Verbrauch	2 % des 30-Tage-Budgets in der letzten Stunde oder 5 % in den letzten 6 Stunden verbraucht (und mindestens eine Minute Ausfall). Höchstens alle 6 h wiederholt.
75 % verbraucht	Drei Viertel des Budgets sind weg. Erneut erst, nachdem es wieder unter 70 % gefallen ist.
Aufgebraucht	Das Ziel wird nicht mehr erreicht. Erneut erst, nachdem es wieder unter 90 % gefallen ist.

Es gibt keine „wiederhergestellt“-Nachricht: Das Budget kommt langsam von selbst zurück, eine Nachricht dafür wäre Lärm. Auch keine Eskalation — ein SLO-Hinweis ist eine Warnung, kein Vorfall. Pausierte oder stummgeschaltete Monitore senden keine.

SLO-Hinweise gehen an E-Mail, Webhooks und die Chat-Kanäle (Slack, Discord, Microsoft Teams, Google Chat, Mattermost, Rocket.Chat, Telegram, ntfy, Pushover). Incident-Werkzeuge (PagerDuty, Jira, Jira Service Management, incident.io, Alertmanager, Splunk, Grafana IRM), SMS und Mobile Push erhalten sie nicht: Sie dienen dazu, jemanden zu alarmieren, und ein Budget-Hinweis ist dafür nicht gedacht.

Statusseiten

SLOs und Budgets werden nie auf öffentlichen Statusseiten angezeigt.

Tarife

Unterhalb von Max sind der SLO-Block in den Formularen und die SLO-Seite sichtbar, aber gesperrt, mit einem Link zu den Tarifen. Wechselt die Organisation in einen niedrigeren Tarif, bleiben ihre SLOs erhalten, werden aber nicht mehr ausgewertet und lassen sich weiterhin entfernen.

API, Terraform und MCP

Was	REST-API	Terraform	MCP
Ziel eines Monitors	sloTarget bei Monitoren (null entfernt es)	slo_target bei okstatus_monitor	slo_target bei create_monitor, update_monitor
Ziel einer Gruppe	sloTarget bei Monitor-Gruppen	slo_target bei okstatus_monitor_group	update_monitor_group
Budgets	GET /api/v1/slos, GET /api/v1/monitors/:id/slo	—	list_slos

Terraform verwaltet das Ziel, nicht das Budget: Eine Zahl, die sich jede Minute ändert, gehört nicht in einen Terraform-State.