L’analyse des alertes affiche les alertes les plus bruyantes, les taux d’acquittement, le MTTA et le MTTR, les tendances du cycle de vie et les groupes d’alertes non résolus les plus anciens.
Les métriques Prometheus exposent la latence des requêtes, la réception des alertes, les files de notifications et l’état des workers, avec authentification facultative par jeton bearer et prise en charge de ServiceMonitor dans Helm.
La configuration peut être remplacée par des variables d’environnement, des fichiers de secrets montés et des références Helm à des Secrets ou ConfigMaps existants.
Les traces d’exécution de l’orchestration affichent les règles correspondantes, les modifications des événements et les décisions proposées face aux résultats réels du cycle de vie.
Les détails des alertes affichent la politique de priorité actuelle et l’origine du routage des notifications ; la liaison à un incident permet de rechercher les groupes d’alertes par titre ou identifiant.
Les images Docker prennent désormais en charge linux/arm64 en plus de linux/amd64.
Les incidents disposent désormais de leur propre espace de travail, cycle de vie, priorité et responsable opérationnel, avec liaison aux groupes d’alertes et historique des activités.
Changement incompatible de l’API : les opérations sur les groupes d’alertes techniques passent à /api/alert-groups ; /api/incidents gère désormais uniquement les incidents opérationnels.
L’intégration Cloud.ru Cloud Eye reçoit les notifications SMN signées d’alarme et de rétablissement avec confirmation automatique de l’abonnement.
Les canaux Feishu / Lark transmettent des notifications textuelles via les webhooks de bots personnalisés, avec signature facultative des requêtes.
Le tableau de bord de la vue d’ensemble affiche les tendances des alertes, l’état des services, l’activité des équipes, les intervenants actuellement d’astreinte et les activités récentes.
Les politiques de notification ajoutent des filtres par priorité, gravité, source et attributs du service, tout en conservant les références aux canaux désactivés.
Les détails des alertes sur mobile et la navigation depuis les notifications push du navigateur sont améliorés ; les webhooks Grafana acceptent les champs facultatifs définis sur null.
La mise en attente des alertes peut suspendre temporairement les notifications, rappels, mises à jour et escalades pour un groupe d’alertes actif sans masquer son état technique ni son impact sur le service.
Les intervenants peuvent mettre en attente et réactiver les alertes depuis l’interface web, les notifications push du navigateur, Slack, Telegram et Mattermost, avec expiration automatique, reprise de la livraison et enregistrements complets dans la chronologie et l’audit.
Une intégration native Azure Monitor accepte les webhooks Common Alert Schema, associe les événements Fired et Resolved, normalise les priorités Sev0-Sev4 et expose les métadonnées Azure pour le routage.
L’historique des événements des alertes enfants entrantes peut être stocké globalement en mode complet, initial uniquement ou désactivé, tandis qu’Event Orchestration peut remplacer ce mode pour les événements correspondants sans supprimer les entrées opérationnelles de la chronologie.
Les fournisseurs OIDC et SAML peuvent associer des attributs d’identité aux identifiants utilisateur Slack, Telegram et Mattermost, ce qui facilite le provisionnement des actions interactives via SSO.
La suppression et la recréation des ressources sont plus sûres : le routage dépendant et les tâches du planificateur sont désactivés de manière cohérente tandis que les enregistrements historiques sont conservés.
L’interface ajoute des localisations complètes en espagnol et en chinois simplifié.
Les déploiements Helm prennent en charge les autorités de certification personnalisées et une configuration HTTP sortante plus sûre vers les réseaux privés, avec des correctifs pour les valeurs numériques et les chemins statiques derrière les reverse proxies.
Des politiques de conservation configurables peuvent supprimer automatiquement l’ancien historique des alertes résolues, les Explain Traces et les traces d’exécution d’Event Orchestration par lots bornés du planificateur.
Event Orchestration peut définir des traces de traitement complètes, compactes ou désactivées pour chaque événement correspondant, avec une mise en mémoire tampon bornée et un état compact ou tronqué visible.
L’acquittement d’un incident corrélé annule désormais les notifications, rappels et escalades obsolètes ; les événements enfants de priorité identique ou inférieure restent acquittés, tandis que les événements de priorité supérieure peuvent rouvrir le groupe.
Une intégration native New Relic reçoit les notifications d’incident Alerts Workflow et achemine les événements de cycle de vie normalisés via les jetons d’entrée IncidentRelay standard.
Une intégration native Nagios Core et Nagios XI associe les problèmes d’hôtes et de services, les rétablissements et les acquittements, tout en ignorant les indisponibilités planifiées, le flapping et les notifications personnalisées.
Le chart Helm est désormais publié sur GHCR comme artefact OCI, avec des valeurs par défaut renforcées et de meilleurs contrôles de déploiement compatibles avec SQLite.
Le thème sombre est plus cohérent dans les vues principales, et le simulateur Orchestration présente les résultats dans un format plus clair et plus convivial.
Event Orchestration ajoute des règles versionnées, globales ou propres à un service, capables de normaliser, enrichir, router, regrouper et dédupliquer les événements entrants avant la fin de leur traitement par le cycle de vie des alertes.
Les règles peuvent sélectionner des équipes, routes, services et politiques, modifier la priorité et la gravité, supprimer les notifications, retarder ou abandonner des événements et mettre en file d’attente des webhooks asynchrones sécurisés.
Un constructeur visuel et un éditeur JSON s’appuient sur la validation, la simulation, le replay, l’exécution en mode fantôme, les traces, les métriques et des workflows immuables de publication et de restauration pour des déploiements plus sûrs.
L’intégration native Uptime Kuma transforme les changements d’état des moniteurs en alertes routées et les résout automatiquement lorsque les moniteurs se rétablissent.
Les silences et fenêtres de maintenance peuvent désormais s’appliquer rétroactivement aux alertes non résolues ; les alertes concernées peuvent être réactivées à la fin de la suppression, tout en maintenant un état cohérent des escalades et notifications.
L’interface ajoute un thème sombre, des préférences d’interface enregistrées, une vue des journaux d’audit et une localisation française complète.
Les jetons API personnels bénéficient de portées granulaires, tandis que la limitation des tentatives de connexion, la sécurisation des requêtes HTTP sortantes et une validation plus stricte renforcent le périmètre de sécurité.
Le chart Helm inclus fournit une méthode prise en charge pour déployer l’application web et les workers en arrière-plan sur Kubernetes.
Les migrations PostgreSQL résolvent désormais les tables, colonnes et index dans le schéma sélectionné par le chemin de recherche actif, corrigeant les mises à niveau qui utilisent un schéma non public.
Des utilitaires d’introspection partagés et sensibles au schéma sont utilisés dans les anciennes migrations et les vérifications de schéma, évitant un repli dangereux vers le schéma public.
Les mises à niveau et les retours arrière de migration conservent désormais les changements de schéma et les enregistrements de migration dans la même transaction, ce qui réduit le risque de migrations partiellement appliquées.
Les nouveaux tests de migration couvrent les schémas PostgreSQL personnalisés, les relations absentes, la recherche d’index, les proxys de base de données et le comportement des autres bases.
IncidentRelay prend maintenant en charge la localisation de l UI avec des catalogues anglais, russes et allemands pour les workflows d alertes, services, routes, rotations, profils et administration.
Les outils de migration Grafana OnCall et PagerDuty aident les equipes a transferer leurs donnees d astreinte existantes vers IncidentRelay.
Les integrations webhook compatibles PagerDuty Events API v2 et Datadog etendent les sources d alertes prises en charge.
Le support de Slack Socket Mode permet les interactions d application Slack sans exposer de point d entree Slack public.
Les secrets de configuration des canaux sont masques plus systematiquement dans les reponses API et UI.
Les images de conteneur officiel IncidentRelay sont maintenant publiées à GitHub Container Registry, et Docker Compose utilise l'image de sortie version par défaut.
Le graphique Helm est maintenant livré en version 1.1.0 et utilise l'image officielle IncidentRelay pour les déploiements Kubernetes.
Les enregistrements d'audit, les erreurs de validation et les réponses de préparation expurgent désormais les secrets et évitent d'exposer les entrées sensibles ou les détails de la base de données.
Les actions répétées de acknowledge et de résolution sont idempotentes, évitant ainsi les événements de chronologie, les notifications et les mises à jour d'impact en double.
Les liens de service et les runbooks valident désormais les URLs externes avant de rendre les liens actionnables.
Heartbeats prend désormais en charge le tracking multi-instance pour les tâches ou les agents exécutés sur de nombreux producteurs.
La découverte automatique peut apprendre de nouvelles instances de battement de cœur à partir de pings réussis, tandis que le mode statique peut appliquer une liste de producteurs attendue.
Chaque instance de pulsation en retard peut créer sa propre alerte acheminée avec des étiquettes d'instance et un comportement de résolution automatique indépendant.
L'état d'instance de battement cardiaque est exposé dans l'interface utilisateur et API, y compris l'inscription et la désactivation des producteurs obsolètes.
Heartbeats ajoute une surveillance par interrupteur d'homme mort pour les chiens de garde, les backups, les tâches ETL, les expéditeurs de journaux et autres systèmes où le silence est le mode de défaillance.
Les modes d'intervalle et d'achèvement programmé peuvent créer des alertes routées normales IncidentRelay lorsque les pings attendus cessent d'arriver.
Les alertes Heartbeat utilisent le pipeline d'itinéraire, d'escalade, de notification, de maintenance et d'impact sur le service existant, avec une résolution automatique facultative au retour des pings.
La notation d’impact des services métiers et du catalogue de services gère désormais les pondérations d’état, de priorité, de gravité et de dépendance de manière plus granulaire.
Les services métiers modélisent des capacités orientées client composées d'un ou plusieurs services techniques.
L’état calculé utilise l’état effectif des composants, l’impact des dépendances, la criticité des composants et des pondérations d’impact configurables.
Les remplacements de statut manuels peuvent décrire l’impact sur le client et éventuellement expirer automatiquement.
Les détails du service d'affaires comprennent les composantes, l'impact actif de l'incident et l'historique du statut, avec l'assurance-chômage complète et la gestion API.
La corrélation tenant compte des dépendances relie les groupes d’alertes actifs associés aux dépendances de service.
Les causes profondes possibles, les symptômes et l’impact en aval incluent un score de confiance, la profondeur de la dépendance et une explication.
La corrélation apparaît dans les listes d'alertes, les détails, les délais et le contexte de notification tout en restant consultative : les alertes ne sont pas fusionnées, supprimées ou résolues automatiquement.
Les paramètres de dépendance et les délais de propagation contrôlent le timing et le bruit de corrélation.
L'historique de l'impact du service stocke des instantanés ponctuels ou manuels des services touchés, de l'impact d'alerte, de l'impact de dépendance, des causes profondes et du rayon d'explosion.
Les graphiques historiques montrent les tendances des services concernés et les raisons de leur impact, tandis que les classements identifient les services qui sont affectés à plusieurs reprises.
L'analyse de la fiabilité du service combine la santé actuelle de SLI/SLO avec les données historiques d'impact pour les examens opérationnels et les enquêtes sur les incidents.
La gestion du contexte du service fournit désormais des flux de travail de commutation et d'édition plus clairs pour les liens, les runbooks et les dépendances.
Les services peuvent définir les SLI et les SLO pour la latence de reconnaissance, la latence de résolution, la disponibilité basée sur les incidents et le dénombrement des incidents.
Les évaluations continues classent les objectifs comme atteints, à risque, violés ou sans données et calculent les budgets d'erreur de disponibilité.
Les ALS supportent la gravité et les champs de priorité, les fenêtres configurables, les incidents ouverts et l'exclusion facultative de la fenêtre d'entretien.
Les détails du service, l'analyse globale et le calendrier de service exposent les mesures actuelles et les changements de configuration.
Les politiques de notification des services sélectionnent les modes de prestation partagés au moyen de règles ordonnées basées sur les apparieurs d'alerte et les types d'événements, avec des modes de prestation combinés et de service uniquement sur la route.
Les politiques de priorité attribuent automatiquement P1 à P5 à l'aide de règles de correspondance ordonnées, de valeurs par défaut d'équipe ou de remplacements de service, de modes de mise à jour configurables et de priorités source ou fallback.
Les préréglages de Matcher réutilisables et un éditeur partagé apportent une validation, un formatage et des suggestions cohérentes JSON des alertes récentes aux itinéraires, aux règles de service, aux silences, aux politiques et aux runbooks de service.
Les intervenants peuvent réinitialiser une priorité d'incident attribuée manuellement à la gestion automatique, tandis qu'Alert Explain Trace montre comment la priorité a été sélectionnée et appliquée.
L'email, Slack, Mattermost, Telegram et les notifications de poussée du navigateur peuvent être reliés directement à l'événement source d'origine, avec une détection améliorée de l'événement Sentry et du projet.
On-call Health ajoute des indicateurs de préparation aux rotations et aux équipes, mettant en évidence les configurations saines, d'avertissement et critiques avant qu'un incident ne se produise.
Des diagnostics détaillés détectent les couches de rotation vides ou désactivées, les membres inactifs, les écarts de planification, les objectifs d'affectation non résolus et les problèmes d'envoi de notifications.
Les détails de santé incluent le nombre de problèmes, la fenêtre de temps vérifiée et des recommandations concrètes pour réparer chaque équipe ou rotation affectée.
Les nouveaux paramètres de synthèse et de détail API exposent des codes de problèmes stables lisibles par machine pour l'automatisation, la surveillance et le diagnostic externe.
Alert Explain Trace enregistre la manière dont les alertes entrantes sont traitées, y compris la correspondance des itinéraires, le regroupement, les décisions de maintenance et de silence, la planification des notifications et les chemins de traitement arrêtés.
Les réponses à l'ingestion d'intégration comprennent maintenant un trace_id, ce qui rend les défaillances de routage, les incidents supprimés et les alertes résolues orphelines plus faciles à enquêter depuis l'interface utilisateur ou API.
La page Alertes comprend une vue Explique et des liens profonds pour ouvrir les traces directement à partir des paramètres de requête trace_id.
Les Alertes API valident désormais les requêtes de la liste à travers un schéma dédié, améliorant les filtres multi-valeurs, la pagination, le tri et le comportement des requêtes assignées à moi.
LibreNMS API Les alertes de transport peuvent maintenant être reçues au moyen d'un paramètre d'intégration librenms dédié avec un statut, une sévérité, des étiquettes, une déduplication et une manipulation de récupération normalisées.
Les utilisateurs peuvent définir une préférence de fuseau horaire de profil, améliorant l'alerte et le rendu du calendrier pour les équipes distribuées.
Le centre de notification expose les demandes de réponse en attente et les actions d'incident face à l'utilisateur via un API dédié.
La documentation Services API couvre désormais l'inventaire, les règles de correspondance, les liens, les runbooks, les dépendances, les paramètres d'impact et d'analyse dans une référence dédiée.
La page Alertes peut préserver l'état du filtre et comprend un filtre assigné à moi pour un triage personnel plus rapide.
Un graphique Helm est maintenant disponible pour les déploiements Kubernetes, y compris les composants web, programmateur et Telegram travailleurs, les secrets de configuration rendus, les sondes, l'entrée, le compte de service et les valeurs de persistance.
Les services peuvent définir les intervenants par défaut qui sont copiés dans de nouveaux incidents, de sorte que les propriétaires et les observateurs peuvent recevoir des notifications créées, prioritaires, de statut et résolues.
Les demandes des intervenants en cas d'incident alimentent désormais un centre de notification où les utilisateurs ciblés peuvent voir les demandes en attente et les accepter ou les refuser du flux de travail des incidents.
Les API d'incident et de service couvrent désormais les intervenants, les intervenants, les priorités, les services et la gestion des intervenants /default.
Les priorités des incidents utilisent désormais une échelle d’information cohérente P1 Critique à P5 pour les détails des alertes et les vues opérationnelles.
La page Alertes prend en charge le filtrage et le tri des priorités, tandis que le tableau de bord affiche les badges de priorité et un résumé de distribution des priorités.
La gravité des alertes entrantes peut automatiquement attribuer ou augmenter la priorité des incidents sans écraser une priorité sélectionnée manuellement ni réduire une priorité automatique existante.
Le courriel, Mattermost, Telegram et les notifications de poussée du navigateur incluent maintenant la priorité d'incident, et les changements de priorité manuelle peuvent aviser les intervenants abonnés par courriel.
En lecture seule CalDAV sync expose les horaires de l'équipe accessible sur appel à Apple Calendar, Thunderbird, DAVx5 et d'autres clients compatibles.
Les flux d'abonnement tokenized ICS permettent aux équipes d'ajouter des horaires sur appel à Outlook, Google Calendar et d'autres clients de calendrier, avec des contrôles pour régénérer ou révoquer les URL de flux.
Une nouvelle intégration Sentry signée reçoit des alertes de sortie, des alertes métriques et des événements du cycle de vie, avec des secrets de route, de duplication et de résolution automatique.
La configuration du parcours fournit désormais des URL webhooks spécifiques à la source, des détails de jeton et des exemples de boucles prêtes à être copiées.
Les paramètres de santé et de préparation supportent les sondes Kubernetes et les vérifications de l'équilibreur de charge.
Impact sur le service v2 montre l'état actuel du service, les causes profondes, les chemins de dépendance et le rayon de souffle en aval.
Service Analytics v2 combine des incidents groupés, un volume d'alerte brut, des mesures de bruit et de déduplication, des compteurs de maintenance et des données de temps de réponse.
L'expérience des Services comprend maintenant des points de vue plus riches sur l'impact et l'analyse avec des graphiques et des résumés opérationnels plus clairs.
Les contrôles de sélection des utilisateurs entre les équipes, les groupes, les rotations et les workflows d'escalade ont des étiquettes plus claires et des mises à jour dynamiques.
Maintenance Windows peut cibler des groupes, des équipes, des services ou des itinéraires et supprimer des notifications, supprimer de nouveaux incidents, créer des incidents de maintenance ou suspendre les escalades.
Les calendriers de maintenance prennent en charge les fuseaux horaires, les statuts effectifs et les règles RFC5545 récurrentes.
Les intervenants peuvent créer, modifier et supprimer des commentaires d'enquête directement sur les groupes d'alerte, les actions étant reflétées dans la chronologie des alertes.
Les détails des alertes incluent désormais des contrôles de gestion des incidents pour la priorité, les demandes des intervenants et les préférences de notification des parties prenantes.
Les responsables de groupe peuvent gérer les utilisateurs de l'équipe dans le cadre de leur périmètre d'accès.
Les signaux de surveillance connexes peuvent maintenant être collectés dans des groupes d'alerte en utilisant des champs de route group_by configurables.
Les opérateurs peuvent ackconnaître, résoudre et fusionner manuellement des groupes d'alertes tout en conservant leurs alertes enfants individuelles.
Les notifications de groupe d'alerte prennent en charge les intervalles de traitement par lots et de mise à jour retardés, réduisant ainsi le bruit des incidents de courte durée ou à expansion rapide.
Les membres de la couche de rotation ont désormais des périodes de début et de fin, préservant les planifications historiques et prenant en charge les modifications futures des membres.
Les requêtes de groupe d'alerte prennent en charge les filtres multi-valeurs pour des vues d'incident plus flexibles et des requêtes API.
Les administrateurs peuvent créer ou mettre à jour des admins IncidentRelay à partir d'un groupe d'utilisateurs Slack avec la nouvelle commande sync-slack-admins.
Les notifications de poussée du navigateur/PWA sont maintenant disponibles pour les utilisateurs assignés à partir de leurs périphériques de profil.
Les notifications de poussée du navigateur peuvent inclure des actions de courte durée ACK et Resolve.
Les règles de notification de profil permettent aux utilisateurs de définir la livraison de suivi via le navigateur, par e-mail ou par appel vocal.
La livraison des notifications gère désormais de manière plus fiable les contrôles de livraison ignorés et le comportement push du navigateur.
Les alertes et les tableaux de style administrateur utilisent désormais des outils de filtrage et de pagination réutilisables pour les ensembles de données plus volumineux.
L'état de garde est désormais visible dans la barre supérieure et dans l'expérience de profil, afin que les utilisateurs puissent voir plus rapidement les équipes en cours et à venir.
Les paramètres de profil incluent désormais le statut d'astreinte et les préférences de notification pour les mises à jour par e-mail de planification des équipes.
Les notifications par e-mail Shift peuvent avertir les utilisateurs des périodes à venir sur appel tout en respectant les préférences et les règles de déduplication.
Les recherches de rotation tiennent désormais compte des couches, des remplacements et de la participation de chaque utilisateur lors du calcul des fenêtres de garde spécifiques à l'utilisateur.
Les vues du calendrier et de la rotation ont été affinées autour de recherches d'horaires limités dans le temps et d'un contexte d'astreinte plus clair.
La gestion des services permet désormais de modéliser les systèmes touchés par les propriétaires, la criticité, les environnements, les métadonnées et les chemins de réponse par défaut.
Les règles de correspondance de service peuvent cartographier les alertes entrantes aux services à partir des champs par défaut de route, étiquettes, annotations et charge utile.
Les dépendances du service et les métadonnées d'impact montrent maintenant comment les services en amont affectent les systèmes connexes et les alertes ouvertes.
Les runbooks fournis par l'intégration peuvent être joints à partir des charges utiles d'alerte et affichés avant les runbooks de niveau service.
L'interface utilisateur des services et API exposent l'inventaire des services, les règles de correspondance, les dépendances et le contexte d'impact pour les flux de travail opérationnels.
Les politiques de remontée d’alerte prennent désormais en charge les chaînes de remontée d’alerte en plusieurs étapes par équipe.
Routes peuvent utiliser le mode politique d'escalade au lieu d'attribuer directement par une seule rotation.
Les règles de stratégie peuvent cibler des rotations ou des utilisateurs spécifiques avec des retards ordonnés et des décomptes de répétitions.
L'interface utilisateur des politiques d'escalation et API permettent aux équipes de créer, de modifier et d'inspecter les politiques et les règles de politique.
Le calendrier de rotation et les workflows de remplacement ont été affinés autour du nouveau modèle de remontée d'informations.
L'authentification SSO prend désormais en charge les fournisseurs OIDC et SAML 2.0.
Les administrateurs peuvent configurer les fournisseurs SSO, les politiques de connexion, les domaines autorisés et les mappages de groupes externes à partir de la nouvelle page SSO.
La page de connexion peut afficher les boutons du fournisseur SSO activés et rediriger les utilisateurs via le fournisseur d'identité sélectionné.
La connexion SSO peut créer automatiquement ou lier les utilisateurs et synchroniser les groupes externes aux rôles de groupe IncidentRelay.
Les métadonnées SAML, les options de signature et les secrets cryptés SSO sont maintenant documentés et exposés par le flux SSO.
L'interface utilisateur de l'application a reçu un rafraîchissement de style matériel avec une navigation plus propre et des interactions de profil /routes améliorées.
Les rotations prennent désormais en charge les horaires de garde à plusieurs niveaux avec des priorités, des restrictions de temps actif, des membres par couche et des règles de transfert tenant compte des fuseaux horaires.
Le calendrier rend maintenant le calendrier final à partir de couches et de dépassements, de sorte que les équipes peuvent inspecter l'utilisateur effectif sur appel pour chaque segment de temps.
Le filtrage du calendrier prend désormais en charge la sélection d'une rotation spécifique lorsqu'une équipe a plusieurs plannings.
Les API de rotation exposent désormais les points de terminaison de couche, de membre de couche et de restriction de couche pour l'automatisation et les intégrations.
Les intervalles de rappel de rotation peuvent désormais être définis sur 0 pour désactiver les rappels répétés pour les alertes attribuées lors de cette rotation.
L'escalade basée sur les rappels respecte désormais les rappels désactivés au lieu de tomber back à un intervalle de rappel global.
Le filtre de gravité de la page Alerts inclut maintenant des avertissements et des détails pour un triage plus précis.
Les durées de vie des jetons personnels API sont maintenant plafonnées à 365 jours tout en permettant des jetons non-expirants avec 0 jours.
La notification de livraison utilise désormais des notifiants dédiés pour les canaux de messagerie, Mattermost, Telegram et d'appel vocal.
Mattermost Les notifications Bot API peuvent créer et mettre à jour des messages d'alerte avec des messages de statut et des boutons d'action.
Les notifications d'appels téléphoniques utilisent désormais le fournisseur de voix configuré avec un texte d'alerte parlé, un support de callback et un mapping d'action DTMF.
La documentation Canaux API inclut désormais les types de canal pris en charge, le paramètre de template par défaut et les schémas de canal plus clairs.
La page Silences peut filtrer à partir de cartes sommaires et éventuellement inclure l'historique expiré plus de 30 jours.
Docker et la documentation système utilisent maintenant le nom de service unifié incidentrelay au lieu de incidentrelay-web.
Les notifications par e-mail peuvent désormais utiliser des modèles HTML personnalisables pour des messages d'alerte plus riches et plus cohérents.
Les paramètres du canal de messagerie incluent des contrôles de modèle et des espaces réservés pris en charge directement dans l'interface utilisateur.
La livraison des e-mails est plus fiable lorsque les équipes utilisent des modèles personnalisés ou des paramètres SMTP globaux.
L'administration des utilisateurs utilise désormais des noms de rôles plus clairs et des flux de travail plus détaillés en matière de gestion des rôles.
Les listes d'équipes et de groupes se concentrent maintenant sur les dossiers actifs, réduisant ainsi l'encombrement dans l'administration quotidienne.
La validation est plus cohérente dans les formulaires API, de sorte que les valeurs non valides sont capturées plus tôt et rapportées de façon plus prévisible.
Les champs de numéro de téléphone sont plus faciles à remplir correctement grâce à une validation plus stricte, une normalisation et un flux frontal immédiatback.
Les messages d'état de connexion et de formulaire donnent désormais des informations plus clairesback lors des flux de configuration et d'administration courants.
Les alertes comportent désormais des pages de détails partageables, ce qui facilite l'envoi d'un lien direct d'incident aux coéquipiers.
La progression de l’escalade est visible directement sur les alertes, aidant ainsi les intervenants à comprendre jusqu’où un incident a dégénéré.
L'état d'alerte est plus facile à suivre grâce à des données plus claires et à un niveau d'escalade dans le API.
Les notifications Telegram peuvent renvoyer à l'alerte correspondante et afficher les bons boutons d'action pour l'état courant.
Le support Telegram inclut des messages riches, des actions interactives, des boutons en ligne et le mode de vote.
Les canaux de notification peuvent utiliser des filtres de gravité avec une gestion normalisée de la gravité pour un routage plus prévisible.
Les remplacements d'astreinte sont plus faciles à gérer grâce à un mode modal réutilisable, un état de mise en cache plus rapide et un comportement tenant compte du calendrier.
Les écrans d’administration, de profil, de calendrier, de rotation et d’alerte ont été repensés pour des opérations quotidiennes plus claires.