Issue beim bestätigten Ausfall anlegen
Das Issue entsteht, 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 GitHub Issues nutzen.
Ein fein granulares Token und ein Repository-Name, und ein bestätigter Ausfall wird zum Issue dort, wo der Code der Seite ohnehin liegt.
Was in GitHub ankommt
Was die Alarmkette in GitHub anlegt, steht hier vollständig, und mehr passiert nicht. Einmal lesen, und du weißt, was dein Team sehen wird.
Entwarnung als eigenes Issue ablegen
Die Entwarnung kommt als zweites Issue, mitsamt Zeitpunkt der Behebung und der Dauer des Ausfalls in Minuten.
Jedes Issue beschriften
Jedes Issue entsteht mit den Labels uptimeify und monitoring, damit ein Filter oder eine Automation sie im Backlog findet.
Lesbaren Text schreiben
URL, Kunde, Organisation, der Fehler samt Statuscode, die prüfenden Standorte und die Zeiten kommen als Markdown-Liste an.
Kritisches Zertifikat melden
Ein TLS-Zertifikat, das in seinen kritischen Bereich rutscht, öffnet ein eigenes Issue in dem Repository, das die Seite ausliefert.
Mit GitHub Enterprise arbeiten
Eine selbst betriebene Instanz wird über ihre eigene API-Basis-URL angesprochen, die https sein muss, und sonst wie github.com behandelt.
Ein Repository je Kunde
Jeder Kanal benennt sein eigenes Repository, damit der Ausfall eines Kunden dort landet, wo dessen Betreuer ohnehin mitlesen.
Test-Issue anlegen
Das Dashboard erzeugt beim Einrichten ein als TEST markiertes Issue, damit ein falscher Repository-Name vor dem ersten Ausfall auffällt.
Nach dem engsten Token fragen
Ein fein granulares Token mit Lese- und Schreibrecht auf Issues genügt, und es liegt verschlüsselt statt im Klartext.
Teams, die ihr Monitoring über Uptimeify fahren
In Minuten eingerichtet. Danach läuft es von allein.
1. Fein granulares Token anlegen
Unter Settings und Developer settings ein Fine-grained Personal Access Token mit Lese- und Schreibrecht auf Issues erstellen.
Personal access token
github_pat_11ABC...Verschlüsselt gespeichert
2. Repository benennen
Das Repository als owner/repo eintragen, das Token einfügen und bei GitHub Enterprise die API-Basis-URL ergänzen.
3. Speichern und testen
Die Monitore zuordnen, die der Kanal abdeckt, und das Test-Issue anlegen, damit der erste echte Ausfall nicht der erste Versuch ist.
Bevor du GitHub verbindest.
Nein. Die Entwarnung wird als eigenes Issue abgelegt, statt das erste zu schließen. Das Ausfall-Issue behält damit Historie und Kommentare, und beide tragen das Label uptimeify, was einer Action zum Schließen reicht.
Lesen und Schreiben auf Issues, in genau dem Repository, das du benennst. Ein so eng gefasstes Fine-grained Token kommt an deinen Code nicht heran, und es liegt verschlüsselt.
Ja. Trage die API-Basis-URL deiner Instanz neben dem Repository ein. Akzeptiert wird nur https, sonst sieht die Anfrage genauso aus wie die an github.com.
Nein. Deine Quota deckt Monitore und das monatliche SMS- und Sprachkontingent. Issues in GitHub, GitLab oder Jira zehren nicht daran.
Nein. Das Issue entsteht zum bestätigten Ausfall, nicht je fehlgeschlagener Anfrage, und wie viele Nachprüfungen die Bestätigung braucht, legst du je Paket fest.
Jeder Alarm dort, wo dein Team ohnehin arbeitet.
GitHub einmal verbinden, und jeder bestätigte Ausfall landet als Issue in dem Repository, das die Seite ausliefert.