Vorfälle

Ein Vorfall steht für ein laufendes Problem mit einem deiner überwachten Dienste. Hoppla erstellt Vorfälle automatisch, wenn Checks fehlschlagen, und löst sie genauso automatisch wieder, sobald alles läuft.

Lebenszyklus eines Vorfalls

Jeder Vorfall durchläuft einen klaren Ablauf:

1. Erstellt -- Ein Check hat einen Fehler entdeckt. Benachrichtigungen gehen an deine konfigurierten Kanäle raus.
2. Bestätigt (optional) -- Jemand aus deinem Team hat den Vorfall bestätigt. Heißt konkret: "Ich hab's gesehen, ich kümmere mich." Wiederholte Benachrichtigungen stoppen dann.
3. Gelöst -- Der Check ist wieder grün (oder jemand hat den Vorfall manuell geschlossen). Eine Entwarnung geht raus.

Jede Statusänderung wird mit Zeitstempel festgehalten und in der Vorfall-Timeline angezeigt.

Automatische Erstellung

Hoppla legt automatisch Vorfälle an, wenn folgende Check-Typen Fehler erkennen:

• Uptime -- HTTP-Fehler oder Timeouts (vorher nochmal von einem zweiten Standort verifiziert).
• SSL -- Abgelaufene oder ungültige Zertifikate.
• DNS -- DNS-Auflösung fehlgeschlagen.
• Cron-Monitore -- Erwarteter Heartbeat-Ping ist ausgeblieben.
• Agent-Monitore -- Agent-Heartbeat ist ausgeblieben.
• Application Health -- Health-Endpoint meldet ungesunden Status.

Wichtig: Pro Monitor gibt es immer nur einen offenen Vorfall. Wenn ein Monitor bereits einen offenen Vorfall hat und erneut fehlschlägt, aktualisiert Hoppla den bestehenden Vorfall, statt ein Duplikat zu erstellen.

Automatische Lösung

Sobald ein zuvor fehlerhafter Check wieder erfolgreich ist, löst Hoppla den offenen Vorfall automatisch. Dabei wird festgehalten:

• Der Zeitpunkt der Wiederherstellung.
• Die gesamte Vorfalldauer.
• Eine Entwarnung, die über dieselben Kanäle geht wie der ursprüngliche Alarm.

Empfindlichkeit und Feinabstimmung

Hoppla ist bewusst so gebaut, dass es dich bei kurzen Aussetzern nicht sofort piept. Zwischen einem einzelnen fehlgeschlagenen Check und einem Alarm in deinem Postfach liegen mehrere Schichten -- und jede davon lässt sich pro Monitor einstellen.

Doppelte Verifizierung (Uptime)

Ein fehlgeschlagener Uptime-Check wird sofort von einem zweiten Standort erneut ausgeführt, bevor er überhaupt zählt. Ein Fehler, der nur an einem Standort auftritt, gilt als lokale Störung in der Nähe dieses Standorts -- nicht als Ausfall -- und löst nie einen Vorfall aus. (Self-hosted-Installationen mit nur einem Standort werden von hoppla:doctor gewarnt, weil die "zweite Meinung" dann vom selben Ort kommt.)

Bestätigungsschwelle -- wie schnell ein Vorfall entsteht

Ein Vorfall entsteht erst nach confirmation_threshold aufeinanderfolgenden bestätigten Fehlern (Standard 2). Ein einzelner fehlgeschlagener Check löst nie einen Vorfall aus.

Benachrichtigungs-Karenz -- Aussetzer unter einer Minute bleiben still

Wenn ein Vorfall entsteht, wird die ausgehende Benachrichtigung für alert_grace_seconds zurückgehalten (Standard 60). Der Vorfall wird sofort erfasst (sichtbar im Dashboard und auf der Statusseite), aber wenn sich der Check innerhalb des Karenzfensters erholt, geht weder eine Ausfall- noch eine Entwarnungs-Mail raus -- ein 30-Sekunden-Aussetzer landet also nie in deinem Postfach. Setz den Wert auf 0, um sofort beim Entstehen eines Vorfalls gepiept zu werden.

Wiederherstellungsschwelle -- wie ein Vorfall gelöst wird

Ein offener Vorfall wird erst nach recovery_threshold aufeinanderfolgenden erfolgreichen Checks gelöst (Standard 2). Diese Hysterese verhindert, dass ein einzelner glücklicher Treffer mitten in einer instabilen Phase einen Vorfall vorzeitig schließt, der dann sofort wieder aufgeht.

Flattern -- eine Benachrichtigung statt eines Sturms

