AI-First Incident Management. Mit Fokus auf Datenschutz.

Stellen Sie sich vor, Incidents ließen sich durch Erkenntnisse statt durch manuelle Intervention lösen.

‍

Stellen Sie sich weiter ein Incident-Management der Zukunft vor, in dem Sie bei kritischen Alarmierungen nie allein sind – Ihr bester Techniker würde stets für Sie da sein, Probleme unermüdlich untersuchen, Logs analysieren, Metriken korrelieren, kürzlich vorgenommene Code-Änderungen prüfen und sofort umsetzbare Erkenntnisse liefern. Diesen Schritt in die Zukunft gehen wir mit unserem ersten intelligenten Agenten: dem ilert Responder.

Warum AI-first?

Incident-Management entwickelt sich rasant weiter. Systeme werden komplexer, die Anzahl von Alarmierungen steigt sprunghaft an, der Druck auf die Teams nimmt zu. SREs sind häufig von Alarmflut überwältigt und müssen unter Zeitdruck Logs, Metriken und Dashboards analysieren, um Root-Causes aufzudecken.

‍

Bei ilert setzen wir seit über drei Jahren auf KI im Incident-Management – mit intelligenter Gruppierung von Alarmierungen, automatisierter Postmortem-Erstellung und darüber hinaus. Der ilert Responder ist kein Anfang, sondern ein Quantensprung. Er baut auf jahrelanger Erfahrung, Grundlagenarbeit und Kundenfeedback auf.

‍

Unser Fokus liegt kompromisslos darauf, die Mean Time to Resolution (MTTR) deutlich zu senken. Jede Entscheidung, jedes Feature bewerten wir gemäß der Frage: Wie trägt es dazu bei, die MTTR zu verringern? In GenAI und agentischen Systemen sehen wir transformatives Potenzial, genau dieses Ziel zu erreichen. Wir setzen auf eine Zukunft, in der Sie nur noch dann angepiept werden, wenn die KI einen Incident nicht autonom beheben kann. Keine Anrufe mehr um 3 Uhr nachts, nur um einen Dienst neu zu starten oder ein Deployment zurückzurollen.

‍

Darum verpflichten wir uns, eine AI-first-Plattform zu werden und künstliche Intelligenz in den Kern all unserer Aktivitäten zu integrieren. Der ilert Responder ist mehr als ein weiteres KI-Feature; es ist die fundamentale Neugestaltung der Incident-Response.

Lernen Sie den ilert Responder kennen: Ihren 24/7-Incident-Co-Piloten

‍

Der ilert Responder ist Ihr zuverlässiger Teamkollege und direkt in die ilert-Plattform integriert. Er

‍

• lässt sich nahtlos mit Ihrem Observability-Stack, Ihrer Cloud-Infrastruktur und Ihrem Code-Repository verbinden,
• analysiert Incidents in Echtzeit anhand verschiedener Datenquellen und identifiziert Root-Causes,
• liefert klare, priorisierte Empfehlungen zur Behebung von Störungen.

Interagieren Sie über eine Chat-Schnittstelle: Stellen Sie Fragen, teilen Sie Kontext und erhalten Sie genau dann Rat, wenn Sie ihn brauchen. Jede Erkenntnis des ilert Responders ist klar, umsetzbar und durch Daten belegt – selbst unter Hochdruck.

‍

Im Kern nutzen wir das MCP (Model-Context Protocol), um den ilert Responder-Agenten mit Ihren Tools und Ihrer Infrastruktur zu verbinden. MCP ist für KI, was HTTP für das Web ist – ein Standardprotokoll, das LLM-basierte Agenten mit den Systemen verbindet, in denen reale Daten liegen. Es löst zwei grundlegende Herausforderungen: das begrenzte und veraltete Wissen von LLMs sowie die Komplexität individueller Integrationsschichten zwischen KI-Apps und externen Datenquellen.

‍

Dank MCP kann der ilert Responder sicher und kontextbezogen mit Tools wie Grafana, Prometheus, GitHub und Kubernetes interagieren – und dort Logs, Metriken, Deployment-Daten, Code-Änderungen und mehr in Echtzeit abrufen. Wir haben eine skalierbare Multi-Tenant-Architektur um MCP herum aufgebaut, mit der wir neue Datenquellen (MCP-Server) einfach hinzufügen können und so die Analysefähigkeiten des Responders mit jeder Integration erweitern.

