OpenAI API timeout: why the AI feature hangs, the OpenAI timeout to set, and the host clock that runs out first

An OpenAI API timeout means the call to the model ran past a deadline and something gave up waiting. The OpenAI client waits 10 minutes by default, but the function your app runs in usually stops far sooner: 60 seconds on a Netlify function, 150 on a free Supabase Edge Function. The shorter clock wins.

What an OpenAI API timeout is, and which clock ran out

An OpenAI API timeout is a call that outlived one of two deadlines: the OpenAI client’s own, 10 minutes by default, or the host’s limit on the function making the call. On Supabase Edge Functions and Netlify’s standard functions, the host’s limit is the shorter one.

Every outside call an app makes needs a limit of its own, and the model call is only one of them; the wider set of controls is laid out under resilience for a SaaS app built with AI. So when a user reports an OpenAI timeout error, the useful first question is which of the two clocks fired, because each one has a different fix.

The table puts the OpenAI client’s default next to what each host publishes for the function that makes the call.

The host figures come from Supabase’s Edge Function limits and Netlify’s function limits, as both read on October 20, 2026. For an app on Vercel, compare the same client default with Vercel’s own function time limit.

On three of the four rows, raising the OpenAI timeout moves a clock that was never going to fire, which is why we treat it as the wrong first change whenever the host’s limit is shorter.

Retries stretch the wait further. The Python client’s README says “Certain errors are automatically retried 2 times by default, with a short exponential backoff”, and that requests that time out are among them, so a call that was always too slow can be attempted up to three times before your code hears about it.

APITimeoutError: Request timed out, and the errors that look like it

APITimeoutError: Request timed out is the OpenAI client’s name for a request that took too long, and OpenAI’s error guide says to retry after a brief wait. A 504 or another gateway error from your own host, with no OpenAI error name, is a different failure: the host stopped first.

In Python the error arrives with the package name in front, as openai.APITimeoutError followed by the message Request timed out., and the README says the client throws it whenever its own deadline passes. The Node client gives the same failure a different name, APIConnectionTimeoutError. OpenAI’s error-code guide explains the Python error as a request that “took too long to complete and our server closed the connection”, and lists the likely reasons as “a network issue, a heavy load on our services, or a complex request that requires more processing time.”

Three other failures look the same from the screen. The guide’s stated causes are what tell them apart.

Not every 429 is about speed: OpenAI’s guide also lists 429 errors for exhausted prepaid credits and for a reached spend or usage limit, and retrying those “won’t restore API access.” Waiting out a rate-limit 429 properly means retries that wait longer each time, and a rejected key has its own fixes under an invalid API key error.

The last row is the hard one to trace. The host ended the function while the call was still open, so your code caught nothing and wrote nothing to a log; the clue is a host error, such as Supabase’s 504, that arrives when the host’s limit runs out. Some agent and automation tools that wrap the API also print their own wording when a stream sends nothing inside their window; the streaming fix below explains that case. Azure OpenAI is a separate Microsoft service, and its timeout settings are not covered here.

What the person waiting on the screen sees

Nobody using your app sees an error name. They see one of three things, and each carries more risk for you than the one before.

The first is an error message. That is the good case: something caught the failure and said so, and the person can try again. The wider design job behind it is how you keep the app usable when a provider fails, so a slow model takes down one feature and leaves the rest working.

The second is a spinner that never stops. The request already failed and the screen was never told, which is the pattern behind an error the screen never hears about. The person decides how long to be patient, and the app looks broken in a way no log records.

The third is a blank or half-finished answer. It reads as a weak feature, so it tends to come back as a quality complaint long before anyone files it as a bug.

Providers do have slow nights. OpenAI’s own write-up of an incident on June 2, 2026 says that from about 9:46 PM to 12:01 AM Pacific time, Responses API “requests took longer than normal to begin generating responses”, and it traces the cause to a “configuration rollout that caused an internal service to repeatedly establish connections” to a shared backend dependency. The lesson we take from it: on a night like that, an app with its own deadline shows users a message, and an app without one shows a spinner until the host gives up.

