Summary
- OpenAI opened the incident at 07:32:04 UTC on 22 July for elevated errors affecting file uploads and image generation.
- At 07:54 the provider was still investigating; at 09:26:27 it said the issue was identified and mitigation was being implemented.
- The canonical news cutoff was 09:40:04, so the correct state for this briefing is identified and ongoing.
- OpenAI posted that mitigation had been applied and recovery was being monitored at 09:44:41, after the cutoff.
- The record disclosed no root cause, affected-user count, request share, geography, data loss or connection to the prior image incident.
A four-minute difference can change the tense of an outage story. At 09:40 UTC, OpenAI was working on a mitigation for file-upload and image-generation errors. At 09:44, it said the mitigation had been applied and it was watching recovery. Reporting the latter inside the earlier window would turn later knowledge into contemporaneous knowledge.
The distinction is not clerical. Customers deciding whether to submit files, start an image queue or release a workflow had only the identified state at the cutoff.
The affected surface combined input and output
File uploads are an ingestion dependency. Image generation is an output dependency. When both appear on the same incident record, a workflow can fail before the model receives its material or after the user requests the final asset.
OpenAI did not enumerate products, file types, regions or customer tiers. It also did not publish an error percentage. The record therefore supports a description of the affected functions, not a claim that every upload or every image request failed.
For document analysis, creative production and agentic workflows, the compound surface matters. A queue can contain jobs whose input never arrived, jobs accepted but not completed, and jobs completed but not returned. Retrying all three states in the same way creates duplicates and uncertainty.
Recurrence is visible; causality is not
The new incident began roughly four hours and forty-two minutes after OpenAI marked a separate, long-running ChatGPT image-generation incident resolved at 02:50 UTC. That proximity makes recurrence operationally relevant.
It does not prove shared machinery or a failed permanent fix. The earlier record concerned image generation in ChatGPT. The new one added file uploads and has its own incident identifier and timeline. OpenAI had not published a cause for either record by the canonical cutoff.
The reliable conclusion is that image-dependent users entered a new incident soon after the previous one closed, and the new record widened the workflow surface. A root-cause conclusion must wait.
An ongoing article needs an explicit boundary
Incident reporting often ages within minutes. A fixed cutoff prevents silent rewriting: this edition captures the status available at 09:40:04 UTC. The 09:44 monitoring update can be cited in a later update, but it cannot retroactively change the fact state used here.
Monitoring also would not equal resolution. It would mean a mitigation had been applied and OpenAI was observing recovery. Customers would still need their own successful requests and a stable period before replaying a backlog.
Queues should preserve the unknown state
During this type of incident, a production system should record whether an upload was rejected, accepted, or left without a final response. Image requests should use idempotency where available and retain request identifiers. Small health probes are safer than resubmitting an entire queue as soon as a banner changes.
Teams using both files and images need independent synthetic tests for each path. A successful upload does not prove generation, and a successful generation from existing data does not prove new files can enter.
At the cutoff, OpenAI's incident remained live and mitigation was being implemented. That wording is less satisfying than a recovery headline, but it is the only version consistent with the window. The later monitoring state is real; it is simply evidence for what happened next.