OpenAI API Timeout: Why Your App's AI Feature Hangs, Then Fails

An AI feature in your app spins for a while, then shows an error, and somewhere in that error is the phrase Request timed out. Search that phrase and there is no shortage of advice. Almost all of it was written for somebody sitting in front of a Python file they can edit, on a laptop, with no host anywhere in the picture. Your app is a different situation. It was built in Lovable or Replit or Base44, or by a developer who has since moved on, and the call that failed is running somewhere you have probably never opened.

On most of the hosts an AI-built app runs on, the host’s clock is shorter than OpenAI’s, so the host is the one that hangs up first. The OpenAI client waits ten minutes by default. Supabase Edge Functions stop at 150 seconds on the free plan and Netlify stops a synchronous function at 60. The shorter clock is almost never the one people change.

The numbers below are the ones each vendor publishes about itself. On 25 August 2026 I read OpenAI’s error-code reference and the timeout and retry sections of its Python client, then the execution limits Supabase and Netlify publish for their functions, then what Lovable, Replit and Base44 say about where an app’s server code runs, and put the two clocks side by side. Nothing here comes from running an app.

The fix the first page of Google recommends for this error is to raise the OpenAI timeout. On most of the places an AI-built app actually runs, that changes nothing a user will ever notice. The rest of this page is why, and what to do instead.

What APITimeoutError: Request timed out actually means

OpenAI is brief about this error, and the brevity is worth reading closely. OpenAI’s error-code reference gives the cause as “Request timed out.” and the solution as “Retry your request after a brief wait and contact us if the issue persists.” The explanation underneath it is one sentence: “A APITimeoutError error indicates that your request took too long to complete and our server closed the connection.”

Read that as a statement about who acted. OpenAI’s server closed the connection, because your request took too long to complete. Nothing in it mentions your host, your plan, or the sixty seconds your function may have had. If the error in front of you carries this name, the conversation between your code and OpenAI got far enough for OpenAI to be the one that ended it.

Several failures look identical on the screen and are nothing like this. The same reference names them separately, and their stated causes are what separate them.

That last row is the one that catches people out, because there is no OpenAI error in it. The host ended the invocation while the model was still writing, so your code never got an exception and OpenAI never got the chance to send one. What you have left is a gap in the logs and a 504 at the door.

One more lookalike is worth naming, because search results push it hard. A thread on OpenAI’s own community forum ranks on the first page for this error with a snippet saying the fix was to change the API key. I read that as a snippet on 25 August 2026 and did not fetch the page, so community.openai.com/t/suddenly-facing-timeout-errors/1130257 stays unlinked here: one forum reply is not vendor guidance, and a snippet is not a reading. A rejected key produces a different error with a different name, and the whole family of key errors reads differently.

Two clocks are running on your AI call, and the shorter one wins

Start with the clock the documentation is loudest about. The OpenAI Python client’s README states it plainly: “By default requests time out after 10 minutes.” The same README states the retry behaviour: “Certain errors are automatically retried 2 times by default, with a short exponential backoff. Connection errors (for example, due to a network connectivity problem), 408 Request Timeout, 409 Conflict, 429 Rate Limit, and >=500 Internal errors are all retried by default.”

Ten minutes, and up to three attempts before your own code hears about any of it. That is the patience your app has out of the box, on the day nobody has set a number.

The second clock belongs to whoever runs your server code. It publishes its own limit, and it does not ask the OpenAI client’s opinion.

On three of the table’s four rows, the host hangs up first, which means raising the OpenAI timeout moves a clock that was never going to fire.

What the ceiling is on Vercel specifically, plan by plan, and whether your plan lets you move it, is the platform half of this same failure.

The Netlify background row is the one place where the order flips, and it is the whole argument for the third fix further down. Give the work fifteen minutes and the client’s ten-minute default becomes the short clock, which is a much better problem to have: it is a number you control, in a file somebody can open, rather than a ceiling on somebody else’s platform.

Retries have a second consequence that nobody notices until the invoice. A call that was always going to be too slow gets tried up to three times, which is three lots of work asked for and at most one answer used. Whether OpenAI bills an attempt it cut off is not something its error reference states, and attempts that produced nothing for a customer are one of the lines that decide what the extra attempts do to your model bill.

One failure that lands in the same place on the screen has no clock in it at all. A 402 Payment Required from Lovable’s AI connector means the workspace ran out of credits while the request was in flight.

What the person waiting on the screen actually sees

Nobody using your app sees an error name. They see one of three things, and the three carry very different amounts of risk for you.

The first is an error message. That is the good outcome: something caught the failure and said so, and the person knows to try again or go elsewhere.

The second is a spinner that never stops. The request already failed and the screen was never told, so the person sits there deciding how long to be patient, and the app looks broken in a way no log records. That is the same class of problem as any other case where the request failed and the screen was never told.

