On 14 and 15 September 2026, OpenAI’s status page marked a ChatGPT Work Mode problem “Resolved” twice within about 24 hours. A 26-post thread on OpenAI’s own Developer Community forum tells a different story: real users, with named tools and error messages, describing Work Mode as still broken for roughly a day after the first fix and several hours after the second. This is a case study in a gap we flagged in our earlier count of OpenAI’s status history: the status page reports what OpenAI’s monitoring sees in aggregate, and that is not always the same as what an individual user experiences.
Key takeaways
- OpenAI logged two separate Work Mode incidents on 14-15 September 2026: one resolved in 71 minutes on the morning of the 14th, a second that opened that evening and was marked “Resolved” at 08:41 AM on the 15th.
- A user who first reported the problem on the morning of 14 September was still documenting specific tool failures, with screenshots and error text, after the first incident was marked resolved.
- Other users in the same thread kept reporting broken file uploads, video analysis and markdown creation through 15 September, until several posted that it was working again that evening, roughly a day after it started.
- No OpenAI staff reply appears in the 26-post thread we read. A fellow user, not OpenAI, pointed the group to the status page.
Last reviewed 29 September 2026. We read two OpenAI status incident pages and one 26-post community thread in a browser on that date. Relative post dates on the forum (“15d” and similar) were converted using the post’s stated day; some posts carry only a date, not an exact time, so the timeline below is accurate to the day for those and to the minute where OpenAI’s status page gives a timestamp.
What OpenAI’s status page logged
We found two separate, officially logged incidents touching Work Mode in this window:
| Incident | Status page timeline | Result |
|---|---|---|
| Elevated error rates for Codex and ChatGPT Work | Investigating from 08:16 AM, resolved 09:27 AM, 14 Sep | 71 minutes, marked fully recovered |
| Elevated errors affecting Work Mode in ChatGPT | 9:28 PM 14 Sep: mitigation applied, “service has recovered”. 1:12 AM 15 Sep: further mitigation, monitoring. 8:41 AM 15 Sep: Resolved | About 11 hours 13 minutes from the first fix attempt to the final Resolved mark, including one mitigation that did not hold |
Note the second incident’s own history: OpenAI’s first update, at 9:28 PM on the 14th, said a mitigation had been applied and “service has recovered”. Its next update, nearly 4 hours later, said it had applied “additional mitigations” and was monitoring again. That is OpenAI’s own record of a first fix not holding, before the incident was marked Resolved at 8:41 AM.
What users were reporting at the same time
The user who opened the thread (Work Mode tools remain unavailable after Sep 14 mitigation, 3,800 views, 15 users, retrieved 2026-09-29) posted on 14 September, after the first 71-minute incident had already been marked resolved. Their report was detailed: a “Some tools are temporarily unavailable” warning on every turn in Work Mode, a Markdown file request that produced no downloadable file, and, on every one of five tested PNG uploads, this message reaching the underlying tool: “Codex could not read the local image at /workspace/scratch/…/upload/<file>.png: No such file or directory (os error 2).” They also reported that a previously working video-analysis capability had stopped functioning, and that the iOS app hid the warning while the same failures continued underneath it.
Other users confirmed similar and related failures through the rest of 14 September and into 15 September: a session reporting no “local file write capability”, Excel editing described as inactive, image generation failing with “Could not load the image path”, and one user unable to upload PPTX and ZIP files together. One wrote: “Putting in a huge amount of effort into a Project only to have Product Failure is unacceptable for PAID SERVICE!” Another, after the incident was marked Resolved and after clearing their cache and waiting, received this reply from the model itself: “I can access the required source files, but this Work session currently lacks the local file-processing runtime needed to extract ZIPs, render exact charts, and build/validate new ZIP archives. I won’t fabricate downloads or hashes.”
The moment the status page and the users disagreed
On 15 September, a user in the thread, not OpenAI staff, wrote: “There seem to be Elevated errors affecting Work Mode in ChatGPT – OpenAI Status. They are right now monitoring the result.” Another replied: “System says both ‘resolved’ and ‘monitoring’. Isn’t it supposed to be smart?” after describing a further half hour spent clearing cache and moving their work to a new session, without success. We read the same status page and can confirm both words, “Resolved” and an earlier “Monitoring” update, appear on that incident’s own history, which is the source of the confusion this user described.
When did it actually get fixed?
The original poster returned on 15 September with an update: “the popup has finally stopped making itself part of the interface… Image uploads, video processing, and markdown file creation/readback are also working again in my latest tests,” while noting one remaining brief error on retry and stopping short of calling it fully stable. Two more users confirmed it was back to normal for them the same day. Based on the dates in the thread, that puts real recovery, as experienced by these users, at roughly a day to a day and a half after the original poster’s first report on the morning of the 14th, well after both of OpenAI’s own Resolved marks.
We did not find any post from OpenAI staff in this thread confirming a cause, a fix, or the final all-clear. The thread’s own resolution came from users comparing notes, not from an official reply. That is a contrast with the Codex capacity thread we covered separately, where a staff member did reply. If Gemini rather than ChatGPT is giving you trouble, our Gemini Live troubleshooting analysis and Gemini error code analysis are built the same way.
Why this matters beyond one thread
In our earlier piece, we counted 37 incidents logged on OpenAI’s status page for 1-26 September 2026 and noted that the page reports errors in aggregate, so an account-specific or slower-to-clear problem might not show its true length there. This thread is a documented example of exactly that gap: two officially logged incidents, one lasting 71 minutes and one about 11 hours, against user reports of broken tools spanning roughly a day. We are not saying OpenAI’s status page is inaccurate about its own monitoring; the page never claims to report individual account experience, and it says so directly (“individual customer availability may vary”). We are saying that “Resolved” on the status page did not mean “fixed for these users” at the time they read it, and worth remembering next time a status page says all clear while your own tool is still broken.
What we could not verify
- Most user posts carry a date but not a clock time, so we can only place the recovery at “15 September, evening” by the order of posts, not an exact hour.
- We read one 26-post thread. Other users may have had a shorter or longer experience that was never posted.
- We could not confirm what OpenAI’s backend fix on 15 September actually changed, since no staff explanation appears in this thread.
- We do not know how many ChatGPT Plus users were affected in total. The forum lists the thread as viewed by 3,800 people and tracked by 15 users, and we counted 12 distinct named posters describing the symptoms across its 26 posts, out of what OpenAI’s status page scopes only as “some ChatGPT Plus users”.
How we researched this
On 29 September 2026 we opened the two Work Mode-related incident pages linked above on status.openai.com and recorded every timestamped update on each. We then read the full 26-post community thread, including all replies, recording who posted, what error or symptom they described, and the date given. Quotes above are copied as posted, and we have not corrected spelling or tone. Where we state a cause or a fix, it is because a source says so; where we could not confirm something, we say so above.
Frequently asked questions
In the case we documented, OpenAI’s status page marked the issue resolved twice, once after 71 minutes and once about 11 hours later, but users kept reporting broken file uploads, image paths and video analysis for roughly a day. We found no official explanation for the gap in the thread we read.
It reports errors in aggregate and says so on every incident page. It is a genuine record of what OpenAI’s own monitoring saw, but as this case shows, “Resolved” there does not guarantee every affected user’s tools are working again at that moment.
Based on what worked for users in the thread we read: clearing cache and waiting did not reliably help, and the issue eventually cleared on its own roughly a day after it started. Reporting it through OpenAI’s feedback channel is the documented way to get it looked at, though we found no confirmation in this thread that it sped up the fix.
Not always. In the 26-post thread we read, no OpenAI staff reply appeared; the only person who pointed to the status page was a fellow user. Our separate count of Codex complaints found a thread where staff did reply, so it varies by thread.
