Uptime Kuma no envía notificaciones: causas y soluciones

Cuando Uptime Kuma no envía notificaciones, el problema no siempre está en Telegram, el servidor de correo o el webhook. También puede ocurrir que el canal no esté asociado al monitor, que todavía no se haya producido un cambio real de estado o que los reintentos estén retrasando la alerta.

La mejor forma de resolverlo es comprobar cada parte de la cadena por separado: primero el canal, después su asociación con el monitor y, finalmente, la conectividad desde el servidor o contenedor donde se ejecuta Uptime Kuma. Si todavía estás preparando los monitores, puedes consultar esta guía general de Uptime Kuma.

Empieza por identificar dónde falla la notificación

Antes de modificar contraseñas, puertos o certificados, comprueba exactamente qué está sucediendo. Estos son los escenarios más habituales:

Síntoma	Causa probable	Primera comprobación
La prueba manual falla	Credenciales, dirección, red o TLS	Revisar la configuración del proveedor
La prueba funciona, pero no llega la alerta real	Canal no asociado o monitor sin cambio de estado	Editar el monitor y revisar sus notificaciones
Solo falla un monitor	Configuración individual incorrecta	Compararlo con otro monitor que sí avise
La alerta tarda demasiado	Reintentos o intervalo excesivo	Revisar los ajustes del monitor
Uptime Kuma indica éxito, pero no ves el mensaje	Spam, destinatario incorrecto o aplicación silenciada	Revisar el servicio receptor

Esta clasificación evita cambiar varias opciones a la vez y facilita localizar el fallo sin estropear una configuración que ya funciona parcialmente.

Cómo probar el canal de notificación

Abre Settings > Notifications, selecciona el canal problemático y pulsa el botón Test. Uptime Kuma intentará enviar un mensaje utilizando la configuración introducida.

Si la prueba falla, el mensaje mostrado suele ofrecer una pista:

• Unauthorized o 401: el token, usuario o contraseña no es válido.
• Forbidden o 403: la credencial existe, pero no dispone de permisos.
• Not Found o 404: la dirección del webhook o recurso es incorrecta.
• Too Many Requests o 429: el proveedor ha aplicado un límite temporal.
• ENOTFOUND: el servidor no puede resolver el dominio mediante DNS.
• ETIMEDOUT: la conexión está siendo bloqueada o no obtiene respuesta.
• Error de certificado: el certificado no es válido, está caducado o no coincide con el dominio.

Una prueba correcta confirma que Uptime Kuma puede contactar con el proveedor en ese momento. Sin embargo, no demuestra que la notificación esté habilitada en el monitor ni que se haya generado un evento `DOWN` o `UP` real.

Comprueba que la notificación esté vinculada al monitor

Este es uno de los errores más frecuentes. El canal puede estar perfectamente configurado y superar la prueba, pero no hacer nada porque ningún monitor lo utiliza.

1. Abre el monitor que no está enviando avisos.
2. Pulsa Edit.
3. Busca el apartado Notifications.
4. Activa el canal que quieres utilizar.
5. Guarda los cambios.

La opción Default enabled permite que una notificación quede seleccionada de forma predeterminada al crear monitores nuevos. Por su parte, Apply on all existing monitors sirve para aplicarla a los monitores que ya existen.

Aun utilizando estas opciones, conviene abrir uno de los monitores afectados y comprobar manualmente que el canal aparece seleccionado. Esto es especialmente importante cuando existen varias notificaciones con nombres parecidos.

Comprueba que exista un cambio real de estado

Uptime Kuma envía las alertas principales cuando el monitor cambia de estado. Si permanece continuamente en `UP` o `DOWN`, puede no producirse un nuevo aviso salvo que tengas configurados recordatorios o reenvíos.

También debes revisar el número de reintentos antes de marcar el servicio como caído. Si el monitor comprueba el servicio cada 60 segundos y tiene tres reintentos, la alerta no llegará con el primer fallo. Uptime Kuma esperará a que se cumplan las condiciones necesarias para cambiar el estado a `DOWN`.

Para comprobar el flujo completo sin interrumpir un servicio real, puedes crear un monitor temporal que apunte a un puerto cerrado. Espera a que cambie a `DOWN`, confirma la recepción del aviso y modifica después el monitor para utilizar un servicio accesible. Deberías recibir también la recuperación `UP`.

Si necesitas vigilar contenido y no solamente un código HTTP, puedes monitorizar una página web con Uptime Kuma utilizando una comprobación adecuada.

Uptime Kuma no envía correos por SMTP

