This report was written on 2026-09-29. Later posts in this topic refine some of what is described below:
New conversations: see post #5 (only a hypothesis, 2 occurrences).
Data export: it arrived after one day and contains the complete versions of the chats that were broken. ChatGPT still shows them truncated, although they now seem to load on every attempt. See post #9.
The original report follows unchanged.
Environment
Surface: Web (Windows)
Browser or app version: Chrome on Windows. Also reproduced on other browsers and devices (all in incognito) and on several networks, with and without VPN. Plan: ChatGPT Plus.
Affected feature and model, if relevant: Loading existing and new conversations (conversation history, resume/stream recovery). Not tied to a specific model.
Bug
Since about 10:00 GMT-3 on 2026-09-28, and still ongoing, none of my conversations load reliably. I can see the conversation list, but opening any conversation fails. It affects old, recent and newly created chats, long and short ones, inside and outside projects, on every browser, device and network I tried.
It does not fail in a single way. Depending on the attempt I get:
A “could not load, try again” message
A truncated conversation that shows an old message as if it were the last one, with messages missing from the part that does load
The same broken state with an endless “thinking” indicator that ends in a timeout after several minutes (“ChatGPT stream recovery polling timed out”)
A generic “something unexpected happened, try again” error
Intermittent “too many requests” messages (sometimes, not always)
Expected: conversations open normally and show the full history, and I can keep working in them.
Impact: I use ChatGPT for daily work and have lost more than a day. I cannot access the full content of my conversations.
Reproduction
Log in to Chatgpt. The conversation list loads.
Open any conversation (old, recent or newly created; inside or outside a project).
One of the states above appears. Which one varies between attempts, and it is not deterministic.
With DevTools open on the Network tab, a failing conversation shows the request sequence described below.
Diagnostics
Exact error or screenshot:
UI: “ChatGPT stream recovery polling timed out” (with a Retry button). The other messages listed above are paraphrased, as my UI is in Spanish.
Console: POST /backend-api/f/conversation/resume 404 (Not Found)
DevTools also shows intermittent 500 and 503 responses on other attempts, which are not in the capture below.
When it happened (with timezone) and how often:
Started about 10:00 GMT-3 on 2026-09-28 and still ongoing. It fails on almost every attempt, with the failure mode changing between attempts.
One sanitized HAR capture of a failing conversation: at 2026-09-29 00:28:27 UTC (21:28 GMT-3), the resume request returned 404 (cf-ray a426de2ffc2c0cdd-SCL).
In that capture, GET /backend-api/conversations/{id} returned 200 with about 12.9 MB, so the data seems to exist on the server.
After the 404, the page polled the stream status about every 12 seconds and re-downloaded the full conversation each time (46 times in about 10 minutes, roughly 590 MB) until it showed the timeout.
A POST /backend-api/conversations/batch returned about 69 MB, and conversation/init requests appeared duplicated or cancelled. No x-request-id is exposed in the response headers.
Troubleshooting already attempted:
Several browsers in incognito, with cache and cookies cleared
Different devices and networks, with and without VPN
Signed out of all devices and back in
Retried repeatedly over many hours, with old, recent and new chats, inside and outside projects
Support status:
help.openai.com chat escalated to a support specialist, no case ID yet
Emailed support with a sanitized HAR and screenshots
This is a particularly useful recovery specimen because your HAR separates “the conversation data is unavailable” from “the client cannot recover/display it correctly.”
The strongest sequence I see in what you preserved is:
the conversation GET succeeds with HTTP 200 and returns about 12.9 MB;
/f/conversation/resume returns 404;
the client then keeps polling/re-fetching state;
the full conversation is fetched about 46 times in ~10 minutes (roughly 590 MB);
the frontend eventually emits “ChatGPT stream recovery polling timed out.”
I would be careful not to interpret the resume 404 by itself as “the backend conversation is dead.” I have a separate native capture where a resume 404 occurred while the turn later recovered and completed normally. The more useful discriminator is whether the conversation/target-turn state is actually changing during the recovery window.
If your existing sanitized HAR already preserves enough response bodies, one high-value check would be:
compare the first successful conversation GET after the resume failure with the last successful GET before the timeout;
for the affected turn, compare the current-node / mapping state and whether any new assistant/tool nodes appear;
keep the browser’s IS_STREAMING/polling state separate from actual tree progress.
That would distinguish two quite different cases:
state unchanged for the whole recovery window → the client is polling a stale/non-progressing turn;
new server-side nodes appear but the UI still never surfaces them → delivery/hydration/rendering is failing despite backend progress.
No need to reproduce this again just for that. The capture you already have is expensive enough in bandwidth and looks much more informative than another retry marathon.
Also, keep the HAR private/sanitized. Cookies, authorization headers and account/session identifiers are much more interesting to strangers than they are to this diagnosis.
Thanks for taking a look, this is helpful. Two clarifications:
The HAR I captured is sanitized and has no response bodies (only sizes and timings), so I can’t compare the conversation payload between the first and last GET or check the current-node/mapping state. It only shows that each GET returned 200 with about 12.9 MB.
I’d rather not post a HAR with response bodies publicly, since they would contain private conversation content. I have sent the sanitized capture to support and can provide more through that channel if they ask.
I also noted your point that a resume 404 alone doesn’t mean the conversation is lost. In my case the problem is not limited to this chat: it affects all my conversations, including newly created ones, and the failure mode changes between attempts (load errors, truncated conversations, endless “thinking”, generic errors, 429s).
Tested in different PC. All have bugs. Seems PC web page keep having this problem but iphone ios app doesn’t affect too much. The things I have test is that leave the PC overnight, I can refresh the chrome page and see the chat. However, after a while, it keeps failed to load the chat. I have also noticed that when it seems recovered the chat, the history chat loading still failed to work. Searching the old chat is not available. Opening a history chat is not possibe. I can always start a new chat, but whenever I want to open an old chat, it shows “could not load this ChatGPT conversation”. Also, for codex, in my main PC, failed to load everything, but in another PC, it works. I’m not sure whether different PC configuration matters. Really annoying!!!
Additional observation, which is only a hypothesis: on 2 occasions (approximately 2026-09-30 01:00 UTC and 04:00 UTC), a brand-new conversation ended in the timeout failure after a few minutes, when the assistant started searching for context from my past broken conversations. When I close and reopen that new conversation, it shows again as if it were still “thinking” until it fails with the timeout once more. This is the same behavior I reported earlier for some of my old conversations.
New conversations in which the assistant did not start searching for that context have worked without failures until now (05:00 UTC). I have not run further tests, to avoid causing more failures on the account I use for work, so I cannot confirm it. It may be useful for you to check on your side.
“Our systems are thinking a bit more about this request before responding”
“ChatGPT stream recovery polling timed out”
“Error in message stream”
“Hmm…something seems to have gone wrong”
temporary “Too many requests” conversation-access limits
conversation history disappearing/reappearing
transient OpenAI tool-safety blocks that later succeed on retry
short periods where 5.6 chats fail while a 5.5 High fallback still responds
OpenAI’s public incident was marked resolved earlier today, but these failures continued for hours afterward.
The most disruptive part is that during long tool-heavy development runs, the UI can fail without making it clear whether backend/tool work actually stopped. That makes retries unsafe because the external operation may already have partially or fully completed.
I have an open Support case (#15695041) and have timestamped screenshots.
At around 3:15 PM AEST, I also had a fresh outage-like period where multiple chats started failing again, including on desktop. Messages duplicated/failed during that window.
It’s getting beyond of just erroring. The responses are getting dumber and dumber each day. Even short conversations are losing context and not remembering elementary thing about projects.
The data export I requested for my account arrived by email yesterday. It took exactly one day: I received the request acknowledgment email on Monday, 2026-09-28, at 22:17 UTC, and the email saying it was ready on Tuesday, 2026-09-29, at 22:17 UTC.
It contains the complete versions of the chats that were broken when I requested it (chats created after the request are obviously not included). As far as I could check and recall, all of them appear complete and intact.
I compared them with what ChatGPT still shows for those chats, which have NOT been fixed. Just like before, the chats shown are cut off for good from a certain point onwards, and the part that does load is missing entire sections of several turns. But at least they seem to load on every attempt, and they don’t look any more broken than before.
Something I had forgotten to mention is that these are continuous conversations: the missing parts are not alternative branches.
So the good news is that the chats aren’t lost: they exist and appear complete in the export. The bad news is that ChatGPT still isn’t showing them for some reason. The problem hasn’t been resolved yet.
There still appears to be a rate-limiting issue when ChatGPT is used across several conversations in parallel.
The problem usually starts after working simultaneously in about 3-5 chats. After some time, requests begin failing with HTTP 429 “Too Many Requests”, and some conversations can no longer load correctly.
It becomes significantly easier to trigger when one of the chats is running a long operation. These long responses sometimes fail because of a connection/streaming error, and refreshing the affected tabs often causes 429 errors to spread to the other open conversations as well.
With only one active chat, the issue is either absent or much less frequent.
A possible cause is that foreground requests, reconnect attempts, history/state restoration, and other requests from multiple tabs are all counted against the same rate limit. Reloading several tabs may therefore create a burst large enough to trigger or prolong the 429 condition.
The relevant areas to investigate seem to be account-level rate limiting, reconnect/retry handling, and conversation restoration after reload.
Thanks for sharing this, @SystemXFiles. As a data point: at least in my case, the problems do not come from loading several conversations at the same time.
In the capture I described in my report, a single page generated a large number of repeated requests on its own: after the resume 404, it polled the stream status about every 12 seconds and re-downloaded the whole 12.9 MB conversation each time (46 times in about 10 minutes). So reconnect and restoration behavior can produce many requests without several conversations in parallel, which seems consistent with the areas you suggest investigating (reconnect/retry handling and conversation restoration after reload).
I have been working the same way for a year with multiple open tabs and long running tasks. Something new must have been deployed today because I started getting messages across tabs of too many requests and 429 http error codes. This is killing my ability to work especially with one of the highest pro accounts.
I’m still getting the 429 “Too Many Requests” error while using ChatGPT chats. It’s sad to see that OpenAI support continues to ignore this ongoing issue.
@ManuelN — following your updates in #9 and #11, I would keep this
open even though the chats now seem to load more reliably. The full
text being present in your export while the interface omits it is an
unresolved display/history problem. The single-page capture also means
that closing extra tabs cannot be treated as a complete fix: one page
generated the repeated downloads on its own.
There is a relevant October 1 clarification from
Support: their web-history
fix did not cover the “Too many requests” error or starting/running
Cloud Work. That should not be read as resolving the 429 reports
here.
For anyone arriving here mainly because they need the missing text,
Manuel’s export result is a useful fallback. On a personal account, Settings → Data controls → Export data, or the Privacy
Portal,
can provide a separate copy of the history; OpenAI says delivery can
take up to seven days. It does not repair the live chat, and Manuel’s
recovery is not a guarantee for every account. But it offers a way to
retrieve work without spending the day refreshing the broken view.
Same here. As soon as I started using multiple tabs, I ran into the same issue. This is the first time this has happened in all the years I’ve been using it.
Honestly, between the decline in model reliability since the update to 5.6, the subscription policies, the lack of communication, and now this. I understand why Claude is now attracting mostly PRO and enterprise customers. I’ve also requested an export of my data. Personally, I’m done with this. I’d rather go with a company that honestly discloses the real limitations associated with its service and subscription. Right now, I just feel like I’m getting locked into opaque terms and conditions for standard use.
