Vercel 800 s max duration: do you still need a Sume webhook?
Vercel Pro allows 800 s functions and a 30-minute beta. A Sume video job can still outlast one request, so use async or webhook mode and return in seconds.

Yes, still use a webhook or a poll. Vercel now lets Pro and Enterprise functions run for up to 800 seconds, with an extended beta up to 1,800 seconds, but a Sume sync wait is capped at 30 seconds and a video job has no promise to finish inside any one function. Submit, store the job id, return, and let the terminal event or a status poll finish the work.
The Vercel numbers
The Vercel duration page (last updated 2026-08-24) lists the Fluid compute limits. Durations above 800 seconds must be set per function, in code or vercel.json, not as a project default. Secure Compute and Static IPs do not support values above 800. For a FastAPI app, key the functions entry on the entrypoint file, for example app/main.py.
| Plan | Default | Maximum | Extended beta |
|---|---|---|---|
| Hobby | 300 s | 300 s | Not listed |
| Pro | 300 s | 800 s | 1,800 s |
| Enterprise | 300 s | 800 s | 1,800 s |
The Sume side
sync and subscribe modes clamp wait_timeout_seconds to 0 through 30. When the job is still running the response says sync.timed_out and gives a status_url. The default mode is async.
A longer function does not change the job. If your function times out, the job keeps running and bills; read the job again instead of submitting a second one.
| Setting | Value |
|---|---|
wait_timeout_seconds | 0 to 30, clamped |
| Webhook retries | Up to 10, 30 s apart |
| Per-attempt timeout | 10 s |
| Replay window | 300 s default |
When a long function is useful
A long function fits work that you cannot split, such as a single download of a large file. It does not fit a wait on a render. The beta runtimes are Node 20, 22 and 24, Bun 1.x and 1.4.x, and Python 3.12 to 3.14.
- Submit with
mode: "webhook"and a public HTTPSwebhook_url. - Verify the
sume-v1signature on the raw body. - Dedupe on
job_id. - Keep a cron or a user-triggered poll on
status_urlas a fallback.
Cost of getting it wrong
A function that waits on a video holds a billed instance for the full wait. A webhook route runs for milliseconds. Even at 800 seconds, one slow job still blocks one request slot.
Setting the duration for the route you keep
If you keep a route that calls Sume, set its maxDuration to the small value it needs, not to the maximum. A submit takes a second or two. The Vercel page says values above 800 seconds must be set per function, and the extended beta does not work with Secure Compute or Static IPs, so a project that uses either cannot rely on it at all.
For a Python app on FastAPI, the functions key must name the entrypoint file such as app/main.py.
Use the shortest path that fits the job.
- Image jobs that finish in seconds:
mode: "sync"with a wait under 30 seconds, then poll ifsync.timed_outis set. - Video, avatar and audio jobs:
mode: "webhook"and a signed receiver. - Anything you cannot guess:
asyncand a poll that followsnext_poll_after_seconds.
Sources
Related posts
More in Developers
- Vercel's 300 s default: does a 30 s Sume image sync call fit?
Yes: with fluid compute the default is 300 seconds, far above the 30-second Sume image wait. Branch on 200, 202 and 502, and poll video jobs instead.
- Verify a Sume Format webhook in Python: empty secret, stale timestamp
A Python check for the Sume format.run.terminal webhook: HMAC-SHA256 over timestamp.raw_body, a 5-minute window, and a refusal to run with an empty secret.
- Verify a Sume avatar video webhook signature in Python
A Python verifier for Sume job webhooks: HMAC SHA-256 over timestamp.raw_body, sume-v1 entries, a 5-minute window, and a refusal when the secret is empty.
- Verify a Sume agent.run.terminal webhook in Python
Python HMAC-SHA256 check for a Sume run webhook: sume-v1 signature over timestamp.raw_body, a five-minute window, and a verifier that refuses an empty secret.
Written by Sume