Como enviar notificaciones desde GitHub Actions a Telegram, Discord o Slack

GitHub Actions te avisa que un workflow fallo poniendo una X roja al lado de un commit. Si no estas mirando la pagina del repo, no te vas a enterar hasta que alguien pregunte por que el deploy no salio. GitHub puede enviar notificaciones por email, pero se pierden en el ruido rapido — especialmente si tienes multiples repos con workflows activos.

Un mejor enfoque: recibir un mensaje de Telegram en tu telefono, un ping de Discord en tu servidor de equipo, o una alerta de Slack en tu canal de desarrollo en el momento en que un workflow falla. Aqui te explico como configurarlo, desde un enfoque rapido por plataforma hasta una solucion mas limpia que funciona en las tres.

Opcion 1: Webhooks por plataforma (La forma rapida)

Cada plataforma tiene su propio formato de webhook. Para Discord, creas una URL de webhook en la configuracion de tu canal y haces POST. Para Slack, configuras una app de Incoming Webhook. Para Telegram, llamas a la Bot API directamente.

Asi se ve un paso de webhook de Discord en un workflow de GitHub Actions:

GitHub Actions — webhook de Discord

name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to production
        run: ./scripts/deploy.sh

      - name: Notificar en caso de fallo
        if: failure()
        run: |
          curl -s -X POST "$DISCORD_WEBHOOK_URL" \
            -H "Content-Type: application/json" \
            -d "{
              \"content\": \"Deploy fallo en \`${{ github.repository }}\` — commit ${{ github.sha }}\"
            }"
        env:
          DISCORD_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}

Esto funciona para una plataforma en un repo. Pero los problemas aparecen rapido:

Una integracion por plataforma. Si quieres Discord y Telegram, estas escribiendo dos pasos de webhook separados con dos formatos de payload diferentes.
Un secreto por repo. Cada repo necesita la URL del webhook en sus secretos. Si rotas la URL, la actualizas en todos los repos.
Formatos de payload diferentes. Discord espera content, Slack espera text, Telegram espera chat_id + text. Estas aprendiendo tres APIs diferentes.
Sin historial. Una vez que el mensaje se envia, no hay registro de que se notifico o cuando.

Para un solo repo con una plataforma, los webhooks estan bien. Para un equipo con multiples repos y personas en diferentes plataformas, se convierte en un desorden de YAML duplicado y secretos.

Opcion 2: Una API de notificaciones (La forma limpia)

En lugar de llamar a la API de cada plataforma directamente, envias la alerta a un unico endpoint de notificaciones. Con NotificationsBot, una sola llamada API puede llegar a Telegram, Discord y Slack — quien sea que este suscrito a ese canal. El mismo comando cURL, el mismo formato de payload, siempre.

GitHub Actions — NotificationsBot

name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to production
        run: ./scripts/deploy.sh

      - name: Notificar en caso de fallo
        if: failure()
        run: |
          curl -s -X POST https://api.notificationsbot.com/event \
            -H "Authorization: Bearer $NOTIFICATIONSBOT_API_KEY" \
            -H "Content-Type: application/json" \
            -d "{
              \"channel\": \"deploys\",
              \"title\": \"Deploy fallo\",
              \"message\": \"${{ github.repository }} — commit ${{ github.sha }}\"
            }"
        env:
          NOTIFICATIONSBOT_API_KEY: ${{ secrets.NOTIFICATIONSBOT_API_KEY }}

Una API key en todos tus repos. Un formato de payload. Si quieres agregar un nuevo miembro del equipo en Telegram, lo agregas en el panel — sin cambios en YAML, sin nuevos secretos.

La diferencia clave

Con webhooks por plataforma, tu pipeline de CI esta acoplado a una plataforma de entrega. Con una API de notificaciones, tu pipeline solo reporta lo que paso — quien recibe la notificacion y en que plataforma se gestiona por separado. Puedes agregar suscriptores, cambiar de plataforma o dividir alertas en diferentes canales sin editar un solo archivo de workflow.

Configurando alertas de CI/CD con NotificationsBot

Si aun no tienes una cuenta, la configuracion toma unos 5 minutos:

Registrate en app.notificationsbot.com — plan gratuito, sin tarjeta de credito
Crea un canal (por ejemplo, deploys o ci-alerts)
Agrega un suscriptor — elige Telegram, Discord o Slack como plataforma
Vincula el suscriptor — conecta su cuenta a traves del flujo de onboarding
Asigna el suscriptor al canal
Crea una API key en Settings y agregala como secreto en tu repo de GitHub (NOTIFICATIONSBOT_API_KEY)

A partir de aqui, cualquier evento enviado a tu canal llega a quien sea que este suscrito. Puedes agregar mas personas despues — diferentes miembros del equipo, diferentes plataformas — sin cambiar tus workflows.

Alertar solo en caso de fallo

El patron mas comun es alertar solo cuando algo sale mal. GitHub Actions tiene una condicion integrada failure() que hace esto facil:

