Uptime Kuma en camaras: alertas, cortes y estado publico
Un caso de camara 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 camara 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 pagina de estado. Este caso muestra que se carga primero, quien responde y como se recupera la base.
Donde se ve el corte antes del llamado
La cifra que corrige la ansiedad esta en la pagina de estado: Uptime Kuma cachea resultados durante 5 minutos y refresca la pagina cada 5 minutos. Ese margen evita prometer tiempo real donde hay una vista publica para socios. La operacion 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 mas de 180 millones de desarrolladores y 630 millones de repositorios. En una camara 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 camara 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 mas de 86.000 estrellas, licencia MIT y desarrollo activo. La version 2.3.2, publicada el 3 de mayo de 2026, corrigio el uso de una sola conexion SQLite por defecto. Para una organizacion chica, esa decision importa porque la base suele vivir en el volumen local de la aplicacion.
Como funciona por dentro
El flujo minimo 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 pagina 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 restauracion 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 pagina de estado. La guia de instalacion 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 camara 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.
Que se instala o configura primero
La pila inicial usa Uptime Kuma 2.3, Docker, volumen local, reverse proxy HTTPS, correo saliente, webhook, pagina 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 dolar vendedor oficial de $1.409 informado por Bluelytics. Incluye instalacion, veinte monitores, cuatro canales, pagina publica, respaldo y prueba de restauracion.
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 pagina de estado para socios; una copia de /app/data; y una restauracion que conserve historial. El costo no incluye cambios en hosting ni soporte 24x7.
La primera configuracion debe nombrar dueno y accion. "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 integracion de pagos, y soporte conserva la hora exacta para reclamar.
Donde se rompe y como probarlo
Primer riesgo: monitorear solo la home. La senal aparece cuando la pagina principal responde, pero el formulario de inscripcion falla. La prueba carga monitores para home, formulario, DNS y certificado. Segundo riesgo: alertas duplicadas. La senal 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 guia de mantenimiento permite asociar monitores y paginas 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 pagina de estado. El socio deja de preguntar cuando el estado publico muestra hora y responsable.