Resumen
- OpenAI abrió el incidente a las 07:32:04 UTC del 22 de julio por errores elevados en carga de archivos y generación de imágenes.
- A las 07:54 continuaba investigando; a las 09:26:27 había identificado el problema y preparaba una mitigación.
- El corte canónico de 09:40:04 conserva el estado «identificado» y el incidente en curso.
- La mitigación aplicada y el paso a vigilancia se publicaron a las 09:44:41, fuera de la ventana.
- No había causa raíz, número de usuarios, porcentaje, geografía, pérdida de datos ni vínculo con el fallo anterior.
En una operación real, cuatro minutos pueden decidir si una cola se envía o se mantiene parada. A las 09:40, el mensaje de OpenAI no decía que la recuperación estuviera bajo vigilancia. Decía que la compañía trabajaba en implementar una mitigación.
La actualización posterior es válida, pero pertenece a otro instante. Un registro con corte fijo debe resistir la tentación de mejorar retrospectivamente el estado.
Un fallo tocó los dos extremos del proceso
Los archivos alimentan flujos de análisis, edición o agentes. Las imágenes pueden ser el resultado final. Si ambas funciones registran errores, una tarea puede quedarse sin entrada o sin salida.
OpenAI no enumeró productos, formatos, niveles de cliente ni regiones. Tampoco indicó una tasa. La evidencia permite hablar de errores elevados en esas funciones, no de caída universal.
Una organización debe distinguir archivos rechazados, aceptados o sin respuesta final. En imágenes, debe saber si la petición nunca entró, quedó pendiente o completó sin entrega visible. Reintentar todos esos estados juntos puede duplicar trabajos y costes.
Hay recurrencia de función, no causa demostrada
El nuevo expediente empezó unas cuatro horas y cuarenta y dos minutos después de que OpenAI cerrara a las 02:50 otro incidente largo de imágenes en ChatGPT.
Para quien depende de imágenes, la proximidad es material. Sin embargo, el expediente nuevo añade carga de archivos y tiene otra cronología. OpenAI no explicó la raíz de ninguno al corte.
Puede describirse una nueva interrupción cercana sobre una superficie parcialmente repetida. No puede afirmarse que falló el mismo sistema o que una corrección permanente volvió a romperse.
Un incidente abierto también es una noticia completa
La precisión no exige esperar a la resolución. Exige declarar el límite. Esta edición congela el estado a las 09:40:04 UTC. La vigilancia de las 09:44 podrá incorporarse a un seguimiento.
Además, vigilancia no significa resuelto. Significa que una acción fue aplicada y el proveedor observa resultados. Los clientes aún deben ejecutar pruebas pequeñas y exigir estabilidad antes de liberar una carga acumulada.
Dos pruebas sintéticas, no una
Un flujo que usa archivos e imágenes necesita verificar cada ruta. Generar desde datos ya presentes no demuestra que una carga nueva funcione. Aceptar un archivo no demuestra que el activo visual llegue.
Identificadores de solicitud, claves de idempotencia y estados separados ayudan a reconciliar el trabajo tras la recuperación. Durante el incidente, sondas limitadas reducen el riesgo de una avalancha de reintentos.
A la hora de corte, OpenAI seguía implementando mitigación. El paso a vigilancia ocurrió después. Mantener esa frontera no ignora la recuperación posterior; conserva la decisión operativa que existía en el momento analizado.