The third is a blank or half-finished result that reads as though the feature simply had nothing to say. This one gets reported as a quality complaint rather than a bug, and it can sit in a product for months.

The vocabulary people use for all three is the same, and none of it is technical. One founder built an internal assistant so the ops team and the non-technical staff could ask questions about the product and the code. When they wrote about it in public, the verdict they gave it was that it was too slow. That is how a call that takes too long gets described from the outside, long before anybody opens a log.

An answer that arrives after nine seconds is a slow feature and you measure it; an answer that never arrives is a broken one and you decode it.

Give the call a deadline you picked

The OpenAI client lets you set both numbers, either for the whole client or for one call. Its README shows the shape:

client = OpenAI(
    timeout=20.0,    # default is 10 minutes
    max_retries=0,   # default is 2
)

# or one call at a time
client.with_options(timeout=5.0).chat.completions.create(...)

That is the whole mechanism, and the useful part is knowing which number to pick.

A number below your host’s limit is the only version of this that changes anything. Twenty seconds under a sixty-second cap buys you an exception you can catch, a message you can put on the screen, and a log line with a name in it. One hundred and twenty seconds under the same cap buys nothing: the host will have ended the invocation a full minute before your deadline ever arrives.

That is the honest correction to the most-read advice on this error. In OpenAI’s own forum thread on frequent timeouts, read on 25 August 2026, the top answer comes from a community member rather than OpenAI staff, recommends raising the timeout “higher to 120 seconds+”, and explains that “A 20 second timeout terminates a non-streaming response before you receive any text, even if the AI is still generating.” Every word of that is correct about the model and silent about the host. On Netlify, where a synchronous function is capped at 60 seconds and the cap is listed as not configurable, a client set to 120 seconds names a moment that will never arrive.

So the job of a client deadline is smaller than the search results make it sound, and more useful. It turns a hang into a fast, catchable failure. It gives you something to show the user in five seconds instead of a spinner they abandon in ninety. And it puts the decision about how long is too long in your code, where you can change it, rather than in a platform default you did not choose.

One thing worth checking before you set anything: whether a deadline used to be there. It is one line of code, and one line is exactly the sort of thing that goes missing when the feature worked last week and an edit is what changed.

Send the answer as it is written, not after it is finished

Streaming does not make the model faster. It changes what the person watching gets: first words in a second or two, instead of a blank box for forty seconds followed by either an answer or an error.

If your app was built in Lovable and uses its built-in AI connector, you may already have this and not know it. Lovable’s AI documentation says the connector “supports streaming responses with server-sent events (SSE)” and that “Lovable uses streaming by default for chatbot and assistant features, so responses appear token by token rather than all at once.” Two useful facts sit in the same sentence: the default is on, and it covers chat and assistant features rather than everything your app might ask a model to do.

The caveat, in this page’s terms, because it is easy to get wrong: streaming changes when the reader sees something, and it changes nothing about how long your host lets the work run, so a job that needs four minutes still ends at exactly the same moment on a host that stops at 150 seconds.

Where streaming earns its place is on the first two of the three outcomes above. It removes the blank box, and it tells the person on the other end that the model is working rather than gone. On a feature that produces a paragraph, that is often the entire complaint fixed.

Answer the request straight away and deliver the result later

The two fixes above make the failure faster and easier to explain. This one removes it, and it is the part the current search results for this error never reach.

Two routes are documented, one on OpenAI’s side and one on your host’s, and a real app usually ends up using both.

OpenAI publishes one on its own side. Background mode starts the work without holding a connection open: “To start response generation in the background, make an API request with background set to true”. Your code gets an identifier immediately, then asks for progress. OpenAI’s instruction is to “Keep polling while the request is in the queued or in_progress state. When it leaves these states, it has reached a final (terminal) state.” A stream that drops can be picked up again from where it stopped using a starting_after cursor. One caveat travels with it: OpenAI documents that “Response data is temporarily stored to disk for roughly 10 minutes to enable asynchronous execution and polling”, so the result is somewhere to collect an answer from, never somewhere to keep it.

The other route belongs to your host. Netlify background functions “run for up to 15 minutes and don’t need to complete before a visitor can take next steps on your site”, and the caller gets an immediate 202 rather than a wait. Netlify lists them as available “on Credit-based plans, including Free, Personal, and Pro” and on Enterprise plans.

Lovable already ships this exact pattern for the one job it knows takes minutes. Its AI page says generating a video clip “usually takes around 1-2 minutes, so video works differently from chat or images: the clip is generated in the background, and your app checks on it until it is done.” The vendor has written the fix down, applied to a different feature than yours.

Long work sitting where somebody has to wait for it does not get reported as a timeout. One founder wrote in public about giving up on a product, then finding out what had been happening while they were gone:

Hundreds of people had signed up and created projects. But almost all have submitted very constructive feedback: The app was not working properly as a web app. It was very hard to edit large videos, and uploading was taking time.