Cuando falla el correo electrónico, revisa primero la combinación entre puerto y cifrado. Una configuración incorrecta puede impedir la conexión aunque el usuario y la contraseña sean válidos.

Puerto	Configuración habitual
465	TLS implícito desde el comienzo de la conexión
587	Conexión inicial seguida de STARTTLS
25	Depende del servidor; puede estar bloqueado por el proveedor

Comprueba también los siguientes elementos:

• El nombre del servidor SMTP debe coincidir exactamente con el proporcionado por el servicio.
• El usuario suele ser la dirección de correo completa, aunque depende del proveedor.
• Las cuentas protegidas con MFA pueden necesitar una contraseña de aplicación.
• La dirección del remitente debe estar autorizada por el servidor.
• El destinatario debe estar escrito correctamente.
• Los encabezados adicionales deben contener JSON válido si decides utilizarlos.
• El certificado debe ser válido y coincidir con el dominio configurado.

No conviene activar permanentemente una opción para ignorar los errores TLS. Puede servir como prueba puntual para identificar un certificado interno mal configurado, pero reduce la seguridad y no soluciona la causa del problema.

Si Uptime Kuma indica que el mensaje se ha enviado, revisa la carpeta de spam, las reglas del buzón y los registros del servidor de correo. Algunos servicios aceptan el mensaje inicialmente y después lo bloquean porque el remitente no supera sus políticas.

Uptime Kuma no envía mensajes por Telegram

Para configurar correctamente las alertas de Uptime Kuma por Telegram necesitas un token válido del bot y el identificador exacto del chat.

• Comprueba que el token no contenga espacios ni caracteres adicionales.
• Inicia una conversación con el bot y envíale un mensaje antes de probarlo.
• Si utilizas un grupo, añade el bot y concédele permiso para publicar.
• Recuerda que los identificadores de grupos suelen incluir un valor negativo.
• Si el grupo utiliza temas, configura el Message Thread ID correspondiente.
• Revisa si la opción de mensaje silencioso está activada.

También puede ocurrir que Telegram esté silenciado en el móvil. En ese caso, el mensaje llega correctamente, pero el dispositivo no muestra una alerta sonora o emergente.

Si quieres separar las notificaciones críticas de los avisos ordinarios, otra posibilidad es configurar ntfy como canal adicional y disponer de una ruta de respaldo.

Los webhooks de Discord, Slack u otros servicios fallan

Un webhook debe apuntar al endpoint de recepción proporcionado por el servicio. No funcionará si introduces la dirección normal de un canal, una página de configuración o una URL copiada desde el navegador.

Si el envío falla, comprueba:

• Que el webhook no haya sido eliminado, revocado o regenerado.
• Que la URL esté completa y no tenga espacios.
• Que el servidor acepte peticiones desde la dirección de Uptime Kuma.
• Que los encabezados de autenticación sean correctos.
• Que el cuerpo enviado tenga el formato JSON esperado.
• Que no exista un límite de peticiones temporal.

Cuando el webhook participe en una automatización, prueba primero el endpoint con una carga sencilla. Después podrás utilizarlo para acciones más avanzadas, como reiniciar automáticamente un contenedor Docker tras una caída confirmada.

Comprueba la red desde el contenedor de Uptime Kuma

Que Telegram, Gmail o un webhook funcionen desde tu ordenador no significa que sean accesibles desde el contenedor. Es Uptime Kuma quien debe resolver el dominio y establecer la conexión saliente.

Localiza primero el nombre del contenedor:

docker ps

Si se llama uptime-kuma, puedes comprobar la resolución DNS mediante:

docker exec uptime-kuma node -e "require('dns').lookup('api.telegram.org', console.log)"

Para probar una conexión HTTPS desde el mismo contenedor:

docker exec uptime-kuma node -e "fetch('https://api.telegram.org').then(r => console.log(r.status)).catch(console.error)"

Sustituye el dominio por el servidor SMTP, webhook o API que estés diagnosticando. Los errores más comunes indican lo siguiente:

• ENOTFOUND: configuración DNS incorrecta.
• EHOSTUNREACH: no existe una ruta hacia el destino.
• ETIMEDOUT: un cortafuegos, proxy o servicio remoto bloquea la conexión.
• ECONNREFUSED: el puerto está cerrado o el servicio no escucha.
• Certificate has expired: el certificado del servidor ha caducado.

En redes corporativas también puede ser necesario configurar un proxy de salida para Docker o instalar la autoridad certificadora interna en el entorno que ejecuta Uptime Kuma.

