Resumo
- A OpenAI abriu o incidente às 07:32:04 UTC de 22 de julho para uploads de arquivos e geração de imagens.
- Às 07:54 continuava investigando; às 09:26:27 identificou o problema e disse implementar mitigação.
- O corte canônico de 09:40:04 mantém o evento como identificado e em andamento.
- A empresa só anunciou mitigação aplicada e monitoramento às 09:44:41, fora da janela.
- Não havia causa, população, taxa de erro, geografia, perda de dados ou vínculo com o incidente anterior.
Uma atualização posterior pode tornar um relato mais otimista sem torná-lo mais correto. No corte desta janela, a OpenAI ainda não dizia monitorar a recuperação. Ela dizia trabalhar na mitigação.
Essa diferença corresponde a uma decisão concreta do cliente: continuar enviando arquivos e imagens ou manter a fila suspensa. O estado das 09:44 não estava disponível às 09:40.
O incidente alcançou entrada e saída
Uploads abastecem análises, edições e agentes. Imagens podem ser o ativo final. Quando as duas funções aparecem juntas, a tarefa pode falhar antes de receber o material ou na hora de devolver o resultado.
O registro não lista produtos, formatos, regiões, categorias de cliente ou percentual de erros. Portanto, não há base para afirmar falha universal.
Uma fila pode conter upload recusado, pedido aceito, processamento sem resposta ou ativo concluído sem recuperação. Repetir tudo após a melhora pode duplicar resultado e custo. Identificadores e idempotência ajudam a reconciliar esses estados.
Recorrência operacional não é causa comum
O novo incidente começou aproximadamente quatro horas e quarenta e dois minutos após a resolução, às 02:50, de outro evento longo de imagens no ChatGPT.
Para fluxos visuais, a proximidade importa: a estabilidade voltou a ser questionada quase imediatamente. Mas o novo registro inclui arquivos e tem cronologia própria. A OpenAI não publicou uma causa compartilhada até o corte.
É possível falar em nova ocorrência sobre uma função parcialmente repetida e com superfície ampliada. Não é possível dizer que o mesmo sistema ou a mesma correção falhou.
“Em andamento” é um resultado editorial válido
Uma matéria de incidente pode terminar sem a resolução do incidente. Basta fixar o relógio. Aqui, o estado é o de 09:40:04 UTC. O monitoramento das 09:44 pertence ao acompanhamento seguinte.
Mesmo monitoramento não seria resolução. Significaria mitigação aplicada e recuperação observada. O cliente ainda deveria usar pequenas sondas, confirmar estabilidade e só então liberar o backlog.
Uploads e imagens também exigem testes distintos. Gerar com conteúdo já disponível não prova que um arquivo novo entra. Aceitar um arquivo não prova que a imagem sai.
No corte, a OpenAI seguia implementando mitigação. Preservar esse estado não ignora o avanço posterior. Evita que uma informação futura altere a decisão que existia no momento analisado.