La página de status de Anthropic tiene demasiadas fallas registradas

Horacio Ontiveros Por Horacio Ontiveros
La página de status de Anthropic tiene demasiadas fallas registradas

La página de status de Anthropic tiene más fallas de las que he visto en cualquier proveedor de infraestructura crítica. Es la señal más visible de que las plataformas de IA están excedidas de demanda — y una razón concreta para tener visibilidad del uptime de tus propios servicios.

La página de status de Anthropic — la empresa detrás de Claude, uno de los modelos de IA más usados del mundo — muestra algo que no había visto antes en ningún proveedor de infraestructura crítica: una cantidad de fallas e interrupciones que convierte su historial de uptime en un semáforo permanente en naranja y rojo. claude.ai: 99.36%. Claude API: 99.42%. Claude Code: 99.34%. Números que suenan bien hasta que calculas lo que significan en tiempo real de caída.

Y esto no es un ataque a Anthropic. Es una señal de algo más grande que está ocurriendo en toda la industria.

¿Qué significa realmente 99.36% de uptime?

Los nueves en uptime importan. La diferencia entre 99% y 99.9% no es marginal — es un orden de magnitud:

Uptime Tiempo de caída al año Tiempo de caída al mes
99.9% ("tres nueves") 8.7 horas 43 minutos
99.5% 43.8 horas 3.6 horas
99.36% 56 horas 4.7 horas
99.0% 87.6 horas 7.3 horas

claude.ai con 99.36% de uptime significa casi 56 horas de caída al año. Más de dos días completos donde el servicio no estaba disponible — o estaba degradado — en los últimos 90 días.

Para un servicio de entretenimiento, eso es tolerable. Para una herramienta de la que dependen equipos de producto, desarrolladores y empresas que han integrado la IA en su operación diaria, eso es un problema operativo real.

Las plataformas de IA están excedidas — y lo están mostrando

No es solo Anthropic. Es el síntoma de una industria entera que creció más rápido de lo que su infraestructura puede sostener.

OpenAI tuvo incidentes mayores repetidos en 2024 y 2025. Google Gemini ha tenido degradaciones de servicio documentadas. Los proveedores de GPU en la nube — el recurso escaso que alimenta todos estos modelos — reportan listas de espera para capacidad adicional.

El crecimiento de la demanda de IA es exponencial. La capacidad de infraestructura crece de forma lineal. Esa brecha se manifiesta exactamente como lo que muestra la imagen: una página de status llena de interrupciones, degradaciones y incidentes que se vuelven la normalidad en lugar de la excepción.

Como analizamos en nuestro post sobre cómo la IA está rompiendo los contratos económicos del internet, las plataformas de IA están redefiniendo expectativas en todos los frentes — incluyendo las de disponibilidad y confiabilidad.

El uptime como métrica de negocio — no solo de ingeniería

Hay una creencia extendida de que el monitoreo de uptime es un problema de DevOps. Algo que resuelve el equipo técnico con una herramienta interna y que el resto de la empresa no necesita ver.

Esa creencia es cara.

Cuando tu sitio web cae, no te enteras por tu equipo técnico — te enteras porque un cliente te manda un mensaje preguntando qué pasó, o peor, porque descubres tres días después que estuviste caído durante horas sin que nadie lo notara. Cuando la API de la que depende tu producto falla, tus usuarios experimentan errores que atribuyen a tu producto, no al proveedor subyacente.

La visibilidad del uptime no es un lujo de empresas enterprise con SLAs formales. Es información básica que cualquier negocio que depende de su presencia digital necesita tener — en tiempo real, sin tener que ir a buscarla.

Tres preguntas que todo sitio web B2B debería poder responder ahora mismo

  • ¿Cuánto tiempo estuvo caído tu sitio web el mes pasado?
  • ¿Cuánto tardaste en enterarte la última vez que hubo una interrupción?
  • ¿Qué prospectos intentaron contactarte cuando el formulario de contacto no funcionaba?

Si no puedes responder estas preguntas, no tienes visibilidad de un riesgo que está ocurriendo ahora mismo, en tiempo real, mientras lees esto.

Lo construí porque lo necesitaba — y decidí hacerlo en Golang

Hace unas semanas identifiqué que necesitaba una herramienta de monitoreo de uptime para mis propios proyectos y los de mis clientes. Las opciones existentes son o demasiado complejas, o demasiado caras para lo que necesita una empresa B2B de tamaño mediano, o ambas.

Así que lo construí. En Golang — un lenguaje en el que tenía cero experiencia práctica — en dos días. Con arquitectura hexagonal, concurrencia con goroutines, WebSockets para actualizaciones en tiempo real, y deploy en Oracle Cloud ARM64.

El resultado es ATBaby.online: un monitor de uptime que verifica la disponibilidad de tus servidores y sitios web, registra el historial de incidentes y te notifica cuando algo cae. Sin complejidad innecesaria. Sin precios de enterprise para funcionalidad básica.

Y tiene un detalle que me parece relevante dado el contexto de este post: puedes incrustar el estado de cualquier servidor directamente en tu sitio web con una sola línea de HTML. Si tu infraestructura está operativa, tus visitantes lo ven. Si hay un incidente, también.

Transparencia de uptime como señal de confianza. Exactamente lo contrario de lo que vemos en la imagen que abre este post.

La ironía que cierra el argumento

Estoy usando un monitor de uptime construido en dos días para vigilar los mismos servicios de IA cuya inestabilidad inspira este post. claude.ai aparece en mi dashboard de ATBaby.online junto con los sitios de mis clientes.

Cuando Claude cae — y cae — me entero antes de que mis clientes lo noten. Eso es visibilidad operativa. Y es lo que cualquier negocio que depende de su presencia digital debería tener sobre sus propios servicios.

Explorar ATBaby.online →

About time, baby!

Conversación

Inicia sesión para participar en la conversación.