Incident Response vom Alarm bis zur Lösung. Ohne Telefonkette.
Jeder Vorfall landet beim zuständigen Team, wird mit einem Klick bestätigt und bekommt klare Rollen. Jeder Schritt steht in der Timeline, und deine Status-Seite zieht mit, damit dein Kunde informiert ist, bevor er anruft.
Entwickelt und gehostet in der
Europäischen Union
DSGVO-konformes Hosting
in Deutschland
Georedundantes Replikat
in der gesamten EU
Der Alarm landet beim richtigen Team. Nicht im Sammelpostfach.
Routing-Regeln entscheiden, welches Team einen neuen Vorfall bekommt: nach Quelle, Schweregrad, Kunde, Monitor, Tag oder einem beliebigen Feld im Alarm. Die erste passende Regel gewinnt. Greift keine, bleibt der Vorfall beim Team der Quelle. So muss morgens niemand sortieren, was nachts eingelaufen ist.
- Regeln mit Reihenfolge, damit die Datenbank-Alarme deines größten Kunden beim Backend-Team landen und nicht beim Frontend.
- Schweregrad beim Routing überschreiben: Ein „Warning" aus dem Shop eines Kunden wird zum Sev1, damit kritische Systeme nicht auf die Einschätzung des Tools angewiesen sind.
- Services mit Kritikalität und Owner: Jeder Vorfall kennt den betroffenen Dienst und das verantwortliche Team, damit Prioritäten nicht im Kopf einzelner Personen liegen.
Regeln werden nach aufsteigender priority (Standard 100) und dann nach id geprüft, die erste Übereinstimmung gewinnt. Alle Bedingungen einer Regel müssen passen: sourceIds, severity, customerIds, monitorIds (je bis zu 500), tags (bis zu 200, ohne Groß- und Kleinschreibung) und fieldMatches (bis zu 50 Schlüssel). Ein leeres {} passt auf alles. customerIds und monitorIds greifen nur bei Alarmen aus der Monitoring Bridge. severityOverride setzt sev1 bis sev4.
Services haben die Kritikalität critical, high, medium oder low und ein optionales Owner-Team. Öffnet die Monitoring Bridge einen Vorfall und gehört der Monitor genau einem Service, wird der Service automatisch gesetzt. Sonst ordnest du ihn von Hand zu.
Ein Vorfall, eine Akte.
Ein Klick auf Bestätigen oder die 4 am Telefon, und das Paging stoppt. Ab da sieht jeder im Team, wer übernommen hat, in welchem Stand der Vorfall ist und was bisher passiert ist. Untersuchen, Ursache gefunden, Beobachten, Gelöst: Jeder Schritt landet mit Uhrzeit und Person in der Timeline, die später auch die Nachbereitung trägt.
- Bestätigen stoppt die Eskalation, in der App oder per Taste am Telefon, damit nach der ersten Reaktion niemand mehr unnötig geweckt wird.
- Klare Rollen im Vorfall: Incident Commander, Tech Lead, Kommunikation und Bearbeiter, damit bei großen Ausfällen niemand doppelt arbeitet und niemand die Kundenkommunikation vergisst.
- Zusammenführen statt doppelt arbeiten: Melden zwei Tools denselben Ausfall, schlägt Uptimeify das Zusammenführen vor, damit dein Team an einem Vorfall arbeitet statt an zwei.
Offene Status sind triggered, acknowledged, investigating, identified und monitoring, abgeschlossen sind resolved und merged. POST /api/im/incidents/:id/ack ist idempotent und steht jedem mit Incident-Management-Zugang offen, weil ein Acknowledge nur Paging stoppt. Statuswechsel sind dem Team des Vorfalls vorbehalten. Ein direkter Sprung von triggered auf investigating zählt nicht als Bestätigung. resolved erreicht nur der eigene Resolve-Endpoint.
Merge verschiebt Alarme und Timeline in den Zielvorfall, der Quellvorfall stoppt seine Eskalation. Vorschläge entstehen bei offenen Vorfällen anderer Quellen mit gleichem Service oder Host innerhalb von 15 Minuten. Snooze pausiert Eskalation und Erinnerungen bis zu sieben Tage, Sammelaktionen wirken auf bis zu 200 Vorfälle mit Ergebnis pro Vorfall.
Dein Team arbeitet in Slack. Der Vorfall kommt dorthin.
Niemand soll ein weiteres Tool offen halten müssen, um mitzubekommen, was gerade brennt. Ausgehende Integrationen schicken Vorfälle dorthin, wo dein Team ohnehin arbeitet, und Filter sorgen dafür, dass im Kanal nur ankommt, was dort hingehört.
- Slack, Microsoft Teams, Discord, Jira, PagerDuty, Opsgenie und Webhook, damit Chat, Ticketsystem und bestehende Prozesse vom selben Vorfall wissen.
- Filter nach Team, Schweregrad und Ereignis, damit der Management-Kanal nur Sev1-Vorfälle sieht und Jira genau ein Ticket pro Vorfall bekommt.
- Zustellverlauf mit erneutem Senden: Jede Zustellung ist 90 Tage nachvollziehbar, damit du bei einem Fehler siehst, was angekommen ist, und gezielt nachschickst.
Typen: slack, teams, discord, jira, pagerduty_v2, opsgenie (Region eu oder us, Standard eu) und webhook. Gefiltert wird nach teams, severities und eventKinds (incident_created, acknowledged, severity_changed, status_changed, comment, resolved). Jira startet mit incident_created, also einem Ticket pro Vorfall.
Secrets und Webhook-URLs werden verschlüsselt gespeichert und nie zurückgegeben, private und lokale Ziele werden abgelehnt. Der Zustellverlauf zeigt sent, failed oder retrying. Ein manueller Retry, bis zu zehn pro Minute und Integration, sendet den aktuellen Stand des Vorfalls, nicht die alte Payload.
Dein Kunde sieht den Status, bevor er anruft.
Dein Team arbeitet intern am Vorfall, dein Kunde sieht davon nur, was er sehen soll. Statusseiten-Regeln schalten die passende Status-Seite automatisch auf eingeschränkt, sobald ein Vorfall eines Teams einen Schweregrad erreicht, und wieder zurück, wenn er gelöst ist. Den öffentlichen Text formulierst du selbst.
- Regel statt Handarbeit: Vorfälle eines Teams ab Sev2 setzen die Status-Seite auf Warnung oder Störung, damit dein Kunde nicht als Erster bemerkt, dass etwas nicht stimmt.
- Eigener öffentlicher Text in den Phasen Untersuchung, Ursache gefunden, Beobachtung und Gelöst, damit interne Notizen intern bleiben.
- Automatisch zurück auf grün, sobald der Vorfall gelöst ist, damit die Status-Seite nicht tagelang eine längst behobene Störung zeigt.
Eine Regel lautet: Vorfälle von Team X ab minSeverity (Standard sev2) setzen Status-Seite Y auf targetState (warning oder degraded, Standard degraded), optional nur für bestimmte Komponenten. autoResolve (Standard an) setzt den Zustand bei Lösung zurück. Ein manueller Override pinnt operational, warning oder degraded mit einer Nachricht bis 5.000 Zeichen, Regeln können ihn nicht überschreiben.
Der öffentliche Text eines Vorfalls hat die Phasen investigating, identified, monitoring und resolved, die öffentliche Timeline wächst nur an. Abonnenten werden nur benachrichtigt, wenn sich der Text ändert. Öffentliche Texte setzen nur admin und editor.
Wir überwachen nicht nur. Wir helfen dir beim Verkaufen.
Jedes Uptimeify-Abonnement enthält Zugang zu unserem Success Kit: eine Sammlung erprobter Ressourcen, um dein Monitoring profitabel zu machen.
Service Level Agreement Vorlagen, um professionelle Grenzen mit deinen Kunden zu definieren.
Finde den Sweet Spot für deine Wartungspläne. Berechne Margen basierend auf Prüfintervallen und Supportstunden.
Präsentationen, die nicht-technischen Kunden 24/7-Monitoring erklären. Schließe mehr Wartungsverträge ab.
Nutze automatisierte Berichte, um proaktiv Wert zu kommunizieren, damit Kunden nie fragen, wofür sie bezahlen.
Bereit, Monitoring in ein Profit-Center zu verwandeln?
Sichere dir dein Success Kit und starte noch heute mit der Skalierung.
Häufig gestellte Fragen
Ein Alert ist ein einzelnes Signal aus einer Quelle, etwa eine Meldung aus Zabbix. Ein Incident bündelt alle Alerts, die zum selben Problem gehören, und ist das, woran dein Team arbeitet. Gepagt, bestätigt und gelöst wird der Incident. So erzeugt ein Ausfall, den fünf Tools melden, nur einen Vorgang.
Ein neuer Vorfall startet als „Triggered". Mit dem Bestätigen wird er „Acknowledged", danach kann das Team ihn auf „Investigating", „Identified" und „Monitoring" setzen. Abgeschlossen ist er als „Resolved" oder, wenn er in einen anderen Vorfall eingeflossen ist, als „Merged". Jeder Wechsel steht mit Zeit und Person in der Timeline.
Jede Person mit Zugang zum Incident Management, also die Rollen Admin, Editor und Responder. Bestätigt wird in der App, über den Link in SMS, E-Mail oder Push oder mit der 4 während eines Alarmanrufs. Bestätigen stoppt nur das Paging, deshalb ist es bewusst offen. Den Status eines Vorfalls ändern dagegen nur Mitglieder seines Teams und Organisations-Admins.
Ja. Ausgehende Integrationen senden Ereignisse an Slack, Microsoft Teams, Discord, Jira, PagerDuty, Opsgenie oder einen eigenen Webhook. Pro Integration filterst du nach Team, Schweregrad und Ereignisart. Jira erzeugt standardmäßig ein Ticket pro Vorfall, und jede Zustellung ist 90 Tage im Verlauf nachvollziehbar.
Nein. Incident Management ist ein internes Werkzeug deines Teams, Kundenzugänge haben darauf keinen Zugriff. Was dein Kunde sieht, steuerst du über deine Status-Seite: den automatisch gesetzten Zustand und den öffentlichen Text, den du freigibst. Interne Rollen, Kommentare zur Ursachenforschung und Bereitschaftspläne bleiben bei dir.
Für den technischen Ansprechpartner
Bereit, jeden Vorfall sauber abzuschließen?
Leg die ersten Routing-Regeln an, verbinde Slack oder Teams und koppel deine Status-Seite. Dein Team weiß bei jedem Vorfall, wer dran ist und was als Nächstes kommt. Dein Kunde weiß es auch.