We audited 21 third-party apps in June and July 2026, and across all 21 scored apps the Reliability & Correctness pillar averages 31.4 out of 100. Those apps were picked for audit rather than drawn at random, so the number describes that group, not AI-built apps as a whole.

If the AI feature is something customers pay for, and the call runs in a function you cannot open or a builder you cannot change, that is the point to bring someone in: a free audit is where we weigh up with you whether your feature needs a shorter deadline, streaming or background work. In the Production Hardening Sprint, deliverable 6.4 sets deliberate timeouts for AI, email, payment, and other external calls, and deliverable 3.11 gives every model-backed feature a timeout with a fallback when the provider is down.

How to set the OpenAI client timeout, then stream or move the work

Three fixes help, in this order: an OpenAI client timeout you choose, streaming the answer, and moving long work into the background.

Give the call a deadline below the host’s limit

The default timeout is long: the Python client’s README says “By default requests time out after 10 minutes.” For an OpenAI API call from JavaScript, the Node client has the same default timeout, “Requests time out after 10 minutes by default”, and it reads timeout in milliseconds. Changing the OpenAI SDK timeout takes one option on the client, or one on a single call.

from openai import OpenAI

client = OpenAI(timeout=20.0, max_retries=0)  # defaults: 10 minutes, 2 retries
client.with_options(timeout=20.0).chat.completions.create(...)  # one call only

import OpenAI from 'openai';

const client = new OpenAI({ timeout: 20 * 1000, maxRetries: 0 }); // milliseconds
// one call only: pass { timeout: 20 * 1000 } as the second argument to create()

The OpenAI API timeout parameter is called timeout in both clients, and it sits beside the retry setting, max_retries in Python and maxRetries in Node, where 0 turns retries off.

Pick a number below the host’s limit. We’d set something like 20 seconds under a 60-second cap, so the failure turns into an exception you catch, a message the user sees and a log line with a name; a number above the host’s limit buys nothing, because the host ends the function first. Turn retries down at the same time: with the default two retries, we’d expect three 20-second attempts to run past a 60-second cap, and the host cuts the last one off anyway.

The same habit applies to deadlines on every outside call, from email to payments. What to catch and what to log when the exception lands in a Python backend is part of error handling in Python for a live app. The settings above are quoted from the two SDK READMEs as they read on October 20, 2026; we did not run them for this article.

Stream the answer so the first words arrive

Streaming sends the answer while it is still being written. OpenAI’s streaming guide says it “lets you start printing or processing the beginning of the model’s output”, sent over server-sent events.

It does not make the model faster, and it does not stop the host’s clock: a job that needs four minutes still ends when a host with a 150-second wall-clock limit stops it. What it fixes is the spinner and the blank box, because words appear while the rest is on its way.

If your app was built in Lovable, you may already have it. Lovable’s AI connector docs say the built-in connector “supports streaming responses with server-sent events (SSE)” and that “Lovable uses streaming by default for chatbot and assistant features”. A summary or a generator outside chat may not stream, so ask. The stream timeouts some agent tools report come from the same mechanism seen from the other end: a stream that sends nothing inside the tool’s window.

Answer at once and deliver the result later

This fix takes the wait out of the request altogether. Two routes are documented, one on OpenAI’s side and one on the host’s.

OpenAI’s background mode starts the work without holding the connection open: you “make an API request with background set to true”, then check on it, and OpenAI’s instruction is to “Keep polling while the request is in the queued or in_progress state.” OpenAI also notes that “Background responses are retained after the polling period only when store=true is explicitly provided”; without it, the response is deleted after roughly 10 minutes, so keep the result in your own database once it arrives.

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 initial 202 response.

For the user, the request returns straight away and the answer lands later: a status that fills in, a notification or an email. Queues, workers and job status belong with moving long AI work off the request.

Retries on a slow call ask for the same work several times, and what failed attempts add to the model bill grows with them. Whether OpenAI bills a call that was cut off midway is not stated in OpenAI’s error-code guide.

Which fix you can do in Lovable, Replit or Base44

