La prueba de la caída tiene que salir del correo que estaba caído

Mientras escribimos esto, la caída de Microsoft 365 que empezó ayer por la tarde sigue abierta y sin hora estimada de vuelta. De eso ya hay cien crónicas. Vamos a la parte del dinero: esto se paga. El acuerdo de nivel de servicio contempla un crédito, pero no se abona solo, no se calcula con el reloj de la noticia y —si compraste tu Microsoft 365 a través de un tercero, como la mayoría de las pymes españolas— no eres tú quien lo pide. Y la prueba que Microsoft exige para pagarlo tiene que llegarle en un correo enviado desde el dominio del inquilino afectado. Es decir: desde el buzón que estaba caído.

Dónde estamos a las ocho de la mañana

Dos identificadores, que son los que importan para todo lo demás: EX1550543 para Exchange Online y MO1550821 para el resto de la suite. Empezó el jueves 12 por la tarde en hora europea, con usuarios que no podían conectar con sus buzones «a través de múltiples métodos de conexión» en América, y se extendió. La página de estado de Microsoft ha ido listando Exchange Online, Teams, SharePoint Online, Copilot, Defender, Planner, To Do, Intune, Purview y Power BI. Microsoft ha escrito que no hay indicios de actividad maliciosa, y que sigue investigando qué disparó los fallos.

De las actualizaciones de Microsoft hay tres frases que conviene guardar. La primera es una corrección de sí misma: determinó que la carga elevada no venía de un aumento general del tráfico, sino de que una gran cantidad de servidores estaba inesperadamente no disponible y fallaba las comprobaciones automáticas de salud. La segunda describe por qué esto dura, y esta sí entrecomillada: «los servidores que hemos devuelto al servicio pueden volver a quedarse sin responder una vez reciben tráfico». La tercera explica lo que ves tú: Microsoft está restringiendo temporalmente, en algunas ubicaciones, qué tipos de tráfico pueden llegar a la infraestructura afectada. De ahí que el acceso sea intermitente incluso en regiones que figuran como recuperadas. A las 04:10 GMT de hoy informaba de recuperación parcial en algunas regiones y añadía que esas acciones no estaban dando una recuperación sostenida.

Las dos lecturas técnicas que suele tocar hacer aquí ya están publicadas y no las vamos a repetir: por qué una lista de servicios caídos a la vez es un mapa de dependencias compartidas que te dan gratis, y por qué una máquina que vuelve al servicio y se cae al recibir tráfico es el problema del arranque y no el de la restauración. Hoy vamos a otro sitio, porque hay una parte de esta caída que tiene fecha de caducidad.

El crédito es un porcentaje de tu cuota, no una indemnización

Para Exchange Online, el SLA consolidado de servicios en línea compromete un 99,9% mensual y liquida los incumplimientos en crédito sobre la cuota de ese servicio. Los tramos son tres: por debajo del 99,9%, el 25%; por debajo del 99%, el 50%; por debajo del 95%, el 100%. El porcentaje de disponibilidad del mes no habla de horas, habla de personas: ((User Minutes − Downtime) / User Minutes) × 100, donde el tiempo caído es la suma, incidente a incidente, de los minutos que duró multiplicados por el número de usuarios a los que afectó.

Hagamos la cuenta de este mes. Noviembre tiene 30 días: 43.200 minutos por usuario. Sobre esa base, los tres umbrales del SLA quedan así:

Mira la fila del medio, porque ahí está el detalle que decide si esto vale una hora de papeleo o no: el salto del 25% al 50% está en 7 horas y 12 minutos. Una caída que arranca a media tarde y pasa de madrugada aterriza justo en ese umbral. Y el reparto por usuarios corta en los dos sentidos: si solo la mitad de tu plantilla se quedó sin buzón, tus user-minutes caídos se parten por dos y el mes no baja del 99% aunque el incidente dure lo mismo. No hay un porcentaje universal para esta caída. Hay el tuyo, y sale de tu plantilla y de tu reloj.

Dos aclaraciones antes de que nadie haga planes. La primera: el crédito se calcula servicio por servicio, y Microsoft lo ilustra con un ejemplo propio —si el cliente tiene una suite Office 365 pero solo sufrió una caída de SharePoint, el crédito se aprueba para SharePoint y no para el plan entero—. La segunda: un crédito nunca excede la cuota mensual de ese servicio, y el propio acuerdo dice que no se concede para compensar ninguna otra forma de pérdida, incluido el lucro cesante. Es un descuento en la factura de Microsoft. La aritmética de por qué un porcentaje de disponibilidad no te dice nada sobre cuánto dura una sola caída ya la desmontamos en octubre.

Lo que cuenta como caída está definido sobre Outlook Web Access

Esta letra pequeña ya la contamos en agosto con otro incidente —hay averías que te paran la oficina y que para el SLA no son una caída—, así que aquí va corta. El acuerdo define el tiempo caído de Exchange Online como «cualquier periodo de tiempo en el que los usuarios no pueden enviar o recibir correo con Outlook Web Access», el nombre antiguo de Outlook en el web. No dice el cliente de escritorio ni el móvil. Esta vez el aviso de Microsoft hablaba de buzones inaccesibles «a través de múltiples métodos de conexión», así que la web entra en el cómputo.

