Resumen
- La incidencia de ChatGPT comenzó el 21 de julio a las 10:36:02 UTC y quedó resuelta el día 22 a las 02:50 UTC.
- La página pasó de mitigación a nuevas investigaciones, por lo que la mejora no se mantuvo de forma estable.
- El registro separado de la API empezó a las 19:33:27 UTC, recibió mitigación a las 20:26 y se resolvió a las 22:19.
- El solapamiento no demuestra que los dos eventos tuvieran el mismo origen técnico.
- No se publicó causa raíz, volumen afectado, distribución geográfica, pérdida de datos ni derecho a créditos.
Una caída que desaparece y vuelve obliga a los usuarios a tomar más decisiones que una indisponibilidad continua. Cada aparente recuperación plantea si reabrir la cola, y cada recaída convierte esos reintentos en trabajo adicional. Esa fue la característica principal del registro largo de ChatGPT.
La cronología de estados importa
Desde las 10:36:02 hasta las 02:50 del día siguiente transcurrieron aproximadamente dieciséis horas y catorce minutos. Durante ese intervalo, OpenAI aplicó mitigaciones y regresó a investigar. La página refleja la perspectiva del proveedor, no todos los resultados individuales, pero permite descartar una recuperación lineal.
Una mitigación puede reducir errores sin vaciar trabajos pendientes o estabilizar todas las rutas. Por ello, los clientes no deberían enviar de inmediato todo su atraso después de un cambio de etiqueta. Varias pruebas sintéticas, espaciadas y exitosas aportan más seguridad.
“Resuelto” tampoco informa de qué ocurrió con cada solicitud previa. El componente puede estar sano y los usuarios aún tener que reenviar creaciones fallidas o revisar respuestas incompletas.
La API tuvo principio y fin propios
El segundo registro cubrió errores elevados en generación de imágenes mediante API desde las 19:33:27 hasta las 22:19. Su mitigación llegó a las 20:26. Es una ventana más corta que coincide parcialmente con ChatGPT.
La coincidencia podría ser compatible con una dependencia común, pero no la prueba. Interfaces, colas, modelos, capacidad y puertas de enlace pueden fallar de maneras distintas. Sin un análisis causal de OpenAI, unir ambos incidentes sería especulación.
Un informe de cliente debe medirlos según su uso. Quien dependía de ChatGPT enfrentó el episodio largo. Quien llamaba a la API tuvo la ventana posterior. Una organización con ambos canales pudo recibir efectos diferentes.
No hay base para contar a todos los afectados
OpenAI no publicó cantidad de peticiones, porcentaje de error, territorios o tipos de cuenta. Tampoco declaró pérdida de datos. Es posible afirmar que la disponibilidad de imágenes se degradó; no es posible calcular el coste total desde estas páginas.
El daño operativo varía. En edición, comercio o publicidad, una imagen puede bloquear la publicación, generar turnos de vigilancia y retrasar aprobaciones. Para otro usuario con activos alternativos, el efecto puede ser menor. Una cifra global requeriría telemetría que no está disponible.
Los flujos resistentes separan aceptación, ejecución, entrega y aprobación. Guardan identificadores y claves de idempotencia para saber qué reintentar. Durante la recuperación, prueban poco a poco y no duplican toda la cola a ciegas.
Ambos registros están cerrados. La conclusión no necesita una teoría de causa: ChatGPT no se estabilizó con el primer intento, y la API sufrió además su propio intervalo de errores. La fiabilidad del cliente depende de verificar el resultado, no de interpretar “mitigado” como punto final.