Netlify Function Timeout and Payload Limits

Netlify publishes six execution and payload limits for functions, and the search that brings people here usually assumes they scale with the plan. They do not. The limits below are flat across every plan and Netlify documents them as not configurable — which is a more useful fact than a per-tier table would have been.

Execution limits

Function type          Execution limit
Synchronous            60 seconds
Scheduled              30 seconds
Background             15 minutes
Streaming (response)   60 seconds

The first three come from Netlify’s “Configuration for functions” page; the streaming figure is stated on the Functions API reference, alongside a 20 MB response size limit for streamed responses. All read on 11 August 2026.

The scheduled figure is the one that surprises people, because it is lower than the synchronous one. A cron-triggered function gets 30 seconds, half of what the same code would get behind an HTTP path, which is why a scheduled model job usually has to dispatch rather than execute. That pattern is worked through on the scheduled functions page.

These are not per-plan

Netlify’s configuration page states that these limits cannot be configured and apply to all functions, and documents no per-plan variation for execution timeouts or payload sizes. There is no Pro tier that raises the 60 seconds and no Enterprise tier that raises the 15 minutes.

That matters for capacity planning in a way a tiered table would not: upgrading does not unblock a job that needs 90 seconds synchronously. The only levers are architectural — stream, move to the background, or split the work — and knowing that upfront saves an upgrade that fixes nothing. It also differs from Vercel, where the ceiling genuinely is a plan property; see the Vercel duration limits page for that table.

Payload limits

Buffered request / response    6 MB
Streamed response              20 MB
Background request / response  256 KB

Netlify notes that binary payloads are base64-encoded, which adds roughly 30% overhead and so reduces the effective binary limit under the 6 MB cap to around 4.5 MB. That figure is Netlify’s own; the arithmetic behind it is that base64 encodes three bytes as four characters, so raw bytes fit at about three-quarters of the stated cap.

The 256 KB background limit is the sharpest edge on this page. It is roughly a twenty-fourth of the synchronous allowance, and a background function is exactly where a developer is most likely to want to post a large document, because it is the one that has fifteen minutes to process it. Pass a storage key, not the bytes.

Edge Functions are separate

Netlify Edge Functions run on a different runtime and have their own limits, documented on their own page:

Code size (after compression)   20 MB
Memory (per deployed set)       512 MB
CPU execution time per request  50 ms
Response header timeout         40 s

The 50 ms figure counts only time spent running your scripts — Netlify is explicit that it excludes time waiting for resources or responses — so a function that awaits a slow model call is not close to it, while a function that parses every streamed chunk may be. The 40-second figure is a deadline on returning response headers, not on the exchange. Both are unpacked on the edge streaming page.

Which limit you hit first

The table is only useful once you know which row applies to you. Mapping the four common AI workload shapes onto it:

• A chat turn. The binding limit is the 60-second synchronous ceiling, and it binds on wall-clock time spent awaiting the provider rather than on anything you compute. Streaming does not move the ceiling — the streamed figure is also 60 seconds — but it changes a slow answer from a hang into visible progress, and it removes the response-size cap from 6 MB to 20 MB.
• A document upload for analysis. The 6 MB buffered request cap binds long before any timeout, and binds harder than it looks because binary content is base64-encoded on the way in. Netlify puts the effective binary ceiling near 4.5 MB, which is a modest PDF. Upload to storage first and pass a key.
• A batch job. The 15-minute background limit binds, and the 256 KB background payload cap binds first if you try to send the work rather than a reference to it. This is the one combination in the table where the two limits pull in opposite directions: the function type with the most time has by far the least room to be told what to do.
• A recurring job. The 30-second scheduled limit binds, and it is the tightest number on this page — half the synchronous allowance, for the function type with no user watching to notice it failed.

None of these four is improved by a plan change. Every one of them is improved by moving the work to a different function type, which is why the useful reading of this table is as a menu of shapes rather than as a set of ceilings to negotiate.

What is actually plan-gated

Two things, and neither is a timeout.

• Memory and vCPU. Netlify documents a default of 1024 MB with a configurable range of 1024 to 4096 MB, or a vCPU value from 0.5 to 2.0 where 0.5 maps to 1024 MB and 2.0 to 4096 MB, available on credit-based Pro and Enterprise plans. The two settings are mutually exclusive — configure one, not both. Set it in the function config as memory: "2gb" or in netlify.toml under [functions.name]. Note that more memory does not buy more time; it buys a faster JSON parse on a 6 MB payload, which is rarely the bottleneck in front of a model.
• Environment variable scopes. Netlify documents scopes — builds, functions, runtime, post-processing — as a Pro and Enterprise feature. On a plan without them every variable applies to every scope, which is the practical reason a key can reach a build log on a lower plan. See the environment variables tutorial.

Background functions themselves are available on the credit-based Free, Personal and Pro plans and on Enterprise plans, per Netlify’s background functions page — so the 15-minute limit is reachable without an upgrade, which is the answer to the question most people are really asking when they search for a per-plan timeout table.

One more thing explains why the answers you find elsewhere disagree with each other. Netlify’s functions usage and billing page documents two billing generations side by side — credit-based plans and legacy plans — and the plan-gated features above are described against the credit-based ones. A guide written under the older generation is describing genuinely different tiers with overlapping names, which is enough to make two confident and contradictory answers both look correct. When you check a plan-gated limit, check which billing generation your team is actually on first; the usage and billing page in your own dashboard is the only authority on that, and no figure on this page or anywhere else can answer it for you.

Consumption limits are the other thing genuinely tiered, and deliberately absent from this page. Netlify meters function execution in GB-hours and counts edge function invocations per month, and the included allowance varies by team plan. Those figures are not reproduced here because they are the fastest-moving numbers Netlify publishes and a stale one would be worse than none — read them from the usage and billing dashboard for your own team, which shows consumption against allowance rather than the allowance alone.