Between 10 July and 8 October 2026, OpenAI’s status feed recorded 111 incidents, and most were labelled degraded performance or left unlabelled, not outage. In OpenAI’s own labels, 79 were degraded performance, 12 partial outage and 2 full outage, and 18 had none marked. The typical incident (the median) stayed open for 114 minutes, but a few long ones carry much of the total time: the 10 longest account for 46% of all incident minutes. We built the dataset ourselves from OpenAI’s public pages, published it as a CSV, and use it to ask four questions: how long incidents last, which products they touch, when they start, and when OpenAI explains them. Anthropic’s page is summarised separately at the end, with a warning about comparing the two.
Key takeaways
- 111 OpenAI incidents started between 10 July and 8 October 2026. Median open time was 114 minutes, the mean 263 and the longest 2,724 minutes (about 45 hours). 53 (48%) stayed open for more than two hours and 23 (21%) for more than six.
- By OpenAI’s labels, 71% were degraded performance, 16% had none marked, 11% were partial outage and 2% full outage. These are OpenAI’s own judgement, and several incidents labelled degraded have titles such as “down” or “unable to”.
- 102 of the 111 (92%) started on a weekday, which is 71% of days, and 54 (49%) started between 14:00 and 19:59 UTC, 10 a.m. to 4 p.m. US Eastern, which is 25% of the hours. Only 4 of the 11 incidents whose write-ups name an internal change started in that window, so we cannot say why.
- OpenAI linked a write-up from 17 of the 111 (15%). Partial or full outages were far more likely to get one (8 of 14, 57%) than the rest (9 of 97, 9%), but 9 of the 17 write-ups are for incidents labelled degraded or unlabelled, and recent incidents may still be waiting for theirs.
Last reviewed 8 October 2026. Data was retrieved on 8 October from OpenAI’s status feed and each incident’s own page, and from Anthropic’s incident feed. All times are UTC. The per-incident CSV and the script that computes every figure are described in the method section. A count of incidents is not a measure of reliability, for reasons we explain below.
What did we measure, and how?
OpenAI’s status page lists each incident with a title, a series of timestamped updates and, usually, the components it affects. The feed lists incidents by resolution time and rolls forward: on 8 October its earliest entry was resolved on 10 July at 23:07 UTC, so incidents that ended before then are not in it, and the first incident in our data started on 10 July at 21:13 UTC. We took every incident in the feed that started on or after 10 July. For each we took the start as the time shown on the first update, the end as the time of the first update marked “resolved”, and the severity as the worst status OpenAI set on any affected component. That gives 111 incidents. One more, resolved on 11 July, began on 29 June and runs 12 days on the page, so we left it out as it started before the window. The data includes non-service notices such as support delays and a billing issue, which OpenAI also posts as incidents.
| Measure (111 incidents, 10 Jul to 8 Oct 2026) | Result |
|---|---|
| Median minutes open | 114 |
| Mean minutes open | 263 (pulled up by a few very long incidents) |
| 90th percentile | 575 minutes (9.6 hours) |
| Longest | 2,724 minutes (45.4 hours): “Elevated errors in ChatGPT Space Pages”, from 30 September |
| Open for more than 2 hours / 6 hours / 24 hours (strictly more than) | 53 (48%) / 23 (21%) / 3 (3%) |
| Share of all incident minutes in the 10 longest | 46% (the 5 longest: 32%), out of about 487 hours in total |
| Severity marked by OpenAI | Degraded 79 (71%), none marked 18 (16%), partial outage 12 (11%), full outage 2 (2%) |
| Median minutes open by severity | Degraded 120, partial outage 108, full outage 28.5 (only 2), none marked 114.5 |
| Started on a weekday | 102 of 111 (92%), against 71% of calendar days |
| Started 14:00 to 19:59 UTC | 54 of 111 (49%), against 25% of the hours in a day |
| Linked to a write-up | 17 of 111 (15%), covering 16 distinct write-ups |
Three cautions. First, a longer open time is not longer downtime. Our measurement of status-page stages found that a large share of an incident’s open time can come after the company says a mitigation is in place. Second, the displayed start can be set earlier than the time OpenAI posted the incident: 11 of the 111 (10%) show a start 15 to 302 minutes before their posting time. Measured from the posting time instead, the median is 100 minutes rather than 114. Third, our earlier articles used the feed’s own creation time and counted only resolved incidents, so their figures differ: for example, the September article’s median of 53 minutes covered 21 resolved incidents from 15 September to 5 October, and the same period on this basis, with all 25 incidents resolved by now, gives 81. Its “40 incidents in September” counted by resolution date and the 40 here count by start date.
How long do incidents last?
The median is 114 minutes and the mean 263, so the typical incident is shorter than the average suggests and a handful stretch the total. The 10 longest incidents hold 46% of the roughly 487 hours of open time across all 111. The three that stayed open for more than 24 hours were “Elevated errors in ChatGPT Space Pages” (2,724 minutes from 30 September), “Elevated errors affecting ChatGPT conversations” (2,543 minutes from 25 July) and a 23 July incident titled “Elevated Error Rates” (1,677 minutes). A notice such as “Support available via email”, open about 330 minutes, counts like any other incident.
The 23 July one shows how the page’s length and an incident’s impact can differ. OpenAI’s write-up describes an impact period of about 402 minutes that ended at about 2:26 p.m. PDT on 23 July. The incident page’s own updates show further activity on 24 July, going back to “investigating” after earlier “monitoring” updates, with the first “resolved” update at 19:33 UTC that day, which gives the 1,677 minutes. The write-up does not mention the 24 July activity, so we cannot say what the later updates covered. Because we end an incident at its first “resolved” update, an incident that is later updated again, such as the 21 July image-generation incident, which kept getting updates until 27 July, is measured only to that first resolve. Month by month, median open time was 114 minutes for 10 to 31 July, 184.5 for August, 91 for September and 94.5 for 1 to 8 October. With 18 to 40 incidents a month and no statistical test, we would not read a trend into that.
Which products do incidents touch?
Of the 93 incidents with at least one component marked, the most frequently affected were Conversations (35 incidents), ChatGPT Work (24), Image Generation (18), Login (17), Codex in ChatGPT Desktop (13), and File uploads, Agent and Connectors/Apps (12 each). An incident that marks several components counts for each, and about 10 incidents list 11 or more components, so a few broad incidents add to many of these counts. Titles from the first week of October mention products such as ChatGPT Work, Dot in Codex and Workspace Agents.
This is a count of incidents that touched a component, not of hours of downtime or users affected. A busier product can look worse on this list because OpenAI posts more incidents for it, or because more people use it and notice. We cannot separate those from this data.
When do incidents start?
Weekdays dominate: 102 of the 111 incidents (92%) started Monday to Friday, which is 71% of the 91 calendar days, or about 1.6 incidents per weekday against 0.35 per weekend day. Tuesday has the most (28, six of them on a single Tuesday, 6 October). By hour, 54 incidents (49%) started between 14:00 and 19:59 UTC, which is 10 a.m. to 4 p.m. US Eastern (EDT, UTC minus 4), a window that is 25% of the day.
It would be tempting to say that changes are shipped during US working hours, but we cannot show that. Of the 11 incidents whose write-ups name an internal change as the trigger, as we covered in our review of the write-ups and in the 29 September article, only 4 started in that window, and one started on a Saturday. The start times also follow when staff post as well as when problems begin.
When does OpenAI explain an incident?
Seventeen of the 111 incidents link a write-up, which is 16 distinct write-ups because two incidents on 25 July share one. They are far more common for the serious ones: 8 of the 14 incidents marked partial or full outage have one (57%), against 9 of the other 97 (9%). But 9 of the 17 are for incidents labelled degraded or unlabelled, and write-ups can arrive days after an incident (the 29 September one took about eight days), so 17 is a floor for recent incidents. By our reading of OpenAI’s wording, 11 of the 16 trace to a change made inside OpenAI (including the 29 September feature rollout), 3 to a provider’s maintenance and 2 to storage or capacity limits. Each write-up is OpenAI’s own account. The 1 October sign-in and Ads Platform incident, for example, says a shared storage system reached its capacity limit.
This matters when several services fail at once, because a single outside cause is easy to assume. Of the 16 write-ups, 11 name a change inside OpenAI and 3 a provider’s maintenance, and the other 95 incidents have no write-up to check. For 3 September, the write-up names an internal routing change, as we found when we checked the Azure explanation.
What does Anthropic’s page show?
| Anthropic status page, 27 July to 7 October 2026 | Result |
|---|---|
| Incidents in the feed | 50 (49 resolved, 1 open when retrieved) |
| Median minutes open (resolved) | 63 |
| Open for more than 2 hours | 12 of 49 |
| Impact labels | Minor 25, major 20, critical 2, none 3 |
| Incidents whose updates name a cause | 3 of 50 (a Windows update, an unnamed upstream cloud provider, a Google Play issue) |
Please do not read the two providers’ tables side by side. OpenAI’s feed also carries an incident-level impact field with values like Anthropic’s, but each company’s staff sets its labels under their own rules, each chooses what to post and when to close it, and we showed in our comparison of September’s incident counts that raw counts mislead. Anthropic’s “3 of 50” counts status updates only, whereas OpenAI’s 17 are separate write-up documents, and the two Anthropic engineering postmortems we found concern response-quality problems, not outages. The longest incident on its page, a Windows-update problem that lasted 99 hours, was fixed by Microsoft, according to Anthropic.
What this means if you depend on these tools
- Expect frequent problems that OpenAI labels degraded, and read the title as well as the label. 2 of 111 incidents were marked full outage, but 6 of the 79 labelled degraded have titles like “Chatgpt.com is down – all signups and logins are down” or “Image generation unavailable in ChatGPT”. If your workflow depends on one feature, such as Work, image generation or login, check that component’s recent incidents.
- Treat “resolved” and the displayed start as OpenAI’s account. Open time includes monitoring and sometimes later updates, as in the 23 July case above, and the displayed start can be set earlier than the post. Our comparison of status-page times with OpenAI’s own write-ups found the first post came a median 20 minutes after the stated start in all 15 incidents we could match, and our Work Mode case study shows three forum users reporting recovery before the page said resolved.
- Read the write-up when there is one. It tends to say what was and was not affected, such as whether API access still worked.
- Be careful with counts. October’s pace so far, 18 incidents in 8 days, is higher than any earlier month in the data, but 15 of the 18 started on 5 to 7 October, and a count does not distinguish more problems from more reporting.
What we could not verify
- We cannot tell how many users were affected by any incident, so the dataset measures what the page displays, not user impact.
- OpenAI sets the severity labels, so our severity breakdown is OpenAI’s own judgement. 18 incidents have none, and several incidents labelled degraded are titled as unavailable.
- The displayed start can be earlier than the post (11 of 111), and we did not check any start against an independent measurement. We end each incident at its first “resolved” update, which can truncate an incident that is later updated again.
- The feed starts, in effect, on 10 July and rolls forward by resolution time, so we cannot say how this period compares with earlier months, July covers about 21 days, and the monthly counts cover unequal numbers of days (21, 31, 30 and 8).
- Write-ups can arrive days after an incident, so the write-up counts are a floor for recent incidents, and the October incidents have had little time to receive one.
- The weekday and hour patterns describe when incidents were logged, and we cannot tell whether they reflect when problems occur or when staff post.
- We read Anthropic’s page only for its 50 most recent incidents, and its labels are not comparable with OpenAI’s.
How we built the dataset, and how you can check it
On 8 October 2026 we read OpenAI’s RSS feed for the list of incidents, then opened each incident’s page and read its embedded data: the timestamped updates, the incident’s own published time, the component statuses and whether a write-up is attached. A script (dataset_openai.py) extracted the data, and a second script (stats_openai.py) computed every figure in this article from it. We cross-checked the start and end times against OpenAI’s JSON feed for the 25 most recent incidents, finding the same start and end minutes for 22; for the other 3, the JSON feed’s start is 23, 141 and 212 minutes later than the first-update time we used. The per-incident data, with start, posting time, end, minutes, severity, components and write-up flag, is in this CSV file (111 rows, retrieved 2026-10-08, times to the second), so you can recompute every figure. The feeds roll forward, so the CSV is the record of what we measured.
More from this series
- Is ChatGPT or Codex down? We counted every incident OpenAI logged in September
- ChatGPT vs Claude: who logged more incidents in September, and why the count misleads
- What “resolved” means on AI status pages
- Is OpenAI’s status page accurate? 15 incidents compared with its write-ups
- What OpenAI’s outage write-ups say caused the incidents
- OpenAI’s 29 September outage: the write-up versus the status page
- The Work Mode outage: status said recovered, users didn’t
- The Azure explanation for the 3 September outage, checked
- Claude Cowork on Windows: broken for four days
Frequently asked questions
OpenAI’s status feed recorded 111 incidents that started between 10 July and 8 October 2026, an average of about 1.2 a day. Most were labelled degraded performance or left unlabelled, and only 2 were marked full outage. The pace varied by month, from 0.65 a day in August to 2.25 a day in the first eight days of October.
In the same 111 incidents the median open time was 114 minutes and the mean 263, with the longest at 2,724 minutes. 48% stayed open for more than two hours. Open time includes any monitoring stage and depends on when staff post and close, so it can be longer or shorter than the time users were affected. In our comparison with 15 write-ups the page ran longer in 8 and shorter in 7.
Sometimes. It linked a write-up from 17 of the 111 incidents (15%). Incidents labelled partial or full outage were much more likely to get one (8 of 14, 57%) than the rest (9 of 97, 9%), but 9 of the 17 write-ups are for incidents labelled degraded or unlabelled. Write-ups can take days, so recent incidents may still be waiting. By our reading, most of the 16 distinct write-ups trace to a change inside OpenAI.
We cannot say from this data. Anthropic’s page showed 50 incidents between 27 July and 7 October with a median of 63 minutes open, but each company sets its own labels and chooses what to post, and a count of incidents is not a measure of reliability.
