Uptime Kuma en cámaras: alertas, cortes y estado publico
Un caso de cámara empresaria que ordena web, DNS, certificados y formularios con Uptime Kuma 2.3, alertas, mantenimiento y copia de la base.
URL, certificado y formulario: cuando uno falla, el asociado llama al tesorero antes de que llegue el proveedor. En una cámara empresaria de San Martin, la web de inscripcion, el DNS, el correo y el sistema de pagos tenian avisos separados. Uptime Kuma 2.3 reune monitores, alertas y página de estado. Este caso muestra qué se carga primero, quien responde y cómo se recupera la base.
Dónde se ve el corte antes del llamado
La cifra que corrige la ansiedad esta en la página de estado: Uptime Kuma cachea resultados durante 5 minutos y refresca la página cada 5 minutos. Ese margen evita prometer tiempo real donde hay una vista publica para socios. La operación diaria necesita otro panel para quien responde el incidente. Cinco minutos alcanzan para avisar sin inventar certezas. La escala global muestra que el monitoreo abierto ya no es raro. Octoverse 2025 informo más de 180 millones de desarrolladores y 630 millones de repositorios. En una cámara local, la escala baja a cuatro servicios, tres proveedores y un tesorero que necesita saber que paso antes de llamar al socio.
El aviso escondido en el grupo de guardia
El antagonista es el mensaje de guardia que dice "se cayo la web" y no incluye URL, hora, certificado, DNS ni responsable. El tesorero de una cámara empresaria en San Martin revisa cuotas y altas desde una notebook con stickers de jornadas sectoriales. Un cable de red gris cruza detras de la impresora fiscal; el monitor debe decir si fallo el formulario, el dominio o el servidor. El repositorio de Uptime Kuma muestra más de 86.000 estrellas, licencia MIT y desarrollo activo. La versión 2.3.2, publicada el 3 de mayo de 2026, corrigio el uso de una sola conexión SQLite por defecto. Para una organización chica, esa decisión importa porque la base suele vivir en el volumen local de la aplicación.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, IT instala Uptime Kuma con Docker y monta el volumen /app/data en almacenamiento local. Segundo, carga monitores HTTP, DNS, ping, certificado y puerto. Tercero, define intervalos, reintentos y etiquetas por servicio. Cuarto, configura alertas por correo, webhook o proveedores soportados. Quinto, publica una página de estado para socios con los servicios visibles. Sexto, programa mantenimiento para tareas previstas. Septimo, copia la base SQLite y archivos de /app/data, y prueba restauración en otro contenedor. Uptime Kuma recibe una URL, dominio, puerto o certificado y entrega estado, tiempo de respuesta, historial y alerta. SQLite guarda monitores, incidentes, usuarios, notificaciones y página de estado. La guía de instalación advierte que /app/data debe estar en un volumen local porque los bloqueos POSIX evitan corrupcion de SQLite. Las notificaciones toman un evento y entregan mensaje por canal configurado. Si falla Uptime Kuma, la cámara pierde visibilidad. Si falla SQLite, se pierde historial. Si falla el canal de alerta, el panel marca rojo y nadie recibe aviso. Los permisos se separan por tarea. IT edita monitores y canales. Mesa administrativa lee estado y mantenimiento. Tesoreria recibe avisos del sistema de pagos. Proveedores ven solo el servicio que atienden. Borrar incidentes queda fuera de la rutina diaria.
Qué se instala o configura primero
La pila inicial usa Uptime Kuma 2.3, Docker, volumen local, reverse proxy HTTPS, correo saliente, webhook, página de estado, mantenimiento programado y backup del volumen. El piloto cuesta entre USD 700 y USD 2.100, entre ARS 986.300 y 2,96 millones al dólar vendedor oficial de $1.409 informado por Bluelytics. Incluye instalación, veinte monitores, cuatro canales, página publica, respaldo y prueba de restauración. El plazo va de una a tres semanas. UMSA suele pedir un entregable verificable: web, DNS, certificado, formulario y pago monitoreados; dos alertas reales; una ventana de mantenimiento; una página de estado para socios; una copia de /app/data; y una restauración que conserve historial. El costo no incluye cambios en hosting ni soporte 24x7. La primera configuración debe nombrar dueno y acción. "Formulario socios" necesita responsable, canal de aviso, horario critico y texto publico. Si un monitor queda sin dueno, el panel solo cambia de color. El reporte semanal separa caidas por proveedor, servicio y horario. Tesoreria ve si el problema fue hosting, dominio, certificado o integración de pagos, y soporte conserva la hora exacta para reclamar.
Dónde se rompe y cómo probarlo Primer riesgo: monitorear solo la home.
La señal aparece cuando la página principal responde, pero el formulario de inscripcion falla. La prueba carga monitores para home, formulario, DNS y certificado. Segundo riesgo: alertas duplicadas. La señal es un tesorero con cinco mensajes por un mismo corte. La prueba baja un servicio y revisa cantidad, canal y hora. Tercer riesgo: mantenimiento sin aviso publico. La guía de mantenimiento permite asociar monitores y páginas de estado a una ventana. La prueba programa una tarea, verifica color y texto, y cancela al terminar. Cuarto riesgo: backup del contenedor sin /app/data. La prueba restaura en otro puerto y confirma monitores, incidentes, usuarios y página de estado. El socio deja de preguntar cuando el estado publico muestra hora y responsable.