Cómo integrar GitHub con Slack (sin ahogarse en el ruido)
Conecta GitHub a Slack correctamente – configura la integración oficial, filtra notificaciones por etiqueta y rama, y mantén los canales útiles.
By Ellis Keane · 2026-03-19
Un despliegue acaba de fallar. El canal de Slack donde tu equipo coordina está en silencio – nadie vio la alerta de GitHub Actions porque se publicó en #github-notifications, un canal que todos silenciaron hace semanas.
Si estás buscando cómo integrar GitHub con Slack, ese escenario es probablemente el motivo. La conexión tarda unos minutos en instalarse (yo configuré la nuestra entre reuniones una vez, lo cual en retrospectiva fue optimista). Hacer que sea realmente útil lleva un poco más, y eso es lo que cubre este tutorial.
Qué hace (y qué no hace) la integración oficial de GitHub con Slack
La app oficial de Slack de GitHub publica notificaciones sobre PRs, issues, despliegues y commits en canales de Slack. Puedes suscribir canales a repositorios específicos, filtrar por tipo de evento y realizar algunas acciones directamente desde Slack – cerrar issues, abrir nuevos, ese tipo de cosas.
Lo que no hace es entender el contexto. Un error tipográfico en un README recibe el mismo tratamiento que un hotfix de producción. Una actualización de dependencia abierta por un bot aparece junto a un parche de seguridad crítico. La integración es una tubería, no un filtro – y las tuberías solo son útiles si controlas lo que fluye por ellas.
"La integración es una tubería, no un filtro – y las tuberías solo son útiles si controlas lo que fluye por ellas." – Chris Calo
(La mayoría de los equipos se dan cuenta de esto alrededor de una semana después, cuando #engineering empieza a parecerse a un ticker de bolsa para commits que nadie pidió ver.)
Configurar la app de GitHub para Slack
Tres pasos y ya estás dentro:
- Instala la app de GitHub en Slack. Ve al directorio de apps de tu workspace de Slack y busca "GitHub". Necesitarás permisos de administrador del workspace, o al menos alguien que los tenga y te deba un favor.
- Autentícate. Escribe
/github signin en cualquier canal. Esto vincula tu cuenta de GitHub para que Slack pueda mostrar notificaciones más enriquecidas y permitirte interactuar con issues sin salir de la conversación.
- Suscribe un canal a un repositorio. En el canal donde quieras las notificaciones:
``` /github subscribe owner/repo-name ``` De forma predeterminada, esto te suscribe a issues, pulls, commits, releases y deployments – cinco tipos de evento, más de lo que la mayoría de los canales necesitan.
- Recorta de inmediato. Cancela la suscripción a lo que no sirve al canal:
``` /github unsubscribe owner/repo-name commits ``` Para la mayoría de los equipos de ingeniería, pulls y deployments son los que vale la pena mantener. issues depende de si tu equipo triagea en GitHub o usa un tracker separado como Linear. commits es casi siempre ruido – si quieres ver los cambios de código, mira el PR.
La referencia completa de comandos está en los docs del repositorio de integración.
Suscríbete primero, luego cancela de inmediato los tipos de evento que no sirven al canal. La suscripción predeterminada a "todo" es el motivo por el que la mayoría de los equipos termina silenciando el canal por completo.
Cómo integrar las notificaciones de GitHub con Slack de forma útil
Aquí es donde la mayoría de los tutoriales se detienen, y donde la mayoría de las integraciones se vuelven silenciosamente inútiles. El sistema de suscripción/cancelación es tosco – o todos los PRs o ningún PR, todos los issues o ningún issue. Si tienes un monorepo con cuarenta colaboradores, "todos los PRs" es una manguera contra incendios.
El filtrado por etiqueta es la solución infrautilizada. Puedes filtrar notificaciones por etiqueta:
``` /github subscribe owner/repo-name +label:"needs-review" ```
Ahora el canal solo ve PRs o issues etiquetados con needs-review. Para equipos que usan etiquetas de forma consistente (y eso es un compromiso real, no algo trivial), esto transforma la integración de ruidosa a útil. Los PRs que necesitan atención aparecen en Slack. Todo lo demás se queda en GitHub donde le corresponde.
El filtrado de ejecuciones de flujo de trabajo te permite acotar las notificaciones de CI por rama:
``` /github subscribe owner/repo-name workflows +branch:main ```
Esto significa que solo ves las ejecuciones del flujo de trabajo activadas en main – no cada ejecución de CI de una rama de funcionalidad. Si tu equipo usa GitHub Actions para despliegues, así es como obtienes alertas relevantes para producción sin el flujo constante de marcas verdes de las ramas de desarrollo.
La arquitectura de canales importa. Un único canal #github para todo es una receta para silenciarlo. Considera dividir:
| Canal | Suscripciones | |-------|--------------| | #deploys | Solo deployments | | #pr-reviews | pulls +label:"needs-review" | | #incidents | issues +label:"P0" |
Tres canales enfocados superan a uno ruidoso. Cada uno tiene un propósito claro, y los miembros del equipo pueden unirse a los relevantes para su rol. (Sé que esto parece obvio, pero he visto equipos con un único canal #dev manejando bots de Slack, notificaciones de GitHub, alertas de despliegue y chat general. Es el caos.)
Tres flujos de trabajo que vale la pena configurar
Recordatorios programados para PRs obsoletos. Los recordatorios programados de GitHub envían avisos a Slack cuando los PRs están esperando revisión. Los configuras a través de la interfaz web de GitHub (Configuración, luego Recordatorios programados), no con un comando de Slack. Captura los PRs que envejecen silenciosamente en el backlog porque nadie los notó.
Enlaces de vista previa de despliegues. Cuando un PR activa una vista previa de despliegue (Vercel, Netlify o similares), el estado aparece en la notificación de Slack. Tu diseñador puede acceder a la URL de vista previa sin abrir GitHub – un cambio de contexto menos por revisión.
Conversaciones basadas en hilos. Los comentarios sobre una notificación de PR permanecen en un hilo de Slack. Tu "se ve bien, un pequeño detalle en la línea 47" ocurre donde vive el resto del contexto. El comentario no se sincroniza de vuelta a GitHub (solo Slack), lo cual es tanto una limitación como, podría decirse, una característica.
Cuando la integración nativa alcanza su límite
La integración oficial cubre mucho terreno, pero hay patrones que no puede manejar:
Visibilidad entre repositorios. Si tu proyecto abarca tres repositorios, necesitas tres suscripciones separadas con tres configuraciones de filtro separadas. No hay un "muéstrame todo lo relacionado con el Proyecto X entre repositorios". Mantienes configuraciones paralelas y esperas que se mantengan consistentes.
Conectar GitHub a tu tracker de issues. Si tu equipo usa Linear como fuente de verdad para las tareas, la integración de GitHub con Slack no sabe nada de esa relación. Un PR podría cerrar un issue de Linear, pero Slack no lo sabe – la notificación dice "PR fusionado" sin contexto sobre para qué tarea era o quién la estaba esperando.
Disciplina de etiquetas a escala. El filtrado por etiqueta funciona, pero requiere consistencia – alguien tiene que aplicar las etiquetas, y el filtro se rompe en el momento en que un PR se envía sin una. La carga de mantenimiento crece con el equipo. En algún punto estás gastando más tiempo manteniendo los filtros precisos de lo que ahorras al tenerlos.
(Este es el punto en el que los equipos recurren a Zapier o a un bot personalizado, lo cual funciona hasta que la autenticación del webhook caduca, el límite de velocidad se activa o alguien se va y nadie recuerda cómo está conectado.)
Hacerlo durar
La integración de GitHub con Slack es una de esas herramientas que o es invisible (porque está bien configurada) o activamente odiada (porque no lo está). La diferencia está en la configuración:
- Suscríbete solo a los tipos de evento que sirven al propósito del canal
- Usa filtros de etiqueta y rama para reducir el ruido antes de que llegue a Slack
- Divide las notificaciones en canales enfocados en lugar de uno general
- Configura recordatorios programados para PRs obsoletos a través de la interfaz web de GitHub
- Acepta que la integración nativa tiene límites – y cuando el contexto entre repositorios o las conexiones con el tracker de issues importan, mira herramientas diseñadas para esa capa
Si necesitas integrar GitHub con Slack, la app nativa es el punto de partida correcto. Los consejos de filtrado y arquitectura de canales anteriores lo mantendrán útil más allá de la primera semana. Y si has superado lo que una tubería de notificaciones puede hacer – si la pieza faltante es la relación entre un PR, el ticket de Linear al que pertenece y el hilo de Slack donde se debatió el enfoque – eso es lo que estamos construyendo en Sugarbug para resolver.
Conecta GitHub, Linear, Slack y Figma en un grafo de conocimiento – para que cada PR se vincule a la conversación y al ticket al que pertenece.
Q: ¿Cómo integro GitHub con Slack? A: Instala la app de GitHub desde el directorio de apps de Slack, autentícate con /github signin y luego suscribe canales a repositorios con /github subscribe owner/repo-name. Recorta los tipos de evento de inmediato – los valores predeterminados incluyen todo, lo que casi siempre genera demasiado ruido.
Q: ¿Puede Sugarbug reemplazar la integración de GitHub con Slack? A: Sugarbug funciona junto a ella en lugar de reemplazarla. La integración nativa gestiona las notificaciones; Sugarbug construye un grafo de conocimiento que conecta los PRs de GitHub con sus issues de Linear correspondientes, conversaciones de Slack y diseños de Figma – para que veas el contexto completo de un cambio, no solo que se fusionó un PR.
Q: ¿Cómo filtro las notificaciones de GitHub en Slack por etiqueta? A: Usa el filtro de etiqueta al suscribirte: /github subscribe owner/repo-name +label:"needs-review". Solo los elementos con esa etiqueta se publicarán en el canal. Puedes combinar múltiples filtros de etiqueta y mezclarlos con suscripciones de tipo de evento.
Q: ¿Sugarbug rastrea automáticamente la actividad de GitHub en Slack y Linear? A: Sí. Sugarbug se conecta a GitHub, Slack y Linear mediante API y correlaciona la actividad – cuando un PR de GitHub hace referencia a una conversación de Slack o cierra un ticket de Linear, esas conexiones se rastrean en el grafo de conocimiento sin etiquetado manual ni disciplina de etiquetas.