La analítica de alertas muestra las alertas más ruidosas, tasas de reconocimiento, MTTA y MTTR, tendencias del ciclo de vida y los grupos de alertas sin resolver más antiguos.
Las métricas de Prometheus muestran latencia de solicitudes, recepción de alertas, colas de notificaciones y estado de los workers, con autenticación opcional mediante token bearer y compatibilidad con ServiceMonitor en Helm.
La configuración permite sobrescribir valores mediante variables de entorno, archivos de secretos montados y referencias de Helm a Secrets o ConfigMaps existentes.
Las trazas de ejecución de la orquestación muestran las reglas coincidentes, los cambios en los eventos y las decisiones propuestas frente a los resultados reales del ciclo de vida.
Los detalles de las alertas muestran la política de prioridad actual y el origen del enrutamiento de notificaciones; al vincular un incidente, se pueden buscar grupos de alertas por título o ID.
Las imágenes de Docker ahora admiten linux/arm64 además de linux/amd64.
Los incidentes ahora tienen su propio espacio de trabajo, ciclo de vida, prioridad y responsable operativo, con vinculación de grupos de alertas e historial de actividad.
Cambio incompatible en la API: las operaciones de grupos técnicos de alertas pasan a /api/alert-groups; /api/incidents ahora solo gestiona incidentes operativos.
La integración con Cloud.ru Cloud Eye recibe notificaciones SMN firmadas de alarma y recuperación con confirmación automática de la suscripción.
Los canales de Feishu / Lark entregan notificaciones de texto mediante webhooks de bots personalizados, con firma opcional de solicitudes.
El panel de la vista general incorpora tendencias de alertas, estado de los servicios, actividad de los equipos, responsables de guardia actuales y actividad reciente.
Las políticas de notificación incorporan filtros por prioridad, gravedad, fuente y atributos del servicio, conservando las referencias a canales desactivados.
Se mejoran los detalles de las alertas en móviles y la navegación desde las notificaciones push del navegador; los webhooks de Grafana aceptan campos opcionales con valor null.
El aplazamiento de alertas puede pausar temporalmente notificaciones, recordatorios, actualizaciones y escalados de un grupo de alertas activo sin ocultar su estado técnico ni el impacto en el servicio.
Los respondedores pueden aplazar y reactivar alertas desde la interfaz web, las notificaciones push del navegador, Slack, Telegram y Mattermost, con vencimiento automático, reanudación de la entrega y registros completos de cronología y auditoría.
Una integración nativa con Azure Monitor acepta webhooks del Common Alert Schema, asigna eventos Fired y Resolved, normaliza prioridades Sev0-Sev4 y expone metadatos de Azure para el enrutamiento.
El historial de eventos de alertas secundarias entrantes puede almacenarse globalmente en modo completo, solo inicial o desactivado, mientras Event Orchestration puede sobrescribir el modo para eventos coincidentes sin eliminar entradas operativas de la cronología.
Los proveedores OIDC y SAML pueden asignar atributos de identidad a identificadores de usuario de Slack, Telegram y Mattermost, facilitando el aprovisionamiento de acciones interactivas mediante SSO.
La eliminación y recreación de recursos es más segura: el enrutamiento dependiente y el trabajo del planificador se desactivan de forma coherente mientras se conservan los registros históricos.
La interfaz añade localizaciones completas en español y chino simplificado.
Los despliegues con Helm incorporan certificados de CA personalizados y una configuración HTTP saliente más segura para redes privadas, además de correcciones para valores numéricos y rutas estáticas detrás de proxies inversos.
Las políticas de retención configurables pueden eliminar automáticamente el historial antiguo de alertas resueltas, los Explain Traces y las trazas de ejecución de Event Orchestration en lotes limitados del planificador.
Event Orchestration puede establecer trazas de procesamiento completas, compactas o desactivadas para cada evento coincidente, con almacenamiento en búfer limitado y estado compacto o truncado visible.
Confirmar un incidente correlacionado ahora cancela notificaciones, recordatorios y escalados obsoletos; los eventos secundarios de igual o menor prioridad permanecen confirmados, mientras que los de mayor prioridad pueden reabrir el grupo.
Una integración nativa con New Relic recibe notificaciones de incidencias de Alerts Workflow y enruta eventos de ciclo de vida normalizados mediante los tokens de entrada estándar de IncidentRelay.
Una integración nativa con Nagios Core y Nagios XI asigna problemas de hosts y servicios, recuperaciones y confirmaciones, e ignora tiempos de inactividad, flapping y notificaciones personalizadas.
El chart de Helm ahora se publica en GHCR como artefacto OCI, con valores predeterminados reforzados y mejores comprobaciones de despliegue seguro con SQLite.
El tema oscuro es más coherente en las vistas principales y el simulador de Orchestration presenta los resultados en un formato más claro y accesible.
Event Orchestration añade reglas versionadas globales y por servicio que pueden normalizar, enriquecer, enrutar, agrupar y deduplicar eventos entrantes antes de que termine de procesarlos el ciclo de vida de la alerta.
Las reglas pueden seleccionar equipos, rutas, servicios y políticas, cambiar la prioridad y la gravedad, silenciar notificaciones, retrasar o descartar eventos y poner en cola webhooks asíncronos seguros.
Un constructor visual y un editor JSON cuentan con validación, simulación, replay, ejecución en sombra, trazas, métricas y flujos inmutables de publicación y rollback para despliegues más seguros.
La integración nativa con Uptime Kuma convierte los cambios de estado de los monitores en alertas enrutadas y las resuelve automáticamente cuando los monitores se recuperan.
Los silencios y las ventanas de mantenimiento ahora pueden aplicarse de forma retroactiva a alertas sin resolver; las alertas afectadas pueden reactivarse cuando termina la supresión, manteniendo coherentes los estados de escalado y notificación.
La interfaz añade un tema oscuro, preferencias de UI guardadas, una vista del registro de auditoría y localización completa al francés.
Los tokens personales de API incorporan ámbitos granulares, mientras que la limitación de intentos de inicio de sesión, las solicitudes HTTP salientes más seguras y una validación más estricta refuerzan el perímetro de seguridad.
El chart de Helm incluido ofrece una vía compatible para desplegar la aplicación web y los workers en segundo plano en Kubernetes.
Las migraciones de PostgreSQL resuelven ahora tablas, columnas e índices en el esquema seleccionado por la ruta de búsqueda activa, corrigiendo las actualizaciones que usan un esquema no público.
Las migraciones antiguas y las comprobaciones de esquema usan ahora utilidades compartidas que respetan el esquema, evitando recurrir de forma insegura al esquema público.
Las actualizaciones y reversiones de migraciones mantienen ahora los cambios de esquema y los registros de migración en la misma transacción, reduciendo el riesgo de migraciones aplicadas parcialmente.
Las nuevas pruebas de migración cubren esquemas personalizados de PostgreSQL, relaciones ausentes, búsqueda de índices, proxies de base de datos y el comportamiento de otras bases de datos.
IncidentRelay ahora incluye localizacion de UI con catalogos en ingles, ruso y aleman para flujos de alertas, servicios, rutas, rotaciones, perfil y administracion.
Las herramientas de migracion de Grafana OnCall y PagerDuty ayudan a los equipos a trasladar sus datos de guardia existentes a IncidentRelay.
Las integraciones webhook compatibles con PagerDuty Events API v2 y Datadog amplian las fuentes de alertas admitidas.
El soporte de Slack Socket Mode permite interacciones de aplicaciones Slack sin exponer un endpoint Slack entrante publico.
Los secretos de configuracion de canales se enmascaran de forma mas consistente en las respuestas de API y UI.
Oficial IncidentRelay imágenes de contenedores se publican ahora a GitHub Container Registry, y Docker Compose utiliza la imagen de liberación versionada por defecto.
El gráfico Helm ahora envía como versión 1.1.0 y utiliza la imagen oficial IncidentRelay para Kubernetes despliegues.
Los registros de auditoría, los errores de validación y las respuestas de preparación ahora ocultan secretos y evitan exponer entradas confidenciales o detalles de la base de datos.
Las acciones repetidas de ackconocimiento y resolución son idempotentes, lo que evita la duplicación de eventos de línea de tiempo, notificaciones y actualizaciones de impacto.
Los enlaces de servicio y los corredores validan ahora URL externas antes de renderizar enlaces factibles.
Heartbeats ahora admite tracking de múltiples instancias para trabajos o agentes que se ejecutan en muchos productores.
El descubrimiento automático puede aprender nuevas instancias de latidos a partir de pings exitosos, mientras que el modo estático puede imponer una lista de productores esperados.
Cada instancia de latido vencido puede crear su propia alerta enrutada con etiquetas de instancia y comportamiento de resolución automática independiente.
Heartbeat instance state is exposed in the UI and API, including listing and disabling obsolete producings.
Los latidos agregan monitoreo de interruptor de hombre muerto para perros guardianes, backups, trabajos ETL, transportistas de registros y otros sistemas donde el silencio es el modo de falla.
Los modos de intervaloración y finalización programada pueden crear alertas normales de routed IncidentRelay cuando los pings esperados dejan de llegar.
Las alertas de latido utilizan la ruta existente, la escalada, la notificación, el mantenimiento y la canalización de impacto en el servicio, con resolución automática opcional cuando regresan los pings.
La puntuación de impacto de los servicios empresariales y del catálogo de servicios ahora maneja las ponderaciones de estado, prioridad, gravedad y dependencia de manera más granular.
Modelo de servicios empresariales con capacidades de cara al cliente compuestas por uno o más servicios técnicos.
El estado calculado utiliza el estado efectivo de los componentes, el impacto de la dependencia, la criticidad de los componentes y los pesos de impacto configurables.
Las anulaciones de estado manuales pueden describir el impacto en el cliente y, opcionalmente, caducan automáticamente.
Los detalles del Servicio de Negocio incluyen componentes, impacto activo y historial de estado, con total IU y API administración.
La correlación basada en dependencias vincula grupos de alertas activos relacionados entre dependencias de servicios.
Las posibles causas fundamentales, los síntomas y el impacto posterior incluyen una puntuación de confianza, la profundidad de la dependencia y una explicación.
La correlación aparece en las listas de alertas, los detalles, los cronogramas y el contexto de las notificaciones, aunque sigue siendo de carácter informativo: las alertas no se fusionan, suprimen ni resuelven automáticamente.
La configuración por dependencia y los retrasos de propagación controlan el tiempo de correlación y el ruido.
Servicio Impacto Historia Tiendas instantáneas programadas o manuales puntuales de servicios afectados, impacto de alerta, impacto de dependencia, causas raíz y radio de explosión.
Los gráficos históricos muestran las tendencias de los servicios afectados y las razones del impacto, mientras que las clasificaciones identifican los servicios que se ven afectados repetidamente.
Los análisis de fiabilidad de servicio combinan la salud actual SLI/SLO con datos de impacto histórico para los exámenes operativos e investigación de incidentes.
La gestión del contexto de servicio proporciona flujos de trabajo más claros de conmutación y edición para enlaces, runbooks y dependencias.
Los servicios pueden definir SLIs y SLOs para el reconocimiento de latencia, latencia de resolución, disponibilidad basada en incidentes y conteos de incidentes.
Las evaluaciones continuas clasifican los objetivos como cumplidos, en riesgo, incumplidos o sin datos y calculan presupuestos de errores de disponibilidad.
Los SLO admiten alcances de gravedad y prioridad, ventanas configurables, incidentes abiertos y exclusión opcional de ventanas de mantenimiento.
Los detalles de servicio, análisis agregados y el cronograma de servicio exponen las mediciones actuales y los cambios de configuración.
Notificación de servicio Las políticas seleccionan los canales de entrega compartidos mediante reglas ordenadas basadas en los matchers de alerta y tipos de eventos, con modos de entrega combinados y solo de ruta.
Las políticas de prioridad asignan automáticamente P1-P5 utilizando reglas de comparación ordenadas, valores predeterminados del equipo o anulaciones de servicios, modos de actualización configurables y prioridades de origen o fallback.
Reusable Matcher Presets y un editor compartido trae consistente JSON validación, formato y sugerencias desde alertas recientes a rutas, reglas de servicio, silencios, políticas y guías de servicio.
Los socorristas pueden restablecer una prioridad de incidente asignada manualmente a la gestión automática, mientras que Alert Explique Trace muestra cómo se seleccionó y aplicó la prioridad.
Correo electrónico, Slack, Mattermost, Telegram y las notificaciones de empuje del navegador pueden vincularse directamente al evento fuente original, con una mejor detección de eventos y proyectos Sentry.
On-call Health agrega indicadores de preparación a las rotaciones y equipos, destacando las configuraciones críticas, de advertencia y de estado saludable antes de que ocurra un incidente.
Los diagnósticos detallados detectan capas de rotación vacías o deshabilitadas, miembros inactivos, brechas en el cronograma, objetivos de asignación no resueltos y problemas de entrega de notificaciones.
Los detalles de salud incluyen recuentos de problemas, la ventana de tiempo verificada y recomendaciones prácticas para reparar cada equipo o rotación afectada.
Nuevo resumen y detalle API endpoints exponen códigos de emisión estables legibles por máquina para automatización, monitoreo y diagnóstico externo.
Alert Explique Trace registra cómo se procesan las alertas entrantes, incluida la coincidencia de rutas, la agrupación, las decisiones de mantenimiento y silencio, la programación de notificaciones y las rutas de procesamiento detenidas.
Las respuestas integradas incluyen ahora un trace_id, lo que hace que las fallas de enrutamiento, los incidentes suprimidos y las alertas resueltas huérfanos sean más fáciles de investigar de la UI o API.
La página Alertas incluye una vista Explain y enlaces profundos para abrir trazas directamente desde los parámetros de consulta trace_id.
Las Alertas API validan ahora las consultas de lista a través de un esquema dedicado, mejorando filtros de multivalor, paginación, clasificación y comportamiento de consulta asignado a mí.
LibreNMS API Ahora se pueden recibir alertas de transporte a través de un punto final de integración dedicado librenms con estado normalizado, gravedad, etiquetas, deduplicación y manejo de recuperación.
Los usuarios pueden establecer una preferencia de tiempo de perfil, mejorando la prestación de tiempo de alerta y calendario para equipos distribuidos.
El Centro de Notificación expone solicitudes de respuesta pendientes y acciones de incidentes de cara al usuario a través de un API dedicado.
Los servicios API documentación ahora cubre inventario, reglas de juego, enlaces, runbooks, dependencias, puntos finales de impacto y análisis en una referencia dedicada.
La página Alertas puede preservar el estado del filtro e incluye un filtro asignado a mí para un triaje personal más rápido.
Un gráfico Helm está disponible ahora para Kubernetes despliegues, incluyendo web, agendador y Telegram componentes de trabajadores, secretos de configuración, sondas, ingresos, cuenta de servicio y valores de persistencia.
Los servicios pueden definir a los interesados por defecto que se copian en nuevos incidentes, por lo que los propietarios y observadores pueden recibir notificaciones creadas, prioritarias, de estado y resueltas.
Las solicitudes de respuesta a incidentes ahora alimentan un centro de notificaciones donde los usuarios específicos pueden ver las solicitudes pendientes y aceptarlas o rechazarlas del flujo de trabajo del incidente.
Las API de incidencias y servicios ahora cubren a los usuarios, los interesados, las prioridades, los servicios y el propietario de servicios /default gestión de los interesados.
Las prioridades de incidentes ahora utilizan una escala consistente de P1 crítico a P5 informativo en todos los detalles de alerta y vistas operativas.
La página Alertas soporta el filtrado prioritario y la clasificación, mientras que el panel muestra las insignias prioritarias y un resumen de distribución prioritaria.
La gravedad de las alertas entrantes puede asignar o aumentar automáticamente la prioridad del incidente sin sobrescribir una prioridad seleccionada manualmente ni reducir una prioridad automática existente.
Correo electrónico, Mattermost, Telegram y las notificaciones de empuje del navegador ahora incluyen prioridad del incidente, y los cambios de prioridad manual pueden notificar a los interesados suscritos por correo electrónico.
Sólo lectura CalDAV sincroniza expone los horarios accesibles del equipo en la llamada a Apple Calendar, Thunderbird, DAVx5 y otros clientes compatibles.
Los feeds de suscripción Tokenized ICS permiten a los equipos añadir calendarios on-call a Outlook, Google Calendar y otros clientes calendario, con controles para regenerar o revocar URLs de alimentación.
Una nueva integración firmada Sentry recibe alertas de emisión, alertas métricas y eventos de ciclo de vida, con secretos de ruta, deduplicación y manejo automático de resolución.
La configuración de ruta ahora proporciona URL de webhook de origen específico, detalles de token y ejemplos de curl listos para copiar.
Los puntos finales de salud y preparación soportan sondas Kubernetes y controles de balanceo de carga.
Service Impact v2 muestra el estado actual de servicio efectivo, causas profundas, caminos de dependencia y radio de explosión aguas abajo.
Service Analytics v2 combina incidentes agrupados, volumen de alerta cruda, métricas de ruido y deduplicación, contadores de mantenimiento y datos de tiempo de respuesta.
La experiencia de Servicios ahora incluye un mayor impacto y vistas analíticas con gráficos y resúmenes operativos más claros.
Los controles de selección de usuarios en equipos, grupos, rotaciones y flujos de trabajo de escalada tienen etiquetas más claras y actualizaciones dinámicas.
Las ventanas de mantenimiento pueden apuntar a grupos, equipos, servicios o rutas y suprimir notificaciones, suprimir nuevos incidentes, crear incidentes de mantenimiento o pausar escaladas.
Los programas de mantenimiento admiten zonas horarias, estados efectivos y reglas RFC5545 recurrentes.
Los respondedores pueden crear, editar y eliminar comentarios de investigación directamente en los grupos de alertas, con acciones reflejadas en el cronograma de alertas.
Los detalles de las alertas ahora incluyen controles de gestión de incidentes para prioridad, solicitudes de respuesta y preferencias de notificación de las partes interesadas.
Los administradores de grupo pueden administrar los usuarios del equipo dentro de su alcance de acceso.
Se pueden recoger señales de monitoreo relacionadas en grupos de alerta usando campos de ruta configurable group_by.
Los operadores pueden ackconocer, resolver y fusionar manualmente grupos de alertas mientras conservan sus alertas infantiles individuales.
Las notificaciones de grupos de alerta admiten intervalos de actualización y procesamiento por lotes retrasados, lo que reduce el ruido de incidentes de corta duración o de rápida expansión.
Los miembros de la capa de rotación ahora tienen períodos de inicio y finalización, lo que preserva los cronogramas históricos y respalda los cambios futuros de membresía.
Las consultas del grupo de alerta soportan filtros multivalor para vistas de incidentes más flexibles y API solicitudes.
Los administradores pueden crear o actualizar IncidentRelay administradores de un Slack grupo de usuarios con el nuevo comando sync-slack-admins.
Las notificaciones push Browser/PWA están ahora disponibles para los usuarios asignados desde sus dispositivos de perfil.
Las notificaciones de presión de navegador pueden incluir acciones de corta duración ACK y Resolver.
Las reglas de notificación de perfil permiten a los usuarios definir la entrega de seguimiento mediante push del navegador, correo electrónico o llamada de voz.
La entrega de notificaciones ahora maneja las comprobaciones de entrega omitidas y el comportamiento de inserción del navegador de manera más confiable.
Las alertas y las tablas de estilo administrador ahora utilizan filtros reutilizables y ayudas de paginación para conjuntos de datos más grandes.
El estado de guardia ahora es visible en la barra superior y en la experiencia del perfil, para que los usuarios puedan ver los turnos actuales y futuros más rápido.
La configuración del perfil ahora incluye el estado de guardia y preferencias de notificación para actualizaciones por correo electrónico de programación de turnos.
Las notificaciones de correo electrónico de cambio pueden advertir a los usuarios acerca de los próximos períodos de reserva respetando las preferencias y las reglas de deduplicación.
Las búsquedas de rotación ahora tienen en cuenta capas, anulaciones y participación por usuario al calcular las ventanas de guardia específicas del usuario.
Las vistas de calendario y rotación se perfeccionaron en torno a búsquedas de horarios con límites de tiempo y un contexto de guardia más claro.
Gestión de servicios ahora modelos afectados sistemas con propietarios, criticidad, entornos, metadatos y vías de respuesta predeterminadas.
Las reglas del partido de servicio pueden mapear alertas entrantes a los servicios desde defectos de ruta, etiquetas, anotaciones y campos de carga.
Las dependencias de servicio y los metadatos de impacto ahora muestran cómo los servicios de corriente avanzada afectan los sistemas conexos y las alertas abiertas.
Los runbooks proporcionados por la integración se pueden adjuntar desde cargas útiles de alerta y mostrarse antes que los runbooks de nivel de servicio.
Los Servicios UI y API exponen inventario de servicios, reglas de juego, dependencias y contexto de impacto para los flujos de trabajo de operaciones.
La autenticación SSO ahora admite proveedores OIDC y SAML 2.0.
Los administradores pueden configurar proveedores de SSO, políticas de inicio de sesión, dominios permitidos y asignaciones de grupos externos desde la nueva página de SSO.
La página de inicio de sesión puede mostrar botones de proveedores SSO habilitados y redirigir a los usuarios a través del proveedor de identidad seleccionado.
SSO login puede auto-crear o vincular usuarios y sincronizar grupos externos a IncidentRelay roles de grupo.
Los metadatos de SAML, las opciones de firma y los secretos de SSO cifrados ahora están documentados y expuestos a través del flujo de SSO.
La aplicación UI recibió un refresco estilo material con navegación limpia y mejores interacciones perfil/routes.
Las rotaciones ahora admiten horarios de guardia en capas con prioridades, restricciones de tiempo activas, miembros por capa y reglas de transferencia que tienen en cuenta la zona horaria.
El calendario ahora hace que el calendario final de capas y overrides, por lo que los equipos pueden inspeccionar el usuario eficaz en la llamada para cada segmento de tiempo.
El filtrado de calendario ahora admite la selección de una rotación específica cuando un equipo tiene múltiples horarios.
Los API s de rotación ahora exponen puntos finales de restricción de capa, miembro de capa y capa para automatización e integraciones.
Los intervalos de recordatorio de rotación ahora se pueden configurar en 0 para deshabilitar los recordatorios repetidos para las alertas asignadas a través de esa rotación.
La escalada basada en recordatorios ahora respeta los recordatorios deshabilitados en lugar de caer back a un intervalo de recordatorio global.
El filtro de gravedad de la página Alerts ahora incluye severidades de advertencia e información para un triaje más preciso.
Las vidas personales API token ahora están cubiertas a los 365 días, mientras que todavía permite fichas no baratas con 0 días.
Entrega de notificaciones ahora utiliza notificadores dedicados para correo electrónico, Mattermost, Telegram y canales de llamada de voz.
Mattermost Bot API notificaciones pueden crear y actualizar puestos de alerta con mensajes de información sobre el estado y botones de acción.
Las notificaciones de llamadas de voz utilizan ahora el proveedor de voz configurado con texto de alerta hablado, soporte de llamada y cartografía de acción DTMF.
Canales API documentación ahora incluye los tipos de canal soportados, el punto final de plantilla de correo electrónico predeterminado y esquemas de canal más claro.
La página Silences puede filtrarse de tarjetas sumarias y opcionalmente incluir la historia vencida mayor de 30 días.
Docker y la documentación sistematizada ahora utilizan el nombre de servicio unificado incidentrelay en lugar de incidentrelay-web.
Las notificaciones por correo electrónico ahora pueden utilizar plantillas HTML personalizables para mensajes de alerta más completos y consistentes.
La configuración del canal de correo electrónico incluye controles de plantilla y marcadores de posición compatibles directamente en la interfaz de usuario.
La entrega de correo electrónico es más confiable cuando los equipos usan plantillas personalizadas o configuraciones SMTP globales.
La administración de usuarios utiliza ahora nombres de función más claros y flujos de trabajo de gestión de funciones más detallados.
Las listas de equipos y grupos ahora se centran en registros activos, reduciendo el desorden en la administración diaria.
La validación es más consistente entre las formas API, por lo que los valores inválidos se capturan antes y se reportan más previsiblemente.
Los campos de número de teléfono son más fáciles de completar correctamente gracias a una validación más estricta, normalización y feedback de interfaz inmediata.
Los mensajes de estado de inicio de sesión y formulario ahora brindan información más claraback durante los flujos comunes de configuración y administración.
Las alertas ahora tienen páginas de detalles que se pueden compartir, lo que facilita el envío de un enlace directo del incidente a los compañeros de equipo.
El progreso de la escalada es visible directamente en las alertas, lo que ayuda a los socorristas a comprender hasta qué punto ha escalado un incidente.
El estado de alerta es más fácil de rastrear mediante datos más claros resueltos y de escalada en el API.
Telegram notificaciones pueden apuntar a la alerta relacionada y mostrar los botones de acción adecuados para el estado actual.
Telegram el soporte incluye mensajes ricos, acciones interactivas, botones en línea y modo de votación.
Los canales de notificación pueden utilizar filtros de gravedad con manejo de gravedad normalizado para un enrutamiento más predecible.
Las anulaciones de guardia son más fáciles de administrar con un modal reutilizable, un estado de caché más rápido y un comportamiento compatible con el calendario.
Se rediseñaron las pantallas de administración, perfil, calendario, rotación y alerta para que las operaciones diarias sean más claras.