Sehen Sie sich den ilert Responder in Aktion an

Einführung von Agentic Incident Management

‍

Der ilert Responder bedeutet den Beginn dessen, was wir Agentic Incident Management nennen. Hier:

‍

• schlussfolgern und untersuchen intelligente Agenten wie erfahrene Techniker,
• lernen aus jeder Interaktion und werden stetig klüger,
• arbeiten transparent Seite an Seite mit Menschen – wobei stets eine klare Übersicht gewährleistet ist.

‍

Standardmäßig arbeitet der neue ilert Responder im Read-only-Modus und unterbreitet Empfehlungen für eine schnellere Lösung. Er ersetzt Ihr Bereitschafts-Team nicht, sondern ergänzt es.

Nehmen Sie am Beta-Programm für ilert Agentic Incident Response teil

‍

Wir laden innovative Teams ein, an unserem Beta-Programm teilzunehmen und frühen Zugang zum ilert Responder zu erhalten. Als Beta-Tester

‍

• gestalten Sie zukünftige Funktionen direkt mit,
• genießen frühe Vorteile und Wettbewerbsvorsprung,
• führen Ihre Branche in das Zeitalter des KI-gestützten Incident-Managements.

‍

Interesse? Schreiben Sie an support@ilert.com und gehören Sie zu den Ersten bei der AI-first-Incident-Response-Revolution.

‍

‍

AI-first-Incident-Management – für alle

KI-Features sind seit einigen Jahren integraler Bestandteil von ilert. Mit diesem nächsten Schritt sind KI-Funktionen nicht länger Premium-Plänen oder Add-ons vorbehalten; sie sind grundlegend.

‍

Wir haben bereits bedeutende Änderungen an unserer Preisgestaltung vorgenommen. Während der Beta-Phase steht der ilert AI Responder ohne zusätzliche Kosten zur Verfügung. Doch das ist nicht alles: Wir stellen unser AIOps-Add-on ein und machen KI-Funktionen wie intelligentes Alert-Grouping im Scale-Tarif verfügbar. Selbst Kunden in unserem Free-Tarif haben jetzt Zugriff auf KI-Features.

‍

Bald erhalten alle ilert-Kunden flexible AI-Credits, um erweiterte Funktionen freizuschalten – vom ilert Responder bis zum ilert Postmortem-Creator. Details zu unserem transparenten Preismodell mit Credits folgen in Kürze. Halten Sie sich über unseren Blog und Newsletter auf dem Laufenden.

Privacy-first, immer

Der Schutz und die Sicherheit Ihrer Daten haben bei uns höchste Priorität. Wir treiben AI-first voran, um die Incident-Behebung zu beschleunigen, und verankern zugleich Privacy-first mit Datensouveränität, End-to-End-Verschlüsselung, regionsspezifischer KI-Verarbeitung und DSGVO-Konformität. Wir entwickeln von Grund auf intelligente Systeme, die Datenschutz ebenso gewährleisten wie sie Innovation ermöglichen. Der ilert AI Responder basiert auf diesem Fundament.

‍

Für die ilert KI nutzen wir Foundation-Modelle, die je nach Standort bei AWS, Microsoft Azure oder OpenAI gehostet werden. Für Kunden in der EU findet die gesamte KI-Verarbeitung innerhalb Europas auf AWS- oder Microsoft-Infrastruktur statt – es verlassen keine Daten die EU, und es werden keine personenbezogenen oder sensiblen Informationen an OpenAI-Endpunkte außerhalb der EU gesendet. Kunden außerhalb der EU können OpenAI oder AWS nutzen, stets unter strengen Zugriffskontrollen sowie Verschlüsselung bei Speicherung und Übertragung.

‍

Darüber hinaus verwenden wir ausschließlich Daten, die Alarmierungen und Incidents betreffen, und teilen keine personenbezogenen Performancedaten mit externen KI-Modellen. Wir nutzen Ihre Daten nicht zum Training von Modellen und haben bei allen LLM-Anbietern ein Opt-out für Training aktiviert.

‍

Erfahren Sie mehr über unser Engagement für Sicherheit und Datenschutz im Q&A-Bereich.

‍

