En la mañana del 31 de agosto de 2026, Outlook y Microsoft 365 (el antiguo Office 365) dejaron de enviar y recibir correo para un número de empresas que la propia Microsoft nunca reveló por completo. Downdetector, el servicio que rastrea fallas en tiempo real, registró más de 5.000 reportes de problemas solo hasta comienzos de la tarde, según TechCrunch. Horas antes, Microsoft ya había reconocido el caso internamente, bajo el código EX1464935.
La causa, según la propia empresa, fue una falla en un componente de autenticación usado por la infraestructura de Exchange Online, el servicio detrás de las bandejas de entrada de Microsoft 365. El problema no se quedó solo en el correo: alcanzó también a Teams, SharePoint, OneDrive y otros servicios que usan el mismo inicio de sesión corporativo. El acceso a la bandeja de entrada volvió a la normalidad para la mayoría unas 12 horas después, pero algunas funciones solo se recuperaron por completo tres días más tarde, el 3 de septiembre.
Para quien trabaja con tecnología, fue un incidente más registrado. Para la empresa que esa mañana no podía enviar una factura, confirmar un pedido o responder a un cliente que reclamaba un plazo, fue un día de trabajo perdido, y la pregunta que quedó fue por qué nadie sabía qué hacer.
Esa es la pregunta que le interesa a quien decide en una empresa, no el detalle técnico de la falla. El dueño del negocio no necesita entender qué es un componente de autenticación. Necesita saber qué hace el equipo en las primeras horas de una caída, y es justamente eso lo que suele faltar.
Cuando el proveedor de correo se cae
No fue un episodio aislado. El 13 de mayo de 2026, una falla distinta derribó Outlook específicamente en América del Sur: Downdetector recibió 711 reportes de problemas en Outlook y más de 270 en Microsoft 365 en pocas horas, según Canaltech. Microsoft atribuyó el caso a un tramo de su propia infraestructura de red en la región, lo que interrumpió el servicio de forma intermitente para usuarios de Brasil y países vecinos.
Los dos episodios tienen algo en común: la causa no fue un ataque ni un error de quien usa el sistema. Fue una falla dentro del proveedor, del tipo que ningún contrato elimina por completo, solo reduce la probabilidad y el tiempo de vuelta. Esto vale para cualquier proveedor de nube, no solo para Microsoft, y también vale para quien mantiene el correo en un servidor dentro de la propia empresa: la cuestión no es qué camino es más seguro, es que ninguno de los dos es infalible.
Lo que hace que estas caídas sean distintas de cualquier otro imprevisto de TI es lo que pasa por el correo: pedido de cliente, factura, contrato firmado, cobro y, con frecuencia, la contraseña de recuperación de otros sistemas que la empresa usa a diario. Cuando se detiene, no es solo una herramienta que queda fuera de servicio. Es el canal por el que la empresa habla con quien le paga.
Y el correo rara vez se cae de forma que avise. Deja de funcionar por dentro, sin aviso en pantalla, mientras la persona sigue escribiendo una respuesta que nunca va a salir, y recién nota el problema cuando el cliente llama a preguntar por qué no recibió nada. Ese retraso entre la caída real y el momento en que la empresa la nota es, muchas veces, la parte más cara de todo el incidente.
Por qué nadie sabía qué hacer
Cuando el correo se cae, el primer problema rara vez es técnico: es de decisión. Nadie sabe decir si la falla es de la conexión contratada, del proveedor de nube o solo de la computadora de una persona, y cada hipótesis pide un camino de solución distinto. Mientras la duda no se resuelve, nadie llama a nadie, y el cliente del otro lado sigue sin respuesta.
Una estrategia de continuidad tiene que considerar distintos escenarios de falla.
El problema de fondo suele ser la ausencia de un plan. Según una encuesta de la aseguradora estadounidense Nationwide con dueños de pequeñas y medianas empresas, publicada en febrero de 2025, el 21% de ellas no tiene ningún plan de continuidad de negocio, aun cuando casi el 90% revisa otras políticas de riesgo con regularidad. La brecha queda justo en el punto donde más cuesta: en medio de un imprevisto real.
Contar solo con el proveedor de nube para resolverlo todo es otro error común. Él se ocupa de su propia infraestructura, pero no sabe a quién, dentro de la empresa, hay que avisar primero, ni qué pedido quedó esperando confirmación. Esa parte siempre es de la empresa, con o sin plan escrito para ella.
Tampoco sirve esperar el problema para descubrir a quién llamar. Muchas empresas pequeñas tienen un contacto de TI solo para cuando algo ya se rompió, sin nadie vigilando la red antes de eso, y es justamente esa falta de seguimiento continuo la que convierte una caída de pocas horas en un día entero de incertidumbre.
Lo que tiene que existir en la práctica
Una TI bien cuidada no evita toda caída; acorta la confusión y el tiempo detenido cuando ocurre una. Eso depende de mecanismos concretos, no de suerte:
Un canal alternativo ya acordado. Teléfono, WhatsApp corporativo o un aviso en el sitio web, definido de antemano y no improvisado en el momento, para avisar a cliente y proveedor que el correo está caído y que el pedido no se perdió.
Alguien que confirme la causa en minutos, no en horas. Un único responsable, interno o contratado, que sepa diferenciar una falla de la conexión, del proveedor de nube o de una computadora específica, sin que todo el equipo se quede adivinando.
Cuentas y listas con copia, no bandejas individuales aisladas, para pedidos, cobros y contratos, de modo que la información no quede atrapada en una única bandeja fuera de servicio.
Monitoreo que detecta la caída antes que el equipo. Cuanto antes alguien lo sepa, más rápido entra en acción la comunicación alternativa.
Un ticket registrado con causa y solución para cada incidente, para que el mismo problema no vuelva a sorprender a la empresa la próxima vez.
Un inventario simple de lo que la empresa usa y de qué depende de qué. Sin eso, nadie sabe de memoria qué más se cae junto con el correo, y la lista de a quién avisar primero se arma en el peor momento.
Así es como trabaja Skills IT: con monitoreo constante de la red, un único punto de contacto para confirmar la causa de un problema, y el ticket siempre registrado, para que la próxima caída encuentre a la empresa más preparada que la anterior.
La ganancia de decidir esto antes de la caída
El retorno de tener este plan listo no aparece solo el día del incidente: aparece en el tiempo que la empresa deja de perder tratando de descubrir qué hacer. Con un canal alternativo ya acordado, el cliente recibe un aviso en minutos, en vez de concluir por su cuenta que fue ignorado. Con alguien que identifica la causa rápidamente, el equipo sigue trabajando en otro frente mientras el correo no vuelve, en vez de quedar todo detenido esperando un veredicto.
También es una cuestión financiera, incluso sin una cifra exacta: cada hora de indecisión es una hora de personal parado, pedidos sin confirmar y retrabajo cuando todo vuelve a la normalidad y hay que reconstruir lo pendiente. La empresa con plan decide rápido; la empresa sin plan decide después, tarde, y bajo presión del cliente del otro lado de la línea.
Hay además una ganancia que solo aparece después, en la segunda vez. Una empresa que ya registró cómo resolvió la última caída no parte de cero en la siguiente: sabe a quién avisar, sabe a quién llamar para confirmar la causa, sabe dónde mirar primero. El aprendizaje de un incidente se convierte en un tiempo de respuesta menor en el siguiente, y eso es lo que separa a quien trata cada caída como una novedad de quien la trata como una rutina ya conocida.
Una guía para el día en que el correo se caiga
Nadie escribe un plan de continuidad en medio de una caída. Tiene que existir antes, aunque sea simple:
- Elija el canal alternativo ahora. Teléfono, WhatsApp o un aviso en el sitio web: acuerden cuál es y dónde queda anotado, para no decidirlo durante el problema.
- Defina quién confirma la causa. Una persona, interna o contratada, que sepa verificar si es la conexión, el proveedor de nube o una computadora específica, y no deje eso para "a ver quién lo descubre primero".
- Ponga los procesos críticos en cuentas con copia. Pedidos, cobros y contratos no pueden depender de una sola bandeja de entrada.
- Escriba los primeros tres pasos de la próxima caída. Quién avisa al cliente, quién confirma la causa, quién registra lo que pasó, por escrito, hoy, no de memoria después.
- Revise el plan después de cada incidente, incluso los pequeños. Eso es lo que separa a la empresa que aprende de la que repite el mismo susto.
