Antwortzeit-Alarme

Ein Dienst kann jede Prüfung beantworten und für seine Nutzer trotzdem zu langsam sein. Ein Antwortzeit-Alarm setzt den Monitor auf beeinträchtigt, wenn seine Prüfungen länger dauern als eine von Ihnen gewählte Schwelle, und sendet einen Degraded-Alarm an seine Kanäle.

Verfügbar in allen Tarifen, für HTTP-, TCP-, Ping-, DNS-, gRPC-, Datenbank-, Mail- und Redis-Monitore. Push-, Gruppen- und KI-Modell-Monitore haben keine Antwortzeit-Schwelle (ein KI-Modell-Monitor hat sein eigenes Limit für die Zeit bis zum ersten Token).

Die Schwelle einstellen

Öffnen Sie den Monitor (Bearbeiten, oder Monitor hinzufügen für einen neuen) und gehen Sie zum Schritt Alarme. Er enthält von oben nach unten:

Wiederholungen vor Down — wie viele fehlgeschlagene Prüfungen in Folge toleriert werden, bevor der Monitor down ist: Keine, 1, 2, 3, 4 oder 5 (standardmäßig 1).
Antwortzeit — Als langsam melden ab, in Millisekunden. Die Antwortzeiten des Monitors der letzten 7 Tage (Durchschnitt, p95, p99) stehen über dem Feld, um die Wahl zu erleichtern. Wählen Sie eine Vorgabe (500 ms, 1 s, 1,5 s, 3 s), geben Sie einen Wert zwischen 50 und 60 000 ms ein, oder wählen Sie Aus.
Die Alarmkanäle, die die Alarme des Monitors erhalten.

Die Regionen, aus denen geprüft wird, wählen Sie im Schritt Zeitplan, neben dem Intervall.

Wann der Alarm ausgelöst wird

Die Schwelle wird pro Region beurteilt, wie Ausfälle:

Eine Prüfung ist langsam, wenn sie erfolgreich ist und strikt länger als die Schwelle dauert.
Die Region wird nach max(2, retries + 1) langsamen Prüfungen in Folge beeinträchtigt. Mit dem Standardwert 1 Wiederholung sind das 2 Prüfungen, mit 3 Wiederholungen 4 Prüfungen. Eine einzelne langsame Prüfung löst nie einen Alarm aus.
Eine langsame Region genügt, um den Monitor auf beeinträchtigt zu setzen. Langsamkeit zählt nie für die Mehrheitsregel: Ein überall langsamer Monitor ist beeinträchtigt, nie down.
Der Monitor ist bei der ersten Prüfung unter der Schwelle wieder up — ohne Bestätigungsfenster auf dem Rückweg.
Ein echter Ausfall hat immer Vorrang: Eine fehlgeschlagene Prüfung folgt der üblichen Wiederholungsregel und setzt den Monitor auf down.

Es gilt dieselbe Sperrzeit wie für andere Alarme: Ein Monitor, der ständig zwischen langsam und schnell wechselt, sendet nicht bei jeder Prüfung einen Alarm.

Was der Alarm enthält

Der Degraded-Alarm nennt die Ursache, die gemessene Zeit und die Regionen:

Response time 2 340 ms is above the 1 500 ms threshold (Paris, Frankfurt)

Die E-Mail zeigt Ihre Schwelle statt der standardmäßigen 2 s. Ein Webhook erhält das Ereignis monitor.degraded mit vier zusätzlichen Feldern, damit ein Empfänger Langsamkeit getrennt von Ausfällen behandeln kann:

{
  "event": "monitor.degraded",
  "monitor": { "name": "API", "url": "https://api.example.com" },
  "region": "fr-dc3",
  "timestamp": "2026-10-17T08:12:44.000Z",
  "reason": "latency_threshold",
  "latencyMs": 2340,
  "thresholdMs": 1500,
  "slowRegions": ["fr-dc3", "de-fra"]
}

Statusseiten

Standardmäßig ist Langsamkeit öffentlich: Ein langsamer Monitor erscheint auf den Statusseiten, die ihn zeigen, als beeinträchtigt (bernsteinfarben) — Ihre Nutzer spüren es, die Seite sagt es.

