Monitor

Con varios sistemas propios en producción (Arca, SortealoPE, la propia landing, Utilitarios), la pregunta "¿todo sigue en pie?" dejó de tener una respuesta obvia. Revisar cada dominio a mano, uno por uno, no avisa nada hasta que un cliente escribe para decir que algo no carga.

El problema

Monitor centraliza dos cosas que antes no existían en ningún lugar único: salud (cada sistema responde su propio /health, que de verdad consulta su base de datos en vez de solo confirmar que el proceso sigue vivo) y auditoría (quién entró, desde dónde y qué hizo, para los sistemas con login). Un sistema en producción que no está enganchado a Monitor es un punto ciego.

Cómo se construyó

Backend en Node y Express con PostgreSQL propia, y tiempo real por Server-Sent Events en vez de WebSockets — más simple de operar en un cPanel compartido sin Redis ni Docker. El frontend en Vite y React se compila a estático y lo sirve el mismo backend, un solo proceso Passenger por sistema hospedado. Cada app monitoreada expone su salud por pull (Monitor la consulta) o empuja su auditoría por push con un cliente compartido (audit-client.js) que se integra en el login y las acciones sensibles de cada sistema.

Por qué esto no es opcional

Un panel de sistemas que se presenta como profesional pero no sabe si sus propios productos están caídos es, en el fondo, una portada que miente. Cada sistema nuevo que llega a producción se engancha a Monitor antes de darlo por terminado — no es una mejora posterior, es parte del criterio de "listo para producción" del propio catálogo.

Estado actual

Monitor está en producción en monitor.appssdar.com, vigilando en tiempo real los sistemas del catálogo que ya están en vivo. Es una herramienta interna de operación, no un producto para terceros, así que no tiene enlace público de acceso — hay una demostración de alto nivel de cómo se ve el panel.