Hay quien lleva desde el lunes sin poder buscar en Microsoft 365. Para el SLA, eso no es una caída

Desde el lunes 17 de agosto hay gente que escribe una palabra en la caja de búsqueda de Outlook, de SharePoint Online o de OneDrive y no le sale nada. El aviso está en el centro de mensajes de Microsoft 365 con el identificador MO1456424, y el último parte que hemos podido leer fijaba la siguiente revisión para hoy viernes a las 04:00 UTC. Mientras tanto, ese fichero se sigue abriendo si sabes dónde está y ese correo se sigue enviando y recibiendo. Y ahí está el detalle que nos interesa: bajo las definiciones de caída que usa el propio contrato de Microsoft, esto no ha ocurrido.

Qué dice el parte, palabra por palabra

El título del aviso es tan literal que casi no hace falta traducirlo: «Some users may be unable to search for content in SharePoint Online, OneDrive, Outlook on the web, or Outlook desktop». El alcance está acotado con cuidado: «Impact is specific to some users served through the affected infrastructure who are attempting to search for content in SharePoint Online, OneDrive, Outlook on the web, or Outlook desktop». Léelo despacio, porque importa para lo que viene después: esto no le pasa a todos los inquilinos y depende de en qué trozo de infraestructura de Microsoft esté tu buzón.

La causa que da Microsoft cabe en una línea: «A recent deployment introduced a resource utilization inefficiency issue, leading to impact». Un despliegue propio que dejó los sistemas de indexación y recuperación de contenido comiendo más recursos de la cuenta. Ni ataque ni tercero ni nada que parchear en tu lado, y hay que reconocerle a Microsoft que lo dice así, sin disfrazarlo de «actividad inusual». Es la clase de avería que en tu propio centro de datos habrías resuelto revirtiendo el cambio en veinte minutos, y que aquí se arregla cuando le toca a tu clúster en la cola del despliegue del arreglo. Lo que sigue no va del aviso, que está bien escrito. Va de lo que pasa con él después.

Leer, escribir, enviar, recibir: buscar no está en la lista

El SLA de servicios en línea de Microsoft no promete «que el servicio funcione». Promete un porcentaje mensual de tiempo de actividad, y para calcularlo define, servicio por servicio, qué cuenta como Downtime. Merece la pena leer los tres que salen en el aviso, en la edición del 10 de agosto de 2026 del documento consolidado. SharePoint Online: «Any period of time when users are unable to read or write any portion of a SharePoint Online site collection for which they have appropriate permissions». Exchange Online: «Any period of time when users are unable to send or receive email with Outlook Web Access». OneDrive para la empresa: «Any period of time when users are unable to view or edit files stored on their OneDrive for Business».

Leer, escribir, enviar, recibir, ver, editar. Ahora pon MO1456424 al lado. Los usuarios afectados pueden leer sus documentos y escribir en ellos, mandan correo y les llega el correo, ven sus ficheros de OneDrive y los editan. Lo único que no pueden hacer es encontrar, y ese verbo no aparece en ninguna de las tres definiciones. Nuestra lectura: cinco días de buscador inútil suman cero minutos de caída. El contador de disponibilidad de agosto se queda exactamente donde estaba.

Y no es una trampa de Microsoft, que es el punto que suele molestar. Cualquier SLA operable necesita una definición binaria de caída, porque hay que medirla con un reloj y multiplicarla por usuarios afectados —el propio documento cuenta el Downtime en user-minutes—. En cuanto admites «el servicio va lento» o «el servicio va, pero mal», el contrato deja de poder calcularse y empieza a discutirse, y un contrato que se discute no sirve para nada. El precio de esa claridad es que lo que se cuenta y lo que duele acaban siendo dos cosas distintas.

Y aunque contara, el crédito hay que pedirlo