Wir beginnen eine neue Ära der Incident-Response – eine Ära, in der künstliche Intelligenz SREs nicht ersetzt, sondern sie auf eine neue Stufe bringt. Der ilert Responder ist erst der Anfang – die Zukunft ist kollaborativ, intelligent und menschenzentriert. Lassen Sie sie uns gemeinsam gestalten!

‍

‍

Die ilert Mobile App wird hauptsächlich von Responder:innen genutzt, um Benachrichtigungen über kritische Alarme zu empfangen, unterwegs darauf zu reagieren und den aktuellen On-Call-Status einzusehen. Sie bietet verschiedene Funktionen, darunter kritische Push-Benachrichtigungen, Schnellaktionen für Alerts und individuelle Einstellungen für kritische Benachrichtigungen. Mit der App können Responder:innen ihre aktuellen On-Call-Schichten und Eskalationsregeln einsehen, Schichten von Kolleg:innen übernehmen oder Vertretungsanfragen erstellen, um Kolleg:innen um eine Übernahme der On-Call-Schicht zu bitten. Letzteres ist eine neue Funktion von ilert, die sich als besonders hilfreich für die Kommunikation zwischen Nutzer:innen erwiesen hat. In diesem Beitrag werfen wir einen genaueren Blick auf die Entwicklung dieser Funktion und die Herausforderungen, die dabei zu bewältigen waren.

Warum wurden Vertretungsanfragen eingeführt?

Seit der Einführung der On-Call-Schedules können Nutzer:innen sogenannte Overrides erstellen – also spezielle Schichten, die Vorrang vor regulären Schichten haben. Ein Override erlaubt es, eine andere Person für eine ganze oder teilweise Schicht als On-Call-Verantwortliche:n einzutragen. Overrides müssen nicht an bestehende Schichten gebunden sein – sie können für beliebige Zeiträume erstellt werden, auch außerhalb definierter Schichten.

‍

Später wurde die Funktion „Take On-Call“ eingeführt, also die Möglichkeit, eine fremde Schicht zu übernehmen. Beide Methoden erzeugen technisch gesehen einen Override, doch keine stellt sicher, dass die jeweils andere Person über diese Änderung informiert wird. Das führte in der Praxis dazu, dass Personen plötzlich für Schichten verantwortlich waren, ohne davon zu wissen – was im Ernstfall kritisch sein kann.

‍

Die Lösung war ein neuer Flow: Nutzer:innen sollten die Möglichkeit bekommen, gezielt eine andere Person um die Übernahme einzelner On-Call-Zeiträume zu bitten – mit klarer Kommunikation und Rückmeldung. Daraus entstand das Konzept der Vertretungsanfragen.

Design der REST API für Vertretungsanfragen

Der typische Ablauf einer Vertretungsanfrage ist:

1. Nutzer:in A erstellt eine Vertretungsanfrage und bittet Nutzer:in B, eine oder mehrere Schichten ganz oder teilweise zu übernehmen.
2. Nutzer:in B erhält eine Benachrichtigung und kann die Anfrage annehmen oder ablehnen.
3. Nutzer:in A wird über die Entscheidung informiert.

‍

‍

Die Vertretungsanfragen-API basiert auf einem eigenen Entity-Typ mit mindestens folgenden Feldern:

• sender
• receiver
• shifts
  

‍

Zusätzlich haben wir ein Nachrichtenfeld (message) eingeführt, damit Nutzer:innen zusätzliche Informationen zur Anfrage übermitteln können. Für die UI haben wir außerdem den aktuellen Status (state) und das Erstellungsdatum (createdAt) als Read-only-Attribute bereitgestellt. Bei einer Ablehnung kann optional ein Kommentar mit der Begründung (declineComment) übermittelt werden. Zur Anzeige mehrerer Anfragen in der Listenansicht und für sinnvolle Filter wurde das Feld state in Kombination mit einem im Frontend berechneten Status expired genutzt. Eine Vertretungsanfrage gilt als abgelaufen, wenn die letzte enthaltene Schicht beendet ist.

‍

Neben klassischen Create- und Read-Operationen wurden eigene Endpunkte fürs Akzeptieren, Ablehnen und Zurückziehen eingeführt. Update- und Delete-Operationen gehören aktuell nicht zum Flow und sind nicht geplant.

Vom Mockup zur finalen UI

‍

