HTTPS público caído, disco al 95%, MySQL muerto: tres scripts distintos, tres URLs curl ntfy.sh/… y un secreto que nunca rotarás. Apúntalos todos a AlertHub y pega un topic de ntfy. El teléfono ve un solo feed; el panel sigue siendo buscable.
AlertHub no es una red de sondas. UptimeRobot (o el cron) sigue comprobando el sitio. Bash sigue ejecutando df y systemctl. ntfy es solo el último tramo.
How-tos que ya existen: monitorización de uptime, uso de disco, watchdog de servicios. Este post es cómo comparten un topic sin despertarte por cada tick al 81%.
Qué suena y qué espera
| Señal | Fuente | Nivel | Prioridad ntfy |
|---|---|---|---|
| Sitio / API caído | UptimeRobot, Healthchecks, email ingest | Critical | 5 |
| MySQL / Nginx / SSH caído | check_services.sh | Critical | 5 |
| Disco ≥ 90% | check_disk.sh | Critical | 5 |
| Disco ≥ 80% | check_disk.sh | Warning | 4 |
| Recuperación / «ya está up» | Webhook de up del monitor | Info | — (solo panel) |
No envíes éxito o recuperación como warning. La gente ignora un topic que celebra tan alto como pagina.
Configuración (una vez)
- Un proyecto AlertHub (o
prodvsstagingsi los timeouts de staging no deben paginar). Copia la clave. - Conserva los POST existentes a
https://api.thealerthub.com/sendAlert— no los sustituyas por curls crudos a ntfy. - Suscríbete a un topic difícil de adivinar y pega
https://ntfy.sh/TU_TOPICen Connections → ntfy.
Si el monitor solo puede email, usa email ingest → ntfy en el mismo proyecto.
Alerta 1: Uptime público (UptimeRobot o cualquier notify HTTP)
Apunta el monitor a AlertHub con ah_level=critical y ah_source=UptimeRobot. Las URLs por query de la guía de uptime siguen valiendo. ntfy recibe prioridad 5. Una segunda URL con ah_level=info basta si quieres una fila de recuperación en el feed.
Alerta 2: Umbral de disco sin lobo
El script de disco ya hace POST al superar un umbral. Usa warning al 80% (ntfy 4) y sube el script a critical al 90%+ si quieres el banner urgente. Cron cada 15–60 minutos; no hagas POST en cada run cuando el uso está bien.
Alerta 3: Servicios systemd
check_services.sh debe enviar critical cuando mysql, nginx o ssh estén inactivos. Mismo ALERTHUB_KEY, ah_source con el hostname para que dos VPS no se vean iguales en la pantalla de bloqueo.
Ideas para sacarle más partido
ah_sourcees el filtro.prod-web-01,UptimeRobot,disk-cron— un topic, historial legible.- Staging nunca en ntfy. Proyecto aparte, o staging en
info. - Ops Android self-hosted. Los mismos tres scripts, Gotify en vez de ntfy.
- Deploy de GitHub + uptime. Fallo de ship vía Actions → ntfy; fallo de sonda en este topic. Mismo teléfono, títulos distintos.
Preguntas frecuentes
¿AlertHub hace ping a mi sitio?
No. El monitor o el cron lo hace. AlertHub guarda y enruta.
¿Puedo dejar Slack para el equipo?
Sí. ntfy para quien tiene el busca, Slack para el canal — guardia híbrida.
¿Por qué no curl a ntfy desde cada crontab?
Rotar el topic entonces implica SSH a cada host. AlertHub es una Connection.
Siguientes pasos
Apunta un monitor y un check de disco al mismo proyecto, pega un topic de ntfy y fuerza un warning.
Relacionado: configuración de ntfy · Uptime a Slack/Telegram · GitHub Actions → ntfy