Alertas e notificações

Os alertas avisam quando algo precisa de atenção; as notificações entregam esses alertas fora do navegador.

Regras de alerta

Regras integradas transformam eventos em alertas. Cada regra tem uma severidade e um debounce — o menor intervalo antes de o mesmo tipo de alerta tocar o sino novamente. Um alerta com debounce não se perde: o evento subjacente continua registrado na página Events.

Alerta	Severidade	Debounce	Dispara quando
Camera offline	warning	—	Uma câmera ficou sem fonte por várias verificações de integridade
Camera degraded	warning	2 min	Acessível, mas o stream está prejudicado — quadros travados ou bitrate baixo/zero
Camera back online	info	—	Uma câmera se recupera
Tamper detected	warning	2 min	Uma obstrução da lente ou mudança de visão é detectada
Alta server unavailable	critical	—	Um servidor Alta está fora do ar (de forma contínua) ou oscilando
Alta server restored	info	—	Um servidor Alta que estava fora do ar se recupera
Alta server restarted	warning	30 s	O processo do Alta foi reiniciado, comprovado por mudança do ID da instância ou reinício do uptime
Alta connectivity blip	info	30 s	Uma breve indisponibilidade do Alta foi recuperada sem reinício do processo
Alta config drift	critical	3 min	A configuração ativa de um servidor Alta não corresponde mais ao que o Vision espera
Alta storage low on space	warning	—	O espaço livre em um volume de arquivo do Alta cai abaixo de um limite de Telemetry Alerts
Alta host CPU high / Alta host RAM high	warning	—	A CPU ou a memória do host Alta permanece acima de um limite de Telemetry Alerts
Critical event	critical	—	Qualquer outro evento marcado como crítico

A visibilidade segue o escopo do evento: os alertas de escopo de servidor e de sistema (as linhas Alta … e qualquer evento crítico de nível de sistema) são exclusivos para administradores. Os alertas de escopo de câmera (offline, degraded, online, tamper) seguem a sua participação nos grupos.

Alertas ao vivo

Os novos alertas chegam em tempo real via Server-Sent Events e aparecem sob o sino na barra superior. Cada alerta aponta para um evento — o evento é o registro do incidente, e tudo o que você faz com o alerta é gravado nele (veja Events).

Um alerta oferece três ações:

• Acknowledge — assumir a responsabilidade: “estou cuidando disso”. Disponível para operadores e administradores. O reconhecimento vale para o primeiro que o fizer: quando alguém reconhece, todos os sinos mostram Acknowledged by com o nome da pessoa, e uma tentativa posterior de reconhecimento não substitui o responsável original. É possível adicionar um comentário opcional, que é registrado no evento.
• Resolve — somente para administradores. Encerra o incidente para todos os usuários de uma vez e remove o alerta de todos os sinos. Um comentário de resolução é obrigatório; o comentário e os detalhes da resolução ficam visíveis na página Events.
• Dismiss — oculta o alerta somente para você. Os demais usuários não são afetados, e nenhuma permissão especial é necessária.

Selecione vários alertas para reconhecê-los ou descartá-los em lote.

Quedas em todo o servidor viram uma única linha

Quando muitas câmeras de um mesmo servidor Alta mudam de estado com menos de um minuto de diferença entre si, o sino mostra uma única linha — 12 cameras offline, 3 of 12 cameras offline ou 12 cameras recovered — sob o nome do servidor. Details lista o último estado de cada câmera; Acknowledge e Dismiss agem sobre o grupo inteiro. Uma regra de notificação envia uma mensagem por grupo, não uma por câmera. Todos os eventos continuam listados na página Events.

Após uma interrupção de rede ou a suspensão do notebook, o navegador se reconecta e ressincroniza automaticamente, de modo que os alertas disparados durante a desconexão não se perdem.

Lendo um alerta do sino

Cada linha de alerta mostra um ícone e uma barra coloridos conforme a severidade, um título derivado do tipo de evento e a câmera afetada (com seu IP) ou o servidor Alta como um link que leva você direto até ele. Os alertas não tratados trazem um ponto de não lido; quando alguém assume a responsabilidade, a linha mostra Acknowledged by [name].

Expanda uma linha com a seta para ver detalhes somente leitura do evento subjacente — o motivo, o tipo de falha, como a recuperação de um servidor foi detectada (probe ou ID da instância), a duração da indisponibilidade, o uptime do Alta, uma mudança de status exibida como from → to, qualquer texto de erro e o horário do evento. Os alertas sem mais nada a mostrar exibem No additional details.

Suas preferências de alerta

Em Settings → Alerts, cada usuário controla as suas próprias preferências de alerta — quais alertas deseja ver e como. Essas configurações são por usuário e não afetam mais ninguém.

Notificações

As notificações entregam os alertas fora do navegador. Elas são configuradas em Settings → Notifications em três camadas:

Camada	Responde	Exemplos
Connection	Com o que enviamos	Um servidor SMTP, uma identidade Web Push (VAPID), um bot do Telegram — um de cada
Recipient	Onde/para quem chega	Uma lista de e-mails, IDs de chat do Telegram, uma URL de webhook ou assinaturas de push do navegador
Rule	Quando e o quê	Quais tipos de evento, escopo, severidade e throttle — direcionados a um destinatário

Os canais compatíveis são Email (SMTP), Web Push (notificações do navegador), Telegram e Webhook. Os destinatários de webhook não precisam de conexão; os demais canais enviam por meio da conexão compartilhada.

Se a conexão de um canal não estiver configurada, a entrega por esse canal é ignorada — os alertas continuam aparecendo no aplicativo. Para usar o Web Push, um administrador primeiro ativa a identidade Web Push e, depois, cada usuário inscreve o seu navegador.

Nem todo alerta pode ser roteado para fora: camera-degraded e os alertas de integridade do servidor Alta (unavailable, restored, restarted, blip, config drift) aparecem apenas no aplicativo e não estão disponíveis como gatilhos de regras de notificação.

Confiabilidade da entrega

Os alertas e as notificações são persistidos antes da entrega, por isso sobrevivem a uma reinicialização do serviço e a picos de carga. A entrega é do tipo at-least-once com deduplicação — raramente pode ocorrer uma notificação duplicada, e isso é intencional.

Os envios de e-mail, webhook, Telegram e push que falham são repetidos com backoff e só são abandonados após falhas repetidas; as entregas abandonadas aparecem nos logs e nas métricas do servidor, não na interface. O throttling conta apenas as entregas confirmadas — um envio com falha não consome a janela de throttle. Um servidor SMTP travado expira após cerca de 30 segundos e nunca atrasa os outros canais.