Zwischen Mockup und finaler Version der Ansicht zur Erstellung einer Vertretungsanfrage gibt es keine großen Unterschiede. Lediglich das Styling wurde angepasst, und es wurde ein zusätzliches Infofeld zur Zeitzone eingeführt. Die finalen Versionen der Listen- und Detailansicht sehen folgendermaßen aus:

‍

Kommunikation ist der Schlüssel

Ein zentrales Ziel dieser Funktion ist es, Nutzer:innen dazu zu motivieren, frühzeitig auf Vertretungsanfragen zu reagieren – da On-Call-Schichten zeitgebunden und oft kurzfristig sind. Außerdem sollen alle relevanten Kommunikationsprozesse in der ilert Mobile App stattfinden, sodass ein Toolwechsel überflüssig wird. Dafür wurden mehrere Kommunikationswege implementiert:

Push-Benachrichtigungen

Sobald eine Aktion bei einer Vertretungsanfrage erfolgt, wird eine Push-Benachrichtigung an die jeweils betroffene Person gesendet:

• Vertretungsanfrage erstellt → Empfänger:in wird benachrichtigt
• Anfrage angenommen/abgelehnt → Absender:in wird benachrichtigt
• Anfrage storniert → Empfänger:in wird benachrichtigt
  

Aber was passiert, wenn die empfangende Person die Mobile-App nicht nutzt?

‍

E-Mail

ilert prüft, ob die relevanten Nutzer:innen über mindestens ein registriertes Push-Token (ein eindeutiger Geräte-Identifikator) verfügen. Falls nicht, wird automatisch eine E-Mail an die primäre Adresse mit den Details zur Vertretungsanfrage gesendet.

In-App Badge‍

‍Da Push-Benachrichtigungen versehentlich übersehen oder weggeswiped werden können – auch bei zeitkritischen Anfragen – wurde in der Listenansicht ein roter Kreis (Badge) oben links am Menü-Icon eingeführt. Dieser zeigt an, ob ungelesene Vertretungsanfragen vorhanden sind. Zusätzlich zeigt der Menüpunkt eine Zählung aller offenen Anfragen an.

Filter bereitstellen, aber UI schlank halten

Eine Filtermöglichkeit für Vertretungsanfragen in der Listenansicht ist notwendig – beispielsweise für empfangene und gesendete Anfragen. Ein weiterer, komplexerer Filter betrifft nur relevante Anfragen, also solche, die noch nicht abgelaufen oder beantwortet sind.

‍

Da bereits ein Toggle für „Erhalten / Gesendet“ existiert, hätte ein zusätzlicher „Aktuell / Alle“-Toggle die Oberfläche überladen.

‍

Ein Vorschlag war eine Filterleiste wie bei der Alert-Liste – diese Idee wurde jedoch verworfen, da sie zum Releasezeitpunkt nur einen Filter enthalten hätte, was nicht stimmig gewirkt hätte. Die finale Lösung: standardmäßig werden nur offene Anfragen (Status Pending) angezeigt, alle weiteren sind über einen Button zugänglich. Diese Lösung bietet die beste Balance zwischen Übersichtlichkeit und Funktionalität.

‍

Alltag bringt Details ans Licht

Nach dem Release begann das ilert-Team selbst mit der Nutzung der Funktion – und stieß schnell auf eine Schwäche: Nach dem Ausführen einer Aktion (Accept, Decline, Cancel) verschwand die betreffende Anfrage sofort aus der Liste, ohne dass der veränderte Status ersichtlich war.

‍

Zwei Verbesserungen wurden daraufhin umgesetzt:

‍

• Nach einer Aktion bleibt man in der Detailansicht, um den aktualisierten Status direkt zu sehen.
• Relevante Anfragen bleiben 24 Stunden nach einer Aktion weiterhin in der Liste sichtbar.

‍

Zuvor verschwand eine Anfrage sofort nach der Statusänderung aus der Liste, da diese auf dem state-Feld basierte. Um auch kürzlich bearbeitete Anfragen anzuzeigen, wurde ein zusätzlicher Query-Parameter in der API eingeführt. Damit kann das Frontend eine createdAt-Zeitgrenze definieren. Die Antwort enthält dann alle Vertretungsanfragen – unabhängig vom Status – ab diesem Zeitpunkt bis jetzt. So können Nutzer:innen alle offenen sowie kürzlich bearbeiteten (innerhalb der letzten 24 Stunden) Anfragen einsehen.

‍

