Caída de Microsoft 365: qué falta en tu plan de continuidad

Tu aplicación carga. La base de datos funciona bien. Un cliente pulsa el botón que debería permitirle continuar y se queda esperando un correo que no llega.

El panel de monitorización indica que el producto está disponible. Para el cliente, es inutilizable. La caída de Microsoft 365 del 12 y 13 de noviembre de 2026 reveló una carencia en los planes de continuidad del correo: tu aplicación puede funcionar mientras el siguiente paso depende del buzón de otra persona.

Para consultar el estado actual de Outlook y Microsoft 365, acude a la página de estado de Microsoft.

Lo útil es seguir una tarea hasta que se completa. Tu independencia de un proveedor depende de que las personas puedan recibir el mensaje, entrar en la aplicación, tomar la decisión y contactar contigo si algo falla. Tener el servidor bajo tu control solo resuelve una parte del recorrido.

Una caída de Outlook puede bloquear la recepción de solicitudes de soporte

El viernes por la mañana, CloudTree avisó a sus clientes de que no recibía los correos de soporte. Para problemas técnicos ajenos a la caída, les pidió que llamaran para que su agente telefónico pudiera abrir una incidencia. A las 14:03, CloudTree comunicó que sus cuentas de Microsoft se habían vuelto a conectar y que esperaba recuperar la recepción de incidencias por correo, aunque seguiría vigilando la situación.

Ese detalle revela un problema mayor. La avería había eliminado una vía para comunicar al proveedor otra avería. Un cliente podía tener un problema de alojamiento distinto y encontrarse sin el canal habitual para avisar.

Piensa en tu propio negocio. Que la cola de soporte funcione solo sirve si la solicitud consigue llegar a ella. Un formulario que reenvía los mensajes al mismo buzón averiado puede parecer un segundo canal y acabar en el mismo destino bloqueado.

La alternativa tiene que hacer llegar el problema al equipo. Alguien responde a la llamada, lo registra en un lugar al que el equipo puede acceder y ofrece al cliente una forma de consultar su evolución. Publicar un número de teléfono es el principio. Decidir quién puede usarlo y qué ocurre después es lo que lo hace útil.

Por eso, el aviso de una incidencia debe explicar qué acción está afectada. «Nuestros servidores están operativos» obliga al cliente a adivinar si debe esperar, volver a intentarlo o contactar con alguien. «El correo de soporte lleva retraso; usa esta vía para problemas urgentes» le permite decidir.

Un segundo proveedor de correo no puede abrir el buzón del destinatario

Puedes cambiar tu propio servicio de correo y seguir necesitando comunicarte con un cliente que usa Microsoft 365. Su infraestructura de recepción sigue formando parte del intercambio.

El aviso de Bright Software Group mostró ese límite: sus aplicaciones y su servicio independiente de envío de correo funcionaban, pero la entrega a destinatarios que utilizaban servicios de Microsoft estaba afectada. Que sus propios sistemas funcionaran no eliminaba la dependencia del lado receptor.

En una startup, esa distinción cambia lo que significa una métrica de correo. Que una tarea termine en tu aplicación demuestra que el código ha llegado a ese punto. Que un servicio de envío acepte un mensaje demuestra que se ha completado otra etapa. Ninguna de esas observaciones confirma que el destinatario pueda abrir su buzón y actuar.

Imagina este ejemplo de un proceso de selección: preparas una invitación a una entrevista, tu proveedor de envío la acepta y el buzón del candidato está inaccesible. La invitación sigue necesitando respuesta. Cambiar de proveedor de envío no puede devolverle al candidato el acceso a su buzón.

No puedes controlar la infraestructura de cada destinatario. Sí puedes decidir qué da por hecho tu producto después de enviar un mensaje. ¿La pantalla afirma que se ha avisado a la persona? ¿El plazo empieza a contar de inmediato? ¿Puede encontrar la invitación dentro de su cuenta tras identificarse, o el correo contiene la única vía de acceso?

Son decisiones de producto. Merecen tanta atención como los reintentos y la configuración del servidor de correo, porque determinan si un mensaje retrasado acaba convirtiéndose en una obligación incumplida.

El acceso, los calendarios y el soporte comparten algo más que un logotipo