La prueba tiene que salir del correo caído

La documentación de Microsoft para los proveedores del programa CSP detalla qué hay que aportar, y ahí está el detalle que da título a esto. Literal: «aporta evidencia de que la caída afectó al cliente y de que este solicitó crédito de SLA. Hay que proporcionar el identificador del inquilino del cliente y el identificador de la caída (del panel de salud del servicio). El correo del cliente presentado como evidencia debe venir del dominio del inquilino afectado. (Un correo de una dirección personal no es aceptable)».

Léelo otra vez pensando en el jueves por la tarde. La petición de crédito por una caída de correo corporativo tiene que viajar por el correo corporativo. Si tu gente, con el buzón muerto, escribió desde su Gmail de siempre —que es exactamente lo que hace todo el mundo en una caída— esa evidencia no vale. No es una trampa ni una maldad: es una comprobación de titularidad bastante razonable desde el lado de Microsoft. Pero exige que alguien se acuerde de mandar ese correo desde el dominio, en cuanto el servicio dé un respiro, y antes de que el calendario cierre la puerta.

Y no basta con el correo. La misma página avisa de que «el nombre del cliente, el identificador de inquilino, el número de ticket del partner y la fecha y hora de creación del ticket no son suficientes para que una reclamación se procese», y lista qué es lo que sí prueba el impacto: información sobre la hora y la duración del tiempo caído; el número y las ubicaciones de los usuarios afectados «si procede»; descripciones de tus intentos de resolver el incidente en el momento en que ocurría; un correo del cliente afectado pidiendo soporte y después la aplicación del crédito; y el número de ticket con los detalles del contacto con el cliente.

Subrayamos la tercera porque es la que no se puede fabricar después. «En el momento en que ocurría»: qué probasteis, a qué hora, con qué resultado. Si nadie apuntó nada mientras pasaba, ese campo se rellena de memoria dos semanas más tarde, y de memoria todas las caídas duran «toda la tarde». Las otras cuatro cosas se pueden sacar de un sistema cuando haga falta. Esta hay que escribirla el mismo día.

Si compraste a través de un tercero, el que reclama no eres tú

Esta es la parte que descoloca a casi todo el mundo, y es una frase sola: «las solicitudes de crédito se aceptan únicamente de proveedores directos e indirectos del programa CSP. No se aceptan solicitudes de revendedores indirectos». Si tienes contratado Microsoft 365 con la empresa de informática del polígono —que es el caso de media España— esa empresa puede ser perfectamente un revendedor indirecto, y entonces Microsoft no le acepta la reclamación a ella tampoco: tiene que subirla su mayorista, el proveedor indirecto que está por encima.

Así que la cadena real de esta caída tiene tres saltos: tú escribes a quien te factura, quien te factura escribe a su mayorista si no puede presentarla él, y el mayorista abre el ticket en Partner Center con tu evidencia dentro. En cada salto puede perderse el identificador, el GUID del inquilino o —sobre todo— el correo que tenía que salir de tu dominio. Nosotros no vendemos licencias de nadie, así que en esta cadena no somos quien te factura: somos quien documenta el incidente y persigue que la reclamación suba con todo dentro. El papeleo de un tercero no es una excusa aceptable cuando el plazo lo pone un calendario.

El plazo: 31 de diciembre

El propio acuerdo lo deja con un ejemplo que no admite interpretación: la reclamación tiene que llegar a Microsoft «al final del periodo siguiente al mes en que ocurrió el incidente», y lo ilustra así —si el incidente fue el 15 de febrero, la reclamación tiene que estar presentada antes del 31 de marzo—. Aplicado a esto: incidente del 12 de noviembre, puerta cerrada el 31 de diciembre de 2026. La documentación del canal dice lo mismo con otras palabras —dos meses desde el final del mes de facturación para Azure, un mes para todos los demás servicios—. La vía para quien compra directo es el centro de administración, en Soporte, abriendo una nueva solicitud de servicio y pidiendo crédito de SLA con el identificador del incidente dentro. Pasada la fecha no hay apelación posible: no es que te lo denieguen, es que ya no existe.

El cuaderno de la caída: seis campos, hoy

Esto es lo que hacemos nosotros mientras un proveedor está caído, y no tiene nada de sofisticado. Es un documento compartido, abierto en el minuto uno, con seis campos. Lo escribe quien está de guardia, no quien luego reclama:

