Hay una diferencia enorme entre que un servicio esté levantado y que sirva para algo. Docker puede decir “healthy”, systemd puede estar contento, el puerto puede responder y aun así la aplicación estar rota para la persona que la usa.
Esto en un homelab doméstico se nota rápido. No te avisa un SLA. Te avisa alguien diciendo que las fotos no cargan, que la domótica no responde, que una web va rara o que internet “está roto” porque el DNS decidió irse a por tabaco. Y cuando el primer síntoma llega por la familia, normalmente ya vas tarde.
Por eso me gustan los healthchecks pequeños. No hablo de montar una plataforma de observabilidad enorme para ver gráficas preciosas que nadie mira. Hablo de pruebas simples que contesten una pregunta concreta: ¿lo importante sigue funcionando?
La clave está en no confundir monitorización con decoración. Una alerta útil te permite actuar antes de que el problema sea visible. Una alerta mala solo te entrena para ignorar Telegram, correo o el canal donde la hayas puesto. Y eso es peor que no tener nada.
El healthcheck bueno prueba una función, no un puerto#
El primer impulso suele ser comprobar si un puerto responde. Para algunas cosas basta. Si un reverse proxy no responde en 443, tenemos problema. Si el panel de una aplicación no abre, también.
Pero muchos fallos reales pasan por debajo de ese nivel.
Un gestor de fotos puede responder HTTP mientras no genera miniaturas. Un servicio de documentos puede abrir la interfaz mientras el OCR está muerto. Una automatización puede estar levantada mientras la cola de jobs se acumula. Un sistema de backups puede terminar con código cero mientras lleva semanas copiando una carpeta equivocada.
Por eso intento que cada healthcheck mida una función mínima del servicio.
Para una web pública, no miro solo si responde. Miro si devuelve el código esperado y si contiene una cadena que sé que debe estar en la página.
Para DNS, no miro si el contenedor vive. Hago una resolución real de un dominio externo y otra de un nombre interno.
Para backups, no miro solo si terminó el job. Compruebo edad del último backup, tamaño razonable y, si puedo, una operación pequeña de lectura.
Para domótica, no necesito probar todas las luces. Me basta saber si Home Assistant responde, si puede hablar con el broker o integración principal, y si las automatizaciones críticas no están desactivadas.
La pregunta no es “¿está encendido?”. La pregunta es “¿hace lo que necesito?”.
Empiezo por lo que rompería la convivencia#
En un homelab es muy fácil monitorizar lo divertido y olvidarse de lo que importa. Métricas de CPU, temperatura, discos, contenedores, latencia interna. Todo eso está bien. Pero si tengo que elegir, empiezo por los servicios que romperían la convivencia en casa.
Mi orden suele ser este:
- DNS y acceso a internet.
- Domótica básica si la casa depende de ella.
- Backups de datos familiares.
- Fotos y documentos.
- Contraseñas y servicios de identidad.
- Webs o servicios expuestos fuera.
- Laboratorio, dashboards y juguetes varios.
La palabra “juguetes” aquí no es desprecio. Muchos de esos servicios molan. Pero si se cae un dashboard de Grafana, nadie cena peor. Si se cae DNS y los móviles dejan de navegar, el homelab pasa de afición a enemigo público.
Ese orden también evita una trampa clásica: acabar con 70 alertas para cosas que no requieren acción inmediata. Si algo puede estar roto dos días sin consecuencias reales, quizá no necesita despertarme ni interrumpirme.
Healthchecks concretos que sí me parecen útiles#
Para DNS uso dos pruebas. Una externa y una interna.
La externa comprueba que puedo resolver un dominio normal. La interna comprueba un nombre de mi red, usando un dominio genérico en documentación y evitando depender de memoria. Si falla la externa, puede ser internet, upstream o DNS. Si falla la interna, puede ser split DNS, Pi-hole, AdGuard o el servidor local.
Para un reverse proxy miro tres cosas: que responde, que el certificado no está cerca de caducar y que una ruta real devuelve contenido esperado. Un 200 en la raíz puede mentir si la aplicación importante vive en otra ruta.
Para backups me gusta comprobar edad y tamaño. Si el último backup tiene más de X horas, mal. Si pesa demasiado poco comparado con lo normal, sospechoso. Si pesa demasiado, también puede ser señal de que algo empezó a meter basura. El tamaño no garantiza calidad, pero detecta muchas cagadas.
Para bases de datos uso una consulta mínima de lectura. Nada destructivo. Algo como contar registros de una tabla pequeña o comprobar que acepta conexión. Si la app responde pero la base de datos va mal, prefiero saberlo antes de que el usuario lo descubra.
Para colas y workers miro acumulación. Muchas apps modernas funcionan con trabajos en segundo plano. La interfaz abre, pero los trabajos no salen. Miniaturas, OCR, emails, importaciones, sincronizaciones. Si la cola crece y no baja, el servicio está enfermo aunque la portada cargue.
Para almacenamiento miro espacio libre, pero también estado de montaje. Este fallo es traicionero: crees que estás escribiendo en un NAS y en realidad el montaje se cayó, así que el servidor empieza a llenar el disco local. Una prueba de “este path está montado donde toca” vale oro.
Uptime Kuma está bien, pero no todo cabe ahí#
Uptime Kuma me parece una herramienta muy decente para casa. Es sencilla, visual, rápida de montar y suficiente para muchas comprobaciones HTTP, TCP, DNS y certificados. Para empezar, la recomiendo sin drama.
Pero hay que conocer su límite. Uptime Kuma ve muy bien disponibilidad externa. No siempre entiende la lógica interna de tus servicios.
Si quieres saber si una copia terminó, si una carpeta tiene un tamaño razonable, si una cola lleva demasiados trabajos o si un job procesó algo en las últimas 24 horas, probablemente necesites un script pequeño. Y eso está bien. No todo tiene que vivir dentro de una herramienta.
Mi patrón favorito es bastante simple:
- Uptime Kuma para checks de red, HTTP, DNS y certificados.
- Scripts pequeños para lógica de negocio doméstica.
- Un endpoint o ping final para avisar si el script pasó.
- Alertas solo cuando hay acción clara.
Ese último punto es el más importante. Si una alerta no me dice qué hacer, es ruido.
Un check pequeño para backups#
Un ejemplo práctico. Imagina un backup diario de documentos. No quiero comprobar solo que el cron se ejecutó. Quiero saber si existe una copia reciente y si tiene un tamaño mínimo razonable.
Algo tan simple como esto ya detecta bastante:
| |
No es perfecto. No prueba una restauración completa. Pero es infinitamente mejor que mirar un log una vez cada seis meses.
Si quiero cerrar el círculo, ese script puede terminar haciendo un ping a un servicio de healthchecks cuando sale bien. Si falla, no hace ping y recibo aviso. También puede enviar una notificación directa, pero prefiero centralizar alertas para no crear otra fuente de ruido.
Cuidado con los falsos positivos#
Una alerta que salta demasiado acaba muerta. La ignoras, la silencias o la justificas mentalmente. “Será lo de siempre”. Esa frase es la lápida de cualquier sistema de monitorización.
Para evitarlo, intento que los checks tengan margen. Si un backup diario suele terminar a las 03:00, no alerto a las 03:05. Doy horas de margen. Si una web tarda un poco en arrancar después de reiniciar, no quiero 20 avisos durante una ventana de mantenimiento.
También separo alerta de warning. No todo merece el mismo canal. Un certificado que caduca en 20 días puede esperar. Un DNS caído ahora mismo no.
La severidad doméstica podría ser así:
- Crítico: afecta a internet, DNS, datos familiares, contraseñas o servicios usados por otros.
- Medio: afecta a servicios personales importantes, pero puedo arreglarlo luego.
- Bajo: laboratorio, métricas, cosas duplicadas o recreativas.
Si todo es crítico, nada es crítico. Esto vale para empresas y vale más todavía en casa, donde el operador eres tú y probablemente estás haciendo otra cosa.
Healthchecks durante mantenimiento#
Otra fuente de ruido son las ventanas de mantenimiento. Actualizas un nodo, reinicias contenedores, mueves una VM y el sistema de alertas empieza a gritar como si hubiese ardido el rack.
Aquí soy bastante práctico. Si sé que voy a tocar algo, pongo silencio temporal o modo mantenimiento. No desactivo checks para siempre, que eso es peligrosísimo. Los pauso con caducidad.
Una buena regla es que cualquier silencio tenga fecha de fin. Si no, seis meses después descubres que el servicio más importante estaba mudo porque una noche te dio pereza volver a activarlo.
También me gusta tener un check posterior al mantenimiento. Algo que responda a la pregunta: “¿lo básico sigue vivo después de tocar?”. DNS, proxy, backups, almacenamiento, servicios principales. No hace falta revisar 50 cosas a mano si tienes cinco pruebas bien elegidas.
Logs verdes no son salud#
Los logs verdes tranquilizan, pero no siempre dicen la verdad útil. Un job puede terminar bien y no haber hecho nada valioso. Una app puede decir que está healthy porque el proceso responde, aunque no pueda escribir en disco. Un contenedor puede reiniciarse solo y ocultar un fallo intermitente durante semanas.
Por eso combino tres señales:
- Disponibilidad: responde.
- Función: hace algo real.
- Frescura: ha hecho algo útil hace poco.
La frescura se olvida mucho. En servicios de sincronización, backups, ingestas, OCR o automatizaciones, saber que “algo pasó recientemente” es clave. Si no se procesó ningún documento en 20 días y debería haber movimiento diario, algo huele raro.
Esto también ayuda con los servicios que no tienen tráfico constante. Una web personal puede estar rota y nadie enterarse hasta que la necesitas. Un check sintético la visita cada cierto tiempo y evita esa lotería.
No monitorices lo que no vas a arreglar#
Esta regla duele un poco, porque a los que montamos homelabs nos encantan las métricas. Pero es sana.
Si no vas a actuar ante una alerta, no la pongas. O ponla como métrica visible, no como interrupción.
Temperatura de CPU un poco alta en verano. Si no vas a apagar nada, limpiar ventiladores ni mover el equipo, quizá no necesitas alerta. Disco al 60 por ciento. No pasa nada. Contenedor recreativo caído. Puede esperar.
En cambio, disco al 90 por ciento en el servidor que recibe backups. Eso sí. Certificado a punto de caducar en un servicio expuesto. También. Backup crítico sin ejecutarse desde hace dos días. Eso merece aviso claro.
La monitorización buena no intenta contarlo todo. Intenta reducir sorpresas.
Mi plantilla mental por servicio#
Cuando añado un servicio nuevo, intento responder estas preguntas antes de olvidarme:
- ¿Quién lo usa?
- ¿Qué pasa si se cae?
- ¿Qué dependencia suele romperlo?
- ¿Cuál es la prueba mínima de que funciona?
- ¿Cada cuánto debería ejecutarse esa prueba?
- ¿Dónde quiero recibir aviso?
- ¿Qué haré cuando avise?
Si no puedo responder la última, no configuro alerta todavía. Investigo un poco más o lo dejo como monitor sin notificación.
Para un servicio de fotos, la prueba mínima puede ser abrir la API, comprobar base de datos y ver que el worker de miniaturas no está muerto. Para documentos, buscar un documento de prueba y comprobar OCR. Para DNS, resolver fuera y dentro. Para backups, edad, tamaño y lectura pequeña. Para una web, HTTP, certificado y contenido esperado.
Cada servicio tiene su pequeño contrato. El healthcheck solo comprueba que ese contrato se cumple.
Conclusión#
Los healthchecks caseros no tienen que ser sofisticados. Tienen que estar bien elegidos.
Prefiero diez checks que prueban funciones reales a cien checks que solo miran puertos. Prefiero una alerta que me dice “el backup familiar lleva 36 horas sin actualizarse” a veinte mensajes diciendo que un contenedor de laboratorio se reinició.
La mejor señal de que lo estás haciendo bien es que las alertas son pocas y cuando llegan sabes qué tocar. La peor señal es tener un canal lleno de avisos que ignoras.
En casa, la monitorización no existe para impresionar a nadie. Existe para que el homelab no se convierta en una fuente de soporte técnico absurdo. Si algo importante se va a romper, quiero enterarme yo antes que la familia. Por pura supervivencia doméstica.