‍Haben Sie die ilert App noch nicht installiert? Probieren Sie sie gerne aus – jetzt für Android oder iOS herunterladen.

‍

Wir freuen uns sehr, dass Rollbar ab sofort Teil des ilert-Integrationskatalogs ist! Diese neue technische Partnerschaft ermöglicht es Softwareteams, dank Rollbar Anwendungsfehler in Echtzeit zu erkennen und sofort mit den leistungsstarken Alarmierungs- und Incident-Management-Funktionen von ilert darauf zu reagieren.

Was ist Rollbar?

Rollbar ist eine umfassende Plattform zur Echtzeit-Fehlerüberwachung und -behebung, die Entwicklungsteams dabei unterstützt, Probleme schneller zu erkennen, zu analysieren und zu beheben – bevor sie sich auf die Nutzer auswirken. Durch detaillierteEinblicke in Anwendungsfehler über den gesamten Softwarelebenszyklus hinweg ermöglicht Rollbar es Teams, qualitativ hochwertigen Code mit mehr Vertrauen in seine Qualität auszuliefern. Mit Kunden wie CircleCI, Twilio, Babbel und Salesforce ist Rollbar die Lösung für Teams, die Zuverlässigkeit und eine nahtlose Benutzererfahrung in den Mittelpunkt stellen.

‍

Im Kern bietet Rollbar eine umfassende Sicht auf den Zustand Ihrer Anwendung, indem es Fehler in dem Moment erfasst, in dem sie auftreten. Egal ob Backend-Exception oder Frontend-Absturz – Rollbar sammelt detaillierte Metadaten, darunter Stack Traces, Request-Parameter und Benutzerdaten, sodass Entwickler Fehler schnell und gezielt beheben können.

‍

Die wichtigsten Funktionen von Rollbar:

‍

• Echtzeit-Überwachung: Fehler werden sofort erkannt und veranschaulicht.
• Intelligente Gruppierung: Reduziert Alarmflutdurch die Gruppierung von Fehlern mithilfe von maschinellem Lernen.
• Umfassender Kontext: Fehleranalysen mit vollständigem Kontext – von lokalen Variablen bis zu betroffenen Nutzern.
• Bereit für den Unternehmenseinsatz: Skalierbar mit Ihrer Infrastruktur, inklusive hoher Sicherheitsstandards und Integrationen.

So profitieren Sie von der Rollbar-Integration

Mit dieser neuen Integration können Rollbar-Alarmierungen automatisch Incidentsin ilert auslösen – und so eine schnelle und gezielte Incident-Response durch Ihre Engineering- und SRE-Teams ermöglichen.

‍

Vorteile der Integration für Ihr Team:

‍

• Sicher bereitstellen: Sie werden sofort benachrichtigt, wenn bei einer neuen Bereitstellung ein Fehler auftritt. Sie können schnell zurückrollen oder Fehler beheben, ohne auf Beschwerden von Nutzern warten zu müssen.
• Brücke zwischen Dev und Ops: SREs und Entwickler arbeiten effizienter zusammen, da ilert Rollbar-Alarmierungen über Ihre bevorzugten Kanäle (Telefon, SMS, Push, Microsoft Teams und mehr) an die richtige diensthabende Person weiterleitet.
• Zentralisierte Ursachenanalyse: ilert empfängt Alarmierungen aus verschiedenen Quellen, was die Ursachenanalyse beschleunigt. Als zentrale Dispatching-Plattform kann ilert Rollbar-Alerts mit Alarmierungen aus anderen Systemen korrelieren und so eine schnellere Incident-Lösung ermöglichen.

So verbinden Sie Rollbar mit ilert

‍

Der Einstieg ist ganz einfach. Um Rollbar mit ilert zu integrieren, folgen Sie einfach unserer Schritt-für-Schritt-Anleitung. In nur wenigen Minuten können Sie:

‍

1. Eine Alarmierungsquelle- in ilert erstellen.
2. Eine Endpoint-URL generieren.
3. Den Webhook in Ihren Rollbar-Einstellungen hinzufügen.

‍

Sobald die Verbindung hergestellt ist, sendet Rollbar Fehlerbenachrichtigungen an ilert. Dort können Sie diese mithilfe Ihrer bestehenden Bereitschaftspläne, Eskalationsregeln und Benachrichtigungseinstellungen verwalten.