Muchas cajas solo hablan email: un job de backup del NAS, un plan barato de uptime, una impresora, un SAI. No deberías montar un parser de correo — ni un curl en un disco sin HTTPS de salida — solo para enterarte de un backup fallido.
La ingesta por email ya convierte un mensaje en una alerta de AlertHub. Añade ntfy como destino y el mismo correo se vuelve notificación en el teléfono. Slack es opcional. El dispositivo nunca aprende una URL de topic.
Cómo es el salto
NAS / UptimeRobot / regla de bandeja
→ {key}@{level}.sendalert.thealerthub.com
→ AlertHub (guarda + panel)
→ ntfy (solo warning / critical)| Campo del email | Campo de la alerta |
|---|---|
| Asunto | ah_title |
| Cuerpo | ah_description |
{key}@warning.… o @critical.… | Nivel → prioridad ntfy 4 o 5 |
| Remitente | ah_source con prefijo Email: |
Las direcciones info (@info.) no salen a ntfy. Úsalas para informes diarios ruidosos.
Configuración (una vez)
-
Copia el secreto del proyecto y elige la dirección de la guía de ingesta por email:
{TU_CLAVE_SECRETA}@critical.sendalert.thealerthub.com -
Apunta el dispositivo o un reenvío de buzón a esa dirección. Warning para degradado, critical para caída / backup fallido.
-
Suscríbete a un topic de ntfy imposible de adivinar y pega
https://ntfy.sh/TU_TOPICen Connections → ntfy.
Docs: fuente email · destino ntfy.
Alerta 1: Backup del NAS fallido
La mayoría de NAS envían email si el job falla. Reenvía a @critical.… para prioridad ntfy 5. El asunto suele bastar como título; no hace falta el log entero en la notificación — el panel guarda el cuerpo.
Alerta 2: UptimeRobot (o cualquier monitor solo-email)
Si el monitor no puede hacer POST a un webhook, aún puede mandar correo. Usa @critical.… para caída. El correo de recuperación debe ir a @info.… o no enviarse: celebrar «up» tan alto como «down» te entrena a ignorar ntfy. Monitores con webhook: uptime → ntfy.
Alerta 3: Regla de bandeja en vez de un dispositivo
Regla de Gmail/Outlook: si el asunto contiene URGENT o viene de [email protected], reenvía a @warning.…. CRMs y tickets legacy que nunca tendrán webhook siguen llegando al teléfono.
No reenvíes toda la bandeja. ntfy no te lo perdonará.
Ideas para sacarle más partido
- Un topic, muchos remitentes.
ah_sourcequedaEmail: backup@nasvsEmail: uptime@…para filtrar el feed. - Canal de equipo después. Añade Slack en el mismo proyecto sin tocar el NAS — guardia híbrida.
- Push self-hosted. Misma dirección de ingesta, Gotify si ops Android ya tiene servidor.
- El asunto se ve en la pantalla de bloqueo. Deja el PII fuera del asunto; ponlo en el cuerpo si hace falta.
Preguntas frecuentes
¿El NAS tiene que llegar a ntfy.sh?
No. Solo envía correo a AlertHub. AlertHub llama a ntfy.
¿Y si el asunto está vacío?
La ingesta exige asunto. Ponlo en el dispositivo o en la regla de reenvío.
¿Un newsletter reenviado por error me paginará?
Solo si cae en @warning o @critical. Usa un reenvío dedicado, no «redirigir todo».
Siguientes pasos
Reenvía un mensaje de prueba a @warning.sendalert.thealerthub.com, pega un topic de ntfy y confirma el teléfono.
Relacionado: configuración de ntfy · Ingesta por email · Uptime + VPS → ntfy