El 15 de mayo de 2026, Anthropic registró tasas de error elevadas en Claude Opus 4.6 y Opus 4.7 a partir de las 00:26 UTC, con impacto en miles de usuarios reportado en Downdetector y resolución oficial confirmada a las 22:25 UTC del mismo día, después de aproximadamente 196 minutos de degradación severa del servicio.
En 30 segundos
- El incidente empezó el 15 de mayo a las 00:26 UTC y afectó los modelos Opus 4.6 y Opus 4.7 de Claude.
- Duración estimada de la degradación crítica: 196 minutos según el historial de status.claude.com.
- Miles de usuarios reportaron fallas en Downdetector durante el pico del outage.
- El servicio volvió a operar con normalidad a las 22:25 UTC del mismo día.
- Quienes usan la Claude API en producción sin retry logic tuvieron pérdida total de funcionalidad durante ese período.
Claude es un modelo de lenguaje grande desarrollado por Anthropic que asiste en tareas de procesamiento de texto, análisis y generación de contenido. Se accede a través de API y aplicaciones web.
Claude Status Update: Qué pasó el 14-15 de mayo 2026
El status.claude.com registra el inicio del incidente el 15 de mayo de 2026 a las 00:26:28 UTC. La descripción oficial fue “Elevated error rates on Opus 4.6 and 4.7”, lo que en términos prácticos significa que las solicitudes a la API empezaron a fallar con mayor frecuencia de lo normal, sin llegar necesariamente a un corte total pero con una tasa de error lo suficientemente alta como para romper workflows que no tienen manejo de errores robusto.
La resolución oficial llegó a las 22:25 UTC del mismo día. Eso da una ventana de algo más de tres horas de degradación severa, aunque el impacto real para distintos usuarios varía según la región, el tipo de plan y si tenían implementado algún mecanismo de retry.
Downdetector, que agrega reportes de usuarios en tiempo real, mostró un pico claro de incidencias durante esa ventana. Miles de reportes, lo que indica que no era un problema puntual de configuración sino degradación a nivel de infraestructura. ¿Fue un outage total? No exactamente. Fue lo que la industria llama “elevated error rates”: el servicio técnicamente seguía respondiendo, pero con suficiente inestabilidad como para que cualquier aplicación en producción se cayera si no tenía fallbacks.
Opus 4.6 vs Opus 4.7: Historia de errores y regresiones en 2026
Que el incidente haya afectado a ambos modelos al mismo tiempo dice algo sobre la arquitectura subyacente, pero también pone sobre la mesa una conversación que viene dando vueltas en la comunidad de developers desde que Opus 4.7 se lanzó.
Opus 4.6 tuvo sus propios problemas en abril de 2026, principalmente relacionados con cambios en verbosidad que rompieron algunos prompts optimizados para respuestas cortas. Opus 4.7 llegó después con dos novedades que no a todos les cayeron bien: un costo un 35% mayor y nuevos comportamientos inesperados en parámetros como budget_tokens y pérdida de contexto en conversaciones largas. Varios developers documentaron regresiones y directamente volvieron a Opus 4.6 como solución temporal.
| Modelo | Lanzamiento | Costo relativo | Issues documentados 2026 |
|---|---|---|---|
| Claude Opus 4.6 | 2026 (Q1) | Base | Cambios de verbosidad en abril; afectado en incidente mayo |
| Claude Opus 4.7 | 2026 (Q2) | +35% vs 4.6 | Bugs en budget_tokens, pérdida de contexto, afectado en incidente mayo |
Lo que no queda del todo claro es si el incidente del 15 de mayo fue específico de la arquitectura compartida entre ambos modelos o si fue un problema de infraestructura más amplio que los afectó por ser los modelos más demandados. Anthropic no publicó un postmortem detallado al cierre de esta nota.
Cómo verificar el estado de Claude en tiempo real
Hay tres formas de saber si Claude está teniendo problemas antes de pasarte media hora debuggeando tu código pensando que el error es tuyo (que pasa más seguido de lo que se admite). Ya lo cubrimos antes en cuando trabajas con Claude Code a escala.
status.claude.com — la fuente oficial
Es la página oficial de Anthropic para el estado de sus servicios. Muestra el historial de incidentes, el estado actual por componente y te permite suscribirte a notificaciones por email. Si hay un problema activo, va a aparecer ahí primero.
Downdetector y StatusGator — para triangular
Downdetector agrega reportes de usuarios en tiempo real. Es útil para confirmar que un problema es real y no solo tuyo, especialmente cuando Anthropic todavía no actualizó su página de status. StatusGator permite monitorear múltiples servicios y configurar alertas en Slack o por webhook. Si tenés Claude integrado en producción, estas herramientas deberían estar en tu stack de monitoreo.
La diferencia entre un outage total y “elevated error rates” importa en la práctica: un outage total significa que la API no responde. Elevated error rates significa que responde, pero falla en un porcentaje suficientemente alto como para que tu aplicación se rompa si no tiene manejo de errores. El incidente del 15 de mayo fue el segundo tipo.
Errores comunes en Claude API: Códigos y soluciones
Ponele que tu aplicación empieza a tirar errores durante un incidente como este. Antes de asumir que es tu código, estos son los códigos que vas a ver y qué significan cada uno:
| Código HTTP | Significado | Recuperable | Acción |
|---|---|---|---|
| 500 | Error interno del servidor de Anthropic | Sí (temporal) | Retry con exponential backoff |
| 529 | API sobrecargada (overloaded) | Sí (temporal) | Retry con espera más larga |
| 429 | Rate limit superado | Sí | Reducir frecuencia de requests, revisar límites del plan |
| 401/403 | Error de autenticación/autorización | No (requiere acción manual) | Verificar API key, permisos del proyecto |
| 400 | Request mal formado | No (error del cliente) | Revisar el payload de la request |
Durante el incidente del 15 de mayo, los errores más frecuentes reportados fueron 500 y 529, ambos del lado del servidor y ambos recuperables con una estrategia de retry adecuada. La documentación oficial de troubleshooting de Claude detalla cómo manejar cada uno de estos casos.
Estrategias de retry y resilience para la Claude API
Este incidente es un recordatorio de algo que muchos equipos aprenden tarde: si usás Claude en producción sin retry logic, cualquier degradación de servicio te tira la aplicación. Relacionado: en nuestro análisis de confiabilidad.
La estrategia estándar es exponential backoff: primer retry a 1 segundo, segundo a 5, tercero a 10, cuarto a 30. Máximo 4-5 reintentos antes de fallar con gracia. La clave está en diferenciar qué errores son recuperables (500, 529, 429) de cuáles no lo son (400, 401, 403). Para los segundos, no tiene sentido hacer retry: el problema es de configuración, no de disponibilidad.
Subís el request, te devuelve 529, esperás un segundo, volvés a intentar, otro 529, esperás cinco segundos, el tercero sale bien. Si el incidente duró 196 minutos y tu retry máximo llega a 30 segundos, igual vas a tener períodos sin servicio. Para casos críticos, el fallback real es tener un modelo alternativo configurado (por ejemplo, Sonnet en vez de Opus) o una respuesta cacheada para los casos de uso más comunes.
Impacto real para desarrolladores y empresas
¿Alguien cuantificó el impacto real? De forma independiente, todavía no hay datos publicados. Pero el volumen de reportes en Downdetector y la cobertura en medios como GV Wire sugiere que el incidente afectó a decenas de miles de usuarios durante el pico.
Para equipos con workflows de LLM en producción, tres horas de degradación en el modelo más capaz de Anthropic es un problema serio. Las aplicaciones que usan Opus para tareas de alta complejidad (análisis de contratos, generación de código, agentes autónomos) no pueden simplemente bajar a un modelo más pequeño sin perder calidad.
Los casos más afectados: cualquier pipeline que haga requests sincrónicos sin timeout adecuado, aplicaciones SaaS que exponen Claude directamente a sus usuarios, y workflows de procesamiento batch que se quedaron a mitad de ejecución durante el incidente.
Monitoreo proactivo: Configurar alertas antes del próximo incidente
El problema de depender únicamente de status.claude.com es que Anthropic suele actualizar la página algunos minutos después de que el problema ya empezó. Para producción, lo que funciona mejor es una combinación: Para más detalles técnicos, mirá como se compara con la competencia.
- Suscripción a notificaciones de status.claude.com (email o webhook RSS).
- StatusGator integrado con Slack para alertas en tiempo real en el canal del equipo de ingeniería.
- Métricas propias de tu aplicación: tasa de error en requests a la API, latencia P99, y una alerta si la tasa de éxito cae por debajo del 95% en una ventana de 5 minutos.
- Un SLA interno explícito que diga qué hace tu sistema cuando Claude no responde: ¿falla con mensaje de error? ¿usa respuesta cacheada? ¿cae a modelo alternativo? Si esto no está documentado antes del incidente, lo vas a improvisar durante él.
Si tu infraestructura está en la nube y usás webhooks o funciones serverless para integrar Claude, revisá también los timeouts configurados. Muchos incidentes “menores” se amplifican porque la función espera 30 segundos sin respuesta antes de fallar, lo que genera colas de requests bloqueados.
Qué está confirmado y qué no
| Aspecto | Estado |
|---|---|
| Inicio del incidente: 15 mayo 2026, 00:26 UTC | Confirmado (status.claude.com) |
| Modelos afectados: Opus 4.6 y Opus 4.7 | Confirmado (status.claude.com) |
| Resolución: 22:25 UTC del mismo día | Confirmado (status oficial) |
| Duración total del incidente: ~196 minutos | Confirmado según historial del status |
| Causa raíz del incidente | No confirmado (Anthropic no publicó postmortem) |
| Número exacto de usuarios afectados | No confirmado (solo estimaciones por Downdetector) |
| Si habrá postmortem público de Anthropic | Pendiente al cierre de esta nota |
Errores comunes cuando Claude da problemas
Asumir que el error es del código propio. Si empezás a ver 500 o 529 de forma repentina y tu código no cambió, lo primero que tenés que hacer es revisar status.claude.com. Antes de tocar cualquier cosa.
Implementar retry sin límite de intentos. Un loop infinito de retries durante un incidente de tres horas puede agotar cuotas, generar costos inesperados, o simplemente saturar tu propia infraestructura. Siempre poné un máximo de reintentos y un circuit breaker.
No diferenciar entre Opus 4.6 y 4.7 en el monitoring. Si usás ambos modelos en distintas partes de tu sistema, necesitás métricas separadas por modelo. Un incidente que afecta a uno puede no afectar al otro, y si los mezclás en el mismo dashboard no vas a ver el patrón.
Preguntas Frecuentes
¿Qué pasó con Claude el 15 de mayo 2026?
Anthropic registró tasas de error elevadas en los modelos Opus 4.6 y Opus 4.7 a partir de las 00:26 UTC del 15 de mayo de 2026. El problema duró aproximadamente 196 minutos y quedó resuelto a las 22:25 UTC. No fue un corte total sino una degradación severa del servicio que afectó a miles de usuarios según los reportes en Downdetector. Esto se conecta con lo que analizamos en según nuestros benchmarks de rendimiento.
¿Cuál es la diferencia entre Opus 4.6 y Opus 4.7 de Claude?
Opus 4.7 es la versión más reciente y tiene un costo un 35% mayor que Opus 4.6. Desde su lanzamiento en 2026, developers reportaron nuevos comportamientos en el parámetro budget_tokens y pérdida de contexto en conversaciones largas. Algunos equipos optaron por quedarse con Opus 4.6 ante estas regresiones. El incidente del 15 de mayo afectó a los dos modelos simultáneamente.
¿Cómo sé si Claude está caído ahora?
Revisá status.claude.com para el estado oficial, o Downdetector para ver si otros usuarios reportan problemas en tiempo real. Para equipos en producción, la opción más robusta es tener alertas propias basadas en la tasa de error de tus requests a la API, sin depender de que alguien del equipo revise la página de status manualmente.
¿Cómo manejar errores 429 y rate limits de Claude?
El error 429 indica que superaste el límite de requests de tu plan. La solución inmediata es reducir la frecuencia de requests y revisar los límites de tu tier en el dashboard de Anthropic. Para evitarlo a futuro, implementá rate limiting del lado de tu aplicación y configurá exponential backoff para reintentos. A diferencia de los errores 500/529, el 429 no es un problema del servidor sino de tu cuota.
¿Cuánto tiempo tardó en resolverse el outage de Claude del 15 de mayo?
Según el historial de status.claude.com, el incidente duró aproximadamente 196 minutos. El inicio fue a las 00:26 UTC y la resolución se confirmó a las 22:25 UTC del mismo día. Es uno de los incidentes de mayor duración que Anthropic registró públicamente en 2026 para sus modelos Opus.
Conclusión
El incidente del 15 de mayo con el claude status update de Opus 4.6 y 4.7 no cambió nada estructural, pero sí dejó en evidencia dos cosas que vale tener presentes. Primera: ningún proveedor de LLMs tiene SLA del 100% y Anthropic no es la excepción. Segunda: la diferencia entre un incidente que “pasó y se resolvió” y uno que “tiró tu aplicación tres horas” está casi siempre en si tenías retry logic, fallbacks y alertas antes de que empezara.
Si usás Claude en producción y todavía no tenés estas tres cosas implementadas, este incidente es el recordatorio. Subscribite al status, configurá alertas en tu herramienta de monitoring y documentá qué hace tu sistema cuando la API no responde. No es trabajo de una tarde, pero es el trabajo que evita la guardia de emergencia a las dos de la mañana.
Fuentes
- Anthropic Status — página oficial de incidentes de Claude
- Anthropic Support — guía oficial de troubleshooting de errores en Claude
- Downdetector — reportes de usuarios sobre disponibilidad de Claude AI
- DevToolPicks — regresiones en Opus 4.7 y vuelta a Opus 4.6 documentada por developers
- GV Wire — cobertura del incidente con datos de Downdetector