Die Alarmanalyse zeigt die häufigsten Alarme, Bestätigungsquoten, MTTA und MTTR, Lebenszyklustrends und die ältesten ungelösten Alarmgruppen.
Prometheus-Metriken erfassen Anfragelatenz, Alarmeingang, Benachrichtigungswarteschlangen und Worker-Zustand, mit optionaler Bearer-Token-Authentifizierung und Helm-ServiceMonitor-Unterstützung.
Konfigurationswerte lassen sich über Umgebungsvariablen, eingebundene Secret-Dateien und Helm-Verweise auf vorhandene Secrets oder ConfigMaps überschreiben.
Orchestrierungs-Traces zeigen passende Regeln, Ereignisänderungen und vorgeschlagene Entscheidungen im Vergleich zu den tatsächlichen Lebenszyklusergebnissen.
Alarmdetails zeigen die aktuelle Prioritätsrichtlinie und die Herkunft des Benachrichtigungsroutings; beim Verknüpfen mit Incidents lassen sich Alarmgruppen nach Titel oder ID suchen.
Docker-Images unterstützen jetzt linux/arm64 zusätzlich zu linux/amd64.
Incidents haben jetzt einen eigenen Arbeitsbereich, Lebenszyklus, eine Priorität und operative Zuständigkeit sowie Verknüpfungen zu Alarmgruppen und eine Aktivitätschronik.
Inkompatible API-Änderung: Operationen für technische Alarmgruppen wechseln zu /api/alert-groups; /api/incidents verwaltet jetzt ausschließlich operative Incidents.
Die Integration von Cloud.ru Cloud Eye empfängt signierte SMN-Alarm- und Wiederherstellungsmeldungen mit automatischer Abonnementbestätigung.
Feishu-/Lark-Kanäle liefern Textbenachrichtigungen über Webhooks benutzerdefinierter Bots mit optionaler Anfragesignatur.
Das Übersichts-Dashboard zeigt Alarmtrends, Dienstzustand, Teamaktivität, aktuelle Bereitschaftsdienste und die neuesten Aktivitäten.
Benachrichtigungsrichtlinien erhalten Filter für Priorität, Schweregrad, Quelle und Dienstattribute; Verweise auf deaktivierte Kanäle bleiben erhalten.
Mobile Alarmdetails und die Navigation über Browser-Push wurden verbessert; Grafana-Webhooks akzeptieren optionale Felder mit dem Wert null.
Alert Shelving kann Benachrichtigungen, Erinnerungen, Updates und Eskalationen für eine aktive Alert-Gruppe vorübergehend pausieren, ohne ihren technischen Status oder die Service-Auswirkungen zu verbergen.
Responder können Alerts über Weboberfläche, Browser Push, Slack, Telegram und Mattermost shelven und wieder aktivieren, einschließlich automatischem Ablauf, fortgesetzter Zustellung sowie vollständigen Timeline- und Audit-Einträgen.
Eine native Azure-Monitor-Integration nimmt Common-Alert-Schema-Webhooks an, ordnet Fired- und Resolved-Ereignisse zu, normalisiert Sev0-Sev4-Prioritäten und stellt Azure-Metadaten für das Routing bereit.
Die Ereignishistorie eingehender Child Alerts kann global vollständig, nur initial oder deaktiviert gespeichert werden; Event Orchestration kann den Modus für passende Ereignisse überschreiben, ohne operative Timeline-Einträge zu entfernen.
OIDC- und SAML-Anbieter können Identitäts-Claims Slack-, Telegram- und Mattermost-Benutzer-IDs zuordnen, sodass interaktive Benachrichtigungsaktionen einfacher per SSO bereitgestellt werden.
Löschen und erneutes Erstellen von Ressourcen sind sicherer: abhängiges Routing und Scheduler-Aufgaben werden konsistent deaktiviert, während historische Datensätze erhalten bleiben.
Die Oberfläche bietet vollständige spanische und vereinfachte chinesische Lokalisierungen.
Helm-Bereitstellungen unterstützen benutzerdefinierte CAs und eine sicherere Konfiguration ausgehender HTTP-Verbindungen in private Netze; außerdem wurden numerische Werte und statische Pfade hinter Reverse-Proxys korrigiert.
Konfigurierbare Aufbewahrungsrichtlinien können alte Verläufe gelöster Alarme, Explain Traces und Event-Orchestration-Ausführungsspuren automatisch in begrenzten Scheduler-Batches entfernen.
Event Orchestration kann für jedes passende Ereignis vollständige, kompakte oder deaktivierte Verarbeitungsspuren festlegen, mit begrenzter Pufferung und sichtbarem Kompakt- oder Kürzungsstatus.
Das Bestätigen eines korrelierten Incidents bricht nun veraltete Benachrichtigungs-, Erinnerungs- und Eskalationsaufgaben ab; untergeordnete Ereignisse gleicher oder niedrigerer Priorität bleiben bestätigt, während Ereignisse höherer Priorität die Gruppe erneut öffnen können.
Eine native New-Relic-Integration empfängt Alerts-Workflow-Benachrichtigungen und leitet normalisierte Lebenszyklusereignisse über standardmäßige IncidentRelay-Aufnahmetoken weiter.
Eine native Integration für Nagios Core und Nagios XI ordnet Host- und Service-Probleme, Wiederherstellungen und Bestätigungen zu und ignoriert dabei Ausfallzeiten, Flapping und benutzerdefinierte Benachrichtigungen.
Das Helm Chart wird nun als OCI-Artefakt in GHCR veröffentlicht, mit gehärteten Standardwerten und verbesserten Prüfungen für SQLite-sichere Deployments.
Das Dark-Theme ist in den zentralen Ansichten konsistenter, und der Orchestration-Simulator präsentiert Ergebnisse in einem klareren, benutzerfreundlicheren Format.
Event Orchestration ergänzt globale und dienstbezogene, versionierte Regeln, die eingehende Ereignisse normalisieren, anreichern, weiterleiten, gruppieren und deduplizieren können, bevor der Alarmlebenszyklus ihre Verarbeitung abschließt.
Regeln können Teams, Routen, Dienste und Richtlinien auswählen, Priorität und Schweregrad ändern, Benachrichtigungen unterdrücken, Ereignisse verzögern oder verwerfen sowie sichere asynchrone Webhooks einreihen.
Ein visueller Builder und ein JSON-Editor werden durch Validierung, Simulation, Replay, Shadow-Ausführung, Traces, Metriken sowie unveränderliche Workflows zum Veröffentlichen und Zurückrollen ergänzt – für sicherere Rollouts.
Die native Uptime-Kuma-Integration wandelt Statusänderungen von Monitoren in weitergeleitete Alarme um und löst sie automatisch, sobald sich die Monitore erholen.
Stummschaltungen und Wartungsfenster können nun rückwirkend auf ungelöste Alarme angewendet werden; betroffene Alarme lassen sich nach Ende der Unterdrückung reaktivieren, während der Status von Eskalationen und Benachrichtigungen konsistent bleibt.
Die Oberfläche bietet ein dunkles Design, gespeicherte UI-Einstellungen, eine Audit-Protokollansicht und eine vollständige französische Lokalisierung.
Persönliche API-Token erhalten granulare Berechtigungsbereiche; gleichzeitig stärken eine Drosselung von Anmeldeversuchen, sicherere ausgehende HTTP-Anfragen und strengere Validierung die Sicherheitsgrenze.
Das mitgelieferte Helm-Chart bietet einen unterstützten Weg, die Web-App und Hintergrund-Worker auf Kubernetes bereitzustellen.
PostgreSQL-Migrationen ermitteln Tabellen, Spalten und Indizes jetzt im Schema des aktiven Suchpfads. Dadurch funktionieren Upgrades auch mit einem nicht öffentlichen Schema korrekt.
Gemeinsame schemaabhängige Introspektionshilfen werden in älteren Migrationen und Schemaprüfungen verwendet und verhindern einen unsicheren Rückfall auf das öffentliche Schema.
Upgrades und Rollbacks von Migrationen führen Schemaänderungen und Migrationseinträge jetzt in derselben Datenbanktransaktion aus und verringern damit das Risiko teilweise angewendeter Migrationen.
Neue Migrationstests decken benutzerdefinierte PostgreSQL-Schemas, fehlende Relationen, die Indexsuche, Datenbank-Proxys und das Verhalten anderer Datenbanken ab.
IncidentRelay unterstuetzt jetzt UI-Lokalisierung mit englischen, russischen und deutschen Katalogen fuer Alert-, Service-, Routen-, Rotations-, Profil- und Administrationsablaufe.
Migrationswerkzeuge fuer Grafana OnCall und PagerDuty helfen Teams, vorhandene Bereitschaftsdaten nach IncidentRelay zu uebernehmen.
PagerDuty Events API v2-kompatible und Datadog-Webhook-Integrationen erweitern die unterstuetzten Alert-Quellen.
Slack Socket Mode ermoeglicht Slack-App-Interaktionen, ohne einen oeffentlichen eingehenden Slack-Endpunkt bereitzustellen.
Geheimnisse in Kanalkonfigurationen werden in API- und UI-Antworten jetzt konsistenter maskiert.
Offizielle IncidentRelay Container-Bilder werden jetzt veröffentlicht zu GitHub Container Registry und Docker Compose verwendet standardmäßig das versionierte Release-Image.
Das Helm-Diagramm wird nun als Version 1.1.0 ausgeliefert und verwendet das offizielle IncidentRelay-Bild für Kubernetes-Bereitstellungen.
Audit-Aufzeichnungen, Validierungsfehler und Bereitschaftsantworten schwärzen jetzt Geheimnisse und verhindern die Offenlegung vertraulicher Eingaben oder Datenbankdetails.
Wiederholte ackWissens- und Lösungsaktionen sind idempotent und verhindern doppelte Zeitleistenereignisse, Benachrichtigungen und Auswirkungsaktualisierungen.
Service-Links und Runbooks validieren nun externe URLs, bevor sie umsetzbare Links darstellen.
Heartbeats unterstützt jetzt Multi-Instanz-Tracking für Jobs oder Agents, die über viele Produzenten hinweg ausgeführt werden.
Die automatische Erkennung kann aus erfolgreichen Pings neue Heartbeat-Instanzen lernen, während der statische Modus eine erwartete Produzentenliste erzwingen kann.
Jede überfällige Heartbeat-Instanz kann eine eigene weitergeleitete Warnung mit Instanzbezeichnungen und unabhängigem Verhalten bei der automatischen Auflösung erstellen.
Der Heartbeat-Instanzzustand wird in der UI und API angezeigt, einschließlich der Auflistung und Deaktivierung veralteter Produzenten.
Heartbeats ermöglichen eine Totmann-Überwachung für Watchdogs, backups, ETL-Jobs, Protokollversender und andere Systeme, bei denen Schweigen der Fehlermodus ist.
Intervall- und geplante Fertigstellungsmodi können normale geroutete IncidentRelay Warnungen erzeugen, wenn erwartete Pings nicht mehr ankommen.
Heartbeat-Warnungen nutzen die bestehende Route, Eskalation, Benachrichtigung, Wartung und Service-Impact-Pipeline, mit optionaler automatischer Lösung, wenn Pings zurückkehren.
Die Bewertung der Auswirkungen auf Business Services und Servicekataloge behandelt Status, Priorität, Schweregrad und Abhängigkeitsgewichtungen jetzt detaillierter.
Business Services modellieren kundenorientierte Funktionen, die aus einem oder mehreren technischen Services bestehen.
Der berechnete Status verwendet den effektiven Komponentenzustand, die Abhängigkeitsauswirkung, die Komponentenkritikalität und konfigurierbare Auswirkungsgewichtungen.
Manuelle Statusüberschreibungen können Auswirkungen auf den Kunden beschreiben und optional automatisch ablaufen.
Business Service-Details umfassen Komponenten, Auswirkungen auf aktive Vorfälle und Statushistorie mit vollständiger Benutzeroberfläche und API-Management.
Abhängigkeitsbewusste Korrelation verknüpft verwandte aktive Alarmgruppen über Dienstabhängigkeiten hinweg.
Mögliche Grundursachen, Symptome und nachgelagerte Auswirkungen umfassen einen Konfidenzwert, eine Abhängigkeitstiefe und eine Erklärung.
Die Korrelation erscheint in Alarmlisten, Details, Zeitleisten und im Benachrichtigungskontext, bleibt jedoch beratend: Warnungen werden nicht automatisch zusammengeführt, unterdrückt oder gelöst.
Abhängigkeitsspezifische Einstellungen und Ausbreitungsverzögerungen steuern Korrelationszeit und Rauschen.
Service Impact History speichert geplante oder manuelle Point-in-Time-Snapshots von betroffenen Diensten, Alarmauswirkungen, Abhängigkeitsauswirkungen, Ursachen und Explosionsradius.
Historische Diagramme zeigen Trends und Auswirkungsgründe bei betroffenen Diensten, während Rankings Dienste identifizieren, die wiederholt betroffen sind.
Servicezuverlässigkeitsanalysen kombinieren den aktuellen Zustand von SLI/SLO mit historischen Auswirkungsdaten für operative Überprüfungen und Untersuchung von Vorfällen.
Service Context Management bietet nun klarere Switching- und Editing-Workflows für Links, Runbooks und Abhängigkeiten.
Dienste können SLIs und SLOs für Quittungslatenz, Auflösungslatenz, Incident-basierte Verfügbarkeit und Incident Counts definieren.
Durch fortlaufende Auswertungen werden Ziele als erreicht, gefährdet, verletzt oder ohne Daten klassifiziert und Verfügbarkeitsfehlerbudgets berechnet.
SLOs unterstützen Schweregrad und Prioritätsbereiche, konfigurierbare Fenster, offene Vorfälle und optionalen Wartungsfensterausschluss.
Servicedetails, aggregierte Analysen und die Service-Timeline zeigen aktuelle Messungen und Konfigurationsänderungen.
Service Notification Policies wählen freigegebene Lieferkanäle durch geordnete Regeln aus, die auf Alarm-Matchern und Ereignistypen basieren, mit Route-only, Service-Policy und kombinierten Liefermodi.
Prioritätsrichtlinien weisen P1-P5 automatisch zu, indem sie geordnete Matcher-Regeln, Teamstandards oder Dienstüberschreibungen, konfigurierbare Aktualisierungsmodi und Quell- oder Fallback-Prioritäten verwenden.
Wiederverwendbare Matcher Presets und ein freigegebener Editor bringen konsistente JSON Validierung, Formatierung und Vorschläge aus den letzten Warnungen zu Routen, Serviceregeln, Stillen, Richtlinien und Service Runbooks.
Die Einsatzkräfte können eine manuell zugewiesene Vorfallpriorität auf die automatische Verwaltung zurücksetzen, während Alert Explain Trace anzeigt, wie die Priorität ausgewählt und angewendet wurde.
E-Mail, Slack, Mattermost, Telegram und Browser-Push-Benachrichtigungen können direkt mit dem ursprünglichen Quellereignis verknüpft werden, mit verbesserter Sentry Ereignis- und Projekterkennung.
On-call Health fügt Bereitschaftsindikatoren zu Rotationen und Teams hinzu und hebt gesunde, warnende und kritische Konfigurationen hervor, bevor ein Vorfall auftritt.
Detaillierte Diagnosen erkennen leere oder deaktivierte Rotationsebenen, inaktive Mitglieder, Zeitplanlücken, ungelöste Zuweisungsziele und Probleme bei der Zustellung von Benachrichtigungen.
Zu den Gesundheitsdetails gehören die Anzahl der Probleme, das überprüfte Zeitfenster und umsetzbare Empfehlungen für die Reparatur jedes betroffenen Teams oder jeder Rotation.
Neue Zusammenfassung und Details API Endpunkte zeigen stabile, maschinenlesbare Ausgabecodes für Automatisierung, Überwachung und externe Diagnose.
Alert Explain Trace zeichnet auf, wie eingehende Warnungen verarbeitet werden, einschließlich Routenabgleich, Gruppierung, Wartungs- und Ruheentscheidungen, Benachrichtigungsplanung und Pfade für gestoppte Verarbeitung.
Integrations-Ingest-Antworten enthalten jetzt eine trace_id, wodurch Routing-Ausfälle, unterdrückte Vorfälle und verwaiste Warnmeldungen leichter von der Benutzeroberfläche oder API aus zu untersuchen sind.
Die Warnseite enthält eine Erklären-Ansicht und tiefe Links zum Öffnen von Spuren direkt aus trace_id Abfrageparametern.
Die Alerts API validiert nun Listenabfragen durch ein dediziertes Schema, verbessert Multi-Value-Filter, Paginierung, Sortierung und Zuordnungsverhalten.
LibreNMS API Transportwarnungen können nun über eine dediziertelibrenmsIntegrationsendpunkt mit normalisiertem Status, Schweregrad, Labels, Deduplizierung und Recovery-Handling.
Benutzer können eine Profilzeitzoneneinstellung festlegen, wodurch die Alarmierung und die Kalenderzeitwiedergabe für verteilte Teams verbessert werden.
Das Benachrichtigungscenter stellt ausstehende Responder-Anfragen und benutzerbezogene Incident-Aktionen über eine dedizierte API frei.
Services API Dokumentation umfasst nun Inventar, Match-Regeln, Links, Runbooks, Abhängigkeiten, Auswirkungen und Analyse-Endpunkte in einer dedizierten Referenz.
Die Warnseite kann den Filterzustand beibehalten und enthält einen zugewiesenen Filter für eine schnellere persönliche Triage.
Ein Helm-Diagramm ist jetzt für Kubernetes-Bereitstellungen verfügbar, einschließlich Web-, Scheduler- und Telegram-Arbeiterkomponenten, gerenderte Konfigurationsgeheimnisse, Sonden, Ingress-, Service-Account- und Persistenzwerte.
Dienste können Standard-Interessengruppen definieren, die in neue Incidents kopiert werden, sodass Eigentümer und Beobachter erstellte, Prioritäts-, Status- und gelöste Benachrichtigungen erhalten können.
Anfragen von Incident-Respondern werden jetzt in ein Benachrichtigungscenter eingespeist, in dem gezielte Benutzer ausstehende Anfragen sehen und diese im Incident-Workflow annehmen oder ablehnen können.
Incident- und Service-API s decken jetzt Responder, Stakeholder, Prioritäten, Services und Service Owner ab/defaultStakeholder Management.
Vorfallprioritäten verwenden jetzt eine konsistente Skala von P1 „Kritisch“ bis P5 „Information“ über alle Alarmdetails und Betriebsansichten hinweg.
Die Warnmeldungsseite unterstützt Prioritätsfilterung und -sortierung, während das Dashboard Prioritätsabzeichen und eine Zusammenfassung der Prioritätsverteilung anzeigt.
Der Schweregrad eingehender Warnungen kann die Vorfallpriorität automatisch zuweisen oder erhöhen, ohne eine manuell ausgewählte Priorität zu überschreiben oder eine vorhandene automatische Priorität zu verringern.
E-Mail, Mattermost, Telegram und Browser-Push-Benachrichtigungen enthalten jetzt Incident-Priorität, und manuelle Prioritätsänderungen können abonnierte Stakeholder per E-Mail benachrichtigen.
Read-only CalDAV sync stellt zugängliche Team-On-Call-Zeitpläne für Apple Kalender, Thunderbird, DAVx5 und andere kompatible Clients zur Verfügung.
Mit tokenisierten ICS-Abonnement-Feeds können Teams On-Call-Zeitpläne zu Outlook, Google Kalender und anderen Kalender-Clients hinzufügen, mit Steuerelementen zum Regenerieren oder Widerrufen von Feed-URLs.
Eine neue unterzeichnet Sentry Integration empfängt Problemwarnungen, metrische Warnungen und Problemlebenszyklusereignisse mit Routengeheimnissen, Deduplizierung und automatischer Lösungsbehandlung.
Die Routeneinrichtung bietet nun quellenspezifische Webhook-URLs, Token-Details und kopierfertige Curl-Beispiele.
Gesundheit und Bereitschaft Endpunkte unterstützen Kubernetes Sonden und Load Balancer Checks.
Wartungsfenster können Gruppen, Teams, Dienste oder Routen ansprechen und Benachrichtigungen unterdrücken, neue Vorfälle unterdrücken, Wartungsvorfälle erstellen oder Eskalationen pausieren.
Wartungspläne unterstützen Zeitzonen, effektive Status und wiederkehrende RFC5545-Regeln.
Antwortende können Untersuchungskommentare direkt zu Alarmgruppen erstellen, bearbeiten und löschen, wobei die Aktionen in der Alarmzeitleiste widergespiegelt werden.
Zu den Alarmdetails gehören jetzt Vorfallmanagementkontrollen für Priorität, Responder-Anfragen und Stakeholder-Benachrichtigungspräferenzen.
Gruppenmanager können Teambenutzer innerhalb ihres Zugriffsbereichs verwalten.
Entsprechende Überwachungssignale können nun unter Verwendung von konfigurierbaren Route group_by-Feldern in Alarmgruppen gesammelt werden.
Bediener können Alarmgruppen erkennen, auflösen und manuell zusammenführen und dabei ihre einzelnen untergeordneten Alarme beibehalten.
Alarmgruppenbenachrichtigungen unterstützen verzögerte Batch- und Aktualisierungsintervalle und reduzieren so den Lärm durch kurzlebige oder sich kurzfristig ausweitende Vorfälle.
Mitglieder der Rotationsschicht verfügen jetzt über Start- und Endperioden, wodurch historische Zeitpläne erhalten bleiben und zukünftige Änderungen der Mitgliedschaft unterstützt werden.
Gruppenabfragen für Warnmeldungen unterstützen mehrwertige Filter für flexiblere Incident Views und API Requests.
Administratoren können IncidentRelay-Admins aus einer Slack-Benutzergruppe mit dem neuen sync-slack-admins-Befehl erstellen oder aktualisieren.
Der Bereitschaftsstatus ist jetzt in der oberen Leiste und im Profil sichtbar, sodass Benutzer aktuelle und bevorstehende Schichten schneller sehen können.
Die Profileinstellungen umfassen jetzt den Bereitschaftsstatus und Benachrichtigungseinstellungen für E-Mail-Updates zur Schichtplanung.
Umschalt-E-Mail-Benachrichtigungen können Benutzer vor bevorstehenden Bereitschaftszeiten warnen und gleichzeitig Präferenzen und Deduplizierungsregeln respektieren.
Rotationssuchen berücksichtigen jetzt Ebenen, Überschreibungen und die Teilnahme pro Benutzer bei der Berechnung benutzerspezifischer Bereitschaftsfenster.
Die Kalender- und Rotationsansichten wurden verfeinert, um zeitgebundene Terminabfragen und einen klareren Bereitschaftskontext zu ermöglichen.
Service-Management-Modelle betrafen nun Systeme mit Eigentümern, Kritikalität, Umgebungen, Metadaten und Standardantwortpfaden.
Service-Match-Regeln können eingehende Benachrichtigungen zu Diensten von Routenstandards, Labels, Anmerkungen und Nutzlastfeldern abbilden.
Serviceabhängigkeiten und Impact-Metadaten zeigen nun, wie sich Upstream-Services auf verwandte Systeme und offene Alarme auswirken.
Von der Integration bereitgestellte Runbooks können aus Warnungsnutzlasten angehängt und vor Service-Level-Runbooks angezeigt werden.
Die Services-Benutzeroberfläche und API legen Serviceinventar, Übereinstimmungsregeln, Abhängigkeiten und den Einflusskontext für Operations-Workflows offen.
Rotationen unterstützen jetzt mehrschichtige Bereitschaftspläne mit Prioritäten, aktiven Zeitbeschränkungen, Mitgliedern pro Schicht und zeitzonenbezogenen Übergaberegeln.
Der Kalender stellt nun den endgültigen Zeitplan aus Layers und Overrides dar, so dass Teams den effektiven On-Call-Benutzer für jedes Zeitsegment inspizieren können.
Die Kalenderfilterung unterstützt jetzt die Auswahl einer bestimmten Rotation, wenn ein Team über mehrere Zeitpläne verfügt.
Rotation API s stellen jetzt Layer-, Layer-Mitglieder- und Layer-Einschränkungsendpunkte für Automatisierung und Integrationen bereit.
Rotationserinnerungsintervalle können jetzt auf 0 gesetzt werden, um wiederholte Erinnerungen für Warnungen zu deaktivieren, die durch diese Rotation zugewiesen wurden.
Die auf Erinnerungen basierende Eskalation berücksichtigt jetzt deaktivierte Erinnerungen, anstatt auf ein globales Erinnerungsintervall zu fallen.
Der Schweregradfilter für Warnmeldungen enthält jetzt Warn- und Informationsschweregrade für eine genauere Triage.
persönlich API Token-Lebensdauern sind jetzt auf 365 Tage begrenzt, während immer noch nicht auslaufende Token mit 0 Tagen erlaubt sind.
Die Benachrichtigungszustellung verwendet jetzt dedizierte Benachrichtigungen für E-Mail, Mattermost, Telegram und Sprachanrufkanäle.
Mattermost Bot API-Benachrichtigungen können Warnmeldungen mit statusbewussten Nachrichten und Aktionsschaltflächen erstellen und aktualisieren.
Sprachanrufbenachrichtigungen verwenden jetzt den konfigurierten Sprachanbieter mit gesprochenem Alarmtext, Rückrufunterstützung und DTMF-Aktionsmapping.
Die Dokumentation von Channels API enthält jetzt unterstützte Kanaltypen, den Standard-E-Mail-Vorlagen-Endpunkt und klarere Kanalschemata.
Die Silences-Seite kann von Sammelkarten gefiltert werden und optional abgelaufene Geschichte enthalten, die älter als 30 Tage ist.
Docker und Systemd Documentation verwenden nun den Unified Service Name incidentrelay anstelle von incidentrelay-web.
Warnungen verfügen jetzt über gemeinsam nutzbare Detailseiten, sodass es einfacher ist, einen direkten Link zum Vorfall an Teamkollegen zu senden.
Der Eskalationsfortschritt ist direkt in den Warnmeldungen sichtbar und hilft den Einsatzkräften zu verstehen, wie weit ein Vorfall eskaliert ist.
Der Alarmzustand lässt sich leichter durch klarer aufgelöste und Eskalationsebenendaten in der API verfolgen.
Telegram Benachrichtigungen können auf die zugehörige Benachrichtigung verweisen und die richtigen Aktionsschaltflächen für den aktuellen Zustand anzeigen.
Telegram Die Unterstützung umfasst Rich Messages, interaktive Aktionen, Inline-Buttons und den Polling-Modus.
Benachrichtigungskanäle können Schweregradfilter mit normalisierter Schweregradbehandlung für eine vorhersehbarere Weiterleitung verwenden.
Bereitschaftsüberschreibungen sind mit einem wiederverwendbaren Modal, einem schnelleren zwischengespeicherten Status und kalenderbewusstem Verhalten einfacher zu verwalten.
Verwaltungs-, Profil-, Kalender-, Rotations- und Warnbildschirme wurden für klarere tägliche Abläufe neu gestaltet.