Reaktionszeitüberwachung

Warum die Antwortzeit einen eigenen Alarm verdient

Standardmäßige Uptime-Alarme basieren auf einem binären Signal: up oder down. Die Grauzone dazwischen – up, aber langsam – ist der Bereich, in dem die meisten modernen Störungen tatsächlich auftreten. Eine falsch konfigurierte Datenbankabfrage dauert plötzlich 4 Sekunden statt 50 ms. Ein Speicherleck verursacht Sprünge bei der Speicherbereinigung. Ein externes API, das das Backend aufruft, wird unzuverlässig. Keine dieser Dinge bringt die Seite komplett zum Stillstand, aber sie macht sie unbenutzbar – und all dies sind frühe Signale für einen Ausfall, der vielleicht erst in ein oder zwei Stunden auftritt.

Mit der Überwachung der Antwortzeit wird die Verlangsamung erkannt, bevor sie zum Ausfall führt. Du konfigurierst den Schwellenwert pro Monitor, und wenn die Antwortzeit ihn in mehreren aufeinanderfolgenden Prüfungen überschreitet, bekommst du einen Alarm. Bevor der Alarm ausgelöst wird, hast du noch Zeit, das Problem zu untersuchen, skalierst nach, drosselst die problematischen Aufrufe oder rollst ein fehlerhaftes Deployment zurück.

Wie funktionieren Schwellenwerte im DiagnoSEO Uptime Monitoring

Jeder Monitor kann mit zwei Parametern konfiguriert werden: rt_threshold_ms und rt_threshold_breaches. Ersterer ist die Antwortzeit in Millisekunden, die du für akzeptabel hältst. Der zweite gibt an, wie viele aufeinanderfolgende Prüfungen den Wert überschreiten müssen, damit ein Alarm ausgelöst wird. Standardmäßig ist der Schwellenwert deaktiviert und die Anzahl der Überschreitungen beträgt drei.

Das Zwei-Parameter-Design schützt vor False Positives. Netzwerk-Jitter kommt vor. Garbage-Collection-Pausen kommen vor. Ein einmaliger Sprung auf 1 Sekunde bei normalen 200 ms rechtfertigt keinen Pager-Einsatz um 3 Uhr morgens. Aber drei aufeinanderfolgende 1-Sekunden-Antworten schon – das ist eine anhaltende Verlangsamung, kein kurzer Ausreißer. Wähle den Schwellenwert auf Basis des beobachteten Verhaltens plus eines Komfortpuffers: wenn das p95 gewöhnlich 400 ms beträgt, dann setze den Schwellenwert auf 1000 ms. Wenn das p95 50 ms ist (internes API), dann 200 ms.

Mit welchen Signalen es sich gut kombinieren lässt

Antwortzeitalarme wirken am besten in Kombination mit anderen Monitor-Signalen. Das komplette Bild: Der Antwortzeitschwellenwert zeigt an, dass das System sich verschlechtert; der HTTP-Code sagt, wann es tatsächlich bricht; SSL-/Domain-Warnungen deuten auf zeitsensitive Ausfälle hin; DNS-Change-Alarme auf Konfigurationsdrift. Zusammen verwandeln diese vier Signale am selben Monitor das binäre "läuft oder nicht" in echte Observability.

Auch das Dashboard hilft hierbei. Jeder Monitor zeigt eine Sparkline der letzten Antwortzeiten – ein schneller visueller Hinweis auf Verschlechterungsmuster. Die erweiterte Ansicht zeigt Durchschnittswerte der Antwortzeiten für 24h, 7d und 30d. Wenn du siehst, dass der Durchschnitt Woche für Woche ansteigt – das ist ein frühes Warnsignal und sollte untersucht werden, bevor der Schwellenwert überschritten wird.

Praktische Schwellenwerte je Seitentyp