Revisa el proxy, el DNS, los certificados y la hora

Una hora del sistema incorrecta puede invalidar certificados o tokens temporales. Comprueba que el host mantenga su reloj sincronizado mediante NTP y que el contenedor herede una configuración horaria coherente.

Si utilizas un proxy corporativo, verifica que permita conexiones hacia los dominios y puertos empleados por las notificaciones. Algunos proxies aceptan tráfico web normal, pero bloquean conexiones SMTP o webhooks hacia destinos no autorizados.

En instalaciones con certificados internos, Uptime Kuma debe confiar en la autoridad que los ha emitido. Desactivar la comprobación de certificados indiscriminadamente solamente oculta el problema y puede facilitar ataques de intermediario.

Los reintentos, las pausas y el mantenimiento pueden ocultar alertas

Un monitor pausado no realiza comprobaciones, por lo que tampoco puede generar un cambio de estado. Revisa que aparezca como activo antes de seguir investigando.

Las ventanas de mantenimiento están diseñadas para evitar avisos durante interrupciones planificadas. Comprueba que el monitor no esté incluido en un mantenimiento activo o programado con una zona horaria incorrecta.

Los reintentos también pueden hacer que parezca que la notificación ha fallado. En realidad, Uptime Kuma todavía está esperando nuevas comprobaciones antes de declarar la caída. Ajusta este valor buscando un equilibrio entre rapidez y protección frente a falsos positivos.

Cómo revisar los registros de Uptime Kuma

Cuando la interfaz no explica suficientemente el error, consulta los registros del contenedor:

docker logs --tail 200 uptime-kuma

Para observar nuevos mensajes mientras realizas una prueba:

docker logs --follow --tail 200 uptime-kuma

Si utilizas Docker Compose y el servicio se llama uptime-kuma, también puedes ejecutar:

docker compose logs --tail=200 uptime-kuma

Busca referencias al nombre del proveedor, códigos HTTP, errores de autenticación, problemas DNS, tiempos de espera o certificados rechazados. No publiques registros completos sin revisarlos: pueden contener direcciones internas, destinatarios o partes de las credenciales.

Errores frecuentes al configurar las notificaciones

La prueba funciona, pero la caída no genera ningún aviso

El canal probablemente no está activado en ese monitor o todavía no se han agotado los reintentos. Edita el monitor, revisa las notificaciones seleccionadas y espera a que se produzca un cambio real a `DOWN`.

Recibes el aviso de recuperación, pero no el de caída

Revisa los eventos habilitados, los filtros del servicio receptor y los registros correspondientes al momento exacto de la caída. El primer mensaje también podría haber sido filtrado como spam o bloqueado temporalmente.

Solamente falla un monitor

Compara su configuración con la de otro que sí funcione. Revisa el canal asociado, los reintentos, las ventanas de mantenimiento y si el monitor está pausado.

Las notificaciones dejaron de funcionar después de una actualización

Vuelve a ejecutar la prueba, consulta los registros y revisa que las credenciales, variables y certificados continúen disponibles dentro del contenedor. Comprueba también las notas de la versión antes de cambiar la configuración.

Los correos se envían, pero llegan sin el asunto esperado

Utiliza preferentemente el proveedor SMTP nativo y revisa la plantilla del asunto. Si has añadido encabezados personalizados, asegúrate de que formen un objeto JSON válido y no sobrescriban campos esenciales.

Orden recomendado para solucionar el problema

1. Pulsa Test en la configuración del canal.
2. Corrige las credenciales, el endpoint o el cifrado si la prueba falla.
3. Comprueba que el canal esté activado en el monitor afectado.
4. Revisa reintentos, pausas y mantenimientos programados.
5. Provoca una caída controlada para verificar los eventos `DOWN` y `UP`.
6. Comprueba DNS y conectividad desde el contenedor.
7. Consulta los registros durante una nueva prueba.
8. Configura un segundo canal para disponer de alertas redundantes.

Cuando Uptime Kuma no envía notificaciones, la solución consiste en localizar si el fallo está en el proveedor, la asociación con el monitor, la generación del evento o la red del contenedor. Una prueba manual correcta es solamente el primer paso: también debes confirmar que el monitor cambia de estado y que el servicio receptor acepta y muestra el mensaje.

Una vez recuperadas las alertas, conviene mantener al menos dos canales independientes, por ejemplo Telegram y correo electrónico. Así, un problema puntual con un proveedor no te dejará completamente a ciegas ante la caída de un servicio.