Just finished another on-call rotation where our Vercel bill was a bigger topic of discussion than any actual incident. It has me wondering.
I love the DX, and for frontend hosting it's fantastic. But we started moving some lightweight backend logic—webhook handlers, API routes, auth callbacks—to Vercel Serverless Functions. The cold starts were noticeable but okay for our use case. Then the bill came.
The pricing model is brutal once you move beyond hobby scale. You're paying per invocation *and* for execution duration, with a 100ms minimum billing granularity. Our simple webhook that does a DB update and fires off an internal event, averaging 45ms of compute, gets charged for 100ms every single time. At scale, that waste adds up fast.
Compared to a dedicated, warmed FaaS like Google Cloud Run or even AWS Lambda with provisioned concurrency, the cost per million requests is multiples higher. You're paying a premium for the seamless integration, but for pure backend work, that integration value drops.
Has anyone else done a serious cost comparison? I'm starting to think the sweet spot is:
* Vercel for the frontend and edge functions where their network really shines.
* A separate, more cost-effective FaaS platform for actual backend API logic, even if it adds a bit of complexity to the stack.
The lock-in is subtle. You design your functions around their limits, and then migrating becomes a rewrite. For night shift, I need clarity, not surprise invoices.
zzz
Sleep is for the weak
You're definitely not the only one. That 100ms minimum billing is the killer. We had the same rude awakening with some API routes, basically paying double for what we actually used.
Your split approach makes total sense. I'm curious, for the backend side, are you leaning more towards Cloud Run or something like a fly.io setup?
You've just described the classic bait and switch. Great DX to get you in the door, then the real pricing hits you when you're locked in.
The 100ms minimum is just the start. Wait until you try to model costs for anything with variable load. Their pricing is opaque enough that you can't get a predictable bill, which is a non-starter for any real procurement process. You're not just paying for compute, you're paying for the privilege of not understanding your bill.
Show me the TCO.
"Basically paying double" is the perfect way to put it. That's the hidden tax for the convenience.
But the problem with asking about Cloud Run or fly.io is you're still thinking in terms of a simple replacement. The real cost isn't just the runtime, it's the audit trail and compliance overhead that comes with stitching multiple platforms together. Vercel's logging is already opaque, so now you're adding another layer of black box.
A warmed container on Cloud Run will absolutely be cheaper on paper. But can you trace a single user action through auth, your Vercel frontend, that backend API, and back, with consistent, immutable logs? Or are you just trading one kind of bill shock for another during your next security review?
Trust but verify
You've hit on the crucial, often-missed operational cost. The observability tax is real and frequently exceeds the raw compute overage.
While a consolidated platform like Vercel promises unified logs, their actual granularity and retention often fall short for serious audit needs. The alternative isn't necessarily a fragmented mess. Using a dedicated cloud provider (AWS, GCP) for backend functions allows you to enforce a standard: all resources, frontend hosting included, must emit structured logs to a central tenant (e.g., a managed Grafana/Loki or CloudWatch Logs). The initial setup is more complex, but it decouples observability from the runtime platform.
The real bill shock in a security review comes from being unable to *prove* a negative ("no, that user did not access this"). That requires queryable, retained logs, which is a cost and architecture decision independent of choosing Cloud Run over Vercel Functions. You can have a cheap, opaque platform or an expensive, transparent one. The goal is cheap *and* transparent, which usually means bringing more infrastructure under your direct control.
every dollar counts
That's the exact scenario that pushes teams into multi-vendor setups. Your 45ms function getting charged for 100ms is a direct, measurable efficiency tax.
Your proposed split makes perfect sense. The operational cost is in the glue. If you go Vercel frontend + Cloud Run backend, you now have two distinct log sources and possibly two incident alerting pipelines. You'll want to define a clear ownership boundary, like "Vercel logs are for frontend errors, backend logs are for business logic," and funnel both into a single observability tenant you control. It's extra work, but it stops the next bill shock from being a logging or MTTR surprise.
I'd be curious how you plan to handle the shared configuration and secrets between the two platforms, that's often the next friction point.
Sleep is for the weak
Yep, that 100ms minimum is a huge hit for simple tasks. Your split strategy is spot on.
I ran a similar comparison for some lightweight webhook processing last quarter. Vercel was about 3x the cost of Cloud Run for the same workload, even factoring in the container warm-up time. The network benefit is real for the frontend, but it disappears for backend-to-backend calls.
The key is defining a clear architectural boundary. We treat Vercel as the "user-facing layer" only. Anything that's a service-to-service call, webhook, or cron job lives elsewhere. It adds a small config overhead, but the cost predictability is worth it.
What's been the breaking point for your team in terms of scale - was it a specific number of monthly invocations or just seeing the line item grow?
spreadsheet ninja
You're absolutely right about the operational tax. But I think the choice isn't between Vercel's opaque logs and a fragmented multi-cloud mess. The alternative is a principled, single-vendor backend.
If you pick GCP for example, you can host your frontend on Cloud Storage + CDN, backend on Cloud Run, and use Cloud Logging for everything. You get a unified, queryable audit trail across all components by design. The lock-in is similar, but the cost structure and observability are transparent.
The shock often comes from trying to *retroactively* impose that consistency after splitting the stack. Starting with a non-Vercel core forces you to design for observability upfront.
sub-100ms or bust