• Marketing-Landingpages: 1500 ms ist vernünftig. Sie sind in der Regel mit Bildern und Tracker-Skripten schwer beladen; absolute Geschwindigkeit ist weniger wichtig als Stabilität.
• Produktseiten/Kategorie-Seiten im E-Commerce: 800–1200 ms. Langsame E-Commerce-Seiten töten die Conversion – knappere Schwellenwerte erkennen Probleme schneller.
• App Dashboards: 500–800 ms. Nutzer erwarten Reaktionsfähigkeit. Langsame Dashboards lassen dein Produkt fehlerhaft erscheinen.
• Öffentliche APIs: 200–400 ms für einfache Endpunkte, mehr für rechenintensive. Entsprechend klassifizieren.
• Interne Microservice-Healthchecks: 50–100 ms. Sollten nahezu instantan sein; Langsamkeit deutet fast immer auf ein echtes Problem hin.

Egal wofür du dich entscheidest, wähle nicht einmal und vergiss es für immer. Bewerte die Schwellenwerte quartalsweise neu, basierend auf den tatsächlich beobachteten Trends. Wenn du ständig Schwellenwertalarme bekommst, die keine echten Probleme anzeigen – dann ist der Schwellenwert zu strikt. Wenn es zu Ausfällen ohne vorangegangenen Schwellenwertalarm kommt – dann war dein Schwellenwert zu großzügig.

Alert-Routing

Schwellenwertalarme werden über dieselben Kanäle gesendet wie Down/Recovery-Alarme: E-Mail, Telegram, Slack, Discord, SMS. Sie beachten die gleiche Nachtruhe. Sie werden in derselben Alarmtabelle protokolliert. Der einzige Unterschied ist der Ereignistyp ("threshold" statt "down") und der Nachrichtentext – er enthält die aktuelle Antwortzeit und den konfigurierten Schwellenwert, sodass du auf einen Blick siehst, wie stark die Überschreitung ausfällt.

Konfiguration

Bearbeite einen beliebigen Monitor. Im Formular stelle "Antwortzeitschwelle (ms)" auf den gewünschten Wert ein. Optional passe "aufeinanderfolgende Überschreitungen" an, falls der Standardwert 3 nicht zu deiner Toleranz passt. Speichern. Ab dem nächsten Zyklus vergleicht jede Prüfung die Antwortzeit mit der Schwelle und nach der eingestellten Anzahl an Überschreitungen erhältst du eine Benachrichtigung.

Häufig gestellte Fragen

• Welche Antwortzeitmetriken werden erfasst?

  Time To First Byte (TTFB) – Millisekunden zwischen dem Absenden der Anfrage und dem Empfang des ersten Bytes der Antwort. Plus die gesamte Zeit zum Herunterladen der vollständigen Antwort. TTFB ist die nützlichste Einzelmetrik für die Servergesundheit.

• Was ist eine „gute“ Antwortzeit?

  Das hängt vom Standort und dem Inhalt ab. Für eine statische Website mit CDN: unter 100 ms ist ausgezeichnet, unter 300 ms in Ordnung. Für dynamische Anwendungen: unter 500 ms ist OK, unter 1000 ms akzeptabel, über 2000 ms erscheint langsam. Vergleiche mit deiner eigenen Historie anstatt mit absoluten Werten.

• Kann ich eine Benachrichtigung erhalten, wenn die Antwortzeit den Schwellenwert überschreitet?

  Ja. Jeder Monitor hat einen optionalen Antwortzeitschwellenwert. Wenn drei aufeinanderfolgende Prüfungen die Schwelle überschreiten, erhältst du einen „Langsame Antwort“-Alarm. Die Vorgabe von 3 Checks verhindert Fehlalarme durch einzelne Netzaussetzer.

• Von wo aus wird die Antwortzeit gemessen?

  Von unseren 13 geografisch verteilten Prüfstandorten (Europa, Nordamerika, Asien, Südamerika, Ozeanien). Bei Single-Region-Monitoren stammen die Zeiten aus der nächstgelegenen Region. Bei Multi-Region wird jede Region unabhängig gemessen – nützlich um regionale CDN-Probleme aufzudecken.

• Zeigt das Dashboard Antwortzeittrends an?

  Ja – 30-tägiger gleitender Durchschnitt, tägliche Maxima/Minima und Perzentile (p50, p95). Nützlich für Kapazitätsplanung: Wenn das p95 innerhalb eines Monats von 800 ms auf 1500 ms ansteigt, sind deine Server überlastet, auch wenn das Uptime %-Ergebnis bei 100 % bleibt.