Las actualizaciones de la Universidad de Bath mostraron otro tipo de dependencia. En su investigación inicial indicó que las funciones básicas de Teams parecían funcionar y que la autenticación no parecía afectada, mientras el personal no podía acceder a Outlook. La universidad también señaló efectos en TOPdesk y en su CRM de candidatos porque dependían de Outlook para el correo; el aviso advertía de posibles fallos al programar reuniones, enviar invitaciones y realizar acciones en el calendario.

Lo relevante es que la avería no se extendió de manera uniforme. Algunas funciones seguían disponibles mientras se interrumpía el trabajo relacionado con ellas. Una etiqueta general como «Teams no funciona» o «Microsoft funciona» habría ocultado la distinción que las personas necesitaban para organizar su jornada.

Al revisar tus dependencias, mira también más allá del nombre del proveedor. Usar una sesión ya abierta, iniciar sesión de nuevo, restablecer una contraseña y aceptar una invitación a una cuenta son recorridos distintos. Uno puede funcionar mientras otro espera un correo.

Una segunda herramienta de colaboración puede estar disponible para el personal que ya tiene la sesión abierta, pero exigir un código por correo a quien accede desde un dispositivo nuevo. Una página de estado puede ser pública y, aun así, necesitar el servicio de identidad afectado para publicar una actualización. Un canal alternativo que depende del canal averiado para entrar ofrece menos posibilidades de las que su nombre sugiere.

Comprueba estos recorridos con las personas que realmente los usarían. Que el fundador tenga una sesión abierta en el navegador no demuestra que un cliente nuevo o un compañero de soporte autorizado puedan entrar. Anota la acción concreta que falla, en lugar de clasificar toda la aplicación como disponible o no disponible.

Organiza el plan de continuidad del correo en torno al trabajo

Un plan de continuidad del correo empieza por el trabajo que no puede esperar: una entrevista prevista para hoy, una solicitud urgente de soporte o una aprobación con una fecha límite real. Comprar una segunda herramienta para cada función añade sistemas que un equipo pequeño debe mantener; solo ayuda si las personas pueden completar esas tareas.

Para cada una, describe brevemente cómo se completa. Incluye a la persona que recibe el mensaje y el acceso que necesita. Los siguientes ejemplos sirven para planificar; no describen fallos observados durante esta incidencia:

La propia guía de Microsoft para mitigar incidentes recomienda mantener vías paralelas de correo, teléfono y SMS cuando la respuesta a incidentes depende de Exchange. Aplica la misma comprobación a los procesos de tus clientes: ¿puede la alternativa llegar a la persona adecuada sin pasar por el buzón inaccesible?

La alternativa puede ser una pausa deliberada. Si no puedes autenticar a alguien de forma segura sin su buzón, explica el retraso y conserva su lugar en el proceso. Una caída no justifica improvisar comprobaciones de identidad ni conceder acceso a partir de un mensaje sin verificar.

Nuestro ensayo de continuidad sin el fundador comprueba si un compañero autorizado puede trabajar sin él. Aquí la pregunta es otra: ¿puede completar la tarea cuando falta un canal de comunicación del que depende? Importan tanto la autorización como la posibilidad de acceder a la infraestructura.

La recuperación termina cuando se resuelve el trabajo pendiente

En una declaración recogida por la BBC a las 16:51 GMT del 13 de noviembre, Microsoft atribuyó la incidencia a un problema surgido durante una ampliación anterior de la capacidad de red que se manifestó tras un cambio reciente en ella. Afirmó que no guardaba relación con actividades maliciosas ni con IA o agentes, que el problema subyacente se había corregido y que la restauración continuaba. El informe completo posterior a la incidencia seguía pendiente.

Cualquier explicación de la causa debe ceñirse a ese relato. Pero tu equipo tiene otra pregunta que resolver durante la recuperación: ¿qué ha pasado con el trabajo que esperaba esos mensajes?

Cuando vuelva el acceso, revisa las obligaciones pendientes antes de dar por recuperada la jornada. En tus propios procesos, busca solicitudes sin respuesta, enlaces caducados y citas modificadas por otro canal. Concilia los registros provisionales con el sistema habitual para que los compañeros no actúen sobre versiones contradictorias.

Después, cambia una suposición concreta que hayas descubierto. Haz que la invitación se pueda consultar fuera del correo. Asegúrate de que la alternativa de soporte llegue por una vía independiente. Explica que un mensaje está pendiente de entrega en vez de dar a entender que el destinatario ya ha actuado.

El panel puede decirte cuándo funciona tu aplicación. Para saber si funciona tu negocio, sigue al cliente más allá del botón de enviar.