Namecheap dejó todos sus servicios caídos durante 15 horas tras perder la refrigeración en su centro de datos de Phoenix

El 13 de agosto de 2026, una fuerte tormenta dejó sin refrigeración el centro de datos RadiusDC Phoenix, las instalaciones que albergan lo que el propio análisis post mortem de Namecheap denomina «algunas operaciones esenciales de Namecheap». Las temperaturas subieron hacia niveles críticos y el operador indicó a Namecheap que desconectara los servicios por completo en lugar de arriesgarse a que el equipamiento se sobrecalentara y sufriera daños permanentes. Namecheap —un registrador y proveedor de alojamiento con 25 años de trayectoria— acató la indicación y todo se apagó a la vez: alojamiento compartido, VPS y dedicado, EasyWP, gestión de DNS, Private Email, facturación y el propio sitio web de la empresa.

El análisis post mortem, escrito por el CEO Hillan Klein al día siguiente, es franco sobre la cascada de fallos. Los clientes no podían gestionar registros DNS ni redirecciones. Muchos sitios web no estaban disponibles, iban lentos o devolvían errores; los sitios de EasyWP seguían arrojando errores de conexión a la base de datos incluso después de que el panel volviera; Private Email no podía ni enviar ni recibir. Fundamentalmente, el servicio de asistencia técnica funcionaba sobre la misma infraestructura averiada: durante quince horas los clientes no tuvieron chat en vivo, ni soporte por correo electrónico, ni forma alguna de contactar con una persona. La recuperación requirió enfriadoras temporales y reinicios escalonados, con el servicio completo restablecido aproximadamente a las quince horas.

El problema está en las credenciales de las instalaciones. RadiusDC Phoenix es un centro de datos de Nivel 3 «diseñado con un alto nivel de redundancia», y Namecheap señaló que nunca había experimentado algo así en sus 25 años de historia. Pero una calificación de Nivel certifica el edificio, no la arquitectura del inquilino: Namecheap había concentrado sus operaciones esenciales —y su plano de control de cara al cliente— dentro de ese único edificio, de modo que un fallo de refrigeración en una tormenta de Arizona inutilizó simultáneamente las interfaces de gestión, los canales de comunicación y los sistemas de ingresos.

15 horas de inactividad en alojamiento, EasyWP, gestión de DNS, Private Email y facturación; el servicio de asistencia también cayó, dejando a los clientes sin ningún lugar al que acudir

Las operaciones esenciales estaban concentradas en unas únicas instalaciones en Phoenix, de modo que el fallo de las instalaciones se convirtió en el fallo de Namecheap: ningún segundo sitio pudo mantener vivo el plano de control.

El servicio de asistencia funcionaba sobre la misma infraestructura averiada, así que los clientes con sitios caídos y correo detenido también perdieron la capacidad de pedir ayuda: un fallo de disponibilidad se convirtió en un fallo de comunicación.

No había un plan de continuidad para el plano de gestión: la gestión de DNS, la facturación y la administración de correo permanecieron caídas durante todo el incidente, aunque la resolución de zonas DNS en sí siguió funcionando.

La redundancia de Nivel 3 a nivel de las instalaciones enmascaró el punto único de fallo a nivel del inquilino; el análisis post mortem califica el suceso de sin precedentes en 25 años.

La insignia de Nivel 3 de unas instalaciones no es tu redundancia: mantén tu plano de control —gestión de DNS, correo, facturación, soporte— dependiente de un solo edificio y un solo fallo de refrigeración apaga todo a la vez.

La refrigeración se restableció con enfriadoras temporales dirigidas al área de Namecheap en las instalaciones, y los servicios volvieron progresivamente a medida que las temperaturas se estabilizaban; un escalonamiento que la empresa defendió como el único orden seguro. El análisis post mortem prometió implementar aún más redundancia en sus otros centros de datos en Europa y Asia. Namecheap también publicó una corrección: publicaciones tempranas en X habían culpado al operador equivocado, PhoenixNAP, cuando las instalaciones eran gestionadas por RadiusDC. La caída de quince horas provocó la indignación generalizada de los clientes, y la empresa reconoció públicamente «les fallamos».