El primer sistema de alertas de un homelab suele ser una verbena. Todo avisa. El servidor avisa. Uptime Kuma avisa. Los cron avisan. El NAS avisa. El router avisa. Los backups avisan. Docker avisa. El certificado avisa. Un contenedor se reinicia y parece que se ha caído producción de una empresa de seguros.
Al principio incluso hace ilusión. Te llega un mensaje y piensas que tu infraestructura está viva, vigilada, seria. Luego pasan dos semanas y descubres la verdad: si todo avisa, nada avisa.
En casa esto es peor que en un laboratorio aislado. Un homelab familiar tiene servicios que afectan a otras personas. DNS, fotos, documentos, contraseñas, domótica, acceso remoto, backups. Pero también tiene pruebas, dashboards, automatizaciones de juguete y servicios que solo existen porque una noche te pareció buena idea mirar una alternativa nueva.
Tratar todo igual es una receta perfecta para silenciarlo todo.
Mi enfoque ahora es separar alertas por prioridad y por momento. Algunas cosas merecen interrumpirme. Otras deben ir a un resumen diario. Muchas no deberían mandar nada hasta repetirse o acumularse. Y unas cuantas deberían desaparecer porque solo generan ansiedad técnica.
La pregunta incómoda: ¿quién sufre si esto falla?#
Antes de crear alertas, clasifico servicios con una pregunta muy simple: ¿quién sufre si esto falla?
Si solo sufro yo y además puedo arreglarlo mañana, no merece una alerta inmediata. Si afecta a la casa, cambia la cosa. Si implica pérdida de datos, cambia mucho más. Si impide recuperar otros servicios, sube de prioridad aunque nadie lo vea directamente.
Para mí hay cuatro niveles bastante prácticos:
- emergencia doméstica
- problema importante
- aviso operativo
- ruido o telemetría
Una emergencia doméstica es algo que rompe una función real de la casa: DNS caído sin fallback, gestor de contraseñas inaccesible, Home Assistant roto si controla cosas importantes, NAS con datos familiares inaccesible, backup crítico fallando varios días, disco con señales serias.
Un problema importante puede esperar un rato, pero quiero saberlo pronto: certificado que caduca en pocos días, backup de un servicio medio fallando, nodo de laboratorio apagado cuando debería estar encendido, espacio en disco creciendo demasiado.
Un aviso operativo va al resumen diario: contenedores actualizables, servicios no críticos reiniciados, tareas programadas lentas, snapshots antiguos, VMs apagadas que llevan tiempo sin usarse.
El ruido es lo que no debería notificar. CPU alta puntual, memoria algo elevada, un ping perdido, una actualización disponible sin urgencia, un contenedor de laboratorio que cae mientras estoy probando cosas. Eso puede estar en un panel, pero no en mi bolsillo.
El móvil no es un dashboard#
Este punto me costó. Telegram, ntfy, Matrix, email o lo que uses para avisos no son dashboards. Son interrupciones. Cada mensaje compite con vida real, trabajo, familia y descanso. Si el sistema te manda diez avisos menores al día, estás entrenándote para ignorarlo.
Yo quiero que una alerta inmediata sea rara. Si vibra el móvil por el homelab, debería haber una razón buena. No “un contenedor tardó en responder una vez”. No “hay una actualización”. No “la CPU está al 85 por ciento durante dos minutos”. Eso es telemetría con complejo de urgencia.
La monitorización buena no es la que grita primero. Es la que acierta cuándo gritar.
Por eso prefiero dos canales:
- canal urgente para interrupciones reales
- resumen diario para mantenimiento
El canal urgente tiene poco volumen. Idealmente, algunos días cero mensajes. El resumen diario puede ser más rico: cambios, backups, certificados, servicios caídos no críticos, actualizaciones, discos, consumo, tareas raras. Lo leo cuando toca, no cuando el sistema decide secuestrarme la atención.
Qué sí me despertaría#
No uso la palabra despertar de forma literal para todo. No quiero que un homelab me saque de la cama salvo que haya una razón muy seria. Pero sí hay alertas que aceptaría como inmediatas, incluso fuera de horario laboral.
La primera es pérdida de datos probable. Discos con errores graves, pool degradado, volumen crítico inaccesible, backup que falla repetidamente en datos familiares, corrupción detectada o snapshot que no se puede crear en un servicio sensible. Esto no siempre exige levantarse corriendo, pero sí merece visibilidad alta.
La segunda es caída de servicios base sin alternativa. DNS interno sin respaldo, acceso a internet roto por una pieza propia, reverse proxy interno caído si bloquea servicios familiares, VPN caída si estoy fuera y la necesito para entrar a algo importante.
La tercera es seguridad. Login raro, demasiados intentos fallidos en un servicio expuesto, certificado inesperado, cambio de IP pública si depende de reglas, servicio que se expone fuera cuando debería ser interno. Aquí prefiero pocos avisos, pero buenos.
La cuarta es domótica que afecta a convivencia. Si Home Assistant solo mide temperatura, puede esperar. Si controla luces, calefacción, enchufes o rutinas que usa la familia, su caída tiene otro peso. La tecnología en casa deja de ser graciosa cuando otra persona paga la incomodidad.
Qué va al resumen diario#
El resumen diario es donde el homelab puede ser pesado sin molestar. Ahí caben cosas que quiero saber, pero que no necesitan invadir el día.
Metería:
- backups completados y fallidos
- servicios no críticos caídos
- contenedores con actualizaciones
- certificados que caducan en menos de treinta días
- uso de disco por encima de umbrales suaves
- VMs apagadas mucho tiempo
- cambios de inventario
- tareas cron que fallaron
- snapshots antiguos
- servicios nuevos sin clasificar
La diferencia está en el tiempo de reacción. Si un certificado caduca en veinticinco días, no quiero una alerta urgente. Quiero verlo en el resumen y arreglarlo en una ventana normal. Si caduca mañana y protege un servicio importante, sube de nivel.
Con backups igual. Un fallo aislado puede ir al resumen. Tres fallos seguidos en un servicio crítico ya no. La prioridad no depende solo del evento, depende del contexto y de la repetición.
Esto evita una barbaridad de ruido. Un sistema que escala alertas por repetición se parece más a cómo piensa una persona. Una cosa rara puede ser casualidad. Tres días seguidos ya es patrón.
La matriz sencilla que uso#
Para decidir el canal, uso una matriz mental con dos ejes: impacto y urgencia.
Impacto:
- bajo: solo laboratorio
- medio: me afecta a mí
- alto: afecta a casa o datos importantes
Urgencia:
- puede esperar al mes
- puede esperar al día
- requiere atención hoy
- requiere atención ahora
Si el impacto es bajo, casi nunca mando alerta inmediata. Si el impacto es alto y la urgencia es alta, sí. Lo interesante está en medio.
Un contenedor de pruebas caído tiene impacto bajo y urgencia baja. Resumen o nada.
Un backup de fotos fallido una vez tiene impacto alto, pero urgencia moderada. Resumen destacado.
Un backup de fotos fallido tres días tiene impacto alto y urgencia alta. Alerta.
Un certificado interno que caduca en veinte días tiene impacto medio o alto, urgencia baja. Resumen.
Un DNS caído sin fallback tiene impacto alto y urgencia alta. Alerta.
Esta matriz no necesita software complejo. Puedes implementarla con etiquetas, scripts y un poco de disciplina. Lo difícil no es programarlo. Lo difícil es aceptar que muchas cosas que nos apetece medir no merecen molestar.
Horarios: no todo pesa igual a las dos de la mañana#
El horario importa. Una alerta a las once de la mañana y una alerta a las dos de la mañana no cuestan lo mismo.
Yo tendría ventanas:
- horario normal
- tarde o noche
- madrugada
- vacaciones
En horario normal puedo recibir más avisos. Por la noche, solo lo importante. En madrugada, casi nada. En vacaciones, solo lo que afecte a acceso remoto, datos o servicios familiares.
Esto se puede hacer de forma simple. No hace falta montar una central de guardias. Basta con que el sistema sepa cuándo degradar avisos al resumen o cuándo agruparlos.
Por ejemplo, si un servicio de laboratorio cae a las dos de la mañana, que se quede callado. Si sigue caído al día siguiente, aparece en el resumen. Si es DNS o almacenamiento crítico, avisa. Si el backup no crítico falla en vacaciones, resumen. Si el backup de documentos familiares falla varios días, alerta.
Este filtro horario es una de las mejoras más sanas que puedes hacer. El homelab tiene que servir a la casa, no convertirla en una guardia permanente.
Agrupar antes de molestar#
Muchas alertas vienen en racimo. Reinicias un host y caen diez servicios a la vez. Actualizas un proxy y todo marca down durante treinta segundos. El NAS tarda en montar un volumen y varios contenedores protestan. Si el sistema manda un mensaje por cada evento, acabas con una novela mala.
Prefiero agrupar.
Si un host cae, quiero una alerta de host, no doce alertas de servicios hijos. Si DNS cae, probablemente muchas comprobaciones fallarán. El mensaje útil es “DNS no responde”, no “Paperless, Vaultwarden, Home Assistant y dashboard no resuelven”.
Esto requiere dependencias mínimas. No hace falta un grafo perfecto, pero sí saber qué servicios viven en qué host y qué piezas son base. Uptime Kuma permite algo de esto con grupos y mantenimiento. Scripts propios pueden hacerlo mejor si tienes inventario.
También usaría retardo antes de alertar. Un fallo de treinta segundos no siempre importa. Para servicios web internos, dos o tres comprobaciones fallidas reducen falsos positivos. Para DNS crítico, quizá menos. Cada cosa con su paciencia.
La alerta buena no solo dice que algo falló. Dice qué probablemente lo causó.
Mensajes accionables#
Una alerta que solo dice “servicio caído” es medio útil. Cuando estás fresco, vale. Cuando estás cansado, necesitas más.
Me gustan los mensajes cortos pero accionables:
| |
No pondría comandos largos en Telegram. Eso se vuelve ilegible. Pondría una pista y un enlace interno a un runbook o nota operativa. Si no hay runbook, al menos una frase que recuerde el primer paso.
Para el resumen diario, usaría algo así:
| |
Esto sí se puede leer con café. Y no te obliga a entrar en cinco paneles solo para saber si hay algo que hacer.
Canales separados#
No mezclaría todo en el mismo canal. Como mínimo tendría:
- urgencias
- resumen diario
- mantenimiento ruidoso
El canal de urgencias puede ir a Telegram, ntfy o el canal que mires siempre. El resumen diario puede ir al mismo sitio, pero con horario fijo y formato reconocible. El mantenimiento ruidoso puede vivir en logs, email secundario o una página interna.
Si usas Telegram, puedes incluso separar chats o hilos. Si usas ntfy, separar topics. Si usas email, etiquetas. Lo importante es que tu cerebro aprenda la diferencia.
Un aviso urgente no debería parecerse a un “hay tres contenedores con update”. Si visualmente todo entra igual, emocionalmente todo pesa igual. Y eso acaba en silencio.
Qué quitaría sin pena#
Quitar alertas cuesta porque parece que pierdes control. En realidad recuperas atención.
Yo quitaría:
- CPU alta puntual
- RAM alta sin swap ni fallo real
- ping perdido una vez
- actualizaciones disponibles de servicios no críticos
- reinicios esperados durante ventanas de mantenimiento
- servicios de laboratorio fuera de horario
- avisos duplicados desde varias herramientas
También revisaría cada mes qué alertas no he usado. Si una notificación aparece siempre y nunca actúo, o está mal calibrada o no importa. Las dos opciones piden cambio.
Una métrica útil para esto es muy simple: ¿cuántas alertas urgentes recibí esta semana y cuántas exigían acción real? Si la respuesta da vergüenza, el sistema está mintiendo.
Mi diseño base#
Si montara esto desde cero en un homelab familiar, haría algo así:
Uptime Kuma para comprobaciones externas y de servicios visibles. Scripts pequeños para backups, certificados, inventario y pruebas funcionales. Un fichero de clasificación por servicio con criticidad, propietario, dependencia y política de alertas. Un canal urgente muy restrictivo. Un resumen diario a una hora fija. Un resumen mensual para limpieza, restores y deuda técnica.
No empezaría por Grafana. Grafana puede venir después para mirar tendencias. Primero quiero decisiones. ¿Tengo algo roto? ¿Tengo datos en riesgo? ¿Hay algo que deba hacer hoy? ¿Qué puedo ignorar?
La parte más importante sería la clasificación. Sin ella, cualquier herramienta se vuelve ruidosa. Con ella, hasta un script sencillo puede ser bastante fino.
La regla que me quedo#
Una alerta inmediata tiene que merecer la interrupción.
Parece obvio, pero casi ningún homelab empieza así. Empezamos al revés: todo avisa y luego vamos silenciando por agotamiento. Prefiero diseñarlo desde el principio para que el móvil sea una señal, no un panel de control con ansiedad.
El resumen diario es donde meto el resto. Me permite mantener el sistema cuidado sin convertir cada rareza en un incendio. Y si algo se repite, sube de nivel.
Esa es la parte útil: no ignorar, pero tampoco vivir de guardia.
En una casa, la mejor alerta no es la más rápida. Es la que llega cuando todavía puedes hacer algo y antes de que alguien pregunte por qué internet, las fotos o las luces han dejado de funcionar.