That is a video app rather than a model call, and the shape is identical: work that takes minutes, sitting where a person is waiting for a page to answer. “Not working properly as a web app” is the review that arrangement earns, and it arrives as product feedback rather than as an error report, which is why it can run for months without anybody filing a bug.

What changes for the person on the other end is the shape of the wait, not its length. The request comes back straight away with a ticket. The answer lands when it is ready, in a notification, an email, or a row that fills itself in. Nobody sits watching a spinner, deciding whether the app is broken.

Which of the three you can actually do in Lovable, Replit or Base44

Every fix above assumes somebody can change something. On a builder, what you can change is whatever the builder documents, so here is what each of the three publishes about the place your AI call runs.

The blanks in the middle column are a finding, not a gap in my reading. Three vendors publish no execution limit for the place your AI call runs, which does not mean there is no limit. It means you cannot look one up, and the first time you learn the number is the day a call runs past it. If you know your app sits on Supabase or Netlify underneath the builder, use the numbers in the two-clock table instead, because those are published.

In Lovable the answer to every column is a sentence in chat rather than a file you open. Lovable’s edge-functions documentation is explicit about it: “There is no create button in the Edge functions view: Lovable writes and deploys functions as part of building the feature you describe.” What you get instead is View code to read what it wrote and View logs to see what happened, and for anything on a schedule the page sends you to Jobs. So the ask is a sentence, and it should name all three fixes at once: put a twenty-second deadline on the model call in this function, stream the response, and show the user a real message when the deadline passes. The dated absence of a documented limit is worth carrying into that conversation, and it is why the Cloud page is no help here either.

On Replit the lever is which deployment type your app is on. An Autoscale deployment scales to zero and back up, which is the right shape for a web app and the wrong shape for a job that has to keep running after the browser has gone. A Reserved VM keeps a machine, and a Scheduled deployment runs on a clock, which between them cover most of what “take the work off the request” means on Replit. The deployment types page is where I looked for a request limit on 29 August 2026 and found none documented.

Base44 is the most locked down of the three and the least documented on this question. Its integrations page lists Invoke LLM alongside SendEmail, SendPushNotification, UploadFile, GenerateImage and ExtractDataFromUploadedFile, and says of custom integrations that “Calls are proxied through the Base44 backend, so secrets never reach the browser”. Useful for keeping credentials out of the browser, and it also means the timeout on that call is Base44’s, not yours, and Base44 does not print it. Where each of Lovable’s other joins to an outside service breaks, join by join, is its own list.

Common questions about OpenAI API timeouts

What does APITimeoutError: Request timed out mean?

APITimeoutError means OpenAI’s server closed the connection because the request took too long to complete. That is OpenAI’s own wording in its error-code reference. It says nothing about your host, and on most hosts an AI-built app runs on, the host’s own limit is shorter than the client’s ten-minute default.

What is the default OpenAI API timeout?

Ten minutes. The OpenAI Python client’s README says “By default requests time out after 10 minutes”, and the same default is what makes the number so easy to overlook: almost nobody’s app gets ten minutes from the platform it runs on, so the client default is rarely the limit that fires.

Does OpenAI retry a timed-out request automatically?

The client does, twice. Its README says “Certain errors are automatically retried 2 times by default, with a short exponential backoff”, covering connection errors, 408, 409, 429 and 5xx responses. One call from your code can therefore become three attempts, and you can turn that down with max_retries.

Should I just increase the OpenAI API timeout?

Raising the timeout only helps if your number lands below your host’s execution limit. Above it, the host ends the invocation first and your deadline never arrives. Setting it below the host’s limit is what turns a silent hang into an error you can catch and explain.

Why does my AI feature work in the preview and time out for real users?

Preview traffic is short prompts, small inputs and one person. Real users send longer prompts, bigger documents and more of them at once, and a model call that took four seconds in testing can take forty in production. The limit never moved. The work grew into it.

Is a timeout the same as a rate limit or a bad API key?

No. OpenAI gives each a different name and a different cause: RateLimitError for “You have hit your assigned rate limit”, AuthenticationError for a key that was “invalid, expired, or revoked”, and APITimeoutError for a request that ran too long. A 504 with no OpenAI name in it is a fourth thing entirely, and it points at your host.

Can I fix this myself in Lovable or Replit without writing code?

Lovable is the one where the answer is a clear yes. Its documentation says there is no create button for edge functions and that it writes and deploys them from what you describe, so a deadline, streaming and a visible error message are all things you ask for in chat. On Replit the equivalent move is choosing the right deployment type for work that outlives a request.

Does a timed-out call still cost me money?

OpenAI’s error-code reference does not answer that, and this page will not guess. What is documented is the multiplier: the default of two automatic retries turns one slow call into up to three attempts, so a feature that times out repeatedly is asking for the same work several times over and using none of it.