1. Tu hora de inicio y tu hora de vuelta, con el reloj de tu casa. En una reclamación lo que cuenta es cuándo lo viste tú; la hora en que el fabricante lo reconoce suele ser bastante posterior.
2. Cuántas personas y dónde. Número y ubicaciones. La fuente lo pide «si procede», y procede siempre que se pueda contar. «Toda la empresa» no es un número.
3. Qué se intentó, con hora. Outlook de escritorio, Outlook en el web, móvil, otra red, otro navegador, reinicio de sesión. Esta es la lista que no se puede reconstruir luego.
4. El identificador del incidente y el GUID del inquilino, copiados de tu propio centro de administración. El prefijo de dos letras dice el servicio: EX Exchange Online, SP SharePoint, MO portal. Aquí: EX1550543 y MO1550821.
5. El historial del incidente, exportado, no enlazado. Las actualizaciones del panel de salud cambian de redacción mientras el incidente vive y acaban archivadas; el PDF o la captura de hoy es tu versión fechada.
6. El correo de solicitud, enviado desde una dirección de tu dominio, pidiendo soporte y el crédito, con los dos identificadores dentro. Es el campo que caduca y el único que depende de que el servicio te dé una ventana.

Seis campos, un cuarto de hora repartido a lo largo del incidente. Y un efecto secundario que vale más que el crédito: ese mismo cuaderno es el informe que te van a pedir el lunes en dirección, y es la base de la conversación sobre qué canal alternativo tiene tu empresa cuando el correo no está. Nosotros lo montamos dentro del soporte gestionado precisamente porque en una caída de proveedor no hay nada que arreglar: solo hay que decidir qué se para, avisar por un canal que siga vivo y dejar escrito lo que pasó.

Cuándo no merece la pena

Si eres diez personas con un plan básico, haz la cuenta antes de ponerte: el 25% de un mes de un solo servicio para diez licencias es una cifra que no paga ni la hora de quien rellena el formulario. Decirlo así nos quita trabajo, pero es la verdad. Y hay un error peor que no reclamar, que es dejar que el papeleo se coma la respuesta: si tienes que elegir entre documentar la caída y abrir el canal alternativo para que la gente siga trabajando, se abre el canal. El cuaderno aguanta quince minutos de retraso sin perder nada por el camino.

El caso contrario es el que nos encontramos más a menudo, y es el que de verdad justifica los seis campos: si tu empresa tiene su propio acuerdo de nivel de servicio firmado con sus clientes —cualquier empresa de software lo tiene—, ayer no eras solo la víctima de una caída ajena. Eras también el proveedor de alguien, y ese alguien te va a preguntar por escrito qué pasó, cuántos de sus usuarios se quedaron fuera y qué hiciste mientras pasaba. Las tres respuestas están en el mismo cuaderno. La diferencia entre tenerlo y no tenerlo no es el crédito de Microsoft: es si tu versión de ayer tiene horas o tiene adjetivos.

Nadie monta su continuidad encima de un descuento, y el canal alternativo y la lista de lo que se para cuando el correo no está se trabajan antes de la siguiente caída, no durante. Pero de todo lo que dejó la tarde de ayer, esta es la única pieza con un número, un dueño y una fecha de vencimiento. Si gestionamos nosotros tu Microsoft 365, el cuaderno es parte del servicio y la solicitud sale con los dos identificadores dentro. Si no, el correo que hay que mandar empieza por «solicito el crédito de SLA correspondiente a los incidentes EX1550543 y MO1550821», sale de una dirección de tu dominio y tiene hasta el 31 de diciembre.

Fuentes (verificadas el 13-nov-2026, 08:00 CET). Microsoft Learn, «Request a credit from Microsoft - Partner Center»: la frase de que solo se aceptan solicitudes de proveedores directos e indirectos de CSP y no de revendedores indirectos; los plazos (dos meses para Azure, un mes para el resto desde el final del mes de facturación); la lista de información requerida y la de evidencia de impacto; el requisito de que el correo del cliente venga del dominio del inquilino afectado y que una dirección personal no sea aceptable; la advertencia de que nombre, GUID y número de ticket no bastan; el ejemplo de la suite con caída solo de SharePoint; la nota sobre incidentes advisory y sobre que una entrada del panel indica que un inquilino podría estar afectado; y la tabla de prefijos de dos letras. SLA consolidado de Microsoft para servicios en línea (edición Worldwide English de 1-ene-2026, leída en el PDF): 99,9% mensual para Exchange Online, fórmula del porcentaje de disponibilidad sobre user-minutes, definición de tiempo caído como «cualquier periodo de tiempo en el que los usuarios no pueden enviar o recibir correo con Outlook Web Access», tramos de crédito del 25/50/100%, tope de la cuota mensual del servicio con la cláusula de que no compensa ninguna otra forma de pérdida incluido el lucro cesante, y la regla de plazo con su ejemplo propio (incidente del 15 de febrero, reclamación antes del 31 de marzo). Actualizaciones del propio incidente EX1550543 / MO1550821 publicadas por Microsoft en el centro de administración y en su página pública de estado, recogidas por la cobertura del 12 y 13 de noviembre de SecurityWeek y de la prensa del sector (las tres frases citadas, la lista de servicios afectados, el descarte de ataque y el estado de las 04:10 GMT). La lectura de la cadena de reventa y los seis campos del cuaderno son nuestros. Nota honesta: el porcentaje que le corresponde a cada inquilino depende de su propio cómputo de user-minutes, que Microsoft calcula con su definición de tiempo caído; nada de lo anterior garantiza un crédito concreto.