Solo en caso de fallo

      - name: Notificar en caso de fallo
        if: failure()
        run: |
          curl -s -X POST https://api.notificationsbot.com/event \
            -H "Authorization: Bearer $NOTIFICATIONSBOT_API_KEY" \
            -H "Content-Type: application/json" \
            -d "{
              \"channel\": \"ci-alerts\",
              \"title\": \"CI fallo: ${{ github.repository }}\",
              \"message\": \"Branch: ${{ github.ref_name }}\nCommit: ${{ github.sha }}\nAutor: ${{ github.actor }}\"
            }"
        env:
          NOTIFICATIONSBOT_API_KEY: ${{ secrets.NOTIFICATIONSBOT_API_KEY }}

Este paso se ejecuta solo si un paso anterior en el job fallo. Incluye el nombre del repo, branch, hash del commit y quien hizo push — suficiente contexto para saber que se rompio sin abrir GitHub.

Alertar en exito y fallo

Para workflows de deploy, puede que quieras saber cuando un deploy tiene exito tambien — especialmente si tarda unos minutos y estas esperandolo. Usa la condicion always() e incluye el estado del job:

En exito y fallo

      - name: Notificar resultado del deploy
        if: always()
        run: |
          if [ "${{ job.status }}" == "success" ]; then
            TITLE="Deploy exitoso"
          else
            TITLE="Deploy fallo"
          fi

          curl -s -X POST https://api.notificationsbot.com/event \
            -H "Authorization: Bearer $NOTIFICATIONSBOT_API_KEY" \
            -H "Content-Type: application/json" \
            -d "{
              \"channel\": \"deploys\",
              \"title\": \"$TITLE\",
              \"message\": \"${{ github.repository }} — ${{ github.ref_name }}\npor ${{ github.actor }}\"
            }"
        env:
          NOTIFICATIONSBOT_API_KEY: ${{ secrets.NOTIFICATIONSBOT_API_KEY }}

Bueno saberlo

Usa if: failure() para workflows de tests y build — solo te importa cuando fallan. Usa if: always() para workflows de deploy — saber que un deploy termino exitosamente es igual de util que saber que fallo.

Workflow reutilizable para multiples repos

Si tienes multiples repos que deben enviar notificaciones, puedes extraer el paso de notificacion en un workflow reutilizable. Lo defines una vez, lo llamas desde cualquier repo:

.github/workflows/notify.yml — workflow reutilizable

name: Notify
on:
  workflow_call:
    inputs:
      channel:
        required: true
        type: string
      title:
        required: true
        type: string
      message:
        required: true
        type: string
    secrets:
      NOTIFICATIONSBOT_API_KEY:
        required: true

jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - name: Enviar notificacion
        run: |
          curl -s -X POST https://api.notificationsbot.com/event \
            -H "Authorization: Bearer $NOTIFICATIONSBOT_API_KEY" \
            -H "Content-Type: application/json" \
            -d "{
              \"channel\": \"${{ inputs.channel }}\",
              \"title\": \"${{ inputs.title }}\",
              \"message\": \"${{ inputs.message }}\"
            }"
        env:
          NOTIFICATIONSBOT_API_KEY: ${{ secrets.NOTIFICATIONSBOT_API_KEY }}

Luego lo llamas desde cualquier workflow:

Llamando al workflow reutilizable

  notify:
    if: failure()
    needs: deploy
    uses: your-org/shared-workflows/.github/workflows/notify.yml@main
    with:
      channel: deploys
      title: Deploy fallo
      message: ${{ github.repository }} — ${{ github.ref_name }}
    secrets:
      NOTIFICATIONSBOT_API_KEY: ${{ secrets.NOTIFICATIONSBOT_API_KEY }}

Webhooks por plataforma vs NotificationsBot

Configuracion por repo — Webhooks: un secreto por plataforma por repo. NotificationsBot: una API key para todos los repos
Multi-plataforma — Webhooks: un paso separado por plataforma, formatos de payload diferentes. NotificationsBot: un paso llega a Telegram + Discord + Slack
Agregar un miembro del equipo — Webhooks: necesitan acceso al canal/grupo. NotificationsBot: agregar un suscriptor en el panel
Cambiar de plataforma — Webhooks: reescribir el paso del workflow, agregar nuevos secretos. NotificationsBot: cambiar la plataforma del suscriptor en el panel
Historial de notificaciones — Webhooks: sin registro. NotificationsBot: log de eventos buscable con timestamps
Formato de payload — Webhooks: diferente por plataforma. NotificationsBot: un formato JSON en todos lados

Bonus: Canales separados para tests y deploys

Una configuracion comun para equipos es tener dos canales de notificacion: uno para fallos de CI (tests/lint/build) y otro para resultados de deploy. El canal de CI va a un canal de Slack donde todo el equipo puede ver que esta roto. El canal de deploy envia un ping de Telegram a la persona responsable de los releases.

Con NotificationsBot, esto son solo dos canales con diferentes suscriptores. Tu workflow de tests envia a ci-alerts, tu workflow de deploy envia a deploys. Cada canal tiene su propio conjunto de suscriptores en la plataforma que prefieran. No se necesitan cambios en workflows cuando personas se unen o dejan el equipo.

Recibe tu primera alerta de CI/CD en 5 minutos

Crea una cuenta gratuita, agrega un suscriptor en Telegram, Discord o Slack, y conecta tu primera notificacion de GitHub Actions.

Comenzar gratis