La caída global de Salesforce y la lección que sirve para cualquier SaaS
El 16 de septiembre de 2026 Salesforce se cayó en todo el mundo, justo en pleno Dreamforce, y la explicación que dio la compañía es casi doméstica: peticiones atascadas esperando la respuesta de un servicio interno de login que acabó consumiendo los recursos del servidor.
Qué pasó, en orden
El miércoles 16 de septiembre, segundo día del Dreamforce —celebrado del 15 al 17 en el Moscone Center de San Francisco—, los clientes empezaron a reportar retrasos severos, errores intermitentes y, en algunos casos, la imposibilidad de entrar en la plataforma. La compañía situó el inicio del incidente alrededor de las 07:50 UTC y en una actualización de las 11:27 UTC aseguró que el arreglo se estaba desplegando en toda su flota. El registro de estado recopilado por un monitor externo indica impacto mayor desde las 3:50 hasta las 11:26, hora del Este: unas siete horas y media, con el incidente marcado como resuelto. Es dato de monitor de estado, no informe oficial, y el análisis de causa raíz de la compañía sigue sin publicarse.
El segundo día del Dreamforce como telón de fondo
El evento estuvo centrado en la apuesta por la IA, con Agentforce como pieza central del mensaje de Marc Benioff. La coincidencia se puede señalar una vez y sin burla, pero el incidente no dice nada de ese producto: la causa publicada es un servicio interno de login.
Qué se vio desde fuera
Inicios de sesión que no entran, ruedas de carga sin fin, errores de API y retrasos severos. Según la prensa, la afectación alcanzó instancias de Core Service en Estados Unidos, Japón, India, Reino Unido, Francia y Alemania. Un análisis de red de ThousandEyes observó problemas de disponibilidad y respuestas con timeout durante la ventana del incidente.
Lee también
La causa inicial, en palabras de Salesforce
Lo que la compañía publicó fue concreto: las peticiones se quedaban atascadas mientras esperaban respuesta de un servicio interno de login, que iba consumiendo los recursos de servidor disponibles. No hay ningún elemento público que apunte a un ciberataque. Hasta que llegue el análisis de causa raíz, ninguna explicación es definitiva.
Por qué una sola dependencia puede tumbar todo
Imagina un edificio con una única puerta. Un día el guardia tarda más en dejar pasar a cada persona: la cola crece por el pasillo, los ascensores se llenan, el vestíbulo se bloquea y, sin que nada se haya roto, nadie entra ni sale. Eso es el agotamiento de recursos: no se acaba el disco ni la red, se acaban los hilos, las conexiones y la memoria de esperar. El login es la peor dependencia posible porque todos pasan por él; cuando sus peticiones se acumulan, el resto de servicios falla en cadena.
Qué revisar antes de la próxima caída de Salesforce
Ninguna de estas piezas es exótica y todas se añaden sin rehacer la arquitectura. La idea común es no esperar indefinidamente a nadie.
Límites de tiempo y cortacircuitos
Toda llamada a una dependencia necesita un timeout corto, un tope de reintentos con esperas crecientes y un cortacircuito que deje de llamar cuando la tasa de error se dispara. Un error rápido y honesto gana siempre a una cola infinita.
Aislamiento, modo degradado y observabilidad
Separa los grupos de recursos por servicio para que uno saturado no ahogue a los demás, define qué funciones siguen vivas al límite y apaga primero lo prescindible. Y mide antes de diagnosticar: sin métricas propias, la saturación se descubre cuando ya es una caída.
Qué hacer si dependes de un SaaS para operar
Desde el lado del cliente el margen es menor, pero existe. Ten un plan de contingencia para las horas sin CRM —qué hace el equipo, qué procesos esperan, quién avisa a los clientes— y guarda copias propias de los datos que necesitas para operar. Y no confundas la página de estado del proveedor con tu monitoreo: si tus usuarios no pueden entrar, tus métricas deberían decírtelo antes de que lo leas en una red social.
Otros tropiezos de la misma semana en la nube
El 17 de septiembre, un día después, Microsoft Copilot presentó una degradación del servicio: usuarios que recibían un mensaje genérico de error en lugar de una respuesta. La compañía lo listó como degradación en su panel y lo marcó como resuelto esa misma tarde, según varios medios que siguieron el incidente. Son episodios distintos y no conviene generalizar: la nube no está peor, sencillamente se ve todo lo que pasa dentro.
Conclusión
La caída de Salesforce no deja villano ni cifra de pérdidas: deja una lección de arquitectura. Las dependencias compartidas son por donde entra el agua; los timeouts, los cortacircuitos, el aislamiento y el modo degradado son las compuertas. Si mantienes software en la nube, es buen momento para revisar los cuatro. En el blog ya escribimos sobre monitoreo y registro en Laravel, rate limiting en una API Laravel y qué es un servidor VPS y cuándo lo necesitas.