Deaktivieren Sie Langsamkeit auf Statusseiten anzeigen unter der Schwelle, um sie intern zu halten: Der Monitor erscheint dann auf öffentlichen Seiten als betriebsbereit, während Dashboard, Alarme und Monitorseite ihn weiterhin als beeinträchtigt zeigen. Ein Ausfall ist immer öffentlich, unabhängig von dieser Einstellung.

Verfügbarkeit und SLA bleiben unberührt

Eine langsame Prüfung ist eine erfolgreiche Prüfung. Sie zählt als up in der Verfügbarkeit in %, in Berichten und in SLA-Werten: Der Dienst hat geantwortet. Antwortzeit-Alarme betreffen die Qualität, nicht die Verfügbarkeit.

Auf der Monitorseite

Das Antwortzeit-Diagramm zeigt die Schwelle als gestrichelte bernsteinfarbene Linie, damit Sie sehen, wie nah Ihre Prüfungen daran liegen.

Ohne Schwelle

Ein Monitor ohne Schwelle (Aus) sendet nie einen Antwortzeit-Alarm. Listen und Prüfverlauf zeigen ihn dennoch als Langsam (bernsteinfarben), wenn seine letzte Prüfung 2 Sekunden oder länger gedauert hat — nur als visueller Hinweis.

Abnormale Latenz (Max und Enterprise)

Eine feste Schwelle erkennt nur, wofür Sie sie eingestellt haben. Ein Dienst, der sonst in 180 ms antwortet und jetzt 600 ms braucht, hat ein Problem, bleibt aber unter einer Schwelle von 1 s. Aktivieren Sie Abnormale Latenz unter der Schwelle, und OKStatus achtet auch darauf.

Was gelernt wird: pro Region das stündliche p95 der letzten 28 Tage, zur gleichen Stunde am gleichen Wochentag — Montag 9 Uhr ist nicht Sonntag 3 Uhr. Der übliche Bereich reicht vom 10. bis zum 90. Perzentil dieser Werte. Bei zu wenigen Wochen weicht er auf dieselbe Stunde an allen Tagen aus, dann auf alle Stunden.
Lernphase: Alarme starten nach 7 Tagen Verlauf. Das Formular zeigt den Fortschritt („Lernphase: 3 von 7 Tagen · Alarme aktiv ab …“) und danach den üblichen Bereich zu dieser Stunde.
Wann alarmiert wird: Alle 5 Minuten wird das p95 der letzten 15 Minuten (mindestens 3 erfolgreiche Prüfungen) mit der Obergrenze des üblichen Bereichs verglichen. Abnormal ist es, wenn es mehr als das 1,5-Fache dieser Grenze und mehr als 100 ms darüber liegt. 3 Auswertungen in Folge (etwa 15 Minuten) senden einen Degraded-Alarm; 2 Auswertungen zurück im Bereich schließen ihn, und die Entwarnung wird gesendet, wenn nichts anderes den Vorfall offen hält.
Was er sagt: „p95 response time 640 ms over 15 min (Paris) is 2.3× the usual 150–280 ms at this hour“. Die E-Mail heißt langsamer als üblich; der Webhook enthält "reason": "latency_anomaly", latencyMs (das p95 über 15 Minuten), usualMs (low, high) und slowRegions.
Was er nicht tut: Er ändert weder den Status des Monitors noch seine Verfügbarkeit und sendet nie einen zweiten Alarm, solange ein Vorfall offen ist — er hält diesen Vorfall nur offen, bis die Antwortzeit wieder im üblichen Bereich liegt.

Auf der Monitorseite zeigt das Antwortzeit-Diagramm den üblichen Bereich als cyanfarbenes Band hinter der Linie der ersten Region.

Unter Max ist die Option sichtbar, aber gesperrt, mit einem Link zu den Tarifen. Wechselt die Organisation in einen kleineren Tarif, enden die Auswertungen, und eine offene Anomalie wird nach spätestens 15 Minuten freigegeben.

API, Terraform und MCP

Einstellung	Feld in REST-API und MCP	Terraform-Attribut
Schwelle (ms, `null` = aus)	`latencyThresholdMs` / `latency_threshold_ms`	`latency_threshold_ms`
Langsamkeit auf Statusseiten anzeigen	`latencyPublic` / `latency_public`	`latency_public`
Abnormale Latenz (Max und Enterprise)	`latencyAnomaly` / `latency_anomaly`	`latency_anomaly`

Siehe Monitors-API, den Terraform-Provider und den MCP-Connector.