Linear, GitHub y Slack: 200 notificaciones reducidas a 5
¿Las notificaciones de Linear, GitHub y Slack abruman a tu equipo? Por qué la arquitectura falla – y las 5 señales que realmente importan.
By Ellis Keane · 2026-03-13
El problema no es que recibas demasiadas notificaciones. El problema es que recibes exactamente el número correcto – de tres herramientas diferentes, sobre el mismo evento, al mismo tiempo.
Cada webhook se dispara correctamente. Cada integración entrega precisamente lo que prometió. GitHub te notifica sobre el PR. Linear te notifica sobre la tarea que el PR cierra. Slack te notifica porque alguien, en algún momento (probablemente tú, hace tres meses, en un arranque de optimismo mal orientado sobre la "visibilidad"), conectó un bot al canal del proyecto. Tres herramientas, tres notificaciones, un evento, y todas funcionando exactamente como fueron diseñadas. La ingeniería es impecable. La experiencia es miserable.
Tus notificaciones de Linear, GitHub y Slack no son abrumadoras porque algo esté roto. Son abrumadoras porque nada lo está. Cada herramienta ejecuta fielmente su contrato de notificaciones con total desconocimiento de que las demás existen. No hay un bus de eventos compartido. No hay una capa de deduplicación. No existe en ningún punto del stack el concepto de "este humano ya sabe esto." No sufres por una mala configuración. Sufres por el punto final lógico de conectar seis herramientas al mismo flujo de trabajo y dejar que cada una grite de forma independiente al vacío.
"El sistema de notificaciones no está fallando. Está teniendo tanto éxito que te entierra." – Chris Calo
Progreso.
Anatomía de un único merge – la autopsia de duplicados
Déjame guiarte por un evento – un único merge de PR – y rastrear lo que sucede en la capa de notificaciones. No porque sea inusual, sino porque es deprimententemente ordinario.
Un compañero de equipo hace merge de un PR en GitHub. Aquí está la cascada:
- GitHub dispara un webhook a tu bandeja de notificaciones. Escribiste una revisión en este PR, así que estás suscrito. Esa es la notificación uno.
- La integración de GitHub de Linear detecta la tarea vinculada y cambia automáticamente su estado de "En progreso" a "Hecho." Linear genera una notificación para todos los que siguen la tarea – lo que te incluye a ti, porque estás en el mismo equipo. Esa es la notificación dos.
- El bot de Slack (el que conectaste en ese arranque de optimismo que mencioné) publica un resumen del merge en #frontend. Si alguien reacciona a ese mensaje con un emoji o un comentario, Slack genera una notificación de hilo. Esa es la notificación tres, potencialmente cuatro.
- CI se ejecuta en el commit del merge. GitHub dispara otro webhook. Si CI pasa, probablemente no te importa, pero recibes la notificación de todas formas porque el modelo de suscripción de GitHub es binario – o estás siguiendo algo o no. Esa es la notificación cinco.
Cinco notificaciones. Un evento. Y estabas en la llamada donde se discutió el merge, así que ya sabías de él antes de que llegara ninguna.
Multiplica esto por cada PR, cada transición de tarea y cada ejecución de CI para un equipo de seis, y estás mirando 30 a 40 eventos duplicados por persona por día antes de contar siquiera las señales genuinamente nuevas. El sistema de notificaciones no está fallando. Está teniendo tanto éxito que te entierra.
Por qué silenciar es un parche sobre una hemorragia
El consejo estándar es silenciar de forma agresiva. Desactiva las notificaciones por correo de GitHub. Configura Slack para que solo notifique con menciones directas. Deja de seguir todos los issues de Linear excepto los asignados a ti. Esto es el equivalente en notificaciones de tratar una muñeca fracturada quitándote el reloj – técnicamente has reducido la complejidad relacionada con la muñeca, pero también has perdido la capacidad de saber qué hora es.
Probé el enfoque de silenciar (por supuesto que lo hice – todos lo hacemos, es lo primero que intenta todo el mundo, justo antes de lo segundo que intenta todo el mundo, que es una cadena de Zapier que de alguna manera lo empeora). Fui agresivo: desactivé completamente los correos de GitHub, silencié todos los canales de Slack que no fueran el canal de trabajo de mi equipo, dejé de seguir todo en Linear excepto mis propias tareas. Beatitud durante unos tres días.
Luego me perdí dos revisiones de PR bloqueantes porque las discusiones ocurrieron en canales que había silenciado. Los ingenieros que necesitaban mi revisión finalmente me enviaron un DM – que es solo una notificación con pasos adicionales y un toque de energía pasivo-agresiva de "oye, ¿viste mi mensaje?". Una semana después, una decisión de diseño aterrizó en un hilo de comentarios de Figma que cambió completamente el componente que estaba construyendo a medias, y no me enteré hasta que rechazaron mi PR. Lo cual fue divertido.
El problema fundamental de silenciar es que aplica reglas estáticas a un contexto dinámico. Tu configuración de notificaciones del martes pasado no sabe nada del bug urgente que apareció esta mañana. Y cuanto más agresivamente silencias, más amplias se vuelven las brechas en tu conocimiento – brechas que los compañeros llenan con DMs de "solo quería asegurarme de que viste...". Lo que, si llevas la cuenta, significa que silenciar agresivamente no reduce tus notificaciones. Solo las desplaza de bots (que no te juzgan) a humanos (que definitivamente sí lo hacen).
Las cinco señales que realmente justifican una interrupción
Después de registrar notificaciones durante unas semanas (en un archivo de texto plano, porque soy exactamente el tipo de persona que esperarías que escribiera un artículo sobre arquitectura de notificaciones), surgió un patrón. De aproximadamente 200 pings diarios, los que genuinamente requerían acción dentro de la hora caían en cinco categorías:
- Alguien está bloqueado por ti. Una solicitud de revisión de PR sobre código que posees, una pregunta que solo tú puedes responder, una decisión esperando tu opinión. Esta es la única categoría donde el retraso tiene un coste compuesto – cada hora que no respondes es una hora que otra persona no puede trabajar.
- Algo que desplegaste está roto. Fallos de CI en tu rama, picos de errores tras tu merge, una solicitud de reversión. La categoría "tu código está en llamas."
- Se tomó una decisión que afecta a tu trabajo actual. Un cambio de diseño, una actualización del contrato de API, un cambio de prioridades del lado del producto. Estas son raras pero costosas de perderse (ver: mi PR rechazado, arriba).
- Una fecha límite se movió. El alcance del sprint cambió, una demo se adelantó, una dependencia se retrasó. Eventos que alteran el calendario.
- Alguien necesita ayuda y tú eres la persona adecuada. No cada @channel. No cada @here. Los específicos donde tu experiencia es genuinamente relevante – e incluso entonces, solo si nadie más puede responder.
Todo lo demás – transiciones de estado, mensajes automáticos de bots, reacciones de emoji de "suena bien", CI pasando en ramas que no sigues – son información que podría ser útil eventualmente pero que no necesita interrumpir la función que estás escribiendo. El complejo industrial de notificaciones nos ha convencido de que todos merecen igual urgencia. No la merecen.
De 200 notificaciones diarias, aproximadamente cinco categorías realmente justifican interrumpir lo que estás haciendo. El resto es información que podría ser útil eventualmente – pero las herramientas tratan todo con igual urgencia, lo que significa que nada lo es.
Un marco de triaje para los arquitectónicamente traicionados
Aquí hay un marco que puedes empezar a usar hoy – sin herramientas necesarias, solo disciplina y unos 20 minutos de configuración. No resolverá el problema arquitectónico (nada salvo una capa de deduplicación puede hacer eso), pero detendrá el sangrado mientras evalúas soluciones a largo plazo.
El barrido dos veces al día: En lugar de revisar notificaciones de forma continua, agrúpalas en dos barridos – una vez a media mañana, una vez a media tarde. Durante cada barrido, escanea tus notificaciones de GitHub, la bandeja de entrada de Linear y los mensajes no leídos de Slack, y clasifica cada uno en uno de tres cubos:
| Cubo | Regla | Acción | |------|-------|--------| | Actuar ahora | Alguien está bloqueado, algo está roto o una decisión te necesita | Gestionar de inmediato | | Agrupar | Importante pero no urgente en tiempo | Añadir a una lista de "responder después", gestionar al final del día | | Archivar | Charla de bots, actualizaciones de estado, hilos resueltos, duplicados | Marcar como leído, seguir con tu vida |
Establecer valores predeterminados a nivel de canal en Slack: Para cada canal, decide: ¿es este un canal de "actuar ahora" (el canal de trabajo de tu equipo, canales de incidentes) o un canal de "agrupar" (anuncios generales, actualizaciones entre equipos)? Silencia los canales de agrupación y solo compruébalos durante tus barridos. Sí, esto es técnicamente silenciar, algo que acabo de criticar durante dos párrafos – la diferencia es que sigues revisándolos en un horario en lugar de pretender que no existen.
Usa los filtros de notificaciones de GitHub: Guarda como marcador github.com/notifications?query=reason:review-requested – esa URL muestra solo las revisiones de PR explícitamente asignadas a ti, eliminando por completo el ruido de suscripciones/CI. Para el correo, GitHub incluye un encabezado de razón (review_requested, mention, subscribed, ci_activity) por el que puedes filtrar: archiva automáticamente "subscribed" y "ci_activity" y no perderás nada que realmente necesites. El hecho de que GitHub entierre estos metadatos útiles en encabezados de correo en lugar de exponerlos en la UI de notificaciones te dice todo sobre cuánto se ha pensado en el lado del consumo de estos sistemas.
Este enfoque no capturará las señales contextuales (¿recuerdas ese comentario de Figma que torpedó mi PR? El barrido dos veces al día tampoco lo habría capturado). Pero reducirá el ruido en un 60 a 70 por ciento, lo que es suficiente para detener el alt-tabulado compulsivo mientras determines si el problema justifica una solución real.
Lo que una capa de deduplicación realmente necesitaría hacer
Aquí es donde se vuelve arquitectónicamente interesante – y donde dejé de pensar en esto como un problema de configuración de notificaciones y empecé a pensar en ello como un problema de clasificación.
El enfoque ingenuo es la coincidencia de palabras clave y la detección de menciones. Si aparece tu nombre, muéstralo. Si es una solicitud de revisión asignada a ti, muéstralo. Esto captura los casos obvios pero se pierde por completo los contextuales – la decisión de diseño en un hilo donde nadie te @mencionó porque no se dieron cuenta de que estabas construyendo el componente que afecta. (Ese me va a perseguir un tiempo.)
Lo que realmente necesitarías es un grafo de relaciones: qué tareas son tuyas, qué PRs se relacionan con qué issues, qué hilos de Slack tratan sobre qué funcionalidades, qué personas tienden a necesitar tu opinión sobre qué temas. Cuando llega una nueva señal – un mensaje de Slack, un evento de GitHub, una transición de Linear – la clasificas contra ese grafo. No "¿menciona esto a Chris?" sino "¿afecta esto a algo en lo que Chris está trabajando activamente, esperando o de lo que es responsable?"
La clasificación necesitaría desglosarse en algo así:
| Clasificación | Qué significa | Acción | |---------------|---------------|--------| | Urgente | Estás bloqueando a alguien, o algo está roto | Mostrar de inmediato | | Importante | Afecta a tu trabajo actual, pero no es crítico en tiempo | Agrupar en un resumen diario | | Informativo | Bueno saberlo, no se necesita acción | Disponible si lo buscas | | Ruido | Duplicados, charla de bots, hilos resueltos | Filtrado completamente |
La parte difícil es que la confianza en la clasificación no es binaria. Un mensaje de Slack en un canal que nunca visitas podría seguir siendo urgente si hace referencia a una tarea asignada a ti. Una notificación de GitHub sobre un repositorio que no has tocado en meses podría importar si alguien acaba de reabrir un bug que creías corregido. Necesitas dos capas trabajando en conjunto: una capa de normalización de eventos que hashea cada webhook entrante contra una clave compuesta – repositorio, ID de issue, actor, tipo de evento – y lo comprueba contra una ventana de deduplicación con TTL (básicamente una ventana deslizante de huellas de eventos recientes), y detrás de esa, un grafo de relaciones en vivo que mapea la propiedad de tareas, los vínculos de PR, los participantes de hilos y los patrones de actividad reciente. Básicamente estás construyendo un modelo de lectura del estado de trabajo completo del equipo, actualizado casi en tiempo real, y consultándolo en cada señal entrante. La capa de deduplicación captura los duplicados obvios. El grafo responde la pregunta más difícil: "¿es esto relevante para ti específicamente, ahora mismo?"
El bucle de clasificación central maneja bien los casos claros, y eso solo ya reduce sustancialmente el ruido – pero las señales genuinamente ambiguas (donde no tienes suficiente confianza para suprimirlas pero tampoco para mostrarlas) siguen siendo un problema abierto. Estamos experimentando con agruparlas en un resumen de "quizás", pero no voy a pretender que lo hemos resuelto.
Qué cambia cuando el torrente se detiene
Lo que no esperaba – genuinamente pensé que el beneficio sería solo "menos pings" – es lo profundamente que cambia tu relación con tus herramientas cuando dejan de gritarte.
Cuando cada notificación podría ser importante, desarrollas esta ansiedad de bajo grado sobre los recuentos de no leídos. La barra lateral de Slack con sus nombres de canal en negrita. El timbre de GitHub. La bandeja de entrada de Linear. Revisas de forma compulsiva, no porque esperes algo urgente, sino porque el coste de perderte algo parece mayor que el coste de revisar 50 cosas que resultan ser ruido. Solía hacer alt-tab a Slack entre escribir una firma de función y su cuerpo. No fue una decisión consciente – solo un reflejo, como comprobarías los espejos en un semáforo en rojo.
La auto-interrupción preventiva es posiblemente peor que las propias notificaciones, porque estás rompiendo tu propia concentración antes de que llegue ningún ping. Vives en un estado de atención parcial permanente, y lo sientes en el código que escribes – revisiones más superficiales, decisiones arquitectónicas más seguras, el camino de menor resistencia en lugar del enfoque que realmente es correcto, porque no confías en tener 45 minutos ininterrumpidos para pensarlo.
Cuando el torrente se detiene – cuando confías en que las señales importantes te encontrarán y el ruido no – ese reflejo se desvanece. No de inmediato, porque los viejos hábitos son obstinados. Pero en un par de semanas notas que pasas períodos más largos en tu editor sin el alt-tab compulsivo. Empiezas a terminar los pensamientos. Escribes mejor código, no porque de repente te hayas vuelto más inteligente, sino porque dejaste de ofrecerte voluntariamente para 30 cambios de contexto por hora en nombre de un sistema de notificaciones que nunca te lo pidió.
Deja de ahogarte en notificaciones. Sugarbug clasifica cada señal de Linear, GitHub y Slack por relevancia – y solo muestra lo que realmente te necesita.
Q: ¿Reduce Sugarbug las notificaciones abrumadoras de Linear, GitHub y Slack? A: Sí. Sugarbug se conecta a Linear, GitHub y Slack vía API y clasifica cada señal por urgencia y relevancia. En lugar de reenviar cada notificación, solo muestra las que requieren tu atención – normalmente reduciendo cientos de pings diarios al puñado que genuinamente te necesita.
Q: ¿Puede Sugarbug priorizar las notificaciones de PR de GitHub según en qué estoy trabajando? A: Sugarbug construye un grafo de conocimiento de tus tareas, PRs y conversaciones. Sabe qué PRs están relacionados con tu trabajo actual y muestra primero las solicitudes de revisión, conflictos de merge y fallos de CI para esos – mientras archiva silenciosamente el resto.
Q: ¿En qué se diferencia Sugarbug de la configuración de notificaciones integrada de Slack? A: La configuración de Slack te permite silenciar canales o establecer palabras clave, pero no puede entender el contexto entre herramientas. Sugarbug lee Linear, GitHub y Slack conjuntamente, por lo que sabe que un hilo de Slack sobre un PR que escribiste es urgente aunque esté en un canal que hayas silenciado.
Q: ¿Cuál es el coste real de la sobrecarga de notificaciones para los equipos de ingeniería? A: La investigación de Gloria Mark en UC Irvine sugiere que se necesitan aproximadamente 23 minutos para recuperar la concentración profunda tras una interrupción. Más allá de los pings en sí, el comportamiento de comprobación compulsiva que generan fragmenta la concentración sostenida que exige el trabajo de ingeniería complejo.
Si las notificaciones de tu equipo de ingeniería han cruzado la línea de "mantenerse informado" a "mantenerse ansioso," eso es probablemente una señal de que la arquitectura necesita arreglarse, no tus preferencias de notificaciones.