White Paper
Juan Velasco7 min readNovember 12, 2026Cuando se cae Exchange Online: qué le pasa a tu automatización y cómo diseñarla para sobrevivirlo
El 12 de noviembre de 2026 Microsoft reportó una degradación en Exchange Online que dejó a miles de usuarios sin acceso a su buzón. Una persona lo nota y espera; un workflow no: falla, o peor, se queda a medias. Esto es lo que rompe realmente y cómo se diseña automatización que sobrevive a una caída del proveedor.
resiliencia
Microsoft 365
Exchange Online
automatización
workflows
operaciones
Resumen ejecutivo. El 12 de noviembre de 2026 Microsoft confirmó una degradación en Exchange Online que afectó el acceso a buzones a través de múltiples métodos de conexión en el continente americano. Para un usuario humano, esto significa "Outlook no abre". Para un sistema de automatización agéntica, significa algo bastante peor: procesos que fallan a mitad de camino, side effects ya comprometidos que no se pueden deshacer, y cursores de ingesta que pueden avanzar sobre mensajes que nunca se procesaron. Este artículo documenta el incidente, explica los tres modos de falla reales y describe los mecanismos concretos que Arcanflows™ expone para recuperarse sin duplicar ni perder trabajo.
1. El incidente
| Campo | Detalle |
|---|---|
| Servicio afectado | Exchange Online (buzones de Outlook), con reportes adicionales sobre Microsoft 365 y Copilot |
| Alcance | Múltiples métodos de conexión (Outlook web, cliente de escritorio, móvil) en América |
| Inicio reportado | 12 de noviembre de 2026, ~10:17 AM CST |
| Estado al cierre de esta nota | Microsoft continuaba investigando; sin hora de resolución confirmada en las fuentes consultadas |
| Magnitud | Miles de usuarios reportando fallas durante la tarde del jueves |
El aviso oficial de Microsoft 365 Status fue explícito sobre el alcance: "We're investigating reports of users experiencing issues accessing Exchange Online mailboxes through multiple connection methods in the Americas". La prensa recogió el mismo cuadro — Outlook y Copilot degradados para miles de personas — y en foros de administración se citó el mensaje de Service Health con la marca de inicio: "Service degradation… Start time: Nov 12, 2026, 10:17 AM CST. Users may be unable to connect to their mailboxes".
⚠️ Nota de vigencia. El estado de un incidente cambia minuto a minuto. La fuente autoritativa no es X ni Downdetector: esadmin.microsoft.com→ Health → Service health, donde aparece el ID de incidente y los updates oficiales.
2. Por qué la automatización sufre más que las personas
Un humano frente a Outlook caído hace lo correcto: refunfuña y espera. No tiene estado que corromper.
Un workflow no puede esperar. Está corriendo ahora, con un grafo de nodos a medio ejecutar, y tres cosas pueden salir mal de formas muy distintas:
Modo 1 — Falla dura (ruidosa, y por eso la menos peligrosa)
El nodo de correo recibe
503 ServiceUnavailable, un timeout, o 429 con retry del lado de Graph. La ejecución se marca como fallida, aparece en el historial, alguien la ve. Duele, pero es visible. Es el caso benigno.Modo 2 — Éxito parcial silencioso (el que de verdad cuesta dinero)
El flujo tiene cinco pasos: leer buzón → clasificar → crear registro en CRM → enviar confirmación al cliente → mover el mensaje a carpeta. La degradación pega en el paso 4.
Resultado: el registro ya se creó en el CRM, la confirmación no salió, y el mensaje sigue en la bandeja de entrada. Si alguien reejecuta el flujo desde el principio sin pensar, el registro se duplica. Este es el escenario que separa una plataforma de automatización de un script con cron.
Modo 3 — Deriva del watermark (pérdida silenciosa de datos)
Los ingestores de correo por sondeo mantienen un cursor: "ya procesé todo lo recibido hasta esta marca". Si el cursor avanza cuando la lectura falló, esos mensajes quedan en un limbo permanente: no se procesaron y nunca se volverán a intentar. Nadie se entera hasta que un cliente pregunta por el correo de hace tres días.
3. Qué hace Arcanflows™ al respecto
3.1 Retry y Resume from failed step son cosas distintas — y la elección importa
La plataforma expone dos recuperaciones, y confundirlas es la causa número uno de duplicados tras un incidente externo:
| Retry | Resume from failed step | |
|---|---|---|
| Qué hace | Crea una ejecución nueva desde el trigger, con los mismos datos de entrada | Continúa la misma ejecución desde el paso que falló |
| Pasos ya completados | Se vuelven a ejecutar | Conservan su resultado registrado y no se reejecutan |
| Side effects previos | Pueden duplicarse (correos, registros, llamadas) | No se duplican |
| Endpoint | POST /api/v1/workflow-executions/{id}/retry | Disponible en la lista de ejecuciones, junto a Retry |
| Cuándo usarlo | Cuando el fallo fue de configuración o de datos de entrada | Cuando el fallo fue transitorio y externo |
Regla práctica para una caída del proveedor: usa Resume, no Retry. El changelog de la plataforma lo confirma en los criterios de aceptación: un paso fallido corregido y reanudado completa la ejecución sin reejecutar los pasos anteriores; reanudar una ejecución ya terminada devuelve
409. Y la guía de usuario es explícita sobre el porqué: "steps that already completed keep their recorded results and are not executed again, so emails, records and calls they produced are not duplicated. Fix the step first if its configuration was the cause, then resume."3.2 El watermark de ingesta no avanza si la lectura falla
El sondeo de buzón usa
last_polled_at, guardado por credencial y carpeta. Cuando la llamada a Graph falla, el cursor no se mueve: la siguiente corrida vuelve a pedir el mismo rango y recupera el hueco. Es la defensa directa contra el Modo 3.Detalle operativo que vale la pena conocer: en la primera corrida, sin marca previa, el sondeo toma por defecto las últimas 24 horas.
3.3 Historial de ejecuciones de tareas programadas
GET /api/v1/scheduled-tasks/{id}/executions devuelve las ejecuciones recientes de una tarea. Durante un incidente es lo primero que hay que abrir: te dice cuántas corridas fallaron, en qué ventana, y cuáles están pendientes de reanudar.3.4 Workflow Doctor para el diagnóstico con evidencia
Cuando el síntoma es difuso — "mi workflow a veces falla", "hace algo raro" — el Builder incluye un especialista que lee el grafo del workflow, su validación y el log de ejecución real, nodo por nodo, con los errores y los datos de la última corrida fallida, y devuelve un diagnóstico basado en evidencia. Es la diferencia entre adivinar y saber qué nodo se rompió y con qué payload.
4. Checklist: qué hacer durante una degradación del proveedor
Durante el incidente
- Confirma en la fuente oficial, no en redes:
admin.microsoft.com→ Health → Service health. - No toques configuraciones locales. Si la degradación es del proveedor, reprovisionar perfiles o recrear credenciales solo agrega ruido y puede dejar configuraciones a medias.
- Revisa el historial de ejecuciones de las tareas programadas que dependen del servicio caído.
- Marca las ejecuciones fallidas para Resume, no para Retry, si ya tenían pasos con side effects completados.
- Pausa lo que no sea crítico. Una tarea que corre cada 5 minutos contra un servicio degradado solo acumula ejecuciones fallidas y consume cuota de reintentos.
Al restablecerse el servicio
- Reanuda desde el paso fallido las ejecuciones marcadas.
- Verifica el hueco de ingesta: confirma que la primera corrida posterior al incidente trajo los mensajes del periodo caído.
- Reconcilia side effects si en algún momento se usó Retry: busca duplicados en CRM, correos dobles, registros repetidos.
Como diseño permanente (esto es lo que de verdad importa)
- Idempotencia en los nodos de escritura. Que crear el registro dos veces no produzca dos registros.
- Retry con backoff en llamadas externas, y un tope de intentos: reintentar infinitamente contra un servicio caído no lo arregla.
- Separa lectura de confirmación de lectura. El cursor solo avanza cuando el procesamiento terminó, no cuando la lectura empezó.
- Sigue las buenas prácticas de scheduling documentadas por la plataforma: evita horas pico, no programes con más frecuencia de la necesaria, y agrega lógica de reintento en workflows programados.
5. La lección de fondo
Ninguna plataforma de automatización puede evitar que Microsoft, Twilio o tu CRM se degraden. Lo que sí puede hacer es garantizar que, cuando eso pase, el resultado sea una ejecución fallida visible y reanudable en lugar de datos duplicados o perdidos en silencio.
Esa es la diferencia operativa entre "IA que conversa" e IA que ejecuta procesos de negocio reales: la segunda tiene que asumir que el mundo externo falla, y diseñarse en consecuencia.
Referencias de plataforma
- Guía de usuario · Workflows → Resuming a failed run
- Guía de usuario · Builder → Skills: capabilities the Builder bundles for an agent (Workflow Doctor)
- Workflows → Error Handling (Schedule Best Practices)
- CHANGELOG (criterios de aceptación de resume/retry)
- API:
POST /api/v1/workflow-executions/{id}/retry,GET /api/v1/scheduled-tasks/{id}/executions
Arcanflows™ es una marca solicitada de Windconsul Tech LLC. Versión de plataforma referida en la documentación vigente: v1.1.17.0.