Function Duration Limits on Vercel by Plan

Vercel publishes three duration figures per plan and they are not interchangeable. The default is what you get if you configure nothing, the maximum is what you may raise it to, and the extended maximum is a beta ceiling with runtime requirements attached. Quoting the wrong one is how a deployment fails validation.

The table

These are the figures Vercel documents on its Vercel Functions Limits page, which carries a last-updated date of 1 July 2026, for functions running on fluid compute — the default for new projects. All three plans share the same default.

Plan         Default   Maximum   Extended maximum
Hobby        300s      300s      -
Pro          300s      800s      1800s  (beta)
Enterprise   300s      800s      1800s  (beta)

Source: Vercel, “Vercel Functions Limits”, and the same table appears on “Configuring Maximum Duration for Vercel Functions”. Vercel states that the 800-second maximum is generally available for Pro and Enterprise teams, and that the 1800-second extended maximum is in beta.

Why there are three numbers, not one

The default is the value applied when no maxDuration is set anywhere. At 300 seconds it is already generous, and Vercel is explicit that it exists to stop a runaway function consuming resources indefinitely rather than to ration you.

The maximum is the highest value you may configure. On Hobby it is the same as the default, so there is nothing to raise — a maxDuration above 300 on a Hobby project is not a slow function, it is an invalid configuration. On Pro and Enterprise it is 800 seconds.

The extended maximum is 1800 seconds and comes with conditions Vercel lists explicitly: during the beta, durations above 800 seconds must be configured per function in code or in vercel.json rather than as a project-level default, and only certain runtime versions are supported — nodejs20.x, nodejs22.x, nodejs24.x, python3.12, python3.13 and python3.14. Vercel also documents that Secure Compute and Static IPs do not support durations above 800 seconds during the beta, which is the constraint most likely to bite an enterprise team that has already put its functions behind a static egress IP.

The Edge runtime is a different clock

Functions using the Edge runtime are not on this table at all. Vercel documents that they must begin sending a response within 25 seconds, and may then continue streaming for up to 300 seconds. That is two deadlines rather than one budget: a function that thinks silently for 26 seconds and then emits a perfect answer has already failed, while a function that emits one byte at second 2 and dribbles for four more minutes is fine.

For a model call this is the difference between awaiting the whole completion and forwarding the provider’s stream as it arrives. The 25-second rule is the single strongest argument for streaming on the Edge runtime, and it is covered in more detail on the Edge function timeout page.

Setting the value

For Next.js App Router routes, SvelteKit, Astro, Nuxt and Remix, the duration is a property of the function definition. In the App Router it is a named export:

// app/api/summarise/route.ts
export const maxDuration = 600;

export async function POST(request: Request) {
  const { document } = await request.json();
  // ... a long model call
  return Response.json({ ok: true });
}

For Python, Go, Rust, Ruby and older Next.js versions there is no in-code hook, so the value goes in the functions object of vercel.json, keyed on a glob:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "functions": {
    "api/summarise.py": { "maxDuration": 900 }
  }
}

Two details from Vercel’s configuration page that catch people out. Glob order matters — the first matching pattern wins, so a broad api/*.js placed above a specific api/test.js shadows it. And if your Next.js project uses the src directory, the pattern must be prefixed with /src/ or the function is simply not matched and silently keeps the default.

Four ways the value is not what you set

The reason this page exists as a facts page rather than a one-line answer is that maxDuration has more ways to be quietly ineffective than almost any other setting on the platform. All four of these deploy successfully and none of them warns you.

• The glob matched nothing. The functions key is a pattern, not a path, and a pattern that matches no file is not an error. The /src/ prefix above is the classic case; another is keying on a route (api/chat) rather than on the file (api/chat.py). Vercel is explicit that for Python framework apps the whole application builds into one function from its resolved entrypoint, so the key must be that entrypoint file — something like app/main.py — and an /api-shaped pattern will never match it.
• The framework owns the setting. SvelteKit, Astro and Nuxt take maxDuration through their adapter configuration — svelte.config.js, astro.config.mjs, nitro.config.ts — rather than from vercel.json. Setting it in the wrong one of those two places is a no-op.
• The project default is doing the work. Vercel exposes a Default Max Duration field in the project’s Functions settings. A value set there applies to everything with no explicit configuration, which means a function you believe is running on the platform default may be running on somebody else’s decision from six months ago.
• The extended maximum cannot be a default. Vercel states that during the beta, durations above 800 seconds must be configured per function in code or in vercel.json, and that project-level defaults above 800 seconds are not supported. Raising the dashboard default to 1800 is therefore not a route to thirty-minute functions.

The cheap way to confirm which value is actually live is to have the function report it. There is no runtime API that returns the configured duration, so the practical check is behavioural: deploy a route that sleeps past the value you believe is set and confirm it is terminated when you expect rather than five minutes later.

What this means for a model call

Vercel defines the duration as covering the whole invocation including time spent sending the response, streamed responses included. A streaming chat endpoint that takes ninety seconds to finish emitting tokens has used ninety seconds of duration, not the two seconds it took to reach the first token.

The billing consequence runs the other way, and it is the part worth internalising. Under fluid compute Vercel charges Active CPU time, which it documents as pausing while your function waits on I/O, plus provisioned memory time for running instances. A function blocked on a provider’s response is accruing memory time but very little CPU time. Raising maxDuration to accommodate a slow model is therefore not the expensive decision it would have been under per-millisecond wall-clock billing — but it is also not free, and a function that hangs for its full 800 seconds because an upstream call has no deadline of its own is paying for silence.

Set your own timeout on the outbound call rather than letting the platform ceiling be your only deadline. If the function exceeds its duration Vercel terminates it and returns a 504 with the error code FUNCTION_INVOCATION_TIMEOUT, which is covered on the page for that error. And where a job genuinely has no bounded duration, Vercel points at Workflows rather than at a larger number here.