Configura las comprobaciones de estado por capas: verifica primero la respuesta de la aplicación Home Assistant y, después, prueba la base de datos, MQTT, DNS, el almacenamiento y la ruta remota solo cuando cada dependencia realmente importe.
Un contenedor marcado como activo puede seguir iniciándose, estar bloqueado por el almacenamiento, desconectado de su bróker o sin poder escribir el historial. Comienza con una comprobación local de disponibilidad económica, añade comprobaciones independientes de las dependencias con nombres claros, concede suficiente margen de inicio y envía alertas antes de activar la automatización de recuperación. Cada sonda debe indicar qué falló y qué demuestra un resultado satisfactorio.
Define el comportamiento saludable antes de escribir una sonda
Enumera las funciones que deben funcionar en tu hogar: la interfaz local responde, las automatizaciones se ejecutan, Recorder puede escribir, los dispositivos MQTT intercambian estados, el DNS resuelve los nombres necesarios y el almacenamiento montado permite escribir. Un único estado en verde no puede demostrar todas esas funciones.
Una guía práctica sobre las comprobaciones de estado de Docker distingue el estado de la aplicación de la simple existencia del proceso y explica que una sonda se ejecuta dentro del contenedor e informa de éxito o fracaso. Aplica esa distinción a nivel de aplicación al definir qué debe observar tu comprobación de Home Assistant.
Asigna un responsable y un significado de fallo a cada sonda. La comprobación de Core no debe fingir que valida la base de datos, y una comprobación del socket MQTT no debe afirmar que los mensajes de los dispositivos están actualizados. Si un resultado no puede conducir a una acción concreta, simplifica o elimina esa sonda.
Añade una comprobación ligera de disponibilidad de Home Assistant
Utiliza un punto de conexión local o un comando que se complete rápidamente y demuestre que la aplicación responde, no solo que existe el proceso de Python. Establece un tiempo de espera inferior al intervalo, un número razonable de reintentos y un periodo de gracia inicial lo bastante largo para el arranque en frío medido.
Las comprobaciones de estado de Compose suelen exponer controles de intervalo, tiempo de espera, reintentos y periodo inicial, mientras que las condiciones de dependencia pueden retrasar un consumidor hasta que un prerrequisito alcance un estado saludable. El comportamiento operativo clave es la disponibilidad en lugar del estado activo, no un calendario de sondeos agresivo.
Inicia Home Assistant desde un almacenamiento en frío y registra cuándo la sonda tiene éxito por primera vez. Si falla durante todos los arranques normales, aumenta el margen en lugar de debilitar la prueba. Si tiene éxito antes de que la interfaz o el servicio necesario estén disponibles, la comprobación es demasiado superficial y necesita una respuesta más representativa.
Comprueba las dependencias por separado y conserva el significado de cada fallo
Crea comprobaciones independientes para la conexión con la base de datos, el bróker MQTT, la resolución DNS y el montaje de almacenamiento necesario. Prefiere una consulta de solo lectura o una pequeña escritura reversible en una ruta de prueba específica; nunca modifiques las tablas de Home Assistant ni publiques comandos a dispositivos reales solo para demostrar disponibilidad.
Mantén separadas las dependencias de descubrimiento y control local de las dependencias de acceso remoto. La descripción general de ZimaSpace sobre las dependencias de los componentes de Home Assistant ofrece un mapa útil para decidir qué fallo debe generar una alerta inmediata y cuál puede permanecer como una advertencia de degradación.
Etiqueta el resultado con la capa que falla. Si Home Assistant está saludable pero falla la comprobación de la base de datos, investiga el almacenamiento o las credenciales en lugar de reiniciar Core. Si solo falla el acceso remoto, mantén funcionando el control local. Esta separación evita que una dependencia en rojo borre las pruebas de los servicios saludables.
Prueba el fallo, la recuperación y el momento de las alertas
Durante una ventana de mantenimiento, detén una dependencia no crítica cada vez o bloquea temporalmente su ruta de prueba. Confirma que la sonda correspondiente falla, que las comprobaciones no relacionadas siguen en verde y que la alerta nombra la capa correcta. Restaura la dependencia y verifica que la misma comprobación se resuelve sin editar manualmente el estado.
Añade reinicios automáticos solo después de observar varios fallos reales. Usa periodos de enfriamiento y un número máximo de intentos, y nunca reinicies la base de datos y Home Assistant simultáneamente sin conservar los registros. Un reinicio es una puerta de verificación, no una prueba de que la dependencia subyacente se haya recuperado.
Un diseño satisfactorio detecta el fallo controlado dentro del intervalo previsto, conserva las funciones locales que no dependen de él y se resuelve después de la restauración. Revierte las sondas que generen una carga considerable o falsas alarmas; escala el incidente si el servicio sigue sin estar disponible mientras todas las comprobaciones de dependencias pasan, porque la prueba a nivel de aplicación necesita entonces evidencias más profundas.
Soporte y Consejos
Más para leer

Home Assistant funciona con Wi-Fi, pero falla con Ethernet o VPN
Prueba cada ruta de red por separado, verifica el estado de la interfaz y del enrutamiento, distingue entre IP directa y descubrimiento, y luego...

Cómo retirar Home Assistant sin dejar datos desprotegidos
Demuestra el reemplazo o archivado, revoca todas las rutas de confianza, sanea cada dispositivo que contenga datos y conserva únicamente copias de recuperación protegidas...

¿Deberías usar actualizaciones automáticas para Home Assistant en un servidor doméstico?
Elige actualizaciones manuales, solo de notificación o automáticas escalonadas según el impacto en el hogar, el riesgo de compatibilidad, el tiempo de observación y...

