Slack Caído: ¿Qué Causó la Caída del 27/05/2026?

El Slack caído paralizó equipos remotos desde Brasil hasta Estados Unidos en la tarde del 27 de mayo de 2026, con más de 6.000 reportes en Downdetector y el estado oficial confirmando "latencia severa afectando todos los servicios de Slack". No fue un incidente aislado: es el quinto problema visible del mes, y el segundo gran pico de reportes después de la caída parcial del día 14. En esta guía, desglosaré lo que sucedió, por qué los SaaS de comunicación derriban empresas enteras en minutos y —más importante— qué ajustar en tu operación para que el próximo Slack caído no pause tu facturación.

TL;DR

• Slack estuvo caído a partir de las 16:00 PDT (20:00 BRT) del 27/05/2026, con más de 6.000 reportes en Downdetector en poco más de una hora.
• Estado oficial: "Severe Latency Impacting All Slack Services" — mensajes, archivos, ediciones y workflows degradados al mismo tiempo.
• Mayo de 2026 tuvo cinco incidentes registrados en la página de estado oficial: días 4, 8, 14, 18, 19 y 27 — señal de una mala racha, no de una falla puntual.
• Qué hacer ahora: tener canal de respaldo acordado (WhatsApp, correo, teléfono), página de estado en monitoreo y plan de comunicación para fuera del horario laboral.
• Qué evitar: depender de un único SaaS de comunicación como columna vertebral de atención al cliente — la redundancia no es lujo, es seguro.

Qué sucedió en la caída de Slack del 27 de mayo de 2026

La tarde del miércoles comenzó normal y se volvió caos alrededor de las 15:54 hora del Pacífico (18:54 en Brasilia), cuando Downdetector pasó de 2.800 reportes de usuarios reportando que el Slack caído les impedía trabajar. En tres minutos, el número saltó a 3.400. A las 16:05 PT, más de 6.000 personas habían registrado fallos — pico raro para una plataforma que normalmente respira tranquilo entre las 17:00 y las 18:00 de la Costa Oeste.

El estado oficial tardó en actualizarse. Inicialmente la página status.slack.com mostraba todo verde, situación típica de los primeros minutos de cualquier incidente grave en SaaS — el sistema de monitoreo interno espera confirmación antes de mover el indicador. Cuando Slack finalmente publicó el boletín, el lenguaje fue directo: "The Slack Engineering team is currently investigating severe latency impacting all Slack services".

Síntomas que los usuarios reportaron

No fue una caída binaria ("la app no abre"). Fue peor, en realidad: una degradación intermitente, de esas que quitan la confianza en el canal sin matarlo del todo. Los reportes más comunes:

• Mensajes enviados que tardaban minutos en aparecer para el destinatario.
• Hilos que cargaban parcialmente, perdiendo respuestas antiguas.
• Reacciones con emoji que no se actualizaban.
• Subida de archivos atascada en el 90% y fallando.
• Workflows automáticos disparando duplicados o nunca disparándose.
• Huddles que conectaban pero con audio entrecortado.

Quien usa Slack como canal principal de soporte al cliente percibió el desastre rápido: tickets de chat acumulándose sin respuesta porque el operador veía el chat con 4 minutos de retraso.

Historial reciente: mayo de 2026 fue tenso para Slack

El Slack caído del 27/05 no es el problema, es el síntoma. Cuando miré la página oficial slack-status.com/calendar, conté seis incidentes en mayo hasta el momento de esta publicación. No está bien.

Fecha (2026)	Incidente	Duración
4 de mayo	Lentitud general en Slack	Resuelto a las 10:37 PDT
8 de mayo	Carga de canales y entrega de mensajes en clientes EKM	Resuelto el 11/05
8 de mayo	Migraciones de grid con tiempo de inactividad extendido	Resuelto a las 10:44 PDT
14 de mayo	Fallos en subidas, ediciones, creación y renombrado de canales	~59 minutos
18 de mayo	Resúmenes de Huddle por IA no se generaban	Resuelto a las 7:53 PDT
19 de mayo	Fallos en subida de archivos y emojis	Resuelto a las 15:27 PDT
27 de mayo	Latencia severa en todos los servicios	En investigación al momento de esta publicación

Dos señales saltan de esta tabla. La primera: muchos incidentes involucraron subsistemas distintos — subidas, workflows, IA, creación de canales, latencia general. Esto sugiere que Slack está tocando capas profundas de la arquitectura al mismo tiempo, o que una dependencia compartida (base de datos, cola, CDN) está oscilando. La segunda: la IA generativa de Slack (resúmenes de Huddle, Slack AI) entra cada vez más en la lista de incidentes — función nueva, superficie nueva para bugs.

Qué enseña el historial sobre la próxima

Ninguna estadística pública garantiza que junio será mejor. Lo que se puede afirmar con seguridad es que, en 30 días, tu equipo fue expuesto al menos a una ventana de degradación significativa. Si tu operación no lo notó, genial — pero puede haber sido suerte de horario. Si lo notó, vale incluir a Slack en la lista de servicios que necesitan un plan B documentado, del mismo modo que WhatsApp Web también ha caído de forma significativa en 2026.

