Vorfälle
Vorfälle werden automatisch erstellt, wenn das Monitoring ein Problem mit einer Website oder einem Service erkennt. Sie sind die Grundlage für Alarmierung, Reporting und die öffentlichen Statusseiten.
Wo Sie Vorfälle finden
- Vorfall-Übersicht:
/incidents - Pro Website / Monitor: Die meisten Detailseiten haben einen Tab mit der Vorfall-Historie
Vorfall-Lebenszyklus
Vorfälle haben zwei primäre Zustände:
open— das Problem besteht nochresolved— der Service hat sich erholt und der Vorfall wurde geschlossen (automatisch, sobald die Checks wieder bestehen)
Was ein Vorfall enthält
Je nach Check-Typ kann ein Vorfall enthalten:
- Typ / Schweregrad — z.B.
downtime,http_status,performance,ssl_warning,ssl_expiry - Start- / Lösungszeit
- HTTP-Statuscode (falls zutreffend)
- Antwortzeit (ms) (falls zutreffend)
- Fehlermeldung — Netzwerkfehler, Timeouts, Parsing-Fehler usw.
- Zeitstempel der letzten Benachrichtigung — für Benachrichtigungs-Erinnerungen
Vorfall-Details (Timeline & Beleg)
Öffnen Sie aus der Vorfall-Liste das Detail-Modal, um Folgendes zu sehen:
- Eine Timeline von Bestätigung → Ausfall → Wiederherstellung
- Den Beleg-Check (der Monitoring-Check, der als Nachweis diente)
- Einen optionalen Traceroute-Auszug
- Einen optionalen Screenshot (falls verfügbar)
Das beantwortet „Was genau ist passiert?" ohne Wühlen in Rohlogs.
Wie Vorfälle den Statusseiten-Status bestimmen
Wenn der Kunde eine öffentliche Statusseite hat, ändern offene Vorfälle den angezeigten Service-Status:
| Vorfall-Situation | Statusseiten-state |
|---|---|
| Keine offenen Vorfälle | operational |
| Nur SSL-Warnung-Vorfälle offen | warning |
| Jeder andere offene Vorfall (downtime, http_status, performance, …) | degraded |
| Aktives Wartungsfenster, keine offenen Vorfälle | maintenance |
Das Gesamt-Banner der Seite spiegelt den schwerwiegendsten Status über alle Services wider. Siehe Statusseiten → Wie der öffentliche Status abgeleitet wird.
Nicht eindeutige Checks (Browser-Verifizierungs-Timeouts)
Manche Seiten nutzen Bot-Schutz / Browser-Verifizierung, die in einen Timeout laufen kann. In diesen Fällen markiert Uptimeify einen Check als nicht eindeutig, statt ihn als vollständigen Ausfall zu werten — so erhalten Sie keine irreführenden „alles ist down"-Alarme und -Vorfälle durch eine Schutz-Challenge statt eines echten Ausfalls.
Design & Branding
Jede Statusseite hat eine visuelle Design-Konfiguration. Bearbeiten Sie sie in der App unter Dashboard → Statusseiten → (Seite) → Design oder über die Design-API. Änderungen werden zusammengeführt — Sie senden nur die Felder, die Sie ändern möchten, der Rest behält seine aktuellen Werte.
Wartung
Mit Wartungsfenstern planen Sie Arbeiten (Deployments, Updates, Migrationen), ohne störende Alarme auszulösen. Während eines aktiven Fensters gilt das betroffene Ziel als in Wartung — Alarme werden unterdrückt, und wenn der Kunde eine Statusseite hat, wird der Service als Wartung statt Beeinträchtigt angezeigt.