Tus servidores los puede apagar alguien con quien no has firmado nada

El 13 de agosto se quedaron sin servicio más de 5.000 servidores en un edificio de Phoenix, y con ellos las webs, el correo, los paneles de control y el DNS de miles de empresas repartidas por medio mundo. Ningún atacante, ningún CVE. La refrigeración de la sala dejó de dar de sí y hubo que apagar antes de que el calor se llevara el hardware. Lo llamativo del caso no es la avería: es que la orden de apagar no la dio la empresa a la que esos clientes le pagan.

Entre una asesoría de Sabadell con su web y su correo y la mano que decidió cortar la corriente había varias empresas, y ninguna había firmado nada con ella. Esa distancia es lo que nos interesa aquí, porque se puede medir antes de contratar y casi nadie la mide.

Treinta horas y media, con horas

La secuencia pública es esta. Durante la madrugada del 13 de agosto una tormenta afecta al centro de datos de RadiusDC en Phoenix. El parte técnico recogido por HostingJournalist es más específico que «una tormenta»: las temperaturas de sala suben tras varios microcortes de suministro eléctrico durante las tormentas nocturnas. A las 10:28 UTC se emite el primer aviso de temperatura del centro de datos. Los equipos se van retirando de servicio de forma escalonada durante las horas siguientes, más de 5.000 servidores en total.

Sobre si apagar estuvo bien no vamos a extendernos, porque ya defendimos esa postura en julio a cuenta de la caída de Google Cloud por energía y refrigeración: el apagado térmico es la decisión correcta, no la avería. Las guías térmicas de ASHRAE sitúan el rango recomendado de temperatura de entrada de aire entre 18 y 27 °C y el permitido para equipo de clase A1 entre 15 y 32 °C, y ese techo describe la condición en la que el fabricante verifica que aquello funciona, con la advertencia de que operar ahí de forma prolongada acorta la vida útil. Con la sala a plena carga y la mitad de las máquinas de frío paradas, seguir encendido era apostar a cuánto tardan en degradarse discos y fuentes.

La cadena por la que baja la orden

Todo el mundo tiene clara la respuesta corta a quién puede reiniciar sus servidores: yo, o mi proveedor si se lo pido. La lista larga es otra cosa. En Phoenix, por encima del cliente final estaban la agencia o el partner que le montó la web, el proveedor de alojamiento que le vendió el plan, phoenixNAP —que vendió el negocio del edificio y sigue dentro como inquilino, y que es quien publica el detalle técnico de lo que pasó— y RadiusDC, que gestiona la sala. Cuatro escalones por encima, ninguno con su teléfono.

Y el edificio había cambiado de manos hacía pocos meses. RadiusDC anunció el 12 de marzo el acuerdo para comprar el negocio de centro de datos y colocation de phoenixNAP en Phoenix, con cierre previsto para el segundo trimestre. Quien manda hoy en la sala donde vive tu hierro puede no ser quien mandaba cuando firmaste, y ese cambio no aparece en ninguna factura.

Que el operador del edificio tenga esa autoridad está bien: es quien ve los termómetros y quien responde si la sala arde. El problema es que esa autoridad no sale nunca en la conversación comercial, donde se habla de porcentajes de disponibilidad. Un porcentaje se responde con un número de folleto. La pregunta de quién puede apagarte se responde con nombres de empresas, y esos nombres cambian.

El DNS llegó más lejos que el edificio

Cuando el DNS de Namecheap dejó de responder se rompieron también sitios que no estaban alojados allí. Cualquier web del mundo cuyos servidores de nombres apuntaran a Namecheap dejó de encontrarse, daba igual dónde viviera. Una empresa que hubiera hecho los deberes —web en un proveedor, correo en otro, copias en un tercero— podía quedarse a oscuras igualmente, porque las tres cosas se localizan preguntando a la misma zona.

El DNS se concentra casi siempre por una razón que no es técnica: viene incluido. Compras el dominio, el registrador te regala la zona y ahí se queda. Nadie decide poner toda su resolución en un único proveedor; lo que ocurre es que nadie decide lo contrario, igual que pasa con las renovaciones de las que hablábamos en el post sobre los dominios .es caducados. El arreglo es de los baratos: el protocolo lleva desde siempre preparado para tener servidores de nombres secundarios en otro operador, y montarlo cuesta una tarde. Con un matiz que conviene decir, porque protege menos de lo que parece: eso mantiene viva la resolución, no el servicio. Si tu web está apagada, el DNS secundario responderá sin problema la dirección de una máquina que no contesta.

Lo que dicen los números, que no es lo que parece

Aquí conviene resistirse a la moraleja fácil de «revisa la refrigeración de tu proveedor». En el reparto de causas de caídas de servicio de TI que Network World extrae del análisis anual de 2026 del Uptime Institute, la refrigeración es la última de la lista con un 8 %, por detrás de red y conectividad (23 %), energía (21 %), sistema y software (18 %) y proveedores terceros (10 %). Para caídas de centro de datos en concreto, la energía se lleva el 45 % de las que tienen impacto. Phoenix es el caso raro, no el típico.