Por qué los SaaS de comunicación caen — y cómo fallan

Para entender por qué el Slack caído se propaga tan rápido, es útil saber cómo se construye este tipo de servicio. Slack, Microsoft Teams, Discord, WhatsApp y similares son sistemas de "conexiones de larga duración": cada cliente mantiene una conexión WebSocket abierta con el backend todo el tiempo. Esto da la sensación de tiempo real, pero crea puntos de fallo que los sitios web tradicionales no tienen.

Los tres modos clásicos de fallo

1. Saturación de cola de mensajes. Cuando el broker (generalmente Kafka, RabbitMQ o similar) se obstruye, los mensajes no desaparecen, pero llegan tarde. Es exactamente el síntoma de "latencia severa" que Slack reportó el 27/05.
2. Tormenta de reconexiones. Si el servicio cierra conexiones para reiniciar, todos los clientes intentan reconectar al mismo tiempo. La "manada atronadora" puede mantener el servicio de rodillas durante 20 a 40 minutos después de que la causa raíz ya se haya resuelto.
3. Degradación en dependencia crítica. Slack depende de S3 para archivos, de bases de datos relacionales para metadatos, de CDNs para imágenes. Una falla de AWS US-East-1, por ejemplo, puede aparecer como "Slack caído" aunque Slack no tenga ningún bug.

No se puede saber, desde fuera, cuál de estos caminos afectó a Slack el 27/05. El lenguaje oficial ("investigando") indica que los ingenieros aún buscaban la causa raíz cuando escribí este texto. Pero el patrón de síntomas — latencia amplia, varios subsistemas afectados — encaja en 1 o 3.

Por qué la página de estado siempre se retrasa

Una queja recurrente cuando Slack cae es: "la página de estado estaba verde". Hay una razón técnica para ello. Toda página de estado tiene un retraso deliberado: si se actualizara con cada parpadeo, estaría parpadeando en rojo todo el día. La regla interna suele ser "error sostenido durante X minutos en Y% de la base". En incidentes que comienzan regionales y crecen, este umbral retrasa el reconocimiento. Conclusión práctica: no confíes solo en la página de estado oficial — combínala con Downdetector y con tu propio monitoreo.

Impacto real: los equipos remotos se paralizan cuando Slack cae

Quien nunca ha vivido un Slack caído en horario laboral subestima el efecto. En empresas que adoptaron remote-first en los últimos cinco años, Slack no es "una herramienta" — es el pasillo de la oficina, la sala de reuniones, el tablón de anuncios y la cola de "hola, ¿puedo interrumpirte?". Cuando desaparece, tres cosas suceden al mismo tiempo:

• Las decisiones se paralizan. Las aprobaciones que dependen de un mensaje rápido del gestor quedan retenidas.
• La atención al cliente se detiene. Quien usa Slack Connect para soporte de cuentas grandes simplemente no puede responder.
• La ingeniería pierde contexto. PRs, despliegues, alertas de producción — todo pasa por bots de Slack. Sin el canal, el equipo se entera del siguiente incidente por Twitter.

El costo financiero varía, pero estimaciones internas que he visto en consultoría rondan entre R$ 80 y R$ 300 por colaborador por hora ociosa, dependiendo del rol. Una empresa de 200 personas con 1 hora de Slack caído consume fácilmente R$ 30.000 en productividad desperdiciada.

El efecto "silencio incómodo"

Tiene un efecto psicológico curioso. Cuando Slack cae, los equipos intentan el mismo canal repetidas veces antes de migrar a otro. Vi esto en el incidente del día 14: la gente tardó 25 minutos en abrir un grupo de WhatsApp porque "Slack volverá en cualquier momento". No volvió. Y en esos 25 minutos, nadie produjo nada.

Qué hacer mientras Slack está caído (checklist práctico)

En medio de un incidente, el cerebro del equipo entra en pánico leve. Para evitarlo, tu empresa necesita un runbook claro. Esto es lo que suelo recomendar como mínimo viable:

1. Confirma que es Slack, no tu red. En orden: abre downdetector.com/status/slack, luego status.slack.com, luego pregunta en otro canal. Si solo tú ves el problema, probablemente sea tu Wi-Fi, VPN o proxy corporativo.
2. Avisa en el canal de respaldo acordado. No improvises. Ten un grupo de WhatsApp, Telegram o Signal pre-creado con los 5–10 contactos críticos: liderazgo, on-call, soporte senior. Úsalo solo en estos momentos.
3. Cambia el estado de atención al cliente. Si usas Slack para chat con cliente externo, publica inmediatamente en tu sitio web, redes sociales y en la URA del teléfono: "Estamos experimentando inestabilidad en el canal de chat. Usa correo o WhatsApp".
4. Pausa workflows críticos. Las alertas de monitoreo que solo se disparan en Slack necesitan una ruta secundaria — PagerDuty SMS, correo o llamada automática.
5. Documenta lo que falló. Después del incidente, registra: hora de inicio (desde tu lado), hora en que lo notaste, hora en que cambiaste de canal, hora de vuelta. Esto vale oro en la próxima retrospectiva.
6. No fuerces reinicios masivos. Pedir a todos que cierren sesión y vuelvan a iniciar es lo que provoca la tormenta de reconexiones que mencioné arriba — retrasas la recuperación.