On a builder, what you can change is what the builder documents. The table sets out what each of the three says about the place the AI call runs, checked on October 20, 2026.

A limit the docs leave out can still be there, and you find it the day a call runs past it. If you know your app sits on Supabase or Netlify underneath the builder, use the published numbers in the two-clocks table.

On Lovable the change is a sentence in chat. Its edge functions page says “There is no create button in the Edge functions view”, and offers View code to read the function and View logs to see what happened. Name all three fixes in one request: a deadline on the model call below the host’s limit, a streamed answer, and a clear message for the user when the deadline passes.

On Replit the lever is the deployment type. We’d keep Autoscale for short requests; work that has to keep going after the browser closes fits a Reserved VM, and work that runs on a timetable fits a Scheduled deployment.

On Base44 the call’s timeout belongs to the platform, and its integrations page does not print one; a request to a backend function that makes the call is terminated past its 5-minute limit. A slow AI step there is the same two clocks with Base44 holding one of them, while an app that drags for other reasons is a different job: a Base44 app that slows down.

Who makes the change depends on where the call lives. Doing it yourself works when the builder exposes the call and the fix is a prompt. A freelancer fits when one function needs a deadline and someone has to read the code to place it. Agencies make sense when the feature is being rebuilt anyway. A fixed-scope service like ours fits when timeouts, background work and the fallback all need doing at once.

How to check that your AI feature fails safely

An AI feature fails safely when a slow model gives the user a clear message within the deadline you chose, nothing is retried without limit, and long work finishes in the background with a visible status. The test is to make the provider slow on purpose and watch.

Run each check in a test environment and keep the evidence it names.

1. 01 Make the provider slow on purpose: point the model call at a proxy that delays the reply, or at an address that never answers. Time how long the user waits and keep the timing.
2. 02 Confirm the user sees a clear message before your deadline passes, not a spinner, and that the log line names the timeout. Keep a screenshot and the log line.
3. 03 Count the attempts in your server logs and check they match what you set: retries off, or the number you chose. Keep the log excerpt.
4. 04 Start a long task in the background and confirm it finishes after the normal request window, with its status visible to the user. Keep the job record.
5. 05 Make the model fully unavailable and confirm the rest of the app still works. Note which screens you tried.

In the Production Hardening Sprint, deliverable 6.4 is verified this way: simulate a slow dependency and confirm bounded waits and a useful failure state. Deliverable 6.6 is verified by running a long task beyond the normal request window and verifying completion and user-visible status.

Common questions about OpenAI timeouts

Why is my API timing out?

Your API call is timing out because it outlived a deadline: the client’s own, or the host’s limit on the function making the call, and a slow model or a long job is what pushes it past one of them. The OpenAI client waits 10 minutes by default, while a Netlify synchronous function stops at 60 seconds. Set your own deadline below the host’s limit and move long work off the request.

Is OpenAI currently down?

OpenAI’s status page at status.openai.com shows whether the API has an incident right now, with separate components such as Chat Completions and Responses and an option to subscribe to updates. If it shows no incident while your app keeps timing out, look at your own deadline and your host’s limit first.

Why is OpenAI API not working?

The error name usually says why the OpenAI API is not working: APITimeoutError means the request ran too long, RateLimitError or a 429 means requests are arriving faster than your limit allows or your credits or spend limit ran out, and AuthenticationError means the key was “invalid, expired, or revoked.” With no error name at all, check OpenAI’s status page for an outage, then your host for a 504 or another gateway error.

Why does ChatGPT keep timing out?

ChatGPT timeouts are OpenAI’s to fix, because ChatGPT is OpenAI’s own app, listed on its status page apart from the API. An AI feature in your app works differently: it calls the API through your code and your host, so it times out when the OpenAI client’s deadline or the host’s limit runs out first.

When is it time to get help with an AI feature that keeps timing out?

It is time to get help when the timeouts reach paying users, when the call runs where nobody on the team can change it, or when retries start to show on the model bill; at that point a fix from someone who can read the code is usually a better next step than more prompting. AxonBuild runs a free audit, where we go over with you where your AI calls run and what your users should see when the model is slow.