Cómo monitorear tus sistemas y enterarte antes que tus clientes (con Uptime Kuma)

Hay una pregunta que distingue a las empresas que tienen su tecnología bajo control de las que no: ¿cómo te enteras de que algo se cayó?

Si la respuesta es "porque alguien llama", el problema no es la caída. Es que entre que ocurre y que alguien la reporta pueden pasar veinte minutos o tres horas, y en ese lapso ya se perdieron ventas, se desperdiciaron horas de trabajo o —peor— nadie notó que el respaldo lleva ocho días sin correr.

Este tutorial monta la solución en una tarde con Uptime Kuma, una herramienta de código abierto que no cuesta licencia.

Antes de instalar nada: decide qué vas a vigilar

El error más común es monitorear todo. Cuarenta alertas que nadie lee protegen menos que seis que sí se atienden.

Haz la lista con este criterio: qué se detiene en el negocio si esto falla.

Paso 1 — Instalar, fuera de tu propia infraestructura

Uptime Kuma se levanta con Docker en unos minutos. Lo importante no es el comando: es dónde lo pones.

docker run -d --restart=always -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma louislam/uptime-kuma:1

Regla no negociable: instálalo fuera de la infraestructura que vas a vigilar. Si corre en el mismo servidor que aloja tu sitio, el día que ese servidor falle también se cae el monitoreo y la alerta nunca se envía. Lo práctico es una instancia pequeña con otro proveedor o en otra ubicación; cuesta unos pocos dólares al mes y es la diferencia entre tener monitoreo y creer que lo tienes.

Al entrar por primera vez, crea el usuario administrador y ponle segundo factor. Este panel sabe dónde está todo lo tuyo.

Paso 2 — Configurar los monitores

Para cada servicio, decide qué tipo de revisión corresponde:

• HTTP(s) para sitios y tiendas. No apuntes solo a la portada: apunta a una página que use la base de datos, como una ficha de producto. Una portada en caché puede seguir cargando con el sistema muerto atrás.
• TCP para servicios que escuchan en un puerto: base de datos, correo, VPN.
• Ping solo para saber si un equipo está vivo. Dice poco.
• Palabra clave para verificar que la respuesta contenga cierto texto. Es la más útil: detecta el caso en que el servidor responde "200 OK" con una página de error.
• Push para trabajos programados como los respaldos. Aquí se invierte la lógica: el trabajo avisa cuando termina bien, y si el aviso no llega a tiempo, salta la alerta.

Intervalos razonables: cada 60 segundos para lo crítico de cara al cliente, cada 5 minutos para lo interno. Revisar cada 10 segundos no te hace más rápido; te hace tener más falsos positivos.

Paso 3 — Las alertas, que es donde se gana o se pierde

Un monitoreo que avisa por correo a una cuenta que nadie mira es un monitoreo decorativo. Configura al menos dos canales: uno inmediato —Telegram, WhatsApp vía integración, o notificación push al teléfono— y uno de registro, como el correo.

Los tres ajustes que hacen la diferencia:

1. Reintentos antes de alertar. Configura que avise después de dos o tres fallas consecutivas, no a la primera. Un parpadeo de red de tres segundos no debe despertar a nadie a las 2 de la mañana; si lo hace, en dos semanas todo el mundo silencia el canal.
2. Destinatario con nombre. Cada monitor debe tener una persona responsable, no un grupo general. En un grupo, todos asumen que alguien más lo vio.
3. Aviso de recuperación activado. Quien recibió la alerta necesita saber que ya pasó. Sin eso, la gente deja de confiar en el sistema.

Paso 4 — La página de estado

Uptime Kuma permite publicar una página de estado con el estado de tus servicios. Vale la pena para dos públicos:

• Interno: una URL que cualquiera en la empresa puede abrir antes de reportar "no me carga el sistema". Resuelve la mitad de las llamadas a soporte.
• Externo: si das servicio a otras empresas, una página pública de estado es un argumento de profesionalismo. Pero solo si la mantienes honesta: una página que siempre dice verde mientras el servicio está caído hace más daño que no tenerla.

Los cinco errores que convierten el monitoreo en ruido

1. Monitorear la portada en caché en vez de una página real. El sitio "responde" con la base de datos muerta.
2. Instalarlo dentro de lo que vigila. Ya está dicho, y sigue siendo el error más frecuente.
3. Alertar a un grupo sin responsable. Nadie se hace cargo.
4. No poner el certificado SSL. Es la caída más previsible del mundo y la más vergonzosa.
5. No revisar el monitoreo nunca. Un monitor apuntando a un servicio que ya no existe, alertando cada hora durante meses, es cómo muere la confianza en el sistema. Revísalo un día cada trimestre.

Qué sigue después

Con esto cubres la pregunta "¿está arriba?". Las dos preguntas siguientes son "¿está lento?" y "¿por qué?", y para eso hacen falta métricas y registros, que es otro nivel de herramienta — Grafana y Prometheus es el camino natural cuando llegue el momento.

Pero no te adelantes. La mayoría de las empresas medianas no necesitan tableros de métricas: necesitan enterarse de que algo se cayó antes que su cliente. Eso se resuelve en una tarde y con costo casi cero, y es lo que evita que el próximo incidente se descubra por una llamada molesta. Si tu operación no puede permitirse el hueco entre la caída y el aviso, los servicios administrados incluyen justamente a alguien que mira esas alertas.