Vercel Functions Hit 30 Minutes: What It Means for You

The headline is simple: Vercel Functions can now run up to 30 minutes, on the Node.js and Python runtimes, for Pro and Enterprise teams. That's more than 2x the previous 800-second ceiling. The detail worth thinking about is why a serverless platform whose whole pitch was "short, stateless, scale-to-zero" suddenly wants your code to run for half an hour.

I read this less as "longer timeouts" and more as Vercel quietly admitting that the AI era broke the old serverless contract. Full announcement is on the Vercel changelog.

---

⏱️ The number that actually changed

Here's the before-and-after, straight from the source:

	Previous limit	New limit
Max function duration	800 seconds (~13.3 min)	30 minutes (1800s)
Runtimes supported	—	Node.js, Python (more "coming soon")
Plan required	—	Pro and Enterprise
Above 800s	—	Beta, requires Fluid Compute

Key takeaway: This isn't a small bump. Going from ~13 minutes to 30 minutes more than doubles the window, and it targets exactly one kind of workload: jobs that wait on something slow.

The "coming soon" on additional runtimes matters if you're on Go, Rust, or an edge runtime. As of this writing, the 30-minute window is Node and Python only. Don't assume your stack is covered until you check.

---

🤖 Why serverless and AI stopped getting along

The original serverless deal was: respond fast, hold no state, scale to zero. That fit web requests. It does not fit a single LLM call that streams a long chain of reasoning and tool calls for several minutes.

Vercel lists the workloads driving this, and they read like a list of everything people are building right now:

• Long LLM reasoning and multi-step tool calls
• AI responses that stream for several minutes
• Document and media processing
• OCR and extraction
• Web scraping and browser automation
• Complex workflow steps or queue handlers

The pattern across all six: most of the clock is spent waiting, not computing. Waiting on a model, a database, a third-party API.

If you've ever shipped a feature that pulls text out of scanned documents, you know this wait. We run a free image-to-text OCR tool on this site, and the slow part is never the CPU. It's the model round-trip. That's the exact shape of work this change is built for.

---

💰 Fluid Compute and the billing trick that makes it affordable

A 30-minute function sounds expensive. The reason it isn't, according to Vercel, is Fluid Compute and how it bills CPU.

Active CPU billing only applies while your code is actually executing. It pauses while your function waits on I/O, such as AI model calls, database queries, and third-party APIs.

This is the part I'd underline for any small team watching its cloud bill. In a naive serverless model, a function that calls an LLM and sits idle for 90 seconds would bill you for all 90 seconds. With active-CPU billing, you're charged for the milliseconds of actual compute, not the idle wait.

Scenario	Naive billing	Active CPU billing
3-min LLM call, mostly idle	Bills ~3 min	Bills only execution slices
OCR job waiting on model API	Bills full wait	Pauses during I/O wait
Web scrape with network stalls	Bills the stalls	Pauses during stalls

One caveat the changelog is explicit about: durations above 800 seconds are in beta and require Fluid Compute. So the long timeout and the cheap billing are tied together. You can't get the 30-minute window on the old compute model.

---

🛠️ How you actually turn it on

You opt in with maxDuration. You don't get long runs by default, which is sensible, a runaway function shouldn't silently bill you for half an hour.

For Next.js App Router, you set it in the route file:

// app/api/long-job/route.js
export const maxDuration = 1800 // seconds = 30 minutes

For other runtimes and frameworks, you configure it per function path in vercel.json:

{
  "functions": {
    "api/long-job.py": { "maxDuration": 1800 }
  }
}

A few things I'd check before leaning on this:

1. Confirm your plan. It's Pro and Enterprise only. Hobby projects don't get the long window.
2. Confirm your runtime. Node and Python today; others "coming soon."
3. Confirm Fluid Compute is on. Above 800s requires it, and it's still beta.
4. Set a realistic ceiling. 1800 is the max, not a target. If your job needs 4 minutes, set ~300, not 1800.

---

💡 What this means for you

If you're a student or solo builder in Sri Lanka shipping side projects on a free or low tier, the headline number doesn't change your day directly, the 30-minute window is gated behind paid plans. But the direction matters, and it's worth understanding even before you pay for it.

For small teams already on Pro, this removes a specific class of ugly workaround. The pattern of "spin up a separate worker queue just because my AI call might take 11 minutes" gets simpler. You can keep more of your pipeline inside one function instead of stitching together a queue, a worker, and a polling endpoint.

Bottom line: The long timeout is for I/O-bound, mostly-waiting work, AI calls, OCR, scraping, media processing. If your job is CPU-bound and genuinely computes for 25 minutes, serverless is still the wrong tool, and you'll feel that on the bill. Match the feature to the workload, not the hype.

My honest read: this is a useful, narrow change. It won't replace your background job system for heavy compute, and it isn't meant to. It just makes the increasingly common "my function spends most of its life waiting on a model" pattern stop fighting the platform. For the kind of AI-glue features most of us are building this year, that's a quietly practical fix.