Message delivery timed out: ChatGPT Timeouts and Too many requests

ChatGPT's observed Japanese notice, translated as "Message delivery timed out," means that delivery of the answer did not complete. First distinguish this from a "Too many requests" restriction. Neither notice, by itself, proves that your weekly allowance has run out or your device has failed. This guide covers checks on mobile, the web, and desktop, precautions when running many chats at once, and ways to resume without losing unfinished work.

Observed Japanese notice:
メッセージの配信がタイムアウトしました。もう一度お試しください。
Translation: Message delivery timed out. Please try again.
This translation does not establish the exact wording shown in the English interface.

Timeouts versus Too many requests

The timeout notice establishes that delivery did not finish. Its wording alone does not reveal whether generation stopped, generation continued but reception failed, or the problem was on the server or your device. Even if part of an answer is visible, recovery of the remainder is not guaranteed.

OpenAI's official ChatGPT error troubleshooting guide lists network settings, browser extensions, and temporary server problems as possible causes. However, the text reviewed on October 12, 2026 does not identify a root cause or a fixed time limit specifically for the delivery timeout above.

These distinctions follow the wording of the messages. In the report provided for this investigation, the user described a notice resembling "Too many requests," but the full text was unavailable, so we cannot establish which notice appeared.The official material reviewed also did not provide a universally safe concurrency count for ChatGPT or a waiting period guaranteed to clear the restriction.

Do not confuse an API 429 with a ChatGPT plan limit

OpenAI's API error documentation distinguishes several HTTP 429 cases, including request-rate restrictions and insufficient credits or quota. The error code in the response matters as well as the HTTP status. This is API documentation; it does not establish that a ChatGPT app notice necessarily corresponds to 429 or uses the same limits.

Do not assume that you need extra credits merely because you saw something resembling "Too many requests." Plan and model allowances, short-term submission restrictions, and concurrency restrictions call for different responses. If the interface explicitly gives a limit or reset time, record it.

Checks and recovery steps when an answer stops

First preserve the information that remains, without deleting the conversation or changing settings. The sequence below is this guide's recommendation based on the official general troubleshooting advice, not a guaranteed recovery procedure for this specific timeout.

1. Save the partial answer and prompt

If an answer is visible, copy the parts you need. Hide private information and account names when capturing an error screenshot. You do not need to start by deleting the conversation, switching accounts, or reinstalling the app.

For research, separate verified sources from conclusions that have not yet arrived. For writing, distinguish completed paragraphs from unfinished sections. If the work involves external apps, an action may already have executed even though the answer stopped. Check the outcome of sending, booking, or publishing before repeating the same request.

2. Pause new submissions when many chats are running

If multiple conversations are being processed, see whether existing answers finish before sending new requests. Follow any waiting instructions shown on screen. Do not assume that another conversation gets separate restrictions or that repeated retries will get through sooner.

The official guide's advice to wait 30–60 seconds is an initial step when an answer appears stuck and does not finish.It does not mean that Too many requests is guaranteed to clear within that time. Do not turn this into a rule to stop a long reasoning process that is progressing normally after a fixed interval.

3. Check incidents and model limit notices

OpenAI Status shows incidents involving ChatGPT conversations and the features you used. Read the affected components and incident period rather than merely looking for the word "ChatGPT." Some incidents, such as billing-reporting delays, do not affect conversations.

An absence of listed incidents does not prove that your device is at fault. The status page itself explains that aggregate availability can differ from individual experiences across plans, models, and features. If a model usage limit is explicitly shown, check its reset time separately from incident reports.

4. Retry once, then transfer the essential context if necessary

For generation that will not finish, the official guide suggests stopping and regenerating, or resending in a new chat. When a Retry button appears below the answer, as in this case, preserve the remaining content first and try once at a time. Check the state of any other active conversations too.

When moving to a new chat, provide a short handoff covering the goal, requirements, completed work, and remaining request rather than assuming that all past history transfers automatically. You do not need to copy an entire confidential conversation. A new chat uses the same service, so it is not guaranteed to resolve request restrictions or service incidents.

The previous answer stopped partway through.
Goal: summarize the research findings in a comparison table.
Verified: the sources pasted below and the completed first half of the table.
Remaining: the second half of the table and an explanation of how to choose.
Continue the unfinished work without repeating what is already complete.
Do not treat unverified information as verified.

What happens when many chats run in parallel

Researching independent topics in parallel can overlap waiting time. However, more simultaneous submissions may also bring more restrictions, failures, and work to review the results. Starting every request at once is different from reducing the total amount of work. You can keep all necessary tasks while staggering their start times.

Distinguish weaker reasoning from apparent slowness

The official material reviewed does not explain that running many chats automatically divides the reasoning effort allocated to each answer. Nor does it guarantee that quality can never change. A quality comparison needs matching models, reasoning settings, prompts, conversation context, and usage-limit states.

OpenAI's explanation of models and usage limits notes that reaching a Thinking limit can lead to continuation with another available model. If answers seem different during parallel work, check for a model change and limit notices as well. A Pro subscription does not remove every model-specific allowance or restriction. For pricing and allowances, see the ChatGPT Pro plan comparison.

Compare completion time and failure rate when adjusting concurrency

Instead of inventing a fixed safe count, compare a small number of parallel requests with your current count on the same kind of work. Measure not just time to the first character, but time until every answer finishes, the number of failures, and time spent redoing work. If all requests finish normally at high concurrency, the count alone is not a reason to reduce it.