Wenn ein Monitor wiederholt zwischen up und down hin- und herspringt (3 oder mehr Wechsel zwischen up und down innerhalb von 10 Minuten), erkennt Hoppla das als Flattern: Es unterdrückt die einzelnen Vorfall-/Entwarnungs-Alarme und schickt stattdessen eine einzige "Monitor flattert"-Benachrichtigung. Warnungen zählen nicht mit: Eine langsame Antwort oder ein Weiterleitungsbefund, der kommt und geht, bleibt eine Warnung. Sobald sich der Monitor 5 Minuten lang stabil hält, ist das Flattern vorbei und mit dem nächsten Check geht eine "Flattern beendet"-Nachricht raus. Genau das verhindert, dass ein instabiles Ziel dein Postfach mit Pärchen aus Ausfall-/Wieder-up-Mails flutet.

Cooldown -- wiederholte Alarme drosseln

cooldown_seconds (Standard 0, aus) legt einen Mindestabstand zwischen Benachrichtigungen für denselben Monitor fest -- unabhängig von Statuswechseln.

Schwellenwerte anpassen

All das ist pro Monitor einstellbar und lebt unter Monitor → Benachrichtigungen im Dashboard (oder im notification_settings-Objekt der Monitor-API):

Einstellung	Standard	Bereich	Wirkung
Bestätigungsschwelle	2	1–10	aufeinanderfolgende Fehler, bevor ein Vorfall entsteht
Wiederherstellungsschwelle	2	1–10	aufeinanderfolgende Erfolge, bevor ein Vorfall gelöst wird
Alarm-Karenz (Sekunden)	60	0–3600	hält die Ausfall-Benachrichtigung zurück; Aussetzer unter der Karenz piepen nie
Cooldown (Sekunden)	0	0–86400	Mindestabstand zwischen wiederholten Benachrichtigungen

Beispiele zur Feinabstimmung

• Beim ersten Fehler piepen (ein kritischer Dienst, bei dem jede Sekunde zählt): Bestätigungsschwelle 1, Alarm-Karenz 0.
• Nur anhaltende Ausfälle sollen piepen (ein lauter oder Edge-Dienst, der oft kurz aussetzt): erhöh die Alarm-Karenz auf 120 und die Wiederherstellungsschwelle auf 3, damit kurze Instabilität still ausgesessen wird.

Die Standardwerte sind so gewählt, dass ein echter mehrminütiger Ausfall trotzdem zügig piept, ein Aussetzer unter einer Minute oder ein flatterndes Ziel aber nicht. Senk die Schwellen für latenzempfindliche Dienste; erhöh sie für laute.

Manuelle Aktionen

Auf der Vorfall-Detailseite kannst du (und dein Team):

• Bestätigen -- Markiert den Vorfall als "gesehen". Wiederholte Eskalations-Benachrichtigungen stoppen, während du das Problem untersuchst. Der Vorfall bleibt offen, bis der Check wieder grün ist oder du ihn manuell schließt.
• Schlummern / Schlummern beenden (Snooze) -- Unterdrückt wiederholte Benachrichtigungen für diesen Vorfall vorübergehend bis zu einem von dir gewählten Zeitpunkt. Funktioniert wie das Bestätigen, ist aber zeitlich begrenzt -- bei geschlummerten Vorfällen pausieren die wiederholten Benachrichtigungen, die Entwarnung geht aber trotzdem raus, sobald der Check sich erholt. Du kannst das Schlummern jederzeit beenden, um Benachrichtigungen sofort wieder zu aktivieren.
• Archivieren / Wiederherstellen -- Schiebt einen gelösten oder alten Vorfall aus der aktiven Liste, damit deine Vorfall-Ansicht übersichtlich bleibt. Archivierte Vorfälle lassen sich jederzeit wieder zurückholen.
• Notizen hinzufügen -- Häng Freitextnotizen an die Timeline an. Praktisch, um festzuhalten, was du herausgefunden hast, was du getan hast oder um Kontext fürs Team zu liefern.

Vorfall-Detailseite

Die Detailseite zeigt dir alles Wichtige zu einem Vorfall:

• Ursache -- Was den Vorfall ausgelöst hat (z. B. "HTTP 503 Service Unavailable", "Certificate expired", "Ping not received").
• Dauer -- Wie lange der Vorfall gedauert hat (oder noch andauert).
• Timeline -- Chronologisches Protokoll aller Statusänderungen (erstellt, bestätigt, Notizen, gelöst) mit Zeitstempeln.
• Betroffener Monitor -- Link zum Monitor, der den Vorfall ausgelöst hat.
• Benachrichtigungsprotokoll -- Welche Benachrichtigungen rausgegangen sind, an welche Kanäle und wann.