Lo cual refuerza el argumento en vez de debilitarlo. Una causa que explica ocho de cada cien caídas se llevó por delante 5.000 servidores durante día y medio, y alcanzó a empresas que ni siquiera tenían nada en ese edificio. Planificar por frecuencia no habría servido de nada. Del mismo informe salen dos cifras para la conversación con dirección: el 57 % de los encuestados dice que su última caída importante costó más de 100.000 dólares, y por segundo año consecutivo uno de cada cinco declara costes por encima del millón. La frecuencia por emplazamiento, mientras tanto, baja por quinto año seguido, y solo alrededor de uno de cada diez dice que su última caída tuvo impacto grave o severo. Con esas dos tendencias juntas se calcula un RTO y un RPO con números en vez de con adjetivos.

Tres preguntas sobre el edificio

Operamos infraestructura propia repartida en varios centros de datos, así que estas preguntas las hemos hecho y también nos las han hecho. Van sobre la cadena de mando, que es lo que no suele estar escrito en ningún sitio.

Cuándo esto no te hace falta

Vendemos colocation y planes de recuperación, así que este párrafo tiene interés de parte y lo decimos antes de escribirlo. Treinta horas de web caída no arruinan a todo el mundo. Si la web es un folleto con un formulario, el correo va por Microsoft 365 y no toca ese edificio, y el negocio se hace por teléfono y en el mostrador, montar un DNS secundario en otro operador merece la pena porque cuesta poco, y duplicar infraestructura en un segundo centro de datos no. Recomendar que no se duplique cuando la cuenta no sale es parte del trabajo, igual que hemos recomendado quedarse en VMware cuando tenía sentido.

La línea se cruza cuando el negocio no puede trabajar sin ello. Un almacén que no expide sin el ERP, una clínica que no pasa consulta sin las historias, una asesoría a final de trimestre. Ahí, día y medio parado se mide en facturación, y el precio de la redundancia deja de compararse con cero.

Llevamos semanas escribiendo aquí sobre versiones que caducan, avisos con plazo y fallos con su número asignado. Este no tiene número, ni boletín que suscribir, ni inventario que cruzar. Hubo una tormenta de verano sobre el desierto y un edificio que no pudo quitarse el calor de encima. El trabajo que sirve para esto se hace antes, y consiste sobre todo en saber dónde están tus cosas y quién manda en el sitio donde están, aunque no le hayas firmado nada.

Fuentes (verificadas el 16 de agosto de 2026): cronología del incidente (primer aviso de temperatura a las 10:28 UTC del 13-ago-2026, cierre a las 17:00 UTC del 14-ago-2026, 30 h 32 min en total, 11 h 42 min para el sitio principal, más de 5.000 servidores, lista de servicios afectados, efecto sobre sitios de terceros que resolvían por Namecheap, ausencia de pérdida de datos y anuncio de redundancia entre sus centros de datos de EE. UU., Europa y Asia), a partir de la página de estado y el comunicado de Namecheap recogidos por Cyber Kendra; parte técnico con los microcortes de suministro durante las tormentas nocturnas, afectación simultánea de Hosting.com y operación por la que RadiusDC se queda el negocio de centro de datos y colocation de phoenixNAP en Phoenix (anunciada el 12 de marzo de 2026, cierre previsto para el segundo trimestre; phoenixNAP continúa como inquilino), según HostingJournalist y la nota de prensa de la operación; dos de los cuatro enfriadores operativos hacia el mediodía (hora del Este) y uso de enfriadores temporales, según TechBarrista; rangos térmicos recomendado (18–27 °C) y permitido de clase A1 (15–32 °C) de las guías térmicas de ASHRAE TC 9.9; reparto de causas de caídas de servicio de TI (red 23 %, energía 21 %, sistema y software 18 %, terceros 10 %, refrigeración 8 %) y energía como causa del 45 % de las caídas de centro de datos con impacto, según la lectura de Network World del Annual Outage Analysis 2026 del Uptime Institute, de donde salen también el 57 % por encima de 100.000 USD, el 1 de cada 5 por encima de 1 M USD, el quinto año consecutivo de descenso por emplazamiento y el ~1 de cada 10 con impacto grave o severo. Discrepancia declarada: Cyber Kendra y TechBarrista atribuyen a RadiusDC la instrucción de retirar los sistemas de servicio; HostingJournalist la presenta como decisión de Namecheap. No hemos podido acceder al comunicado propio de Namecheap. Las citas en castellano de textos originalmente en inglés son traducción nuestra. La lectura sobre la cadena de autoridad del apagado, sobre la concentración del DNS y las tres preguntas son nuestras, no de las fuentes.