ilert stellt mithilfe unserer vorgefertigten Integrationen oder per E-Mail eine nahtlose Verbindung zu Ihren Tools her. Ilert lässt sich in Überwachungs-, Ticketing-, Chat- und Kollaborationstools integrieren.
So erreichen führende Unternehmen mit ilert eine Uptime von 99,9 %
Unternehmen weltweit vertrauen auf ilert, um ihr Incident-Management zu optimieren, die Zuverlässigkeit zu steigern und Ausfallzeiten zu minimieren. Lesen Sie, was unsere Kunden über ihre Erfahrungen mit unserer Plattform sagen.
Dieser Artikel erklärt, warum KI-gesteuerte Automatisierung bei der Reaktion auf Vorfälle jetzt realisierbar ist. Teams können endlich repetitive und zeitkritische Reaktionsaufgaben sicher an KI-Agenten delegieren, die mit Kontextbewusstsein und menschlicher Aufsicht arbeiten. Das Ergebnis sind schnellere Reaktionen, eine höhere Serviceverfügbarkeit und weniger Alarmmeldungen – ohne Kontrollverlust.
Da diese Funktionen nun bei realen Vorfällen zum Einsatz kommen, verlagert sich die Frage natürlich von ob Automatisierung möglich ist zu wie sie sinnvoll eingeführt und gesteuert werden sollte.. Der Agentic Incident Management Guide befasst sich mit diesem nächsten Schritt und beschreibt praktische Rahmenbedingungen, Einführungsstrategien und Beispiele aus der Praxis, die zeigen, wie SRE- und DevOps-Teams die Reaktion auf Vorfälle effektiv und sicher automatisieren können.
Fehlstarts der Automatisierung
Automatisierung ist seit Jahrzehnten ein wichtiger Bestandteil der Technologiestrategie. Sie wurde in unzählige Roadmaps und Transformationsinitiativen aufgenommen, doch die wirklich weit verbreitete, KI-gestützte Automatisierung hat oft die Erwartungen nicht erfüllt. Frühe Versuche stießen aufgrund fragiler Tools, mangelnder Kontextwahrnehmung und einer Betriebskultur, die noch nicht bereit war, autonomen Systemen zu vertrauen, an ihre Grenzen.
Die Technologie hat endlich aufgeholt
Der Hauptgrund für die heutige Realisierbarkeit der Automatisierung ist die erhebliche Verbesserung der KI-Fähigkeiten. Automatisierung ist nicht mehr auf starre, regelbasierte Skripte beschränkt. Moderne Modelle des maschinellen Lernens, insbesondere große Sprachmodelle (LLMs), bieten Kontextverständnis, probabilistische Entscheidungsfindung und adaptives Lernen. Dadurch können Automatisierungssysteme in Umgebungen funktionieren, die früher zu komplex oder unvorhersehbar waren.
Ebenso wichtig ist die Entwicklung der technologischen Infrastruktur. Cloud-native Plattformen, weit verbreitete APIs und zuverlässige Orchestrierungsframeworks ermöglichen der KI den sofortigen Zugriff auf Daten und die Steuerung über verteilte Systeme hinweg. Vor einem Jahrzehnt gab es diese Konnektivität noch gar nicht.
Auch Verbesserungen bei Auto-Scaling, Observability und Telemetrie reduzieren das Risiko erheblich. Vollständige Transparenz, verbesserte Log-Korrelation und ruboste CI/CD Pipelines machen es möglich, Automatisierung in großem Maßstab einzusetzen und gleichzeitig die Auswirkungen und die Wiederherstellung sorgfältig zu steuern. Das Ergebnis ist nicht nur eine intelligentere, sondern auch eine sicherere Automatisierung.
Die Betriebskultur hat sich weiterentwickelt
Technologie allein reicht nie aus. Die zweite wichtige Veränderung war kultureller Natur. Der Aufstieg von DevOps und SRE hat die Einstellung der Teams zur Automatisierung verändert. Dieselben Teams, die sich einst gegen die Automatisierung sträubten, sehen darin nun eine Möglichkeit, Konsistenz zu gewährleisten, unnötige Arbeit zu reduzieren und Ergebnisse zu beschleunigen.
Schuldfreie Nachbesprechungen und fortlaufende Verbesserungsmethoden fördern Experimente und Wiederholungen, wodurch die Automatisierung wachsen und sich anpassen kann. Die SRE-Prinzipien – Reduzierung manueller Arbeit, Verwaltung von Fehlerbudgets und Ausrichtung der Aufgaben an Service Level Objectives (SLOs) – unterstützen auf natürliche Weise eine schrittweise und gut gesteuerte Automatisierung.
In diesem Umfeld wird KI nicht als Ersatz für Ingenieure angesehen, sondern als Partner, der das menschliche Urteilsvermögen verbessert, die mentale Belastung verringert und es den Teams ermöglicht, sich auf wichtigere Aufgaben zu konzentrieren.
Risiken wurden zu einem zentralen Designprinzip
Einer der meistübersehenen Faktoren für KI-gestützte Automatisierung ist der moderne Umgang mit Risiko. Heutige Automatisierungs-Frameworks sind auf eine schrittweise Einführung ausgelegt. Rollouts können gestaffelt erfolgen, Aktionen lassen sich in Echtzeit nachverfolgen, und automatisierte Rollback-Strategien gehören inzwischen zum Standard. Berechtigungen, Richtlinien und Freigabeprozesse werden als Code definiert – klar formuliert, testbar und wiederholbar.
Ebenso wichtig ist, dass KI-gestützte Systeme heute großen Wert auf Observability und Erklärbarkeit legen. Aktionen sind auditierbar, reversibel und messbar. Diese Transparenz verändert die Wahrnehmung von KI: weg von einer Black Box hin zu einem verlässlichen operativen Partner. Durch enge Feedback-Schleifen können Teams Auswirkungen kontinuierlich bewerten und Probleme beheben, bevor sie eskalieren.
Die Vorteile zeigen sich bereits
Dank der Kombination aus ausgereifter Technologie, einer weiterentwickelten Kultur und integrierten Sicherheitsvorkehrungen können Unternehmen die Automatisierung zuversichtlich vorantreiben. Teams, die KI-gesteuerte Automatisierung einsetzen, profitieren bereits von konkreten Vorteilen:
Deutlich reduzierte MTTR dank KI-gestützter Ursachenanalyse und automatisierten Korrekturen
Geringere Betriebskosten, da Routineaufgaben und Skalierungen automatisch verwaltet werden
Erhöhte Zuverlässigkeit und Konsistenz durch weniger menschliche Fehler
Erhöhte Innovationsfähigkeit, da Ingenieure weniger Zeit mit sich wiederholenden Aufgaben verbringen und sich mehr auf geschäftskritische Arbeiten konzentrieren können
Das Ergebnis sind eine schnellere Behebung von Vorfällen, eine verbesserte Servicezuverlässigkeit und eine spürbare Steigerung der Teamzufriedenheit.
Fazit
KI-gesteuerte Automatisierung ist heute nicht aufgrund eines einzelnen Durchbruchs realisierbar, sondern aufgrund einer seltenen Konstellation. Fortschrittliche KI-Fähigkeiten, produktionsreife Infrastruktur, DevOps- und SRE-gesteuerte kulturelle Veränderungen und ein disziplinierter Umgang mit Risiken sind gemeinsam gereift. Der nächste Schritt besteht darin, diese konvergente Entwicklung in der Produktion umzusetzen. Der Agentic Incident Management Guide von ilert untersucht, wie Teams KI-gesteuerte Automatisierung kontrolliert und schrittweise bei realen Vorfällen anwenden können. Hier wird Automatisierung vom Wunsch zum Wirklichkeit.
Als SRE, Platform Engineer oder Bereitschaftsingenieur*in, braucht man sicher nicht noch einen Artikel, der erklärt, wie schmerzlich Incidents sind. Jedes Mal, wenn das Telefon mitten in der Nacht aufleuchtet und das gleiche Muster von vorne anfängt, merkt man es wieder.
Laute Alarme, die echte Probleme übertönen
Mühsame, manuelle Triage
Hektische Suche in Tribal Knowledge, nur um zu verstehen, was passiert
Trotz Investitionen in Runbooks, Automatisierung, Observability und Best Practices, fühlt sich jede Incident Response wie ein einziger Ausnahmezustand an.
Nun Stellen Sie sich nun dieselbe nächtliche Pager-Benachrichtigung vor, jedoch unterstützt durch AI SRE:
Ein Traige-Agent identifiziert in Sekunden das eine Deployment, das mit dem CPU-Spike korreliert.
Ein Kausalinferenz-Agent verfolgt Paketflüsse und weist ein durch eine fehlerhafte Library verursachtes Memory Leak nach.
Ein Kommunikations-Agent erstellt automatisch eine präzise Root-Cause-Zusammenfassung.
Ein Remediation-Agentführt völlig autonom ein Rollback des fehlerhaften Deployments durch
Was früher Stunden dauerte, passiert jetzt in wenigen Minuten - zuverlässig, reproduzierbar und ohne Überlastung des Teams.
Dieser Artikel ist eine kurze Vorschau auf unseren „Agentic AI for Incident Response Guide“. Er zeigt, warum die Runbook-Ära an ihr Ende kommt und wie AI SRE grundlegend verändert, wie Teams künftig mit Incidents umgeht.
Das Problem: Warum Incident Response feststeckt
Selbst die besten Engineering-Teams stoßen an dieselbe Grenze. Das Problem ist nicht der fehlende Einsatz, sondern das Modell, auf das wir uns verlassen.
Runbooks haben früher gut funktioniert. Doch unsere Systeme entwickeln sich schneller, als unsere Runbooks aktualisierbar sind.
Unsere Analyse zeigt:
Alarme skalieren schneller, als Teams Schritt halten können.
MTTR liegt weiterhin in Stunden, nicht in Minuten.
Bereitschaftsingenieur*innen sind auf verstreutes Tribal Knowledge angewiesen.
Jeder Incident erfordert menschliche Interpretation und Kontext.
Moderne Infrastrukturen sind zu verteilt, zu dynamisch und zu stark voneinander abhängig, als dass statische Runbooks mithalten könnten. Runbooks sind nicht schlecht, sie sind schlichtweg überholt.
Warum inkrementelle Automatisierung scheitert
Die meisten Teams beginnen damit, Skripte, Bots und einfache Auto-Remediation hinzuzufügen. Anfangs wirkt das hilfreich, doch schon bald zeigt sich, dass die Komplexität die Automatisierung überholt. Die Komplexität moderner Infrastrukturen steigt nicht linear, sie augmentiert. Verteilte Architekturen, ephemeres Compute, kontinuierliche Deployments und tief miteinander verknüpfte Abhängigkeiten erzeugen eine sich ständig wechselnde Incident-Landschaft.
Automatisierung scheitert häufig, weil sie fragil ist und ins Stocken gerät, sobald Incidents nicht zu bekannten Mustern passen. Während Skripte veralten und Alarme sich anhäufen, bleibt kritisches Wissen isoliert. Nur erfahrene Ops-Teams können echte Probleme zuverlässig von Noise unterscheiden.
Das Ergebnis: Menschen verbringen weiterhin den Großteil ihrer Zeit mit Triage und dem Hinterherjagen von Symptomen über fragmentierte Tools hinweg. Damit rutscht das Team in einen reaktiven Firefighting-Modus ab, in dem Teilautomatisierung paradoxerweise noch mehr manuelle Arbeit erzeugt.
Die Lösung: vom Firefighting-Modus zur intelligenten Response
Teams benötigen heute ein System, das ihre Umgebung versteht, Signale im Kontext interpretiert und sich dynamisch an veränderte Bedingungen anpasst, ähnlich wie ein erfahrenes medizinisches Team, das auf die Situation eines Patienten reagiert.
Genau das ist das Versprechen von Agentic AI für Incident Response.
Im Gegensatz zu statischen Tools, die lediglich vordefinierte Regeln ausführen, bietet Agentic AI eine adaptive, kontext bewusste Intelligenz. Sie interpretiert Signale, erkennt Abhängigkeiten, lernt aus jedem einzelnen Incident und kann auf eine Weise handeln, die herkömmliche Automatisierung nicht erreicht.
Damit kommen wir zur ersten zentralen Komponente von AI SR
Umgebungsintellignete AI
Ein AI-SRE-System bringt Fähigkeiten mit, die manuelle oder halbautomatisierte Ansätze grundsätzlich nicht erreichen können. Es führt nicht nur Schritte aus, sondern es interpretiert Signale, bewertet Kontext, lernt kontinuierlich dazu und trifft fundierte Entscheidungen, anstatt starren Regeln zu folgen. Je mehr Incidents das System löst, desto intelligenter wird es.
Die Zukunft der Incident Response besteht darin, menschliche Expertise durch AI zu verstärken. Die AI übernimmt das Mühsame, das Laute und das kognitiv Erdrückende, das Menschen nicht tragen sollten. Menschen bleiben dabei selbstverständlich essenziell. So wie Ärzt:innen sich auf automatisierte Monitore verlassen, um Vitalwerte zu überwachen, während sie die zugrunde liegende Ursache diagnostizieren, managt AI SRE die kontinuierlichen Hintergrundsignale, damit Engineers sich auf die Entscheidungen konzentrieren können, bei denen menschliches Urteilsvermögen wirklich zählt.
Sobald ein System dieses Verständnis erreicht, stellt sich die nächste Frage: Wie geht es mit komplexen, vernetzten Systemen um, in denen ein Symptom häufig aus einem völlig anderen „Körperteil“ stammt?
Das führt uns zur zweiten Hauptkomponente des Systems: dem Übergang von linearen Incident-Pipelines zu einem dynamischen, vernetzten Incident Mesh.
Das „Incident Mesh“
Stellen Sie sich Incidents als Signale in einem lebendigen Netzwerk vor. Probleme breiten sich aus, verändern sich und verketten sich über Services hinweg. Agentic AI nimmt diese Komplexität mit einem Incident-Mesh-Modell an. Anstatt linear durch eine Queue zu laufen, werden Incidents zu miteinander verbundenen Knoten, die das System ganzheitlich erfasst und steuert.
Dieses Mesh-Modell ermöglicht:
Dynamische Repriorisierung, während sich ein Incident entwickelt.
Lernen und Anpassen in Echtzeit –– jeder gelöste Incident verbessert die zukünftige Response.
Jeder Agent übernimmt dabei einen Teil des Gesamtpuzzles - ähnlich wie ein medizinisches Einsatzteam, in dem Triage, Chirurgie und Diagnostik parallel und koordiniert agieren, nicht sequenziell.
Dieser Multi-Agent-Ansatz funktioniert jedoch nur, wenn das zugrunde liegende System dafür geschaffen ist. Spezialisierte Agenten benötigen eine Architektur, die nahtlose Kollaboration, Kommunikation und Übergabe von Aufgaben ermöglicht. Genau dafür muss das System von Grund auf für Multi-Agent-Intelligenz gebaut sein.
Blueprint: Architektur für Agentic AI
Agentic AI ist kein einzelner Bot, sondern ein koordiniertes System aus spezialisierten, zusammenarbeitenden Agents. Reife Teams setzen bereits folgende Bausteine ein:
Modulare Agent-Cluster:Root-Cause-Analyse, Remediation und Kommunikation arbeiten orchestriert zusammen.
Data-First-Architektur:Logs, Traces und Tickets werden vereinheitlicht; Datenschutz wird durch strikte Zugriffskontrollen und Maskierung gewährleistet.
Ereignisgesteuerte Orchestrierung:Incidents werden in Subtasks zerlegt und dynamisch an den jeweils bestgeeigneten Agent geroutet.
Eingebaute Observability:Jede Aktion eines Agents wird nachverfolgt; Feedback-Schleifen treiben kontinuierliches Lernen und Optimierung.
Human-in-the-Loop-Fallbacks:Bei unklaren oder risikoreichen Szenarien fordert das System vor der Ausführung eine Bestätigung an.
Das ist keine Theorie: Diese Muster entstehen bereits heute in Engineering-first-Organisationen, die genug von „Spray-and-Pray“-Automatisierung haben.
Wahlüberlastung überwinden: So starten Sie den Wandel
Sobald Teams verstanden haben, was Agentic AI ist, taucht das nächste Hindernis auf: die Einführung. Viele Teams bleiben genau an diesem Punkt stehen. Es ist leicht, in endlose Evaluationszyklen, Feature-Vergleiche oder die Sorge hineinzurutschen, Kontrolle abzugeben.
Doch echter Fortschritt beginnt überraschend einfach:
1. Analysieren Sie Ihren Incident-Response-Flow.Erfassen Sie, wie viel Zeit für Triage, Diagnose und Remediation anfällt. Was ist noch manuell? Wo ist Wissen isoliert?
2. Starten Sie Pilotprojekte dort, wo der größte Toil entsteht.Beginnen Sie mit routinemäßigen, aber schmerzhaften Incidents, wie etwa Cache-Clears, lauten Deployment-Rollbacks oder massenhaftem Log-Parsing. Halten Sie den Scope eng und vollständig beobachtbar.
3. Bestehen Sie auf Transparenz.Setzen Sie auf Frameworks, in denen jede Aktion eines Agents geloggt, erklärbar und reversibel ist. Keine Blackbox, keine Magie.
4. Kalibrieren Sie den Autonomiegrad schrittweise.Schalten Sie nicht sofort alles auf „autonom“. Iterieren Sie, überprüfen Sie Ergebnisse und lassen Sie Vertrauen durch echte, wiederholbare Erfolge wachsen.
5. Messen Sie, was wirklich zählt.Fokussiere: tatsächliche MTTR, Reduktion von Alerts und den messbaren Rückgang menschlicher Stunden im Firefighting-Modus –– nicht auf Vanity-Metriken.
Sobald Pilotphasen spürbare Ergebnisse liefern, entsteht zwangsläufig die nächste Frage: Wie skalieren wir Autonomie verantwortungsvoll?
An dieser Stelle werden Prinzipien entscheidend.
Adaptive Autonomy
Autonomie ist nicht binär. Stimmen Sie sie abhängig vom Risiko ab:
AI-geführt bei routinemäßigen Fixes mit geringem Blast Radius
AI-mit-Freigabe bei sensiblen oder wirkungsvollen Änderungen
Mensch-geführt bei unsicheren oder mehrdeutigen Szenarien
Wichtig: Teams –– nicht Vendoren –– sollten den Regler kontrollieren.
Cognitive Coverage statt Alert Coverage
Hören Sie auf, „Erkennen wir alles?“ zu denken. Stellen Sie stattdessen die entscheidende Frage:
„Versteht unsere AI die Systemgesundheit über alle relevanten Dimensionen hinweg?“
Erfassen Sie Blind Spot, etwa unüberwachte Abhängigkeitsspitzen, genauso rigoros wie Lücken in der Alert Coverage.
So verschiebt sich die Diskussion von reiner Noise-Reduktion hin zu echtem situationalen Verständnis.
Mit diesen Prinzipien können Teams AI SRE sicher und selbstbewusst ausbauen.
Der Point of No Return: Die nächste Ära des Incident Managements
Agentic AI markiert einen Wendepunkt für Incident Response. Es eröffnet einen klaren Ausweg aus einem reaktiven Firefightung-Modus und fragiler Automatisierung und führt zu einem neuen Operating Model, das auf Kontext, Anpassungsfähigkeit und intelligenter Zusammenarbeit basiert. Für SREs und Engineering-Teams geht es bei diesem Wandel nicht darum, Expertise zu ersetzen, sondern sie freizusetzen.
Wenn Agents die kognitiv belastenden 80 % der Incident-Response-Arbeit übernehmen, entsteht in den verbleibenden 20 % genau das, was Teams heute brauchen: Platz für kreative Lösungen, präzises Engineering-Judgment und strategisches Denken auf Systemebene. Genau dort entstehen für Teams, die Plattform und das gesamte Unternehmen der größte Mehrwert.
Wenn Ihnen durch diese Vorschau , was möglich ist, geht der vollständige „Agentic AI for Incident Response Guide“ tiefer. Er geht tief auf Architektur-Patterns, Reifegrade und praktische Designprinzipien ein, mit denen Teams agentische Incident-Response-Systeme sicher und effektiv einführen können.Der Guide begleitet Teams von den ersten Experimenten bis zu einer modernen Reliability-Funktion, die organisatorische Komplexität nicht mehr bremst, sondern beschleunigt und Incident Response auf ein neues Level hebt.
Die Runbook-Ära macht Platz für etwas Neues. Die Frage ist nicht mehr, ob sich etwas wandelt, sondern wer diesen Wandel prägen wird.
Während sich die Feiertage nähern, macht das ilert Team genau das Gegenteil von langsamer werden – wir legen noch einen Gang zu. In den vergangenen Wochen haben wir eine Welle wirkungsvoller Verbesserungen in den Bereichen Alarmierung, KI-gestützte Automatisierung, Mobile App und Statusseiten ausgeliefert. Von großen Upgrades, die verändern, wie Teams Incidents triagieren, bis zu kleinen Verfeinerungen, die tägliche Reibung entfernen – dieses Release ist vollgepackt mit Updates, die Bereitschaftsdienst und Betrieb reibungsloser, smarter und schneller machen. Legen wir los.
AI SRE: Ihr kompetenter Incident-Buddy
Sie erinnern sich wahrscheinlich an unsere Ankündigung von ilert Responder – ilerts ersten intelligenten Agenten, der während Incidents umsetzbare Einblicke liefert. In den letzten Monaten haben wir deutlich mehr Funktionen, leistungsfähigere Agenten und Fähigkeiten eingeführt, die nun alle unter ilert AI SRE zusammengefasst sind. Was genau hat sich geändert?
Wie die vorherige Version kann ilert AI SRE Logs analysieren, Metriken korrelieren, jüngste Code-Änderungen prüfen und Ihnen und Ihrem Team empfohlene Maßnahmen zur Lösung des Incidents vorschlagen. Darüber hinaus können ilert Agenten nun – sofern Sie die Erlaubnis erteilen – auch autonom handeln.
Auch wenn es zunächst gewagt klingen mag, einer AI Zugriff auf eine Produktionsumgebung zu geben, werden Sie überrascht sein, wie viele Probleme eher manuelle, schnelle Fixes erfordern als große intellektuelle Analysen. Um die Last durch manulle Aufgaben mitten in der Nacht zu reduzieren und mehr wertvolle Zeit für nachhaltige langfristige Lösungen zu gewinnen, können Sie AI SRE schrittweise mehr Zugriff geben und automatische Aktionen wie Rollbacks auf die letzte stabile Version oder das Neustarten eines Services aktivieren. Damit Sie verschiedene Level agentischer Autonomie leichter erkennen, haben wir drei Stufen in unserem Agentic Incident Management Guide eingeführt.
Hinter den Kulissen wird ilert AI SRE deshalb nützlich, weil es sich tief in Ihre bestehenden Monitoring-, Observability- und Deployment-Tools integriert. Das bedeutet: Sie müssen Ihren Stack nicht ändern – Sie verbinden Ihre vorhandenen Tools und lassen den Agenten übergreifend damit arbeiten. Alles beginnt mit Deployment events, denn sie ermöglichen dem Agenten, Alarme mit jüngsten Code-Änderungen und Rollouts zu korrelieren – oft entscheidende Signale zur Identifikation von Root Causes. Wenn Sie das noch nicht getan haben, empfehlen wir Ihnen den Artikel dazu, wie Sie Ihre CI- und CD-Pipelines mit ilert verbinden.
Als nächsten Schritt machen Sie den Agenten mit Ihren Observability-Daten vertraut. Dafür verbinden Sie ihn mit Tools wie Grafana, Prometheus, Loki, Elastic usw. – Der Ablauf ist simpel und geradlinig. Und als letzter Schritt der Einrichtung definieren Sie die Root Cause Analysis Policy für den Agenten. Wir empfehlen, zunächst mit einem manuellen Trigger zu starten, um die Performance des Agenten zu beobachten.
Sobald der SRE-Agent eingerichtet ist und der erste Incident eintritt, können Sie über den Chat auf der rechten Seite der Alarmansicht mit ihm kommunizieren – genau so, als würden Sie mit Ihrer Kollegin oder Ihrem Kollegen sprechen. Schauen Sie sich die Live-Demo von ilert AI SRE auf der Öredev Conference in Malmö an, um agentische Incident Response in Aktion zu sehen.
Wenn Sie zu den Ersten gehören möchten, die die ilert AI SRE Incident Response ausprobieren, schicken Sie uns einfach eine Nachricht an support@ilert.com.
Claude, Cursor und andere MCP-Klienten mit ilert verbinden
Mit der Veröffentlichung des ilert MCP Servers wird die Integration Ihrer Alarmierungs- und Incident-Management-Workflows in AI-Assistenten nahtlos. Der MCP Server implementiert das Model Context Protocol – einen offenen Standard, der es Tools wie Claude, Cursor (oder jedem MCP-kompatiblen Client) ermöglicht, über eine einheitliche Schnittstelle mit ilert zu interagieren. Über dieses Setup kann Ihr Assistent mit korrekten Berechtigungen und Audit-Trails sicher Alarme auflisten, Dienstpläne einsehen, Incidents erstellen oder eskalieren, Alarme bestätigen oder auflösen.
Das Verbinden ist ganz einfach: Sie erzeugen in ilert einen API-Key und konfigurieren anschließend Ihren MCP-Client über einen Remote-HTTP-Transport. Ausführlichere Anleitungen finden Sie in der ilert Dokumentation. Sobald die Konfiguration abgeschlossen ist, erscheint ilert in der Tool-Liste des Clients und steht direkt in der Oberfläche des Assistenten zur Verfügung. Das reduziert Kontextwechsel, verkürzt die Time-to-Resolution und integriert Incident Response nahtlos in den KI-gestützten Workflow Ihres Teams ein.
Lesen Sie einen ausführlichen Deep Dive zu dieser Funktion in unserem Blog.
Verwandte Alarme mit nur einer Aktion zusammenführen
Mit der Funktion zum Zusammenführen von Alarmen können Sie bestehende Alarme per Klick zu einem einzigen Hauptalarm kombinieren. Das Zusammenführen stoppt sofort doppelte Eskalationen und Benachrichtigungen, hält Responder in einem gemeinsamen Kommunikationsfaden ausgerichtet und bewahrt vollständige Nachvollziehbarkeit, indem zusammengeführte Alarme im Audit-Log erhalten bleiben. Das Ergebnis ist eine aufgeräumte Incident-Arbeitsumgebung, präzise Berichte und eine bessere Grundlage für AI SRE-Funktionen – einschließlich automatischer Merge-Empfehlungen während der Root-Cause-Analyse.
Das Zusammenführen von Alarmen arbeitet Hand in Hand mit dem Event Grouping: Events werden zu Alarmen zusammengeführt, und Alarme können jetzt zu einem primären Alarm zusammengeführt werden. Klar, zielgerichtet und so gebaut, wie Teams in der Realität tatsächlich Troubleshooting betreiben.
Alarme schneller und gezielt nach Labels filtern
Die Alarmliste unterstützt jetzt ein leistungsstarkes, Label-basiertes Filtern, mit dem Sie exakt die Alarme herausfiltern können, die für Sie relevant sind. Sie können Filter mithilfe von Label-Keys und -Values samt Autovervollständigung erstellen, mehrere Bedingungen miteinander kombinieren und aktive Filter unmittelbar in einer kompakten ICL-ähnlichen Syntax sehen. Das Bearbeiten der Filter ist nur einen Klick entfernt, und dieselbe Nutzererfahrung steht auch mobil zur Verfügung. So können Teams ihren Alarmstream jederzeit und überall nach Umgebung, Region, Service oder beliebigen Custom-Labels aufschlüsseln.
Das bringt erheblich mehr Präzision in die Alarm-Triage, besonders in größeren Umgebungen, in denen Labels das primäre Mittel sind, um Daten systemübergreifend zu organisieren.
Weitere Optionen zum Alarm-Filtern
Sie können Alarme jetzt auch nach Priorität filtern – sowohl in der ilert Nutzeroberfläche als auch in der App. Egal ob Sie am Schreibtisch triagieren oder unterwegs sind: Ganz einfach, sich zuerst auf die kritischsten Alarme zu konzentrieren und die Alarmflut niedriger priorisierter Themen zu durchdringen.
Transparente Alarm-Gruppierung
Um Verwirrung durch nicht übereinstimmende Event-Zählungen zu vermeiden, haben wir die Darstellung von gruppierten Events auf der gesamten Plattform vereinheitlicht. Zuvor wurden Event-Grouping via alertKey und die auf Alarmquellen basierende Gruppierung getrennt behandelt, was zu Unterschieden in der Alarmliste und in den Alarmdetails führte. Das aktualisierte Design konsolidiert diese zu einer einzigen, konsistenten Event-Anzahl – mit klaren Gruppierungszuständen und einer detaillierten Aufschlüsselung im Dialog Event Grouping. So sehen Nutzerinnen und Nutzer stets eine korrekte Summe – unabhängig von der Gruppierungsmethode – und können leicht nachvollziehen, wie und wann Events zusammengeführt wurden.
Neuer Wait-Knoten für Event Flows
Event Flows erhalten einen leistungsstarken neuen Kontroll-Schritt: den Wait-Knoten. Diese Ergänzung ermöglicht es Teams, einen Flow entweder für eine bestimmte Dauer zu pausieren oder bis zum Beginn bzw. Ende definierter Supportzeiten zu warten. Sie bringt präzise Timing-Kontrolle in die Automatisierung und ermöglicht intelligentere Workflows – zum Beispiel das Verzögern nicht dringender Aktionen außerhalb der Geschäftszeiten oder das Einplanen fester Wartezeiten zwischen Retries. Der Knoten respektiert Supportzeiten-Konfigurationen einschließlich Feiertags-Ausnahmen und bietet so vorhersehbares, kontextbewusstes Verhalten.
Diese Verbesserung baut auf dem Fundament unseres jüngsten Deep Dives zu Event Flows auf. Der Wait-Knoten erweitert die Möglichkeiten der Flow-Automatisierung und hilft Teams, verlässlichere, menschenfreundlichere Prozesse zu gestalten.
Responsive Grid-Layout für großflächige Statusseiten
Statusseiten unterstützen nun eine dritte Layout-Option – das responsive Grid – entwickelt für Organisationen, die Hunderte oder sogar Tausende Services verwalten.
Das neue Layout führt ein hochdichtes Grid ein, das für umfangreiche Service-Kataloge optimiert ist. Auf breiten Bildschirmen werden Services in bis zu 12 Spalten innerhalb einer Inhaltsbreite von 1536 px angeordnet – für eine saubere, schnell zu erfassende Übersicht. Mit abnehmender Bildschirmbreite passt sich das Grid nahtlos an: Tablets zeigen weniger Spalten, und auf dem Smartphone wechselt die Ansicht in einen Icon-only-Modus für maximale Klarheit. Entscheidender Punkt: Dieses Layout unterstützt alle Schlüsselelemente wie aktive Incidents, vergangene Incidents, Metriken und Service-Gruppierungen, sodass Teams den Status in jeder Größenordnung effektiv kommunizieren können.
Fürr Unternehmen mit weit verzweigten Architekturen macht das responsive Grid Statusseiten sowohl performant als auch benutzerfreundlich und verwandelt umfangreiche Service-Inventare in eine klar lesbare, leicht navigierbare Darstellung.
Neuigkeiten zur Mobile App
Das Bearbeiten von Coverage-Requests auf dem Smartphone ist deutlich reibungsloser geworden. Bislang war vielen Nutzerinnen und Nutzern nicht klar, dass der obere Abschnitt im Coverage-Request-Flow lediglich als Suchfilter fungiert. Das bedeutete, dass sie die unten aufgeführten Shifts trotzdem manuell anpassen mussten, bevor sie die Anfrage absendeten – ein häufiger Punkt der Verwirrung, den mehrere Kundinnen und Kunden gemeldet haben.
Mit dem neuesten Update wendet ilert Mobile die ausgewählten Suchgrenzen nun standardmäßig auf alle passenden Shifts an. Sie können einzelne Shifts weiterhin feinjustieren, falls nötig, aber das Standardverhalten entspricht jetzt der im Filter ausgedrückten Absicht. Das Ergebnis: weniger Taps, weniger Unklarheit und ein intuitiveres Erlebnis beim Erstellen von Coverage-Requests.
Die Heartbeat-Liste in der Mobile App erscheint nicht mehr leer: Wir haben sowohl die Listen- als auch die Detailansicht von einer Abhängigkeit zu Alarmquellen mit Integrationstyp-Filtern auf die Verwendung der dedizierten Heartbeat Monitors API umgestellt. Dadurch werden Ihre Monitore korrekt und in Echtzeit angezeigt – im Einklang mit der Art, wie Heartbeats plattformweit verwaltet werden.
Laden Sie die ilert App für iPhone und Android herunter.
Und noch ein paar kleinere, aber dennoch augen- und herzerfreuende Updates.
Wir haben den Katalog für Outbound-Integrationen (Ihnen auch als Alert Actions vertraut) überarbeitet. Sie sehen jetzt alle relevanten Features zu jeder Verbindung, und die Navigation durch die Liste ist einfacher.
Außerdem zeigen die Logs der Alert Actions nun, zu welchem Alarm und welcher Alarmquelle jede Aktion gehört, und Sie können nach diesen Referenzen filtern, um schneller genau nachzuvollziehen, was passiert ist.
Statusseiten-E-Mail-Benachrichtigungen unterstützen jetzt Markdown, wodurch sich Updates klar und konsistent formatieren lassen. Fettschrift, Listen, Links und andere leichtgewichtige Formatierungen werden in ausgehenden E-Mails korrekt gerendert – Teams können also strukturierte, gut lesbare Incident-Updates teilen, ohne das Tool zu wechseln oder Inhalte neu zu verfassen.
Vorlagen für Custom Processing Rules verhalten sich nun so, wie Teams sie tatsächlich nutzen: Bedingungen werden nur dann als wahr ausgewertet, wenn wirklich eine Vorlage vorhanden ist (für alertKey oder eine der Aktionen create/accept/resolve). Zusammen mit neuen Out-of-the-box-Vorlagen für die meistgenutzten Integrationen bedeutet das weniger Rätselraten, weniger „leere“ Bedingungen und eine schnellere Einführung konsistenter, hochwertiger Alert-Payloads.
Und zum Schluss: Unser ilert Maskottchen – der blaue Frosch – hat plattformweit einen frischen Look. Freuen Sie sich bei jedem Öffnen von ilert über seinen helleren, farbenfroheren Stil.
Hoppla! Beim Absenden des Formulars ist etwas schief gelaufen.
Unsere Cookie-Richtlinie
Wir verwenden Cookies, um Ihre Erfahrung zu verbessern, den Seitenverkehr zu verbessern und für Marketingzwecke. Erfahren Sie mehr in unserem Datenschutzrichtlinie.