Comunicación con el cliente externo

Si tu empresa usa Slack como canal de soporte con cuentas corporativas (Slack Connect, canales compartidos), el impacto va más allá de ti. Ten una plantilla lista para enviar por correo y WhatsApp diciendo: "Somos conscientes de la inestabilidad de Slack. Para urgencias, responde a este correo o llama al [número]". Enviar esto en los primeros 10 minutos del incidente marca una gran diferencia en la percepción del cliente.

Cómo reducir la dependencia: redundancia de comunicación en la empresa

Depender de un único SaaS para comunicación interna es como ejecutar producción sin réplica de la base de datos. Funciona hasta que se detiene. La buena noticia es que la redundancia en comunicación es barata — generalmente solo cuesta tiempo de organización.

Principios prácticos

• Canal de respaldo elegido con antelación. WhatsApp y correo son los más obvios en España. Para equipos técnicos, Signal o Matrix funcionan bien porque tienen clientes de escritorio decentes.
• Directorio de contactos fuera de Slack. Mantén una hoja de cálculo (Google Sheets o similar) con nombre, función, móvil y correo de los 30 a 50 contactos críticos. Cuando Slack cae, nadie recuerda el WhatsApp del otro.
• Documentación fuera de Slack. Las decisiones importantes deben vivir en Notion, Confluence, Linear, Google Docs — no en mensajes efímeros. Nunca he tenido un post-mortem serio basado en scroll de Slack.
• Alertas con dos rutas. Cualquier alerta de producción sale por Slack y por SMS/PagerDuty/correo. Costo pequeño, valor enorme.

Cómo integrar WhatsApp como redundancia

Si tu elección es usar WhatsApp como canal de respaldo, hazlo a través de la API Oficial de WhatsApp para evitar el riesgo de bloqueo por volumen. Improvisar con WhatsApp Web en 50 cuentas personales es receta para suspensión. Otra ruta inteligente es centralizar atenciones críticas en una plataforma que permita agentes ilimitados sin costo por empleado, de modo que el canal de respaldo escale rápidamente cuando Slack caiga.

Cuándo vale considerar alternativas a Slack

No es porque el Slack caído se haya vuelto noticia varias veces en mayo que debas migrar mañana. La migración de chat corporativo es cara, dolorosa y típicamente lleva de 3 a 6 meses para una empresa de 200 personas. Pero vale la pena revisar la decisión si:

• Tu operación tiene ventana 24×7 y Slack ha tenido más de dos degradaciones graves por trimestre.
• Tu equipo ya está dentro del ecosistema Microsoft 365 — Teams puede ser "gratis" y simplificar la facturación.
• Necesitas "on-prem" o alojamiento en nube propia (Mattermost, Rocket.Chat).
• Tu mayor caso de uso es comunidad abierta, no equipo interno — Discord cubre mejor.

Lo más común, sin embargo, no es migrar. Es endurecer el uso actual: acordar redundancia, entrenar al equipo, documentar runbook. Las empresas que hacen esto sienten el Slack caído como un hipo, no como un apagón.

El caso de la IA dentro de Slack

Vale una nota sobre Slack AI y los resúmenes automáticos. Los dos incidentes de mayo que involucraron IA (día 8 con Huddles y día 18 con resúmenes) muestran que las funciones nuevas tienen bugs. Esto es normal. Pero, si estás pensando en apoyar procesos críticos en funciones de IA de Slack, considera el nivel de madurez — 2026 aún es pronto para tratarlas como producción firme. Haz pilotos y mantén un plan B humano.

Conclusión y próximos pasos

El Slack caído del 27 de mayo de 2026 pasará a la historia como un incidente más de latencia severa en una mala racha para la plataforma. Para tu equipo, lo que importa no es la causa raíz que Slack publicará en el post-mortem — es lo que cambias en tu operación el jueves por la mañana. Sal de esta lectura con tres acciones concretas: (1) crea o revisa el canal de respaldo acordado, (2) documenta el runbook de incidente de Slack y (3) revisa dónde tu operación quedó ciega en mayo. Cuando llegue el próximo incidente — y llegará —, esos 30 minutos de preparación valen cada céntimo.

Si la redundancia pasa por WhatsApp y tu empresa aún usa cuentas personales, vale la pena conversar: integrar la API Oficial bien hecha transforma el canal de respaldo en una estructura sólida. Es el tipo de proyecto que toca DNS, infraestructura, atención y CRM — y es exactamente lo que he estado haciendo con clientes de Agathas Web en los últimos años.

— Cleverson Gouvêa, CTO de Agathas Web