Edge Function Timeout Limits on Vercel

The Edge runtime’s limit is not a maximum duration in the way the Node.js runtime’s is. It is a deadline for starting to respond, after which a longer budget applies. Getting that distinction right changes which fix you reach for.

The rule: 25 seconds to first byte

Vercel documents Edge runtime functions as needing to begin sending a response within 25 seconds to maintain streaming capabilities beyond that period, and as being able to continue streaming data for up to 300 seconds.

Two numbers, doing different jobs. The 25 seconds is a time-to-first-byte deadline. The 300 seconds is how long the response may keep flowing once it has started. A function that returns nothing for 24 seconds and then streams for four minutes is inside both. A function that computes silently for 30 seconds and then returns a complete JSON body is outside the first, even though its total time is well under the second.

Vercel also notes on the same reference that it recommends migrating from Edge to Node.js for performance and reliability, both runtimes running on Fluid compute with Active CPU pricing, and that from Next.js 16.3 setting runtime = 'edge' is no longer supported — routes and pages run on Node.js. If you are choosing today rather than diagnosing an existing deployment, that is the more consequential sentence on this page.

Where a model call hits it

A chat completion that is not streamed produces its first byte when the whole answer is ready. Generation time scales with output length, so the requests that break the 25-second deadline are the long ones — and they break it intermittently, which is what makes this hard to catch before production.

The shapes that run into it, roughly in order of frequency:

• A non-streamed long completion. Ask for a 2,000-word document and wait for the closing brace before writing anything.
• A reasoning model. Extended thinking happens before the first visible token, so time-to-first-byte can be most of the request even when the visible answer is short.
• Sequential calls before the response. Embed, then retrieve, then call the model, then post-process, then return. Each step is fine; the sum crosses 25 seconds on a slow day.
• A retry hidden in a client library. Two attempts at 15 seconds each is 30 seconds, and the code reads as one call.

The common thread is that all four are fixed by producing output earlier, not by asking for more time — which is the point of the section below.

How the Node.js runtime differs

The Node.js and Python runtimes on Fluid compute have a plain maximum duration rather than a first-byte deadline. Vercel documents the defaults and maxima as: Hobby, 300 seconds default and maximum; Pro and Enterprise, 300 seconds default with an 800-second maximum, and an extended maximum of 1,800 seconds documented as in beta and requiring per-function configuration on specific runtime versions.

So the runtimes fail differently in a way that matters for diagnosis. On Node.js, a function that thinks silently for 200 seconds and then responds is fine. On Edge, it is not. If you moved a route from one runtime to the other and it started timing out at a threshold that looks arbitrary, this is why. For the per-plan Node.js numbers and how maxDuration is configured, the function duration page is the one to read.

What the timeout looks like

Vercel documents that a function which does not complete within its duration returns a 504 with the error code FUNCTION_INVOCATION_TIMEOUT. From the browser it is a 504 page or a rejected fetch; in your logs it is a request with no completion.

The diagnostic that distinguishes a first-byte timeout from a total duration timeout is whether any bytes arrived. If the client received headers and a partial body before the failure, you were streaming and hit something else — a 300-second ceiling, an upstream disconnect, or a client abort. If the client received nothing at all, you missed the first-byte deadline. Logging a timestamp at the moment you write your first chunk is the cheapest way to tell these apart after the fact:

const t0 = Date.now();
// ... upstream work ...
console.log(JSON.stringify({ event: "first_byte", ms: Date.now() - t0 }));

Watch the distribution of that number, not its average. A p50 of four seconds and a p99 of 26 is a route that fails for one user in a hundred and looks healthy on every dashboard that reports a mean. The dedicated fix page starts from the error string itself.

The three fixes, in order

1. Stream. This is the answer for almost every model-backed route, because it converts the constraint from “finish in 25 seconds” to “start in 25 seconds”, and a provider’s first token typically arrives in one or two. The mechanics are in the edge streaming tutorial.
2. Send something immediately. Where the work genuinely cannot start producing output — a long retrieval before any model call — you can open the response with a keep-alive comment frame and fill it in later. This is a real technique and it is also a way of hiding a slow route from your own monitoring, so use it knowing that.
3. Stop responding synchronously. If the work takes minutes, no HTTP timeout is the real problem. Accept the request, return a job id, do the work in a background function or a queue, and let the client poll or subscribe. Vercel documents Workflows for workloads that need unlimited execution time.

What is not on the list is raising a timeout, because on the Edge runtime there is no knob for the 25-second deadline. That absence is the practical meaning of the distinction at the top of this page.