---
title: "Vorfälle"
description: "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](/status-pages) 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](/status-pages#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.