Repeatedly rerunning important work for comparison consumes allowance and introduces more variation in results. This guide recommends first recording the starts, finishes, and failures of your ordinary work, then considering a small controlled comparison only if that is insufficient. We have not conducted a load test designed to trigger restrictions.

Diagnosing mobile, web, and desktop issues

Do not assume that submitting from another device creates a separate allowance or restriction. If you are checking on a PC several jobs started on mobile, the number of tabs currently visible does not reveal the total number of active requests. A spinning indicator also does not guarantee that server processing is progressing normally.

OpenAI's guidance on slow responses suggests closing other programs or tabs to free device resources. This is a possible way to improve interface responsiveness, not a statement that your device's CPU determines the AI model's reasoning ability.

On corporate networks, settings that interrupt long-lived connections may warrant investigation. The official network guidance recommends checking WebSocket timeouts and message-size restrictions when a connection starts but then stalls. This does not mean that every timeout is caused by WebSockets.

Do not disable protective features or a VPN without authorization on a device containing confidential information. The official guide lists possible changes involving extensions, VPNs, and caches, but organizational rules and the owner's permission take priority. Start with recording the error, checking incidents, and comparing approved environments.

Observed notices and similar user reports

During its October 12, 2026 investigation, AI Arte confirmed the Japanese delivery-timeout notice quoted above in a screenshot supplied by a user. For a separate error, the user explained that it appeared after running many chats in parallel from the mobile app. We did not compare answer quality experimentally or obtain mobile network logs.

This report makes a restriction associated with high concurrency a possible cause. However, it is not a reproducibility test with a fixed device, model, and concurrency count, so it does not prove a general limit or causal relationship. We also did not infer the internal number of active requests from the dozen or so spinning indicators visible on screen. Private conversation names and contents from the supplied screenshot are not published.

As a concrete external example, OpenAI Developer Community user Krillo74 reported that, after a connection broke during lengthy research, reconnection failed with 404/410 and the same English delivery-timeout message appeared. Their diagnostic record describes reproduction in another browser and a new project. See the report and subsequent update.

An October 7 update to the same post says the issue no longer reproduced in the user's environment, but the cause and any fix remained unconfirmed.Even though it appears on an official site's community forum, this is a user report, not an OpenAI finding about the cause. It is also not evidence that the screenshot in this investigation had the same cause. Treat it as a similar case useful for investigation, rather than generalizing that every session stops after a certain number of minutes or that every user of this model encounters a bug.

What to record and tell support

To narrow the cause, preserving the conditions of one failed attempt is more useful than changing many settings. You do not need to include the confidential information entered into the chat. The following format also works as a mobile note.

Date and time: include the time zone
Interface: mobile app / web / desktop
Model and reasoning settings: what the interface showed
Full error text: record without omissions
Concurrency: number of requests you submitted together
Failure stage: immediately after submission / during reasoning / partway through the answer
Limit notice: whether present and the reset time shown
Comparison: did other conversations finish, and did retrying help?
Network code and request ID: only if obtained

If only one conversation fails, investigate its length and content. If several conversations or devices fail during the same period, account-level or service-side restrictions and incidents are possible. However, failures on several devices using the same connection can still be network-related; the device count alone does not establish the cause.

For problems that persist across browsers, devices, and networks, the official guide recommends sending support timestamps, the model, conversation URL or ID, browser errors, and a HAR file where appropriate. HAR files record network activity and may contain credentials or conversation content. Do not publish raw logs; check their contents and recipient first.

When contacting support, distinguish "the answer stopped partway through," "submission was immediately restricted," and "other conversations completed" rather than simply saying "it is often slow." Consult OpenAI's support contact instructions and send only the information needed for investigation. For this article, we have not contacted support, changed device settings, or submitted large numbers of requests to test restrictions.

Summary: save the full notice, concurrency count, and time

A delivery timeout means the answer did not arrive in full; a Too many requests notice points to a possible request restriction. First save the partial answer, pause new submissions if many chats are active, and check incidents separately from model limit notices. New chats and restarts are diagnostic options, not guaranteed fixes.

We found no evidence that reasoning ability is simply divided according to the number of parallel chats. In practice, assess the failure rate, time until all work finishes, and any model changes. If Codex displays "Selected model is at capacity," that is a different error; see investigating and handling Codex capacity errors.

Frequently asked questions

If an answer finishes but you cannot receive its file, see ChatGPT ZIP download failures and the observed Japanese operation-failed notice. That guide distinguishes generated-link expiry, file existence, and checking the contents of a handoff ZIP.

How many chats can run in parallel?

The official material reviewed did not establish a universally safe concurrency count for ChatGPT. Match the model, interface, and type of work, and first record ordinary completion times and error counts. One user's successful count is not a limit for everyone.

Will upgrading to Pro or buying more fix the error?

There is no evidence that changing plans or making an additional purchase resolves this delivery timeout or the restriction notice whose full text was unavailable. Distinguish an explicitly stated model usage limit from a connection or service failure.

Does closing the mobile app reduce active requests?

We have not established that closing the interface also ends server-side requests. If you want to stop processing, look for a control such as Stop generating. If you cannot use it, record the state, pause additional submissions, and wait for completion or instructions about the restriction.

How many minutes guarantee recovery?

No fixed time has been established. Follow any waiting period or allowance reset time shown on screen. The official 30–60 second advice is an initial step for an apparently stuck response, not the time required to clear a request restriction.