Vorfall beim bestätigten Ausfall auslösen
Der Trigger geht raus, sobald genug unabhängige EU-Standorte den Check oft genug hintereinander abweisen, nicht schon bei der ersten fehlgeschlagenen Anfrage; beide Schwellen stehen in deinem Paket.
Uptimeify mit SolarWinds Incident Response nutzen.
Ein Incident-Webhook am Service, und ein bestätigter Ausfall alarmiert die Bereitschaft in SolarWinds Incident Response, wozu Squadcast geworden ist, und schließt sich selbst, sobald die Seite wieder läuft.
Was in SolarWinds Incident Response ankommt
Was die Alarmkette an SolarWinds Incident Response schickt, steht hier vollständig, und mehr passiert nicht. Einmal lesen, und du weißt, was dein Team sehen wird.
Automatisch auflösen
Die Erholung schickt resolve mit derselben Event-ID, damit niemand einen Vorfall schließt, der längst erledigt ist.
Über die Event-ID zusammenfassen
Die ID ist je Vorfall stabil, ein erneutes Ereignis ergänzt also den bestehenden Vorfall statt einen weiteren auszulösen.
Den Incident-Webhook sprechen
Die Nutzlast ist das, was die Incident-Webhook-API liest, die Integration läuft mit der URL allein und ohne weitere Einstellung.
Sagen, was wirklich kaputt ist
Die Meldung trägt Seite und Zustand, die Beschreibung den Fehler samt Statuscode, Antwortzeit und prüfenden Standorten.
Vor ablaufenden Zertifikaten und Domains warnen
Auslaufende TLS-Zertifikate, ablaufende Domains und Einträge auf Blocklisten lösen genauso eigene Vorfälle aus und schließen sie wieder.
Ein Service je Kunde
Jeder Kanal ist ein eigener Webhook, damit der Ausfall eines Kunden den Service alarmiert, für den dessen Team bereitsteht.
Testvorfall senden
Das Dashboard feuert beim Einrichten einen Test, damit eine falsche Webhook-URL vor der ersten echten Alarmierung auffällt.
Webhook-URL verschlüsselt halten
Die URL trägt das Token in sich, liegt deshalb verschlüsselt und wird vor dem Aufruf gegen interne Ziele geprüft.
Teams, die ihr Monitoring über Uptimeify fahren
In Minuten eingerichtet. Danach läuft es von allein.
1. Ziel-Service öffnen
In SolarWinds Incident Response die Services öffnen, Team und den zu alarmierenden Service wählen und eine Alarmquelle hinzufügen.
Webhook URL
api.squadcast.com/v2/incidents/api/xxxxVerschlüsselt gespeichert
2. Incident-Webhook wählen
In der Liste der Alarmquellen nach Incident Webhook suchen und die erzeugte URL samt Token kopieren.
3. URL in Uptimeify hinterlegen
Die URL als Squadcast-Kanal anlegen, die Monitore zuordnen und den Testvorfall senden.
Bevor du SolarWinds Incident Response verbindest.
Ja. Die Erholung schickt resolve mit derselben Event-ID wie der Trigger. SolarWinds Incident Response schließt damit genau den Vorfall, den es geöffnet hat, statt eine tote Alarmierung stehen zu lassen.
Nein. Die Event-ID ist je Vorfall stabil, wiederholte Ereignisse landen also auf demselben Vorfall. Wie viele Nachprüfungen ein Ausfall braucht, bis er als bestätigt gilt, legst du je Paket fest.
Ja. Jeder Kanal ist ein eigener Webhook, und du ordnest ihm Monitore und Kunden zu. Der Ausfall eines Kunden alarmiert damit den Service, für den dessen Team bereitsteht.
Nein. Deine Quota deckt Monitore und das monatliche SMS- und Sprachkontingent. Alarme über Squadcast, E-Mail, Webhook oder Slack zehren nicht daran.
Verschlüsselt in der Kanal-Konfiguration, denn die URL trägt das Token in sich. Zusätzlich wird sie vor jedem Senden aufgelöst und gegen interne sowie Loopback-Ziele geprüft.
Jeder Alarm dort, wo dein Team ohnehin arbeitet.
SolarWinds Incident Response einmal verbinden, und jeder bestätigte Ausfall alarmiert die Bereitschaft und schließt sich, sobald die Seite wieder läuft.