Uptimeify Docs

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 noch
  • resolved: 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, ssl_handshake
  • 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

ssl_handshake: der Server hat den TLS-Handshake abgebrochen (z.B. mit einem internal_error-Alert) und nie eine sichere Verbindung zustande gebracht. Die Website ist über HTTPS nicht erreichbar.

Wie Zertifikatsprobleme eingestuft werden

Ein Zertifikatsproblem ist nur so lange eine Warnung, wie Besucher die Website noch erreichen. Sobald ein Browser das Zertifikat ablehnt, ist die Website nicht mehr erreichbar, und der Vorfall wird wie jeder andere Ausfall behandelt:

  • downtime bedeutet, dass das Zertifikat aktuell abgelehnt wird: es ist abgelaufen, wurde widerrufen, oder ein echter Browser hat die Seite verweigert (z.B. net::ERR_CERT_COMMON_NAME_INVALID bei einem Hostnamen, für den das Zertifikat nicht gilt). Besucher sehen eine ganzseitige Warnseite statt Ihrer Website, das ist ein Ausfall und alarmiert mit kritischem Schweregrad. Die Fehlermeldung am Vorfall nennt weiterhin die Zertifikatsursache.
  • ssl_expiry, das Zertifikat ist noch gültig, hat aber die kritische Schwelle vor dem Ablauf erreicht. Noch wird niemand blockiert; das ist eine Warnung.
  • ssl_warning, ein Zertifikatsproblem, bei dem wir nicht nachweisen konnten, dass Besucher blockiert werden. Ebenfalls eine Warnung.

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-SituationStatusseiten-state
Keine offenen Vorfälleoperational
Nur SSL-Warnung-Vorfälle offenwarning
Jeder andere offene Vorfall (downtime, http_status, performance, …)degraded
Aktives Wartungsfenster, keine offenen Vorfällemaintenance

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.

Auf dieser Seite