BookinglyTech News
Infraestructura

Microsoft revierte un cambio de configuración que dejó SharePoint en blanco

El fallo impidió cargar sitios y páginas de SharePoint Online durante casi hora y media el 16 de septiembre y quedó registrado como incidente SP1472983.

2 min de lecturaThe Register0 vistas

Microsoft revirtió un cambio de configuración que dejó a parte de sus clientes sin poder cargar sitios y páginas de SharePoint Online. La interrupción se prolongó entre las 16:04 y las 17:30 GMT del 16 de septiembre, según el seguimiento del incidente, que la compañía registró como SP1472983. Los afectados se topaban con un mensaje de error en lugar de su contenido: "Lo sentimos, algo ha ido mal: el subproceso se ha anulado".

La causa, según la propia Microsoft, fue un cambio en la manera en que sus servidores entregan el código que se usa para renderizar las páginas de SharePoint. La compañía revirtió la modificación y aseguró que la telemetría del servicio confirmaba que el problema estaba resuelto. En su comunicación añadió que está revisando "el proceso mediante el cual validamos y desplegamos los cambios de configuración para que futuros despliegues no provoquen un impacto similar".

Un patrón conocido

No es la primera vez que un cambio de configuración tumba un servicio en la nube de Microsoft. A principios de este año, un problema en Azure se propagó a servicios que dependían de él, y otro cambio en Microsoft 365 hizo caer una parte considerable de la suite de productividad. En 2025, una modificación similar dejó a usuarios sin acceso a Exchange Online a través de Outlook en la web. Entonces un portavoz de la compañía declaró que estaban trabajando para mejorar la detección de ese tipo de eventos y reducir el tiempo necesario para identificarlos, mitigarlos o prevenirlos.

En esta ocasión Microsoft no ha respondido a las peticiones de más detalle. Sí ha comprometido un informe preliminar del incidente en dos días hábiles y uno definitivo en cinco.

El episodio se suma a una lista de fallos que comparten un mismo origen: algo que se despliega en producción y que no debería haber llegado ahí en ese estado. Para quien opera servicios críticos sobre la plataforma, lo relevante no es solo la duración de la caída, sino la frecuencia con la que el mecanismo de validación previo deja pasar cambios defectuosos. Detectar rápido es la mitad del trabajo; la otra es no romper. Y en el caso de Microsoft, esa segunda mitad sigue dando señales de flaqueza, igual que Windows Update continúa produciendo una ristra de problemas que deberían haberse detectado antes de salir. Queda por ver qué dicen los informes prometidos y si esta vez vienen acompañados de algún cambio real en el proceso de despliegue.