A análise de alertas mostra os alertas mais ruidosos, taxas de confirmação, MTTA e MTTR, tendências do ciclo de vida e os grupos de alertas não resolvidos mais antigos.
As métricas Prometheus apresentam latência dos pedidos, receção de alertas, filas de notificações e estado dos workers, com autenticação opcional por token bearer e suporte para ServiceMonitor no Helm.
A configuração permite substituir valores através de variáveis de ambiente, ficheiros de segredos montados e referências Helm a Secrets ou ConfigMaps existentes.
Os rastos de execução da orquestração mostram regras correspondentes, alterações nos eventos e decisões propostas face aos resultados reais do ciclo de vida.
Os detalhes dos alertas mostram a política de prioridade atual e a origem do encaminhamento de notificações; ao associar um incidente, é possível pesquisar grupos de alertas por título ou ID.
As imagens Docker suportam agora linux/arm64 além de linux/amd64.
Os incidentes têm agora o seu próprio espaço de trabalho, ciclo de vida, prioridade e responsável operacional, com associação de grupos de alertas e histórico de atividade.
Alteração incompatível na API: as operações de grupos técnicos de alertas passam para /api/alert-groups; /api/incidents gere agora apenas incidentes operacionais.
A integração com Cloud.ru Cloud Eye recebe notificações SMN assinadas de alarme e recuperação com confirmação automática da subscrição.
Os canais Feishu / Lark entregam notificações de texto através de webhooks de bots personalizados, com assinatura opcional dos pedidos.
O painel da visão geral apresenta tendências de alertas, estado dos serviços, atividade das equipas, responsáveis atualmente de prevenção e atividade recente.
As políticas de notificação passam a ter filtros por prioridade, gravidade, fonte e atributos do serviço, preservando referências a canais desativados.
Foram melhorados os detalhes dos alertas em dispositivos móveis e a navegação a partir das notificações push do navegador; os webhooks do Grafana aceitam campos opcionais com valor null.
O adiamento de alertas pode pausar temporariamente notificações, lembretes, atualizações e escalonamento de um grupo de alertas ativo sem ocultar o seu estado técnico ou impacto no serviço.
Os respondentes podem adiar e reativar alertas pela interface web, notificações push do navegador, Slack, Telegram e Mattermost, com expiração automática, retoma da entrega e registos completos da linha temporal e auditoria.
Uma integração nativa com o Azure Monitor aceita webhooks do Common Alert Schema, mapeia eventos Fired e Resolved, normaliza prioridades Sev0-Sev4 e disponibiliza metadados do Azure para encaminhamento.
O histórico de eventos de alertas filhos recebidos pode ser armazenado globalmente nos modos completo, apenas inicial ou desativado, enquanto o Event Orchestration pode substituir o modo para eventos correspondentes sem remover entradas operacionais da linha temporal.
Os fornecedores OIDC e SAML podem mapear atributos de identidade para IDs de utilizador do Slack, Telegram e Mattermost, facilitando o aprovisionamento de ações interativas através de SSO.
A eliminação e recriação de recursos é mais segura: o encaminhamento dependente e o trabalho do agendador são desativados de forma consistente enquanto os registos históricos permanecem disponíveis.
A interface adiciona localizações completas em espanhol e chinês simplificado.
As implementações Helm passam a suportar CAs personalizadas e uma configuração HTTP de saída mais segura para redes privadas, com correções para valores numéricos e caminhos estáticos atrás de proxies reversos.
As políticas de retenção configuráveis podem remover automaticamente o histórico antigo de alertas resolvidos, Explain Traces e rastos de execução do Event Orchestration em lotes limitados do agendador.
O Event Orchestration pode definir rastos de processamento completos, compactos ou desativados para cada evento correspondente, com buffer limitado e estado compacto ou truncado visível.
Confirmar um incidente correlacionado agora cancela notificações, lembretes e escaladas obsoletos; os eventos filhos com prioridade igual ou inferior permanecem confirmados, enquanto eventos de prioridade superior podem reabrir o grupo.
Uma integração nativa com New Relic recebe notificações de incidentes do Alerts Workflow e encaminha eventos normalizados do ciclo de vida através dos tokens de entrada padrão do IncidentRelay.
Uma integração nativa com Nagios Core e Nagios XI mapeia problemas de hosts e serviços, recuperações e confirmações, ignorando períodos de indisponibilidade, flapping e notificações personalizadas.
O chart Helm é agora publicado no GHCR como artefacto OCI, com predefinições reforçadas e melhores verificações para implementação segura com SQLite.
O tema escuro está mais consistente nas vistas principais, e o simulador de Orchestration apresenta resultados num formato mais claro e acessível.
O Event Orchestration adiciona regras globais e específicas por serviço, com controlo de versões, que podem normalizar, enriquecer, encaminhar, agrupar e eliminar duplicados de eventos recebidos antes de o ciclo de vida do alerta concluir o processamento.
As regras podem selecionar equipas, rotas, serviços e políticas, alterar prioridade e gravidade, suprimir notificações, atrasar ou descartar eventos e colocar webhooks assíncronos seguros em fila.
Um construtor visual e um editor JSON contam com validação, simulação, replay, execução em sombra, rastreios, métricas e fluxos imutáveis de publicação e rollback para implementações mais seguras.
A integração nativa com o Uptime Kuma transforma alterações de estado dos monitores em alertas encaminhados e resolve-os automaticamente quando os monitores recuperam.
Os silêncios e as janelas de manutenção podem agora ser aplicados retroativamente a alertas não resolvidos; os alertas afetados podem ser reativados quando a supressão termina, mantendo consistentes os estados de escalonamento e notificação.
A interface adiciona um tema escuro, preferências de UI guardadas, uma vista do registo de auditoria e localização completa em francês.
Os tokens de API pessoais passam a ter âmbitos granulares, enquanto a limitação de tentativas de início de sessão, pedidos HTTP de saída mais seguros e uma validação mais rigorosa reforçam o limite de segurança.
O chart Helm incluído oferece um caminho suportado para implantar a aplicação web e os workers em segundo plano no Kubernetes.
As migrações do PostgreSQL agora resolvem tabelas, colunas e índices no esquema selecionado pelo caminho de pesquisa ativo, corrigindo atualizações que usam um esquema não público.
As migrações antigas e as verificações de esquema agora usam utilitários compartilhados que respeitam o esquema, evitando o retorno inseguro ao esquema público.
Atualizações e reversões de migrações agora mantêm as alterações de esquema e os registros de migração na mesma transação, reduzindo o risco de migrações aplicadas parcialmente.
Novos testes de migração cobrem esquemas PostgreSQL personalizados, relações ausentes, consulta de índices, proxies de banco de dados e o comportamento de outros bancos.
IncidentRelay agora inclui suporte a localizacao de UI com catalogos em ingles, russo e alemao para fluxos de alertas, servicos, rotas, rotacoes, perfil e administracao.
As ferramentas de migracao do Grafana OnCall e do PagerDuty ajudam as equipes a mover dados de plantao existentes para o IncidentRelay.
As integracoes webhook compativeis com PagerDuty Events API v2 e Datadog ampliam as fontes de alertas suportadas.
O suporte ao Slack Socket Mode permite interacoes de apps Slack sem expor um endpoint Slack publico de entrada.
Os segredos de configuracao de canais agora sao mascarados de forma mais consistente nas respostas da API e da UI.
As imagens oficiais do recipiente IncidentRelay estão agora publicadas para GitHub Container Registry, e Docker Compose usa a imagem versão release por padrão.
O gráfico Helm agora é enviado como versão 1.1.0 e usa a imagem oficial IncidentRelay para implementações Kubernetes.
Registros de auditoria, erros de validação e respostas de prontidão agora editam segredos e evitam expor detalhes sensíveis de entrada ou banco de dados.
As ações repetidas de reconhecimento e resolução são idempotentes, impedindo eventos duplicados de linha do tempo, notificações e atualizações de impacto.
Links de serviço e runbooks agora validam URLs externas antes de renderizar links acionáveis.
Heartbeats agora suporta rastreamento multi-instance para trabalhos ou agentes correndo entre muitos produtores.
Auto-descoberta pode aprender novas instâncias de batimento cardíaco com pings de sucesso, enquanto o modo estático pode forçar uma lista de produtores esperada.
Cada instância cardíaca atrasada pode criar seu próprio alerta roteado com etiquetas de instância e comportamento de resolução automática independente.
O estado de instância Heartbeat é exposto na UI e API, incluindo listagem e incapacitação de produtores obsoletos.
Batimentos cardíacos adicionam monitoramento de switch-homem morto para cães de guarda, backups, trabalhos de ETL, carregadores de log e outros sistemas onde o silêncio é o modo de falha.
Os modos de intervalo e completamento programado podem criar alertas IncidentRelay roteados normais quando os pings esperados param de chegar.
Alertas de batimento cardíaco usam a rota existente, escalada, notificação, manutenção e pipeline de impacto de serviço, com resolução automática opcional quando os pings retornam.
Business Services e Service Catalog pontuação de impacto agora lidar com status, prioridade, gravidade e dependência pesos mais granularmente.
As ligações de correlação entre grupos de alerta ativo relacionados entre dependências de serviço.
Possíveis causas radiculares, sintomas e impacto a jusante incluem um escore de confiança, profundidade de dependência e explicação.
A correlação aparece em listas de alertas, detalhes, timelines e contexto de notificação, permanecendo o aconselhamento: os alertas não são mesclados, suprimidos ou resolvidos automaticamente.
Configurações de per-dependência e atrasos de propagação controlar o tempo de correlação e ruído.
Service Impact History armazena instantâneos pontuais dos serviços afetados, impacto de alerta, impacto de dependência, causas raiz e raio de explosão.
Gráficos históricos mostram tendências de serviço afetadas e razões de impacto, enquanto rankings identificam serviços que são repetidamente afetados.
Análises de confiabilidade de serviços combinam saúde SLI/SLO atual com dados de impacto histórico para revisões operacionais e investigação de incidentes.
O gerenciamento de contexto de serviço agora fornece fluxos de trabalho de comutação e edição mais claros para links, runbooks e dependências.
Os serviços podem definir DELs e SLOs para latência de reconhecimento, latência de resolução, disponibilidade baseada em incidentes e contagens de incidentes.
As avaliações periódicas classificam os objetivos como cumpridos, em risco, violados ou sem dados e calculam os orçamentos de erro de disponibilidade.
SLOs suportam gravidade e escopos de prioridade, janelas configuráveis, incidentes abertos e exclusão opcional da janela de manutenção.
Detalhes do serviço, análise agregada e a linha do tempo do serviço expõem as medições atuais e as alterações de configuração.
Políticas de notificação de serviços selecionam canais de entrega compartilhados através de regras ordenadas baseadas em pares de alerta e tipos de eventos, com somente rota, política de serviço e modos de entrega combinados.
Políticas Prioritárias automaticamente atribuir P1-P5 usando regras de correspondência ordenadas, padrões de equipe ou sobreposições de serviço, modos de atualização configuráveis e prioridades de origem ou back.
Predefinições de correspondência reutilizáveis e um editor compartilhado trazem consistente JSON validação, formatação e sugestões de alertas recentes para rotas, regras de serviço, silêncios, políticas e runbooks de serviço.
Os respondedores podem redefinir uma prioridade de incidente atribuída manualmente ao gerenciamento automático, enquanto o Alert Explaine Trace mostra como a prioridade foi selecionada e aplicada.
Email, Slack, Mattermost, Telegram e notificações de push do navegador podem se conectar diretamente ao evento fonte original, com detecção de eventos e projetos Sentry melhorados.
A Saúde de plantão adiciona indicadores de prontidão às Rotações e Equipes, destacando configurações saudáveis, de alerta e críticas antes que ocorra um incidente.
Diagnósticos detalhados detectam camadas de rotação vazias ou desativadas, membros inativos, falhas de programação, metas de atribuição não resolvidas e problemas de entrega de notificação.
Detalhes de saúde incluem contagens de problemas, a janela de tempo verificada e recomendações acionáveis para reparar cada equipe afetada ou rotação.
Novos parâmetros de resumo e detalhe API expõem códigos de emissão legíveis por máquina estáveis para automação, monitoramento e diagnósticos externos.
O Alert Explique Trace registra como os alertas recebidos são processados, incluindo correspondência de rotas, agrupamento, decisões de manutenção e silêncio, agendamento de notificações e caminhos de processamento interrompidos.
As respostas de integração incluem agora um trace_id, tornando falhas de encaminhamento, incidentes suprimidos e alertas órfãos resolvidos mais fáceis de investigar da UI ou API.
A página Alertas inclui uma visão Explicar e links profundos para abrir traços diretamente de parâmetros de consulta trace_id.
Os Alertas API agora validam consultas de lista através de um esquema dedicado, melhorando filtros de vários valores, paginação, ordenação e comportamento de consulta atribuído a mim.
LibreNMS API Os alertas de transporte podem agora ser recebidos através de um endpoint de integração librenms dedicado com estado normalizado, gravidade, rótulos, deduplicação e tratamento de recuperação.
Os usuários podem definir um perfil de preferência no fuso horário, melhorando a renderização de tempo de alerta e calendário para equipes distribuídas.
O Centro de Notificação expõe solicitações de resposta pendentes e ações de incidentes voltadas para o usuário através de um API dedicado.
A documentação dos serviços API agora abrange inventário, regras de correspondência, links, runbooks, dependências, parâmetros de impacto e análise em uma referência dedicada.
A página Alertas pode preservar o estado do filtro e inclui um filtro atribuído a mim para triagem pessoal mais rápida.
Um gráfico Helm está agora disponível para implantações Kubernetes, incluindo componentes web, agendador e Telegram do trabalhador, segredos de configuração renderizados, sondas, entrada, conta de serviço e valores de persistência.
Os serviços podem definir stakeholders padrão que são copiados para novos incidentes, para que proprietários e observadores possam receber notificações criadas, prioritárias, de status e resolvidas.
Pedidos de resposta a incidentes agora alimentam um centro de notificação onde usuários específicos podem ver pedidos pendentes e aceitá-los ou recusá-los do fluxo de trabalho incidente.
As API s de incidentes e serviços agora cobrem respondedores, stakeholders, prioridades, serviços e gerenciamento de stakeholders /default.
As prioridades de incidentes agora usam uma escala P1 Crítica consistente através do P5 Informational através de detalhes de alerta e visualizações operacionais.
A página Alertas suporta filtragem e ordenação de prioridade, enquanto o painel mostra crachás de prioridade e um resumo de distribuição de prioridade.
A severidade do alerta de entrada pode atribuir ou elevar automaticamente a prioridade incidente sem sobrescrever uma prioridade selecionada manualmente ou diminuir uma prioridade automática existente.
Email, Mattermost, Telegram e notificações de push do navegador agora incluem prioridade incidente, e alterações de prioridade manual podem notificar stakeholders subscritos por e-mail.
A sincronização CalDAV somente leitura expõe os horários de chamadas da equipe acessível para o Apple Calendar, Thunderbird, DAVx5 e outros clientes compatíveis.
Feeds de assinatura ICS tokenized permitem que as equipes adicionem agendas de plantão para o Outlook, Google Calendar e outros clientes de calendário, com controles para regenerar ou revogar URLs de alimentação.
Uma nova integração Sentry assinada recebe alertas de problema, alertas métricos e eventos de ciclo de vida, com segredos de nível de rota, deduplicação e resolução automática.
A configuração da rota agora fornece URLs webhook específicas para fontes, detalhes de fichas e exemplos de curl prontos para copiar.
Os parâmetros de saúde e de prontidão suportam sondas Kubernetes e verificações do balanceador de carga.
O Service Impact v2 mostra o estado de serviço efetivo atual, causas de raiz, caminhos de dependência e raio de explosão a jusante.
O Service Analytics v2 combina incidentes agrupados, volume de alerta bruto, métricas de ruído e deduplicação, contadores de manutenção e dados de tempo de resposta.
A experiência dos Serviços agora inclui vistas de impacto e análise mais ricas com gráficos e resumos operacionais mais claros.
Os controles de seleção de usuários entre equipes, grupos, rotações e fluxos de trabalho de escalada têm rótulos mais claros e atualizações dinâmicas.
O Windows de manutenção pode direcionar grupos, equipes, serviços ou rotas e suprimir notificações, suprimir novos incidentes, criar incidentes de manutenção ou pausar escalações.
Os horários de manutenção suportam fusos horários, status efetivo e regras recorrentes RFC5545.
Os respondedores podem criar, editar e excluir comentários de investigação diretamente em grupos de alerta, com ações refletidas na linha do tempo de alerta.
Os detalhes dos alertas agora incluem controles de gerenciamento de incidentes para prioridade, solicitações de resposta e preferências de notificação das partes interessadas.
Os gerentes de grupo podem gerenciar usuários de equipe dentro de seu escopo de acesso.
Os sinais de monitoramento relacionados podem agora ser coletados em grupos de alerta usando campos configuráveis de rota group_by.
Os operadores podem reconhecer, resolver e fundir manualmente grupos de alerta, mantendo seus alertas individuais.
As notificações de grupo de alerta suportam lotes atrasados e intervalos de atualização, reduzindo o ruído de incidentes de curta duração ou de expansão rápida.
Os membros da camada de rotação agora têm períodos de início e fim, preservando horários históricos e apoiando futuras mudanças de adesão.
Consultas de grupo de alerta suportam filtros de vários valores para visualizações incidentes mais flexíveis e solicitações API.
Os administradores podem criar ou atualizar administradores IncidentRelay de um grupo de usuários Slack com o novo comando sync-slack-admins.
O status de chamada está agora visível na barra superior e experiência de perfil, para que os usuários possam ver os turnos atuais e futuros mais rápido.
As configurações de perfil agora incluem as preferências de status de chamada e notificação para agendamento de turno de atualizações de e-mail.
As notificações por e-mail de turno podem alertar os usuários sobre os próximos períodos de chamada, respeitando as preferências e regras de deduplicação.
As pesquisas de rotação agora são responsáveis por camadas, substituições e participação por usuário ao calcular janelas de plantão específicas do usuário.
As views de calendário e rotação foram refinadas em torno de buscas de programação com limite de tempo e contexto de plantão mais claro.
O gerenciamento de serviços agora modela sistemas afetados com proprietários, criticidade, ambientes, metadados e caminhos de resposta padrão.
Regras de correspondência de serviço podem mapear alertas de entrada para serviços de rota padrão, rótulos, anotações e campos de carga útil.
As dependências de serviço e os metadados de impacto mostram agora como os serviços upstream afetam sistemas relacionados e alertas abertos.
Os runbooks fornecidos pela integração podem ser anexados a partir de cargas úteis de alerta e mostrados antes dos runbooks de nível de serviço.
Os Serviços UI e API expõem inventário de serviços, regras de correspondência, dependências e contexto de impacto para fluxos de trabalho de operações.
As rotações agora suportam agendamentos de chamadas em camadas com prioridades, restrições de tempo ativa, membros por camada e regras de transferência consciente do fuso horário.
O calendário agora renderiza o cronograma final a partir de camadas e substituições, para que as equipes possam inspecionar o usuário de plantão efetivo para cada segmento de tempo.
A filtragem de calendário agora suporta selecionar uma rotação específica quando uma equipe tem vários horários.
API s de rotação agora expõem terminais de restrição de camada, membro de camada e camada para automação e integrações.
Intervalos de lembrete de rotação podem agora ser configurados como 0 para desativar lembretes repetidos para alertas atribuídos através dessa rotação.
A escalada baseada em lembretes agora respeita lembretes desativados em vez de voltar para um intervalo global de lembretes.
O filtro de gravidade da página Alertas agora inclui gravidades de aviso e informações para triagem mais precisa.
Vida útil pessoal API do token é agora fechado em 365 dias, enquanto ainda permite tokens não expirando com 0 dias.
As listas de equipes e grupos agora se concentram em registros ativos, reduzindo a desordem na administração diária.
A validação é mais consistente em API formulários, então os valores inválidos são capturados mais cedo e relatados mais previsivelmente.
Os campos de número de telefone são mais fáceis de preencher corretamente graças à validação mais rigorosa, normalização e feedback de frontend imediato.
As mensagens de status de login e formulário agora dão feedback mais claro durante os fluxos comuns de configuração e administração.