Four incidents in one day, published by the vendor
On 27 July, OpenAI's status page recorded four separate incidents. Elevated errors affecting ChatGPT conversations at 4:32pm. Elevated latency, timeouts and interrupted streaming on gpt-5.1 mini and gpt-4.1 mini across the API at 6:06pm. Image generation unavailable in ChatGPT at 7:04pm, and unavailable again at 8:24pm. Each was closed with the same sentence: all impacted services have now fully recovered.
That was not an unusual day. The 25th carried two incidents of elevated error rates. The 24th carried three, including elevated API error rates and latency on the gpt-image-2 model and elevated errors in Codex Review. Saturday's disruption was the visible one, touching fifteen ChatGPT components, four Codex components and twelve API components, with users meeting 503 responses that carried an internal circuit-breaker label. OpenAI moved from investigating to monitoring within about an hour.
Independent tracking of the same status history counts roughly 166 incidents across about nine months, an average close to 18 a month. None of that is leaked or inferred. It is the vendor's own published record, updated in real time, free to read, and almost never read by the people signing the contract.
The remedy was denominated in the broken currency
OpenAI's response to the weekend disruption was to reset usage limits for Codex and ChatGPT Work users. Read that as an instrument rather than as a gesture. The compensation for a service being unavailable was more allowance on the service that had been unavailable. It is not money, it is not a contractual service credit, and it cannot be spent anywhere else.
Then came the genuinely instructive part. Users who had already consumed one of their resets shortly before the compensation landed found it did nothing for them. A reset restores an allowance to full. It does not add to an allowance already banked. For that group the goodwill gesture arrived as a write-off of value they were holding, and the complaint was not ingratitude. It was arithmetic.
This failure mode is worth naming, because it will recur across every consumption-priced product. When the unit of compensation is the same unit that was disrupted, the remedy's value depends entirely on the customer's position at the moment it is granted. Some customers are made whole. Some are made worse off. Nobody is paid.
Eighteen a month is a number, not a feeling
For most buyers the useful move here is unglamorous. Take the incident count from the vendor's status history, write it into the file next to the marketing availability figure, and note that the two describe different things. An availability percentage is an aggregate over time. An incident count is a frequency of disruption, and frequency is what actually interrupts your staff.
If your organisation is a financial entity inside the scope of the European digital operational resilience framework, this is already a formal obligation rather than good practice. Information and communication technology third-party risk has to be registered, assessed and monitored, and a provider that publishes its own incident history has effectively handed you the evidence. The awkward part is that the evidence sat in public the whole time.
The wider point holds outside regulated sectors too. Any dependency a team touches dozens of times a day deserves a measured reliability figure rather than an impression. Impressions are formed by the worst outage anyone remembers. A status history is formed by all of them.
Three questions to answer before Friday
First, which agreement governs your usage. A seat-based subscription, an enterprise agreement and an API contract typically carry different commitments, and the remedy for downtime in each is rarely the same. Establish whether your organisation is entitled to a service credit, to a refund, or to nothing beyond whatever the vendor decides to grant.
Second, what a disruption costs you per hour. Not in theory, but with the number of people affected and the work that stops. Firms routinely discover at renewal that they never calculated it, which is precisely why a remedy denominated in tokens was accepted without anyone noticing what it was.
Third, what happens to the work in flight. Saturday's reports were dominated by developers who lost momentum rather than data, but the same disruption pattern reaches document workflows, customer-facing assistants and anything with a queue behind it. Decide in advance whether a two-hour interruption is an inconvenience your team absorbs or an incident your customers see, because that determination changes which vendor commitments are worth paying for.
Read next: A Delhi Court Backed OpenAI on Training Data | The Warning Shipped 14 Days Before the Deletions



