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.
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.
Das Jahresende setzt unter Druck. (Man kennts). Die Nachfrage steigt, die Erwartungen an Reaktionszeiten bleiben hoch, und Engineering-Teams jonglieren Produktionsprobleme, Releases und freie Tage. Für viele Teams wird der Bereitschaftsdienst genau dann chaotisch: Dienstpläne brechen, Benachrichtigungen treffen zur falschen Zeit ein, und genau dann, wenn man es sich am wenigsten leisten kann, entstehen Lücken in der Abdeckung.
Die Funktionen Feiertage und Supportzeiten von ilert wurden entwickelt, um genau das zu beheben. Sie vereinfachen das Bereitschaftsmanagement, schützen die Zeit Ihres Teams und halten Organisationen reibungslos am Laufen.
In diesem Artikel zeigen wir, wie diese Funktionen helfen, die Kontrolle zu behalten, Burnout zu verhindern und auch in den heißen Phasen planbare, verlässliche Dienstpläne zu etablieren. Und am Ende finden Sie ein praktisches Bonus-Kapitel: Wie Sie Ihre Gesundheit schützen, die Balance behalten und ohne Burnout durch die Weihnachtszeit kommen.
Jahresende – ein Crashtest für Ihre On-Call-Routine
Bereitschaftsmanagement wird kompliziert, wenn Support-Erwartungen je nach Region, Kunde oder Zeitzone variieren. Kommen Feiertage und die PTO-Saison hinzu, greifen Teams oft zu Tabellen, Slack-Pings oder „Bitte übernehmen Sie meine Schicht“-Improvisationen.
Der Betrieb zum Jahresende verlangt ohnehin höchste Konzentration. Dennoch flicken viele Teams Dienstpläne weiterhin manuell mit Tabellen, E-Mails oder Slack-Threads. Diese kleinen Improvisationen summieren sich – und ziehen Engineers und Manager weg vom Lösen der eigentlichen Probleme hinein ins administrative Feuerwehrspiel.
Die Funktion Feiertage und Supportzeiten löst das, indem sie Teams präzise automatisierte Kontrolle darüber gibt, wann Alarme ausgelöst werden sollen und wer sie bearbeitet. Das Ergebnis: weniger Unterbrechungen, sauberes Routing und Dienstpläne, die die tatsächliche Verfügbarkeit widerspiegeln.
Schauen wir uns zuerst die Funktion Supportzeiten an.
Die Supportzeiten-Funktion in ilert ermöglicht es Teams, genau festzulegen, wann Alarme ausgelöst werden sollen und wie sie anhand zeitbasierter Regeln geroutet werden. Sie fungiert als Leitlinie, die prüft, ob ein Ereignis während der Geschäftszeiten, außerhalb oder innerhalb speziell definierten Zeitfenstern stattfindet. So können Teams das Verhalten nach Dringlichkeit steuern: Kritische Incidents können rund um die Uhr eskaliert werden, während weniger schwerwiegende Themen bis zum nächsten Morgen warten können.
Supportzeiten können einfach sein (Wochentage 9–5) oder hochstrukturiert mit mehreren Blöcken, Zeitzonen und Logikschichten. Sie sind ideal für Organisationen mit unterschiedlichen SLA-Tiers, globalen Kundenstämmen oder Engineering-Teams, die Nächte und Wochenenden vor unnötigem Lärm schützen möchten.
Feiertage treiben dieses Konzept noch weiter. Intern nennen wir sie scherzhaft „Supportzeiten auf Steroiden“.
Damit können Teams nationale Feiertage, unternehmensweite freie Tage oder regionale Gedenktage automatisch aus regulären Support-Fenstern ausschließen. Anstatt Dienstpläne jedes Mal manuell anzupassen, wenn ein Feiertag ansteht, matcht ilert Ihre Servicezeiten mit dem relevanten Feiertagskalender und passt das Routing automatisch an.
Das ist besonders stark für verteilte Teams mit länderspezifischen Feiertagen – oder für alle, die schon einmal versehentlich am Weihnachtsmorgen gepaged wurden. Feiertage stellen sicher, dass Ihre Eskalationslogik die Realität widerspiegelt: weniger Überraschungen für Engineers und eine sauberere operative Abdeckung, wenn im Büro die Lichter aus sind.
Darum wird Ihnen Ihr zukünftiges Ich danken
Wir haben Supportzeiten und Feiertage aus grundlegenden Gründen etabliert. Wir erhalten täglich zahlreiche Support-Tickets, doch der Januar ist eine besondere Hochsaison – und wir verstehen die Herausforderungen, vor denen unsere Kundinnen und Kunden stehen. Kommt Ihnen davon etwas bekannt vor?
Lücken in der Abdeckung treten zu dem ungünstigsten Zeitpunkt auf. Wenn Engineers sich wohlverdiente freie Tage nehmen, werden diese häufig unvermeidlich – es sei denn, Dienstpläne passen sich automatisch an. Ohne diese Automatisierung verteilt sich die Last ungleich: Jemand trägt am Ende zusätzliche Bereitschaftsdienste, oder – im schlimmsten Fall – eine Ingenieurin oder ein Ingenieur wird während der Feiertage benachrichtigt. Diese Lücken schaden der Moral und verlangsamen die Incident Response direkt, dann wenn Uptime am meisten zählt.
Manuelle Korrekturen kosten Zeit, die Sie nicht haben. Die Jahresendarbeit verlangt ohnehin volle Konzentration, und dennoch improvisieren viele Teams mit Tabellen oder Slack-Threads, um Dienstpläne zu flicken. Diese Last-Minute-Anpassungen verbrauchen Engineering-Zeit, die besser in die Stabilisierung von Systemen, das Ausliefern von Features oder die Vorbereitung auf Traffic-Spitzen fließt – statt in die Betreuung von Kalendern.
Eskalationen werden laut und ungenau. Wenn Supportzeiten und Feiertage nicht vollständig in die On-Call-Logik integriert sind, werden Alarme zum falschen Zeitpunkt ausgelöst. Menschen werden außerhalb der Geschäftszeiten gepingt, oder dringende Themen rutschen unbemerkt durch. In einer Hochsaison voller Kundenaktivität eskalieren fehlgeleitete Alarme schnell zu Incidents – mit Auswirkungen auf Kundinnen und Kunden und unschönen roten Flecken auf Ihren Statusseiten.
Internationale Teams spüren die Komplexität noch stärker. Verteilte Teams haben es mit einem Flickenteppich aus nationalen Feiertagen, kulturellen Anlässen und regionalen Support-Regeln zu tun. Ohne ein System, das sich an den Kalender jeder Region anpasst, werden einige Teams überlastet, während andere unbeabsichtigt unterfordert sind. Dieses Ungleichgewicht wird besonders gefährlich, wenn die globale Nutzung anzieht.
Kundinnen und Kunden pausieren ihre Erwartungen nicht. Selbst wenn interne Teams langsamer an- oder in den Urlaub gehen, ticken SLAs weiter. Kundinnen und Kunden erwarten das gleiche Maß an Reaktionsfähigkeit – und jede Fehlanpassung zwischen Support-Verträgen und On-Call-Abdeckung wird schmerzhaft sichtbar. Schlecht gesteuerte Supportzeiten in der geschäftigsten Saison sind nicht nur lästig für Engineers – sie untergraben Vertrauen.
Bonus: 8 Tipps für Engineers im Dienst, um Burnout in der Vorweihnachtszeit zu vermeiden
Verbessern Sie Ihre Alarme. Räumen Sie lärmende Monitore auf, entfernen Sie veraltete Checks und justieren Sie Schwellwerte, bevor der Traffic steigt. Ein leiseres, genaueres Alarm-Setup zahlt sich in stressigen Wochen enorm aus.
Automatisieren Sie, was geht. Kleine Automatisierungen wie Log-Parser, Deployment-Skripte und Filter für Fehlermeldungs-Benachrichtigungen sparen Stunden, wenn die Alarmflut einsetzt.
Nutzen Sie Rotationen sinnvoll. Stellen Sie sicher, dass On-Call-Verantwortlichkeiten fair verteilt sind und dass Feiertage korrekt abgebildet werden, damit niemand länger am Stück arbeitet, als er oder sie sollte.
Proben Sie Failover und Edge-Cases. Führen Sie kurze Simulationen oder Tabletop-Übungen mit Ihrem Team durch. Zu wissen, wie sich Systeme unter Last verhalten, entfernt die Raterei, wenn echte Probleme auftreten.
Konfigurieren Sie Sicherheitsnetze. Aktivieren Sie – wo sinnvoll – Auto-Remediation, stellen Sie sicher, dass Backup-Kontakte definiert sind, und prüfen Sie doppelt, dass Eskalationen korrekt geroutet werden, wenn jemand nicht verfügbar ist.
Teilen Sie den Kontext proaktiv. Posten Sie kurze Updates in Slack oder Ihrem Incident-Channel zu laufenden Themen, Infrastrukturänderungen oder bekannten Risiken. Die nächste Person im Bereitschaftsdienst sollte nicht wiederentdecken müssen, was Sie bereits wissen.
Verlassen Sie sich auf Ihre Tools. Funktionen wie Supportzeiten und Feiertage existieren, um die mentale Last zu reduzieren. Lassen Sie sie die schwere Arbeit übernehmen, damit Sie nicht über Dienstpläne oder Routing nachdenken müssen.
Wenn ein Incident passiert, debriefen Sie schneller. Kurze, fokussierte Nachbesprechungen helfen Teams dabei Muster zügig zu lösen, ohne Stunden in Analysen zu versenken.
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.