Supongamos por un momento que sí contara. La compensación del SLA llega en forma de crédito sobre la cuota del servicio afectado, y va por tramos. Por debajo del 99,9 % y hasta el 99 %, un 25 %. Por debajo del 99 % y hasta el 95 %, un 50 %. Por debajo del 95 %, el 100 %. Conviene hacer la cuenta una vez para no volver a hacerla nunca: un mes de 31 días tiene 44.640 minutos, así que bajar del 99,9 % pide 44 minutos y medio de caída medida, y bajar del 99 %, 446 minutos, siete horas y cuarto largas.

Y el crédito no cae solo. Hay que reclamarlo con la información del incidente, y hay plazo: el propio SLA pone como fecha límite el final del mes natural siguiente a aquel en que ocurrió el incidente, y lo ilustra con un ejemplo que no deja lugar a dudas —«if the Incident occurred on February 15th, we must receive the claim and all required information by March 31st»—. Alguien de tu casa tiene que reunir las pruebas y abrir el caso para recuperar un porcentaje de la cuota de un servicio. Casi nadie lo hace, y no es dejadez: es que la hora que cuesta vale más que lo que recuperas.

Escribimos hace unas semanas que un RTO no se decide, se mide, y que no debería firmarse ningún número que no se haya cronometrado antes en un ensayo. Aquí el problema es anterior: el número del contrato ni siquiera está midiendo la capacidad que se ha caído. Cuánto tiempo puede estar tu empresa sin poder buscar, y qué hace durante ese tiempo, es una pregunta que el crédito de servicio no responde.

Tu monitorización mide lo mismo que el SLA

Aquí es donde el asunto deja de ser una queja sobre Microsoft y pasa a ser un problema de casa. Casi todas las comprobaciones sintéticas que se montan contra un SaaS preguntan lo mismo que pregunta el SLA: ¿responde? Un inicio de sesión, un HTTP 200, un correo de prueba que va y vuelve. Todas esas comprobaciones han estado en verde toda la semana, porque todas esas cosas funcionaban.

La comprobación que sí lo habría cazado es aburrida de montar y por eso casi nunca está: una búsqueda conocida contra un contenido fijo, que devuelve un número de resultados que tú controlas. Un documento testigo en un sitio de SharePoint con una palabra rara que no aparece en ningún otro sitio, y una consulta programada que dice «esto tiene que devolver exactamente 1». Técnicamente no tiene misterio, aunque tampoco es gratis: hay que registrar una aplicación en Entra, darle permisos sobre la API de búsqueda de Graph y dejar un trabajo programado ejecutándose. Lo que cambia es la pregunta que le haces al sistema, que pasa de «¿estás vivo?» a «¿sigues sabiendo lo que sabías ayer?».

Seamos honestos con el alcance de todo esto: enterarte antes no arregla la búsqueda, y una copia de seguridad tampoco. Nadie del departamento legal va a ponerse a rebuscar un contrato en la consola de un backup porque el buscador vaya flojo tres días. Donde la segunda vía sí decide algo es un escalón más arriba, el día que el problema no es el índice sino el acceso al inquilino entero, y de eso ya escribimos: la copia que Microsoft guarda de tus datos nunca sale de Microsoft. Son dos riesgos distintos y conviene no mezclarlos para vender el segundo con el susto del primero.

Cuándo esto no es tu problema

Toca la parte que no vende: para mucha gente esto es una molestia y nada más. Si tu equipo trabaja con carpetas ordenadas, rutas conocidas y correo de los últimos treinta días, un buscador flojo durante unos días es incómodo y se pasa. Montar una plataforma de búsqueda alternativa por un incidente de cinco días sería tirar dinero, y no vamos a recomendarlo.

La pregunta que sí cambia las cosas es más concreta: ¿hay algún proceso vuestro que se pare si nadie puede buscar? Un departamento legal que localiza contratos por cliente. Un servicio de atención que busca el hilo de correo del último pedido. Una respuesta a un requerimiento con plazo, donde hay que localizar todo lo relacionado con una persona o un asunto. Si la respuesta es «ninguno», enhorabuena y cierra esta pestaña. Si la respuesta es «ese», ya sabes cuál es tu proceso frágil, y lo has averiguado gratis mirando la avería de otro.

