Alertas y notificaciones

Las alertas te avisan cuando algo requiere atención; las notificaciones entregan esas alertas fuera del navegador.

Reglas de alertas

Las reglas integradas convierten eventos en alertas. Cada regla tiene una severidad y un debounce — el intervalo mínimo antes de que el mismo tipo de alerta vuelva a sonar en la campana. Una alerta con debounce no se pierde: el evento subyacente se sigue registrando en la página Events.

Alerta	Severidad	Debounce	Se activa cuando
Camera offline	warning	—	Una cámara ha estado sin fuente durante varias consultas de estado
Camera degraded	warning	2 min	Es accesible, pero el stream está deteriorado — cuadros detenidos o bitrate bajo/nulo
Camera back online	info	—	Una cámara se recupera
Tamper detected	warning	2 min	Se detecta una obstrucción de la lente o un cambio de vista
Alta server unavailable	critical	—	Un servidor Alta está caído (de forma sostenida) o inestable
Alta server restored	info	—	Un servidor Alta caído se recupera
Alta server restarted	warning	30 s	El proceso de Alta se reinició, comprobado por un cambio de ID de instancia o un reinicio del tiempo de actividad
Alta connectivity blip	info	30 s	Una breve interrupción de Alta se recuperó sin que el proceso se reiniciara
Alta config drift	critical	3 min	La configuración activa de un servidor Alta ya no coincide con la que Vision espera
Alta storage low on space	warning	—	El espacio libre en un volumen de archivo de Alta cae por debajo de un umbral de Telemetry Alerts
Alta host CPU high / Alta host RAM high	warning	—	La CPU o la memoria del host de Alta se mantiene por encima de un umbral de Telemetry Alerts
Critical event	critical	—	Cualquier otro evento marcado como crítico

La visibilidad sigue el alcance del evento: las alertas de alcance servidor y sistema (las filas Alta … y cualquier evento crítico de nivel sistema) son solo para administradores. Las alertas de alcance cámara (offline, degraded, online, tamper) siguen tu pertenencia a grupos.

Alertas en vivo

Las nuevas alertas llegan en tiempo real mediante Server-Sent Events y aparecen bajo la campana de la barra superior. Cada alerta apunta a un evento — el evento es el registro del incidente, y todo lo que hagas con la alerta se escribe en él (consulta Events).

Una alerta ofrece tres acciones:

• Acknowledge — asumir la responsabilidad: “me encargo yo”. Disponible para operadores y administradores. En el reconocimiento gana el primero: cuando alguien reconoce la alerta, todas las campanas muestran Acknowledged by con el nombre de esa persona, y un intento posterior de reconocimiento no reemplaza al responsable original. Se puede añadir un comentario opcional, que se registra en el evento.
• Resolve — solo para administradores. Cierra el incidente para todos los usuarios a la vez y elimina la alerta de todas las campanas. Se requiere un comentario de resolución; el comentario y los detalles de la resolución son visibles en la página Events.
• Dismiss — oculta la alerta solo para ti. Los demás usuarios no se ven afectados y no se necesita ningún permiso especial.

Selecciona varias alertas para reconocerlas o descartarlas en bloque.

Las caídas de todo un servidor son una sola fila

Cuando muchas cámaras de un mismo servidor Alta cambian de estado con menos de un minuto de diferencia, la campana muestra una sola fila — 12 cameras offline, 3 of 12 cameras offline o 12 cameras recovered — bajo el nombre del servidor. Details lista el último estado de cada cámara; Acknowledge y Dismiss actúan sobre todo el grupo. Una regla de notificación envía un mensaje por grupo, no uno por cámara. Cada evento sigue apareciendo en la página Events.

Tras una interrupción de red o la suspensión de la computadora portátil, el navegador se reconecta y se resincroniza automáticamente, de modo que las alertas que se activaron mientras estaba desconectado no se pierden.

Cómo leer una alerta de la campana

Cada fila de alerta muestra un icono y una barra con el color de la severidad, un título derivado del tipo de evento y la cámara afectada (con su IP) o el servidor Alta como un enlace que te lleva directamente allí. Las alertas sin atender llevan un punto de no leído; cuando alguien asume la responsabilidad, la fila muestra Acknowledged by [name].

Expande una fila con su chevrón para ver detalles de solo lectura del evento subyacente — el motivo, el tipo de fallo, cómo se detectó la recuperación de un servidor (sondeo o ID de instancia), la duración de la interrupción, el tiempo de actividad de Alta, un cambio de estado mostrado como from → to, cualquier texto de error y la hora del evento. Las alertas sin nada más que mostrar indican No additional details.

Tus preferencias de alertas

En Settings → Alerts cada usuario controla sus propias preferencias de alertas — qué alertas quiere ver y cómo. Estos parámetros son por usuario y no afectan a nadie más.

Notificaciones

Las notificaciones entregan las alertas fuera del navegador. Se configuran en Settings → Notifications en tres capas:

Capa	Responde a	Ejemplos
Connection	Con qué enviamos	Un servidor SMTP, una identidad Web Push (VAPID), un bot de Telegram — uno de cada
Recipient	Dónde/a quién llega	Una lista de correos, IDs de chat de Telegram, una URL de webhook o suscripciones push del navegador
Rule	Cuándo y qué	Qué tipos de evento, alcance, severidad y limitación — dirigido a un destinatario

Los canales admitidos son Email (SMTP), Web Push (notificaciones del navegador), Telegram y Webhook. Los destinatarios de webhook no necesitan conexión; los demás canales envían a través de su conexión compartida.

Si la conexión de un canal no está configurada, la entrega por ese canal se omite — las alertas siguen apareciendo en la aplicación. Para usar Web Push, un administrador habilita primero la identidad Web Push y luego cada usuario suscribe su navegador.

No todas las alertas se pueden enviar al exterior: camera-degraded y las alertas de estado del servidor Alta (unavailable, restored, restarted, blip, config drift) aparecen solo en la aplicación y no están disponibles como disparadores de reglas de notificación.

Fiabilidad de la entrega

Las alertas y las notificaciones se almacenan de forma persistente antes de la entrega, por lo que sobreviven a un reinicio del servicio y a picos de carga. La entrega es de al menos una vez con deduplicación — una notificación duplicada ocasional es posible por diseño.

Los envíos fallidos de correo, webhook, Telegram y push se reintentan con retroceso progresivo y solo se abandonan tras fallos repetidos; las entregas abandonadas aparecen en los registros y las métricas del servidor, no en la interfaz. La limitación solo cuenta las entregas confirmadas — un envío fallido no consume la ventana de limitación. Un servidor SMTP que no responde agota el tiempo de espera tras unos 30 segundos y nunca retrasa los demás canales.