El primer sistema de alertas de un homelab suele nacer con buena intención y acabar convertido en una máquina de molestar. Montas Uptime Kuma, añades todos los servicios, conectas Telegram, haces un par de cron jobs, pones avisos para backups, certificados, discos, contenedores, CPU, memoria, temperatura y cualquier cosa que tenga una métrica. Durante dos días te sientes en control. A la semana empiezas a ignorarlo.
Ese es el fracaso real de una alerta. No que falle técnicamente. Que entrenes a tu cerebro para no hacerle caso.
En casa no hay un NOC ni un equipo de guardia. Hay una persona con vida, trabajo, familia y ratos de cacharreo. Si el homelab me despierta o me interrumpe, más le vale tener una razón. Si no, el sistema de alertas se convierte en otro servicio que mantener, justo lo contrario de lo que quería.
Mi regla actual es simple: una alerta solo merece existir si cambia una acción.
El ruido también rompe sistemas#
Cuando pensamos en fiabilidad, solemos mirar discos, backups, alimentación, red y actualizaciones. Pero el ruido también rompe sistemas. Los rompe por la vía humana.
Si recibo diez avisos al día y ocho no importan, el noveno puede ser crítico y aun así pasará desapercibido. Telegram lleno de mensajes rojos no es observabilidad. Es decoración de ansiedad.
El problema se agrava porque muchas herramientas son demasiado fáciles de conectar. Uptime Kuma manda notificaciones en minutos. Cron puede enviar mensajes con curl. Un script puede avisar por ntfy, email, Discord o lo que sea. La parte técnica es trivial. La parte difícil es decidir qué no debe avisar.
Un homelab tiene que monitorizarse con una idea clara de impacto. No todo lo caído importa igual. No todo lo raro exige atención inmediata. No todo lo que se puede medir merece una notificación.
Mi clasificación de alertas#
Antes de configurar canales, clasifico los problemas en cuatro niveles.
El primer nivel es urgente y doméstico. Cosas que afectan a la casa o a datos importantes: DNS caído, acceso a internet roto, Home Assistant fuera si controla cosas reales, servidor de backups fallando varios días, almacenamiento crítico lleno, certificado caducado de un servicio que uso desde fuera, temperatura peligrosa o un disco con señales claras de fallo.
El segundo nivel es importante pero no urgente. Backups que fallan una noche, un servicio personal caído, un contenedor reiniciado, espacio creciendo más de lo normal, actualizaciones pendientes en algo sensible, un certificado que caduca dentro de dos semanas.
El tercer nivel es informativo. Métricas curiosas, servicios de laboratorio caídos, tareas que terminaron bien, reinicios planificados, cambios menores. Esto no debería interrumpirme. Como mucho, entra en un resumen diario o en un panel.
El cuarto nivel es basura. CPU alta durante cinco minutos, memoria cacheada, un contenedor de pruebas apagado, un ping perdido, logs que suenan dramáticos pero no tienen consecuencia. Esto no merece alerta. Merece silencio o revisión manual cuando toque.
Esta clasificación cambia la configuración entera. De repente no necesito que todo hable por Telegram. Necesito que pocas cosas hablen bien.
Uptime Kuma: buen panel, mal megáfono si te pasas#
Uptime Kuma me gusta mucho para homelab. Es simple, visual, rápido de montar y suficientemente flexible. Pero es peligrosamente cómodo añadir monitores.
Mi consejo es no meter todo. Meter lo importante.
Para servicios críticos, sí quiero checks claros: DNS, proxy principal, acceso remoto, Home Assistant si lo uso de verdad, gestor de contraseñas, fotos, documentos, backups, panel del NAS o almacenamiento principal. Para servicios personales de bajo impacto, quizá los monitorizo pero sin alerta inmediata. Para laboratorio, muchas veces ni eso.
También ajusto tiempos. Un servicio que falla una vez durante veinte segundos no necesita despertarme. Puede ser un reinicio, una actualización, un corte pequeño, una carga puntual. Prefiero detectar problemas persistentes. Por ejemplo, aviso tras varios fallos seguidos y recuperación confirmada después. La sensibilidad extrema parece profesional, pero en casa suele ser una fábrica de falsos positivos.
Otra cosa importante: los mensajes tienen que decir qué hacer. “Servicio caído” ayuda poco. “DNS principal caído, fallback activo, revisar contenedor dns-1” ayuda más. No siempre se puede meter todo en la alerta, pero al menos el nombre del servicio debería ser humano y la prioridad evidente.
Si llamas a un monitor container-17-prod-http, dentro de cuatro meses no sabrás si debes levantarte o encogerte de hombros.
Telegram: canal de acción, no vertedero#
Telegram es buen canal porque llega rápido y lo ves. Precisamente por eso hay que protegerlo.
Yo no mandaría todo a Telegram. Solo lo que requiere atención o lo que conviene ver en el momento. Lo demás puede ir a un log, a Uptime Kuma, a un resumen diario o a ninguna parte.
Un patrón que funciona bien es tener dos tipos de mensajes.
Los avisos inmediatos son cortos y accionables. Algo como:
- DNS principal caído durante 3 minutos. Fallback activo. Revisar cuando puedas.
- Backup de documentos falló 2 noches seguidas. Último bueno: lunes 02:14.
- Disco de datos al 91%. Quedan 820 GB. Tendencia: subiendo rápido.
Los resúmenes son tranquilos. Una vez al día o cada pocos días, con estado general: backups OK, certificados OK, servicios críticos OK, cambios raros ninguno. Si todo está bien, incluso puede no mandar nada.
La frase clave es “si todo está bien, no me hables”. Los sistemas que celebran cada éxito acaban pareciendo inseguros. No necesito que un cron me diga cada noche que ha hecho su trabajo. Necesito que me avise cuando no lo hace, o cuando lleva demasiado sin demostrar que lo hace.
Cron: el clásico que miente con cara seria#
Cron es maravilloso. También es una fuente tremenda de confianza falsa.
Un cron ejecutado no significa una tarea correcta. Significa que el reloj llamó al script. El script puede haber copiado cero archivos, haber escrito en un destino equivocado, haber fallado a medias o haber terminado con código cero por un error mal manejado.
Por eso no monitorizo cron por existencia. Monitorizo resultado.
Para backups, quiero saber la edad del último backup bueno, no la edad del último intento. Para sincronizaciones, quiero recuento o tamaño razonable. Para certificados, fecha real de caducidad. Para importaciones de datos, número de registros nuevos o al menos una señal de que no se quedó vacío. Para healthchecks, salida breve y código de estado fiable.
Una técnica sencilla es que cada tarea importante escriba un pequeño estado en JSON o texto: última ejecución, último éxito, duración, tamaño, contador, mensaje corto. Luego otro check lee ese estado y decide si alerta. Separar ejecución y alerta evita que cada script mande mensajes por su cuenta como si estuviera desesperado por atención.
También me gusta poner ventanas. Si un backup nocturno falla una vez, quizá espero al segundo fallo antes de avisar. Si falla dos noches, ya quiero saberlo. Si falla una copia de fotos familiares, quizá aviso antes. El umbral depende del valor del dato, no de lo bonito que quede el script.
Certificados, discos y backups: las alertas que sí quiero#
Hay tres familias de alertas que me parecen casi obligatorias.
La primera son certificados. No necesito saber cada renovación correcta. Necesito saber si algo caduca pronto y no se ha renovado. El aviso bueno llega con margen, por ejemplo 14 días y luego 7 días. El aviso malo llega cuando el servicio ya está roto.
La segunda son discos. Aquí hay que evitar el drama barato. Un disco al 70% no es noticia. Un disco al 92% y creciendo 5% al día sí lo es. Un pool degradado sí lo es. Errores SMART preocupantes también. Temperaturas puntualmente altas pueden ser ruido, pero temperaturas sostenidas en verano merecen atención.
La tercera son backups. No solo si terminó la tarea. Quiero edad del último backup bueno, tamaño sospechoso, espacio en destino y alguna prueba periódica de restauración. Un backup que falla en silencio es peor que no tener backup, porque te da confianza prestada.
Estas alertas tienen una característica común: si llegan, sé qué hacer. Renovar, limpiar, cambiar disco, revisar tarea, ampliar destino, restaurar prueba. No son avisos filosóficos.
Lo que prefiero dejar fuera#
No alertaría por CPU alta salvo casos muy concretos. En un homelab, una CPU puede subir por transcodificación, backups, indexado, actualizaciones, compresión, IA local o cualquier cosa normal. Si el servicio responde y la temperatura está bien, no quiero enterarme.
Tampoco alertaría por memoria usada sin entender Linux. Ver RAM llena por caché no es un problema. Es Linux haciendo Linux. Si hay OOM kills, eso sí cambia la conversación.
Los contenedores de laboratorio no merecen alertas. Si algo vive en laboratorio, puede estar apagado. Si de repente importa, entonces ya no es laboratorio y debería moverse de categoría.
Los pings externos también los trato con cuidado. Un ping perdido no significa caída. Puede ser red, proveedor, ICMP filtrado o una ráfaga tonta. Prefiero checks HTTP, DNS o TCP que prueben lo que realmente uso.
Y no quiero alertas de éxito constantes. “Backup completado correctamente” suena tranquilizador, pero si lo recibes todos los días acabas ignorándolo. Mejor resumen semanal o silencio salvo fallo.
Diseñar mensajes que no den pereza#
Una buena alerta tiene cinco datos, no una novela.
Qué pasa. Desde cuándo. A quién afecta. Qué ha hecho el sistema. Qué haría yo después.
Ejemplo malo:
ERROR backup failed
Ejemplo decente:
Backup documentos falló 2 veces. Último bueno: 2026-07-01 02:10. Destino accesible. Revisar logs de restic.
No hace falta que el mensaje resuelva todo. Pero tiene que ahorrarme el primer minuto de confusión. Si estoy en el móvil, necesito decidir si puedo esperar o si debo abrir el portátil.
También uso nombres humanos. fotos, dns-principal, backup-documentos, home-assistant, proxy-publico. Los nombres internos raros pueden vivir en la documentación, no en la alerta principal.
Horarios y convivencia#
No todas las horas valen igual.
Si algo no es urgente, no debería sonar por la noche. Puede esperar a la mañana. Los backups fallidos, certificados con margen o un servicio personal caído pueden entrar en resumen. El DNS de casa caído quizá sí merece aviso. Un contenedor de recetas caído a las tres de la mañana, no.
Esto parece obvio hasta que conectas todas las notificaciones al mismo canal sin distinguir prioridad. Entonces una actualización de madrugada tiene el mismo volumen que un fallo real.
Me gusta pensar en las alertas como interrupciones que tienen que ganarse el derecho a existir. Si no merece interrumpir una cena, una reunión o una noche, no va al canal inmediato.
Paneles para mirar, alertas para actuar#
Un panel y una alerta no son lo mismo.
Un panel sirve para mirar estado cuando tienes contexto. Uptime Kuma, Grafana, Beszel, Netdata o el dashboard que uses. Ahí pueden vivir métricas, históricos, servicios menos críticos y detalles. Una alerta sirve para sacarte de lo que estás haciendo.
Me costó separarlo. Durante un tiempo quería que todo lo visible también avisara. Ahora prefiero paneles ricos y alertas pobres. Ricas en intención, pobres en cantidad.
El panel puede decirme que el servidor lleva 42 días vivo, que el NAS está al 68%, que hay cinco contenedores con updates y que una VM de laboratorio está apagada. La alerta solo me dice lo que rompe una expectativa importante.
Mi configuración ideal en casa#
Si empezara de cero, montaría algo así.
Uptime Kuma para servicios críticos y algunos importantes, con notificaciones solo en los críticos. Checks con varios fallos antes de alertar. Nombres humanos. Sin meter cada contenedor.
Scripts de cron importantes escribiendo estado local. Un verificador separado revisando edad, último éxito, tamaño y condiciones raras. Telegram solo si el fallo supera umbral.
Alertas de certificados con margen. Alertas de disco basadas en porcentaje, tendencia y salud, no solo en un número suelto. Alertas de backups centradas en último backup bueno y restauración de prueba.
Resumen diario o semanal solo si aporta algo. Si todo está verde y no hay cambios, silencio. El silencio también es una feature.
Y documentación mínima: dónde mirar logs, cómo parar avisos si estoy haciendo mantenimiento, cómo desactivar una alerta rota y qué servicios son críticos de verdad.
Mi conclusión#
Las alertas buenas no son las que te cuentan todo. Son las que consiguen que actúes antes de que un problema pequeño se convierta en una tarde perdida.
En un homelab, el enemigo no es la falta de herramientas. Tenemos de sobra. El enemigo es el ruido. Uptime Kuma, Telegram y cron pueden formar un sistema muy útil, pero solo si cada aviso tiene propósito.
Prefiero cinco alertas bien pensadas a cincuenta checks gritando. Prefiero un mensaje que me diga “el backup importante lleva dos días sin éxito” a veinte mensajes de tareas correctas. Prefiero no enterarme de un contenedor de laboratorio caído y sí enterarme de que el DNS de casa está usando fallback.
Monitorizar bien en casa no va de parecer profesional. Va de seguir confiando en tus avisos cuando de verdad hacen falta.