Es la misma idea que defendimos hablando de otra cosa completamente distinta: la alta disponibilidad no evita la caída, la acorta. Ninguna arquitectura te promete que no pase nada. Lo que se decide de antemano es cuánto dura y qué haces mientras dura.

La pregunta que no se hace en la renovación

En las mesas de renovación se pregunta siempre «¿qué SLA tenéis?», y siempre se contesta un número con tres nueves que no dice nada por sí solo. La pregunta útil es incómoda justo por eso: ¿qué define exactamente tu proveedor como caída, y qué degradaciones quedan fuera de esa definición? Vale para Microsoft y vale para cualquiera que te venda un servicio gestionado, nosotros incluidos. Nadie va a reescribir un SLA por ti; lo que sí puedes es saber dónde está el hueco antes de necesitarlo, y decidir con la cabeza fría si lo cubres o lo asumes.

Qué haríamos esta semana

• Mirar el centro de mensajes, no la prensa. Si alguien de la casa se queja de que «Outlook no busca», el sitio donde confirmar si te ha tocado es el estado del servicio de tu propio inquilino. MO1456424 no afecta a todos los inquilinos, y saber si estás dentro o fuera cambia la respuesta que das a tus usuarios.
• Escribir la respuesta antes de la siguiente vez. Dos líneas para el servicio de asistencia: qué está pasando, qué se puede hacer mientras tanto (filtros de carpeta, ordenar por fecha, la ruta directa al sitio de SharePoint) y qué no hace falta que prueben. Ahorra la mitad de los tickets.
• Añadir una comprobación de resultado, no de respuesta. Un documento testigo con una palabra única, una consulta programada contra la API de búsqueda y una alerta si el número de resultados deja de ser el esperado. Es una tarde de trabajo contando el registro de la aplicación y los permisos, y es la única forma de enterarte antes que la persona que abre el ticket.
• Listar los procesos que dependen de buscar. No los sistemas: los procesos. Media hora con las personas que los ejecutan y sabrás si esto era una molestia o un riesgo. En la mayoría de sitios el resultado es tranquilizador; en los que no, ya sabes por dónde seguir.
• Guardar el aviso. Si algún proceso con plazo se vio afectado, el parte de Microsoft con su identificador y sus fechas es la prueba de que la causa fue del proveedor. Cuesta cero guardarlo hoy y no se puede reconstruir en noviembre.

Con suerte, cuando leas esto el buscador ya vuelve a encontrar cosas y MO1456424 está cerrado. El hueco entre lo que promete el contrato y lo que necesita tu gente sigue exactamente donde estaba.

Fuentes (verificadas el 21 de agosto de 2026): el identificador MO1456424, el título del aviso, la frase sobre el alcance y la causa «A recent deployment introduced a resource utilization inefficiency issue, leading to impact», del aviso de degradación de servicio republicado por el soporte de NHSmail y de la cobertura de BleepingComputer del 18 de agosto. El inicio de los avisos el lunes 17 de agosto, la confirmación de que no se trata de un ciberataque y la hora del siguiente parte (viernes 21 de agosto, 04:00 UTC), de Cyber Security News. Las tres definiciones de Downtime (SharePoint Online, Exchange Online y OneDrive para la Empresa), la medición en user-minutes, los tramos de crédito de servicio, el plazo de reclamación y su ejemplo del 15 de febrero, del SLA consolidado de servicios en línea de Microsoft, edición del 10 de agosto de 2026 (enlace directo al documento; el índice de descargas lista también el resto de idiomas). La lectura de que una búsqueda rota no encaja en ninguna de esas definiciones es nuestra y se declara como tal en el texto; la aritmética de los 44 minutos y medio y los 446 minutos sale de aplicar los porcentajes a los 44.640 minutos de un mes de 31 días. Las citas se dejan en inglés, su idioma original, para que se puedan verificar palabra por palabra.