El YAML que reporta un job muerto no tiene que saber de Slack. Si la guardia ya vive en ntfy, deja el paso failure() de GitHub Actions apuntando a AlertHub y pega una URL de topic en Connections.
AlertHub guarda cada run en el panel y hace POST de warning / critical a ntfy con Title, Priority y Tags. Los builds correctos se quedan en info y no llegan al teléfono.
Esto no son webhooks del repositorio (pushes, PRs). El pipeline mismo dice que el job murió.
Por qué ntfy para CI
| Necesidad | ntfy | Slack / Teams |
|---|---|---|
| Maintainer solo, sin workspace de chat | Nativo | Exceso |
| Despertar el teléfono a las 2 a.m. | Prioridad 5 (urgente) | Guerras de mute en el canal |
| Rotar el destino | Una URL de topic | Bot + canal + app |
| El mismo evento a un canal de equipo después | Añade Slack en el mismo proyecto | Ya está |
Las alertas critical de AlertHub mapean a prioridad 5 de ntfy; warning a 4. Info no sale del panel.
Configuración (una vez)
- Conserva (o añade) el curl de
failure()de la guía de GitHub Actions. Secreto:ALERTHUB_KEY. - En ntfy: suscríbete a un topic difícil de adivinar. La URL es
https://ntfy.sh/TU_TOPIC(o?auth=…si está reservado). - En AlertHub: Connections → ntfy del proyecto → pega la URL del topic. Envía un
warningde prueba.
Pasos del destino: docs de ntfy. El nombre del topic es la contraseña.
Alerta 1: Workflow fallido → ntfy urgente
Usa "ah_level": "critical" en if: failure() para que ntfy lo trate como prioridad 5. Incluye la URL del run en ah_description para abrir el job rojo de un toque.
El paso es el mismo curl que la guía orientada a Slack: solo cambia el destino. No añadas un segundo curl ntfy.sh/… en el YAML; esa es la pila de scripts que los usuarios de ntfy ya lamentan.
Alerta 2: Solo main, los PR en silencio
El CI phone-first muere cuando cada flake de PR suena. Filtra el paso:
if: failure() && github.ref == 'refs/heads/main'Los fallos de PR pueden quedarse en warning en otro job (prioridad 4) o en info para que existan en el feed sin buzz.
Alerta 3: Job de deploy vs job de tests
Los monorepos suelen tener tests verdes y un deploy rojo. Distingue ah_source (GitHub Deploy vs GitHub Actions) para filtrar el panel. Mismo topic de ntfy; títulos distintos. Deploys del host sin Actions: Vercel + Gotify.
Ideas para sacarle más partido
- Un topic para todos los repos. Secreto de organización
ALERTHUB_KEY;ah_source= nombre del repo. - No envíes éxitos a ntfy.
if: success()+infoes solo historial del panel. - ¿El equipo sigue en Slack? Añádelo en el mismo proyecto — guardia ntfy con Slack.
- ¿Teléfono self-hosted? Misma ingestión, destino Gotify en vez de (o junto a) ntfy.
Preguntas frecuentes
¿El YAML de Actions menciona ntfy?
No. Habla con AlertHub. ntfy es una Connection.
¿Cada PR fallido me despertará?
Solo si envías warning/critical sin filtrar github.ref. Filtra en main o baja el ruido de PR a info.
¿Funciona ntfy autoalojado?
Sí. Pega https://tu-host/topic (HTTPS, accesible desde internet).
Siguientes pasos
Copia el paso de fallo de GitHub Actions, pega un topic de ntfy en Connections y haz fallar un job de test en main.
Relacionado: configuración de ntfy · GitHub Actions a Slack/Telegram · Uptime + VPS en ntfy