Vercel Serverless Functions — Cold Starts, Timeouts, and Cost

Asha's demo ran perfectly. Every click, every API response, every loading state — exactly as rehearsed. Then a potential pilot customer opened the same link from a coffee shop in Edinburgh, watched a spinner turn for three seconds, and closed the tab. The product hadn't changed. The infrastructure had simply gone quiet between her run-through and his first click. What follows is why that happens on Vercel, and what to do before it costs you the pilot.

Why does your app feel fast in your own demos but slow — or broken — for real users?

Vercel serverless functions shut down after a period of inactivity — roughly five to ten minutes — and must fully reboot the next time someone makes a request. That reboot is called a cold start. You never see it in demos because you are always warming the function yourself. Your first real user, arriving after any quiet period, absorbs the full cost.

This is the structural gap between a demo environment and a production one. When you run through your product before a meeting, you are — without knowing it — pre-heating the infrastructure. The function is alive and ready. Your investor or pilot customer arrives minutes later to a cold server that needs to reconstitute itself before it can respond to a single click. From their side of the screen, the app just looks broken.

The vibe-coded MVP got you here fast — that was the right call. But the same architecture that let you ship in days has characteristics that only surface under real-world usage patterns: intermittent traffic, varying geographic distance, and the simple fact that real users do not arrive on a schedule that keeps your functions warm.

What exactly is a cold start, and how long does it actually take?

A cold start is the time Vercel spends rebuilding the runtime container for your function after it has been deallocated. On Vercel's Hobby and Pro tiers, Node.js functions commonly add between 300 milliseconds and 1.5 seconds of overhead before your code runs a single line. That gap — invisible in testing — is long enough to fail a user's first interaction.

To make that concrete: 1.5 seconds is not a minor inconvenience. Research on web performance consistently places user abandonment thresholds at the one-to-three-second range for first meaningful interactions. A cold start can consume that entire budget before your function has done any work at all. The user sees a spinner. They assume the product is broken. They leave.

The mechanism matters because understanding it tells you where to intervene. Vercel deallocates the container — the small isolated compute environment running your function — after approximately five to ten minutes of inactivity. When the next request arrives, Vercel must allocate a new container, load the Node.js runtime, pull in your function's dependencies, and then — finally — execute your code. Every dependency your function imports adds to that initialization time. A function that imports a large AI SDK, a database client, and several utility libraries on every cold start will always be slower to warm than one that loads only what it needs, when it needs it.

When your function just… stops — what is a timeout and why does it kill AI calls?

Vercel enforces hard limits on how long a function can run: 10 seconds on the Hobby tier, 60 seconds on Pro, 300 seconds on Enterprise. When your function exceeds that limit, Vercel terminates it and returns a 504 error — silently, from the user's perspective. No error message. No explanation. The page simply stops responding.

This is the single most common production failure in vibe-coded apps. The reason is structural: AI-generated MVPs almost always make calls to large language models or external APIs, and those calls can take ten, twenty, or thirty seconds depending on prompt length, model load, and network conditions. On the Hobby tier, a single slow LLM response will breach the limit every time. On Pro, a complex chain of API calls — the kind that feels snappy when the model is fast and the network is clean — will fail the moment conditions degrade.

The failure mode is particularly damaging because it is invisible to you during development. Local testing has no timeout limit. Your staging environment may be on a higher tier than your production one. And LLM APIs are faster when traffic is low — exactly when you are developing — and slower under load, exactly when a pilot customer is trying your product for the first time.

A 504 error does not look like a timeout to the person receiving it. It looks like your product is down.

How does this show up on your bill — and when does serverless stop being cheap?

Vercel bills on two dimensions: the number of function invocations and the GB-seconds of compute consumed — that is, how much memory your function uses multiplied by how long it runs. A single poorly structured AI call can drive both numbers far beyond what the traffic volume would suggest.

The mechanism is compounding. A function that times out does not stop billing at the point of timeout — it bills for the full duration up to the limit. If that function then retries automatically (as many AI SDK implementations do by default), each retry is a new invocation at full cost. A function that loads a large language model SDK and several heavy dependencies on every cold start consumes significant GB-seconds before it processes a single user request. Stack those two patterns together and one inefficient function can account for the majority of a month's compute spend before your pilot has reached any meaningful scale.

This is not a theoretical concern. It is the billing pattern that surprises founders at the end of their first month with real users — a moderate number of invocations producing a bill that feels disproportionate. The serverless model is genuinely cost-efficient when functions are lean and calls complete cleanly. When they are not, costs scale nonlinearly with traffic in a way that a fixed-server model would not.

Three concrete fixes your engineer can ship this week — without touching your core product logic

Your engineer can address the three failure modes above with targeted, reversible changes that leave your product's core logic untouched. None of these require a rewrite. Each can be scoped, tested, and deployed independently.

Move long-running AI calls off the synchronous request path. Any LLM or external API call that might exceed your tier's timeout limit should be handled as a background job or a streaming response — returning an initial acknowledgment to the user immediately and delivering results progressively or asynchronously. This keeps your function's execution time well under the limit and eliminates the silent 504 failure mode. The user experience actually improves: a streaming response feels faster than waiting for a complete result.

Trim your function bundle and lazy-load heavy dependencies. Cold-start latency is directly proportional to how much code your function initializes on startup. Your engineer can audit which dependencies are imported at the top of each function file and defer any that are only needed conditionally — loading the AI SDK only when an AI call is actually being made, for instance, rather than on every invocation. Reducing bundle size and deferring initialization are the two highest-leverage changes for cold-start latency.

Set explicit timeout and retry budgets. Default retry behavior in AI SDKs is generous by design — helpful in a development context, expensive in production. Your engineer can configure explicit maximum retry counts and timeout values for every external API call. This prevents a single slow or failed LLM response from cascading into multiple full-duration invocations and controls your GB-second spend directly.

Each of these changes is scoped to the infrastructure layer. Your product's features, your UX, your data model — none of that moves.

What do you actually do next — and how do you know if it worked?

Before your next pilot meeting or investor demo, run a function-level audit. This means pulling cold-start frequency, average cold-start duration, and timeout rate from your Vercel logs for every function in your app — not just the ones you suspect are slow.

The audit gives you a ranked list of where to act first. Not all functions will have cold-start problems; the ones making AI or external API calls will surface immediately. Your engineer can complete this audit in a few hours and return a prioritized remediation list the same day.

Two metrics tell you the fixes worked. First, median cold-start latency below 400 milliseconds — meaning the typical first-request experience after an idle period adds less than half a second of overhead. Second, zero 504 timeout errors in a 48-hour window under representative load. Both are measurable, specific, and achievable with the three changes above.

The audit is your lowest-risk next step. It does not change the product. It does not require a deployment. It tells you exactly where the gap between your demo and your users' experience is coming from — and gives you a clear, scoped list of what your engineer needs to fix before the next person who matters opens your app for the first time.