Alertas — /alerts
Una integración que se detiene en silencio es peor que una que falla en voz alta. Las alertas existen para que el silencio deje de ser posible: cada evento relevante del CMS puede volverse notificación, correo o webhook, con destinatarios elegidos por usted.
Cómo se configura una alerta
Una alerta es la combinación de cuatro cosas:
- Tipo de evento — qué tiene que pasar.
- Alcance — Aplicación, y según el tipo también Interfaz y Definición.
- Destinatarios — qué usuarios del CMS la reciben.
- Canales — notificación in-app (siempre), correo, webhook y/o ticket en una herramienta de Help Desk.
La combinación tipo + aplicación + interfaz + definición es única: no existen dos configuraciones disputando el mismo evento. Intentar crear la segunda se rechaza con un mensaje claro. La excepción es Condición Cumplida: cada configuración tiene su condición, y la misma Recolección puede tener varias.
Al crear una Aplicación, Interfaz, Definición o Error de Negocio, el CMS pre-registra las configuraciones de alerta aplicables — desactivadas y sin destinatarios. Aparecen en la lista esperando que alguien diga a quién avisar, en vez de tener que crearse desde cero.
Tipos de evento
Nivel Aplicación
No piden Interfaz: valen para la aplicación entera.
| Evento | Dispara cuando |
|---|---|
| Aplicación Offline | El keep-alive de la aplicación falla |
| Aplicación Online | La aplicación vuelve a responder |
El cuerpo de la alerta de aplicación offline incluye, en líneas separadas, las observaciones registradas en la Aplicación y el error capturado por el keep-alive. Eso transforma un “está offline” en algo accionable: quien recibe el mensaje ya lee el teléfono del responsable y el error de red.
Nivel Interfaz
| Evento | Dispara cuando |
|---|---|
| Interfaz Bloqueada | La interfaz se bloquea, manualmente o por error de negocio |
| Interfaz Desbloqueada | La interfaz se libera |
| Mensajes Acumulados en Interfaz | La cola pasa el límite configurado en la Interfaz |
| Error de Recolección | Una recolección falla al leer el origen |
| Interfaz con Programador Pausado | El programador de la interfaz está inactivo |
| Conexión Perdida | Cae la conexión persistente de la Recolección — MQTT, SAP IDoc, OPC UA o Modbus |
| Directorio Inaccesible | La carpeta de una recolección de archivos dejó de responder |
| Dispositivo Sparkplug Offline | Un edge node o device anunció NDEATH / DDEATH |
Conexión Perdida y Dispositivo Sparkplug Offline son cosas distintas. La primera es la caída del broker; la segunda es la caída del equipo con el broker en pie. Confundirlas manda al equipo equivocado al lugar equivocado.
Nivel Definición
Estos piden también la Definición, porque lo interesante es saber cuál integración falló:
| Evento | Dispara cuando |
|---|---|
| Error de Entrega | Falla técnica al entregar (red, timeout, HTTP de error) |
| Error de Negocio | El destino respondió, pero la respuesta coincidió con una regla de Error de Negocio |
| Condición Cumplida | El dato recolectado pasó a cumplir la condición configurada — solo en Recolecciones. La vuelta dispara Condición Normalizada |
| Falla en el iFlow (SAP CPI) | El SAP CPI aceptó la Entrega, pero el iFlow terminó en falla después, dentro del tenant — solo en Entregas a una Aplicación SAP CPI. Ver Estado en el SAP CPI |
Condición Cumplida es la alerta sobre el contenido de la lectura: temperatura por encima de 80 durante 5 minutos, estado distinto de OK. Tiene campos propios — la condición, Separar por, la duración mínima y el mensaje — y las reglas de disparo están en Condiciones sobre el dato.
Error de Entrega no se aplica a Interfaces de Recolección. En una Recolección, la falla de lectura es Error de Recolección; lo que existe de “error de definición” ahí es el Error de Negocio. La pantalla rechaza la combinación inválida en vez de crear una alerta que nunca dispararía.
Mensajes acumulados
El límite no está en la alerta, sino en la Interfaz (campo de alerta de mensajes acumulados). Un
programador de sistema — Check-msg-acumulada-alert — recorre las interfaces cada minuto y dispara la
alerta de quien pasó del techo. Por eso esa alerta llega con hasta un minuto de retraso, por
construcción.
Destinatarios
Solo aparecen en la lista los usuarios con “¿Acepta recibir alertas?” marcado en su registro, y que tengan acceso a la Aplicación/Interfaz de la alerta. Si la lista viene vacía, eso es lo que falta — la pantalla lo dice explícitamente.
Una alerta puede configurarse para varios usuarios; cada uno recibe su propia copia, y la lectura es individual.
Canales
| Canal | Cómo funciona | Requisito |
|---|---|---|
| Notificación in-app | Campana en el encabezado, con conteo de no leídos | Ninguno |
| Correo | Un mensaje por destinatario | SMTP en Configuraciones → E-mail |
| Webhook | Un POST con la alerta en JSON | Webhook habilitado en Configuraciones |
| Ticket | Abre un ticket en cada destino elegido en Abrir ticket en | Una herramienta activada y un destino — ver Help Desk |
La notificación in-app siempre se graba — incluso con correo y webhook apagados, la alerta queda en el historial y en la campana. Cada usuario ve sus últimos no leídos, puede descartarlos uno a uno o marcar todos como leídos.
El webhook, y qué resuelve
El canal marcado como WhatsApp en la pantalla envía, en realidad, un POST a la URL configurada en Configuraciones — típicamente una automatización (n8n, Power Automate, Zapier) que decide qué hacer con eso. El cuerpo es estandarizado:
{
"tipo": "APLICACAO_OFFLINE",
"mensagem": "🔴 Aplicación MES - Manufacturing Execution System está offline!\n...",
"disparadoEm": "2026-08-26T13:40:02.145Z",
"aplicacao": { "id": 1, "sigla": "MES", "descricao": "..." },
"fila": null,
"definicaoMensagem": null,
"definicaoColeta": null,
"contexto": { "erro": "connect ETIMEDOUT 10.0.3.7:8080" },
"destinatarios": [
{ "id": 4, "nome": "...", "login": "...", "email": "...", "telefone": "..." }
]
}Note que los teléfonos de los destinatarios van en el payload: es lo que permite a la automatización disparar WhatsApp, SMS o una llamada sin consultar el CMS. El endpoint acepta Basic Auth opcional.
Como el payload lleva datos de contacto, apunte el webhook únicamente a un endpoint bajo su control. Sale del CMS con todo lo que la automatización necesita para hablar con las personas.
Ticket
El campo Abrir ticket en elige en qué destinos de ticket la alerta abre un ticket — cada destino con el ícono, la sigla y la descripción de la herramienta, para que no haya dudas sobre en qué sistema se abrirá. Una alerta puede abrir tickets en más de un destino a la vez.
La lista no trae los destinos marcados como Disponible en la apertura manual: esos son del botón Abrir ticket del mensaje con error, con campos que completa un operador. Un destino ya vinculado sigue en la lista, para poder desactivarlo.
En Aplicación Offline aparece también Solo abrir ticket después de (minutos), con 5 por defecto: el correo sale de inmediato, y el ticket solo si la Aplicación sigue caída después de ese tiempo. La deduplicación, la alerta de recuperación y lo que pasa cuando la propia herramienta se cae están en Help Desk.
Encontrar lo que está activo
Una Aplicación acumula decenas de alertas pre-registradas y desactivadas, y las pocas activas se pierden en medio de ellas. Tres recursos responden “¿dónde está encendida?” sin abrir fila por fila:
- Conteo por nivel. Los grupos Aplicación, Interfaz y Definición traen, a la derecha, cuántas alertas están activas e inactivas — en la misma columna que los contadores de la Aplicación. Recorriendo con la vista hacia abajo, se ve en qué nivel están las activas.
- Resumen de la Aplicación abierta. Una franja arriba muestra dónde están las activas, con un sello por lugar — la propia Aplicación, cada Interfaz, cada Definición, con la cantidad — y por qué canales avisan: e-mail, WhatsApp y ticket.
- Ver dónde está activo. El botón de la franja, o el contador verde en el encabezado de la Aplicación (sin necesidad de expandirla), abre un popup con las alertas activas agrupadas por el lugar donde valen, con los canales, los destinos de ticket, los destinatarios y el lápiz que abre la edición.
El conteo, la franja y el popup respetan los filtros y la búsqueda de la pantalla.
Dónde más aparecen las alertas
- En la campana del encabezado, con conteo de no leídos.
- En el Panel de Aplicaciones y en el Cockpit, como alerta sonora y título de pestaña parpadeando cuando una aplicación monitoreada se cae.
- En la pantalla de Definiciones, donde las alertas de esa definición pueden configurarse sin pasar por aquí.
Permiso
La Herramienta es /alerts. Como todas las pantallas agrupadas por Aplicación, el usuario solo ve
alertas de las Aplicaciones e Interfaces a las que tiene acceso.