Uptime Kuma 2.5.4: SFTP, alertas y salida
Guía técnica para monitoreo propio con Uptime Kuma: HTTP, SFTP, notificaciones, página de estado, permisos, backup y prueba de salida operativa.
Un monitor SFTP cuenta algo que un panel de uptime común suele dejar afuera: si el archivo llegó, si la clave responde y si la alerta sale a tiempo. Uptime Kuma 2.5.4 suma ese tipo de monitor y mantiene controles para HTTP, TCP, DNS, ping y páginas de estado. Para una pyme, la guía útil es dónde se guarda la configuración, quién recibe alertas, qué volumen se respalda y cómo se prueba la salida.
Dónde aparece el monitoreo propio
El release 2.5.4 de Uptime Kuma agrega monitor SFTP con contraseña o clave privada, nuevos proveedores de notificación, correcciones de caché y una actualización de seguridad de jsonata. La mejora tiene lectura operativa: muchas tareas críticas no son sitios web, sino servicios que entregan archivos, emiten reportes o esperan conexiones internas. La documentación principal del repositorio lista monitores HTTP, TCP, JSON Query, WebSocket, ping, DNS, push, juegos, contenedores Docker, páginas de estado, intervalos de 20 segundos y más de 90 servicios de notificación. Ese conjunto evita una planilla de chequeos manuales que nadie revisa a las dos de la mañana. El tablero sin dueño es el antagonista. En una clínica privada de Godoy Cruz, soporte tenía un monitor del sitio público y ninguna prueba del envío de archivos a un proveedor. La pulsera de admisión imprimía bien, el sitio respondía y el lote SFTP fallaba cada domingo. La alerta llegaba como comentario perdido en el chat. El primer cambio fue nombrar servicios por rutina: sitio, VPN, SFTP, correo, turno web y base de reportes. El paso siguiente es definir quién puede crear monitores y quién solo recibe avisos.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, sistemas instala Uptime Kuma en Docker y publica la consola detrás de un proxy HTTPS. Segundo, un administrador crea monitores: HTTP para sitios, TCP para puertos, DNS para registros y SFTP para llegada de archivos. Tercero, la aplicación guarda configuración y resultados en su volumen de datos local; por eso el README advierte que NFS no está soportado y pide un directorio o volumen local. Cuarto, cada monitor genera estados y tiempos de respuesta. Quinto, las notificaciones salen por correo, Telegram, Slack, Gotify u otro proveedor definido en el repositorio de componentes. Sexto, una página de estado muestra a gerencia qué servicio está caído, degradado o recuperado. El permiso de administración queda separado del permiso de lectura: quien consulta estado no necesita borrar monitores. La encuesta Stack Overflow 2025 ubica las preocupaciones de seguridad y privacidad al tope de los motivos que frenan una tecnología en proyectos de trabajo. En monitoreo propio eso se traduce en una pregunta concreta: qué URLs, credenciales y tokens quedan dentro del sistema, y quién puede verlos. El backup decide si el tablero vuelve después de una falla.
Qué se instala o configura primero
La pila inicial usa un VPS chico, Docker Compose, volumen local, proxy HTTPS, correo saliente y un canal de alertas. Uptime Kuma recibe respuestas de servicios y entrega estado, historial y avisos. El volumen local guarda monitores, usuarios, páginas de estado y configuración. El proxy limita exposición; el backup copia el volumen y una prueba restaura la consola en otra máquina. Con dólar oficial venta a ARS 1.530, el servidor puede costar entre USD 8 y USD 20 mensuales, es decir entre ARS 12.240 y ARS 30.600. Una puesta en marcha prudente va de USD 320 a USD 650, entre ARS 489.600 y ARS 994.500. Incluye diez monitores, dos canales de alerta, página de estado interna, backup y prueba de restauración. No incluye SMS pagos ni guardia 24x7. UMSA puede ordenar el arranque con una matriz breve: servicio, dueño, prueba, canal, horario y acción esperada. Si el SFTP falla, el aviso debe decir qué lote quedó pendiente y quién lo toma. Si el sitio responde lento, el tablero debe mostrar URL, tiempo, última caída y canal enviado. La primera entrega se acepta cuando una alerta llega a la persona correcta y deja registro.
Dónde se rompe y cómo probarlo
El primer riesgo es monitorear una URL que siempre responde 200 aunque el proceso interno esté roto. La señal aparece cuando el sitio figura activo y el usuario no puede completar una operación. La prueba agrega un monitor HTTP con palabra esperada o JSON Query y compara respuesta contra una operación real. El segundo riesgo es guardar el volumen en NFS o en una ruta que no entra al backup. La señal aparece cuando una restauración trae el contenedor vacío. La prueba levanta una copia en otra máquina y verifica que aparezcan monitores, usuarios y páginas de estado. El tercer riesgo es una alerta sin destinatario. La señal aparece cuando todos reciben todo y nadie toma nada. La prueba apaga un servicio de laboratorio, mide el tiempo de aviso y confirma quién cerró el incidente. El cuarto riesgo es dejar credenciales SFTP sin revisión. La prueba rota una clave de prueba, actualiza el monitor y confirma que la alerta vuelve a verde. Un monitor sirve cuando obliga a corregir el flujo, no solo a mirar un color.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.