TL;DR

Under Fluid compute, a function with maxDuration = 1800 starts a new instance roughly every 30 requests. The same code at 300s or 800s starts one every 600–700 requests. Requests routed to those new instances spend ~2.2–3.0s on the platform before the handler runs. This shows up as a separate latency peak at 2.25–3.25s, and it dominated our p95/p99. Moving everything except one genuinely long route to ≤800s removed it. Sharing the numbers in case they help others and the beta team.

Setup

• Next.js 16.3.5 App Router, Node 24, Fluid compute, 2048 MB, single region (bom1)
• One Hono app served by thin App Router route handlers. The same application code ran under four function layouts, so the only variable was maxDuration grouping (confirmed with vercel inspect):

How we measured

• Platform duration: report.durationMs from the log drain.
• Handler duration: timed inside our framework middleware, so it excludes anything before the handler runs.
• Instance identity: each process creates a UUID on globalThis when our module first loads and logs {id, ageMs, rss} to stdout at most once per 30s. A new instance shows up as a new ID with ageMs under 5s.
• Caveat: the drain's request ID can't be joined to our request events, so attribution is statistical (timing, distribution shape, instance age).

1. A single fixed ~2.5s mode across unrelated trivial routes

In layout B, five unrelated trivial routes (p50 of 12–100ms) all had p99 ≈ 2,783ms. In layouts A and D the same routes had p99 of 70–300ms.

Histogram for those routes in B: