Incident Management
So funktioniert Incident Management: Alarmquellen, Routing, Teams, Bereitschaftspläne, Eskalation, Benachrichtigungen, Statusseiten und Berichte, und wie du es einrichtest.
Incident Management (IM) macht aus Alarmen Incidents und sorgt dafür, dass die richtige Person geweckt wird. Es arbeitet neben dem Monitoring: Uptimeifys eigene Checks sind eine Alarmquelle unter mehreren (Zabbix, Datadog, Grafana, Prometheus, Sentry, E-Mail, dein eigener Webhook oder Code).
Alles hier Beschriebene geht auch über die Incident-Management-API.
Wer es nutzen kann
Mitglieder der Organisation mit der Rolle admin, editor oder responder. Kunden-Logins (readonly) haben keinen Zugriff. Innerhalb eines Teams darf jedes Mitglied (Teamrolle admin, member oder stakeholder) an den Incidents dieses Teams arbeiten; Team-Admins dürfen zusätzlich das Team selbst ändern. Organisations-Admins dürfen beides für jedes Team.
Einrichten
- Aktiviere Incident Management für deine Organisation (Organisations-Admin). Im Dashboard: Incidents. API: Aktivieren.
- Lege ein Team an und füge seine Mitglieder hinzu (Incidents → Teams).
- Lege einen Bereitschaftsplan für das Team an: wer wann Bereitschaft hat und wie die Rotation weiterläuft.
- Baue die Eskalationskette des Teams: Stufe 1 wird zuerst alarmiert; jede Stufe hat ihre Pläne und bestimmt, wann der Incident zur nächsten Stufe weitergeht.
- Verbinde eine Alarmquelle (Incidents → Quellen): Vorlage wählen, Ingest-URL in dein Tool kopieren. Die Einrichtungsanleitungen behandeln jedes Tool.
- Stelle deine eigenen Benachrichtigungen ein (Incidents → Benachrichtigungen): wie und nach welcher Zeit du erreicht wirst, und bestätige deine Telefonnummer für SMS und Anrufe.
- Schick einen Test-Alarm, um zu prüfen, dass die Alarmierung dich erreicht.
Vom Alarm zum Incident
- Ein Alarm ist ein einzelnes Signal einer Quelle. Alarme mit demselben Deduplizierungsschlüssel gehören zusammen, damit ein flatternder Check nicht zehn Incidents öffnet.
- Ein Incident bündelt Alarme und ist das, woran Menschen arbeiten. Er hat einen Schweregrad (
sev1am schwersten bissev4) und einen Status:triggered(noch niemand hat reagiert),acknowledged,investigating,identified,monitoringund am Enderesolved(odermergedin einen anderen Incident). - Routing-Regeln bestimmen, welches Team einen neuen Incident bekommt, etwa nach Quelle oder Kunde, und können seinen Schweregrad überschreiben. Passt keine Regel, übernimmt das Team der Alarmquelle.
- Die Monitoring-Brücke (Organisationseinstellungen) übernimmt Incidents aus Uptimeifys eigenen Checks automatisch in Incident Management.
Bereitschaft und Eskalation
- Ein Bereitschaftsplan legt Rotationen fest: wer Schicht hat und wann die Schicht übergeben wird.
- Eine Vertretung ersetzt den Plan für einen Zeitraum: Jemand übernimmt eine Schicht oder gibt sie ab, solange er nicht verfügbar ist.
- Die Eskalationskette alarmiert zuerst Stufe 1. Bestätigt niemand innerhalb der Zeit der Stufe, wird die nächste Stufe alarmiert. Eine Stufe kann vorher erneut alarmiert werden, und die ganze Kette kann sich wiederholen.
- An einem Incident kannst du bestätigen (stoppt die Eskalation), snoozen (Eskalation und Erinnerungen bis zu 7 Tage pausieren), sofort eskalieren (nächste Stufe sofort alarmieren), Responder hinzufügen, kommentieren, Schweregrad ändern, Duplikate zusammenführen und lösen.
Wie du benachrichtigt wirst
Jede Person bestimmt selbst, wie sie erreicht wird:
- Kanäle: Push (Mobile App), SMS, Anruf, E-Mail. SMS und Anruf brauchen eine bestätigte Telefonnummer.
- Regeln je Dringlichkeit: zum Beispiel „Push sofort, SMS nach 5 Minuten, Anruf nach 10 Minuten“.
- Schweregrad-Filter: zum Beispiel keine SMS und keine Anrufe für
sev4. - Das Benachrichtigungsprotokoll zeigt jede Benachrichtigung, die für dich gesendet, übersprungen oder nicht zugestellt wurde.
Gemeinsame Kanäle (Webhook, Slack, E-Mail) gehören der Organisation oder einem Team. Einer davon kann der Fallback-Kanal sein: die letzte Stelle, wenn einer Eskalation die Stufen ausgehen.
Details: Persönliche Benachrichtigungseinstellungen, Kanäle.
Statusseiten und andere Tools
- Statusseiten-Regeln schalten eine Statusseite auf Warnung oder beeinträchtigt, solange ein Team offene Incidents eines bestimmten Schweregrads hat, mit manueller Übersteuerung.
- Ausgehende Integrationen leiten Incident-Ereignisse an Slack, Microsoft Teams, Discord, Jira, PagerDuty, Opsgenie oder einen allgemeinen Webhook weiter. Fehlgeschlagene Zustellungen lassen sich einsehen und wiederholen.
Berichte und Audit
- Analytics: Incident-Menge, MTTA und MTTR pro Tag, das Verhältnis von Alarmen zu Incidents und die Bereitschaftslast pro Person.
- Berichte: Incident-Bericht (nach Team, Schweregrad oder Monat) und Bereitschaftsbericht (Minuten pro Person), auch als CSV.
- Audit-Log (Organisations-Admins): wer was in Incident Management geändert hat.
API
Für jeden Schritt oben gibt es einen Endpunkt: Incident-Management-API. Die meisten Endpunkte akzeptieren einen organisationsweiten API-Token; persönlicher Bereitschaftsstatus und Benachrichtigungseinstellungen brauchen eine Benutzersitzung.
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.
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.