Incident erstellen
Manchmal weißt du von einem Problem, bevor die automatische Erkennung anschlägt -- oder du möchtest proaktiv kommunizieren. So erstellst du manuell einen Incident.
Schritt für Schritt
- Klicke in der Seitenleiste auf "Vorfälle"
- Klicke auf "Vorfall erstellen"
- Fülle das Formular aus:
- Titel: Kurze, aussagekräftige Beschreibung (z.B. "API-Antwortzeiten erhöht") -- je Sprache pflegbar
- Schweregrad: Gering, Erheblich oder Kritisch
- Status: Untersuchung, Identifiziert, Überwachung oder Behoben
- Nachricht: Beschreibe, was passiert und was du unternimmst -- ebenfalls je Sprache pflegbar
- Betroffene Services: Wähle die betroffenen Services aus
- Ziel-Statuspage(s): Auf welchen deiner Statuspages der Incident erscheinen soll
- Komponenten-Status: Pro betroffener Komponente ein Impact-Status (betriebsbereit, beeinträchtigt, teilweiser Ausfall oder größerer Ausfall)
- Abonnenten benachrichtigen: Sollen Statuspage-Abonnenten informiert werden?
- Klicke auf "Vorfall erstellen"
Mehrsprachige Incidents
Titel und Nachricht sind übersetzbar: Pflegst du deine Statuspage in mehreren Sprachen, kannst du beide je Sprache hinterlegen. Besucher sehen den Incident dann automatisch in ihrer bevorzugten Sprache -- fehlt eine Übersetzung, wird die Standardsprache angezeigt.
Aus Vorlage erstellen
Für häufige Szenarien kannst du Incident-Vorlagen anlegen -- das spart wiederholtes Ausfüllen und sorgt für einheitliche Kommunikation.
Veröffentlichen oder als Entwurf speichern
Nicht jeder Incident muss sofort öffentlich sein:
- Als Entwurf speichern: Nur intern sichtbar, taucht nicht auf der Statuspage auf. Hilfreich, um die Situation erst intern zu klären.
- Veröffentlichen: Der Incident und alle Updates erscheinen auf deiner Statuspage.
Du kannst den Status jederzeit wechseln: "Veröffentlichen" macht einen Entwurf sichtbar, "Als Entwurf setzen" verbirgt einen Incident wieder. Beliebig oft -- veröffentliche erst, wenn du bereit bist.
Den richtigen Schweregrad wählen
| Schweregrad | Wann verwenden? | Beispiele |
|---|---|---|
| Gering | Kleine Einschränkungen, der Service ist nutzbar | Leicht erhöhte Ladezeiten, einzelne Funktionen langsam |
| Erheblich | Deutliche Beeinträchtigung, wichtige Funktionen betroffen | Login nicht möglich, E-Mail-Versand verzögert, API-Fehler bei bestimmten Endpunkten |
| Kritisch | Komplettausfall, nichts funktioniert mehr | Website nicht erreichbar, alle API-Anfragen schlagen fehl, Datenverlust möglich |
Im Zweifel höher einstufen
Besser etwas höher einstufen und Entwarnung geben, als zu niedrig einordnen und Kunden überraschen. Transparenz schafft Vertrauen.
Den richtigen Status wählen
Meist startest du mit Untersuchung und arbeitest dich durch die Stufen:
| Status | Wann wählen? |
|---|---|
| Untersuchung | Es gibt ein Problem, aber die Ursache ist noch unklar |
| Identifiziert | Du hast die Ursache gefunden und weißt, was zu tun ist |
| Überwachung | Du hast eine Lösung angewendet und beobachtest, ob sie wirkt |
| Behoben | Das Problem ist gelöst und der Service funktioniert wieder |
Jeder Statuswechsel erzeugt einen Timeline-Eintrag. Mit aktiviertem "Abonnenten benachrichtigen" erhalten deine Statuspage-Abonnenten bei jedem Update eine Benachrichtigung.
Betroffene Services zuordnen
- Auswählen: Jeder Service zeigt seinen aktuellen Monitoring-Status zur besseren Einschätzung
- Später anpassen: Services lassen sich auch nach dem Erstellen hinzufügen oder entfernen
- Einzeln wiederherstellen: Funktioniert ein Service wieder, markierst du ihn als "Wiederhergestellt", ohne den ganzen Incident zu schließen
Auswirkung auf Statuspage
Bei einem veröffentlichten Incident werden die betroffenen Services auch auf deiner Statuspage angezeigt. Kunden sehen sofort, welche Dienste betroffen sind.
SLA-relevant? (nur Business)
Hast du Services ausgewählt und nutzt du SLA-Monitoring, erscheint zusätzlich die Option „Zählt als SLA-Ausfallzeit". Manuell erstellte Vorfälle sind zunächst reine Kommunikation -- nur mit diesem Opt-in fließt ihr Zeitfenster in die SLA-Berechnung ein. Automatisch erkannte Vorfälle zählen ohnehin immer.
Ziel-Statuspages und Komponenten-Status
Betreibst du mehrere Statuspages, wählst du beim Erstellen, auf welchen der Incident erscheinen soll. Zusätzlich kannst du pro betroffener Komponente einen eigenen Impact-Status setzen -- so signalisierst du differenziert, wie stark ein einzelner Baustein betroffen ist:
| Impact-Status | Bedeutung |
|---|---|
| Betriebsbereit | Komponente läuft normal |
| Beeinträchtigt | Eingeschränkte Leistung, aber nutzbar |
| Teilweiser Ausfall | Teile der Komponente sind nicht verfügbar |
| Größerer Ausfall | Komponente ist komplett ausgefallen |
Tipps für gute Incident-Kommunikation
- Transparent und verständlich: Schreibe für nicht-technische Leser. Statt "Datenbankcluster-Failover verursacht erhöhte Latenz" lieber "Teile unserer Infrastruktur haben Probleme, was zu langsameren Ladezeiten führt."
- Zeiteinschätzungen geben: Teile eine Schätzung, auch wenn sie ungenau ist -- "Wir rechnen mit einer Lösung innerhalb der nächsten Stunde" ist besser als Schweigen.
- Regelmäßig aktualisieren: Auch ohne Neuigkeiten zeigt ein kurzes "Wir arbeiten weiter an der Lösung", dass du dran bist.
- Klar abschließen: Erkläre bei der Auflösung kurz, was passiert ist. Bei größeren Incidents empfehlen wir ein Postmortem.
Stille ist das Schlimmste
Nichts verunsichert Kunden mehr als Funkstille während einer Störung. Lieber ein kurzes "keine Neuigkeiten" als gar kein Update.
Weiterführende Themen
- Incident verwalten -- Updates posten, kommentieren und auflösen
- Incident-Vorlagen -- Vorlagen für wiederkehrende Szenarien
- Incidents verstehen -- Schweregrade und Status-Verlauf im Überblick
- Postmortems -- Nach dem Incident: Ursachen dokumentieren
- Statuspages -- Incidents auf deiner Statuspage veröffentlichen
- SLA-Monitoring -- Ausfallzeiten gegen Verfügbarkeitsziele messen (Business)